Skip to main content

Architecture

The Lagrange State Committee (LSC) network is conceptually similar to Ethereum's Sync Committee and will serve as a foundation for crypto-economic secure and trustless light client-based cross-chain bridging and messaging.

Ethereum Light Client vs Lagrange State Committee Light Client​

The Ethereum Light Client utilizes a sync committee of 512 randomly chosen validators that sign new block headers every 27 hours. This system enables light clients to verify chain state without knowledge of the entire validator set. However, its security is limited by the fixed committee size, with an estimated economic security threshold of about $26 million.

Economic Security of Sync Committee = 512 nodes * 32 Eth * $2400 USD/ETH = $39,321,600

Threshold to Compromise Sync Committee = $39,321,600 * 2/3 = $26,214,400

This cap on security becomes problematic as the value secured by light client bridges increases, potentially making attacks economically viable when the secured assets exceed the security threshold.

The Lagrange State Committee light client implements a scalable approach to address these limitations. It employs an unbounded set of nodes with leveraged rehypothecated collateral, either restaked with EigenLayer or staked with liquid staking derivatives. This architecture allows for dynamic scaling of security as required, accommodating an expanding set of validators. The Lagrange system features a flexible attestation period and supports state proofs for EVM-based chains beyond Ethereum. By enabling dynamic scaling of collateral behind each attestation, the Lagrange State Committee facilitates generalizable state proofs of arbitrary chains with super-linear security, overcoming the constraints of the fixed-size Ethereum sync committee.

Technical Note​

Our technical approach is inspired by the current implementation of the Ethereum sync committees that is used by Ethereum light clients to verify that an Ethereum block header d’ is valid, assuming a previous block header d is valid (without re-executing all transactions that lead from d to d’).

In particular, given two Ethereum blocks headers d and d’, and assuming you trust d, an Ethereum light client can verify that block header d’ is valid by verifying an aggregate signature by a certain number of public keys that are contained in either the current committee or the next committee field of d. The individual signatures are computed by Ethereum nodes that actually check the validity of d’ by replaying all transactions.

LSC was designed by combining Lagrange’s ZK Prover Network and EigenLayer restaking.

Key Components​

The key components of the Lagrange State Committee protocol are the sequencer, Database, gRPC Server, Consensus, and attestation nodes.

  • The Sequencer is responsible for fetching L2 batch data from L1 (Ethereum), and L2 blocks from EVM rollup chains and updating the database.
  • The Database stores new finalized batch with aggregate signatures and send non finalized batches to consensus for verification.
  • The gRPC Server a physical component of the architecture is responsible for communicating with attestation nodes.
  • The Consensus is responsible for computing aggregate signature and ensuring 67% of total voting power is used to sign the batch in order to consider it as finalized.
  • The Attestation Nodes are validator nodes operated by EigenLayer operators that participates in the State Committee protocol for aggregate signature generation.
State Committees Architecture Diagram

State Committee Contracts - The Lagrange service and Lagrange committee smart contract is deployed on the Ethereum mainnet. The smart contract manages epoch updates, voting power updates and calculates the Merkle tree. A Merkle tree is computed by hashing individual data blocks to form leaf nodes, then iteratively hashing pairs of leaf nodes to form parent nodes until a single hash, the Merkle root, is obtained. This root summarizes the data, allowing efficient and secure verification of the data’s integrity with minimal information.

LSC Node Requirements​

State Committee Nodes are the attesters within the Lagrange State Committees infrastructure that are responsible for signing the state roots of different chains. Lagrange cross-chain State Committees are not designed to replace proofs of consensus but instead are an alternative mechanism for chains whose finality or consensus is not provable within a zero-knowledge context.

Nodes wishing to join the cross-chain State Committees must restake via EigenLayer. A node must provide at least 10 ETH worth of rehypothecated collateral to join the network and must indicate which chain or roll-up 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 If an operator manages multiple restaked Ethereum nodes, they can establish a secure RPC connection to a single instance of the chain’s validator, ideally running locally on their system, for all nodes. Once in the network, the attestation node will sign the batch of rollup blocks using their BLS key (BN254 curve).

Responsibilities of a Cross-Chain State Attester​

Each cross-chain state attester is responsible for executing a signature with its BLS (BN254) key on every finalized batch during the attestation periods that it is active for. Each signature is executed on a tuple containing a batchHeader, committeeHeader. Merkle root of public keys, operators, and aggregated signatures of the batch.

//BatchHeader holds information about a batch of Layer 2 blocks and their corresponding Layer 1 anchor

struct BatchHeader {
			BatchNumber (uint64)
			ChainId (uint32)
			L2Blocks ([]*BlockHeader)
			L1BlockNumber (uint64)
			L1TxHash (string)
			L1TxIndex (uint32)
			L2FromBlockNumber (uint64)
			L2ToBlockNumber (uint64)
}

//CommitteeHeader contains committee information for the batch.
struct CommitteeHeader {
			CurrentCommittee (string)
			NextCommittee (string)
			TotalVotingPower (uint64) 
}

// Batch combines both headers and includes cryptographic data like public keys and signatures for verifying the batch 
struct Batch {
			BatchHeader (*BatchHeader)
			CommitteeHeader (*CommitteeHeader)
			PubKeys ([]string)
			Operators ([]string)
			AggSignature (string)
}

The signature executed on the tuple creates slashable conditions for fraud proofs on malicious nodes. Before executing each signature, a cross-chain State Committees node must independently check the state of both Ethereum and the attested chain and perform the three basic checks:

  1. The batch_header verifies the content of the batch that was signed

  2. The current_committee Merkle root was correctly derived from the public keys of the attestation set on Ethereum for a given batch of the arbitrary chain.

  3. 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.

info

The next subsections go deeper into the technicals of the Sequencer, Database, gRPC Server, Consensus and Attestation nodes.