How does the Blockchain Work? (Part 3)
By: Collin Thompson
Tags: Cryptocurrency, Fintech, Bitcoin, Distributed Ledgers, Blockchain

How does the Blockchain Work? (Part 3)

What is consensus and why does it matter?

The world of Bitcoin and underlying technologies of distributed ledger, and the blockchain are experiencing rapid change and growth.

As low-trust digital-based systems gain adherents and differing use cases, developers are creating new variant blockchains to deal with the inevitable fragmentation between public, consortium and private blockchain technologies.

First, let’s note the differences between public, consortium and private blockchains.

Public — Fully decentralized and uncontrolled networks with no access permission required — anyone can participate in the consensus process to determine which transaction blocks are added. There is usually little or no pre-existing trust between participants in a Public blockchain.

Consortium — The consensus process for new transaction blocks is controlled by a fixed set of nodes, such as a group of financial institutions where pre-existing trust is high.

Private — Access permissions are tightly controlled, with rights to read or modify the blockchain restricted to certain users. Permissions to read the blockchain may be restricted or public. [1]

There is usually some degree of pre-existing trust between at least some of Private blockchain participants.

The degree of pre-existing trust that an organization requires, as well as necessary control over participant permissions, will determine what type of blockchain to use.

Different blockchain solutions have advantages and disadvantages. Take for example, the difference between how transactions are validated within each type of blockchain:

Proof of Work (PoW): About “mining” transactions utilizing a resource-intensive hashing process, which (a) confirms transactions between network participants and (b) writes the confirmed transactions into the blockchain ledger as a new block.

The accepted new block is proof that the work was done, so the miner may receive a 25 BTC (Bitcoins) payment for successfully completing the work. The problem with PoW is that it is resource-intensive and creates a centralizing tendency among miners based on computer resource capability.

Proof of Stake (PoS): About “validating” blocks created by miners and requires users to prove ownership of their “stake”[2]. Validation introduces a randomness into the process, making the establishment of a validation monopoly more difficult, thereby enhancing network security.

One problem with PoS is the “nothing at stake” issue, where miners have nothing to lose in voting for different blockchain histories, preventing a consensus from being created. There are several attempts to solve this problem underway.

Additional developments in this area hope to combine PoW with PoS to create hybrid blockchains with the highest security and lowest resource requirements.

To that end, some developers are focused on enhancing network security through ‘consensus without mining.’ [3]

Tendermint co-founder Jae Kwon has published a paper describing his firm’s concept and approach in this regard.

Existing Proof of Work and Proof of Stake protocols have various problems, such as requiring huge outlays of energy usage and increasing centralization (PoW) or participants having nothing at stake (PoS) possibly contributing to consensus disruption on mined blocks.

Kwon’s solution is twofold and does not require Proof of Work mining:

(a) A ⅔ majority of validators is required to sign off on block submission, with no more than ⅓ able to sign duplicate blocks without penalty

(b) The protocol raises the penalty of double-spend attacks to unacceptably high levels by destroying the malicious actor’s Bitcoin account values.

The algorithm is “based on a modified version of the DLS protocol and is resilient up to ⅓ of Byzantine participants.”

Kwon and his team at Tendermint hope to bring speed, simplicity and security to blockchain app development.

So, how does one decide on what type of blockchain to use and their relevancy for your company use case? [4]

Below are a few examples of different types of blockchains, depending on the organization’s greatest prioritized need:

One consideration is confidentiality. For example, in the case of a public financial blockchain, all the transactions appear on the ledgers of each participant. So while the identities of the transacting parties are not known, the transactions themselves are public.

Some companies are developing ‘supporting’ blockchains to avoid this problem, by “storing or notarizing the contracts in encrypted form, and performing some basic duplicate detection.” Each company would store the transaction data in their own database, but use the blockchain for limited memorialization purposes.

A second consideration is whether you need provenance tracking. Existing supply chains are rife with counterfeit and theft problems. A blockchain that collectively belongs to the supply chain participants can reduce or eliminate breaks in the chain as well as secure the integrity of the database tracking the supply chain.

A third example is the need for recordkeeping between organizations, such as legal or accounting communications. A blockchain that timestamps and provides proof of origin for information submitted to a case archive would provide a way for multiple organizations to jointly manage the archive while keeping it secure from individual attempts to corrupt it.

Blockchains fundamentally operate on the basis of how consensus is agreed upon for each transaction added to the ledger.

What are the benefits of each type of consensus mechanism and in which situation are they best utilized?

Proof of Work — Miners have a financial incentive to process as many transactions as quickly as possible. PoW is best utilized by high-throughput requirement systems.

Proof of Stake — Transaction Validators receive rewards in proportion to the amount of their “stake” in the network. This arguably improves network security by discouraging duplicitous attacks. PoS is best used by computing power constrained organizations.

Delegated Proof of Stake [5] — Network parameters are decided upon by elected delegates or representatives. If you value a “democratized” blockchain with reduced regulatory interference, this version is for you.

PAXOS — An academic and complicated protocol centered around multiple distributed machines reaching agreement on a single value. This protocol has been difficult to implement in real-world conditions.

RAFT — Similar to PAXOS in performance and fault tolerance except that it is “decomposed into relatively independent subproblems”, making it easier to understand and utilize.

Round Robin — Utilizing a randomized approach, the round robin protocol requires each block to be digitally signed by the block-adder, which may be a defined set of participants. This is more suited to a private blockchain network where participants are known to each other.

Federated Consensus — Federated consensus is where each participant knows all of the other participants, and where small sets of parties who trust each other agree on each transaction and over time the transaction is deemed valid. Suitable for systems where decentralized control is not an imperative.

Proprietary Distributed Ledger — A PDL is one where the ledger is controlled, or proprietary, to one central entity or consortium. The benefits of this protocol is that there is already a high degree of pre-existing trust between the network participants and agreed-upon security measures. Suitable for a consortium or group of trading partners, such as supply chains.

PBFT — In a PBFT system, each node publishes a public key and messages are signed by each node, and after enough identical responses the transaction is deemed valid. PBFT is better suited for digital assets which require low latency due to high transaction volume but do not need large throughput.

N2N — Node to node (N2N) systems are characterized by encrypted transactions where only the parties involved in a transaction have access to the data. Third parties such as regulators may have opt-in privileges. Suitable for use cases where a high degree of transaction confidentiality is required.

The above list represents the current major consensus mechanisms in operation or from research.

Due to the initial visibility of Bitcoin, the financial services industry has been early in researching the possible uses of consensus mechanisms to streamline operations, reduce costs and eliminate fraudulent activity.

The multi-trillion dollar global financial services industry is really composed of many different sectors, from lending to smart contracts, trading execution, letters of credit, insurance, payments, asset registration, regulatory reporting and more.

For example, the process of securing a letter of credit, which is an important import/export trading service, would likely utilize a ‘consortium’ approach to achieving transaction consensus.

In August, 2016 a banking consortium, R3CEV, successfully designed and executed trading smart contracts. These types of contracts could then be applicable to accounts receivable invoice factoring and letter of credit transactions.

For the use case example of cross border remittances, which would involve many individuals on both sides of the transaction, a ‘public’ consensus mechanism would likely be a relevant choice.

Since remittances would need to have a relatively short time latency for transaction completion, a solution involving a Proof of Stake approach with its low resource requirement to validate transactions along with potentially higher security, would be compelling.

In sum, the state of blockchain development is rapidly gaining speed worldwide, yet there is much work to be done.

Numerous Global 2000 companies led by their technology executives and consultants are beginning to participate in development and testing of this revolutionary technology sector.

Organizations that begin first-hand learning about the power of blockchain technologies will have increased opportunity to lead their industry.