The present article by Tokensight has been written to provide a technical overview of Omni, as an interoperability AVS on EigenLayer. In this piece, we’ll explore its consensus architecture, some objective and intersubjective slashing scenarios that may occur, and its innovative rollup-interoperable design for effective message relaying between rollups.

Omni is an interoperability solution that enables Ethereum rollups to communicate in a secure, performant, and globally compatible manner. It introduces a universal gas marketplace, where the process of gas payments across rollups is simplified. Users can pay fees in the native token of the source network, which is then converted into OMNI to compensate relayers on the target rollup. Alternatively, OMNI can be used directly as a payment medium for gas across all cross-rollup transactions.

Omni sets a new standard for secure cross-rollup messaging by deriving its cryptoeconomic security from restaked ETH via EigenLayer in an objective-fault context, and from EIGEN staking in an intersubjective-fault context. It employs a dual staking quorum consisting of the same restaked ETH (ETH Quorum) via EigenLayer and the native Omni token, OMNI (Omni Quorum).

The role of the Omni Operator Network is to contribute as validators within Omni's CometBFT consensus mechanism. To deter malicious behavior, Omni leverages the security of Ethereum through EigenLayer, relying on its Proof-of-Stake (PoS) system. Validators must stake capital in the form of bEIGEN tokens.

If an objectively-verifiable misbehavior is detected, the operator’s bEIGEN stake will be slashed. In cases of intersubjectively-agreeable misbehavior, an operator’s bEIGEN1 token will be forked into bEIGEN2, resulting in the loss of access to the former and the inability to redeem the latter.

CometBFT is a consensus mechanism enabling a network of validators to work together and update the blockchain's state. Each validator's voting power is proportional to their bonded stake, thus tying network security to the stake's value rather than solely the number of validators. This approach incentivizes validators to commit higher stakes to ensure robust security.

Here’s the high-level overview of how CometBFT works within Omni:

1. Proposer Selection: Each round, a proposer is chosen based on a deterministic round-proposing algorithm considering each validator's voting power.

2. Proposal: The proposer broadcasts a block proposal containing a batch of transactions to all validators.

3. Pre-vote: Validators broadcast a pre-vote for the proposed block if valid, or nil if no valid proposal is received within a set time.

4. Pre-commit: If a validator receives >2/3 pre-votes for the same block, it broadcasts a pre-commit for that block. If >2/3 pre-votes are nil, it pre-commits nil.

5. Commit: If a validator receives >2/3 pre-commits for the same block, it commits the block to its local blockchain, finalizing the block. If >2/3 pre-commits are nil, it moves to the next round.

6. Round Progression: If a proposer fails to get sufficient pre-votes or pre-commits, the protocol progresses to the next round with a new proposer until a block is committed.

And an overview of how Omni's architecture works:

1. XMsg & XBlock Generation: Users initiate transactions through an XDapp on source rollup VMs. These transactions are captured as XMsgs by the Portal Contract, which are then packaged by validators into XBlocks, specifically to be processed for cross-network communication.

2. Validator Consensus and XBlock Finalization: Once XMsgs are packaged into XBlocks, validators use the CometBFT consensus mechanism to agree and attest to the hashes of these XBlocks. Omni validators are responsible for verifying the authenticity of cross-rollup messages (XMsgs) and transactions on the Omni EVM. This process ensures that only verified and agreed-upon XBlocks are added to the Omni blockchain.

3. Relayer XBlock and XMsgs Submissions: Relayers monitor the Omni consensus layer to track finalized XBlocks. Upon detecting a block attested by the required majority (>66%) of validators, relayers are responsible for submitting these XMsgs to the corresponding destination rollups.

4. Destination Rollup: At the destination rollup VM, XMsgs are received and processed by the Portal Contract, which validates the data using the proofs and signatures provided by relayers. This ensures that messages are executed in the same state and order as they were sent from the source rollup.

5. Final XMsg Execution: Upon successful validation by receiving network’s Portal contract, the XMsgs are executed on the destination rollup VMs and an XReceipt is emitted, signaling the correct verification each submitted XMsg by the Portal contract.

   

In the recently published EIGEN: The Universal Intersubjective Work Token whitepaper, EigenLayer introduced three distinct methods on how faults can be attributed to the malicious party:

Objectively-Attributable Faults are faults that can be proven both mathematically and cryptographically, independent of subjective opinions. Examples include deterministic faults like execution validity, where anyone can verify if a node runs a piece of code on a distributed VM and checks whether the output is correct based on predefined rules.

• Example for Interoperability:

Cross-Chain Double-Signing & Cross-Chain MEV Extraction: If nodes sign two conflicting signatures when attesting to XMsgs validity in XBlocks—either maliciously or non-maliciously—it can be proven on-chain that the nodes have committed an on-chain attributable fault. This can occur in scenarios where validators attempt to manipulate the system (and thereby potentially benefit competitors) by simultaneously validating conflicting messages on different chains, leading to double-signing incidents. Additionally, validators may attempt to extract MEV by reordering, including, or excluding transactions in a way that benefits them financially at the expense of the network's integrity.

Intersubjectively-Attributable Faults require a broad-based consensus agreement among active observers of the system. For instance, verifying the accuracy of a price reported by an oracle depends on collective agreement, as it may not be immediately verifiable. Intersubjective staking involves achieving consensus among honest participants to confirm events that are not easily observable on-chain or occur off-chain.

• Example for Interoperability:

XMsg/XBlock Emission Censorship or Stalling: XMsgs or XBlocks could be withheld temporarily but then released, which might lead to disagreements on whether an attack occurred. To such subjective issues, Omni can specify a maximum allowable period for withholding, such as up to x seconds, to clearly define what constitutes an attack.

Non-Attributable Faults occur when only the victim is aware of the fault, preventing third parties from conclusively determining whether a fault has occurred or if there is malicious intent within the system or by an individual. For example, in a secret-sharing system where the secret is revealed only after a predetermined period, collusion among nodes may lead to premature disclosure of the secret, which could be undetectable without external knowledge.

• Example for Interoperability:

Validator Collusion: When a group of validators colludes to discreetly corrupt or approve incorrect XMsgs in XBlocks, the fault becomes non-attributable, as it is challenging for external observers to identify the responsible validators. This kind of collusion obscures fault origins, requiring sophisticated collusion-resistant solutions and enhanced decentralization.

In the context of intersubjective faults, assessing the profit from corrupting in an Interoperability service like Omni involves broad-based social consensus. Instead of straightforward slashing, malicious operators will see their stake forked, a process governed within the EIGEN ecosystem. This highlights the critical role of consensus-based approaches in managing and resolving disputes over intersubjective faults.

Furthermore and delving deeper into the relationship between interoperable rollup networking and intersubjective faults, it becomes clear that Liveness presents a greater risk likelihood than Safety. Therefore, consensus mechanisms and forking conditions must prioritize Liveness considerations when developing risk mitigation strategies and when modeling potential attack vectors for this type of AVS.

Cost of Corruption is defined as the cost enforced by the system on an attacker or group of colluding attackers to successfully carry out and compromise Omni Network's security.

This scenario occurs when validators holding more than one-third of the network's stake interfere with the smooth operation of the system. Such interference can result in delayed or non-production of XMsgs, impacting the network's ability to operate efficiently, which could be done to increase the opportunity costs associated with using a certain rollup, benefiting competing rollups.

This type of manipulation is classified as an Intersubjective-Attributable Fault—due to its off-chain and concurrently observable impact—where the malicious activity can include:

• XMsg Emission Censorship: Deliberately blocking or ignoring certain messages, thus manipulating their cross-rollup relaying, distorting the network's perception of effective inter-rollup communication.

• XMsg Emission Stalling: Intentionally slowing down the messaging verification and attestation processes, which can increase latency. This affects the timeliness and reliability of rollup communication, and may lead users to question the system’s effectiveness.

The other type of fault that also falls in the Liveness Violation category are the Non-Attributable Faults, which would be represented in this case by Validator Collusion. The main way to mitigate such a fault is through appropriate node decentralization (through DVT perhaps), and hence become more collusion resistant.

Dual Staking Scenario (Restaked ETH and OMNI Staking): With $1.5B of restaked Ether in the Omni AVS contract on EigenLayer and an additional $1.5B of OMNI staked, an attacker or group of attackers would need to acquire, at least, $500M worth of restaked ETH and $500M of staked OMNI, totalling $1B in required capital to corrupt the network. The dual staking mechanism effectively doubles the cost of corruption compared to the solo restaked ETH or solo native token staking scenarios.

This condition arises when validators control more than two-thirds of the network's stake, enabling them to manipulate the data validation process. Such a level of control can lead to the certification of false messages as correct, which is a direct threat to the integrity of the network.

This type of manipulation is classified as an Objectively-Attributable Fault—due to its deterministic validity and on-chain observable impact—where the malicious activity can include:

• Cross-Chain Double Signing: Engaging in the signing of conflicting blocks that contain messages, thereby creating ambiguity and mistrust regarding its true availability and integrity.

Dual Staking Scenario (Restaked ETH and OMNI Staking): With $1.5B of restaked Ether in the Omni AVS contract on EigenLayer and an additional $1.5B of OMNI staked, an attacker or group of attackers would need to acquire, at least, $1B worth of restaked ETH and $1B of staked OMNI, totaling $2B in required capital to corrupt the network. Effectively doubling the cost of corruption compared to the solo restaked ETH or solo native token staking scenarios.

• Anti-Sybil Mechanism: Mechanism used in the context of transactions submitted to the Omni EVM, to deter spam and malicious activities such as DoS attacks.

• Trusted Execution Environments (TEEs): Secure portions of hardware that generate and securely store validator keys and databases of previously signed data. By design, they enhance security without compromising scalability.

• Legal Consequences: Public entity validators not only incur considerable financial costs but also jeopardize their social standing and may encounter legal repercussions, when partaking in malicious actions.

The potential Profit from an attack can be calculated as:

Profit = Value of Transactions — Cost of Acquiring the Necessary Stake — Cost of Executing the Attack

For example, if an attacker incurs a $1B cost to garner $400 million worth of data, the direct financial outcome appears unprofitable. However, considering the indirect benefits like strategic dominance or long-term market manipulation may provide a broader context to justify such expenses, in a Interoperability scenario.

• Integration of Oracle/Bridge Solution: To restrict the potential PfC extracted from Omni, a bridge can be set-up to restrict the value flow within the period of slashing, or an oracle can have bounds on the total value transacted within a given period.

• Withdrawal Lock-Up Period: Lock-up period applied to Validators for security against corruption attacks.

• Associated Costs: This includes both the acquisition cost of the necessary stake and operational expenses related to the attack.

• Legal and Reputational Risks: Potential legal consequences and reputational damages can significantly deter these attacks.

By considering both intersubjectively- and objectively-attributable faults, stakeholders can better understand the varied nature of potential attacks on Omni and develop more effective defense mechanisms.

Illustrated is an hypothetical Liveness Violation scenario where the stalling or censoring of XMsg transactions disrupts transaction throughput and finality performances in the Omni network. Again, such a case should be resolved through a consensus agreement established around intersubjectivity in slashing penalties.

As there is limited available data on Omni's operations, the TPS and Finality values depicted in this visualization are assumed and intended to provide a conceptual understanding of the potential outcomes, rather than reflecting actual performance metrics.

At Epoch 10, an XMsg or XBlock stalling fault occurs, causing a significant drop in transaction throughput. This is visually represented by the node sizes and colors, indicating a undesirably high finality time, which is severely detrimental to the network. As the incident is resolved, transactions throughput gradually return to normalcy and continue to increase as the system matures and as Omni battle-tests itself and introduces new improvements to mitigate such faults.

As we wrap up this in-depth piece of Omni as AVS on EigenLayer, several pivotal questions remain about its long-term viability and operational efficiency:

1. Technological & Competitive Edge: Will Omni explore and securely implement TEEs, DVTs, fast-finality mechanisms like pre-confirmations or other valuable solutions to improve its product and front-run alternative interoperable solutions that will be built as AVSs?

2. Faults' Nature: How effectively will intersubjectively-attributable and non-attributable faults, especially in high-stakes scenarios involving high traffic, be managed? What kinds of scenarios should we monitor that may trigger these novel kinds of faults?

3. Operator Dynamics: What will be the criteria for selecting operators for Omni? Is there a risk of centralization, and how diverse or concentrated will the operator set be?

4. Attack Vectors: Are there more effective or damaging strategies for attacks beyond cross-chain double-signing and cross-chain MEX extraction? What other vulnerabilities could potentially be exploited?

5. Code Complexity: As an AVS, how complex will Omni's underlying code be, and what might this complexity mean for system robustness and bug susceptibility?

These inquiries are crucial for the community to consider as Omni becomes fully operational in the coming months. Tokensight will continue to monitor Omni's development and provide updates through further technical research. Follow us on X!