Difference between revisions of "Proof chain"

Latest revision as of 08:46, 16 July 2014

Figure 0-a: Diagram of proof chain

The proof chain is 1 of the 3 core components of the mini-blockchain scheme and provides our 3rd function of the blockchain. It is essentially just a chain of block headers. When nodes discard the old blocks, they will not discard the block headers, only the transactions. So the mini-blockchain is essentially a blockchain pruned of all but the most recent transactions. This means all nodes can still use the chain of block headers to verify the best mini-blockchain with the highest cumulative difficulty, and thanks to the account tree they don't need old transactions to calculate address balances.

The way the proof chain works is that it essentially acts as a container of spent network energy because the proof-of-work solutions (or “proofs”) are chained together in such a way that each proof is connected to the one before it and each proof corresponds to the block it was created for. The proof chain proves which mini-blockchain has the most long-term computational backing. We are able to store this proof chain indefinitely because it is extremely small and trimmable and we don't need to store all the block data along with it.

We have what is essentially a normal blockchain, so mining can work the same way as it does in Bitcoin. Nodes must hash the block headers and search for resulting hashes below the current target. It's possible to discard old transactions and store only a chain of block headers because proving the solution doesn't rely upon knowing the transactions in the block. It's secure for the same reason Bitcoin is secure, each proof in the proof chain feeds into the next proof, making it nearly impossible to generate a fake proof chain.

The master hash needs to be embedded in the block headers as detailed in figure 0-a because it allows the nodes to verify the transactions in the block and make sure their account tree has been altered correctly by the block. The master hash stored in the block header is calculated after the transactions in the block have been applied to the account tree. We can work our way from the start of the proof chain up to where it feeds into the back-end of the mini-blockchain and we can verify that the most recent blocks we have are valid.

Without the proof chain it's impossible to tell which blockchain and account tree should be trusted, the proof chain essentially helps to secure the entire network and point nodes to the right chain. It gives us some historical data about what happened before the oldest block in the mini-blockchain, and it's the best type of data: proof-of-work. We can work our way from the start of the proof chain up to where it feeds into the back-end of the mini-blockchain and we can verify that the oldest block in the mini-blockchain has the backing of the proof chain.

Security provided by proof chain

Since the proof chain proves which mini-blockchain has the most long-term computational backing, an attacker cannot sit around forever generating a fake proof chain because the proof chain must feed into the mini-blockchain. So if an attacker tries to create a totally invalid mini-blockchain they will also need a strong proof chain to go along with it. This essentially takes us back to the level of security of offered by a typical full blockchain scheme, but it's still not perfectly secure in all situations.

The main problem is that an attacker could build on the legitimate proof chain in secret using an invalid account tree, and then release the secret chain to the network when the they think it's so long that no one will have history going back that far. In that situation new nodes would not be able to detect which chain was real. We call this the "The Secret Chain Attack". If all transactions can be discarded after a week (as in Cryptonite) the attacker must maintain the majority of the hashing power for more than a week (in secret).

We believe even if this attack does happen it wont be catastrophic because:

1. the attack will only affect nodes who haven't synced with the network in more than a week, all other nodes can detect the attack and reject the fake chain.
2. a possible Secret Chain Attack underway can be detected by new nodes, although they cannot know which chain is the real one.
3. the release of "community checkpoints" will point nodes to the correct chain in the off chance this attack did happen, thereby making it a worthless attack.

See weaknesses and attack vectors page for more info.

Trimming the proof chain

It's possible to trim down the proof chain because after a sufficient period of time has passed it wont reduce the total cumulative difficultly of the chain enough to pose a problem. Assuming the trimmings are not done periodically the security risk should be low once the chain is long enough. There's no real reason to store proofs which go right back to original genesis block, we can simply update the genesis data in the source code after a sufficient period of time, without requiring any type of forking to take place.