1. Abstract

2. Brevis Breakdown

3. Brevis coChain Architectural Workflow

4. Brevis coChain Consensus Architecture

5. EIGEN Fault Types for Brevis coChain

   5.1 Objectively Attributable Faults

   5.2 Intersubjectively Attributable Faults

   5.3 Non-Attributable Faults

6. Corruption Scenarios

   6.1 Corruption Analysis with Pooled Security

   6.1.1 Safety vs. Liveness

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

   6.2 Corruption Analysis in a Intersubjectively Staking World with Attributable Security

   6.2.1 Cryptoeconomic Security

   6.2.2 Strong Cryptoeconomic Security

7. Brevis coChain Scenario Analysis

8. Conclusion

The present article by Tokensight has been written to provide a technical overview of Brevis coChain, as a ZK Coprocessor AVS on EigenLayer. In this piece, we’ll explore its consensus architecture, some potential objective and intersubjective corruption scenarios, and its innovative approach at scaling onchain querying through off-chain ZK computations, powered by restaked security.

Brevis is a smart ZK Coprocessor for blockchains that empowers dApps with powerful, trustless computation through access, compute, and verification of onchain data. dApps' smart contracts can access full historical on-chain data, run computations on ZK-verified data, and generate ZK proofs for the results. These results, along with the proofs, are then submitted onchain for verification and utilization by smart contracts on supported blockchains, assisting such intensive data-driven DApps.

However at scale, Brevis may likely run into challenges with high proof generation costs and limited scalability due to ZK computational overhead, resulting in delays and suboptimal user experiences.

Along with the advent of restaking and EigenLayer, the Brevis coChain AVS was spun up by the Brevis team to address some of these challenges by using advanced ZK cryptographic algorithms and large-scale parallel computing to process complex computations on thousands of transactions in minutes. Supported by restaking and EigenLayer, this enhanced architecture offers greater security and cost efficiency by ensuring fast and trustless access to historical blockchain data and support for arbitrary cross-chain computation, facilitating the scalable development of its dApp clients.

Brief overview of how it works:

1. Data Access (zkFabric): Smart contracts, through Brevis's APIs, can trustlessly access the full historical on-chain data, such as states, transactions, and events, from Ethereum and other chains.

2. Computation (zkQueryNet): Developers then can build and deploy their customized business logic without any prior knowledge of ZK using Brevis's SDK. Brevis runs the computation and generates an off-chain ZK proof for the results.

3. Result Verification (zkAggregatorRollup): The computation results, along with the ZK proof, are submitted back on-chain for application smart contracts to seamlessly verify and consume.

Now expanding on how the architecture workflow works:

1. Data Request: Smart contracts initiate a request for specific blockchain data using the Brevis SDK. This request is directed to the Brevis infrastructure, indicating the required historical data and the type of computation to be performed.

2. Data Synchronization: Relayers synchronize block headers from various connected blockchains and submit these headers to the zkFabric module. This ensures that the most recent and relevant blockchain data is available for processing.

3. Proof Generation: The zkFabric module processes the submitted block headers and generates ZK Consensus Proofs. These proofs validate the correctness and integrity of the block headers and their underlying data, ensuring they can be trusted for further computations.

4. Query Processing: Then zkQueryNet receives data queries from dApps. It processes these queries using the attested block headers from zkFabric and generates ZK Query Proofs. This step involves executing the specified business logic and computations on the historical blockchain data. In essence, it handles data queries and produces ZK proofs.

5. Proof Verification: At last, the zkAggregatorRollup module collects the proofs generated by zkFabric and zkQueryNet and verifies these proofs to ensure their validity and correctness. Upon successful verification, zkAggregatorRollup updates its storage with the validated data and proofs, ensuring the availability of reliable data for applications.

6. Result Utilization: Applications retrieve the verified data from zkAggregatorRollup. The verified results are then used by smart contracts and other dApps, ensuring they operate with trustworthy and accurate data.

Brevis derives its cryptoeconomic security from restaked ETH via EigenLayer (Proof-of-Stake) in an objective-fault context, and from EIGEN staking in an intersubjective-fault context. As of now, it's only safe to suggest that Brevis coChain is pursuing a "Pure Wallet" business model (the most secure one for newborn protocols) where no native AVS token is involved, and user fees are paid in a purely neutral denomination (like ETH). Assumption prone to be faulty.

In a pure zero-knowledge system like Brevis, consensus is achieved internally through the generation of ZK Consensus Proofs at the zkFabric Prover Network stage:

• The zkFabric's Prover Network ensures the generation of ZK Consensus Proofs is entirely trustless, eliminating the need for any external validation entity. Its security and consensus are fully and solely derived from the underlying blockchains and the mathematically-sound proofs outputted by the network.

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

Note: There is theoretically no safety risk within Brevis post-proof generation, since the zero-knowledge, cryptographic proofs would not be able to be wrongfully generated in the first place in a pure ZK system like Brevis is built to be. The objective fault example below is taken in a pre-proof generation context, to illustrate the potential fault that may occur in such scenario.

These kinds of faults 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 ZK Coprocessing:

• Double-Signing: If validators sign two conflicting block headers for the same sequence or wrongfully sign headers they should not; they can be detected and proven onchain. Ensures validators are directly held accountable through slashing for outright maliciously or non-maliciously manipulation.

Faults that require broad-based consensus 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 or occur off-chain.

In the context of intersubjective faults, assessing the harm from corruption in a protocol like Brevis involves broad-based social consensus. Instead of straightforward slashing, malicious operators will see their stake forked, a process governed by the social consensus within the EIGEN ecosystem. The role of consensus-based approaches in managing and resolving disputes over intersubjective faults is critical.

An interesting use case where intersubjective faults for disputes toward Brevis can be implemented is:

• On the database level: Writing fraud proofs or validity proofs for various execution environments can be complex in general. As a result, using intersubjective slashing can serve as an intermediate step before slashing contracts for the AVS can be rigidly built.

Fault examples for ZK Coprocessing:

• Network Latency through Proof Censorship, Sybil Attacks, Merkle Tree Synchronization Issues, zkSNARK/zkSTARK Frail Setup: If a validator/validators causes delays in communication and consensus by censoring proofs, network throughput/finality may be affected; perform sybil attacks involving creating multiple fake identities to manipulate network processes and disrupt consensus; inconsistencies in data ingestion or digestion during preprocessing or indexing impacting validity of proofs and queries; inconsistent Merkle tree states across nodes can lead to discrepancies in data validation and proof generation, compromising system’s accuracy; the integrity of the SNARK/STARK setup with regards to its randomness and parameter generations can be agreed upon by consensus (could also be considered non-attributable fault under different contexts).

  By setting a maximum allowable period for withholding (e.g., a few seconds), implementation of anti-sybil mechanisms, continuous data and state validation checks, Brevis coChain can define clear criteria for what constitutes a fault, enabling consensus on these subjective matters.

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

Faults that 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 example for ZK Coprocessing:

• Validator Collusion: When a group of validators colludes to discreetly approve incorrect transactions or blocks, it becomes challenging for external observers to pinpoint the responsible validators. This makes the fault non-attributable, necessitating advanced collusion-resistant measures and increased decentralization to mitigate such risks. Again, light-node infrastructure will be important to potentially mitigate this risk.

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 Brevis coChain'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:

Looking deeper into the relationship between ZK Coprocessing architecture and the different kinds of possible faults, it becomes clear that Liveness presents a greater risk likelihood than Safety for Brevis. Therefore, intersubjective slashing penalties should be carefully considered and prioritized when developing risk mitigation strategies and when modelling these attack vectors.

Ensuring the correctness and low latency of cryptographic proofs is crucial to maintaining trust and reliability in this type of AVS. As addressed, Brevis being a pure-ZK system enables itself to be extremely airtight against safety faults, since a given proof will not be generated if a signing or coordination error were to happen. Therefore, focusing on mechanisms to guarantee liveness should be prioritized for Brevis.

In Brevis' Network, provers commit to generating proofs within a given time period and collateralize the commitment with restaked capital. The failure to generate a proof on time results on a penalty in the form of slashing or non-payment, which incentivizes operators to perform as promised, resulting in liveness guarantees.

• Fully Homomorphic Encryption (FHE): Enables computations on encrypted data without needing to decrypt it, ensuring the results remain encrypted and only accessible with the appropriate key. In this context, FHE can offer significant benefits, such as allowing operators to order and process transactions and generate proofs without ever seeing the actual data, ensuring complete privacy. It would also ensure that proofs are generated securely without revealing the underlying data.

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

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

• Integration of Oracle/Bridge Solution: To restrict the potential PfC extracted from Brevis, 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 Provers 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 Brevis 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 stronger 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 visualization below provides a hypothetical scenario analysis on the effects of the horizontal scaling of nodes and the heavier SQL data requests on the processing times of cryptographic proofs and queries in Brevis' parallel ZK coprocessor.

Note: The values and their measures are intended to be illustrative only, offering an approximation of the phenomena at hand.

Horizontal scaling of nodes is achieved through EigenLayer's pool of restaked operators and Brevis zkFabric Prover Network through MapReduce, native to Brevis.

The coloured lines show Query Response Times for growing sets of nodes, which naturally decrease as the number of nodes increases — although slightly upward sloped every time —, due to the growing data size being processed. This reduction in query response times occurs due to both factors that compose the effective horizontal scaling of nodes. Particularly highlighting the benefits of Brevis MapReduce's parallel processing in improving query response timing efficiency.

The white dashed line representing Proof Generation Time performs a slight, logarithmic downward trajectory, assuming node scaling increases and data ingestion sizes also increase. Starting at smaller data sizes and decreasing logarithmically aligns with the expected timing efficiency gains in proof generation from increased node participation and hyper-data parallelization — as the workload is distributed more effectively.

Proof generation and query response times clearly improve with horizontal node scaling, even though data size expands along with it. The varying rates of increase in response times for different node counts illustrate the advantages of restaking shared security and hyper-parallel data processing. The visualization helps underscore the system's scalability and efficiency, showcasing the positive tradeoffs that come from Brevis' ZK Coprocessor.

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

As stressed in the Breakdown section, with this AVS on EigenLayer, developers can now build non-privacy intrusive, data-driven dApps (in the marketing realm of user acquisition, for instance), ZK bridges, and ZK identity solutions that operate at a significantly lower cost when compared to a pure zero-knowledge model without a restaked cryptoeconomic security model.

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

1. Technological & Competitive Edge: Will Brevis explore and securely implement TEEs, DVTs, 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 Brevis? Is there a centralization risk, and how diverse or concentrated 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 Brevis' 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 Brevis becomes fully operational in the coming months. Tokensight will continue to monitor Brevis' development and provide updates through further technical research.

Follow us on X at @tokensightxyz!

• Brevis Docs: https://docs.brevis.network/

• Brevis Blog: https://blog.brevis.network/

• RISC ZERO, A Guide to ZK Coprocessors for Scalability: https://www.risczero.com/blog/a-guide-to-zk-coprocessors-for-scalability

• EIGEN: The Universal Intersubjective Work Token whitepaper & EigenLayer: The Restaking Collective: https://docs.eigenlayer.xyz/eigenlayer/overview/whitepaper

• STAKESURE: Proof of Stake Mechanisms with Strong Cryptoeconomic Safety: https://arxiv.org/abs/2401.05797

• Vitalik Buterin, An approximate introduction to how zk-SNARKs are possible: https://vitalik.eth.limo/general/2021/01/26/snarks.html

• Vitalik Buterin, An Incomplete Guide to Rollups: https://vitalik.eth.limo/general/2021/01/05/rollup.html

• Infinite Layers (Youtube): Infinite Layers featuring Brevis - the Smart ZK Coprocessor for Blockchains