Add verifying snapshots book entry (#5885)
This commit is contained in:
parent
958cbe688b
commit
48d754220b
|
@ -63,6 +63,7 @@
|
|||
- [Cross-Program Invocation](cross-program-invocation.md)
|
||||
- [Rent](rent.md)
|
||||
- [Inter-chain Transaction Verification](interchain-transaction-verification.md)
|
||||
- [Snapshot Verification](snapshot-verification.md)
|
||||
|
||||
- [Implemented Design Proposals](implemented-proposals.md)
|
||||
- [Blocktree](blocktree.md)
|
||||
|
|
|
@ -0,0 +1,50 @@
|
|||
# Verifying Snapshots and Account state proof
|
||||
|
||||
## Problem
|
||||
|
||||
When a validator boots up from a snapshot, it needs a way to verify the account set matches what the rest of the network sees quickly. A potential attacker
|
||||
could give the validator an incorrect state, and then try to convince it to accept a transaction that would otherwise be rejected.
|
||||
|
||||
## Solution
|
||||
|
||||
Currently the bank hash is derived from hashing the delta state of the accounts in a slot which is then combined with the previous bank hash value. The problem with this is that the list of hashes
|
||||
will grow on the order of the number of slots processed by the chain and become a burden to both transmit and verify successfully.
|
||||
|
||||
Another naive method could be to create a merkle tree of the account state. This has the downside that with each account update which removes an account state from the tree, the merkle
|
||||
tree would have to be recomputed from the entire account state of all live accounts in the system.
|
||||
|
||||
To verify the snapshot, we propose the following:
|
||||
|
||||
On account store hash the following data:
|
||||
* Account owner
|
||||
* Account data
|
||||
* Account pubkey
|
||||
* Account lamports balance
|
||||
* Fork the account is stored on
|
||||
|
||||
Use this resulting hash value as input to an expansion function which expands the hash value into an image value.
|
||||
The function will create a 440 byte block of data where the first 32 bytes are the hash value, and the next 440 - 32 bytes
|
||||
are generated from a Chacha RNG with the hash as the seed.
|
||||
|
||||
The account images are then combined with xor. The previous account value will be xored into the state and the new
|
||||
account value also xored into the state.
|
||||
|
||||
Voting and sysvar hash values occur with the hash of the resulting full image value.
|
||||
|
||||
On validator boot, when it loads from a snapshot, it would verify the hash value with the accounts set. It would
|
||||
then use SPV to display the percentage of the network that voted for the hash value given.
|
||||
|
||||
The resulting value can be verified by a validator to be the result of xoring all current account states together.
|
||||
|
||||
An attack on the xor state could be made to influence its value:
|
||||
|
||||
Thus the 440 byte image size comes from this paper, avoiding xor collision with 0 (or thus any other given bit pattern):
|
||||
[https://link.springer.com/content/pdf/10.1007%2F3-540-45708-9_19.pdf]
|
||||
|
||||
The math provides 128 bit security in this case:
|
||||
```ignore
|
||||
O(k * 2^(n/(1+lg(k)))
|
||||
k=2^40 accounts
|
||||
n=440
|
||||
2^(40) * 2^(448 * 8 / 41) ~= O(2^(128))
|
||||
```
|
Loading…
Reference in New Issue