Skip to content

Instantly share code, notes, and snippets.

@n1bor
Last active November 11, 2016 22:29
Show Gist options
  • Save n1bor/55b25d72cd3c24eef85f7e24d549ef7a to your computer and use it in GitHub Desktop.
Save n1bor/55b25d72cd3c24eef85f7e24d549ef7a to your computer and use it in GitHub Desktop.

Chainstate only download - Version 2

Introduction

I originally proposed this idea: https://gist.github.com/n1bor/d5b0330a9addb0bf5e0f869518883522 and implemented a working POC of it https://github.com/n1bor/bitcoin/tree/chaindownload.

However gmaxwell thought coding the chainstate in a specific format in the block chain was a bad idea: https://botbot.me/freenode/bitcoin-core-dev/2016-10-24/?msg=75398575&page=3

And I sort of agree! So this new proposal avoids any hashes in the blockchain. As such it avoids the need for a softfork.

Instead would hardcode the hash of the chainstate in the C++ instead - much like current checkpoints.

Overview of proposal

  1. Every 10,000 blocks (about every 2 months) nodes take a temporary LevelDB snapshot and then create a physical on disk copy of the blockchain at that block. Snapshot would consist of 8192 binary files each with a subset of transactions in.
  2. Whilst taking the copy the node would compute the hash of each file, and then the hash of all the hashes. These hash would be stored in the leveldb database.
  3. The client would keep a copy of the chainstate that corresponded to the last checkpoint in the source code if it had it. It would also keep the last 3 - 10,000 block copies. (So a minimum of about 4.5 months worth).

A new node would then be able to download chainstate as per my previous proposal, and would have the hash available to it in the C++ to check it was authentic. The chainstate would be as old as the previous 10,000th block before the release of that version. So 1-6 months old. This would still reduce significantly the initial block download time.

When a node upgraded it would have the last chainstate checkpoint data (assuming upgraded less that 4.5 months after release) and so be able to server chainstate to later upgraders who did not have the blockchain.

Advantages

The advantages over the previous proposal are:

  1. No softfork.
  2. Chainstate format etc.. can be changed at any time. Nothing is encoded in the blockchain itself.

Proof of concept

I have not coded this yet! But 90% of the code is already in the existing POC. Only additional task would be to add the code to dump the chainstate block to files, and then read back from them when requested. If this idea gets some ACKs will update code!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment