Blockchain Technology
BITS Pilani Dr. Amitesh Singh Rajput
Pilani Campus
Computer Science & Information Systems
Consensus Mechanisms
• An agreement that multiple parties agree on.
• A renewed interest has arisen in developing distributed
consensus algorithms that are suitable for blockchain networks.
BITS Pilani, Pilani Campus
Categorization
Traditional distributed systems (applicable to private blockchain)
1. Paxos
2. Raft
3. PBFT
BITS Pilani, Pilani Campus
Categorization
Specifically designed for public blockchain networks
1. Proof of Work (PoW)
2. Proof of Stake (PoS)
3. Proof of Burn (PoB)
4. Proof of Activity (PoA)
5. Proof of Elapsed Time (PoET)
BITS Pilani, Pilani Campus
Two major properties
• A consensus algorithm must be able to satisfy the safety and
liveness properties.
• Three properties of Safety
➢ Agreement: No two processes decide on different values.
➢ Validity: The decided value should always be proposed by
an honest process and has not been created out of thin air.
➢ Integrity: A process must decide only once.
BITS Pilani, Pilani Campus
Two major properties
• Liveness: The protocol should make progress even if the
network conditions are not ideal.
➢ Termination: Each honest node must eventually decide on a
value.
BITS Pilani, Pilani Campus
BITS Pilani
Pilani Campus
Private Blockchain Consensus
Paxos
• Developed by Leslie Lamport.
• Used to build a reliable system that works correctly, even in the
presence of faults.
• Assumes an asynchronous message-passing network.
• Majority-based acceptance of the proposals instead of expecting
all nodes to agree.
BITS Pilani, Pilani Campus
Paxos
➢ Proposers
➢ Acceptors Roles
➢ Learners
• Five parties A, B, C, D, and E planning to go to a restaurant.
• A to C, D, and E Two votes are secured
• B to C, D, and E One vote is secured
BITS Pilani, Pilani Campus
Paxos
BITS Pilani, Pilani Campus
Paxos
1. Proposer broadcasts the message <prepare(n)> to all acceptors.
2. Acceptor responds if proposal n is the highest that it has
responded so far.
Acknowledgement message = <ack(n,v,s)>
n = proposal number
v = value of highest numbered proposal acceptor has accepted
s = seq. no. of the highest accepted proposal
BITS Pilani, Pilani Campus
Paxos
3. If majority acknowledgements are received, the proposer sends
the “accept” message <accept(n,v)> to the acceptors.
4. If majority of the acceptors accept the proposed value, then the
agreement is achieved.
5. Finally, in the learning phase, the acceptors broadcast the
“accepted” message. This phase is necessary to disseminate
which proposal has been finally accepted.
BITS Pilani, Pilani Campus
Raft
• Concept of having a leader.
• Node starts up -> Leader election -> Log replication
• Leader is always assumed honest.
BITS Pilani, Pilani Campus
Raft
Procedure
1. First the node starts up.
2. Leader election process starts. All changes go through the leader
then.
3. Each change is entered in the nodes log.
4. Log entry remains uncommitted until the entry is replicated to
follower nodes.
5. Once the leader receives the confirmation from majority of nodes
then it is committed locally.
BITS Pilani, Pilani Campus
Raft
6. The leader notifies the followers regarding the committed entry.
7. Once this process ends, agreement is achieved.
BITS Pilani, Pilani Campus
Raft
Log replication
BITS Pilani, Pilani Campus
Byzantine Generals Problem
• Attacking a fort with separate team of generals.
• Every general has a preference about whether to attack or retreat.
• It has to be a coordinated attack or retreat to incur minimum loss.
BITS Pilani, Pilani Campus
Practical Byzantine Fault Tolerance
• 2F + 1 rule to commit a change.
• Ensures fault tolerance as long as the number of nodes in a
system stays N > 3F + 1.
❑ Work in rounds.
❑ In each round an elected leader node (primary node) handles the
communication with the client.
❑ Participants are called replicas. One of the replicas becomes
primary in each round and the rest act as backup.
BITS Pilani, Pilani Campus
Practical Byzantine Fault Tolerance
Pre-prepare phase:
• Client request is sent to backups through primary (with a sequence
number).
Prepare phase:
• Participants accept the pre-prepare message, checks the message,
and sends the prepare message to all other replicas.
BITS Pilani, Pilani Campus
Practical Byzantine Fault Tolerance
Commit phase:
• The replica waits for 2F prepare messages with the same
sequence no and request.
• Sends a commit message to all replicas.
• Waits until 2F+1 valid commit messages arrive and is accepted.
• Executes the received request.
• Sends a reply with execution result to the client.
BITS Pilani, Pilani Campus
Practical Byzantine Fault Tolerance
BITS Pilani, Pilani Campus
BITS Pilani
Pilani Campus
Public Blockchain Consensus
Proof-of-Work (PoW)
• Nodes compete to propose a block
• Resource intensive
BITS Pilani, Pilani Campus
Proof-of-Stake (PoS)
• No competition as of mining
• Validators explicitly stake capital in the form of cryptocurrency into
the network.
• A validator is responsible for:
➢ Checking that new blocks propagated over the network are
valid
➢ Occasionally creating and propagating new blocks
BITS Pilani, Pilani Campus
Proof-of-Stake (PoS)
- To participate as a validator
• A user must deposit 32 ETH into the deposit contract.
• Run three separate pieces of software:
➢ An execution client
➢ A consensus client
➢ A validator
BITS Pilani, Pilani Campus
Proof-of-Stake (PoS)
- Validator Client
• Once activated, the validator receives new blocks from peers.
• The transactions delivered in the block are re-executed to:
➢ Check that the proposed changes to Ethereum's state are valid
➢ The block signature is checked
The validator then sends a vote (called an attestation) in favor of
that block across the network.
BITS Pilani, Pilani Campus
Proof-of-Stake (PoS)
- Execution and Consensus Client
Transaction execution in Ethereum
1. A user creates and signs a transaction with its private key.
➢ A tip (amount of gas) to a validator to encourage them to
include the transaction in a block is also included.
2. The transaction is submitted to an Ethereum execution client
which verifies its validity.
➢ Ensuring that the sender has enough ETH to fulfill the
transaction and they have signed it with the correct key.
BITS Pilani, Pilani Campus
Proof-of-Stake (PoS)
- Execution and Consensus Client
3. If the transaction is valid, the execution client adds it to its local
mempool.
➢ Also broadcasts it to other nodes over the execution layer
gossip network.
➢ Other nodes add the transaction to their local mempool too.
BITS Pilani, Pilani Campus
Proof-of-Stake (PoS)
- Execution and Consensus Client
Adding a block
4. One of the nodes, block proposer, is made up of below parts:
➢ Execution client: Bundles transactions from the local
mempool into an execution payload and executes them locally
to generate a state change.
➢ Consensus client: Execution payload is wrapped as part of a
beacon block that also contains information about rewards,
penalties, slashings, attestations etc.
BITS Pilani, Pilani Campus
Proof-of-Stake (PoS)
- Execution and Consensus Client
Adding a block
5. When other nodes receive the new beacon block, they
➢ Pass it to their execution client where the transactions are re-
executed locally to ensure the proposed state change is valid.
➢ The validator client then attests that the block is valid and is the
logical next block in their view of the chain.
➢ The block is added to the local database in each node that
attests to it.
BITS Pilani, Pilani Campus
Proof-of-Stake (PoS)
Choosing a validator
Randomized Block Selection
• Selects node with the highest stake value and lowest hash
value.
Coin Age Selection
• Selects node with number of coins stacked ⨯ number of days
stacked.
BITS Pilani, Pilani Campus
Proof-of-Stake (PoS)
- Variants
Chain-based PoS
• Very similar to PoW.
• Block is generated in below two steps:
1. Transactions are picked from mempool to form a block.
2. A clock is setup with a constant time interval (known as tick). At
each tick, the following condition is checked to add a block:
𝐻𝑎𝑠ℎ 𝐵 𝑐𝑙𝑜𝑐𝑘 𝑡𝑖𝑚𝑒 < 𝑡𝑎𝑟𝑔𝑒𝑡 × 𝑠𝑡𝑎𝑘𝑒 𝑣𝑎𝑙𝑢𝑒
BITS Pilani, Pilani Campus
Proof-of-Stake (PoS)
- Variants
Committee-based PoS
• A group of stakeholders is chosen using a verifiable random function
(VRF).
• The VRF produces a random set of stakeholders based on their
stake and current blockchain state.
• The chosen group of stakeholders becomes responsible for
proposing blocks in sequential order.
BITS Pilani, Pilani Campus
Proof-of-Stake (PoS)
- Variants
Delegated PoS
• Very similar to committee-based PoS.
• Instead of using a random function to select stakeholders, the group
is formed by stake delegation.
• A fixed no. of verifiers are selected that create blocks in RR fashion.
• Delegates are chosen via voting by network users.
• Votes are proportional to the amount of the participants stake in the
network.
BITS Pilani, Pilani Campus
BITS Pilani
Pilani Campus
Thank You!
