How do Verifier Nodes Work

This document is based on the design for alphanet. The mainnet will be similar, but please check this page for any new updates. (06/18/2024)

Overview

CARV Smart Contract Design

The overall architecture is divided into four modules: veCARV, License NFT, Protocol Service, and Vault. With the exception of the Protocol Service module, each module corresponds to a single smart contract. The Protocol Service module, however, comprises multiple smart contracts (proxy contract, logic contract, settings contract, etc.). The CARV Token contract is not detailed in the architecture diagram as it only implements the basic ERC20 standard.

• Vault Contract: This contract manages the assets for the entire Carv protocol. It operates under four roles: foundation, tee staking pool, veCARV reward pool, and NFT pool. Each role can only manage its designated funds through specific methods. Additionally, the Vault contract defines the reward release curve to regulate reward fund operations.

• veCARV Contract: This contract facilitates the exchange between CARV and veCARV tokens. Exchanged CARV tokens are stored within the veCARV contract. When users make a claim, half of the CARV tokens that have not met the lock-in period are directed to the foundation address within the Vault.

• NFT Contract: This contract oversees the purchase and redemption of NFTs by users. The ETH from NFT purchases is stored in the NFT account within the Vault. Upon redemption, 80% of the ETH is returned to the user (with the remaining 20% serving as a channel fee) or exchanged for an equivalent amount of CARV, which is then linearly released back to the user. The exchange of ETH for CARV is managed by the foundation, completed by the Vault contract, and based on Chainlink exchange rates.

• Protocol Service Contract: This contract handles the majority of the business logic and includes several components:

  1. Permission Management: admin, tee

  2. System Parameter Management: Managed through the settings contract

  3. Tee-related Operations: stake, unstake, slash

  4. Verifier-related Operations: enter, exit, report active, slash

  5. Delegation Operations: delegate, redelegate, undelegate

  6. Report Operations: attestation, verification

Verifier Nodes Workflow

1. Upon completing data processing, TEE nodes submit the data verification, AI model training result and the TEE attestation to smart contracts on the execution layer.

2. The smart contracts employ a Verifiable Random Function (VRF) to randomly choose a subset of verifiers for attestation validation.

   In cryptography, a verifiable random function (VRF) is a random number generator (RNG) that generates an output that can be cryptographically verified as random. Verifiable randomness is essential to many blockchain applications because its tamper-proof unpredictability enables exciting gameplay, rare NFTs, and unbiased outcomes. As the name suggests, a verifiable random function is defined by its core features: Verifiable, Random, Function.

3. Verifiers monitor events from the smart contract to initiate the verification process.

4. Verifiers assess the authenticity of the attestation. For more details, please check SGX Attestation Verification

5. Based on the outcome, verifiers relay their findings to the smart contract:

   • If the attestation is invalid, the smart contract penalizes the responsible TEE node by slashing its stake, which is then allocated to the verifiers as additional rewards.

6. When the attestation is confirmed as valid with over 50% of designated Verifiers, the smart contract distributes not only the consumers' fees but also on-chain rewards among the TEE nodes, verifiers, and data providers.