🏗️Verified Computing Architecture

Core Components

Component	Description
TEE Worker Nodes	Secure computation nodes running AI tasks (e.g., preprocessing, training, inference) within a trusted enclave, signing all outputs.
iDAO	Submits datasets and models, configures agent execution logic, and selects the validation mode (TEE, TEE+ZK, or TEE+OP).
VSC (Verifiable Service Coordinator)	Coordinates proof submission, batches TEE attestations and optional ZK/OP proofs, and submits them to LazChain.
Verifier Contract	Smart contract on LazChain that verifies TEE attestations, ZK or OP proofs, and anchors the result hashes on-chain.
Challenger Registry	Quorum-elected members who monitor verification results, issue fraud claims, and trigger slashing when violations occur.

Execution Lifecycle Flow

Step 1: iDAO Task Submission

An iDAO submits a task definition, including:

• Data references (IPFS, Arweave, etc.);

• Target model or Agent ID;

• Expected output type and optional constraints;

• Selected verification method: TEE, TEE+ZK, or OP.

Step 2: Secure Execution in TEE

A TEE Worker Node picks up the task;

• Inside a hardware-enforced enclave, it performs:

  • Data loading and pre-checks;

  • Model or Agent execution;

  • Output generation and hashing;

  • Signing the result with the TEE’s private key;

If selected, the node may also:

• Generate a ZK Proof for the output computation;

• Generate a Fraud Proof-Ready Trace for OP-based setups.

Step 3: Submitting Proofs to LazChain

VSC aggregates all relevant data:

• TEE Signature (for execution authenticity);

• Optional ZK-SNARK (for result verifiability);

• Optional OP Trace Hash (for fraud challenge preparation);

• Metadata such as model ID, data Merkle root, execution timestamp;

• These are submitted as a transaction to the Verifier Contract on LazChain.

Step 4: On-Chain Verification

The Verifier Contract:

• Checks TEE signature validity using known attestation keys;

• Verifies optional ZK or OP proofs;

• Anchors result hash and validation status for downstream logic (e.g., DAT reward, access log, or revenue claim);

• Emits event logs for traceability.

Step 5: Dispute and Challenger Mechanism

Challengers (Quorum validators) continuously monitor on-chain proof submissions;

• If a suspicious or invalid computation is detected, they can:

  • Pull the result + metadata + optional trace;

  • Recompute the output locally or verify it against OP/Fraud-Proof references;

  • Submit a FraudProof;

Once validated, the system executes a slashing procedure:

• iDAO penalty: burning of stake or reduction of DAT value;

• Challenger reward: incentive for honest verification.

Optional Verification Modes Explained

Mode	When to Use	Advantages	Overhead
TEE Only	Trusted agents in performance-critical use cases; fast, low gas	Hardware-based trust, ultra-low gas	Needs TEE-compatible hardware
TEE + ZK	Highly sensitive data, regulatory audits, or public agent use	Public verifiability, cryptographic guarantees	Medium gas cost, higher latency
OP	For open models with fast finality and community arbitration	Transparent fraud resolution, no ZK setup	Requires fraud monitoring and challenge periods

Security Guarantees

Layer	Protection	Mechanism
Execution Trust	Code and data cannot be tampered with during runtime	Hardware TEE isolation, remote attestation
Verifiable Output	Outputs are provably derived from claimed inputs	ZK-SNARK or OP Fraud-Proof
Data Privacy	Data processed inside secure enclaves, not exposed on-chain	TEE memory isolation, encryption
Dispute Resolution	Any party can challenge invalid results	On-chain challenger registry with incentives

Integration with Consensus and Reward Mechanism

• All proofs submitted via VSC are included in blocks through the Quorum-Based BFT consensus;

• iDAO stakes, DAT updates, and model access rights are governed by verified task results;

• Fraud proofs or confirmed proofs serve as inputs to reward allocation, slashing, and token distribution via Verifier and Settlement Contracts.