Blockchain across Oracle
上QQ阅读APP看书,第一时间看更新

Lightweight consensus mechanisms

In a business environment, where trust between participants is high or at least partially present, you can come across one of the following more lightweight consensus methods. One of the most well-known consensus mechanisms, besides PoW and (delegated) PoS, is the practical byzantine fault tolerance (PBFT) method. It is used by many enterprise blockchain providers.

The difference between the previously-discussed sophisticated methods and PBFT is that this protocol is much more lightweight, since it does not require nodes to perform computations in order to create and verify blocks of transactions. With PBFT, every peer in the network maintains its own internal state, or their view on the current plan of actions. Transactions that are submitted to the network reach the validating peers at different times, so the order of transactions received doesn't have to be the same. In a given time period, peers that are fully in sync vote for a validating leader who chooses the sequence of transactions. The other peers use this sequence, in conjunction with their internal state, to perform a computation until they have the same sequence and consensus.

The following diagram shows you visually how this consensus mechanism works:

With PBFT, each peer might receive the same transactions in a different order, but broadcast their sequence to all other peers in order for validating peers to vote regarding the correct order

With PBFT, a consensus is reached based on the total number of decisions submitted by all peers. The consensus does not operate on the principle requiring that the majority of peers agree on a single decision submitted by a validating peer, but every decision that is sent. For every block, one of the validating pears is chosen as the leader, which will ultimately decide the final order of the transactions. So, if participant A sends one result sequence to participant B, and a different result sequence to participant C, then participant C would send this different result to participant B, who concludes that participant A has sent two different sequences. I will discuss the PBFT in more detail in Chapter 4, Blockchain 101 - Blocks, Chains, and Consensus.

Another similar consensus mechanism is the federated Byzantine agreement (FBA). It assumes that participants in a network know each other, and they can distinguish which participants are important to them and which are not. In contrast to PBFT, instead of listening to all votes coming in for a certain sequence, a validating peer waits for the majority of the nodes it considers to be important to agree on a transaction before it agrees to the transaction. The same goes for the other validating peers in the network. A transaction is considered verified once enough peers considered important by enough nodes have agreed on its legality.

Another up-and-coming consensus mechanism is called the Tangle protocol. It works a bit differently than the ones I have explained up until now, and it is not considered a blockchain. When you submit a transaction with the Tangle protocol, it is confirmed by the network if and when two other peers in the network have proofed your transaction. Therefore, it is different from the others since, at any given time, no single node helps maintain the entire ledger. Each node helps by adding or editing two transactions at a time. The protocol also stores the transactions on a directed acyclic graph (DAG) (https://en.wikipedia.org/wiki/Directed_acyclic_graph) rather than on a linked list. In short, a DAG is a graph without a directed cycle, such that there is no way to start at any vertex v and follow a consistently-directed sequence of edges that eventually loops back to v again, as shown in the following diagram:

Transactions connected into a DAG. Arrows are drawn from the child to the parent. G is the genesis transaction.

The Tangle protocol does not know the concept of miners either. Since each edge holds only one transaction, other users can easily perform validation and PoW. Thus, there are no fees or rewards for confirming transactions in the ledger, but in order to submit your own transaction, you need to proof two other transactions first.