SessionQueueValidation: TaskRoot & SessionRoot for ERC-8004 Compatibility (Draft)
Status: Conceptual Design Phase
Related Modules: SessionQueue, Validator, QuantitativeStats, QualitativeStats
Reference: https://x.com/cortensor/status/1974765387339473150
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
Prototype canonical hashing schema
(taskID, minerID, modelID, inputHash, outputHash, metadata)for Merkle generation.Integrate ValidationRequest / ValidationResponse into Cortensor’s PoI loop.
Map SessionID / ValidatorID to ERC-8004 Identity Registry for agent reputation linkage.
Simulate rolling SessionRoot updates and test replay validation.
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 RegistryFlow 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.
Last updated