Hey EigenLayer community, our team at Lagrange Labs has recently been working on an architecture for a shared cross-chain state security zone that we want to purpose today.
As background, Lagrange Labs is focused on building secure infrastructure for zero-knowledge based cross-chain state and storage proofs. An abridged version of our design is outlined below but the full version can be found on our HackMD.
Lagrange Cross-Chain State Committees
Ismael Hishon-Rezaizadeh & Charalampos Papamanthou
- Any protocol that relies on cross-chain state can plug into consuming inductive ZK state proofs, derived from a chain agnostic light client committee based on restaked ETH.
- Isolated k-of-n bridges, Ethereum light client bridges and ZK light client bridges face inherent security limitations at scale.
- Restaking (via EigenLayer) provides a power primitive to dynamically scale the underlying security of state proof generation.
- Lagrange Labs has built the first proof system that enables the creation of inductive zero-knowledge proofs of the state of any arbitrary chain or roll-up with super-linear security.
Existing Cross-Chain Security Models:
Limitations of Isolated Cross-Chain State Security:
Current approaches to messaging and bridging between EVM chains rely on isolated economic guarantees. These guarantees typically are k of n assumptions, where proving that a state exists or a transaction occurred on a different chain requires a plurality, k, of a set of n nodes to agree and sign. Examples of these approaches include multi-signature wallets, threshold signatures schemes across attestation sets, Tendermint proof-of-stake consensus and proofs of Ethereum’s light client sync committee.
While each of these approaches have distinct advantages, they all share a central flaw: Each cross-chain protocol has a capped sized set of validators that can be attacked in isolation by compromising a plurality of its nodes. Empirically, we’ve seen isolated k of n security guarantees fail, including the well-publicized hacks of Ronin Bridge ($650m), where 5 out of a set of 9 validators were compromised and Harmony Horizon ($100m), where 2 out of a set of 5 validators were compromised.
Security across isolated k of n protocols is either constant or sublinear with respect to staked collateral. In short, as the amount of available collateral increases, security increases at a diminishing rate as the validator set begins to cap out in size.
To improve on the limitations of isolated k of n security guarantees, newer cross-chain protocols, such as zkBridge, Polyhedra Network and Succinct Labs, have begun to generate proofs of the signatures by Ethereum’s light client sync committee members. While Ethereum’s light client sync committee provides a rough proxy for Ethereum consensus, its security has inherent limitations when used for proving Ethereum state on other chains.
Understanding Ethereum Sync Committee:
The sync committee of Ethereum is a group of 512 Ethereum validators that are chosen at random every 256 epochs (~27 hours). The sync committee is responsible for continually signing new block headers, so that Ethereum light clients can verify chain state, without having to know the entire validator set. Nodes are given 512 epochs (~54 hours) of prior notice before they become a sync committee member.
The security of light client bridges, ZK bridges and sync committee proofs are all based on verification of signatures from the Ethereum light client sync committee. As the size of the sync committee is fixed, the economic security that underpins it is also capped over a 27-hour window. Once slashing is eventually implemented for Ethereum sync committees, the economic security will be bounded as follows:
Economic Security of Sync Committee = 512 nodes * 32 Eth * $1650 USD/ETH = $27,033,600
Threshold to Compromise Sync Committee = $27,033,600 * 2/3 = $18,022,400
Limitations of Ethereum’s Light Client and ZK Light Client Bridges:
While light client bridges and ZK light client bridges are thought of as a gold standard for cross-chain interoperability, the amount of assets they can secure with randomized sync committees is severely limited. As previously shown, the amount of collateral that colluding nodes would have to burn to simultaneously compromise all Ethereum light client and ZK light client bridges is capped at $18m.
Consider a situation, where the sum of the value of all assets secured by all light client and ZK light client bridges is of an amount k. When k < $18m, all assets secured across the bridges are safe, as an attack is not economically viable.
As k grows such that k > $27m , it becomes profitable for a group of bad actors in the sync committee to attest to malicious block in order to compromise the secured assets. The only remaining security once this economic threshold is passed is the complexity of requiring 342 random nodes (2/3 of the sync committee) to communicate and coordinate an attack over an 81-hour window.
Introducing Lagrange’s Shared Cross-Chain State Security:
Cross-Chain State Proofs Through Shared Security
Lagrange Labs is developing the cross-chain state committee to provide a more secure alternative to both randomized light client sync committees and isolated k of n bridges for applications that require trustless cross-chain states. The security of the Lagrange cross-chain state committee is derived from an ever growing, dynamically sized set of nodes with leveraged rehypothecated collateral, either restaked with EigenLayer or staked with liquid staking derivatives, such as Rocket Pool.
The Lagrange cross-chain state committee is designed to be extensible to generate state proofs for any chain, irrespective of consensus mechanisms, sequencer or validator set specifications. At launch the cross-chain state committee will provide state proofs for Ethereum, Polygon, Arbitrum, Optimism & zkSync.
Nodes wishing to join the cross-chain state committee must either restake via EigenLayer or rETH into Lagrange’s Ethereum contracts. A node must provide at least 32 ETH worth of rehypothecated collateral to join the network and must indicate which chain or roll-up that they wish to provide attestations for.
Every node in the network must run a containerized validator or watcher of a relevant chain or roll-up. If multiple restaked Ethereum nodes are operated by the same actor, each node can instead maintain a secure** RPC connection to a single instance of that chain’s validator (ideally run locally by the node operator). Once in the network, a node must execute a BLS12-381 signature on every new block that reaches finality on the chain that they are attesting to.
The set of attestors for each chain are active for a duration of n blocks, otherwise called an attestation period. The length of the attestation period is variable for each chain based on the fraud proof time required to slash colluding nodes. As opposed to the Ethereum light client sync committee which has a cap of 512 nodes, the consensus mechanism that underpins the cross-chain state committee supports an unbounded set of nodes.
As such, the collateral behind each attestation can scale dynamically as is required to create secure proofs for each given chain. This property is what enables the Lagrange cross-chain state committee to be the first protocol to enable generalizable state proofs of any arbitrary chain with super-linear security.
Joining the Cross-Chain State Committee:
During each attestation period, cross-chain state committee nodes can signal that they want to either join or leave the attestation set at the end of the period. Nodes wishing to join the cross-chain state committee must provide at least 32 ETH worth of rehypothecated collateral through either restaking with EigenLayer or rETH as collateral into Lagrange’s contract on L1 Ethereum.
Nodes that wish to leave the attestation set must submit a transaction to Ethereum requesting removal at the end of the attestation period. At the end of an attestation period* the active set of attestors is amended based on the attestors that have requested to leave or join for the next period.
Since a list of active peers is maintained via Ethereum contracts, verifying peer nodes can be done independently by every attestor. In order to easily prove inclusion of nodes in the active set of attestors, each node independently constructs and stores a Merkle tree of the public keys of all active committee members. This committee root is constructed with a SNARK friendly hash function, such as Poseidon, Pedersen or Reinforced Concrete.
Responsibilities of a Cross-Chain State Attestor:
Each cross-chain state attestor is responsible for executing a signature with its BLS12-381 key on every finalized block during the attestation periods that it is active for. Each signature is executed on a tuple containing a block header, a Merkle root of the public keys of the current committee and a Merkle root of the public keys of the next committee.
struct block {
var block_header,
var current_committee,
var next_committee,
}
Both of these signatures create slashable conditions for fraud proofs on malicious nodes. Each cross-chain state committee node therefore must independently check the state of both Ethereum and the attested chain before executing each signature. The three basic checks that every attestor performs before signing include:
- The block_header is correct and corresponds to a finalized block of the chain that is being attested to.
- The current_committee Merkle root was correctly derived from the public keys of the attestation set on Ethereum for a given block of the arbitrary chain.
- The next_committee Merkle root was correctly derived by altering the current_commitee at the end of the attestation period with any nodes who opted to enter or leave the attestation set.
Inductive Zero-Knowledge State Proofs:
For a state proof of a single block to be valid, the following recursive properties must hold:
- At least 2/3 of the n attestors restaked for a given block b must have signed the block header. The public keys of these nodes are stored in the current_committee Merkle tree.
- The current_committee of block b equals the next_committee tree of block b-1.
- Block b-1 is either the genesis block or is valid with respect to these three conditions.
This recursive relationship allows any block to be proven as valid via an inductive proof, starting with the base case of an initial hardcoded genesis attestor set. To prove an arbitrary block, a contract requires an inductive zero-knowledge proof of the validity of the previous block with respect to genesis and an aggregated BLS signature of the current_commitee of the present block:
struct block {
var block_header,
var current_committee,
var next_committee,
}
struct block_attestation {
var block,
var signer_public_keys
var bls_signature,
var previous
}
def inductive_state_proof (block_attestation, genesis):
verify_bls(block_attestation.block, block_attestation.bls_signature,
block_attestation.signer_public_keys)
for attestor_key in block_attestation.signer_public_keys:
verify_inclusion(attestor_key, block_attestation.block.current_committee)
require(3 * block_attestation.signer_public_keys.length >= 2 *
block_attestation.block.current_committee.length)
require(block_attestation.previous.block.next_committee ==
block_attestation.block.current_committee)
if block_attestation == genesis:
return true
else:
inductive_state_proof(block_attestation.previous, genesis)
Call For Collaborators:
If you are a cross-chain protocol or application layer DApp that is interested in collaborating with Lagrange Labs on building a cross-chain state committee, please reach out to ismael@lagrange.dev or cpap@lagrange.dev.