Performance certificates: making providers prove their hardware

Since v0.4.2, a provider can't take a lease until it has run a sixty-second benchmark the network can check, and can't outsource.

1 min read

  • XE Protocol

Machine-readable: /blog/performance-certificates.md

A marketplace for compute is only as good as the honesty of its listings. v0.4.2 makes providers prove what their machines can do before they're allowed to accept a lease.

A benchmark with a receipt#

On startup, a provider runs a benchmark of about sixty seconds: a SHA-256 hash chain of 375 million iterations, followed by a memory-hard phase. The result is a performance certificate: attested timestamps, a score, and merkle-root proofs of the work.

  • Certificates are broadcast over the xe/certificates GossipSub topic, and every node caches them.
  • Any node serves any provider's certificate at GET /certificate/{provider}.
  • The format is compact: merkle roots instead of full arrays cut a certificate from 2.6 KB to 837 bytes.

Why it can't be faked#

The memory-hard phase builds a 256 MB lookup table and makes a million reads from it, each one depending on the last. Doing that over a network instead of in local memory would be about ten thousand times slower, so a provider can't rent the benchmark out to faster hardware somewhere else.

Also in v0.4.2#

  • Timekeeper attestations are mandatory on lease_accept and lease_settle. Self-reported timestamps are gone.
  • Certificates with the wrong iteration count are rejected.
  • Provider nodes refuse to start without sys.timekeepers in the state chain.

See the changelog for the full release.

  • Written by

    XE Protocol

    Core engineering

    The engineers behind the XE node: the lattice, consensus, and compute leasing.

    GitHub ↗

←All posts

Read more like this

Newsletter

New posts, straight to your inbox.

Releases, protocol deep dives and the occasional opinion. Nothing else, and you can leave any time.