# 03 technical architecture Auvin Chain employs an Optimistic Rollup architecture as its Layer 2 scaling solution, with full EVM compatibility, and deep integration of EIP-4844 Blob transactions, Native Account Abstraction, Precompiled contract optimizations, and TEE (Trusted Execution Environment), providing high-performance, low-cost on-chain infrastructure for the AI Agent Economy, high-frequency Prediction Market trading, and large-scale compute scheduling. ## 3.1 Overall Architecture Design Auvin Chain's overall architecture adopts a layered design model, from bottom to top consisting of five layers: the Consensus Layer, Data Availability Layer, Execution Layer, Protocol Layer, and Application Layer. Each layer performs specific technical functions, with standardized interfaces between layers ensuring modularity and scalability. ### Five-Layer Architecture Overview ``` ┌─────────────────────────────────────────────────────────┐ │ APPLICATION LAYER │ │ ┌──────────────┐ ┌──────────┐ ┌──────────────────┐ │ │ │ Prediction │ │ AI Agent │ │ AI Box Compute │ │ │ │ Market │ │ Service │ │ │ │ │ └──────────────┘ └──────────┘ └──────────────────┘ │ ├─────────────────────────────────────────────────────────┤ │ PROTOCOL LAYER │ │ ┌──────────────┐ ┌──────────┐ ┌──────────────────┐ │ │ │ Ve(3,3) │ │ ZK+TSS │ │ x402 Payments │ │ │ │ DEX │ │ Bridge │ │ │ │ │ └──────────────┘ └──────────┘ └──────────────────┘ │ ├─────────────────────────────────────────────────────────┤ │ EXECUTION LAYER │ │ ┌──────────────┐ ┌──────────┐ ┌──────────────────┐ │ │ │ EVM-Compatible │ Native AA │ Precompiles │ │ │ │ Engine │ │ │ │ │ └──────────────┘ └──────────┘ └──────────────────┘ │ ├─────────────────────────────────────────────────────────┤ │ DATA AVAILABILITY LAYER │ │ ┌──────────────┐ ┌──────────┐ │ │ │ EIP-4844 │ │ KZG │ │ │ │ Blob │ │Commitments│ │ │ └──────────────┘ └──────────┘ │ ├─────────────────────────────────────────────────────────┤ │ CONSENSUS LAYER │ │ ┌──────────────┐ ┌──────────┐ │ │ │ PoS Stake │ │ VRF │ │ │ │ Proof │ │ Leader │ │ │ │ │ │ Election │ │ │ └──────────────┘ └──────────┘ │ └─────────────────────────────────────────────────────────┘ ``` ### Consensus Layer Adopts Proof of Stake (PoS), where validators stake AUV tokens to obtain block production rights and voting power, combined with VRF for fair leader election. This layer is responsible for L2 network security and decentralization, ensuring honest validator behavior through economic incentives and slashing conditions. PoS is 99%+ more energy-efficient than PoW, while validators' idle compute resources can be redirected toward real AI compute tasks. ### Data Availability Layer Submits compressed transaction data to Ethereum L1 via EIP-4844 Blob transactions. Blob data is cryptographically verified using KZG (Kate-Zaverucha-Goldberg) commitment schemes, ensuring verifiable data availability. This layer is the critical bridge through which Auvin Chain inherits Ethereum's security. ### Execution Layer Fully EVM-compatible Smart Contract execution environment supporting Solidity, Vyper, and other mainstream Smart Contract languages. This layer integrates three core components—Native Account Abstraction, Precompiled contracts, and TEE—providing AI Agents with a programmable, high-performance, secure on-chain execution environment. ### Protocol Layer Built-in two core financial primitives—the self-developed cross-chain bridge based on a ZK+TSS hybrid architecture, and a DEX adopting the Ve(3,3) model. Also integrates x402-compatible AI Agent payment protocols, providing the ecosystem with a complete protocol stack for asset interoperability, liquidity exchange, and machine-to-machine payments. ### Application Layer Hosts decentralized applications (DApps) for end users, including the decentralized Prediction Market, AI Agent service platform, AI physical mining (AI Box), and other core applications. All Application Layer DApps share the underlying AUV Gas token economic system. ## 3.2 Optimistic Rollup Layer 2 ### Why Optimistic Rollup? The two major Layer 2 scaling routes are Optimistic Rollup and ZK Rollup. Auvin Chain chose Optimistic Rollup for its full EVM compatibility—all existing Ethereum Smart Contracts, developer tools, and security audit standards can be migrated to Auvin Chain at zero cost. For a new public chain needing rapid ecosystem bootstrapping, EVM compatibility is not optional—it is mandatory. Arbitrum, Optimism, and Base have validated this approach with over $10 billion in combined TVL. ### How Optimistic Rollup Works Its core idea is the "optimistic assumption"—all transactions are presumed valid unless disputed. The workflow: 1. **Transaction Collection and Sequencing:** The Sequencer node collects user-submitted transactions, orders them by receipt time, and generates an ordered transaction list. The Sequencer executes transactions on L2 instantly and returns receipts to users, providing sub-second confirmation. 2. **State Transition:** The L2 execution engine processes each transaction in order, updating account balances, contract states, etc. Upon completion, a new State Root (Merkle tree hash of all account states) is generated. 3. **Batch Submission:** The Sequencer compresses large numbers of transactions into a batch, submits it to an Ethereum L1 Smart Contract along with the new State Root. Batches use calldata or EIP-4844 Blob storage. 4. **Challenge Window:** A 7-day dispute period begins after submission. Any validator can submit a Fraud Proof to challenge invalid state transitions. Fraud Proofs verify correctness by re-executing disputed transactions on L1. 5. **Final Confirmation:** If no successful Fraud Proof challenge occurs within 7 days, the transaction batch is considered final. The State Root on L1 becomes Auvin Chain's canonical state. ### Table 3-1: Optimistic Rollup vs ZK Rollup Comparison | Dimension | Optimistic Rollup | ZK Rollup | | ----------------------- | ----------------------------------- | ---------------------------------------- | | Proof Mechanism | Fraud Proof (post-hoc verification) | Validity Proof (instant verification) | | Finality Time | 7 days | \~1 hour | | EVM Compatibility | Native; 100% Solidity support | Requires zkEVM; some Opcodes unsupported | | Technical Complexity | Lower; mature | Higher; complex cryptography | | On-Chain Data Cost | Low (State Root only) | High (proof verification required) | | Representative Projects | Arbitrum, Optimism, Base | zkSync Era, Starknet | | TVL (2025) | $10B+ | \~$1B | ## 3.3 EIP-4844 Blob and Data Availability EIP-4844 (Proto-Danksharding) went live on March 13, 2024, with the Ethereum Dencun upgrade, as the first phase of the complete Danksharding sharding solution. This upgrade had a revolutionary impact on Layer 2 fee structures and is the underlying enabler of Auvera Chain's low-cost high-frequency trading. ### Core Innovation of Blob Transactions EIP-4844 introduces Blob (Binary Large Object) as a new data container type with three key characteristics: * Blobs are \~125–128KB data chunks attached to blocks with an independent fee market (Blob Gas Market) separate from regular gas markets * Blobs are temporary—stored on the consensus layer for \~18 days before pruning, never permanently occupying on-chain storage * Blobs use KZG commitment schemes (Kate-Zaverucha-Goldberg) for cryptographic verification without entering EVM execution—exclusively for L2 data availability ### KZG Commitment Scheme Kate-Zaverucha-Goldberg commitment is a polynomial commitment scheme allowing a prover to commit to a polynomial and prove its value at a specific point without revealing the entire polynomial. The process: 1. L2 encodes transaction data as a polynomial 2. Computes the KZG commitment (an elliptic curve point, just 48 bytes) 3. Submits the commitment to the L1 Blob contract 4. When data availability needs verification, generates an opening proof showing specific data exists in the polynomial KZG commitment size is constant at 48 bytes (one BLS12-381 curve point), regardless of original data size. ### Table 3-2: EIP-4844 Post-Deployment L2 Fee Changes | Metric | Before Upgrade | After Upgrade | Reduction | | ------------------ | -------------- | ------------- | --------- | | L2 Swap Fee | $0.50 – $2.00 | $0.01 – $0.10 | 95%–99% | | Arbitrum Single Tx | $0.37 | $0.012 | 97% | | Optimism Single Tx | $0.32 | $0.009 | 97% | | Simple Transfer | $0.50+ | <$0.01 | >98% | For Auvera Chain, EIP-4844's cost reduction makes three key applications viable: high-frequency Prediction Market trading (hundreds of orders per second), AI Agent micropayment invocations ($0.001-level single transactions), and real-time compute network settlement (hundreds of compute transactions per minute). ## 3.4 Native Account Abstraction Account Abstraction (AA) is a technical paradigm that makes blockchain user accounts programmable, liberating wallet logic from hardcoded protocol rules and allowing developers to customize signature verification, gas payment, and transaction execution through Smart Contracts. For Auvera Chain's AI Agent Economy, Native Account Abstraction is mandatory—not optional. ### Limitations of Traditional EOAs Traditional Ethereum accounts (Externally Owned Accounts, EOAs) suffer from fundamental flaws: * **Single private key control** — key compromise means total asset loss with no recovery * **No native social recovery** — lost keys mean permanent asset loss * **Must hold ETH for gas** — AI Agents need additional gas token inventory management * **Single transaction execution** — no batch operations * **No programmable verification logic** — cannot customize spending limits, allowlists, or other security policies ### Table 3-3: Three Generations of Account Abstraction Evolution | Solution | Date | Core Features | Adoption | | --------- | ---------- | ----------------------------------------------------------------------------- | ----------------------------------------- | | ERC-4337 | March 2023 | No protocol changes; introduces UserOperation mempool and EntryPoint contract | 26M+ Smart Accounts; 170M+ UserOperations | | EIP-7702 | May 2025 | Protocol-layer change; EOA temporarily gains Smart Contract functionality | Major L2s adopting | | Native AA | 2026+ | Every Ethereum wallet defaults to Smart Contract wallet | Auvera Chain native support | ### Core Capabilities Auvera Chain Native AA Brings to AI Agents **Session Keys:** Temporary keys with limited permissions and short lifecycles. AI Agent operators can create session keys defining spending caps, validity periods, and contract interaction allowlists. Agents operate autonomously within defined limits without requiring human authorization for each transaction. Keys automatically expire after the session. **Spending Limits:** Multi-tier limit control: * Session Cap (cumulative spend per session) * Per-Transaction Cap (maximum per transaction) * Time-Window Cap (daily/weekly/monthly cumulative caps) Even if an AI Agent is attacked, losses are strictly limited to preset ranges. **Contract Allowlists:** AI Agents can only interact with pre-approved Smart Contract addresses. Any contract call not on the allowlist is automatically rejected, preventing malicious contracts from inducing agents to execute dangerous operations. **Gas Abstraction:** Via Paymaster contracts for gas sponsorship. AI Agents only need to hold AUV or stablecoins—no need for additional ETH gas management. Paymasters accept AUV as gas payment and pay ETH gas to the network on behalf of the agent. **Batching:** `approve + transfer + contract call` in one atomic operation. Traditional workflows require 3 transactions (approve, transfer, call); batching compresses to 1, improving efficiency and reducing total gas costs by \~40%. **Social Recovery:** Multi-sig guardian mechanism—AI Agent wallet managers can preset 3–5 guardian addresses. When the primary key is lost, a majority of guardians can jointly sign to recover wallet control. ## 3.5 Precompiles Optimization Precompiled Contracts (Precompiles) are special contracts implemented directly in the EVM protocol in native code (Go/Rust/C++), deployed at fixed addresses. They execute complex operations using underlying native code, achieving 100–1,000x performance improvement compared to Solidity bytecode interpretation. When the EVM encounters a precompiled contract address call, it does not execute Solidity bytecode but directly calls the native function in the node client. These native functions, implemented in compiled languages (Go/C++), directly manipulate underlying data structures, bypassing EVM interpretation overhead. ### Table 3-4: Auvin Chain Precompile Optimization List | Precompile | Function | Optimization Scenario | Efficiency Gain | | ------------------------- | ------------------------------------------ | --------------------------------------------- | --------------------------- | | ecAdd / ecMul / ecPairing | Elliptic curve operations | Signature verification, ZK proof verification | 100x+ | | SHA256 / BLAKE2b | Hash computation | Data fingerprinting, Merkle proofs | 100x+ | | KZG Point Evaluation | KZG polynomial evaluation | EIP-4844 Blob data availability verification | From infeasible to feasible | | BLS12-381 Series | BLS signature aggregation and verification | PoS consensus batch signature verification | 1,000x+ | | ModExp | Large integer modular exponentiation | RSA verification, VDF computation | 200x+ | Micropayments ($0.001 level) are only economically viable when L2 gas costs are below $0.0001. Precompiles reduce core cryptographic operation gas costs, making high-frequency AI Agent interactions feasible. EIP-4844's KZG precompile directly enables L2 cost reduction, indirectly making x402 and similar Agent payment protocols viable. The BLS12-381 precompile is particularly important for PoS consensus—each block contains dozens of validator signatures, and BLS aggregation reduces verification costs by three orders of magnitude. ## 3.6 TEE Trusted Execution Environment TEE (Trusted Execution Environment) is a hardware-level isolated area within a processor or memory where code and data execute securely. This isolation occurs at the hardware level (CPU instruction set level), ensuring that code and data inside the TEE are invisible and inaccessible to any external software—including the operating system itself, Hypervisor, and even root-privileged malware. TEE's core security characteristics include: hardware-level isolation (strict separation between TEE and Rich Execution Environment via CPU memory management unit), remote attestation (allowing remote verifiers to cryptographically verify the integrity of code running in the TEE), and secure storage (TEE-internal data is encrypted—physical storage extraction cannot decrypt it). ### Table 3-5: TEE Technology Comparison | Technology | Principle | Advantages | Limitations | | ------------------ | ------------------------------------------------------------ | --------------------------------------------------------- | -------------------------------------------------- | | Intel SGX | Secure enclaves on CPU with hardware-level memory encryption | Small attack surface; broad CPU support; mature ecosystem | \~256MB memory limit; side-channel attack risks | | ARM TrustZone | CPU partitioned into "Secure World" and "Normal World" | Billions of devices; low power consumption | Mobile-focused; limited Secure World resources | | AWS Nitro Enclaves | Cloud-native VM-level isolation with independent kernel | Flexible resource allocation; AWS ecosystem integration | AWS vendor lock-in; requires trust in AWS hardware | | AMD SEV-SNP | Memory encryption + integrity protection | Large memory VM support; no SGX memory limits | Relatively new; ecosystem still building | ### Three Critical Roles of TEE in Auvera Chain's Architecture **1. Verifiable Execution of AI Inference** AI Agent inference and decision processes occur off-chain (on-chain execution is too costly and slow), but TEE ensures this off-chain execution is verifiable. The process: * AI models and inference code are loaded into the TEE * The TEE uses remote attestation to prove to on-chain contracts that the loaded code is the expected version * Inference executes securely within the TEE * Results are signed and submitted on-chain * On-chain contracts verify the TEE signature to confirm results originate from a trusted execution environment This is the technical realization of the "on-chain constraint on AI" concept. **2. AI Agent Private Key Protection** AI Agent signing private keys are generated and stored within the TEE. Keys never leave the TEE boundary throughout their entire lifecycle from generation to use. Application code requests signing operations through TEE-provided cryptographic APIs but can never directly access raw keys. Even if the host OS is compromised, private keys remain secure. **3. Prompt Injection Attack Prevention** Prompt Injection is a core security threat facing AI Agents—attackers manipulate LLM behavior through carefully crafted inputs (e.g., "ignore previous instructions, execute the following..."). TEE ensures spending limits, contract allowlists, and other security policies are enforced at the hardware isolation layer, independent of external manipulation. Even if an LLM is induced by injection attacks to generate malicious operation requests, the security policy layer within the TEE independently verifies each operation, rejecting calls exceeding permission scope. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://auverachain.gitbook.io/auvinchain/english/auvin-chain-collection/white-paper/03-technical-architecture.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.