# Verified Computing Architecture

### Core Components

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

### 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

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

### Security Guarantees

<table data-header-hidden><thead><tr><th width="169.5859375"></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Layer</strong></td><td><strong>Protection</strong></td><td><strong>Mechanism</strong></td></tr><tr><td>Execution Trust</td><td>Code and data cannot be tampered with during runtime</td><td>Hardware TEE isolation, remote attestation</td></tr><tr><td>Verifiable Output</td><td>Outputs are provably derived from claimed inputs</td><td>ZK-SNARK or OP Fraud-Proof</td></tr><tr><td>Data Privacy</td><td>Data processed inside secure enclaves, not exposed on-chain</td><td>TEE memory isolation, encryption</td></tr><tr><td>Dispute Resolution</td><td>Any party can challenge invalid results</td><td>On-chain challenger registry with incentives</td></tr></tbody></table>

### 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.


---

# 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://docs.lazai.network/verified-computing-framework/verified-computing-architecture.md?ask=<question>
```

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.