Checkpoints

[pixelspark]

Rollup = current state of database serialized in some canonical format (note, take care of undefined stuff, such as row ordering, sorting specifics, etc.).

• Mark every N'th block as a checkpoint block
• In a checkpoint block, include a hash of a rollup of blocks (i-x-N)...(i-x) where x is a parameter determining when blocks are considered verified and N is the rollup interval.
• Miners calculates a rollup before a checkpoint block is made, then only accept a new checkpoint block from someone else when the rollup hash matches (rollup block cannot contain new transactions).
• At some point in time, a checkpoint block becomes the 'new genesis' (new nodes that want to join the network need to obtain a checkpoint hash from someone else). Note, a checkpoint hash + the next N blocks containing that hash (conforming to the difficulty requirements, which should not depend on the block contents) is proof that the checkpoint was accepted by miners.
• Non-miners simply accept any mined block (miners will only mine from a block that contains a valid checkpoint). They can start syncing blocks from a certain checkpoint and discard old blocks.

[pixelspark]

Use a Merkle tree for partial roll ups/verification?

[pixelspark]

Merkle tree containing hashes for sets of N (1000? or <x MB, whichever comes first) rows. (Doesn't really need to be a tree now does it? Or perhaps group by table to allow fetching a table).

For downloading a copy, we need a fetchArchive gossip message using which a particular slice can be downloaded.

Nodes each verify a random piece against their own copy (if they only have partial copies that's what they'll verify against). They can also request a slice from another node (that builds it on the fly). If a signature is not good the block that contains it won't be accepted.