Heartbeat Chain

[!WARNING] Prototype, not shipped This page describes PoC 1 and PoC 3 from the xeprotocol/proof-of-uptime research repository. They are standalone Node.js demos. There is no heartbeat code in an XE node, and no block carries a heartbeat or VDF output. See the section overview for what is and is not implemented.

PoC 1 establishes the foundational primitive: a linear hash chain of dual-signed heartbeats between provider and consumer.

Concept

Every ~60 seconds, both parties participate in creating a heartbeat that cryptographically chains to the previous one. Neither party can fabricate heartbeats alone, and the chain cannot be backfilled because each heartbeat depends on the hash of its predecessor.

H0 ← H1 ← H2 ← H3 ← ... ← Hn
│         │              │
tip      each links     genesis
         to prev

Signing Process

Heartbeat creation is a four-step protocol between provider and consumer:

Step 1: Provider Creates Payload

The provider constructs the heartbeat payload:

leaseId:sequence:timestamp:prevHash

Field

Type

Description

leaseId

string

Hash of the lease block

sequence

uint64

Monotonically increasing counter (0-indexed)

timestamp

int64

Unix millisecond timestamp

prevHash

hex string

SHA-256 hash of the previous heartbeat (zero hash for genesis)

Step 2: Provider Signs

The provider computes the SHA-256 hash of the payload and signs it with ed25519:

payloadHash = SHA-256(payload)
providerSig = ed25519.Sign(providerKey, payloadHash)

Step 3: Consumer Countersigns

The consumer receives the payload and provider signature, verifies the provider's signature, then countersigns the payload joined to the provider signature:

consumerInput = payload : providerSig
consumerSig   = ed25519.Sign(consumerKey, SHA-256(consumerInput))

Step 4: Final Hash

The complete heartbeat hash chains everything together:

finalHash = SHA-256(payload : providerSig : consumerSig)

This finalHash becomes the prevHash for the next heartbeat.

Heartbeat Structure

The prototype emits a heartbeat as a plain record; hashes and signatures are hex strings.

{
  leaseId,      // lease block hash
  sequence,     // monotonic counter
  timestamp,    // unix millis
  prevHash,     // SHA-256 of previous heartbeat (hex)
  providerSig,  // ed25519 signature (hex)
  consumerSig,  // ed25519 countersignature (hex)
  hash,         // SHA-256 of complete heartbeat (hex)
}

JSON-encoded, that is a few hundred bytes per heartbeat: the PoC 4 24-hour demo measured 718.9 KB across 1,440 heartbeats. A binary encoding would be considerably smaller, but no binary format has been specified.

Properties

Forward-Only

Each heartbeat references the hash of the previous one. To insert or modify a heartbeat mid-chain, every subsequent hash would need to be recomputed -- but that would require both signatures to be regenerated, which requires both private keys.

Dual-Signature Requirement

Both provider and consumer must actively participate. A provider cannot fabricate heartbeats without the consumer's signing key, and vice versa.

[!INFO] Why dual signatures matter A single-signed chain proves only that the signer was running something. Dual signatures prove that two specific parties were communicating at the claimed time -- a much stronger guarantee.

Discardable History

The chain tip is self-verifying. Given heartbeat Hn, you can verify its signatures and confirm it claims to follow Hn-1 (via prevHash). You don't need the full history to validate the latest state -- only to prove specific past heartbeats existed.

Compact On-Chain Footprint

Only the chain tip needs to be stored on-chain for basic verification. The full chain can be stored off-chain by either party and disclosed during disputes.

Weakness: Batch Fabrication

[!WARNING] The collusion problem If provider and consumer collude, they can batch-generate an entire chain of heartbeats instantly. There is no mechanism in PoC 1 to bind heartbeats to real wall-clock time.

A month of fake heartbeats can be generated in the time it takes to sign them — nothing in the construction costs wall-clock time.

This is the motivation for PoC 3's VDF addition.

VDF Hardening (PoC 3)

PoC 3 addresses batch fabrication by adding a Verifiable Delay Function (VDF) to each heartbeat. The VDF input is the previous heartbeat's hash, and its output is folded into the signed payload:

vdfOutput = SHA-256(SHA-256(...SHA-256(prevHash)...))       // N iterations
payload   = leaseId : sequence : timestamp : prevHash : vdfOutput

Because each VDF input depends on the previous heartbeat's hash, the chain is inherently sequential: the work cannot be parallelised across heartbeats.

The prototype sets N = 100,000, tuned for roughly 50-100 ms per heartbeat on a typical machine. The intended production setting is far higher -- enough that one heartbeat costs about one heartbeat interval of sequential computation, so faking a day of uptime costs a day of compute.

[!WARNING] The prototype VDF is a stand-in Iterative SHA-256 is not a real VDF. Its verification cost is symmetric: checking the output means recomputing all N iterations, so a verifier pays what the prover paid. A production construction (Wesolowski or Pietrzak) computes in T sequential steps but verifies in O(log T) from a proof, and would need per-hardware-class calibration of the iteration count. Neither has been selected.

Production Decision

Despite VDF's effectiveness, the production design omits it from the base protocol. The reasoning: fabrication requires both parties to cooperate, and the consumer is spending real XUSD to do it. Unless the XE emission is worth more than the lease cost, the colluding pair loses money — so the VDF is buying protection against a case the emission curve is already designed to exclude, at a standing computational cost to every honest participant.

VDFs are kept in reserve as an optional hardening layer. Turning one on would be a protocol change, not a runtime switch: no sys.* key toggles a VDF today, so activating it would mean shipping the construction first and then governing its parameters via state chain governance.

Merkle Epochs -- compressing heartbeat chains into epoch roots
Production Design -- how heartbeat chains fit into the three-layer architecture
Threat Analysis -- attacks against heartbeat chains and mitigations
Accounts and Keys -- ed25519 key pairs used for signing