Threat Analysis

Red team analysis of the proof-of-uptime system. Each threat is assessed for feasibility, impact, and available mitigations.

#Threat Summary

#Ghost Node Attack

Scenario: Provider accepts a lease, extracts the VM's signing key, shuts down the actual VM, and runs a lightweight sentinel process (e.g., on a Raspberry Pi) that generates heartbeats using the extracted key. The provider earns emissions without providing any compute.

Normal:     Provider VM ←──heartbeats──→ ConsumerGhost:      Raspberry Pi ←──heartbeats──→ Consumer (no real VM)

#Defences

Filesystem challenges. The consumer can issue random filesystem challenges -- requesting the hash of a specific file or directory in the VM. A ghost node without the actual filesystem cannot respond correctly.

Compute challenges. Similar to filesystem challenges but targeting CPU/memory. The consumer sends a computation that requires real resources (e.g., hash a large random buffer). Response time reveals whether real hardware is backing the VM.

Fisherman verification. Third-party verifiers independently probe provider VMs. See Stage 3 of the rollout plan.

Collateral slashing. If a ghost node is detected and a dispute succeeds, the provider's staked collateral is slashed. The economic loss from slashing must exceed the potential gain from running ghost nodes.

#Collusion

Scenario: Provider and consumer agree to fabricate heartbeats without any real compute occurring. They split the XE emissions between them.

Provider ←──fake heartbeats──→ ConsumerNo VM running, but chain looks valid

#Defence: Economics

The primary defence is economic design:

emission_per_heartbeat < lease_cost_per_heartbeat

For collusion to be profitable:

1. Consumer pays XUSD for the lease.
2. Provider earns XE emissions.
3. Total XE earned must exceed total XUSD paid.

Network parameters ensure this inequality never holds. The colluding pair loses money on every fabricated heartbeat.

#Defence: VDF (Optional)

If economic parameters change or an edge case is discovered, VDF hardening can be activated. With VDF enabled:

• Fabricating 1 day of heartbeats takes 1 day of computation.
• The colluding pair cannot batch-generate a month of proofs in seconds.
• Even with collusion, real wall-clock time must be spent.

VDF is available as a governance-activated option via the state chain.

#Key Compromise

Scenario: An attacker obtains a provider's or consumer's ed25519 private key. They can now sign heartbeats on behalf of the compromised party.

#Current Status

#Required Mitigations

Key rotation protocol. Both provider and consumer must be able to rotate their signing keys. The new key must be registered on-chain (via a block or state chain operation) and the old key invalidated.

Rotation triggers:

• Scheduled rotation (e.g., every 30 days)
• Manual rotation on suspected compromise
• Forced rotation by governance in emergency

Backward compatibility. Old heartbeats signed with the previous key must remain verifiable. The chain of trust should record which key was active during which period.

HSM support. For providers running high-value leases, hardware security module integration would prevent key extraction entirely.

#Timestamp Manipulation

Scenario: A provider manipulates the timestamp field in heartbeats to claim uptime during periods when the VM was actually down.

Real:     H1(t=100) H2(t=160) [gap: VM down] H3(t=500)Faked:    H1(t=100) H2(t=160) H3(t=220) H4(t=280) ...

#Current Status

#Required Mitigations

Tolerance windows. Each heartbeat's timestamp must be within an acceptable range:

expected = prevTimestamp + intervaltolerance = 30 secondsassert abs(heartbeat.timestamp - expected) < tolerance

Monotonicity enforcement. Timestamps must be strictly increasing:

assert heartbeat.timestamp > prevHeartbeat.timestamp

Clock drift handling. Allow for reasonable NTP drift between provider and consumer clocks. A tolerance of 5-10 seconds handles normal drift without opening manipulation windows.

Attestation timestamps. Timekeeper attestations provide an independent timestamp that can be compared against heartbeat timestamps for consistency.

#Performance Degradation

Scenario: Provider runs the VM but at reduced capacity -- fewer CPU cores, throttled memory, or overloaded disk I/O. Heartbeats continue normally because the signing process requires minimal resources.

Lease:    4 vCPU, 8 GB RAMActual:   1 vCPU, 2 GB RAM (heartbeats still work fine)

#Current Status

This attack is not addressed at the heartbeat level. Heartbeats prove presence, not performance.

#Mitigation Approach

Performance verification is the consumer's responsibility:

• Application-level health checks
• Compute benchmarks run inside the VM
• Resource monitoring agents
• SLA-based dispute triggers

#Overcommitment

Scenario: Provider accepts more leases than its hardware can support. Each individual lease appears healthy (heartbeats continue), but all VMs are degraded.

Hardware:  8 vCPU totalLease A:   4 vCPU ─┐Lease B:   4 vCPU  ├── 12 vCPU committed, 8 availableLease C:   4 vCPU ─┘

#Current Status

There is no cross-lease awareness in the current system. Each lease is verified independently, with no mechanism to detect that a provider has overcommitted its resources.

#Potential Mitigations

Resource attestation. Providers could be required to attest to their total hardware capacity. Accepting leases beyond capacity would be detectable.

Cross-lease monitoring. Sentinel nodes could track the total committed resources per provider and flag overcommitment.

Provider reputation. A reputation system based on historical performance could penalise providers that consistently underdeliver.

Hardware proofs. TEE attestation (Stage 4) could cryptographically prove the hardware resources available to a provider.

#Must-Fix Items

The following issues must be resolved before production deployment:

#Related Pages

• Production Design -- the three-layer architecture and staged rollout
• Heartbeat Chain -- VDF hardening details
• Merkle Epochs -- merkle proof construction
• Compute Leasing -- lease lifecycle and collateral
• Attestations -- timekeeper attestations