Page 55 - FIGI: Security Aspects of Distributed Ledger Technologies

Annex A Consensus protocols in use in various DLT types� 388

Exhibit 2: Consensus protocols in use in various DLT types. 389

Access Type Mechanism Examples
Miners compete to find a numeric solution (a ‘nonce’) 391 to a math-
ematical question concerning hashing, 392 earns the right to add a
Proof of Work block of validated transactions to the blockchain and a reward for Bitcoin, Ethereum,
Public 393 394 Zcash, Monero,
(POW) 390 an amount of native currency. The energy expenditure to per- SiaCoin
form the ‘work’ is substantial and intentional by design 395 to disin-
centivizs 396 bad acts.
Designed to be a more energy efficient than POW. 398 POS gener-
ates consensus using an algorithm that is based upon the owner-
Proof of Stake Tendermint, Ethe-
Public ship of native crypto-currency in relation to others in the system
(POS) 397 along with some weighting mechanism such as how long the cur- reum (W/P)
rency has been held by the stakeholder. 399 Also known as staking. 400
Variation of POS. Token holders vote for a certain number of del-
Delegated egates called ‘Witnesses,’ who are given the authority to validate
Public Proof of Stake transactions and blocks. Stakeholders such as coin holders have Lisk
(dPOS) weighted votes 401 on electing the witnesses who can validate
transactions and add blocks. 402
A lottery system used in permissioned blockchain networks to
decide the mining rights or the block winners on the network
Proof of using. Every participant in the network is assigned a random Hyperledger Saw-
Private Elapsed Time amount of time to wait, and the first participant to finish waiting tooth
(PoET)
gets to commit the next block to the blockchain. 403 All nodes are
equally likely to be a winner.
For private (mostly enterprise consortiums) or permissioned DLTs
and blockchains which may not have as many participants in its Hyperledg-
Practical Byz- walled garden as compared to openly accessible public, per- er Fabric (FT),
antine Fault missionless blockchains. 404 It is suited to enterprise consortiums Hyperledger Indy
Private
Tolerance where members are partially trusted. These are important because (RBFT), Hyper-
(PBFT) malicious attacks and software errors are increasingly common ledger Iroha (Sum-
and can cause faulty nodes to exhibit arbitrary behavior (Bizan- eragi)
tine faults). 405
Ripple consensus algorithm proceeds in rounds. In each round,
four steps occur. Initially, each server takes all valid transactions
it has seen prior to beginning of consensus round that have not
already been applied. It is declared to be public in the form of a Ripple Payment
Federated Ripple Consen- list known as ‘candidate set.’ The server has the responsibility to System and Cryp-
sus Algorithm combine the candidate set of all servers on its UNL. It then votes 407
for the transaction with “yes” or “no” votes after verifying its trans- to-currency.
actions. Receiving a minimum percent of yes votes is considered
to be the criteria to move into the next round, usually 50%. Uses
the DLS Protocol 406 as of BFT.
To add data to a blockchain, so-called consensus mechanisms have evolved that require a miner (validator) to prove that
they have undertaken the task of being able to add the blockchain to the chain. Bitcoin and Ethereum (for now) uses proof
of work (POW), while proof of stake (POS) has evolved to solve inter alia the power consumption issues in POW as well as
scaling 408 issues. Ethereum’s Constantinople’ upgrade is designed to use POS. 409

Security Aspects of Distributed Ledger Technologies 53