Narayan Prusty [Narayan Prusty] - Blockchain for Enterprise

Ethereum is the most popular DApp after Bitcoin. Ethereum is a decentralized platform that allows us to build other blockchain-based DApps on top of it. In Ethereum, we build DApps using Ethereum smart contracts. Smart contracts are applications that run exactly as programmed without any possibility of downtime, censorship, fraud, or third-party interference. Ethereum can be thought of as a platform to deploy and run smart contracts. Ethereum supports two consensus protocols, PoW and PoA (Clique).

The main public Ethereum network uses PoW for consensus. If you want to deploy your own private Ethereum network, then you have to use PoA. PoW requires a lot of computation power to keep the blockchain secure, therefore it's good for public blockchain use, whereas PoA doesn't have any such computation power requirement; instead it requires a few authority nodes in the network to achieve consensus.

• Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals

• Improve your learning with Skill Plans built especially for you

• Get a free eBook or video every month

• Mapt is fully searchable

• Copy and paste, print, and bookmark content

Let's see how the IBFT consensus protocol works at a level that will make us comfortable enough to build DApps. We won't go in depth into IBFT as it's not necessary.

IBFT is a type of proof-of-authority protocol. In IBFT, there are two kinds of nodes: validator nodes ( referred to as authorities when they are linked to physical entities ) and regular nodes. Authority nodes are the ones that create blocks. IBFT is used in a network where there is a need for BFT, blocktime up to a few seconds is good enough, and we need a single confirmation (the absence of regular forks).

The system can tolerate at most F Byzantium or crashed nodes in a N validator nodes network that is, F = (N-1)/3 . The default block time in IBFT is between one to ten seconds and Quorum does allow you to customize this.

In IBFT, a round involves creating and committing a new block to the blockchain. A new round is started once a new block is committed in the (2F + 1) validators blockchain. Before each block creation round, the validators will pick one of them as the proposer. The proposer is the validator responsible for creating the block. For the block to be committed to the blockchain, it must be signed by at least (2F + 1) validators. So, there is a process which involves sending and receiving various messages between the purposer and other validators at each round to agree to the new block.

There are two algorithms supported by Quorum for selection of the purposer: round robin and sticky purposer. Round robin is used by default, and in round robin algorithms the purposer is selected in round robin fashion. But, in the sticky purposer algorithm, a single validator becomes the purposer for all rounds, and if the purposer crashes then the next validator is selected as the new purposer, which again remains the sole purposer for all rounds; the purposer remains constant until it fails. Regardless of the round robin or sticky purposer algorithm, if the purposer fails to commit a block in 1-10 seconds time, then a new round is started and the next validator becomes the purposer of the new round.

If the network manages to have more than F faulty nodes, then these faulty nodes can prevent creation of new blocks by declining to sign blocks. When a crashed node in the network comes up, it can get missed blocks from any node in the network. There is no way more than F faulty nodes can rewrite blocks.

The list of validators is stored in the header of genesis blocks, and the extraData field in the header contains the list of validators. For the first round, the first validator is selected. The header also contains various other fields and details related to IBFT to help the network reach consensus.

A validator can add or remove a validator. Even adding or removing new validators to the network requires 2F + 1 validators agreeing to it. This process of validators agreeing or disagreeing to adding or removing a validator is done manually. It cannot be an automatic process as validators can start adding multiple validating nodes of their own and compromise the network. Therefore, a manual process makes sure that other validators learn who the new validator is and decide whether to allow it or not.

It is time to delve more deeply into contracts. Let's start with some new features and then we will go deeper into the features we have already seen.