Skip to main content
ParalleliX Docs

// Section 5.1 · Protocol

Proof-of-Execution

2 min5.1Protocol
// 1 of 5 · the proof model

The binding layer. Not the validation layer.

// 5.1 · proof-of-execution · sha-256 hash commitment

PoE binds a result to a request and a node. It does not prove the computation was honest. That part is the redundancy mechanism in §5.5. The two are designed to compose: PoE makes results attributable; sampled re-dispatch makes them honest. Together they cover what a real zero-knowledge proof would cover in one primitive, at a cost the network can afford at launch. The live unit of work is a whole ParalleliX AI inference request, served end to end by one node; the same commitment applies to a segmented sub-task on the general parallelizable-workload path.

// poe · hash commitment · v1
PoE = SHA-256(request_id || result || node_id)
// REQUEST_IDRequest bindingAllocated by the coordinator at intake. Unique per request.
// RESULTResult bindingThe bytes the node returned for this request.
// NODE_IDActor bindingSHA-256 of the node's RSA public key. Derived, not assigned.

What it proves. What it does not.

// the design boundary, stated explicitly

// PROVES

Specific node returned a specific result for a specific request

Reconstruct SHA-256(request_id, result, node_id) at the coordinator. Compare to the value the node submitted. Mismatch rejects the result outright. The binding is unforgeable: an attacker would need to find a SHA-256 preimage collision for the exact (request_id, result, node_id) triple.

// DOES NOT PROVE

The computation was performed honestly

A node can return a fabricated result and a matching PoE. The commitment binds the fabrication to the actor, but does not catch it. Honesty enforcement is the sampled re-dispatch mechanism in §5.5: a fraction of requests runs on a second node; the commitments are compared; disagreement triggers escalation.

Reference implementation

// pseudocode · not a stable API

// node-side · python pseudocode
def proof_of_execution(request_id: bytes, result: bytes, node_id: bytes) -> bytes:
    """Compute the PoE commitment for a completed request."""
    return sha256(request_id + result + node_id).digest()

# Node returns to coordinator:
#   {
#     "request_id": "req_a3f1",
#     "result":     <bytes>,
#     "poe":        <hex>,           # SHA-256 commitment
#     "sig":        <rsa_sign(result || poe)>
#   }
// coordinator-side · verification
def verify_poe(returned: RequestReturn) -> bool:
    expected = sha256(returned.request_id + returned.result + returned.node_id).digest()
    return expected == returned.poe and rsa_verify(
        node_pubkey(returned.node_id),
        returned.result + returned.poe,
        returned.sig,
    )

PoE v1 vs real zero-knowledge

// why this is the right primitive at launch

Real ZK collapses binding and honesty into one primitive. The proof-generation cost makes it a research direction, not part of the launch scope. The honest tradeoff:

// PROPERTY// POE V1// REAL ZK
Cryptographic primitive
SHA-256 over (request_id, result, node_id)
zk-SNARK / zk-STARK over program trace
Proves result-to-request binding
Yes
Yes
Proves honest computation
No (needs redundancy)
Yes (directly)
Verifier cost
One hash · microseconds
Proof verification · ms to seconds
Prover cost
Negligible · one hash
Heavy · often >> execution time
Detects fabricated outputs
Only with sampled re-dispatch
Every time
Detects algorithm modification
Only with sampled re-dispatch
Every time
Build status
Available at launch
Research direction

Real ZK is not deployed because proof-generation cost for general-purpose compute (especially GPU workloads with floating-point arithmetic) remains orders of magnitude above the useful work. Ongoing research tracks the zkVM and proving-system literature and migrates when the economics flip.

READING PATHforward links
The Proof ModelParent hub for §5.1 through §5.5.
Threat ModelHow redundancy compensates for the missing honesty proof.
Scale ModelReal zero-knowledge proofs are a research direction, not yet built.