From 942562535cde2b0fa5d0db702564e87a8f011d1b Mon Sep 17 00:00:00 2001 From: "reaction.la" Date: Wed, 30 Mar 2022 22:09:01 +1100 Subject: [PATCH] clarifying my account of patricia merkle trees and explaining the motivation. --- docs/libraries.md | 5 +++-- ...e_patricia-dac.md => merkle_patricia_dag.md} | 17 ++++++++++++++--- 2 files changed, 17 insertions(+), 5 deletions(-) rename docs/{merkle_patricia-dac.md => merkle_patricia_dag.md} (98%) diff --git a/docs/libraries.md b/docs/libraries.md index 5b66077..663773b 100644 --- a/docs/libraries.md +++ b/docs/libraries.md @@ -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 diff --git a/docs/merkle_patricia-dac.md b/docs/merkle_patricia_dag.md similarity index 98% rename from docs/merkle_patricia-dac.md rename to docs/merkle_patricia_dag.md index fd59dc7..d03c71c 100644 --- a/docs/merkle_patricia-dac.md +++ b/docs/merkle_patricia_dag.md @@ -1002,11 +1002,22 @@ solve the problem of the number of items not being a power of two? -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