Bitcoin Lightning Network - Unlimited blockchain scale?

Background

The Bitcoin blockchain has scalability issues. Transactions on the blockchain can take a long time to confirm and incur non-trivial fees, especially during periods of high usage. The Lightning Network proposes a solution to these scalability issues.

Idea

The Lightning Network is a second-layer protocol on top of Bitcoin. It enables users to transact with one another directly without broadcasting their transactions to the Bitcoin blockchain until they want to settle the final balance. This significantly speeds up transactions and reduces fees.

Channels

The main concept introduced is that of "channels." Two participants open a channel between them and transact by updating the balance sheet between them. These transactions are not broadcast to the blockchain, thus remaining off-chain. The channel can stay open for any duration, during which countless transactions can take place. Once the participants decide to close the channel, only the final state (balance) is broadcast to the blockchain.

Different from layer 2s on Ethereum

Although I used the term second-layer protocol earlier, this is not be mixed up with a typical layer 2 on Ethereum and co. In a layer 2 network, transactions or blocks are checkpointed on the layer 1 at periodic intervals. Everyone who is on the layer 2 network moves in tandem — any state updates require coordination with the layer 2 operators to create blocks. State changes in a channel on the lightning network only requires coordination among the 2 parties that are involved in that channel. This key distinction unlocks unlimited scalability for lightening network.

  • For more details on the differences, check this vetted answer from ChatGPT Both the Bitcoin Lightning Network and Ethereum Layer 2 solutions aim to address the scalability issues of their respective Layer 1 blockchains. However, the approaches, architectures, and specific use-cases can differ. Here's a breakdown of their differences:
    1. Purpose:
      • Bitcoin Lightning Network: This is primarily a payment channel network designed to facilitate fast and low-cost Bitcoin transactions. It allows users to open bilateral channels, lock up some Bitcoin, and then transact off-chain with instant finality.
      • Ethereum Layer 2: Ethereum's Layer 2 solutions are more diverse, as they're not just about payments. They're meant to scale general smart contract computations and interactions. Layer 2 can encompass a variety of scaling solutions like Rollups, Plasma, and state channels.
    2. Architecture & Techniques:
      • Bitcoin Lightning Network: Uses payment channels to allow off-chain transactions. Funds are locked in a multi-signature wallet, and participants can transact multiple times off-chain. Only the opening and closing of channels involve on-chain transactions.
      • Ethereum Layer 2:
        • Rollups: Aggregate multiple transactions into a single one, reducing the data stored on-chain. There are two main types: zk-Rollups (using zero-knowledge proofs) and Optimistic Rollups (using fraud proofs).
        • Plasma: Creates child chains that run parallel to the main Ethereum chain, periodically committing their state to the main chain.
        • State Channels: Similar in concept to Bitcoin's payment channels, but they're more general in nature, allowing off-chain execution of smart contracts.
    3. Finality:
      • Bitcoin Lightning Network: Transactions made within the channels achieve instant finality, but settling the channel's final state on the Bitcoin blockchain still requires block confirmations.
      • Ethereum Layer 2: The finality depends on the specific solution. For example, with Rollups, the finality is as fast as the on-chain data availability and verification. With Plasma, users may need to wait for challenges in case of malicious behaviors.
    4. Interoperability:
      • Bitcoin Lightning Network: It's specifically designed for the Bitcoin network.
      • Ethereum Layer 2: Ethereum's Layer 2 solutions are meant for Ethereum's ecosystem and can interact with a variety of tokens and smart contracts within that ecosystem.
    5. Security:
      • Bitcoin Lightning Network: Security is rooted in the Bitcoin blockchain, but there are nuances, such as the requirement to monitor channels to prevent fraudulent closes.
      • Ethereum Layer 2: Security considerations can be more complex due to the diverse nature of Layer 2 solutions. Each approach (Rollups, Plasma, State Channels) has its own set of security guarantees and trade-offs.
    6. Adoption & Use-cases:
      • Bitcoin Lightning Network: Primarily used for payments and microtransactions.
      • Ethereum Layer 2: Given Ethereum's focus on decentralized applications and smart contracts, Layer 2 solutions support a broader range of use-cases, from DeFi to NFTs and beyond. In summary, while both the Bitcoin Lightning Network and Ethereum's Layer 2 solutions are aimed at scalability, they are tailored to the unique characteristics and requirements of their respective blockchains. The Lightning Network is more specialized for Bitcoin payments, while Ethereum's Layer 2 solutions cater to a broader set of decentralized applications and use-cases.

Routing

The Lightning Network allows for the creation of a network of channels. If Alice wants to send money to Charlie but doesn't have a direct channel with him, the payment can be routed through Bob, given that Alice has a channel with Bob and Bob has a channel with Charlie.

This is similar to how the Internet works today. Packets of information are routed through nodes in the network. We don’t always need a direct path between 2 parties to facilitate communication — very often, we don’t.

Security

The security of transactions is maintained through smart contracts on the Bitcoin blockchain. If any participant acts maliciously, the other participant can close the channel and claim their rightful balance using the latest agreed-upon balance sheet.

The Bitcoin network had support for smarts contracts for a long time using Bitcoin scripts. However, Bitcoin script is not turing complete where is EVM is. For example, Bitcoin script doesn’t support loops — remember this when we discuss about the design for how channel settlements occur

Advantages

  • Scalability: Allows for millions to billions of transactions per second.
  • Low fees: Transactions are primarily off-chain, so blockchain transaction fees are not incurred for every payment.
  • Instant payments: Without the need for block confirmations, payments are nearly instant.

Disadvantages

  • Only works for payments

Lifecycle of a Channel

To open a Lightning Network channel, an on-chain transaction (often referred to as the "funding transaction") is required. This transaction creates a multi-signature wallet, which both parties in the channel can access using their respective private keys. The funds in this multi-signature wallet represent the capacity of the channel.

Here's an example that walks through different steps in the life cycle:

  1. Channel Opening: Alice and Bob want to transact with each other over the Lightning Network. They agree to open a channel with a certain amount of Bitcoin. Let's say Alice commits 0.5 BTC and Bob commits 0.5 BTC, making the total channel capacity 1 BTC.
  2. Funding Transaction: They create a funding transaction on the Bitcoin blockchain. This transaction sends 1 BTC (0.5 BTC from Alice and 0.5 BTC from Bob) into a multi-signature wallet. This transaction, being on-chain, will require confirmation on the Bitcoin network and will incur the standard transaction fees.
  3. Channel Updates (Off-chain): After the channel is opened and the funding transaction is confirmed, Alice and Bob can transact with each other as many times as they want without involving the main Bitcoin blockchain. These transactions are off-chain and are essentially updates to their balance sheet. The transactions are called Commitment Transactions.
  4. Channel Closing: When either Alice or Bob decides to close the channel, they can submit the final state of their balance sheet to the Bitcoin blockchain. This "settlement transaction" reflects the final distribution of the 1 BTC based on their transactions. This is another on-chain transaction and will again require confirmation and transaction fees.

To minimize on-chain fees, users are encouraged to keep channels open as long as possible and conduct as many transactions as needed off-chain. If users expect to transact frequently with each other, it makes economic sense to establish and maintain a channel rather than transact on-chain each time.

Commitment Transactions:

After opening the channel, Alice and Bob each hold a commitment transaction. This transaction reflects the initial distribution of the funds in the channel. For instance, if Alice commits 0.5 BTC and Bob commits 0.5 BTC, their commitment transactions would reflect these amounts.

  • Updating the Balance: Now, let's say Alice wants to pay Bob 0.1 BTC. They would update their balance off-chain (without broadcasting to the Bitcoin network) and create new commitment transactions to reflect the updated balance (Alice 0.4 BTC and Bob 0.6 BTC).
  • Safety Mechanism: Commitment transactions have built-in cryptographic mechanisms to discourage dishonest behavior. For instance, if Alice tries to broadcast an old state of the channel where she had more funds, Bob will have a predetermined window to contest this with the updated transaction. If Alice's dishonesty is proven (because Bob provides the newer transaction), Bob can claim all the funds in the channel as a penalty.
  • Closing the Channel: When either party decides to close the channel, they can broadcast the latest commitment transaction to the Bitcoin network, which will release the funds in the channel according to the final balance. This becomes an on-chain transaction and will require the usual confirmations on the blockchain.

Did you notice: The lightning protocol relies only on submitting a single Commitment transaction (the latest one) to settle a channel on the Bitcoin network. A naive design could have requested posting all state transitions in sequence — this can be prohibitively expense if done on EVM or even impossible since there can be arbitrarily large number of transactions off-chain. It’s impossible on Bitcoin network given that it doesn’t support loops.

Before we go further

Think about how you could design a mechanism to detect that a single proof submitted on chain is the latest one of a series of proofs?

Securing Commitment Transactions:

Commitment transactions in the Lightning Network are secured using a combination of time-locks and cryptographic "secrets" to ensure that an old state cannot be fraudulently broadcast by a malicious party without consequences. The process of contesting an old state involves what's termed as "penalty transactions" or "justice transactions.”

  1. Revoking Old States: When Alice and Bob update the balance in their channel, they effectively revoke the old state and agree on a new one. This revocation is done by exchanging secrets that would allow one party to punish the other if they try to cheat by broadcasting an old state
  2. Breach Remedy Transaction: When Alice and Bob create a new commitment transaction, they also create a "breach remedy" or "penalty" transaction. This transaction allows one party to claim all funds in the channel if they can provide the secret associated with the other party's old commitment transaction.
  3. Time-Locks: The commitment transactions include a time-lock mechanism. If Alice tries to close the channel using an old state, Bob has a certain time window (e.g., a day or two) to provide the secret for that state and claim all the funds using the breach remedy transaction. The time-lock ensures Bob has sufficient time to notice and act if Alice tries to cheat.
  4. Watching the Blockchain: To be able to contest an old state being broadcast, nodes have to monitor the blockchain or use third-party services, called "watchtowers," to monitor on their behalf. If an old commitment transaction is detected, the party (or watchtower) can use the relevant secret to punish the cheating party by claiming all the funds in the channel.
  5. Risk for the Cheater: The setup is such that the risk of trying to cheat by broadcasting an old state is very high. If caught — and the system is designed to make it likely they will be caught — the cheating party stands to lose all the funds in the channel. This strong financial disincentive makes it unappealing to attempt such fraud.

Trust in the Lightning Network

While the Lightning Network itself isn't strictly a "trust network" in the same way PGP's WoT is, it does reduce the need for trust. Channels in the Lightning Network are built upon the trust-minimized foundation of the Bitcoin blockchain. However, there's a certain level of trust in the network's topology and routing. When making a payment to someone you don't have a direct channel with, you trust intermediaries to route the payment properly (though they can't steal or divert the funds thanks to cryptographic guarantees).

The mental model I work with:

Internet: The internet routes packets of data between 2 parties using a network of untrusted nodes — the thesis is, each node in a route cannot interfere or steal information in the packets they route. They can however choose to censor.

Bitcoin Lightning: The lightning network works on similar principles, untrusted nodes in the network route value but cannot steal or cheat.

Channel Fees

I didn’t go into this in detail but as you can imagine each channel in the network has a routing fee — composed of a base fee (for using the channel) and variable fee (depending on the value routed). This provides a natural incentive for someone HODLing Bitcoin to generate revenue by acting like BGPs on the Internet to facilitate value routing.

The top liquidity providers on the Lightning network are, unsurprisingly, crypto exchanges — https://mempool.space/lightning/nodes/rankings/liquidity

Stats

At the time of this writing. There are 63,570 channels between 14,192 nodes with a total capacity of 5,408 BTC. See the lightning network live at https://mempool.space/lightning

Security concepts

HTLC — Hashed TimeLock Contract

This is the security concept that allows us to route payments across multiple channels. For example: Alice → Bob → Charlie

https://blog.summerofbitcoin.org/htlc-lightning-network/

RSMC — Revocable Sequence Maturity Contract

This secures the establishment of new Commitments and revoking old commitments (by exchanging secrets).