Skip to main content
ParalleliX Docs

// Chapter 05 · Protocol

The Proof Model

How strangers transact compute without a third party they both trust.

7 min5 sectionsProtocol

Four primitives, one guarantee

// 5.0 · what each binds, what each does not

Four cryptographic primitives carry the weight. None of them is novel. What matters is how they compose: each primitive binds one thing, and together they make a unit of work verifiable after the fact and tamper-evident in perpetuity.

// Binding matrix · 4 primitives × 2 axes

  • 5.1SHA-256 commitmentresultthe computation was correct
  • 5.2RSA signatureactorthe content of the signed message
  • 5.3RSA encryptionchannelthe policy of what runs inside
  • 5.4prev_hash linkagerecordwhether any logged result was correct

Proof-of-Execution

// 5.1 · the binding layer

// Key claim

The binding layer. Not honest computation.

// PoE v1 · formula
PoE = SHA-256(task_id ‖ result ‖ node_id)

A hash commitment. The network reconstructs the hash from the returned result, the known task_id, and the known node_id, then compares. Mismatches reject.

// PoE properties · binding · 2 entries

  • // proves

    A specific node returned a specific result for a specific task.

  • // does not prove

    That the computation was performed honestly without re-execution. Honesty is enforced out-of-band by sampled redundant re-dispatch (5.5) and by economic incentives via the staking contract.

// PoE flow · node + coordinator5 stages
  1. // 01node

    Compute

    node runs the unit of work locally

  2. // 02node

    Commit

    node SHA-256s (task ‖ result ‖ node)

  3. // 03node

    Sign

    node personal-signs the result

  4. // 04coord

    Reconstruct

    coord SHA-256 from canonical inputs

  5. // 05coord

    Match

    compare commitment to reconstruction

PoE v1 versus zero-knowledge

// 5.1 · what we shipped, what we have not

Real zero-knowledge proofs collapse binding and validation into one primitive. They are not deployed today because proof-generation cost for general-purpose compute runs orders of magnitude above the useful work itself. The research direction is to track the zkVM literature and migrate once the economics flip.

// PoE v1 · zero-knowledge · 9 axesdocumentation.md §5.1

  • Cryptographic primitiveSHA-256 commitment over (task_id, result, node_id)zk-SNARK / zk-STARK over the program trace
  • Proves binding (result to task)YesYes
  • Proves honest computationNo · requires redundancy to detect liesYes · directly
  • Verifier costOne hash reconstruction (microseconds)Proof verification (ms → s)
  • Prover costNegligible · one hashHeavy · often greater than exec time
  • Detects fabricated outputsOnly with sampled re-dispatchYes · every time
  • Detects algorithm modificationOnly with sampled re-dispatchYes · every time
  • Build statusAvailable at launchResearch direction
  • Why nowCheap, fast, sufficient with the network + samplingReplaces redundancy once production-ready

Note·Why PoE v1 and not ZK now

PoE v1 binds the result to the actor and the task; sampled redundancy detects dishonest computation. The pair composes into the validation guarantee that real ZK collapses into a single primitive. Migration happens when ZK proof-generation costs fall below the useful work itself.

The launch validator model

// 5.5 · hash check + sampled redundancy

At launch the coordination layer is the validator. Two checks run before settlement.

// At launch · validation pipelineshipping

  1. // 01

    Hash-commitment reconstruction

    Reconstruct SHA-256(task_id, result, node_id) and compare to the node's commitment. Mismatches reject outright.

  2. // 02

    Sampled redundant re-dispatch

    A configurable fraction of completed units, whole inference requests or general-path sub-tasks, dispatches to a second, independently selected node. Results compare. Disagreement triggers a third dispatch and a majority decision; persistent disagreement flags every party for review.

Caveat·Centralised validation is a known trade-off

At launch this is a centralised validator: one entity reconstructs hashes and samples re-dispatch. The honesty signal is that we state this clearly. Decentralised validator quorums (independent third-party validators staking $PRLX to participate in validation) are a planned later addition.

Three supporting primitives

// 5.2 · 5.3 · 5.4 · authentication · encryption · records

// Primitive register · trust layerlive now

  1. // 5.2

    RSA signature

    · RSA-SIGN

    Nodes register an RSA public key when they join. Every message a node emits is signed with the private key. The coordinator verifies against the registry. Unattributable returns are dropped.

  2. // 5.3

    RSA encryption

    · RSA-ENC

    Payloads dispatched to nodes, a whole inference request or a single general-path sub-task, are encrypted to the recipient node's RSA public key. Only that node can decrypt. Plaintext-in-transit is a configuration error, not an option.

  3. // 5.4

    Immutable records

    · HASH-CHAIN

    Validated execution records anchor to the blockchain with previous_hash linkage. Any modification to a past record breaks the chain. The tamper-evidence property comes from the chain structure, not from zk machinery.

// Where to go next · reading path