cheng/wallet
0
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

clarifying my account of patricia merkle trees

Browse Source 
and explaining the motivation.
This commit is contained in:
reaction.la 2022-03-30 22:09:01 +11:00
parent e71a79de03
commit 942562535c
No known key found for this signature in database
GPG Key ID: 99914792148C8388
2 changed files with 17 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
docs/libraries.md
View File

@ -139,13 +139,14 @@ being stronger than the underlying elliptic curve. With password
strengthening, we can randomly leave out one of the adjectives or adverbs
from one of the passphrases.
# Polkadot, substack and gitcoin
# Polkadot, Near, substack and gitcoin
It has become painfully apparent that building a blockchain is a very large project.
Polkadot is a blockchain ecosystem, and substack a family of libraries for
constructing blockchains. It is a lot a easier to refactor an existing
blockchain than to start entirely from scratch.
blockchain than to start entirely from scratch. [Near] is way ahead of me,
because not suffering from not invented here syndrome.
Polkadot is designed to make its ecosystem subordinate to the primary
blockchain, which I do not want - but it also connects its ecosystem to

17
docs/merkle_patricia-dac.md → docs/merkle_patricia_dag.md
View File

@ -1002,11 +1002,22 @@ solve the problem of the number of items not being a power of two?
</g>
</svg>
This is a Merkle binary dag, not a Merkle-patricia tree. I found that
This data structure means that instead of having one gigantic
proof that takes weeks to evaluate that the entire blockchain is
valid, you have an enormous number of small proofs that each
particular part of the blockchain is valid. This has two huge
advantages over the chain structure.
1. It protects clients against malicious peers, since any claim
the peer makes about the total state of the blockchain can
be proven with $\bigcirc(\log_2n)$ hashes.
1. If a block gets lost or corrupted that peer can identify that one specific block that is a problem. Peers have to reload down, or at least re-index, the entire blockchain far too often.
This is not a Merkle-patricia tree. I found that
generalizing Merkle patricia trees to handle the case of immutable append
only files led to more complicated data structures and more complicated
descriptions. It has a great deal in common with a Merkle-patricia tree, but
a Merkle vertex is its own type, even though it convenient for it to have
this vertex is its own type, even though it convenient for it to have
much in common with a Merkle patricia vertex. Putting it into the patricia
straightjacket generated a lot of mess. A Merkle patricia vertex is best
handled as a special case of a Merkle vertex, and a Merkle patricia tree as
@ -1019,7 +1030,7 @@ structure that another party is using.
This reduces the amount of trust that clients have to place in peers. When
the blockchain gets very large there will be rather few peers and a great
many peers, thus there will be a risk that the peers will plot together to
many clients, thus there will be a risk that the peers will plot together to
bugger the clients. This structure enables a client to verify that any part of
the blockchain is what his peer say it is, and thus avoids the risk that peer
may tell different clients different accounts of the consensus. Two clients