# 07 consensus Auvin Chain employs Proof of Stake (PoS) consensus, where validators stake AUV tokens to participate in block production and network security. PoS combines VRF-based fair leader election with economic incentives and slashing conditions to ensure network security while being 99%+ more energy-efficient than PoW. ## 7.1 Proof of Stake Consensus Proof of Stake (PoS) is a consensus mechanism that achieves network agreement through economic staking rather than energy consumption. In PoS, validators obtain the right to produce blocks and validate transactions by locking (staking) a certain amount of tokens. A validator's voting weight is proportional to their staked token amount, but block production rights are allocated through cryptographic random functions to prevent large stakers from monopolizing. As an Optimistic Rollup Layer 2, Auvin Chain's PoS consensus operates at the L2 level, inheriting Ethereum L1's PoS security as ultimate guarantee. L2 PoS validators are responsible for: transaction sequencing and block production, state transition execution, fraud proof verification (during the dispute window), and L1 batch submission signature authorization. This dual-layer security model—L2 PoS for efficient consensus, L1 PoS for finality—provides optimal balance between security and performance. **Staking Mechanism:** Validators must stake a minimum amount of AUV tokens to become active validators. Process: validators send AUV tokens to the Staking Contract where they are locked; validators run full node software and register with the network; after an activation delay (\~1–2 epochs), validators gain block production eligibility; staked tokens are non-transferable during staking, but validators continuously earn block rewards and transaction fees. ``` +---------------------------------------------------------------+ | Auvera Chain PoS Consensus Economic Cycle | +---------------------------------------------------------------+ | | | +------------------+ | | | User stakes AUV | | | +--------+---------+ | | | | | v | | +------------------+ +----------------------+ | | | Enters validator | | VRF random election | | | | set +---> | (Is selected?) | | | +------------------+ +----------+-----------+ | | | | | +------------+------------+ | | | Yes | No | | v v | | +------------------+ +------------------+ | | | Block production | | Participates in | | | | right | | attestation | | | +--------+---------+ +--------+---------+ | | | | | | v v | | +------------------+ +------------------+ | | | Produces block + | | Validates block + | | | | collects fees | | signs | | | +--------+---------+ +--------+---------+ | | | | | | v v | | +------------------+ +------------------+ | | | Earns block | | Earns attestation| | | | rewards | | rewards | | | +--------+---------+ +--------+---------+ | | | | | | +-----------+-------------+ | | | | | v | | +------------------+ | | | Compounds stake | | | +--------+---------+ | | | | | +-----------> (Cycles back | | to staking) | +---------------------------------------------------------------+ ``` *Figure 7-1:* Auvin *Chain PoS Consensus Economic Cycle* ## 7.2 Validators and Block Production **Validator Set:** Auvin Chain's validator set is dynamic. Any node meeting minimum staking requirements can join or exit. Management is automatic via the Staking Contract: * **Join:** New validators submit stake → enter activation queue → wait for current epoch end → formally join at next epoch start * **Exit:** Validators initiate exit request → enter exit queue → wait unbonding period (7–14 days) → staked tokens returned The unbonding period prevents validators from withdrawing stake immediately after misbehavior to evade slashing. **Block Production Process:** At each epoch (\~12 seconds): 1. VRF randomly selects one validator as block proposer 2. The proposer collects mempool transactions, sorts by gas price and receipt time 3. Executes transactions, updates state, generates new block 4. Broadcasts block to network, other validators independently verify validity 5. Validators sign and broadcast attestations after confirming validity 6. When 2/3+ validators attest, the block is finalized 7. If a proposer misbehaves, other validators reject the block and initiate fraud proof ## 7.3 VRF and Leader Election VRF (Verifiable Random Function) plays a core role in Auvera Chain's PoS consensus, generating unpredictable random numbers for each epoch to fairly select block proposers. VRF combines asymmetric cryptographic signatures with hash function characteristics. Each validator holds a VRF keypair (public key registered on-chain, private key kept locally). At each epoch start, validators use their private key to compute VRF on the epoch number and random seed, producing a random number and a proof. The validator with the lowest random number (or falling within a specific range) is selected as the current epoch's block proposer. The proof enables public verification that the random number was correctly generated by that validator's private key. VRF's three key properties ensure consensus fairness: | Property | Description | | -------------------- | ------------------------------------------------------------------------------------ | | **Verifiability** | Anyone can verify VRF output correctness using the validator's public key and proof | | **Unpredictability** | The output cannot be predicted before generation because it requires the private key | | **Unmanipulability** | No validator can manipulate VRF output to favor themselves | ## 7.4 Slashing Conditions and Economic Security PoS security relies on economic game theory—the value of a validator's staked tokens must exceed potential gains from misbehavior. Auvin Chain designs strict slashing conditions: | Condition | Description | Penalty | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------- | | **Double Signing** | A validator submits two different blocks or signatures at the same height. The most serious offense—can cause chain forks, destroying consensus consistency. | 100% of staked tokens are slashed | | **Surround Vote** | A validator votes on conflicting block heights. | Slashing proportion 50%–100% depending on severity | | **Extended Downtime** | A validator fails to participate in voting across consecutive epochs. | Penalty starts with reward deduction (not principal); exceeding the threshold triggers forced exit | | **Invalid Block Proposal** | A proposer proposes a block containing invalid transactions. Other validators reject the block. | Proposer loses that block's rewards; multiple invalid proposals may trigger additional penalties | **Economic Security Boundary:** An attacker needs to control >1/3 of staked tokens to prevent block finalization, and >2/3 to successfully execute a double signing attack. When total staked value is sufficiently large and token distribution is sufficiently decentralized, attack costs far exceed potential gains. ## 7.5 Useful Work and Compute Repurposing Auvera Chain's PoS consensus integrates deeply with the AI compute network. Validator nodes repurposing idle compute resources toward real AI compute tasks while participating in consensus achieves "network security + compute services" dual-value output. **Compute Repurposing Architecture:** Validator nodes are typically high-performance servers with enterprise-grade GPUs. These resources are idle: * \~99% of the time (only one validator produces blocks per epoch) * During non-attestation periods * During network low-traffic periods Auvin Chain's compute scheduling system redirects this idle capacity to the AI compute task pool. **Task Scheduling:** Validator nodes run dual-mode software—**Consensus Mode** and **Compute Mode**. | Mode | Description | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Compute Mode** | When not the current epoch's proposer, nodes automatically switch to Compute Mode, obtaining pending AI tasks from Auvin's compute pool; executing under TEE protection to ensure data privacy and result integrity; submitting results to the pool and earning additional AUV compute rewards. | | **Consensus Mode** | When VRF selects the validator as the next proposer, the node switches back to Consensus Mode, pausing compute tasks to ensure timely consensus participation. | ### Table 7-2: PoS vs PoW Comparison | Dimension | PoW (Bitcoin) | PoS (Auvera Chain) | | --------------------------- | ------------------------------------------- | ----------------------------------------------------- | | **Core Resource** | CPU/GPU compute (SHA-256 hashing) | Economic stake guarantee | | **Energy Consumption** | Extreme (\~150 TWh/year) | Minimal (99%+ less than PoW) | | **Block Right Allocation** | Hash rate competition; mining pool monopoly | VRF random election; fair stake-weighted distribution | | **Misbehavior Cost** | Energy waste; high economic cost | Staked tokens slashed; direct economic loss | | **Participation Threshold** | High (requires ASIC mining rigs) | Medium (requires AUV stake + node operation) | | **Environmental Impact** | High carbon emissions | Low energy; idle compute repurposed for AI | | **Finality Speed** | 60 minutes (6 confirmations) | \~12s per epoch; finalized at 2/3 attestation | --- # 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/07-consensus.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.