Security and architecture
ZooBC's security rests on signatures and hashes, not on energy spent. Every block, transaction, receipt and seed proof is signed, and every node checks everything it accepts, so no node has to take another's word for anything. Around that core, the architecture adds a few firm limits: settled history cannot be rewritten, a new node can find the genuine chain on its own, and a signature counts on one chain only.
The attacker ZooBC plans for
The design assumes an attacker who can run any number of nodes and accounts, sees every message, exploits any logic flaw and is wealthy, but who cannot forge signatures, find hash collisions or buy every token. Its goals would be to steal, censor, rewrite history or disrupt the chain. What Proof of Participation defends against goes through each attack and its answer.
Two chains in every node
Every node keeps two chains. The main chain makes a block every 15 seconds and carries the transactions; its blocks are made by registered nodes drawn by lot (see Proof of Participation). The spine chain makes one block a day on mainnet and carries no transactions: each block is a checkpoint of the main chain, a record of the node keys that joined or left, and the manifests of the latest state snapshots, co-signed by two thirds of the seats.
Layers of defence
| Layer | What it guarantees | Article |
|---|---|---|
| validation by every node | a block counts only if its drawn producer signed it and its seed proof, transactions and receipts check out | Proof of Participation |
| equal, paced seats | power cannot be bought quickly: one equal chance per seat, one admission per cycle | What Proof of Participation defends against |
| bounded rollback | no node rolls back more than 720 blocks (3 hours) | Finality and rollback |
| spine checkpoints | no node reorganises below a checkpoint that two thirds of the seats co-signed | The spine chain |
| checked fast sync | a new node loads the state the spine names, checks every hash and samples its peers | Snapshots and fast sync |
| release pin | a new installation refuses a spine history that contradicts its release | The release pin |
| chain-bound signatures | a transaction signed for one chain is refused on every other | Chain-bound signatures |
| two-thirds decisions | checkpoints, bridge transfers, oracle facts and release vetoes need two thirds of the seats | The two-thirds rules |
| unpredictable seeds | no producer can choose the randomness that picks the next producer | The block seed (VRF) |
| double-signing reports | a producer that signs two blocks on one parent is proven and charged | Double-signing (equivocation) |
The layers overlap. A rewrite of history from a year back, for example, fails at each of several layers on its own: the rollback limit, the checkpoint floor, the spine's co-signatures and the release pin.
What a majority could and could not do
Even an attacker holding more than half of the seats could only delay or censor transactions and replace recent blocks within the 3-hour limit. It could not forge signatures, spend others' coins, mint more than the coinbase schedule or go below the spine checkpoint, because every node checks every block for itself.
What ZooBC's security does not rely on
- Secrecy. Peer traffic is plain gRPC; protection comes from signatures and verification.
- Energy or hardware. No puzzle is solved and no machine gives an advantage.
- A trusted party. No foundation countersigns blocks, no website vouches for snapshots, and a single honest peer is enough to learn of the heaviest chain.
See also
Articles in this topic
- Chain-bound signatures
Why a transaction signed for one ZooBC chain cannot be replayed on another: every signature covers the chain's genesis hash, the only identity a ZooBC chain has. - Finality and rollback
How far a ZooBC node will roll back to follow a heavier branch (720 blocks, 3 hours), why it never goes below the spine checkpoint, and how a stranded node rebuilds itself. - Snapshots and fast sync
How a new ZooBC node reaches the present without replaying every block: monthly state snapshots named in the spine, checked chunk by chunk and against its peers. - The release pin
The pin a ZooBC release can ship: one public line naming a spine block by height and hash, which a node checks at start-up so that it never runs on a forged spine history. - The spine chain
The slow second chain every ZooBC node keeps: one block a day, co-signed by two thirds of the seats, holding main-chain checkpoints, node-key changes and snapshot manifests. - The two-thirds rules
Which ZooBC decisions need two thirds of the registered seats (spine blocks, bridge transfers, oracle facts, release vetoes, rule upgrades), how suspended seats count, and what needs no vote. - What Proof of Participation defends against
The attacker ZooBC is designed to resist, and how Proof of Participation answers each attack: bought power, Sybil seats, a majority, seed games, long-range rewrites and eclipse.