Blockchain and Its Architecture(BCS-063)

Unit 2

-by Assist prof . Sandeep Mukherji

Distributed Consensus:
If there is no failure, it is easy and trivial to reach in a consensus Broadcast the personal
Choice to all Apply a choice function, say the maximum of all the values.

Different Types of distributed Consensus Fault:

Consensus mechanism permissioned Blockchain

Three general Byzantine Algorithm:

 —The sequence number is within a threshold
RequestPre-t prepare Prepare

52
S2

2) Prepare:
—Replicas agree on the assigned sequence number

•If the backup accepts the PRE-PREPARE message, it enters prepare phase by
multicasting a message (P, v, n, d, i )+ð_ii to all other replicas
•A replica (both primary and backups) accepts prepare messages if
—Signatures are correct
—View number equals to the current view
—Sequence number is within a threshold
•Pre-prepare and prepare ensure that non-faulty replicas guarantee on a total order for
the requests within a view
3) Commit
To commit a message if
—2f prepares from different backups matches with the corresponding pre-prepare
— You have total 2f + 1 votes (one from primary )from the non-faulty replicas
•Why do you require 3f + 1 replicas to ensure safety in an asynchronous system
when there are f faulty nodes?
—If you have 2f+ 1 replicas, you need all the votes to decide the majority - boils
down to a synchronous system
—You may not receive votes from certain replicas due to delay, in case of an
asynchronous system
—f + 1 votes do not ensure majority, may be you have received f votes from
Byzantine nodes, and just one vote from a non-faulty node (note Byzantine nodes
can vote for or against )
—If you do not receive a vote
•The node is faulty and not forwarded a vote at all
•The node is non-faulty, forwarded a vote, but the vote got delayed
—Majority can be decided once 2f + 1 votes have arrived - even if f are faulty, you
know f + 1 are from correct nodes, do not care about the remaining f votes
• Multicast COMMIT, vv, nn, dd, ii >oo_ii message to all the replicas
including primary
•Commit a message when a replica
— Has sent a commit message itself
— Has received 2f + 1 commits (including its own)

Reply
5Request
2 . Pre- prepare I Prepare
 Scalability Aspects in BlockChain
SCALABILITY ASPECTS
1.Permissionless Dynamic participation and Self
Healing
2. Resilience to faults (benign and malicious)
3. Incentive alignment inclusiveness
4. Predictability
Blockchain Scalability: Execution, Storage, and Consensus

Blockchain scalability is the ability of a blockchain to process transactions,

store data, and reach consensus as additional users are added to the network.
• Trust minimization is a valuable security property that blockchain
technology is uniquely positioned to generate—replacing handshakes,
brand reputation, and paper contracts with guarantees based on computer
code, cryptography, and decentralized consensus. These superior
guarantees provided by blockchains form the basis of cryptographic truth
• With the ultimate goal of unlocking blockchain technology for all users and
use cases, scalability is at the forefront of blockchain research and
development as a key element in smart contracts becoming the preferred
backend of major industries such as finance, supply chain, gaming, and
beyond. The following post provides an overview of blockchain scalability,
focusing on how blockchains differ from traditional computing before
outlining the advantages and tradeoffs of different approaches to scaling
the execution, storage, and consensus layers of blockchains.
Blockchains vs. Traditional Computing

• Before discussing how to scale blockchains, it’s important to

first understand why blockchain computing is fundamentally
different from traditional computing. In general, blockchains
are valuable for three reasons:
• Deterministic computation—predefined coded logic
executes exactly as written with a very high level of certainty.
• Credible neutrality—there is no central administrator
and no special network privileges, meaning anyone can submit
transactions without fear of censorship or discrimination.
• End-user verification—the historical and current state of
the block chain's ledger and the code underpinning the client
software are auditable by anyone in the world.
 Three Key Properties of Blockchain
Scaling
• Blockchain scaling can be broken down into three general
categories: execution, storage, and consensus:-
• Blockchain Execution
• Blockchain execution is the computation required to execute
transactions and perform state changes. Transaction execution
involves checking the validity of transactions (e.g. verifying
signatures and token balances) and executing the on-chain logic
needed to calculate state changes. State changes are when full
nodes update their copy of the ledger to reflect new token
transfers, smart contract code updates, and data storage..
• When scaling the execution layer, the main problem to solve is
how to achieve more computations per second without
substantially increasing the hardware requirements on individual
full nodes that validate the transactions in blocks.
 Blockchain Storage
• Blockchain storage refers to the storage requirements of full nodes, which
maintain and store a copy of the ledger. Blockchains have two general
forms of storage:
• Historical data encompasses all the raw transactions and block data.
Transaction data includes the origin and destination addresses, the amount
sent, and the signature of every individual transaction. Block data includes
the list of transactions and metadata from a specific block, such as its
Merkle root, nonce, previous block hash, etc. Historical data doesn’t
typically require quick access, and there only needs to be at least one
honest entity making it available for download.
• Global state is a snapshot of all the data that smart contracts can read
from or write to, such as account balances and the variables within all
smart contracts. Global state can be generally thought of as the database
of a blockchain, which is required to validate incoming transactions. State is
commonly stored within tree structures (e.g. Merkle trees) where access
and modifications can be easily and quickly made by a full node.
• Full nodes need access to historical data in order to sync to the
blockchain for the first time and global state in order to validate
new blocks and execute new state changes.
• As the ledger and associated storage grow, computation of state
becomes slower and more expensive because nodes require more
time and computations to read from and write to state.
• If a node’s memory storage becomes full, it will need to use disk
space storage, which further slows down computation since nodes
need to swap between storage environments during execution.
• Blockchains with increasing storage requirements often experience
state bloat—a situation in which, without hardware upgrades, it
becomes harder for full nodes to stay synced to the current version
of the ledger (i.e. the chain tip) and for users to sync up new full
nodes.
• Some factors that may affect whether a blockchain experiences
state bloat include the historical length of the ledger, the frequency
of new block additions, the max size per block, and the amount of
data that must be stored on-chain to verify transactions and
execute state changes.
• When scaling the storage layer, the main problem to solve is how to
allow blockchains to process and validate more data without
increasing storage requirements for full nodes; i.e., where can data
be stored long term without major changes to the trust
assumptions of blockchains?
 Blockchain Consensus
• Blockchain consensus is the method by which nodes in a
decentralized network reach an agreement on the current
state of the blockchain.
• Consensus is mostly concerned with achieving an honest
majority in the face of a certain threshold of malicious actors
and reaching finality; i.e., transactions are accurately
processed and highly unlikely to ever be reversed.
• Blockchain consensus is generally designed around
minimizing communication overhead in order to increase the
upper bound on decentralization for stronger Byzantine fault
tolerance and lower the time to finality for faster settlement.
• When scaling the consensus layer, the main problem to solve
is how to reach finality faster, cheaper, and with more trust
minimization—all in a predictable, stable, and accurate
manner.
Scaling the Execution Layer
• Below are five different approaches currently being taken to scale the
execution layer of blockchains along with the advantages and tradeoffs of
each. In practice, some of these approaches are combined for even greater
execution capacity.
1. Vertical Scaling of Validator –
Blockchain execution can be scaled by increasing the hardware requirements
for block producers. Higher hardware requirements lead to each validator
being able to perform more computations per second
2. Horizontal Scaling via Multi-Chain Ecosystems
An alternative to vertical scaling is horizontal scaling through the use of
multiple independent blockchains or sidechains within a single ecosystem.
Horizontal scaling spreads the computation of transactions in an ecosystem
across many independent blockchains, with each chain having its own block
producers and execution capacity.
3. Horizontal Scaling via Execution Sharding
• A similar yet unique approach to multi-chain scaling is having
a single blockchain that supports parallel execution across
many different shards. Each shard essentially acts as its own
blockchain, meaning many blockchains can execute in
parallel. There is also a single main chain that has the sole
purpose of keeping all shards synced together.
• In execution sharding, there is one pool of validators that is
split up across shards to execute transactions. Nodes are
randomly and regularly rotated so they don’t always
execute/validate the same shard, with the number of shards
configured to make the risk of corrupting any single shard
statistically insignificant.
 Scalability continued…
4. Horizontal Scaling via Modularity:
Another approach to horizontal scaling is modular blockchains, where the architecture of
blockchains is separated into multiple different layers; i.e., isolating the execution, data
availability (DA), and consensus components.
The most popular way to perform execution in modular blockchain implementations is via
rollups, which move the computation and state off-chain into off-chain networks while storing
transaction data on-chain.
State changes computed off-chain are then proven on-chain proactively as valid using zero-
knowledge proofs (zk-rollups) or invalid retroactively using fraud proofs (optimistic rollups).
5. Payment and State Channels
• Payment and state channels can be used for blockchain scaling by allowing users to lock
cryptocurrency into a multi sign smart contract with other parties and then exchange
signed messages off-chain representing a transfer of asset ownership and/or change of
state without making any on-chain transactions. Users only need to make on-chain
transactions when opening a channel and closing a channel.
• The multisig contract is used to ensure the correct settlement of the channel by having
users cryptographically sign each interaction, with each signature accompanied by a nonce
so the smart contract can verify the correct order of transactions.
 Scaling Data Storage
• Vertical Scaling of Blockchain Nodes
• Similar to vertical scaling of blockchain execution,
vertical scaling of blockchain storage involves raising
the hardware requirements of running a full node
• Data Sharding on Layer-1 Blockchains
• Another approach to scaling the data storage of
blockchains is data sharding. Data sharding splits the
storage of the ledger and/or the data used to recreate
the ledger across many shards, reducing an individual
node’s storage requirements at any given time to that
of a single shard or small set of shards.
3. Compressed On-Chain Data Storage With Modular Blockchains
• Modular blockchains perform computation off-chain and then store
transaction data or state differences either on-chain or off-chain.
The data allows other nodes or users to rebuild the current or
historical state of the ledger. When rollups employ on-chain data
storage, transaction data is often compressed off-chain prior to
being stored on-chain.
4. Off-Chain Data Storage in Modular Blockchain Designs
• Modular blockchains can store transaction data off-chain to further
reduce on-chain storage requirements. This includes “validiums,”
which publish zero-knowledge proofs on-chain while storing data
off-chain. There are four main approaches to off-chain data storage
by modular blockchains:
• Centralized storage consists of off-chain storage on a centralized
platform. While it’s the cheapest way to store data, it can be
subject to data withholding and security issues such as the
centralized storage platform modifying data or going offline.
• Permissioned DACs store data off-chain but provide on-chain
attestations of that data being published correctly using a
signature scheme from a small committee of trusted nodes,
referred to as a data availability committee (DAC). The
advantages and trade-offs are similar to centralized storage
solutions but with slightly better trust assumptions on
availability.
• Permission less DACs store data off-chain but provide on-
chain proofs using permission less DACs with crypto economic
incentives to act honestly. Permission less DACs are cheaper
than on-chain storage solutions while being more secure than
other off-chain solutions. The trade-offs are that this is still
less secure than on-chain storage and has yet to be achieved in
production at scale with sustainable economics.
• Volitions enable users to choose whether they want to store
their transaction data on-chain or off-chain. Volitions are novel
because they enable data availability solution options at the
individual transaction level while allowing all transactions to
share the same state root and consensus cost. However, this
method is more complex than the others listed above and has
yet to be achieved in production.
5. Data Pruning
• Data pruning is a technique that enables blockchain full nodes to
discard historical data beyond a specific block height. Data pruning
is often paired with Proof-of-Stake checkpoints, where the
transactions in blocks beyond the checkpoint are considered final;
i.e. they can’t be reversed without major social consensus or a hard
fork.
6. Statelessness, State Expiry, and State Rent
There also exist methods focused around limiting the amount of state
that full nodes have to store, particularly through state expiry,
statelessness, or state rent implementations.
• State expiry designs allow nodes to prune state that hasn’t
been accessed in a certain amount of time, yet utilize a type of merkle
proof (called “witnesses”) to revive expired state if needed.
• Statelessness designs are where full nodes are not required to
store state. Full nodes only need to validate new blocks with the
inclusion of witnesses. Weak statelessness is when only block
producers are required to store global state while all other nodes can
verify blocks without storing state.
• State rent designs require that users pay to maintain limited
state storage. State that is no longer being paid for is recycled and
rented out to new users.
 Scaling Consensus
Below are four general goals when trying to scale blockchain consensus mechanisms as they
pertain to more frequent block times, faster finality, and enhanced robustness against
downtime or malicious attacks. Note that scaling consensus is not just about speed but also
accuracy, stability, and security.
• Increase Execution and Storage Capacity
• A foundational component in scaling a blockchain’s consensus mechanism is increasing its
computational and storage capacity without substantially raising the hardware
requirements for full nodes. This will allow more nodes to participate in consensus or at
least prevent existing nodes from dropping off the network as the ledger grows—helping
maintain strong consensus guarantees around uptime, censorship resistance, accuracy, and
security. If execution and storage capacity is raised to a significant level without meaningful
impact on full nodes, blockchains may even be able to support faster block times and/or
larger block sizes in a stable manner without sacrificing their core property of
decentralization.
• Reduce Networking Bandwidth
• Another way to approach scaling a blockchain’s consensus mechanism is to reduce
networking bandwidth; i.e. the communication overhead (sending and receiving messages)
required between full nodes in order to reach consensus. Instead of requiring that nodes be
able to communicate between all other nodes (i.e. all-to-all voting), blockchains consensus
can be designed so that nodes only need to communicate with a small portion of other
nodes at any moment in time (e.g. sub-sampling). Some consensus designs do not use
multi-round voting or communication schemes so the only communication required is the
propagation of blocks, but this generally comes at the expense of probabilistic finality.
Increase Network Latency
• There are also methods focused on trying to reduce network
latency during consensus, particularly as it relates to lowering the
time to finality. Some blockchain consensus mechanisms have
instant finality either through multi-round sub-sampling or all-to-all
voting rounds. Other blockchains implement checkpoints secured
by a supermajority consensus of validators after a period of time,
meaning blocks are considered final past the checkpoint since
there can no longer be in-protocol re-orgs beyond it. Often a
tradeoff between network latency and network bandwidth has to
be made, although some hybrid approaches have been optimized
for both.
Increase the Security Budget
• The trust minimization of consensus can also be scaled by
increasing the security budget that funds nodes participating in
consensus. This is generally done by achieving a monetary
premium, having inflationary token rewards, and/or growing
transaction fee revenue because demand for block space exceeds
supply. Higher security budgets open up more potential revenue
for participants, which may then increase the network’s
decentralization since more nodes are incentivized to join.
Blockchains can also require nodes to put up more stake or
computational power to participate in consensus, although this
risks increasing the centralization of the network if requirements
become too high.
A Scalable and Secure Cross-Chain Future
• Blockchain scalability is at an exciting point in its
development as demonstrated by the plethora of
solutions being built, tested, and launched into
production. With a strong focus on scaling while
preserving trust minimization, blockchains are poised to
cement themselves as the go-to backend for a wide
variety of industries and use cases.
• In support of the expanding multi-chain ecosystem, the
Cross-Chain Interoperability Protocol (CCIP) is actively
being developed on top of Chain-link to enable users to
securely exchange data and tokens between different
blockchains based on user-defined logic. CCIP is being
built with a strong focus on security, as demonstrated by
the development of a Risk Management Network, to
enable cross-chain smart contracts and secure token
bridging in a manner that doesn’t break the trust
assumptions of blockchains
Ledger Conflicts and Resolutions
• What are conflicts?
•It is possible, that the two different miners solve the Proof-of-Work
at the same time and thus add their blocks to the last known block
in the chain.
•Now, we have two branches afterBlock103.

Both the branches are valid. So the next mined block may be added
in either of the branches. Suppose, the miner adds the newly mined
block to Block104-A, the branch containing Block104-A will be longer
than the branch containing Block104.
• In Bit coin architecture, the longest branch always wins
and the shorter ones are purged. So the Block 104-B
has to be purged. Before purging this block, all
transactions in this block will be returned to the
transaction pool so that they are mined and added to
some future block. This is how the conflicts are
resolved and only one single chain of blocks is
maintained by the system.
 Scalability Parameter
Forking:
What is forking?
In the context of blockchain, "forking" refers to a split or
divergence in the blockchains protocol, resulting in two or more
versions of the blockchain, either due to a software update or a
disagreement among network participants.
•Forking is a term that refers to a situation
where a crypto currency or token project needs
to make technical updates to its own code.
•These updates will either be applied to the
backend of a project with no major changes in
service, or they will fundamentally change the
scope of the original project.
•Forking implies any divergence(divison) in
Blockchain-temporary or permanent. Very
simply, forking is said to happen when a
Blockchain splits into two branches.
•It can happen as a result of a change in
consensus algorithm or other software changes.
•Depending on the nature of change, the fork
can be categorized into Hard Fork and Soft Fork
Protocol Change:
A fork occurs when developers or the community decide
to change the rules or protocol of a blockchain.
Blockchain Split:
This change can lead to the blockchain splitting into two
or more versions, each following its own set of rules.
New Cryptocurrency:
In some cases, a fork can lead to the creation of a new
crypto currency, with its own blockchain and ecosystem.
Examples:
Bitcoin Cash (BCH) and Litecoin (LTC) are examples of
cryptocurrencies that came into existence due to hard
forks of Bitcoin and Litecoin respectively.
 Types of Forks:
Hard Fork
Hard Fork

• A hard fork is a permanent divergence from the previous version of the

Block chain, and node s running previous versions will no longer be
accepted by the newest version.
• A hard fork is a radical change to the protocol that makes previously
valid blocks or transactions invalid.
• Any transaction on the forked(newer)chain will not be valid on the older
chain.
• All nodes and miners will have to upgrade to the latest version of the
protocol software if they wish to be on the new forked chain.
• This essentially creates a fork in the Block chain, one path which follows
the new, upgraded Blockchain, and one path which continues along the
old path.
• Hard Fork is usually done only when there is enough
support from the mining community.
• Only when the majority of miners give positive signal
towards the upgrade or fork, the developers of the
chain starts work on the upgraded code.
• A hard fork introduces a change that is not backward-
compatible with the older version of the blockchain.
Incompatibility: Nodes running the old version of the
software will no longer be able to validate blocks created
by the new version, and vice versa.
New Chain: This can lead to the creation of a new,
separate blockchain, as the old and new versions diverge.
• Typically, the support should come from 90 to 95
percent of the miners A good example of a Hard Fork
was when Bit coin Cash came into existence.
Previously Bit coin was the dominant player in the
crypto currency game. But as transaction times slowed
and fees started to rise, the future of Bitcoin came into
question. Generally, there are two different ways
which a hard fork can occur. It can either be:
Contentious or planned Fork can occur because of
•Block Size
•Proof of Work
•Bit coin Reward per block and many more
A planned hard fork means that the creators/developers
were all in agreement as to how the coin would be
forked. When this occurs, there is no split in the chain.
This is because all of the nodes have agreed to upgrade to
the latest version of t he coin’s client that possesses the
rule change.
Soft Fork
• A soft fork is said to happen when a change to the software
protocol keeps it backward compatible.
•What this means is that the new forked chain will follow the new
rules and will also honour the old rules.
•The original chain will continue to follow the old rules.
•This kind of fork requires only a majority of the miners upgrading to
enforce the new rules, as opposed to a hard fork which
requires(almost)all nodes to upgrade and agree on the new version.
• A soft fork introduces a change that is backward-compatible with
the older version of the blockchain.
• Compatibility: Nodes running the old version of the software can
still validate blocks created by the new version, and vice versa.
• Single Chain: The blockchain remains a single chain, with the new
rules being enforced by a majority of the nodes
• New transaction types can often be added as soft
forks, requiring only that the participants for e.g.
sender and receiver and miners understand the new
transaction type.
• This is done by having the new transaction appear to
older clients as a “pay-to-anybody” transaction (of a
special form) and getting the miners to agree to reject
blocks including this transaction unless the transaction
validates under the new rules.
•A soft fork can also occur at times due to a temporary
divergence in the Blockchain when miners using non-
upgraded nodes violate a new consensus rule their nodes
don’t know about.
Why do Forks Happen?
Protocol Upgrades:
Developers may initiate a fork to introduce new
features, improve security, or address scalability
issues.
Community Disagreement:
Disagreements among network participants about
the direction of the project can also lead to a fork.
Creating New Crypto currencies:
Developers may also use a fork to create entirely
new crypto currencies and ecosystems.
Aspect Hard Fork Soft Fork

Permanent change to blockchain

Definition protocol.
Update to existing protocol.

Backward Compatibility Not backward-compatible. Backward-compatible.

Chain Split Yes, creates a new blockchain. No, retains the same blockchain.

Old nodes can't validate new Old nodes can still validate
Impact on Nodes transactions. transactions.

Consensus Requirement Requires majority consensus. Requires less consensus.

Less flexible, suited for minor

Flexibility More flexibility for radical changes.
changes.

Risk of Network Split High, can lead to community division. Low, usually no network split.

Requires nodes to upgrade to remain Nodes can still function even if not
Upgrade Process compatible. upgraded.

More complex to manage due to chain

Complexity split.
Simpler to implement and transition.

Can improve scalability drastically (e.g., Smaller-scale updates to improve

Scalability by increasing block size). performance or security.

Can cause disruption to the network

Disruption and economy.
Minimal disruption to the network.