aere-network/aere-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
53f1b81117
aere-docs/AERE-COMPUTE-MARKET-V3-SUMMARY.md

7.3 KiB
Raw Blame History

Spec 10: Aere Compute Market V3 (proof-carrying DePIN)

Note added 2026-08-19. Statements in this document that consensus on chain 2800 is (or remains) classical secp256k1 ECDSA QBFT were written before the post-quantum header anchor went live, and remain true for block-by-block finality. Since block 13,014,000 anchor blocks (every 32nd block, on every one since block 13,889,296) also carry, under the block hash, a certificate of validator Falcon-512 seals, and since 2026-08-14 a node rejects an anchor block with fewer than three valid seals (f+1 of nine; eight or nine are carried in practice). That is a post-quantum checkpoint about every 16 seconds, not a per-block quorum: the claim published on 2026-08-15 that from block 14,050,000 no block finalizes without a post-quantum quorum was wrong (the per-block rule armed at that height is retired in the shipped code in favour of the anchor rules) and was withdrawn on 2026-08-19. Details: https://aere.network/quantum.html and the aere-node repository, anchor/README.md.

Revised 2026-07-20. The prior revision of this file described V3 before the liveness review; the sections below supersede it.

Delivered

  1. aere-contracts/contracts/depin/AereComputeMarketV3.sol (new; deployed V1/V2 untouched)
  2. aere-contracts/test/AereComputeMarketV3.test.js (14 tests: safety)
  3. aerenew/contracts/test/AereComputeMarketV3.liveness.test.js (14 tests: liveness and griefing, NEW)
  4. aere-research/formal-consensus/computemarket_smt.py (z3 solvency model, extended for the new exits)
  5. aerenew/docs/AERE-COMPUTE-MARKET-V3.md

What it does

Requester posts a job (specHash, reward escrow, deadline, verification mode); provider claims and runs off-chain; result acceptance depends on the mode:

  • REPLAY (0): deterministic recompute. Result bytes emitted; challenge window; a dispute records the challenger's recomputed hash; arbiter resolves. Cheap, and only sound for deterministic work.
  • ZK_VERIFIED (1): SP1 proof verified on-chain via the deployed SP1 gateway (ISP1Verifier). publicValues bound to the job (abi.encode(specHash, resultHash), specHash must match). Paid in the SAME tx, only on a valid proof. No other pay path exists for a ZK job. Strongest, and expensive.
  • OPTIMISTIC (2): challenge window + provider bond. A successful dispute slashes the provider bond to the challenger and refunds the requester. Cheap, but needs a watcher and a bond.

What changed in the 2026-07-20 review

The prior V3 was sound on SAFETY (nobody is paid without evidence) and had three holes in LIVENESS (funds that could never leave the contract). All three are now closed and tested.

  1. FALCON KEY MOVED FROM REQUESTER TO PROVIDER. Previously the requester supplied the settlement key at postJob, which handed the requester a permanent veto over paying for correct work: never sign, never pay. The key is now the PROVIDER's, registered at claimJob. This also makes the security claim coherent, since it is the provider's payout authorization being hardened.
  2. resolveByTimeout (NEW). An arbiter that never resolves previously froze the reward and both bonds forever. After ARBITRATION_TIMEOUT (14 days) anyone can unwind a stale dispute NEUTRALLY: reward to the requester, both bonds home, nothing slashed.
  3. reclaimUnsettled (NEW). A pqc job whose provider never signs previously locked the escrow forever. After the challenge window plus PQC_SETTLEMENT_GRACE (7 days) the requester reclaims the reward and the provider bond is RETURNED, not slashed. Guarded so it cannot be used on a non-pqc job.
  4. submitResultRef (NEW). Outputs too large for calldata commit as (keccak256 hash, URI). Data availability is explicitly NOT solved; see the design doc.

PQC: where it is used and where it is deliberately not

Used: the final payout release, optionally per job, via Falcon-512 at the live precompile 0x0AE1 over a digest binding (chainId, contract, jobId, provider, token, amount, resultHash). Fail-closed.

NOT used: posting, claiming, submitting, disputing, arbitration. None of those move value to a new owner, so ECDSA is sufficient and Falcon there would be decorative.

Two boundaries stated plainly in the doc:

  • Consensus is classical secp256k1 ECDSA QBFT. Nothing here changes that.
  • The ZK proofs are classical BN254 and Shor-breakable. pqcSettlement on a ZK job hardens WHO RECEIVES the payout; it does NOT make the proof quantum-safe.

Fail-closed / invariants

  • Escrow solvency: totalLiabilities[token] = sum(open rewards + posted bonds); contract balance always

    = liabilities per asset. isSolvent() view; asserted after every mutating step in every test.

  • No double-pay: terminal statuses reached once; nonReentrant; CEI ordering.
  • No pay-without-proof (ZK): settle inside submitResultZK after verifyProof (reverts on invalid).
  • No admin drain: no owner, no sweep. Arbiter only routes a DISPUTED job's escrow; governance only flips a token-allowlist bool.
  • Fee-on-transfer/rebasing reward tokens rejected at escrow (received must equal stated reward).
  • LIVENESS: every job has an exit no single party can block (reclaimExpired, permissionless finalize, resolveByTimeout, reclaimUnsettled).

MEASURED results, 2026-07-20

From aerenew/contracts:

npx hardhat compile -> Compiled 1 Solidity file successfully (evm target: paris).

npx hardhat test aere-contracts/test/AereComputeMarketV3.test.js test/AereComputeMarketV3.liveness.test.js -> 28 passing (7s), 0 failing.

From aerenew/formal-consensus, python computemarket_smt.py -> 21 PROVED, 4 CEX-FOUND (negative controls firing as designed), 0 FAILED.

Full-repo npx hardhat test did NOT complete: it segfaults (node exit 139) inside the Falcon KAT suites. PRE-EXISTING and unrelated to this work: npx hardhat test test/AereFalcon1024Verifier.test.js alone reproduces the same segfault on a file this task never touched. Excluding the 8 heavy Falcon-KAT files, the run reached 1044 passing / 0 failing before a 10-minute harness timeout truncated it.

Grounding used

  • Built on the AereComputeMarketV2 job/escrow model (depin/).
  • ZK: ISP1Verifier.sol + SP1VerifierGateway.sol; deployed gateway 0x9ca479C8c52C0EbB4599319a36a5a017BCC70628.
  • Falcon: input encoding + fail-closed raw-32-byte return pattern from AerePQCMessageVerifier.sol; tests use MockPQCPrecompile(1) @0x0AE1, MockSp1Verifier (reverts on invalid), MockERC20Lending.

Flags

  • [VERIFY] ZK path tested vs MockSp1Verifier (mirrors gateway revert-on-invalid); real gateway wired at deploy. Real SP1 proving has NOT been run against V3.
  • [VERIFY] Falcon path tested vs MockPQCPrecompile. Real Falcon signing has NOT been run against V3; the wire encoding is KAT-proven elsewhere and 0x0AE1 is live on 2800.
  • [DEPLOY DEPENDENCY] A pqcSettlement job is unsettleable on any chain lacking a live 0x0AE1, since _falconVerify fails closed. Deploy on 2800 or a precompile-carrying testnet, not a generic EVM chain.
  • [MEASURE] Real GPU supply, off-chain provers and real SP1 proving are external (adoption, not code).
  • [PUBLIC REPO DRIFT] aerenew/publish-bundle/aere-contracts/.../AereComputeMarketV3.sol still holds the PRE-review V3 (requester-held key, no timeout exits). That is the version mirrored to the public repo. Re-syncing the bundle is a publish action and is FOUNDER-GATED; not done here.
  • NOT DEPLOYED, NOT AUDITED. Founder-gated.