From 833b1c23b235c0db73f3f518c10ed4a69e129e04 Mon Sep 17 00:00:00 2001
From: pingshuijie Merkle TreesMerkle trees take advantage of the properties of hash functions discussed above and can perform many functions in this way. There are many different variants of Merkle trees, in this case we first look at simple Merkle trees built on a binary search tree.
The leaves of the tree store data that has been hashed using a hash function. Subsequently, the resulting hash values of each of two leaf nodes are also hashed again and the resulting hash forms the parent node of these two leaf nodes. The process of producing parent nodes by taking hash values from two child nodes is performed recursively until we have only one hash value, often referred to as a Merkle root or root hash.
Since for the same input in hash functions always the same output comes out, therefore the hash value of the parent node depends directly on the hash values of the children. So, accordingly, the root depends on all the hash values in the tree and thus all the data (hashed as leaves) in the Merkle tree. Moreover, we know that in practice it should not be possible for two different inputs to produce the same output. In this way, the integrity of the data can be checked: we can thus quickly determine whether data within a tree has changed based only on the root, since we can be sure that the original root could only have come about through the input of that very data.
-But why the tree? One can come up with the idea of simply putting all the data strung together into a hash function and even then the ouput would be unique to the input. The biggest advantage lies in the fact that in this way an efficient verifiability of individual contained data is made possible. No matter how many leaves there are in the tree, all that is needed to prove a single data point is the hash value of the data point itself, plus any sibling nodes on the way to the root. The depth of the tree is always logarithmic to the number of data in the binary Merkle tree, which can be considered efficient. Here is a pictorial illustration.
+But why the tree? One can come up with the idea of simply putting all the data strung together into a hash function and even then the output would be unique to the input. The biggest advantage lies in the fact that in this way an efficient verifiability of individual contained data is made possible. No matter how many leaves there are in the tree, all that is needed to prove a single data point is the hash value of the data point itself, plus any sibling nodes on the way to the root. The depth of the tree is always logarithmic to the number of data in the binary Merkle tree, which can be considered efficient. Here is a pictorial illustration.
diff --git a/doc/book/insert-update-proofs.html b/doc/book/insert-update-proofs.html index b3bbf7f77..9ec554489 100644 --- a/doc/book/insert-update-proofs.html +++ b/doc/book/insert-update-proofs.html @@ -208,7 +208,7 @@Insertion proofs consist of the inserted key, a non-membership proof of the node in the current tree, a membership proof of the new node in the JMT, and the updated merkle root.
The non-inclusion proof has two variants for different cases:
After finding the position the new node should be inserted into, it is inserted and a membership proof is created.
diff --git a/doc/book/print.html b/doc/book/print.html index ceb82b845..7c93b635c 100644 --- a/doc/book/print.html +++ b/doc/book/print.html @@ -389,7 +389,7 @@Insertion proofs consist of the inserted key, a non-membership proof of the node in the current tree, a membership proof of the new node in the JMT, and the updated merkle root.
The non-inclusion proof has two variants for different cases:
After finding the position the new node should be inserted into, it is inserted and a membership proof is created.
@@ -950,7 +950,7 @@The leaves of the tree store data that has been hashed using a hash function. Subsequently, the resulting hash values of each of two leaf nodes are also hashed again and the resulting hash forms the parent node of these two leaf nodes. The process of producing parent nodes by taking hash values from two child nodes is performed recursively until we have only one hash value, often referred to as a Merkle root or root hash.
Since for the same input in hash functions always the same output comes out, therefore the hash value of the parent node depends directly on the hash values of the children. So, accordingly, the root depends on all the hash values in the tree and thus all the data (hashed as leaves) in the Merkle tree. Moreover, we know that in practice it should not be possible for two different inputs to produce the same output. In this way, the integrity of the data can be checked: we can thus quickly determine whether data within a tree has changed based only on the root, since we can be sure that the original root could only have come about through the input of that very data.
-But why the tree? One can come up with the idea of simply putting all the data strung together into a hash function and even then the ouput would be unique to the input. The biggest advantage lies in the fact that in this way an efficient verifiability of individual contained data is made possible. No matter how many leaves there are in the tree, all that is needed to prove a single data point is the hash value of the data point itself, plus any sibling nodes on the way to the root. The depth of the tree is always logarithmic to the number of data in the binary Merkle tree, which can be considered efficient. Here is a pictorial illustration.
+But why the tree? One can come up with the idea of simply putting all the data strung together into a hash function and even then the output would be unique to the input. The biggest advantage lies in the fact that in this way an efficient verifiability of individual contained data is made possible. No matter how many leaves there are in the tree, all that is needed to prove a single data point is the hash value of the data point itself, plus any sibling nodes on the way to the root. The depth of the tree is always logarithmic to the number of data in the binary Merkle tree, which can be considered efficient. Here is a pictorial illustration.
maybe for the crypto intro
diff --git a/doc/book/searchindex.js b/doc/book/searchindex.js index f04ddcce1..86968c1b6 100644 --- a/doc/book/searchindex.js +++ b/doc/book/searchindex.js @@ -1 +1 @@ -Object.assign(window.search, {"doc_urls":["index.html#what-is-prism","index.html#why-prism","index.html#how-does-it-work","quickstart.html#quickstart","quickstart.html#the-authentication-challenge","quickstart.html#the-split-world-vulnerability","quickstart.html#what-is-key-transparency","quickstart.html#what-is-prism","quickstart.html#prism-as-a-sovereign-rollup-on-celestia","quickstart.html#block-sequencing-in-prism","quickstart.html#prism-node-types","quickstart.html#why-celestia","quickstart.html#enhancing-security-with-trust-minimized-light-clients","rollup.html#prism-as-a-sovereign-rollup-on-celestia","rollup.html#block-sequencing-in-prism","rollup.html#prism-node-types","rollup.html#why-celestia","rollup.html#enhancing-security-with-trust-minimized-light-clients","datastructures.html#prism-datastructures","datastructures.html#accounts","datastructures.html#jellyfish-merkle-trees","datastructures.html#service-registration","datastructures.html#account-creation","labels.html#accounts-on-prism","labels.html#high-level-overview","labels.html#account-creation-and-service-registration","labels.html#other-considerations","labels.html#future-developments","labels.html#protocols","insert-update-proofs.html#adherance-to-application-specific-guidelines","insert-update-proofs.html#versioning","insert-update-proofs.html#insertion-and-updates","insert-update-proofs.html#proof-of-update","insert-update-proofs.html#proof-of-insert","jellyfish-merkle-proofs.html#jellyfish-merkle-proofs","jellyfish-merkle-proofs.html#proof-format","jellyfish-merkle-proofs.html#proof-of-inclusion","jellyfish-merkle-proofs.html#proof-of-exclusion","jellyfish-merkle-proofs.html#efficiency-improvements","jellyfish-merkle-proofs.html#versioning","jellyfish-merkle-proofs.html#considerations-for-zero-knowledge-proofs","state.html#state-of-prism","state.html#1-circuits","state.html#2-rollup-status","state.html#3-api-development","state.html#4-state-tree-optimization","state.html#5-wasm-compatibility","architecture.html#architecture","tutorial.html#basic-service-tutorial","tutorial.html#introduction","tutorial.html#step-1-create-a-new-project","tutorial.html#step-2-starting-a-local-prism-devnet","tutorial.html#step-3-registering-your-service","tutorial.html#step-4-creating-accounts-from-your-service","tutorial.html#step-5-adding-keys-and-data-to-existing-accounts","mammothon/ct-service.html#idea-1-certificate-transparency-browser-extension","mammothon/ct-service.html#problem","mammothon/ct-service.html#solution","mammothon/ct-service.html#prism-service","mammothon/ct-service.html#browser-extension","mammothon/ct-service.html#resources","mammothon/reclaim.html#idea-2-accounts-from-web-sources","mammothon/reclaim.html#problem","mammothon/reclaim.html#solution","mammothon/reclaim.html#resources","crypto-intro/intro.html#introduction-to-cryptography","crypto-intro/symmetric.html#symmetric-encryption","crypto-intro/asymmetric.html#asymmetric-encryption","crypto-intro/hybrid.html#hybrid-encryption","crypto-intro/hash-functions.html#hash-functions","crypto-intro/merkle-trees.html#merkle-trees","crypto-intro/cryptographic_commitment.html#cryptographic-commitments","crypto-intro/general-merkle-proofs.html#proof-of-membership","informal-zkps.html#informal-zero-knowledge-proofs","informal-zkps.html#ali-baba-and-the-forty-thieves","informal-zkps.html#the-zero-knowledge-proof-in-a-new-experimental-setup","informal-zkps.html#the-simulator-paradigm","informal-zkps.html#summary","zkp-basics.html#basics-of-zero-knowledge-proofs","zkp-basics.html#the-first-small-definitions","zkp-basics.html#types-of-zkps","zkp-basics.html#next-destination-zksnarks","zkp-basics.html#proofs-arguments-and-witnesses","zkp-basics.html#how-prism-uses-zkps","resources.html#resources","resources.html#podcasts","resources.html#livestreams","resources.html#papers","resources.html#books","resources.html#talks"],"index":{"documentStore":{"docInfo":{"0":{"body":20,"breadcrumbs":2,"title":1},"1":{"body":53,"breadcrumbs":2,"title":1},"10":{"body":64,"breadcrumbs":5,"title":3},"11":{"body":31,"breadcrumbs":3,"title":1},"12":{"body":59,"breadcrumbs":8,"title":6},"13":{"body":47,"breadcrumbs":6,"title":4},"14":{"body":45,"breadcrumbs":5,"title":3},"15":{"body":64,"breadcrumbs":5,"title":3},"16":{"body":31,"breadcrumbs":3,"title":1},"17":{"body":59,"breadcrumbs":8,"title":6},"18":{"body":0,"breadcrumbs":3,"title":2},"19":{"body":129,"breadcrumbs":2,"title":1},"2":{"body":87,"breadcrumbs":2,"title":1},"20":{"body":108,"breadcrumbs":4,"title":3},"21":{"body":12,"breadcrumbs":3,"title":2},"22":{"body":132,"breadcrumbs":3,"title":2},"23":{"body":28,"breadcrumbs":4,"title":2},"24":{"body":79,"breadcrumbs":5,"title":3},"25":{"body":44,"breadcrumbs":6,"title":4},"26":{"body":59,"breadcrumbs":3,"title":1},"27":{"body":58,"breadcrumbs":4,"title":2},"28":{"body":44,"breadcrumbs":3,"title":1},"29":{"body":20,"breadcrumbs":6,"title":4},"3":{"body":21,"breadcrumbs":3,"title":1},"30":{"body":35,"breadcrumbs":3,"title":1},"31":{"body":177,"breadcrumbs":4,"title":2},"32":{"body":127,"breadcrumbs":4,"title":2},"33":{"body":81,"breadcrumbs":4,"title":2},"34":{"body":26,"breadcrumbs":6,"title":3},"35":{"body":40,"breadcrumbs":5,"title":2},"36":{"body":55,"breadcrumbs":5,"title":2},"37":{"body":72,"breadcrumbs":5,"title":2},"38":{"body":61,"breadcrumbs":5,"title":2},"39":{"body":43,"breadcrumbs":4,"title":1},"4":{"body":89,"breadcrumbs":4,"title":2},"40":{"body":89,"breadcrumbs":7,"title":4},"41":{"body":13,"breadcrumbs":4,"title":2},"42":{"body":45,"breadcrumbs":4,"title":2},"43":{"body":40,"breadcrumbs":5,"title":3},"44":{"body":42,"breadcrumbs":5,"title":3},"45":{"body":47,"breadcrumbs":6,"title":4},"46":{"body":36,"breadcrumbs":5,"title":3},"47":{"body":81,"breadcrumbs":2,"title":1},"48":{"body":0,"breadcrumbs":4,"title":3},"49":{"body":61,"breadcrumbs":2,"title":1},"5":{"body":56,"breadcrumbs":5,"title":3},"50":{"body":20,"breadcrumbs":6,"title":5},"51":{"body":213,"breadcrumbs":7,"title":6},"52":{"body":125,"breadcrumbs":5,"title":4},"53":{"body":171,"breadcrumbs":6,"title":5},"54":{"body":167,"breadcrumbs":8,"title":7},"55":{"body":0,"breadcrumbs":9,"title":6},"56":{"body":69,"breadcrumbs":4,"title":1},"57":{"body":28,"breadcrumbs":4,"title":1},"58":{"body":29,"breadcrumbs":5,"title":2},"59":{"body":122,"breadcrumbs":5,"title":2},"6":{"body":55,"breadcrumbs":4,"title":2},"60":{"body":2,"breadcrumbs":4,"title":1},"61":{"body":7,"breadcrumbs":7,"title":5},"62":{"body":44,"breadcrumbs":3,"title":1},"63":{"body":39,"breadcrumbs":3,"title":1},"64":{"body":5,"breadcrumbs":3,"title":1},"65":{"body":35,"breadcrumbs":4,"title":2},"66":{"body":121,"breadcrumbs":6,"title":2},"67":{"body":94,"breadcrumbs":6,"title":2},"68":{"body":114,"breadcrumbs":6,"title":2},"69":{"body":137,"breadcrumbs":6,"title":2},"7":{"body":49,"breadcrumbs":3,"title":1},"70":{"body":230,"breadcrumbs":6,"title":2},"71":{"body":202,"breadcrumbs":6,"title":2},"72":{"body":192,"breadcrumbs":6,"title":2},"73":{"body":67,"breadcrumbs":10,"title":4},"74":{"body":130,"breadcrumbs":10,"title":4},"75":{"body":184,"breadcrumbs":12,"title":6},"76":{"body":191,"breadcrumbs":8,"title":2},"77":{"body":165,"breadcrumbs":7,"title":1},"78":{"body":34,"breadcrumbs":10,"title":4},"79":{"body":72,"breadcrumbs":9,"title":3},"8":{"body":46,"breadcrumbs":6,"title":4},"80":{"body":141,"breadcrumbs":8,"title":2},"81":{"body":126,"breadcrumbs":9,"title":3},"82":{"body":153,"breadcrumbs":9,"title":3},"83":{"body":134,"breadcrumbs":9,"title":3},"84":{"body":13,"breadcrumbs":2,"title":1},"85":{"body":8,"breadcrumbs":2,"title":1},"86":{"body":4,"breadcrumbs":2,"title":1},"87":{"body":57,"breadcrumbs":2,"title":1},"88":{"body":18,"breadcrumbs":2,"title":1},"89":{"body":26,"breadcrumbs":2,"title":1},"9":{"body":45,"breadcrumbs":5,"title":3}},"docs":{"0":{"body":"Prism is a new verifiable authentication standard allowing users to directly verify the authenticity of cryptographic materials (e.g. keys and certificates) without a trusted intermediary . Prism Banner","breadcrumbs":"Introduction » What is Prism?","id":"0","title":"What is Prism?"},"1":{"body":"Every time you browse a website or send an encrypted message, you're trusting that you're connecting to the right place and the right person. Without transparency systems, however, a malicious actor could secretly show you different security credentials than everyone else sees— allowing them to intercept your sensitive data without detection. This \"split-world\" vulnerability affects billions of daily internet interactions, from simply browsing the web to private messaging, making it one of the most fundamental security challenges of the internet. Learn More →","breadcrumbs":"Introduction » Why Prism?","id":"1","title":"Why Prism?"},"10":{"body":"Prism employs three primary node types, each with distinct responsibilities: Prover : A singleton node that generates epoch proofs for operations in the previous Prism block and posts them to a proof namespace on Celestia. Full Nodes : These nodes run all operations posted to Prism blocks, ensuring that the Merkle root is updated according to the application-specific policies, independent of the SNARK contents. Light Nodes : Running on end-user devices, light nodes verify epoch proofs without downloading Prism blocks or single operations, making them efficient for minimal-resource environments.","breadcrumbs":"Prism Quickstart » Prism Node Types","id":"10","title":"Prism Node Types"},"11":{"body":"Prism utilizes the Celestia blockchain because of its unique focus on data availability, a crucial quality for a key transparency solution like Prism. By relying on Celestia, Prism circumvents the need to pay for execution and settlement functionalities typical in monolithic blockchains, optimizing for both efficiency and cost-effectiveness.","breadcrumbs":"Prism Quickstart » Why Celestia?","id":"11","title":"Why Celestia?"},"12":{"body":"Celestia’s innovations enable trust-minimized light clients that can read the blockchain without relying on RPCs. This capability allows Prism to embed WASM light clients into end-user applications, enabling direct access to the common data layer. As a result, split-view attacks on the key directory's root are prevented, while the security of the Celestia network is directly enhanced. This integration with Celestia not only bolsters Prism's scalability and security but also establishes a robust framework for end-to-end encrypted communication systems that rely on a decentralized key directory.","breadcrumbs":"Prism Quickstart » Enhancing Security with Trust-Minimized Light Clients","id":"12","title":"Enhancing Security with Trust-Minimized Light Clients"},"13":{"body":"Prism operates as a sovereign based rollup on the Celestia blockchain. A rollup is a scaling solution for blockchain networks, particularly designed to increase transaction throughput and reduce fees while maintaining the security guarantees of the underlying Layer 1 (L1) blockchain. Unlike traditional rollups, Prism does not rely on the Celestia L1 to validate its blocks - the nodes of the rollup network are responsible for validating them, allowing Prism to take charge of its own settlement. Architecture","breadcrumbs":"Rollup Construction » Prism as a Sovereign Rollup on Celestia","id":"13","title":"Prism as a Sovereign Rollup on Celestia"},"14":{"body":"Prism's block sequencing and ordering are directly determined by Celestia’s validators as they produce blocks on the Celestia chain. This means that Prism transactions and state updates are included within Celestia blocks, ensuring a tight coupling with Celestia’s consensus mechanism. This offers strong security guarantees for Prism, as the state progression is backed by Celestia's validator set, enhancing security by leveraging Celestia’s data availability layer.","breadcrumbs":"Rollup Construction » Block Sequencing in Prism","id":"14","title":"Block Sequencing in Prism"},"15":{"body":"Prism employs three primary node types, each with distinct responsibilities: Sequencer/Prover : A singleton node that generates epoch proofs for operations in the previous Prism block and posts them to a proof namespace on Celestia. Full Nodes : These nodes run all operations posted to Prism blocks, ensuring that the Merkle root is updated according to the application-specific policies, independent of the SNARK contents. Light Nodes : Running on end-user devices, light nodes verify epoch proofs without downloading Prism blocks or single operations, making them efficient for minimal-resource environments.","breadcrumbs":"Rollup Construction » Prism Node Types","id":"15","title":"Prism Node Types"},"16":{"body":"Prism utilizes the Celestia blockchain because of its unique focus on data availability, a crucial quality for a key transparency solution like Prism. By relying on Celestia, Prism circumvents the need to pay for execution and settlement functionalities typical in monolithic blockchains, optimizing for both efficiency and cost-effectiveness.","breadcrumbs":"Rollup Construction » Why Celestia?","id":"16","title":"Why Celestia?"},"17":{"body":"Celestia’s innovations enable trust-minimized light clients that can read the blockchain without relying on RPCs. This capability allows Prism to embed WASM light clients into end-user applications, enabling direct access to the common data layer. As a result, split-view attacks on the key directory's root are prevented, while the security of the Celestia network is directly enhanced. This integration with Celestia not only bolsters Prism's scalability and security but also establishes a robust framework for end-to-end encrypted communication systems that rely on a decentralized key directory.","breadcrumbs":"Rollup Construction » Enhancing Security with Trust-Minimized Light Clients","id":"17","title":"Enhancing Security with Trust-Minimized Light Clients"},"18":{"body":"","breadcrumbs":"Datastructures » Prism Datastructures","id":"18","title":"Prism Datastructures"},"19":{"body":"In Prism, Accounts are the values stored in the leaves of the key directory. /// Represents an account or service on prism, making up the values of our state\n/// tree.\npub struct Account { /// The unique identifier for the account. id: String, /// The transaction nonce for the account. nonce: u64, /// The current set of valid keys for the account. Any of these keys can be /// used to sign transactions. valid_keys: Vec