1. Abstract

2. Breakdown

   2.1 Data Workflow

   2.2 Consensus Architecture

3. EIGEN Fault Types for eOracle

   3.1 Objectively Attributable Faults

   3.2 Intersubjectively Attributable Faults

   3.3 Non-Attributable Faults

4. Corruption Scenarios for eOracle

   4.1 Corruption Analysis with Pooled Security

   4.1.1 Liveness Tolerance Violation (>1/3 Stake Attack)

   4.1.2 Safety Tolerance Violation (>2/3 Stake Attack)

   4.1.3 Factors to Consider When Estimating Cost of Corruption & Profit from Corruption

   4.2 Corruption Analysis in an Intersubjective Staking World with Attributable Security

   4.2.1 Cryptoeconomic Security

   4.2.2 Strong Cryptoeconomic Security

5. eOracle: CoC vs. PfC Scenarios Under Different Slashing Types

6. Conclusion

The present article by Tokensight has been written to provide a technical overview of eOracle, as an oracle AVS on EigenLayer. In this piece, we’ll explore its data workflow and consensus architectures, types of objective and intersubjective faults, and potential corruption scenarios that may occur along those faults.

eOracle is a decentralized oracle solution that securely delivers external data to blockchain networks. It sets a new security standard for oracle technology by leveraging a dual staking system: restaked ETH via EigenLayer for objective-fault security, and eOracle's native token staking for intersubjective-fault security (TBD, yet to be launched). This dual quorum model ensures robust cryptoeconomic security, with protection anchored in both restaked ETH and eOracle’s native token. It is an outstanding question whether EIGEN will also be used for intersubjective slashing within eOracle's system and its specific utility function if so.

The protocol's business model focuses on two main user segments: Data Users (DApps, chains, or entities requiring on-chain external data) and Custom Oracle Builders (developers or companies creating unique oracles on eOracle's infrastructure).

By building on EigenLayer, eOracle benefits from:

• Bootstrapping: eOracle leverages EigenLayer to instantly access a large independent pool of Ethereum node operators, solving the critical challenge of bootstrapping a trustless system, offering customers a robust, decentralized oracle service from day one.

• Unparalleled Security: The protocol benefits from the security of restaked ETH, providing robust cryptoeconomic guarantees comparable to other top networks, which minimizes the risk of oracle failure.

• Capital Efficiency: EigenLayer’s shared security model significantly lowers operational costs, allowing eOracle to offer high-quality, secure oracle services at a much lower cost to both data users and oracle builders.

Overviewing eOracle’s data processing workflow:

• Data Sourcing: eOracle operators connect to APIs or WebSockets, fetching real-time data from publicly accessible sources. The data type and frequency of reporting are defined programmatically by the user or application.

• Data Signing: Operators cryptographically sign the fetched data with their private key to ensure its integrity and authenticity.

• Transaction Submission: The signed data is submitted as a transaction to the EO-chain, with gas fees paid in native tokens or ETH. The transaction includes data, signature, and operator identity.

• Identity Verification: Upon receiving the transaction, an eOracle node verifies the operator’s signature using public key cryptography to authenticate the report.

• Data Aggregation: Verified data is aggregated on the EO-chain using various schemes, ranging from statistical averages to more sophisticated methods such as Byzantine fault-tolerant aggregation to filter out malicious reports.

• Data Publication on Target Blockchains: Aggregated data, once validated, is published on target blockchains with a Merkle tree structure, allowing users to verify data using a Merkle proof.

eOracle operates an independent PoS blockchain called the EO-chain, powered by EigenLayer operators and using the eBFT consensus mechanism, which ensures transparent, immutable data settlement and aggregation through on-chain verification, while offloading computation from target chains.

Now diving in in detail:

• Operator Stake Validation: Follows a stake-weighted approach: the influence of an operator is proportional to their staked value, ensuring that those with larger stakes have a stronger say in the final outcome.

• Permissionless Validation: Any node can validate data reports, aiming therefore for decentralization and censorship resistance by preventing a single authority from blocking or altering data.

• Consensus Formation via eBFT: The eBFT mechanism ensures that more than two-thirds of validators must agree on the final aggregated data before it’s confirmed for accuracy and network liveness.

• Immediate Block Finality: Operators propose blocks with immediate finality, avoiding forks and reorgs, which enhances efficiency and fault tolerance, making data confirmation quick and reliable.

• Cryptographic BLS Signatures: The aggregated result is cryptographically secured by BLS threshold signatures, allowing multiple validator signatures to be combined into one, ensuring data integrity while optimizing network performance.

• Slashing and Reward Mechanism: Honest validators are rewarded, while those submitting malicious or inaccurate data face slashing penalties on their restaked ETH or native tokens, encouraging consistent integrity in the network.

On the EIGEN: The Universal Intersubjective Work Token whitepaper, EigenLayer introduced three distinct ways how faults can be attributed to a malicious party:

Objectively-Attributable Faults 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 if the output is correct based on predefined rules.

• Fault examples for Oracles:

Data Corruption & Signing Issues (Double-Signing & Wrongful Block Signing): Data could be manipulated via the Data Validators' reporting, potentially profiting from subsequent user malfunctions; also if nodes sign two conflicting signatures—either maliciously or non-maliciously—, then it can be proven on-chain that the nodes have committed an on-chain attributable fault.

Intersubjectively-Attributable Faults require a broad-based consensus agreement among active observers of the system. For example, 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 or occur off-chain.

• Fault examples for Oracles:

Sybil & Data Stalling: Fake identities can be spun up by adversaries which may not be clearly/immediately verifiable onchain, creating a need for consensus from onlookers. Data could be halted on the oracle's reporting stage, which may lead to disagreements on whether an attack occurred. To mitigate data-withholding issues, contracts can specify a maximum allowable period for withholding data, such as up to 1 day, to clearly define what constitutes an attack.

Favourable and concrete incentives and infrastructure that facilitate light nodes to join and monitor the network these kinds of intersubjective faults would also be strongly advised. Light nodes will play a important role in observing, inputting, and assisting on consensus-reaching toward these intersubjective matters, and therefore, ultimately, be useful in fostering intersubjective cohesion and mitigating intersubjective fracture.

As per EigenLayer's whitepaper:

"To make the faults intersubjectively attributable, the AVS may need to focus on developing robust monitoring infrastructure including light clients. This can lower the cost-of-monitoring, ensuring that there will be a wide net of community members from EIGEN’s social consensus who will be operating the AVS’s light node software for monitoring the EigenLayer operators that have opted into the AVS."

"Intersubjective cohesion. An important requirement for social consensus to be able to resolve intersubjective faults for potentially verifiable digital tasks is that all honest members of social consensus should be in cohesion about what the correct fork of bEIGEN after an intersubjective challenge is triggered."

"Intersubjective fracture. If an AVS doesn’t carefully design its light node architecture for users to utilize when resolving intersubjective faults, it presents the risk of a fracture in the social consensus."

Learn more on Tokensight’s deep-dive post dedicated to Intersubjective Fracture and Cohesion within the EIGEN token.

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.

• Fault examples for Oracles:

Validator & Third-Party Providers Collusion: When a group of validators colludes to discreetly approve incorrect data validations, 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.

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 eOracle's security. Profit from Corruption comprises the net value the same attacker or group of attackers is able to extract after performing the attack.

In a standard pooled security context for a single AVS the below holds true:

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

Social consensus mechanisms and forking conditions must consider both Liveness and Safety when developing risk mitigation strategies and modeling potential attack vectors for this type of AVS, in preparation for EigenLayer’s Slashing release.

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 data availability attestations, impacting the network's ability to operate efficiently. This type of manipulation is classified as an Intersubjectively Attributable Fault—due to its off-chain and concurrently observable impact—where the malicious activity can include:

• Data Censorship: Deliberately blocking or ignoring certain transactions, thus manipulating the visibility and processing of data. This selective interference can distort the network's perception of data availability.

• Data Stalling: Intentionally slowing down the data verification and attestation processes. This action can increase latency, affecting the timeliness and reliability of data availability, and may lead users to question the system’s effectiveness.

Dual Staking Scenario (Restaked ETH and Native Token Staking): With $1.5B of restaked Ether in the eOracle AVS contract on EigenLayer and an additional $1.5B of native token staked, an attacker or group of attackers would need to acquire, at least, $500M worth of restaked ETH and $500M of staked native token, 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 data 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:

• Data Corruption: The process of certifying incorrect or compromised data as valid and available, which can deceive the network and its users into relying on false information.

• Double-Signing: Engaging in the signing of conflicting data attestations, thereby creating ambiguity and mistrust regarding the true availability and integrity of data.

Dual Staking Scenario (Restaked ETH and Native Token Staking): With $1.5B of restaked ETH in the eOracle AVS contract on EigenLayer and an additional $1.5B of native token staked, an attacker or group of attackers would need to acquire, at least, $1B worth of restaked ETH and $1B of staked native token, 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.

The potential Profit from an attack can be calculated as:

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

• although being somewhat of a subjective variable, the manipulation of financial outcomes, based on corrupted data, could potentially be exploited for financial leverage, in an indirectly monetary or even non-monetary way.

For example, if an attacker incurs a $2B cost to garner $500 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 an oracle scenario.

Factors to Consider To Increase Cost of Corruption

• Transport Layer Security (TLS/zkTLS): TLS secures data exchanges between validators by encrypting communications and authenticating participants, therefore raising the difficulty and cost for attackers seeking to corrupt the network.

• Zero-Knowledge Proofs: A few types of zk proofs could be implemented for eOracle’s benefit in the fields of data privacy, particularly, increasing its security profile further when faced with an attack.

• Trusted Execution Environments (TEE): 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.

• Distributed Validator Technology (DVT): Incentivizes client diversity through the distribution of the validation process across multiple operators, reducing the risk of a single chokepoint in case of failure/corruption. Constitutes a deterrent for a malicious attacker to proceed or makes it significantly more resource-intensive to forge.

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

Some of the above, are being actively researched by the eOracle team.

Factors to Consider When Estimating and Reducing Profit from Corruption

• Integration of Oracle/Bridge Solution: To restrict the potential PfC extracted from eOracle, an oracle or bridge solution 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 toward eOracle and develop more effective defense mechanisms.

Cryptoeconomic Security: "For any attacker, the maximal profit extractable from attacking the safety (profit-from-corruption) is smaller than the minimum cost enforced by the system on the attacker (cost-of-corruption).", as per the EigenLayer whitepaper.

However, there's a fundamental problem: the profit-from-corruption is non-measurable (or almost impossible to measure). The adversary may have perverse incentives outside the system’s scope of measurement. Moreover, this notion does not guarantee that the user actually gets compensated for the value that they lost in the case the attack happened in fact. We must therefore define a more robust notion of cryptoeconomic safety.

Strong Cryptoeconomic Security: "Any user should be compensated a pre-specified amount in the event that the safety guarantee to the user is violated.", as per EigenLayer whitepaper.

This security threshold is accomplished if the Redistributable Stake obtained by the AVS is greater than the Harm from Corruption. The equation is fully measurable onchain:

• Redistributable Stake is the amount of stake that is uniquely attributable to the affected AVS for the fault, it allows to self-specify how much security they want;

• Harm from Corruption can be estimated by attempting to simulate scenarios where funds can be extracted, like censorship within the proof period for Brevis, with confidence intervals, time-series scenario analysis, and Value-at-Risk concepts in mind, once AVS payments and attributable security are fully functional (very much central to Tokensight's ethos).

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

The chart illustrates the balance between the Cost of Corruption (CoC) and the Profit from Corruption (PfC), based on the Cryptoeconomic Security section of eOracle’s documentation, emphasizing the AVS’s cryptoeconomic security across three scenarios.

• The dark blue bars represent CoC: Restaked ETH Slashing, showing the penalties for misbehavior through ETH stake slashing.

• The light blue bars represent Native Token Stake Slashing, which adds additional slashing penalties for malicious actors, at the AVS level.

CoC remains constant across all scenarios illustrated, representing the economic deterrent to corrupt the oracle system and profiting from it.

The PfC variables show the potential profit attackers can gain:

• The dark green bars represent Profit from Manipulation (PfM), where internal profit is gained from corrupting data (e.g., price updates).

• The light green bars show Profit from Depreciation (PfD), or external profit from short selling the protocol’s token post-attack.

The scenarios illustrate varying short-selling interest levels, with the high PfM & high shorting scenario exceeding the CoC, indicating greater profit potential for attackers.

The CES (Cryptoeconomic Security) margin, the difference between CoC and PfC, determines whether the protocol is secure or vulnerable. In the low and medium scenarios, CoC outweighs PfC, keeping the system secure. However, in the high PfM & high shorting scenario, the attacker’s potential profit surpasses the CoC, making the system vulnerable. This highlights the need for strong CoC and appropriate slashing mechanisms, especially when the market is prone to short selling pressures due to periods of high interest, ensuring eOracle remains secure and resilient against external and internal threats.

A more refined definition for CES focuses on attack deterrence and effort to execute an attack by a) making it operationally difficult and risky through slashing penalties so it’s not attempted, and b) requiring high coordination and budgeting efforts to carry it out successfully.

Visit eOracle’s detailed and comprehensive section on CES at:

Cryptoeconomic Security | eOracle

While traditional oracles rely on their proprietary tokens to maintain ecosystem health and secure operations, eOracle introduces a novel security approach with its dual-token design. The model synergizes the specific advantages of a protocol-dedicated token with the enhanced security and economic stability provided by a well-established token like ETH, used for staking purposes.

https://docs.eoracle.io

A swath of multi-agent simulations based on actual data and more precise risk parameters will be central to understand the risks computed through various stress scenario analysis for Oracles. Tokensight plans to do much more in this topic going forward.

As covered in the Breakdown section, with this AVS on EigenLayer, developers can now leverage a decentralized and secure Oracle framework, tap into restaked ETH for enhanced cryptoeconomic security, and build custom oracle solutions with reduced operational costs, all while benefiting from EigenLayer’s shared security model and the high scalability of eOracle.

To wrap up this in-depth piece of eOracle, some important considerations remain about its long-term viability and operational efficiency:

1. Technological & Competitive Edge: Will eOracle explore and securely implement TEEs, TLS, light node infrastructure or other valuable solutions to improve its product and front-run alternative solutions that will be built as AVSs?

2. Faults' Natures: 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 eOracle? Is there a centralization risk, and how diverse or entrenched will the operator set be?

4. Attack Vectors: Are there more effective or damaging strategies for attacks, even against such a robust zero-knowledge architecture? What other vulnerabilities could potentially be exploited?

5. Code Complexity: As an AVS, how complex will eOracle underlying code be, and what might this complexity mean for system robustness and bug susceptibility? How well defined will the parameters of slashing intersubjective be (helpful in mitigating code complexity through excessive slashing rules for objective faults)?

These inquiries are central for the community to consider as eOracle becomes fully operational in the coming months. Tokensight will continue to monitor eOracle's development and provide updates through further technical research.

Follow us on X at @tokensightxyz!