Contract & Execution Flow

Core Smart Contract Modules

LazAI’s Verified Computing system consists of the following core contract modules:

Contract	Responsibility
Verifier Contract	Core validator that receives proofs from the VSC and verifies TEE signatures, ZK proofs, or OP-based fraud evidence on-chain.
VSC Coordinator	Middleware that aggregates proofs from TEE nodes, including optional ZK/OP proofs, and submits them to the Verifier contract.
Challenger Registry	Maintains a list of Quorum-elected challenger nodes and tracks their activity, reputation, and rewards.
ExecutionRecord	Stores metadata of each computation task, including result hash and verification status.
Settlement Contract	Handles reward allocation and slashing based on verification results, impacting DAT ownership and value.

Verifier Contract Interface

interface IVerifier {

function submitTEEProof(

bytes calldata taskId,

bytes calldata resultHash,

bytes calldata teeSignature,

bytes calldata attestationReport

) external;

function submitZKProof(

bytes calldata taskId,

bytes calldata zkProof,

bytes calldata publicSignals

) external;

function submitFraudProof(

bytes calldata taskId,

bytes calldata evidence,

address challenger

) external;

function verifyResult(bytes calldata taskId) external view returns (bool valid);

}

Task Lifecycle Flow Diagram

Full Execution Lifecycle

This section outlines the step-by-step process for verifiable execution under each supported mode: TEE, TEE+ZK, and OP. Each flow ensures secure and auditable AI computation within the LazAI framework.

Step 1: Task Submission by iDAO

The iDAO initiates a computation task via an off-chain UI or dApp, sending it to the VSC for orchestration.

Submitted Fields:

• taskId: Unique hash for the task;

• dataRef: Dataset reference (e.g., IPFS, Arweave hash);

• modelId: The model or Agent identifier to execute;

• params: Inference or training parameters;

• verifyMode: Enum specifying TEE, TEE+ZK, or OP.

The VSC stores this metadata and assigns the task to eligible TEE nodes.

Step 2: Secure Execution Inside TEE

The assigned TEE Worker Node performs the task inside an isolated enclave:

In-Enclave Process:

1. Initialize environment using the specified dataset and model;

2. Run computation (e.g., forward pass, token prediction, classification);

3. Generate resultHash from the output;

4. Sign the result using TEE’s private key;

5. Attach remote attestation report.

Depending on verifyMode, the node additionally:

• Generates a ZK-SNARK proving the correctness of the computation without revealing input/output (for TEE+ZK mode);

• Prepares a Fraud-Proof-ready execution trace, hashed and stored off-chain (for OP mode).

Security Guarantees:

• Execution is isolated and tamper-resistant;

• Signed results are cryptographically bound to the specific TEE environment.

Step 3: VSC Aggregation and Proof Packaging

Once execution is complete, the VSC (Verifiable Service Coordinator) aggregates the following:

Data	Included When	Purpose
TEE Signature	Always	Confirms execution occurred inside TEE
ZK Proof	TEE+ZK only	Proves result validity without exposing data
OP Trace Hash	OP only	Enables later challenge by a third party
Execution Metadata	Always	Includes modelId, dataRoot, execution timestamp, etc.

The VSC then formats this package and submits it as a transaction to the Verifier Contract on LazChain.

Step 4: On-Chain Verification by Verifier Contract

The Verifier Contract receives the task package and performs the following steps:

TEE Mode

• Verifies the TEE signature using trusted attestation keys;

• Validates that resultHash and attestation correspond to the original request;

• Marks task as verified and stores the output hash on-chain.

TEE + ZK Mode

• Verifies the TEE signature as above;

• Executes on-chain ZK verifier to validate the ZK-SNARK proof;

• Records both resultHash and proofResult in ExecutionRecord.

OP Mode

• Stores the result and OP Trace Hash;

• Opens a challenge window (e.g., 12–24 blocks) for registered challengers to submit fraud claims;

• If no valid fraud proof is submitted within the window, the result is finalized as valid.

Step 5: Post-Verification Hooks

Once verification is complete:

• The ExecutionRecord module stores taskId, verification status, resultHash, and timestamp;

• The Settlement Contract:

  • Increases or adjusts DAT value for contributing iDAOs;

  • Releases access credits or rewards based on usage;

  • Optionally triggers stake updates or slashing (in case of OP fraud).

All results are publicly queryable and indexed on LazChain for audit, traceability, and downstream data monetization.

Module-to-Module Interaction Summary

Source	Target	Data Transmitted	Purpose
iDAO	VSC	taskId, modelId, dataId, verifyMode	Task configuration
TEE Node	VSC	resultHash, signature, attestation	Secure result
VSC	Verifier	Proofs and metadata	On-chain validation
Verifier	ExecutionRecord	Status and result hash	Task tracking
Verifier	Settlement	valid status, DAT info	Reward or slashing

Proving Dataset and Model Ownership

To establish clear and verifiable ownership of datasets and models within LazAI, the following protocol is implemented between iDAO users, Quorum nodes, and the LazChain infrastructure:

1. Initial Anchoring with TEE Attestation When a user (or iDAO member) first uploads a dataset or model to a Quorum, the selected TEE Worker Node performs a cryptographic attestation by:

   1. Computing the data hash (e.g., SHA256 of the dataset or model);

   2. Binding it to the uploader’s public key or LazChain address;

   3. Signing this tuple using the TEE’s private attestation key.

2. Ownership Registration via LazChain The Verifiable Service Coordinator (VSC) packages this attestation into a LazChain transaction, which includes:

   1. The data or model hash;

   2. The uploader’s public address;

   3. The TEE signature and timestamp.

   The Ownership Registry Contract stores this mapping, establishing an on-chain link between data hash and rightful owner.

3. Consensus-Based Verification and Transfer All future operations involving the dataset - whether validation, licensing, delegation, or ownership transfer - must be registered as consensus-approved transactions on LazChain. This ensures tamper-proof traceability and cryptographic auditability.

4. Ownership Query and Privacy-Preserving Claims To prove ownership, a user simply queries the on-chain registry for the binding between their address and the data hash. In cases where the user must prove specific dataset properties (e.g., contains 10,000 labeled entries, complies with regulatory filters) without revealing the raw data, a Quorum node may generate a Zero-Knowledge Proof (ZKP) certifying the claim, which can then be verified on-chain.

Computing node

• Users can indirectly query and use encrypted data through computing nodes, including fine-tuning and inference.

• Verify that nodes control accounts that can access the data through contracts.

• Joint data analysis allows users to securely process information across multiple iDAOs.