The blocks themselves are not the problem--they are just the inputs to the state machine and can be thrown out. The problem is that the amount of information that defines the full state of the network in our system grows without bound. In theory, if we changed the system to expire all the different kinds of data after some amount of time, we might be able to bound the size, but I am not aware of any work that's been done in this direction.
You still need the full blockchain for a new machine to get to the present state of the database even if the client includes a recent trusted checkpoint.
What about the idea of encoding the running snapshot of the database in such a way that it can deterministically be reduced to a single hash that commits to the entire state of the database, and having the delegates include that hash (and the block height of the block which was the head block at the time of database snapshot that the hash refers to) in the block headers as part of their job. The hash would have to be correct for the block to be valid. Once delegates finished computing (in parallel to regular block producing operations) the hash of one recent snapshot in parallel, they begin computing the hash of the state of the database immediately after the previous hash was computed. All full nodes (including of course the delegate notes) are able to coordinate on which database snapshot they will be computing the hash of next.
Then it becomes possible for the client with a recent trusted checkpoint to also get the hash of a recent trusted database state. They can ask any node that has a copy of that state (or has the full blockchain and can regenerate a copy of that state) to provide the full state to the requester. The requester will compute the hash to make sure it is in fact the true trusted database state and then continue evolving the database from that point using the portion of blockchain starting from that point. If all clients store the same database state snapshot once every 6 months (the one as of block N where N is the largest integer less than ((the current block height) - 1577846) and where N % 1577846 == 0) and only keep the most recent snapshot (to save space), then a new full client (with a trusted checkpoint no older than 6 months) only needs to download and process 6 to 12 months worth of the blockchain (unless they can find a node that also has a database snapshot that is more recent than 6 months but still older than the trusted checkpoint, in which case they only have to download and process less than 6 months worth of the blockchain) rather than the entire thing, in addition to downloading and validating the entire database state that existed somewhere between 6 and 12 months in the past.
Furthermore, if the database encoding was done in a way that anyone can provide log(K) sized proofs of the existence of some (key, value) pair in the database (where K is the number of unique keys that hold a value in the database), and the database was designed in a clever way, it
becomes possible for lightweight clients to easily verify (with only the minimal trust required that the current active delegates will not go against their economic interest to defraud users when it is guaranteed that they will eventually be caught) the proof provided by an untrusted third party (say the light wallet server) about something they are interested to know about the blockchain as it existed in the most recent snapshot (which
ideally should happen frequently enough that the most recent snapshot is always less than a minute old). This of course assumes that the light wallet knows who the current active 101 delegates are and has a way to
update that set over time (under normal circumstances) in a lightweight manner without needing to rely on trusted checkpoints built into the client (other than to initialize the belief in the active set of delegates on a new machine or after a long time of being offline). If the snapshot frequency happens fast enough that its period is less than 17 minutes, then ideally all (or >80%) of the delegates should
sign the previous block header (which creates a verification chain to the most recent snapshot) every block, so that the light wallet can actually have enough trust in the validity of the root hash of an extremely recent database snapshot.
Topic: Blockchain size projections (Read 7053 times)
