Paying to keep data (longevity)

ZooBC nodes prune old history, so an ordinary transaction stays on a mainnet node for 30 to 60 days (pruning of history). A longevity record keeps one chosen transaction, and the block it is in, on every node for as long as the record holds money. It is how a proof of payment, the hash of a document or an escrow with a distant deadline stays readable from any node.

Opening a record

There are two ways to open a record.

• The survival field. A transaction of version 2 or 3 carries a survival field: the sender's own deposit, either 0 or at least 0.1 ZBC (10,000,000 atomic units). A deposit there opens a record for that same transaction (transaction envelope).
• FundLongevity (type 52). Any account may fund any transaction. The body is exactly 28 bytes: the target transaction's id (8 bytes), the amount (8), the height of the block that holds the target (4) and the target's size (8), its body plus its message. The amount must be at least 0.1 ZBC.

The first funding must arrive while the target is younger than one snapshot interval, 172,800 blocks (about 30 days) on mainnet, and it must state the target's real height and size. That window guarantees that every node still holds the target and can check the claim. A late or wrong first funding is a paid no-op: the fee is kept and nothing is funded.

A later top-up must state the same size, and it may come at any time while the record lives. Its price is blended into the record's price as a weighted average.

What it costs

When the record is opened it locks the size of the target and the storage price per MiB (0.05 ZBC at the start). It pays nothing until two snapshot intervals after the target's block, because the nodes keep the transaction that long anyway. After that, once per period:

rent = ceil(payload bytes × locked price ÷ 1,048,576), at least 1 unit

The rent is taken from the deposit and credited to the longevity pool, which pays the nodes a slice in every block through the coinbase lottery. At the starting price a 16-byte payload pays 77 units per period and a 1,000-byte payload 4,769 units, so for the larger one the minimum deposit of 0.1 ZBC covers more than 2,000 periods. When a record's money reaches zero, the record is released and its transaction can be pruned again.

Snapshots carry the funded transactions together with the headers of the blocks that hold them, so a node that joins from a snapshot holds them too (snapshots and fast sync).

Ending a record

The rent is drawn from the payers' money first in, first out: the oldest deposit is used up before the next one is touched. A record lives as long as anyone still pays.

To end it early, every payer whose money is not yet used up votes with an ordinary CloseLongevity (type 309). When the last of them has voted, the record closes and its remainder goes to the longevity pool.

• A top-up withdraws that payer's vote, and a new payer must vote too.
• A payer who lost its key simply keeps the record alive until its money runs out.
• When billing uses up the money of the last payer who had not voted, the record closes at that billing block.

Nothing paid into a record comes back to a payer, so nobody can take the others' deposits. The CancelLongevity type (53) is retired: every chain refuses it. No outside party, the ZooBC Foundation included, can close a record.

Reading records

The node API has routes for records and prices: /longevity, /longevity/quote, /accounts/<address>/survival, /accounts/<address>/objects and /objects/<id>.

See also

• Pruning of history
• The transaction envelope
• The pools
• The archive and reading the past
• Project ideas