What Proof of Participation defends against
Proof of Participation was designed against a strong attacker: one who can run any number of nodes and accounts, sees every message on the network, exploits any flaw in the logic and has plenty of money. It assumes only that the attacker cannot forge signatures, cannot find hash collisions and cannot buy every token. Against that attacker, it aims to prevent four things: stealing, censoring, rewriting history and disrupting the chain. This page goes through the main attacks and the rules that answer them.
Buying block production
In Proof of Work, power follows hardware; in Proof of Stake, coins. Both can be bought quickly. In Proof of Participation every registered seat that is not suspended has the same chance of being drawn for the next block, whatever its balance or hardware (see draw). Coins and machines alone buy nothing: power needs seats.
Seats come only through the queue, at a pace the protocol sets. The first newcomer joins 7 days after genesis. Each admission then sets the wait for the next: 600 days divided by the seats counted before that newcomer, kept between 7 and 90 days. Genesis seats count as at most 11, and suspended seats do not count. With 11 seats the wait is about 54.5 days, so the second newcomer arrives at about day 61.5. The queue is ordered by stake multiplied by time waited, so an attacker must also outbid honest applicants.
Sybil identities
A Sybil attacker creates many identities to gain influence. In Proof of Participation an identity is a registry seat, and each seat has real costs:
- Money. A locked stake of at least the queue minimum, which starts at 100 ZBC (the seats can vote it between one atomic unit and 250 ZBC, and at entry half the median queued stake can lift it). 10 % of it is at risk.
- Time. A place in a queue ordered by stake × time waited, and a paced admission: weeks or months between newcomers.
- Work. A new seat starts at a participation score of 20 % and earns nothing until it is mature: 4 score units after admission plus one block of its own, 2 days below 2,880 nodes. It must then keep producing its turns and relaying.
A seat that goes silent counts as missing, earns nothing and loses score; at zero it is expelled and 10 % of its lock goes to the longevity pool. The same 10 % is lost by leaving while missing or suspended, or by leaving the queue. An exit in good standing returns the whole lock after a 7-day cool-down. See missed turns, suspension and expulsion and leaving the registry.
A majority of the seats
Suppose an attacker did control more than half of the seats. It would make most blocks and could build the heaviest branch, which is what a majority buys on any heaviest-chain design. It could:
- delay or censor transactions by leaving them out of its blocks;
- replace recent blocks, within the rollback limit, by building a heavier branch.
It could not forge anything. Every node checks every block: each transaction's signature, each block's seed proof, each receipt and each coinbase amount. A majority cannot spend the ZBC of accounts whose keys it does not hold, cannot pay itself more than the fixed coinbase schedule, and cannot rewrite history older than 720 blocks (3 hours) or below the last spine checkpoint (see finality and rollback). Blocks made after skipped turns also weigh less, and idle seats lose their income and their score.
Gaming the seed
The seed that drives every draw is the output of a verifiable random function: a producer cannot choose it among several values. Its only lever is to withhold its block, which costs a missed turn, income and score, and only hands the seed to the next drawn node (see block seed (VRF)).
Rewriting history from far back
A long-range attack builds a different history from far in the past, for example with the old keys of nodes that left the registry long ago. Each of these defences stops it on its own:
- a running node never rolls back more than 720 blocks;
- no node reorganises below the last checkpoint co-signed on the spine chain;
- a new node follows the spine, whose blocks need two thirds of the seats and which records which node keys joined and which left, so keys that left long ago are not on its signer list;
- the release a new node installs can carry a release pin, so a forged spine history is refused at start-up.
Keys do not expire, and nobody reviews branches by hand.
Eclipse
In an eclipse attack, the attacker surrounds a node with its own peers so that the node sees only the attacker's chain. Against a registered node this is hard. Its assigned peers, 12 on mainnet, are drawn from the seed of a period block and re-drawn every 40 blocks (about 10 minutes), so the attacker cannot choose them (see receipts and the network topology). Peers prove their node keys in a signed handshake that also names the chain's genesis hash. And one honest peer is enough: fork choice is by weight, so a single connection reporting a heavier branch lets the node fetch it and check it block by block. A node whose tip has gone stale follows the tip that two thirds of a sample of registered peers report.
Peer traffic travels as plain gRPC, without encryption: the protection comes from signatures and verification, not from secrecy.
Other attacks
- Double-signing a block is proven by an EquivocationReport and charged as a missed turn (see double-signing (equivocation)).
- Replaying a signed transaction on another ZooBC chain fails, because every signature covers the chain's genesis hash (see chain-bound signatures).
- Forged snapshots are caught by hashes named in the co-signed spine and by a sample checked with registered peers (see snapshots and fast sync).