- About Multi-Prover AVS
- Directory Structure
- AVS Task Description
- AVS Architecture
- AVS Workflow
- TEE Committee and Quorum
- Quick Start
The Automata Multi-Prover AVS target to build a robust, fortified prover system through the use of diverse, decentralized TEE committees.
Read this blog to understand more about the Multi-Prover AVS.
├── contracts: Solidity contracts, including the AVS contracts and the attestation layer contracts. │ ├── dcap-v3-attestation: On-chain verification library for Dcap attestation of Intel SGX. │ ├── src: Source files for AVS contracts. │ └── test: Tests for smart contracts. ├── operator: The operator implementation. ├── aggregator: The aggregator implementation. ├── sgx-prover: the sgx version of TEE prover.
Task definition: A state transition or computational process seeking to leverage the independent execution within a Trusted Execution Environment (TEE) to ascertain its correctness.
struct StateHeader {
uint256 identifier;
bytes metadata;
bytes state;
}This is the structure of the state header submitted ty provers, below is the detailed explaination:
- identifier: identifier of the handled task, it can be used to distinguish different kinds of tasks and used to calculator the contribution of each operators
- metadata: metadata that describe the specific task, for example
keccak256(abi.encodePacked(chainID, blockNumber))is the metadata for the task to prove blockchain state at specific block height - state: the final state produced by the TEE prover, it can be either a root state of blockchain, or statement proved by a zk circuit
The architecture of the AVS contains:
- Eigenlayer core contracts
- AVS contracts
- ServiceManager which allow operators to submit tasks, reward and slash logic will be added in the future
- Attestation contracts
- Manage the register/deregister and livenness of various TEE provers, it will verify attestation of different TEE platforms such as Intel SGX, AMD SEV, ARM TrustZone and so on
- TEEProverRegister is the interface for the attestation layer used by the operators and aggregator
- Aggregator
- Aggregate the BLS signatures from operators and submit the aggregated state to AVS
- Interact with the Automata attestation layer to check the validity of each prover(operator), those who failed to pass the attestation verification or liveness challenge will be rejected to handle tasks until they are valid again.
- Operator
- Fetch state proofs from TEE prover and submit it to the aggregator
- TEE prover
- TEE prover that prove the final state of a given task, for example, a prover of zk-rollup L2 will execute blocks inside TEE and produce the root state at specific block
Below is a detailed diagram of the workflow
sequenceDiagram
autonumber
participant O as Operator
participant A as Aggregator
participant EC as Eigenlayer Contracts
participant M as Multi-prover AVS
participant L as TEE Liveness Contract
participant AC as Attestation Contracts
Note over O,L: Operator registration
O->>EC: Restake and register to Multi-prover AVS
O->>L: Operator Liveness
Note over O,AC: Operator Liveness (Periodically)
loop Every liveness cycle
O->>O: Generate Attestation Report
O->>L: Submit Attesatation Report with pubkey(submitLivenessProof)
L->>+AC: Verify Attestation Report(verifyAttestation)
AC->>AC: Verify MrEncalve and MrSigner
AC->>AC: Verify QE Report
AC->>AC: Verify Quote CertChain
AC->>AC: Verify TCB
AC-->>-L: Return reportData(pubkey)
L->>L: Mark the operator(pubkey) as attested within the liveness cycle
end
Note over O,L: Proving state
O-->>O: Fetch task and calculate inside TEE
O->>A: Provide state and signature(submitTask)
A-->>EC: Fetch pubkey by OperaterId
A->>L: Fetch operator's validity (verifyLivenessProof)
L-->>A: Operator's validity
alt Is Valid TEE Prover
A-->>A: Wait and aggregate signatures
A->>M: Submit state and aggregated signatures
else Not Valid TEE Prover
A-->>O: Reject
end
Components:
The workflow is divided into two parts:
- Setup
- Follow the Eigenlayer's doc to stake and register as operator of Multi-prover AVS
- Generate attestation and register as TEE prover, attestation and its generating process differs depending on the TEE technology. For example, dcap-v3-attestation is the contracts of verifying Dcap attestation of Intel SGX
- Working
- Except what operators should do to handle tasks, they must complete liveness challenge periodically, otherwise they will be treated as invalid and their submission will be rejected by the aggregator
- Operators fetch new task and finish the calculation inside TEE
- Operators sign the final state and send it together with signature to aggregator
- Aggregator will fetch operator's validity before accepting its submission
- Aggregator aggregate all the BLS signature and submit to the AVS service manager
TEE Committee is a set of quorum that is responsible to handle a specific type of task. For example, proving the root state of Zk-Rollup at a particular block height. Operators do not need to actively choose a committee, but automatically belong to a committee by joining quorums. The introduction of TEE Committee facilitates a more organized structuring of operators and tasks. And lays the groundwork for future enhancements, including the rewarding mechanism and constraints of stake distribution across quorums.
The concept of a TEE Quorum aligns with the quorum definition utilized by Eigenlayer, but each quorum is associated with a TEE platform, such as Intel SGX. Each quorum belongs to a committee, operators can choose to join any quorum, But only the votes from operators possessing the requisite attestation will be accepted by the aggregator.
| Name | Proxy |
|---|---|
| MultiProverServiceManager | 0x4665Af665df5703445645D243f0FD63eD3b9D132 |
| RegistryCoordinator | 0x62c715575cE3Ad7C5a43aA325b881c70564f2215 |
| StakeRegistry | 0x5C7BbAfA3d5A3Fa0b592cDCF4b7B52261FaA99A8 |
| BlsApkRegistry | 0x2b6C2584760eDbcEC42391862f97dBB872b5e2Eb |
| IndexRegistry | 0x158583f023ca440e79F199f037aa8b53b198F500 |
| OperatorStateRetriever | 0xbfd43ac0a19c843e44491c3207ea13914818E214 |
| TEELivenessVerifier | 0x2E8628F6000Ef85dea615af6Da4Fd6dF4fD149e6 |
| AutomataDcapV3Attestation | 0x5669FE82711052e1A0EE16eafCDAb49ffe02ab14 |
Please visit the Operator setup repository if you are interested in joining the Multi-Prover AVS on Holesky testnet. The onboarding guide is available here.
| Name | Proxy |
|---|---|
| MultiProverServiceManager | 0xE5445838C475A2980e6a88054ff1514230b83aEb |
| RegistryCoordinator | 0x414696E4F7f06273973E89bfD3499e8666D63Bd4 |
| StakeRegistry | 0x4A4EC1631aE79699be7dCFD3fCA395Ab89c5eFe9 |
| BlsApkRegistry | 0x61D25c9b943b893747Bd33F92B62Ec8270222e6F |
| IndexRegistry | 0x16552d7863560Ee6903F092A901A9124a5013085 |
| OperatorStateRetriever | 0x91246253d3Bff9Ae19065A90dC3AB6e09EefD2B6 |
| TEELivenessVerifier | 0x8E26055388347A2f4A7a112A7210CcC88A1c2F30 |
| AutomataDcapV3Attestation | 0xA65a18a7f8Bb621017Ec0481B7eFe37a006EbD93 |
The Multi-Prover AVS will launch on mainnet soon, please be patient!
go build -o out/operator ./cmd/operator
go build -o out/aggregator ./cmd/aggregator