Eltoo: Lightning Update Mechanism
One of the core innovations that enabled Lightning in the first place was an off-chain update mechanism to renegotiate a new state and ensure that the old state can not be settled on-chain. Today, we’re excited to release our latest research paper on a new, simplified, update mechanism for layer 2 protocols, called eltoo.
As we all know, the core technology behind lightning is that it takes transactions off chain, basically what happens is that the user sends an onchain transaction that guarantees the existence, and the willingness to send-off the bitcoins, then a payment channel is opened between the sender and the receiver, in which the sender and the receiver can exchange transactions, without waiting for a block confirmation, basically thousands of times in a minute.
Eltoo is a new updating mechanism for the transactions in the payment channel, it works by having state represented as a set of two transaction, one update transaction spending the contract’s ouput making a new output, and one called a settlement transaction which spends the newly created update output and splits the funds according to the distribution wanted. A script included in the output allows either a new transaction to be attached to the channel immediately or else the settlement transaction will be enforced. Eltoo does this by having a new Sighash flag called SIGHASH_NOINPUT that allows a transaction input to be bound to any transaction output with a matching script. This allows us to skip intermediate updates in the channel and skip right ahead to the last transaction announced.
Eltoo aims to replace the current lightning mechanism that enforces a penalty on the misbehaving party; instead it just enforces the latest agreed-upon state of the off-chain contract. This also simplifies the data management for the lightning nodes, as they don’t need to store the hash preimages for the older invalidated states, they only need to store the latest update transaction and its settlement transaction. Eltoo can also be deployed incrementally due to a feature flag, nodes can just signal if they support Eltoo or not when connecting to other nodes.
Support us and the authors of this article by donating to the following address:3D2jvqZ3kkChFqRdAxHqH4g8tX4EiCEQUn