Types of Verifications
Background
Polymer Hub allows developers to choose between different client types, each managing the latest state of a connecting rollup on Polymer Hub. These clients are crucial for validating packets sent between various rollups.
Polymer Hub serves as the state manager for communicating rollups, relying on the rollup's chain state instead of individual transactions.
All Polymer Hub clients are based on the rollup's architecture i.e how a rollup is communicating its latest state to Ethereum via the Native Rollup Bridge. Since rollups are designed to be faster, there’s an inherent lag between the Sequencer’s off-chain view and the on-chain view on Ethereum.
As you move away from Ethereum to access the latest rollup state, you increase centralization (such as the sequencer acting dishonestly) and reorg risks.
As a developer, you can select the client that best aligns with your use case and the trade-offs you're comfortable with.
Our clients are designed around these critical pillars for rollup interoperability: ordering (re-org resistance) and truth (validity).
- Ordering: Finality of the state in question (Risk: Re-org and loss of transaction).
- Truth: Validity of the state transaction, i.e., execution of a transaction (Risk: Processing fraud).
Guaranteeing both safety properties is crucial for rollup-to-rollup interoperability.
Trade-off Matrix
| Client Type | Source of Truth (Validity) | Re-org Protection (Ordering) | Speed/Latency |
|---|---|---|---|
| Ethereum Client | Ethereum | Yes (Ensures data is finalized on Ethereum) | 150 mins |
| Lagrange Client | State Committee/AVS | Yes (Derived from finalized data on Ethereum) | 30 mins |
| Sequencer Client | Sequencer/Rollup Operators | Partial (Blocks are off-chain, checked against L1) | 6-10 secs |
Ethereum Client
Every rollup proposes a state on Ethereum. Polymer Hub being a rollup itself, is able to read any information present on Ethereum like other rollup states via its own Native bridge (acting as the L1 light client). This direct view from Ethereum is used to build an image of the source rollup, i.e latest state of the rollup as per Ethereum.
- Source: Takes the input state directly from Ethereum (e.g., for Optimism, the proposer contract). 1st party source of truth, the best actually i.e Ethereum.
- Features:
- This client also makes sure that the ordering of transactions is finalization on Ethereum. Add both ordering and data availability guarantees.
- In future will allow app developers to program a custom challenge window, ranging from zero (immediate state root proposal) to a full seven-day window.
- Risk: Similar to all rollup native bridges, trust lies in the rollup operators and the ability to submit fraud, provided there is an honest party.
Lagrange ZK Client
The next step towards getting closer the latest transactions on a rollup are the the batches of transactions submitted by rollups on Ethereum. They batches are posted so that anyone can derive the latest state of rollup and challenge the sequencer in case a fraudulent state is proposed.
Lagrange uses the same data to compute the state of rollup and attests (BLS signatures) to it backed by EigenLayer AVS stake, giving it crypto-economic security - that can be slashed in case they sign a wrong state root.
- Source: The Lagrange State Committee (LSC) network, a simple and efficient ZK light client protocol for optimistic rollups that settle on Ethereum. 3rd party source of truth.
- Features:
- Aggregated ZK proofs for cross-rollup transactions significantly lower the cost and complexity of proof generation, benefiting from economies of scale and dynamic security.
- BLS Signatures provide a quicker and more reliable method for verifying the state of rollups, addressing challenges associated with state updates in optimistic rollups.
- Risk: The Lagrange State Committee network is an EigenLayer AVS (Actively Validated Service), backed by crypto-economic security.
Sequencer Client
Moving a step further to the exact source of ordering and state transition, the Sequencer. Sequencer is simply a centralized process that every rollup team operates, that orders incoming user transactions, build blocks and then executes these transactions → this is the primary source where the new state is created, in real-time!
This state is signed and emitted by the sequencer to fellow nodes (P2P gossip network) to track the rollup chain, Polymer Hub taps into this P2P network to get the latest state as fast as the blocks are produced.
- Source: The sequencer of the rollup. 1st party source of truth.
- Features:
- Fastest client possible, only limiting factor is block production rate of the rollup.
- This client tracks the L1 origin of the rollup to protect against L1 reorgs (existing forks) to maintain a consistent chain view of the rollup between the networking rollups.
- Risk: Trust lies in the sequencer i.e rollup operators. Given this client operates pre-finality, there is significant reorg risk (future L1 reorg) till the ordering is finalized on Ethereum.