Immutes all the historical blocks. MerkleRoot is the merkle root over the transaction list. • Immutes the current transaction list. Bitcoin Blockchain – Immutability (I) HashPrevBlock MerkleRoot ................................ ... ................................ ... Block Header
(leaves) and paires and hashes results until a merkle root remains. A merkle tree gives granularity in transaction validation; lite clients can validate entire blocks, transaction groups, or just single transactions with partial merkle branches only. Bitcoin Blockchain – Immutability (II) #1 #2 #3 #4 #5 #6 #7 #8 78 #56 #34 #12 #1234 #5678 #12345678 tx1 tx2 tx3 tx4 tx5 tx6 tx7 tx8
Agreement: All non-faulty processes must agree on the same value. Consensus Problem (all processes have an initial value) Agreement: All non-faulty processes must agree on the same (single) value. These problems are equivalent to one another!
FaultyProcess Fischer & Lynch & Paterson, JACM 1985 The consensus problem involves an asynchronous system of processes, some of which may beunreliable. The problem is for the reliable processes to agree on a binary value. In this paper, it is shown that every protocol for this problem has the possibility of nontermination, even with only one faulty process. By way of contrast, solutions are known for the synchronous case, the “Byzantine Generals”problem.
Liskov, OSDI 1999 This paper presents a new, practical algorithm for state machine replication that tolerates Byzantine faults. The algorithm offers both liveness and safetyprovided at most out of a total of replicas are simultaneously faulty. The algorithm works in asynchronous systems like the Internet and it incorporates important optimizations that enable it to perform efficiently
System Satoshi Nakamoto, 2008 ... The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof ... that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers.
hash. Nonce has to be guessed to achieve that. This guessing is compute intensiv, so it is a proof of work. Difficulty Nonce ................................ ... ................................ ... Block Header
There are rules to direct the race towards the longest chain. Finally, proof of work inhibits double spending of (U)TXOs. Difficulty Nonce ................................ ... ................................ ... Block Header
a form of "virtual mining“ ... Whereas proof of work relies on computer hardware as the primary form of scarcity to prevent Sybil attacks, proof of stake relies on coins inside of the blockchain itself. In proof of work, a user might take $1000, use it to buy a mining computer, plug it in and start participating in the network and producing blocks and getting rewards, in proof of stake, one could take $1000, convert it into $1000 worth of coins, then deposit the coins into the proof of stake mechanism, which would (pseudo-)randomly assign the owner the right to produce blocks and get rewards. https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ
as follows. There exists some set of coin holders that place their coins into a proof of stake mechanism and thereby become validators. Given a particular blockchain "head" (ie. the latest block in a blockchain), the algorithm randomly selects one of these validators (the randomness being weighted by deposit size, so a validator with 10000 coins has 10x the chance of a validator with 1000 coins) and assigns to them the right to create the next block. If that validator does not create a block within some period of time, then a secondary validator is selected that can create the block instead. Just like in proof of work, the "longest chain" is considered to be the canonical one. https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ