This handbook is a collection of three short articles written for the Auth0 Blog1. The first of thesearticles2focuses on the concept of blockchain, a decentralized, verifiable, and ordered database ofoperations. To get a better sense of how blockchains operate, the first article explores Bitcoin, thefirst popular and successful implementation of a blockchain.The second article3explores Ethereum, a different blockchain implementation focused on decentralized applications. At the end of the article an example of a decentralized application is presented.This example attempts to explore how a decentralized authentication solution for Ethereum userscould be implemented. It also details many of its shortcomings and mentions that a better alternative will be presented in the next article.Finally, the third article4 presents the work of GFT’s Innovation Team on creating a practicalauthentication solution for Ethereum users with high-value accounts. The article shows howblockchain technologies can be integrated into classical projects, and explores some of the intricacies of blockchains applied to decentralized applications. The solution presented in this articlesolves many of the problems presented in the second article.This handbook is targeted at people wanting to learn more about blockchain technologies, makinga strong emphasis on practical applications of Ethereum. It is intended for technical and nontechnical minds alike. Some of the articles included in this handbook originally used videos to showcertain things. These videos are available online and it is recommended that you watch them asyou find them while reading.
An interesting aspect of contracts being able to store data is how that can be handled in an efficient way. If state is mutated by contracts, and the nature of the blockchain ensures that state is always consistent across all nodes, then all nodes must have access to the whole state stored in the blockchain. Since the size of this storage in unlimited in principle, this raises questions with regards to how to handle this effectively as the network scales. In particular, how can smaller and less powerful nodes make use of the Ethereum network if they cant store the whole state? How can they perform computations? To solve this, Ethereum makes use of something called Merkle Patricia Trees10.
id: 0958669f59430aa87749573698726d0f - page: 34
A Merkle Patricia Tree is a special kind of data structure that can store cryptographically authenticated data in the form of keys and values. A Merkle Patricia Tree with a certain group of keys and values can only be constructed in a single way. In other words, given the same set of keys and values, two Merkle Patricia Trees constructed independently will result in the same structure bit-by-bit. A special property of Merkle Patricia Trees is that the hash of the root node (the first node in the tree) depends on the hashes of all sub-nodes. This means that any change to the tree results in a completely different root hash value. Changes to a leaf node cause all hashes leading
id: 56bd7f2d07541f40b6a17551f6b10c3b - page: 34
8 9 10 32 to the root hash through that and sister branches to be recomputed. What we have described is in fact the Merkle part of the tree, the Patricia part comes from the way keys are located in the tree. Patricia trees are tries11 where any node that is an only child is merged with its parent. They are also known as radix trees or compact prefix trees. A trie is a tree structure that uses prefixes of the keys to decide where to put each node. The Merkle Patricia Trees implemented in Ethereum have other optimizations that overcome inefficiencies inherent to the simple description presented here.
id: d7b76a16e98cf5d191a9759d6140ce18 - page: 34
Figure 2.3: Simplified Merkle Patricia Tree For our purposes, the Merkle aspect of the trees is what matters in Ethereum. Rather than keeping the whole tree inside a block, the hash of its root node is embedded in the block. If some malicious node were to tamper with the state of the blockchain, it would become evident as soon as other nodes computed the hash of the root node using the tampered data. The resulting hash would simply not match with the one recorded in the block. At this point we should find ourselves asking a big question: why not simply take the hash of the data? Merkle Patricia Trees are used in 11 33
id: f37f681d60344e3f2c7ad1cafbae5e32 - page: 35