Towards L2s with payment channels

By: Barnabé Monnot

Blockchains scale in a networked fashion. As the capacity of a single chain is reached, new chains are propped up to provide an environment to execute excess user demand. Yet trade-offs abound.

Sidechains patch together a network by bridging assets from one chain to another. Yet all chains in the network settle on themselves, and rely on the word of their counterparties - either the sidechain or the bridge operators - to certify asset ownership. When assets originate from a highly secure "hub chain", it is sometimes unsatisfying to trade cheaper and faster execution against the lower security of parallel chains.

The issue, as always in decentralized systems, is trust. How do I trust what my counterparty claims? Bitcoin removed the need for trust inherent in payment systems, replacing it with cryptography and incentives. Ethereum further removed the trust in correct execution of arbitrary programs. Can we follow this pattern to scale safely?

We'll consider here a clever use of Bitcoin's semantics to produce a network of trustless, cheap and fast payment channels known as the Lightning network. Conceived in 2015 by Joseph Poon and Thaddeus Dryja, it is estimated to have capacity at least equal to 4,600 BTC as of September 2022. During our exploration, we'll emphasize how the Lightning network bootstraps Bitcoin's security to protect users against theft.

From Bitcoin to Lightning

Some words on Bitcoin

On the Bitcoin network, users send each other payments by creating and signing Unspent Transaction Outputs (UTXOs). When Alice wishes to send 1 BTC to Bob, she collects the set of UTXOs spendable by her. Alice currently owns one UTXO for 0.5 BTC, and one UTXO for 0.75 BTC. She uses both UTXOs as inputs to her transaction, and outputs two new UTXOs:

• One UTXO spendable by Bob, for 1 BTC.

• One "change" UTXO, spendable by Alice, for 0.25 BTC.

UTXOs in this special case of simple payments represent notes, like banknotes: units of value which are added with one another. More generally, UTXOs represent rights, encoded in a minimal language called Bitcoin Script.

With simple payments, the UTXOs represent the right for Alice to use a note as input to a transaction, with Alice's public key registered on the UTXO. Once Alice appends her signature to the UTXO, it unlocks the value contained and inputs it to the transaction. Yet more complex operations are built with the UTXO model.

Multi-signatures are such an operation. A multi-sig UTXO becomes spendable as soon as some fixed number of signatures are obtained, from a larger set of accounts. For instance, a 3-of-5 multi-sig UTXO requires 3 signatures from a set of 5 accounts to unlock the value contained within.

Building payment channels

The multi-sig primitive is key to create an infrastructure where a set of parties has joint rights. It is indeed a key to the Lightning network. Let's see how.

Assume Alice and Bob trade often between one another. They could, every time they do a trade, exchange bank notes with one another, i.e., settle the trade. But this is cumbersome, so more often, Alice and Bob would simply keep a running tally, “Alice paid $2 to Bob”, “Bob paid Alice $3” etc. The current state of their balances can be reconstituted by following the flows. Meanwhile, let's say once every month, Alice and Bob check their current balances, one of them sends the amount owed to the other with cold hard cash, and all the trades are settled in one fell swoop.

How could we replicate this pattern on Bitcoin? We don't want Alice and Bob to settle every payment they are doing to each other, as settling means executing one Bitcoin transaction every time, which is expensive. But keeping a "running tally" off-chain means that we introduce additional trust assumptions. We want both Alice and Bob to trust that neither of them can run away while some amount is owed to one of them!

One way to do so is by adding some skin-in-the-game. We're looking for a system that allows Alice or Bob to settle at any time, without requiring an action from their counterpart. A multi-sig is the right infrastructure: when Bob does a payment, he can give Alice the right to settle, without making settlement mandatory. In other words, the multi-sig must control an amount of funds at least equal to the maximum amount currently owed by either Alice or Bob. Whenever Alice wants to settle, for instance because she needs the bitcoin sent to her by Bob, she can take Bob's "right" to the multi-sig and close the channel by withdrawing her share of the pot.

Struck by Lightning: why Lightning is secure

Let's be more concrete about the Lightning payment channel network. Alice and Bob open a channel by funding a 2-of-2 multi-sig between themselves. It is not important who makes the funding transaction, Alice, Bob or even both of them. The multi-sig starts with some balances for both Alice and Bob. In our example, let's say that Alice funds the multi-sig with 1,000 satoshis (1 satoshi is 100,000,000-th of a bitcoin). The initial balances are (1,000; 0).

Since the multi-sig requires both their signatures to process any transaction, how can Alice ensure that she can retrieve her 1000 satoshis if Bob is unresponsive? Along with the funding transaction, Alice creates a refund transaction, engaging Bob to release the 1,000 satoshis from the multi-sig should Alice settle. Bob signs the refund transaction before Alice broadcasts the funding transaction, giving Alice certainty that she can always retrieve her 1,000 satoshis.

Apart from withdrawing her initial balance, what Alice can do with the multi-sig funds is to send a payment to Bob, since Bob's balance in the multi-sig is zero. So let's say Alice sends Bob 200 satoshis, and the balances are now (800; 200). But what does Alice send exactly?

To send Bob the 200 satoshis, Alice requests an invoice from Bob. Bob signs the invoice, which contains a commitment to a secret that only Bob knows. Once Alice receives the invoice, she signs it herself and broadcasts it back to Bob. In this sense Bob "receives" the 200 satoshis: Alice made a binding promise to pay them to Bob, but this promise exists only off-chain, and is not seen by the Bitcoin network at this stage.

Now what could go wrong? Alice could submit the initial refund transaction to the multi-sig, and leave with her 1,000 satoshis. Yet Bob has a more recent commitment from Alice, granting him 200 satoshis. To prevent such malicious behaviour, a transaction granting funds to a user always comes with a timelock.

Specifically, a timer starts when Alice submits the initial refund transaction for settlement. If Bob is able to submit a more recent transaction from Alice before the time elapses, he will be able to prove that Alice is attempting to settle an old state. When Alice signed Bob's invoice, she included a cryptographic revocation of her own previous secret. Armed with Alice's initial recent transaction and her more recent revocation of the transaction, Bob has all the evidence he needs to indict Alice.

The punishment is set to the worst possible penalty. Bob receives all the funds kept in the multi-sig, i.e., the 1,000 satoshis Alice initially committed. This ensures that for any level of balances, none of the parties have an incentive to deviate from the protocol.

Properties of Lightning

We'll take a high-level view here to understand what makes Lightning tick, and where this scaling solution fits in our larger design space. How does the Lightning network differ from a sidechain?

The result of off-chain computations on sidechains is settled back to the parent chain by letting the sidechain communicate its state to the parent chain. There is no inherent proof of the validity of the state: one must rely on the sidechain's word, via its bridge, to evaluate the state.

With the Lightning network, it is impossible for anyone to commit theft of funds by creating invalid state transitions. Alice can never pretend that Bob committed to sending her 500 satoshis, if he never signed such an invoice. When Bob tries settling an outdated state, Alice can challenge the settlement by making available some data proving that she holds a more recent commitment from Bob.

Finally, if Bob is unresponsive and Alice desires closing the channel, she can emit a transaction to that effect, leaving Bob time to acknowledge the closure and get his own funds back, or letting Alice take custody of her funds again without Bob's involvement. The ability to always exit and repossess one's own's assets on the parent chain is critical to extend the parent chain's perimeter of security. On a sidechain, one's assets may be frozen should the validator set of the sidechain censor a specific user's withdrawals.

As more peer-to-peer channels open between pairs of users, a network emerges. Users of a channel may advertise the existence of their multi-sig, broadcasting to the Lightning network that a new link is available. The Lightning network enables multi-path routing. If Alice wants to send funds to Carol, but doesn't have a channel open with Carol, she is able to route her payment via her own Alice-to-Bob channel and Bob's own channel with Carol. This only works when all channels along the path have sufficient capacity to route the payment. Today, liquidity providers and "payment hubs" naturally emerged to fill such gaps in the network.

Alice and Carol do not have a channel open with each other, but Alice and Bob do, and so do Bob and Carol.

Towards general execution

At this point, a natural question appears: could we extend the Lightning construction to any type of computation on the child chain? Sidechains such as Polygon PoS are popular because they offer EVM-based smart contract developers a scalable environment to deploy their contracts on. The Lightning network is powerful for peer-to-peer payments, could we do the same for general smart contracts?

One of the two original authors of the Lightning whitepaper, Joseph Poon, answered this question with the Plasma design, co-authored with Vitalik Buterin. Users deposit their assets to the Plasma smart contract on the parent chain. Each asset is issued an "ID", a ticket number identifying the asset. A Plasma operator collects transactions executed on their network, which reads "Alice sends Bob assets with ID 12", "Bob sends assets with ID 12 to the Uniswap contract", etc. The owner of the asset is always clearly assigned, and a hash of the ownership registry is posted on the parent chain periodically.

When Bob wants to exit, he goes to the smart contract on the parent chain and makes a claim, "I own assets with ID 12!" Given the ownership registry hash, Bob can prove he is indeed the owner. But we're back to the Lightning network dilemma: does Bob really still own assets? Has he perhaps sent them to Uniswap in the meantime?

Additionally, while payment channels settle the validity of state transitions with a simple cryptographic check, no such thing exists for general purpose execution, so how do we fully convince ourselves that Bob isn't making a claim out of thin air? A malicious Plasma operator could publish a commitment to an ownership registry that is not consistent with the transactions actually executed on the Plasma.

Much like in Lightning, we hold off before making any decision. A user could come to the smart contract and contradict Bob's claim, exhibiting a more recent transaction where Bob sends his assets to a different place. When Bob makes an invalid claim, we rely on fraud proofs to contradict him, showing that he never owned the assets he claims to.

But therein lies the rub: to guarantee exit, Bob may need to retrace the asset's steps from its arrival on the Plasma all the way to the transaction conferring him ownership. Without getting into the technical details, keeping that chain of causality available and usable by the Plasma is a major technical challenge, which defeated some its earliest instantiations. Overall, making Plasma work requires many careful trade-offs, so much so that a construction with less intricate mechanisms but a more foolproof approach eventually emerged as a more realistic contender for scaling blockchains: rollups.

Conclusion

The Lightning network provides a first example of a scaling solution inheriting its security from the base layer it builds on. To extend the perimeter of security of the base layer, two ingredients are necessary: *verifiable settlement*, so that the base layer can convince itself of the validity of off-chain execution, and data availability*, so that users may always challenge unlawful exits. While generalizing the Lightning construction proved to be a challenge, a different pattern, rollups, may offer a way forward.