# SessionQueueValidation: TaskRoot & SessionRoot for ERC-8004 Compatibility (Draft) **Status:** Conceptual Design Phase\ **Related Modules:** `SessionQueue`, `Validator`, `QuantitativeStats`, `QualitativeStats`\ **Reference:** *** ### **Overview** The **SessionQueueValidation** module is being extended to introduce **TaskRoot** and **SessionRoot** structures — a cryptographic framework for tracking verifiable task completion and continuous session evolution.\ This design aims to make Cortensor’s **inference validation** interoperable with **ERC-8004’s Validation Registry**, enabling standardized proof exchange across agent and compute networks. Cortensor sessions are continuous and open-ended.\ Each **task** executed within a session becomes an **atomic proof unit**, while the session itself evolves as a **rolling ledger of trust**. *** ### **Conceptual Design** #### **TaskRoot (Sealed Proof)** * Each task request within a session is executed by multiple miners. * Their outputs are hashed, verified, and aggregated into a **Merkle root (TaskRoot)** that cryptographically commits to all miner results for that task. * Once sealed, a TaskRoot serves as an immutable proof artifact — representing one verifiable checkpoint of inference. **Purpose:**\ Provides tamper-evident validation for a single task execution.\ Used by validators for replay verification (e.g., **Proof of Inference (PoI)** or **Proof of Useful Work (PoUW)**). *** #### **SessionRoot (Rolling Ledger)** * As each TaskRoot is sealed, it is appended to a **rolling Merkle accumulator** called the **SessionRoot**. * The SessionRoot evolves as new tasks are completed, forming a cumulative state that represents all verified tasks under one session. * This enables perpetual sessions without closure after each task, maintaining continuity for long-lived agent or application processes. **Purpose:**\ Maintains a verifiable, cumulative record of all TaskRoots under a given session.\ Acts as a **living commitment** to the full session history. *** ### **Proposed ERC-8004 Mapping** The design aligns Cortensor’s validation structure with **ERC-8004’s trust fabric**, allowing Cortensor sessions to function as verifiable agent servers under the ERC-8004 model. | **ERC-8004 Field** | **Cortensor Equivalent** | **Description** | | ------------------ | ------------------------ | ------------------------------------------------------------------------------------------------------------------------ | | `AgentServerID` | `SessionID` | Represents the aggregated “agent server.” Abstracts miner identities internally but exposes a unified external identity. | | `AgentValidatorID` | `Validator / Oracle` | Executes PoI / PoUW checks and records ValidationResponse events to the ERC-8004 Validation Registry. | | `DataHash` | `TaskRoot / SessionRoot` | Cryptographic commitment referencing either a single verified task or the cumulative session state. | **Key Relationship:** * **TaskRoot** → atomic proof of a single inference. * **SessionRoot** → rolling ledger of all inferences under a session.\ Together, these structures enable **cross-network trust interoperability** — allowing Cortensor proofs to be read, verified, or referenced by external ERC-8004 registries. *** ### **Internal Data Model** Each **TaskRoot** is derived from a canonical hashing schema that records the full provenance of a task: ``` (taskID, minerID, modelID, inputHash, outputHash, metadata) ``` **Fields:** * **taskID:** Unique identifier of the inference task. * **minerID:** Node(s) performing the work. * **modelID:** Model or architecture used for inference. * **inputHash:** Cryptographic hash of the input (prompt, configuration). * **outputHash:** Hash of the generated output tensor or result. * **metadata:** Optional contextual data (timestamps, environment info, scoring). Merkle leaves are constructed from this structure.\ The resulting **TaskRoot** becomes a deterministic commitment to all miner outputs, verifiable by validators or external auditors. *** ### **Validator Interaction** #### **1. ValidationRequest** Validators initiate verification using a `DataHash` (TaskRoot or SessionRoot) to request validation of a given inference. #### **2. Verification Process** Validators perform: * **Proof of Inference (PoI):** embedding-distance checks for result consistency. * **Proof of Useful Work (PoUW):** LLM-based evaluations of result quality and utility. #### **3. ValidationResponse** Upon completion, validators submit **ValidationResponse** entries into the **ERC-8004 Validation Registry**, anchoring Cortensor proofs on a common trust layer for transparent, interoperable validation. *** ### **Why It Matters** * **Reproducibility:** Every inference becomes a sealed, replayable proof unit. * **Continuity:** SessionRoot preserves long-running, evolving workloads. * **Interoperability:** Bridges Cortensor’s decentralized validation with ERC-8004’s standardized trust registries. * **Transparency:** Enables external audits, proof replay, and cross-network reputation scoring. Together, **TaskRoot** and **SessionRoot** form a unified framework for **verifiable, evolving, and auditable inference**, anchoring decentralized AI execution in a shared validation ecosystem. *** ### **Next Steps** 1. Prototype canonical hashing schema `(taskID, minerID, modelID, inputHash, outputHash, metadata)` for Merkle generation. 2. Integrate **ValidationRequest / ValidationResponse** into Cortensor’s PoI loop. 3. Map **SessionID / ValidatorID** to ERC-8004 Identity Registry for agent reputation linkage. 4. Simulate **rolling SessionRoot updates** and test replay validation. 5. Benchmark **multi-validator performance and gas costs** for potential cross-chain anchoring. *** ### **Architecture Flow** ``` ┌───────────────────────────────┐ │ Task Execution (Miners) │ └──────────────┬────────────────┘ │ ▼ Hash inputs/outputs → Build Merkle leaves │ ▼ TaskRoot (sealed proof per task) │ ▼ SessionRoot (rolling ledger of all TaskRoots) │ ▼ Validator performs PoI / PoUW verification │ ▼ ValidationResponse → ERC-8004 Validation Registry ``` **Flow Summary:**\ Each task produces a **TaskRoot** as a sealed proof.\ The **SessionRoot** continuously aggregates all TaskRoots, forming a rolling ledger of trust.\ Validators then verify and anchor these proofs into **ERC-8004’s on-chain Validation Registry**, connecting Cortensor’s decentralized execution fabric with the emerging agent trust fabric. --- # 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.cortensor.network/technical-architecture/designs-wip/wip-agentic/sessionqueuevalidation-taskroot-and-sessionroot-for-erc-8004-compatibility-draft.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.