From Traditional Fault Tolerance to Blockchain. Wenbing Zhao
Читать онлайн книгу.
and the other with a single sender of broadcast messages.
5.3 An example rotation sequencer based system in normal operation.
5.4 Normal operation of the membership view change protocol.
5.5 Membership change scenario: competing originators.
5.6 Membership change scenario: premature timeout.
5.7 Membership change scenario: temporary network partitioning.
5.8 A simplified finite state machine specification for Totem.
5.9 A successful run of the Totem Membership Protocol.
5.10 Membership changes due to a premature timeout by N2.
5.11 Messages sent before N1 fails in an example scenario.
5.12 Messages delivered during recovery for the example scenario.
5.13 Message sent before the network partitions into two groups, one with {N1, N2}, and the other with {N3, N4, N5}.
5.14 Messages delivered during recovery in the two different partitions for the example scenario.
5.15 Causal ordering using vector clocks.
6.1 Normal operation of the Paxos algorithm.
6.2 A deadlock scenario with two competing proposers in the Paxos algorithm.
6.3 If the system has already chosen a value, the safety property for consensus would hold even without the promise-not-to-accept-older-proposal requirement.
6.4 If two competing proposers propose concurrently, the system might end up choosing two different values without the promise-not-to-accept-older-proposal requirement.
6.5 With the promise-not-to-accept-older-proposal requirement in place, even if two competing proposers propose concurrently, only a single value may be chosen by the system.
6.6 Normal operation of Multi-Paxos in a client-server system with 3 server replicas and a single client.
6.7 View change algorithm for Multi-Paxos.
6.8 With reconfigurations, a group of 7 replicas (initially 5 active and 2 spare replicas) can tolerate up to 5 single faults (without reconfigurations, only up to 3 faults can be tolerated).
6.9 The Primary and secondary quorums formation for a system with 3 main replicas and 2 auxiliary replicas.
6.10 The Primary and secondary quorums formation as the system reconfigures due to the failures of main replicas.
6.11 Normal operation of Cheap Paxos in a system with 3 main replicas and 1 auxiliary replica.
6.12 The Primary and secondary quorums formation for a system with 3 main replicas and 2 auxiliary replicas.
6.13 Normal operation of (Multi-) Fast Paxos in a client-server system.
6.14 Collision recovery in an example system.
6.15 Expansion of the membership by adding two replicas in method 1.
6.16 Expansion of the membership by adding two replicas in method 2.
6.17 Reduction of the membership by removing two replicas one after another.
7.1 Two scenarios that highlight why it is impossible to use 3 generals to solve the Byzantine generals problem.
7.2 The message flow and the basic steps of the OM(1) algorithms. 252
7.3 The message flow and the basic steps of the OM(2) algorithms. 254
7.4 Normal operation of the PBFT algorithm.
7.5 PBFT view change protocol.
7.6 A worst case scenario for tentative execution.
7.7 Normal operation of Fast Byzantine fault tolerance.
7.8 Zyzzyva agreement protocol (case 1).
7.9 Zyzzyva agreement protocol (case 2).
7.10 A corner case in view change in Zyzzyva.
8.1 Bitcoin nodes.
8.2 The relationship between private key, public key, and address in Bitcoin.
8.3 Bitcoin transaction structure.
8.4 An example transaction chain in Bitcoin.
8.5 Bitcoin transactions per block data since its inception in 2009 through September 15, 2020. The data are downloaded from https://www.blockchain.com/charts/n-transactions-per-block.
8.6 Bitcoin block structure.
8.7 An issue with Bitcoin Merkle tree computation where different trees could produce the same Merkle root.
8.8 Bitcoin blockchain consensus and conflict resolution.
8.9 Structure of Ethereum transaction.
8.10 State transition via transaction in Bitcoin and Ethereum.
8.11 Ethereum smart contract structure.
8.12 An example transaction receipt in the JSON format. The content is color-coded. The yellow blocks are identifier information for the transaction, the contract invoked, and the block in which the transaction reside. The blue block contains the cumulative gas used. The green block contains the logs. The red block contains the logs Bloom filter string. The purple block contains the status of the transaction (success or not). The pink block contains the gas used for this transaction alone.
8.13 Ethereum block structure.
8.14 The annotated source code on verification of an ommer block.
8.15 An example on what kind of stale blocks may be chosen as an ommer block.
8.16 The annotated source code on the block reward scheme in Ethereum.
8.17 The cache size vs. the epoch number.
8.18 The dataset size vs. the epoch number.
8.19 The Ethash algorithm.
8.20 The double-spending attack steps.
9.1 A model for public blockchain consensus.
9.2 Main loop used by a mining node to compete in the creation of a new block using PoS in PeerCoin.
9.3 Major steps in the CreateNewBlock function in PeerCoin PoS.
9.4 Major steps in the CreateCoinStake function in PeerCoin PoS.
9.5 Major steps in the CheckStakeKernelHash function in PeerCoin PoS.
9.6 Information included in the data stream for computing PoS hash.
9.7 Major steps in PoET consensus.
10.1 Main benefits of blockchain for applications.
10.2 A model for cyber-physical systems.
10.3 Blockchain-enabled CPS applications.
10.4 Key operations and their relationship with the CPS applications and the blockchain benefits.
10.5 Basic CPS operations with respect to the latency and throughput requirements.
10.6 Stale block rate for different block sizes and block intervals.
10.7 Throughput for different combinations of block sizes and block intervals.
10.8 Payment channel operation.
10.9 Two level logging for sensing data with blockchain.
10.10 The format for the raw data (together with the aggregated data tuple) for local logging.
10.11 Summary of the token paradigm.
10.12