UNIT II

BLOCKCHAIN

Introduction, Advantage over conventional distributed database, Blockchain Network,

Mining Mechanism, Distributed Consensus, Merkle Patricia Tree, Gas Limit,
Transactions and Fee, Anonymity, Reward, Chain Policy, Life of Blockchain
application, Soft & Hard Fork, Private and Public blockchain.

2.1 Advantages of Distributed database

Distributed databases basically provide us the advantages of distributed computing to the
database management domain. Basically, we can define a Distributed database as a
collection of multiple interrelated databases distributed over a computer network and a
distributed database management system as a software system that basically manages a
distributed database while making the distribution transparent to the user.
Distributed database management basically proposed for the various reason from
organizational decentralization and economical processing to greater autonomy. Some of
these advantages are as follows:
1. Management of data with different level of transparency –
Ideally, a database should be distribution transparent in the sense of hiding the details of
where each file is physically stored within the system. The following types of
transparencies are basically possible in the distributed database system:
 Network transparency:
This basically refers to the freedom for the user from the operational details of the
network. These are of two types Location and naming transparency.
 Replication transparencies:
It basically made user unaware of the existence of copies as we know that copies of data
may be stored at multiple sites for better availability performance and reliability.
 Fragmentation transparency:
It basically made user unaware about the existence of fragments it may be the vertical
fragment or horizontal fragmentation.

2. Increased Reliability and availability

Reliability is basically defined as the probability that a system is running at a certain time
whereas Availability is defined as the probability that the system is continuously available
during a time interval. When the data and DBMS software are distributed over several sites
one site may fail while other sites continue to operate and we are not able to only access the
data that exist at the failed site and this basically leads to improvement in reliability and
availability.

3. Easier Expansion –
In a distributed environment expansion of the system in terms of adding more data,
increasing database sizes or adding more processor is much easier.

4. Improved Performance –
We can achieve interquery and intraquery parallelism by executing multiple queries at
different sites by breaking up a query into a number of sub queries that basically executes
in parallel which basically leads to improvement in performance.

41
Distributed databases are computer databases that are spread across multiple
physical locations, typically connected by a network. Here are some of the advantages
of distributed databases:
1. Improved scalability: Distributed databases can be scaled horizontally by adding more
nodes to the network. This allows for increased capacity and performance as data and
user demand grow.
2. Increased availability: Distributed databases can provide increased availability and
uptime by distributing the data across multiple nodes. If one node goes down, the data
can still be accessed from other nodes in the network.
3. Increased flexibility: Distributed databases can be more flexible than centralized
databases, allowing data to be stored in a way that best suits the needs of the application
or user.
4. Improved fault tolerance: Distributed databases can be designed with redundancy and
failover mechanisms that allow the system to continue operating in the event of a node
failure.
5. Improved security: Distributed databases can be more secure than centralized
databases by implementing security measures at the network, node, and application
levels.
distributed databases provide several advantages over centralized databases, including
improved scalability, availability, performance, flexibility, fault tolerance, and security.
These advantages make distributed databases a popular choice for large-scale applications
where data must be accessed by a large number of users or applications in a geographically
dispersed manner.

2.1.1 Features of distributed databases include:

Scalability: Distributed databases can be easily scaled by adding more nodes to the system.
This allows for the database to handle large volumes of data and high traffic loads.
Fault tolerance: Distributed databases are designed to be resilient to failures, which means
that if one node fails, the database can continue to operate without interruption.
Data replication: Distributed databases often replicate data across multiple nodes to ensure
data availability and reduce the risk of data loss.
Distributed query processing: Distributed databases can perform queries across multiple
nodes, allowing for faster and more efficient data retrieval.
Data consistency: Distributed databases must ensure data consistency across all nodes.
This can be achieved through various methods, such as using a consensus protocol or a
distributed locking mechanism.
Location transparency: Distributed databases allow users to access data regardless of the
location of the data or the user. This means that users can access the data they need from
any node in the system.
Security: Distributed databases must ensure that data is secure and protected from
unauthorized access. This can be achieved through various security mechanisms, such as
encryption and access control.

42
2.2 Blockchain network

This topic will describe, at a conceptual level, how Hyperledger Fabric allows
organizations to collaborate in the formation of blockchain networks. If you’re an
architect, administrator or developer, you can use this topic to get a solid underst anding
of the major structure and process components in a Hyperledger Fabric blockchain
network. This topic will use a manageable worked example that introduces all of the
major components in a blockchain network.

After reading this topic and understanding the concept of policies, you will have a solid
understanding of the decisions that organizations need to make to establish the policies
that control a deployed Hyperledger Fabric network. You’ll also understand how
organizations manage network evolution using declarative policies – a key feature of
Hyperledger Fabric. In a nutshell, you’ll understand the major technical components of
Hyperledger Fabric and the decisions organizations need to make about them.

What is a blockchain network?

A blockchain network is a technical infrastructure that provides ledger and smart
contract (chaincode) services to applications. Primarily, smart contracts are used to
generate transactions which are subsequently distributed to every peer node in the
network where they are immutably recorded on their copy of the ledger. The users of
applications might be end users using client applications or blockchain network
administrators.

In most cases, multiple organizations come together as a consortium to form the network
and their permissions are determined by a set of policies that are agreed by the
consortium when the network is originally configured. Moreover, network policies can
change over time subject to the agreement of the organizations in the consortium, as
we’ll discover when we discuss the concept of modification policy.

2.2.1 The sample network

Before we start, let’s show you what we’re aiming at! Here’s a diagram representing
the final state of our sample network.

Don’t worry that this might look complicated! As we go through this topic, we will build
up the network piece by piece, so that you see how the organizations R1, R2, R3 and R4
contribute infrastructure to the network to help form it. This infrastructure implemen ts
the blockchain network, and it is governed by policies agreed by the organizations who
form the network – for example, who can add new organizations. You’ll discover how

43
applications consume the ledger and smart contract services provided by the blockch ain
network.

Four organizations, R1, R2, R3 and R4 have jointly decided, and written into an
agreement, that they will set up and exploit a Hyperledger Fabric network. R4 has been
assigned to be the network initiator – it has been given the power to set up the initial
version of the network. R4 has no intention to perform business transactions on the
network. R1 and R2 have a need for a private communications within the overall
network, as do R2 and R3. Organization R1 has a client application that can perform
business transactions within channel C1. Organization R2 has a client application that
can do similar work both in channel C1 and C2. Organization R3 has a client
application that can do this on channel C2. Peer node P1 maintains a copy of the ledger
L1 associated with C1. Peer node P2 maintains a copy of the ledger L1 associated with
C1 and a copy of ledger L2 associated with C2. Peer node P3 maintains a copy of the
ledger L2 associated with C2. The network is governed according to policy rules
specified in network configuration NC4, the network is under the control of
organizations R1 and R4. Channel C1 is governed according to the policy rules specified
in channel configuration CC1; the channel is under the control of organizations R1 and
R2. Channel C2 is governed according to the policy rules specified in channel
configuration CC2; the channel is under the control of organizations R2 and R3. There
is an ordering service O4 that services as a network administration point for N, and uses
the system channel. The ordering service also supports application channels C1 and C2,
for the purposes of transaction ordering into blocks for distribution. Each of the four
organizations has a preferred Certificate Authority.

44
2.2.2 Creating the Network
Let’s start at the beginning by creating the basis for the network:

The network is formed when an orderer is started. In our example network, N, the
ordering service comprising a single node, O4, is configured according to a network
configuration NC4, which gives administrative rights to organization R4. At the network
level, Certificate Authority CA4 is used to dispense identities to the administrators and
network nodes of the R4 organization.

We can see that the first thing that defines a network, N, is an ordering service, O4. It’s
helpful to think of the ordering service as the initial administration point for the network.
As agreed beforehand, O4 is initially configured and started by an administrator in
organization R4, and hosted in R4. The configuration NC4 contains the policies that
describe the starting set of administrative capabilities for the network. Initially this is set
to only give R4 rights over the network. This will change, as we’ll see later, but for now
R4 is the only member of the network.

2.2.3 Certificate Authorities

You can also see a Certificate Authority, CA4, which is used to issue certificates to
administrators and network nodes. CA4 plays a key role in our network because it
dispenses X.509 certificates that can be used to identify components as belonging to
organization R4. Certificates issued by CAs can also be used to sign transactions to
indicate that an organization endorses the transaction result – a precondition of it being
accepted onto the ledger. Let’s examine these two aspects of a CA in a little more detail.

45
Firstly, different components of the blockchain network use certificates to identify
themselves to each other as being from a particular organization. That’s why there is
usually more than one CA supporting a blockchain network – different organizations
often use different CAs. We’re going to use four CAs in our network; one for each
organization. Indeed, CAs are so important that Hyperledger Fabric provides you with a
built-in one (called Fabric-CA) to help you get going, though in practice, organizations
will choose to use their own CA.

The mapping of certificates to member organizations is achieved by via a structure called

a Membership Services Provider (MSP). Network configuration NC4 uses a named MSP
to identify the properties of certificates dispensed by CA4 which associate certificate
holders with organization R4. NC4 can then use this MSP name in policies to gr ant
actors from R4 particular rights over network resources. An example of such a policy is
to identify the administrators in R4 who can add new member organizations to the
network. We don’t show MSPs on these diagrams, as they would just clutter them up,
but they are very important.

Secondly, we’ll see later how certificates issued by CAs are at the heart of
the transaction generation and validation process. Specifically, X.509 certificates are
used in client application transaction proposals and smart contract transaction
responses to digitally sign transactions. Subsequently the network nodes who host copies
of the ledger verify that transaction signatures are valid before accepting transactions
onto the ledger.

Let’s recap the basic structure of our example blockchain network. There’s a resource,
the network N, accessed by a set of users defined by a Certificate Authority CA4, who
have a set of rights over the resources in the network N as described by policies
contained inside a network configuration NC4. All of this is made real when we
configure and start the ordering service node O4.

2.2.4 Adding Network Administrators

NC4 was initially configured to only allow R4 users administrative rights over the
network. In this next phase, we are going to allow organization R1 users to administer
the network. Let’s see how the network evolves:

46
Organization R4 updates the network configuration to make organization R1 an
administrator too. After this point R1 and R4 have equal rights over the network
configuration.

We see the addition of a new organization R1 as an administrator – R1 and R4 now have

equal rights over the network. We can also see that certificate authority CA1 has been
added – it can be used to identify users from the R1 organization. After this point, users
from both R1 and R4 can administer the network.

Although the orderer node, O4, is running on R4’s infrastructure, R1 has shared
administrative rights over it, as long as it can gain network access. It means that R1 or
R4 could update the network configuration NC4 to allow the R2 organization a subset of
network operations. In this way, even though R4 is running the ordering service, and R1
has full administrative rights over it, R2 has limited rights to create new consortia.

In its simplest form, the ordering service is a single node in the network, and that’s what
you can see in the example. Ordering services are usually multi-node, and can be
configured to have different nodes in different organizations. For example, we might run
O4 in R4 and connect it to O1, a separate orderer node in organization R1. In this way,
we would have a multi-site, multi-organization administration structure.

We’ll discuss the ordering service a little later in this topic, but for now just think of the
ordering service as an administration point which provides different organizations
controlled access to the network.

47
2.2.5 Defining a Consortium
Although the network can now be administered by R1 and R4, there is very little that can
be done. The first thing we need to do is define a consortium. This word literally means
“a group with a shared destiny”, so it’s an appropriate choice for a set of organizations in
a blockchain network.

Let’s see how a consortium is defined:

A network administrator defines a consortium X1 that contains two members, the

organizations R1 and R2. This consortium definition is stored in the network
configuration NC4, and will be used at the next stage of network development. CA1 and
CA2 are the respective Certificate Authorities for these organizations.

Because of the way NC4 is configured, only R1 or R4 can create new consortia. This
diagram shows the addition of a new consortium, X1, which defines R1 and R2 as its
constituting organizations. We can also see that CA2 has been added to identify users
from R2. Note that a consortium can have any number of organizational members – we
have just shown two as it is the simplest configuration.

Why are consortia important? We can see that a consortium defines the set of
organizations in the network who share a need to transact with one another – in this
case R1 and R2. It really makes sense to group organizations together if they have a
common goal, and that’s exactly what’s happening.

48
The network, although started by a single organization, is now controlled by a larger set
of organizations. We could have started it this way, with R1, R2 and R4 having shared
control, but this build up makes it easier to understand.

We’re now going to use consortium X1 to create a really important part of a Hyperledger
Fabric blockchain – a channel.

2.2.6 Creating a channel for a consortium

So let’s create this key part of the Fabric blockchain network – a channel. A channel is a
primary communications mechanism by which the members of a consortium can
communicate with each other. There can be multiple channels in a network, but for now,
we’ll start with one.

Let’s see how the first channel has been added to the network:

A channel C1 has been created for R1 and R2 using the consortium definition X1. The
channel is governed by a channel configuration CC1, completely separate to the network
configuration NC4. CC1 is managed by R1 and R2 who have equal rights over C1. R4
has no rights in CC1 whatsoever.

The channel C1 provides a private communications mechanism for the consortium X1.
We can see channel C1 has been connected to the ordering service O4 but that nothing
else is attached to it. In the next stage of network development, we’re going to connect
components such as client applications and peer nodes. But at this point, a channel
represents the potential for future connectivity.

49
Even though channel C1 is a part of the network N, it is quite distinguishable from it.
Also notice that organizations R3 and R4 are not in this channel – it is for transaction
processing between R1 and R2. In the previous step, we saw how R4 could grant R1
permission to create new consortia. It’s helpful to mention that R4 also allowed R1 to
create channels! In this diagram, it could have been organization R1 or R4 who created a
channel C1. Again, note that a channel can have any number of organizations connected
to it – we’ve shown two as it’s the simplest configuration.

Again, notice how channel C1 has a completely separate configuration, CC1, to the
network configuration NC4. CC1 contains the policies that govern the rights that R1 and
R2 have over the channel C1. An example of these policies is defining who can add a
new organization to the channel. In our example, organizations other than R1 and R2
have no permissions over the channel C1 and can only interact with it if they are added
by R1 or R2 to the appropriate policy in the channel configuration CC1. Specifically,
note that R4 cannot add itself to the channel C1. It must, and can only, be authorized by
R1 or R2.

Why are channels so important? Channels are useful because they provide a mechanism
for private communications and private data between the members of a consortium.
Channels provide privacy from other channels, and from the network. Hyperledger
Fabric is powerful in this regard, as it allows organizations to share infrastructure and
keep it private at the same time. There’s no contradiction here – different consortia
within the network will have a need for different information and processes to be
appropriately shared, and channels provide an efficient mechanism to do this. Channels
provide an efficient sharing of infrastructure while maintaining data and communications
privacy.

We can also see that once a channel has been created, it is in a very real sense “free from
the network”. It is only organizations that are explicitly specified in a channel
configuration that have any control over it, from this time forward into the future.
Likewise, any updates to network configuration NC4 from this time onwards will have
no direct effect on channel configuration CC1; for example if consortia definition X1 is
changed, it will not affect the members of channel C1. Channels are therefore useful
because they allow private communications between the organizations constituting the
channel. Moreover, the data in a channel is completely isolated from the rest of the
network, including other channels.

50
As an aside, there is also a special system channel defined for use by the ordering
service. It behaves in exactly the same way as a regular channel, which are sometimes
called application channels for this reason. We don’t normally need to worry about this
channel, but we’ll discuss a little bit more about it later in this topic.

2.2.7 Peers and Ledgers

Let’s now start to use the channel to connect the blockchain network and the
organizational components together. In the next stage of network development, we can
see that our network N has just acquired two new components, namely a peer node P1
and a ledger instance, L1.

A peer node P1 has joined the channel C1. P1 physically hosts a copy of the ledger L1.
P1 and O4 can communicate with each other using channel C1.

Peer nodes are the network components where copies of the blockchain ledger are
hosted! At last, we’re starting to see some recognizable blockchain components! P1’s
purpose in the network is purely to host a copy of the ledger L1 for others to access. We
can think of L1 as being physically hosted on P1, but logically hosted on the channel
C1. We’ll see this idea more clearly when we add more peers to the channel.

A key part of a P1’s configuration is an X.509 identity issued by CA1 which associates
P1 with organization R1. When R1 administrator takes the action of joining peer P1 to
channel C1, and the peer starts pulling blocks from the orderer O4, the orderer uses the
channel configuration CC1 to determine P1’s permissions on this channel. For example,
policy in CC1 determines whether P1 (or the organization R1) can read and/or write on
the channel C1.

51
Notice how peers are joined to channels by the organizations that own them, and though
we’ve only added one peer, we’ll see how there can be multiple peer nodes on multiple
channels within the network. We’ll see the different roles that peers can take on a little
later.

2.2.8 Applications and Smart Contract chaincode

Now that the channel C1 has a ledger on it, we can start connecting client applications to
consume some of the services provided by workhorse of the ledger, the peer!

Notice how the network has grown:

A smart contract S5 has been installed onto P1. Client application A1 in organization R1
can use S5 to access the ledger via peer node P1. A1, P1 and O4 are all joined to
channel C1, i.e. they can all make use of the communication facilities provided by that
channel.

In the next stage of network development, we can see that client application A1 can use
channel C1 to connect to specific network resources – in this case A1 can connect to
both peer node P1 and orderer node O4. Again, see how channels are central to the
communication between network and organization components. Just like peers and
orderers, a client application will have an identity that associates it with an organization.
In our example, client application A1 is associated with organization R1; and although it
is outside the Fabric blockchain network, it is connected to it via the channel C1.

It might now appear that A1 can access the ledger L1 directly via P1, but in fact, all
access is managed via a special program called a smart contract chaincode, S5. Think of

52
S5 as defining all the common access patterns to the ledger; S5 provides a well -defined
set of ways by which the ledger L1 can be queried or updated. In short, client application
A1 has to go through smart contract S5 to get to ledger L1!

Smart contracts can be created by application developers in each organization to

implement a business process shared by the consortium members. Smart contracts are
used to help generate transactions which can be subsequently distributed to every node in
the network. We’ll discuss this idea a little later; it’ll be easier to understand when the
network is bigger. For now, the important thing to understand is that to get to this point
two operations must have been performed on the smart contract; it must have
been installed on peers, and then defined on a channel.

Hyperledger Fabric users often use the terms smart

contract and chaincode interchangeably. In general, a smart contract defines
the transaction logic that controls the lifecycle of a business object contained in the
world state. It is then packaged into a chaincode which is then deployed to a blockchain
network. Think of smart contracts as governing transactions, whereas chaincode governs
how smart contracts are packaged for deployment.

2.2.9 Installing a chaincode package

After a smart contract S5 has been developed, an administrator in organization R1 must
create a chaincode package and install it onto peer node P1. This is a straightforward
operation; once completed, P1 has full knowledge of S5. Specifically, P1 can see
the implementation logic of S5 – the program code that it uses to access the ledger L1.
We contrast this to the S5 interface which merely describes the inputs and outputs of S5,
without regard to its implementation.

When an organization has multiple peers in a channel, it can choose the peers upon
which it installs smart contracts; it does not need to install a smart contract on every
peer.

2.2.10 Defining a chaincode

Although a chaincode is installed on the peers of individual organizations, it is governed
and operated in the scope of a channel. Each organization needs to approve a chaincode
definition, a set of parameters that establish how a chaincode will be used on a channel.
An organization must approve a chaincode definition in order to use the installed smart
contract to query the ledger and endorse transactions. In our example, which only has a
single peer node P1, an administrator in organization R1 must approve a chaincode
definition for S5.
53
A sufficient number of organizations need to approve a chaincode definition (A majori ty,
by default) before the chaincode definition can be committed to the channel and used to
interact with the channel ledger. Because the channel only has one member, the
administrator of R1 can commit the chaincode definition of S5 to the channel C1. Once
the definition has been committed, S5 can now be invoked by client application A1!

Note that although every component on the channel can now access S5, they are not able
to see its program logic. This remains private to those nodes who have installed it; in our
example that means P1. Conceptually this means that it’s the smart
contract interface that is defined and committed to a channel, in contrast to the smart
contract implementation that is installed. To reinforce this idea; installing a smart
contract shows how we think of it being physically hosted on a peer, whereas a smart
contract that has been defined on a channel shows how we consider it logically
hosted by the channel.

2.2.11 Endorsement policy

The most important piece of information supplied within the chaincode definition is
the endorsement policy. It describes which organizations must approve transactions
before they will be accepted by other organizations onto their copy of the ledger. In our
sample network, transactions can only be accepted onto ledger L1 if R1 or R2 endorse
them.

Committing the chaincode definition to the channel places the endorsement policy on the
channel ledger; it enables it to be accessed by any member of the channel. You can read
more about endorsement policies in the transaction flow topic.

2.2.12 Invoking a smart contract

Once a smart contract has been committed to a channel, it can be invoked by a client
application. Client applications do this by sending transaction proposals to peers owned
by the organizations specified by the smart contract endorsement policy. The transaction
proposal serves as input to the smart contract, which uses it to generate an endorsed
transaction response, which is returned by the peer node to the client application.

It’s these transactions responses that are packaged together with the transaction proposal
to form a fully endorsed transaction, which can be distributed to the entire network.
We’ll look at this in more detail later For now, it’s enough to understand how
applications invoke smart contracts to generate endorsed transactions.

54
By this stage in network development we can see that organization R1 is fully
participating in the network. Its applications – starting with A1 – can access the ledger
L1 via smart contract S5, to generate transactions that will be endorsed by R1, and
therefore accepted onto the ledger because they conform to the endorsement policy.

2.2.13 Network completed

Recall that our objective was to create a channel for consortium X1 – organizations R1
and R2. This next phase of network development sees organization R2 add its
infrastructure to the network.

Let’s see how the network has evolved:

The network has grown through the addition of infrastructure from organization R2.
Specifically, R2 has added peer node P2, which hosts a copy of ledger L1, and chaincode
S5. R2 approves the same chaincode definition as R1. P2 has also joined channel C1, as
has application A2. A2 and P2 are identified using certificates from CA2. All of this
means that both applications A1 and A2 can invoke S5 on C1 either using peer node P1
or P2.

We can see that organization R2 has added a peer node, P2, on channel C1. P2 also hosts
a copy of the ledger L1 and smart contract S5. We can see that R2 has also added client
application A2 which can connect to the network via channel C1. To achieve this, an
administrator in organization R2 has created peer node P2 and joined it to channel C1, in
the same way as an administrator in R1. The administrator also has to approve the same
chaincode definition as R1.

55
We have created our first operational network! At this stage in network development, we
have a channel in which organizations R1 and R2 can fully transact with each other.
Specifically, this means that applications A1 and A2 can generate transactions using
smart contract S5 and ledger L1 on channel C1.

2.2.14 Generating and accepting transactions

In contrast to peer nodes, which always host a copy of the ledger, we see that there are
two different kinds of peer nodes; those which host smart contracts and those which do
not. In our network, every peer hosts a copy of the smart contract, but in larger networks,
there will be many more peer nodes that do not host a copy of the smart contract. A peer
can only run a smart contract if it is installed on it, but it can know about the interface of
a smart contract by being connected to a channel.

You should not think of peer nodes which do not have smart contracts installed as being
somehow inferior. It’s more the case that peer nodes with smart contracts have a special
power – to help generate transactions. Note that all peer nodes can validate and
subsequently accept or reject transactions onto their copy of the ledger L1. However,
only peer nodes with a smart contract installed can take part in the process of
transaction endorsement which is central to the generation of valid transactions.

We don’t need to worry about the exact details of how transactions are generated,
distributed and accepted in this topic – it is sufficient to understand that we have a
blockchain network where organizations R1 and R2 can share information and processes
as ledger-captured transactions. We’ll learn a lot more about transactions, ledgers, smart
contracts in other topics.

2.2.15 Types of peers

In Hyperledger Fabric, while all peers are the same, they can assume multiple roles
depending on how the network is configured. We now have enough understanding of a
typical network topology to describe these roles.

 Committing peer. Every peer node in a channel is a committing peer. It receives

blocks of generated transactions, which are subsequently validated before they are
committed to the peer node’s copy of the ledger as an append operation.
 Endorsing peer. Every peer can be an endorsing peer if it has a smart contract
installed. However, to actually be an endorsing peer, the smart contract on the peer
must be used by a client application to generate a digitally signed transaction
response. The term endorsing peer is an explicit reference to this fact.

56
 An endorsement policy for a smart contract identifies the organizations whose peer
should digitally sign a generated transaction before it can be accepted onto a
committing peer’s copy of the ledger.
These are the two major types of peer; there are two other roles a peer can adopt:

 Leader peer. When an organization has multiple peers in a channel, a leader peer is a
node which takes responsibility for distributing transactions from the orderer to the
other committing peers in the organization. A peer can choose to participate in static
or dynamic leadership selection.

It is helpful, therefore to think of two sets of peers from leadership perspective –

those that have static leader selection, and those with dynamic leader selection. For
the static set, zero or more peers can be configured as leaders. For the dynamic set,
one peer will be elected leader by the set. Moreover, in the dynamic set, if a leader
peer fails, then the remaining peers will re-elect a leader.

It means that an organization’s peers can have one or more leaders connected to the
ordering service. This can help to improve resilience and scalability in large networks
which process high volumes of transactions.
 Anchor peer. If a peer needs to communicate with a peer in another organization,
then it can use one of the anchor peers defined in the channel configuration for that
organization. An organization can have zero or more anchor peers defined for it, and
an anchor peer can help with many different cross-organization communication
scenarios.
Note that a peer can be a committing peer, endorsing peer, leader peer and anchor peer
all at the same time! Only the anchor peer is optional – for all practical purposes there
will always be a leader peer and at least one endorsing peer and at least one committing
peer.

2.2.15 Adding organizations and peers to the channel

When R2 joins the channel, the organization must install smart contract S5 onto its peer
node, P2. That’s obvious – if applications A1 or A2 wish to use S5 on peer node P2 to
generate transactions, it must first be present; installation is the mechanism by which this
happens. At this point, peer node P2 has a physical copy of the smart contract and the
ledger; like P1, it can both generate and accept transactions onto its copy of ledger L1.

R2 must approve the same chaincode definition as was approved by R1 in order to use
smart contract S5. Because the chaincode definition has already been committed to the
channel by organization R1, R2 can use the chaincode as soon as the organi zation

57
approves the chaincode definition and installs the chaincode package. The commit
transaction only needs to happen once. A new organization can use the chaincode as
soon as they approve the chaincode parameters agreed to by other members of the
channel. Because the approval of a chaincode definition occurs at the organization level,
R2 can approve the chaincode definition once and join multiple peers to the channel with
the chaincode package installed. However, if R2 wanted to change the chaincode
definition, both R1 and R2 would need to approve a new definition for their
organization, and then one of the organizations would need to commit the definition to
the channel.

In our network, we can see that channel C1 connects two client applications, two pe er
nodes and an ordering service. Since there is only one channel, there is only
one logical ledger with which these components interact. Peer nodes P1 and P2 have
identical copies of ledger L1. Copies of smart contract S5 will usually be identically
implemented using the same programming language, but if not, they must be
semantically equivalent.

We can see that the careful addition of peers to the network can help support increased
throughput, stability, and resilience. For example, more peers in a network will allow
more applications to connect to it; and multiple peers in an organization will provide
extra resilience in the case of planned or unplanned outages.

It all means that it is possible to configure sophisticated topologies which support a

variety of operational goals – there is no theoretical limit to how big a network can get.
Moreover, the technical mechanism by which peers within an individual organization
efficiently discover and communicate with each other – the gossip protocol – will
accommodate a large number of peer nodes in support of such topologies.

The careful use of network and channel policies allow even large networks to be well -
governed. Organizations are free to add peer nodes to the network so long as they
conform to the policies agreed by the network. Network and channel policies create the
balance between autonomy and control which characterizes a de-centralized network.

2.2.16 Simplifying the visual vocabulary

We’re now going to simplify the visual vocabulary used to represent our sample
blockchain network. As the size of the network grows, the lines initially used to help us
understand channels will become cumbersome. Imagine how complicated our diagram
would be if we added another peer or client application, or another channel?

58
That’s what we’re going to do in a minute, so before we do, let’s simplify the visual
vocabulary. Here’s a simplified representation of the network we’ve developed so far:

The diagram shows the facts relating to channel C1 in the network N as follows: Client
applications A1 and A2 can use channel C1 for communication with peers P1 and P2,
and orderer O4. Peer nodes P1 and P2 can use the communication services of channel
C1. Ordering service O4 can make use of the communication services of channel C1.
Channel configuration CC1 applies to channel C1.

Note that the network diagram has been simplified by replacing channel lines with
connection points, shown as blue circles which include the channel number. No
information has been lost. This representation is more scalable because it eliminates
crossing lines. This allows us to more clearly represent larger networks. We’ve achieved
this simplification by focusing on the connection points between components and a
channel, rather than the channel itself.

2.2.17 Adding another consortium definition

In this next phase of network development, we introduce organization R3. We’re going
to give organizations R2 and R3 a separate application channel which allows them to
transact with each other. This application channel will be completely separate to that
previously defined, so that R2 and R3 transactions can be kept private to them.

Let’s return to the network level and define a new consortium, X2, for R2 and R3:

59
A network administrator from organization R1 or R4 has added a new consortium
definition, X2, which includes organizations R2 and R3. This will be used to define a new
channel for X2.

Notice that the network now has two consortia defined: X1 for organizations R1 and R2
and X2 for organizations R2 and R3. Consortium X2 has been introduced in order to be
able to create a new channel for R2 and R3.

A new channel can only be created by those organizations specifically identified in the
network configuration policy, NC4, as having the appropriate rights to do so, i.e. R1 or
R4. This is an example of a policy which separates organizations that can manage
resources at the network level versus those who can manage resources at the channel
level. Seeing these policies at work helps us understand why Hyperledger Fabric has a
sophisticated tiered policy structure.

In practice, consortium definition X2 has been added to the network configuration NC4.
We discuss the exact mechanics of this operation elsewhere in the documentation.

2.2.18 Adding a new channel

Let’s now use this new consortium definition, X2, to create a new channel, C2. To help
reinforce your understanding of the simpler channel notation, we’ve used both vis ual
styles – channel C1 is represented with blue circular end points, whereas channel C2 is
represented with red connecting lines:

60
A new channel C2 has been created for R2 and R3 using consortium definition X2. The
channel has a channel configuration CC2, completely separate to the network
configuration NC4, and the channel configuration CC1. Channel C2 is managed by R2
and R3 who have equal rights over C2 as defined by a policy in CC2. R1 and R4 have no
rights defined in CC2 whatsoever.

The channel C2 provides a private communications mechanism for the consortium X2.
Again, notice how organizations united in a consortium are what form channels. The
channel configuration CC2 now contains the policies that govern channel resources,
assigning management rights to organizations R2 and R3 over channel C2. It is managed
exclusively by R2 and R3; R1 and R4 have no power in channel C2. For example,
channel configuration CC2 can subsequently be updated to add organizations to support
network growth, but this can only be done by R2 or R3.

Note how the channel configurations CC1 and CC2 remain completely separate from
each other, and completely separate from the network configuration, NC4. Again we’re
seeing the de-centralized nature of a Hyperledger Fabric network; once channel C2 has
been created, it is managed by organizations R2 and R3 independently to other network
elements. Channel policies always remain separate from each other and can only be
changed by the organizations authorized to do so in the channel.

As the network and channels evolve, so will the network and channel configurations.
There is a process by which this is accomplished in a controlled manner – involving
configuration transactions which capture the change to these configurations. Every
configuration change results in a new configuration block transaction being generated,
and later in this topic, we’ll see how these blocks are validated and accepted to create
updated network and channel configurations respectively.

61
2.2.19 Network and channel configurations
Throughout our sample network, we see the importance of network and channel
configurations. These configurations are important because they encapsulate
the policies agreed by the network members, which provide a shared reference for
controlling access to network resources. Network and channel configurations also
contain facts about the network and channel composition, such as the name of consortia
and its organizations.

For example, when the network is first formed using the ordering service node O4, its
behaviour is governed by the network configuration NC4. The initial configuration of
NC4 only contains policies that permit organization R4 to manage network resources.
NC4 is subsequently updated to also allow R1 to manage network resources. Once this
change is made, any administrator from organization R1 or R4 that connects to O4 will
have network management rights because that is what the policy in the network
configuration NC4 permits. Internally, each node in the ordering service records each
channel in the network configuration, so that there is a record of each channel created, at
the network level.

It means that although ordering service node O4 is the actor that created consortia X1
and X2 and channels C1 and C2, the intelligence of the network is contained in the
network configuration NC4 that O4 is obeying. As long as O4 behaves as a good actor,
and correctly implements the policies defined in NC4 whenever it is dealing with
network resources, our network will behave as all organizations have agreed. In many
ways NC4 can be considered more important than O4 because, ultimately, it controls
network access.

The same principles apply for channel configurations with respect to peers. In our
network, P1 and P2 are likewise good actors. When peer nodes P1 and P2 are interacting
with client applications A1 or A2 they are each using the policies defined within channel
configuration CC1 to control access to the channel C1 resources.

For example, if A1 wants to access the smart contract chaincode S5 on peer nodes P1 or
P2, each peer node uses its copy of CC1 to determine the operations that A1 can
perform. For example, A1 may be permitted to read or write data from the ledger L1
according to policies defined in CC1. We’ll see later the same pattern for actors in
channel and its channel configuration CC2. Again, we can see that while the peers and
applications are critical actors in the network, their behaviour in a channel is dictated
more by the channel configuration policy than any other factor.

62
Finally, it is helpful to understand how network and channel configurations are
physically realized. We can see that network and channel configurations are logically
singular – there is one for the network, and one for each channel. This is important;
every component that accesses the network or the channel must have a shared
understanding of the permissions granted to different organizations.

Even though there is logically a single configuration, it is actually replicated and kept
consistent by every node that forms the network or channel. For example, in our network
peer nodes P1 and P2 both have a copy of channel configuration CC1, and by the time
the network is fully complete, peer nodes P2 and P3 will both have a copy of channel
configuration CC2. Similarly ordering service node O4 has a copy of the network
configuration, but in a multi-node configuration, every ordering service node will have
its own copy of the network configuration.

Both network and channel configurations are kept consistent using the same blockchain
technology that is used for user transactions – but for configuration transactions. To
change a network or channel configuration, an administrator must submit a configuration
transaction to change the network or channel configuration. It must be signed by the
organizations identified in the appropriate policy as being responsible for configuration
change. This policy is called the mod_policy and we’ll discuss it later.

Indeed, the ordering service nodes operate a mini-blockchain, connected via the system
channel we mentioned earlier. Using the system channel, ordering service nodes
distribute network configuration transactions. These transactions are used to co-
operatively maintain a consistent copy of the network configuration at each ordering
service node. In a similar way, peer nodes in an application channel can distribute
channel configuration transactions. Likewise, these transactions are used t o maintain a
consistent copy of the channel configuration at each peer node.

This balance between objects that are logically singular, by being physically distributed
is a common pattern in Hyperledger Fabric. Objects like network configurations, that are
logically single, turn out to be physically replicated among a set of ordering services
nodes for example. We also see it with channel configurations, ledgers, and to some
extent smart contracts which are installed in multiple places but whose interfaces e xist
logically at the channel level. It’s a pattern you see repeated time and again in
Hyperledger Fabric, and enables Hyperledger Fabric to be both de-centralized and yet
manageable at the same time.

63
2.2.20 Adding another peer
Now that organization R3 is able to fully participate in channel C2, let’s add its
infrastructure components to the channel. Rather than do this one component at a time,
we’re going to add a peer, its local copy of a ledger, a smart contract and a client
application all at once!

Let’s see the network with organization R3’s components added:

The diagram shows the facts relating to channels C1 and C2 in the network N as follows:
Client applications A1 and A2 can use channel C1 for communication with peers P1 and
P2, and ordering service O4; client applications A3 can use channel C2 for
communication with peer P3 and ordering service O4. Ordering service O4 can make
use of the communication services of channels C1 and C2. Channel configuration CC1
applies to channel C1, CC2 applies to channel C2.

First of all, notice that because peer node P3 is connected to channel C2, it has
a different ledger – L2 – to those peer nodes using channel C1. The ledger L2 is
effectively scoped to channel C2. The ledger L1 is completely separate; it is scop ed to
channel C1. This makes sense – the purpose of the channel C2 is to provide private
communications between the members of the consortium X2, and the ledger L2 is the
private store for their transactions.

In a similar way, the smart contract S6, installed on peer node P3, and committed to
channel C2, is used to provide controlled access to ledger L2. Application A3 can now
use channel C2 to invoke the services provided by smart contract S6 to generate
transactions that can be accepted onto every copy of the ledger L2 in the network.

64
At this point in time, we have a single network that has two completely separate
channels defined within it. These channels provide independently managed facilities for
organizations to transact with each other. Again, this is de-centralization at work; we
have a balance between control and autonomy. This is achieved through policies which
are applied to channels which are controlled by, and affect, different organizations.

2.2.21 Joining a peer to multiple channels

In this final stage of network development, let’s return our focus to organization R2. We
can exploit the fact that R2 is a member of both consortia X1 and X2 by joining it to
multiple channels:

The diagram shows the facts relating to channels C1 and C2 in the net work N as follows:
Client applications A1 can use channel C1 for communication with peers P1 and P2, and
ordering service O4; client application A2 can use channel C1 for communication with
peers P1 and P2 and channel C2 for communication with peers P2 and P3 and ordering
service O4; client application A3 can use channel C2 for communication with peer P3
and P2 and ordering service O4. Ordering service O4 can make use of the
communication services of channels C1 and C2. Channel configuration CC1 applies to
channel C1, CC2 applies to channel C2.

We can see that R2 is a special organization in the network, because it is the only
organization that is a member of two application channels! It is able to transact with
organization R1 on channel C1, while at the same time it can also transact with
organization R3 on a different channel, C2.

65
Notice how peer node P2 has smart contract S5 installed for channel C1 and smart
contract S6 installed for channel C2. Peer node P2 is a full member of both channels at
the same time via different smart contracts for different ledgers.

This is a very powerful concept – channels provide both a mechanism for the separation
of organizations, and a mechanism for collaboration between organizations. All the
while, this infrastructure is provided by, and shared between, a set of independent
organizations.

It is also important to note that peer node P2’s behaviour is controlled very differently
depending upon the channel in which it is transacting. Specifically, the policies
contained in channel configuration CC1 dictate the operations available to P2 when it is
transacting in channel C1, whereas it is the policies in channel configuration CC2 that
control P2’s behaviour in channel C2.

Again, this is desirable – R2 and R1 agreed the rules for channel C1, whereas R2 and R3
agreed the rules for channel C2. These rules were captured in the respective channel
policies – they can and must be used by every component in a channel to enforce correct
behaviour, as agreed.

Similarly, we can see that client application A2 is now able to transact on channels C1
and C2. And likewise, it too will be governed by the policies in the appropriate channel
configurations. As an aside, note that client application A2 and peer node P2 are using a
mixed visual vocabulary – both lines and connections. You can see that they are
equivalent; they are visual synonyms.

2.2.22 The ordering service

The observant reader may notice that the ordering service node appears to be a
centralized component; it was used to create the network initially, and connects to every
channel in the network. Even though we added R1 and R4 to the network configuration
policy NC4 which controls the orderer, the node was running on R4’s infrastructure. In a
world of de-centralization, this looks wrong!

Don’t worry! Our example network showed the simplest ordering service configuration
to help you understand the idea of a network administration point. In fact, the ordering
service can itself too be completely de-centralized! We mentioned earlier that an
ordering service could be comprised of many individual nodes owned by different
organizations, so let’s see how that would be done in our sample network.

66
Let’s have a look at a more realistic ordering service node configuration:

A multi-organization ordering service. The ordering service comprises ordering service

nodes O1 and O4. O1 is provided by organization R1 and node O4 is provided by
organization R4. The network configuration NC4 defines network resource permissions
for actors from both organizations R1 and R4.

We can see that this ordering service completely de-centralized – it runs in organization
R1 and it runs in organization R4. The network configuration policy, NC4, permits R1
and R4 equal rights over network resources. Client applications and peer nodes from
organizations R1 and R4 can manage network resources by connecting to either node O1
or node O4, because both nodes behave the same way, as defined by the policies in
network configuration NC4. In practice, actors from a particular organization tend to use
infrastructure provided by their home organization, but that’s certainly not always the
case.

2.2.23 De-centralized transaction distribution

As well as being the management point for the network, the ordering service also
provides another key facility – it is the distribution point for transactions. The ordering
service is the component which gathers endorsed transactions from applications and
orders them into transaction blocks, which are subsequently distributed to every peer
node in the channel. At each of these committing peers, transactions are recorded,
whether valid or invalid, and their local copy of the ledger updated appropriately.

Notice how the ordering service node O4 performs a very different role for the channel
C1 than it does for the network N. When acting at the channel level, O4’s role is to

67
gather transactions and distribute blocks inside channel C1. It does this according to the
policies defined in channel configuration CC1. In contrast, when acting at the network
level, O4’s role is to provide a management point for network resources according to the
policies defined in network configuration NC4. Notice again how these roles are defined
by different policies within the channel and network configurations respectively. This
should reinforce to you the importance of declarative policy based configuration in
Hyperledger Fabric. Policies both define, and are used to control, the agreed behaviours
by each and every member of a consortium.

We can see that the ordering service, like the other components in Hyperledger Fabric, is
a fully de-centralized component. Whether acting as a network management point, or as
a distributor of blocks in a channel, its nodes can be distributed as required throughout
the multiple organizations in a network.

2.2.24 Changing policy

Throughout our exploration of the sample network, we’ve seen the importance of the
policies to control the behaviour of the actors in the system. We’ve only discussed a few
of the available policies, but there are many that can be declaratively defined to control
every aspect of behaviour. These individual policies are discussed elsewhere in the
documentation.

Most importantly of all, Hyperledger Fabric provides a uniquely powerful policy that
allows network and channel administrators to manage policy change itself! The
underlying philosophy is that policy change is a constant, whether it occurs within or
between organizations, or whether it is imposed by external regulators. For example,
new organizations may join a channel, or existing organizations may have their
permissions increased or decreased. Let’s investigate a little more how change policy is
implemented in Hyperledger Fabric.

The key point of understanding is that policy change is managed by a policy within the
policy itself. The modification policy, or mod_policy for short, is a first class policy
within a network or channel configuration that manages change. Let’s give two brief
examples of how we’ve already used mod_policy to manage change in our network!

The first example was when the network was initially set up. At this time, only
organization R4 was allowed to manage the network. In practice, this was achieved by
making R4 the only organization defined in the network configuration NC4 with

68
permissions to network resources. Moreover, the mod_policy for NC4 only mentioned
organization R4 – only R4 was allowed to change this configuration.

We then evolved the network N to also allow organization R1 to administer the network.
R4 did this by adding R1 to the policies for channel creation and consortium creation.
Because of this change, R1 was able to define the consortia X1 and X2, and create the
channels C1 and C2. R1 had equal administrative rights over the channel and consortium
policies in the network configuration.

R4 however, could grant even more power over the network configuration to R1! R4
could add R1 to the mod_policy such that R1 would be able to manage change of the
network policy too.

This second power is much more powerful than the first, because R1 now has full
control over the network configuration NC4! This means that R1 can, in principle
remove R4’s management rights from the network. In practice, R4 would configure the
mod_policy such that R4 would need to also approve the change, or that all
organizations in the mod_policy would have to approve the change. There’s lots of
flexibility to make the mod_policy as sophisticated as it needs to be to support whatever
change process is required.

This is mod_policy at work – it has allowed the graceful evolution of a basic

configuration into a sophisticated one. All the time this has occurred with the agreement
of all organization involved. The mod_policy behaves like every other policy inside a
network or channel configuration; it defines a set of organizations that are allowed to
change the mod_policy itself.

We’ve only scratched the surface of the power of policies and mod_policy in particular
in this subsection. It is discussed at much more length in the policy topic, but for now
let’s return to our finished network!

2.2.25 Network fully formed

Let’s recap what our network looks like using a consistent visual vocabulary. We’ve re -
organized it slightly using our more compact visual syntax, because it better
accommodates larger topologies:

69
In this diagram we see that the Fabric blockchain network consists of two application
channels and one ordering channel. The organizations R1 and R4 are responsible for the
ordering channel, R1 and R2 are responsible for the blue application channel while R2
and R3 are responsible for the red application channel. Client applications A1 is an
element of organization R1, and CA1 is it’s certificate authority. Note that peer P2 of
organization R2 can use the communication facilities of the blue and the red application
channel. Each application channel has its own channel configuration, in this case CC1
and CC2. The channel configuration of the system channel is part of the network
configuration, NC4.

We’re at the end of our conceptual journey to build a sample Hyperledger Fabric
blockchain network. We’ve created a four organization network with two channels and
three peer nodes, with two smart contracts and an ordering service. It is supported by
four certificate authorities. It provides ledger and smart contract services to three client
applications, who can interact with it via the two channels. Take a moment to look
through the details of the network in the diagram, and feel free to read back through the
topic to reinforce your knowledge, or go to a more detailed topic.

2.3 Mining Mechanism

A peer-to-peer computer process, Blockchain mining is used to secure and verify bitcoin
transactions. Mining involves Blockchain miners who add bitcoin transaction data to
Bitcoin’s global public ledger of past transactions. In the ledgers, blocks are secured by
Blockchain miners and are connected to each other forming a chain.

When we talk in-depth, as opposed to traditional financial services systems, Bitcoins have no
central clearinghouse. Bitcoin transactions are generally verified in decentralized clearing
systems wherein people contribute computing resources to verify the same.

70
This process of verifying transactions is called mining. It is probably referred to as mining as
it is analogous to mining of commodities like gold—mining gold requires a lot of effort and
resources, but then there is a limited supply of gold; hence, the amount of gold that is mined
every year remains roughly the same.

In the same manner, a lot of computing power is consumed in the process of mining bitcoins.
The number of bitcoins that are generated from mining dwindles over time. In the words of
Satoshi Nakamoto, there is only a limited supply of bitcoins. Only 21 million bitcoins will
ever be created.

At its core, the term ‘Blockchain mining’ is used to describe the process of adding transaction
records to the bitcoin blockchain. This process of adding blocks to the Blockchain is how
transactions are processed and how money moves around securely on Bitcoins.

This process of Blockchain mining is performed by a community of people around the world
called ‘Blockchain miners.’

Anyone can apply to become a Blockchain miner. These Blockchain miners install and run a
special Blockchain mining software that enables their computers to communicate securely
with one another.

Once a computer installs the software, joins the network, and begins mining bitcoins, it
becomes what is called a ‘node.’ Together, all these nodes communicate with one another and
process transactions to add new blocks to the blockchain which is commonly known as the
bitcoin network.

This bitcoin network runs throughout the day. It processes equivalent to millions of dollars in
bitcoin transactions and has never been hacked or experienced downtime since its launch in
2009.

At its core, the term ‘Blockchain mining’ is used to describe the process of adding transaction
records to the bitcoin blockchain. This process of adding blocks to the Blockchain is how
transactions are processed and how money moves around securely on Bitcoins.

This process of Blockchain mining is performed by a community of people around the world
called ‘Blockchain miners.’

71
Anyone can apply to become a Blockchain miner. These Blockchain miners install and run a
special Blockchain mining software that enables their computers to communicate securely
with one another.

Once a computer installs the software, joins the network, and begins mining bitcoins, it
becomes what is called a ‘node.’ Together, all these nodes communicate with one another and
process transactions to add new blocks to the blockchain which is commonly known as the
bitcoin network.

This bitcoin network runs throughout the day. It processes equivalent to millions of dollars in
bitcoin transactions and has never been hacked or experienced downtime since its launch in
2009.

2. Pool Mining

In pool mining, a group of users works together to approve the transaction. Sometimes, the
complexity of the data encrypted in the blocks makes it difficult for a user to decrypt the
encoded data alone. So, a group of miners works as a team to solve it. After the validation of
the result, the reward is then split between all users.

3. Cloud Mining

Cloud mining eliminates the need for computer hardware and software. It’s a hassle-free
method to extract blocks. With cloud mining, handling all the machinery, order timings, or
selling profits is no longer a constant worry.

While it is hassle-free, it has its own set of disadvantages. The operational functionality is
limited with the limitations on bitcoin hashing in blockchain. The operational expenses
increase as the reward profits are low. Software upgrades are restricted and so is the
verification process.

72
2.3.1 How can you mine bitcoins?

You can buy and trade for bitcoins, or you can mine them. For mining bitcoins, users are
rewarded in bitcoins. This mechanism forms the pivot around which the bitcoin economy
revolves.

While the cost and difficulty of mining bitcoins individually continue to increase, several
cloud-based mining services have gradually emerged. These services allow individual users
to lease the processing power of mining equipment and mine bitcoins remotely. However,
you can mine bitcoins in person too.

2.3.2 Mining Bitcoins in Cloud

 Obtain a bitcoin wallet: Bitcoins are stored in digital wallets in an encrypted manner.
This will keep your bitcoins safe.
 Secure the wallet: Since there is no ownership of bitcoins, anyone who gains access to
your blockchain wallet can use it without any restriction. So, enable two-factor
authentication and store the wallet on a computer that does not have access to the
Internet or store it on an external device.
 Choose a cloud mining service provider: Cloud mining service providers allow users
to rent processing or hashing power to mine bitcoins remotely. Popular cloud mining
service providers are Genesis Mining and HashFlare.
 Choose a cloud mining package: To choose a package, you will need to decide on
how much you are willing to pay and keep your eyes open to the hashing power the
package will offer. Cloud mining companies will mostly envisage the Return on
Investment (ROI) based on the current market value of Bitcoins.
 Pick a mining pool: This is the best shot you can get to earn bitcoins easily. There are
many mining pools that charge a mere 2 percent of your total earnings. Over here, you
will have to create workers which are basically subaccounts that can be used to track
your contributions to the pool.
 Put your earnings in your own secure wallet: Whenever you witness an ROI, simply
withdraw your earnings and put them in your own secure wallet.

73
2.3.3 Mining Bitcoins on your own

 Purchase custom mining hardware: You need to purchase an Application-specific

Integrated Circuit (ASIC) miner to mine bitcoins. While purchasing an ASIC Blockchain
miner, you should consider its efficacy in hashing power and take note of its pricing
policies.
 Purchase a power supply: Blockchain miners consume a lot of power. So, get a
dependable power supply that is compatible with the ASIC miner that you purchase.
 Obtain a bitcoin wallet: Bitcoins are stored in digital wallets in an encrypted manner.
This will keep your bitcoins safe.
 Secure the wallet: Since there is no ownership on bitcoins, anyone who gains access to
your wallet can use it without any restriction. So, enable two-factor authentication and
store the wallet on a computer that does not have access to the Internet or store it in an
external device.
 Pick a mining pool: This is the best shot you can get to earn bitcoins easily. There are
many mining pools that charge a mere 2 percent of your total earnings. Over here, you
will have to create workers which are basically subaccounts that can be used to track
your contributions to the pool.
 Connect the power supply to the ASIC Blockchain miner.
 Connect the ASIC Blockchain miner to your router.
 Boot up your ASIC miner.
 Enter your router’s IP address in a web browser.
 Find ‘connected devices in the router miner page.
 Find your ASIC miner and click on it to display the device information.
 Copy and paste the IP address of your ASIC miner into your web browser.
 Log in to the ASIC miner with the default username and password that are ‘Root’ and
‘Root.’
 Select ‘Miner Configuration’ to set up the miner according to your preferences.
 Enter the URL, username, and password for your mining pool on the Miner
Configuration page of the ASIC Miner.
 Click ‘Save and Apply’ to save your credentials for future use.
 Start mining and in periodic intervals check your profitability.

74
  Put your earnings in your own secure wallet: Whenever you witness an ROI, simply
withdraw your earnings and put them in your own secure wallet.

2.3.4 Uses of Blockchain Mining

1. Validating Transactions

Bitcoin transactions take place in huge figures every day. Cryptocurrencies function without
a central administrator and the insecurity can be substantial with the transactions that
transpire. So, what is the authentication method with such cryptocurrencies? With each
transaction, new blocks are added to the blockchain in the network and the validation lies in
the mining results from the blockchain miners.

2. Confirming Transactions

Miners work the blockchain mining process to confirm whether the transaction is authentic or
not. All confirmed transactions are then included in the blockchain.

3. Securing Network

To secure the transaction network, bitcoin miners work together. With more users mining the
blockchain, blockchain network security increases. Network security ensures that there are no
fraudulent activities happening with cryptocurrencies.

2.4 .Merkle Patricia Trie

Blockchain has the potential to do many things, however to achieve these things one thing is
vital- Programmability. Ethereum is a programmable blockchain that lets you do many things
making it truly transformational. It runs down a wide variety of applications meeting different
industry needs and purposes. This is the reason that Ethereum accounts and transactions have too
many associated properties which need to be efficiently represented.

If you ask for Ethereum’s key data structure, there is one and only answer- Merkle Patricia Trie.
Ethereum uses the data structure that combines the power of Merkle tree and Patricia trie. The
Merkle Patricia trie is used for representing certain data in the header of an Ethereum block.

75
We have already discussed Merkle tree and Patricia trie. To brief, Merkle tree has pivotal role in
management of blockchain network as it uses the hash representation to save storage space and
speed up search operations. While, Patricia trie is a tree-like data structure used to store (key,
value) pairs. The compression technique in the Patricia trie reduces the storage requirement in the
blockchain.

In Ethereum, each node of the tree is referenced by its hash value, like a Merkle tree. The root
hash acts as a digital fingerprint of the entire data set represented by it. If any key-value is
updated, the Merkle root will also change. Ethereum keys are represented in a hexadecimal
format, which has 16 possible characters ( 0–9 and A-F).

Merkle Patricia trie comprises 4 types of nodes:

1. null: A non-existent node, represented as an empty string.

2. branch: A node that has links to a maximum of 16 distinct child notes, corresponding to
16 hex characters. It has also a value field.
3. leaf: An “end-node” that contains the final part of the key and a value.
4. extension: A “shortcut” node that stores a part of the key based on a common prefix, and
a link to the next node.
-Usually trie is stored in a separate database. The “link” fields in a node stores the hash
value of the next node. This hash value is used as a key to retrieve the actual node from
the database during traversal. Therefore searching a key in the trie requires multiple
database lookups for getting the nodes in the path.

-Leaf nodes and extension nodes have similar structure. So a flag is included at the
beginning of path value to differentiate between them.

2.4.1 Tries in Ethereum

Ethereum uses three trie structures. You might be wondering why multiple tries. Well, it is that
we have to deal with permanent data like transactions in a committed block as well as temporary
data like account balance which gets updated. Data structures are demanded to store them
separately. In Ethereum, every block header stores roots of three trie structures: stateRoot,
transactionRoot, and receiptsRoot.

76
State trie: The state trie / world state trie represents a mapping between account addresses and
the account states. The account state includes the balance, nonce, codeHash, and
storageRoot. The storageRoot itself is the root of an account storage trie, which stores the
contract data associated with an account. Here the key is a 160 bit address of an Ethereum
account and the value is the account state. The root node depends on all internal data and its hash
value acts as a unique identifier for the entire system state.

Ethereum accounts are added to the state trie only after a successful transaction is recorded
against that account. The world state trie stores some temporary data which gets updated,
changing the root hash frequently. The stateRoot is hash of the root node of the state trie, after
every transactions are executed and committed.

Transaction trie: It is created on the list of transactions within a block. The path to a specific
transaction in the transaction trie is tracked based on the position of the transaction within the
block. Once mined, the position of a transaction in a block does not change. So a transaction trie
never gets updated. This is similar to the Merkle tree representation of transactions in Bitcoin and
the transaction verification can be done similarly. The transactionRoot is the hash of the root
node of the transaction trie.

Receipt trie: The receipt records the result of the transaction which is executed successfully. It
consists of four items: status code of the transaction, cumulative gas used, transaction
logs, Bloom filter (a data structure to quickly find logs). Here the key is an index of transactions
in the block and the value is the transaction receipt. Like transaction trie, receipt trie never gets
updated. The receiptsRoot is the hash of the root node of the trie structure populated with the
receipts of each transaction in the transactions list portion of the block;

77
Let us see a simple Merkle-Patricia Trie example used for storing the mapping between account
address and ether balance.

Let us see a simple Merkle-Patricia Trie example used for storing the mapping between account
address and ether balance.

Since the nodes are stored in the database, each node visit will require a database lookup.

2.4.2 Why Merkle Patricia trie ?

We already saw how Merkle Patricia trie combines the advantages of Merkle and Patricia trie.
Now let us look into some of the benefits offered by Merkle Patricia trie.

In case of state trie, it allows quick re-calculation of root hash when updates like changes in
account balance, nonce, etc takes place. The root value entirely depends on data. It does not
depend on the order in which updates are made. So even if updates are done in different order, the
final tree will remain the same.

Hashing helps with easy detection of data changes . If any peer attempts to make alterations to the
data, the root hash will change notifying other peers in the network to identify the change.

Querying is easy without requiring re-computation of the whole trie.

78
Check whether transaction is included in a block ?. Ask transaction trie.

Want to check whether an account is valid ?. Ask state trie

Want to know your account balance ? Ask receipt trie

Devices with limited storage and computation capability( light weight clients) like mobile
applications can make use of this feature for data verification.

The tries are stored in a database. So we can prove that a large amount of data is correct, without
storing the whole data in the blockchain. It reduces the storage overhead of blockchain also.

2.4.3 Merkle Vs Merkle-Patricia

Since we have seen both Merkle tree and Merkle Patricia tree, let us analyze some of the major
differences that keeps them separate.

1. Root of a Merkle Patricia trie does not depend on the order of data. However, Merkle root
depends on order of data, since we are pairing adjacent nodes and taking the hash value.

2. Tree size of Merkle Patricia trie is lower than a standard Merkle tree due to prefix based
compression techniques.

3. Merkle patricia tries are faster than Merkle trees, but the implementation is complicated.

2.5. Gas Limit

Understanding Gas in Ethereum

The concept of gas was introduced to compensate miners for their work done on maintaining
and securing the blockchain. After the proof of stake algorithm was rolled out in September
2022, gas fees became the reward for staking ETH and participating in validation—the more
a user has staked, the more they can earn.

"Gas limit" is the maximum amount of work you're estimating a validator will do on a
particular transaction. A higher gas limit usually means the user believes the transaction will
require more work. "Gas price" is the price per unit of work done. So, a transaction cost is
the gas limit multiplied by the gas price. Many transactions also include tips, which are
added to the gas price (the more you pay, the faster your transaction is completed). The
lower a user estimates their gas limit, the lower the priority in the queue they will be.

Ethereum validators, who perform the essential tasks of verifying and processing
transactions on the network, are awarded this fee in return for staking their ether and
verifying blocks.

79
Another factor to consider is that supply and demand for transactions dictate gas prices—if
the network is congested, gas prices might be high. On the other hand, they could be low if
there is not much traffic.

2.5.1 Gas and the Ethereum Virtual Machine (EVM)

Etherium, as platform and system, is designed to be used by others to create more use cases
for blockchain and crypto currency. For this reason, it is commonly called the Ethereum
Virtual Machine, because applications can be created that run on it. The EVM is essentially
a large virtual computer, like an application in the cloud, that runs other blockchain-based
applications within it.

Many decentralized application, cryptocurrencies, and tokens have been created using the
EVM. Because the Ethereum blockchain is part of the EVM, the cryptocurrencies built on
that blockchain require gas fees. For example, a popular token built on Ethereum's
blockchain is DAI. Because it uses the Ethereum blockchain, users need to pay gas fees in
gwei to conduct transactions on the chain.

What Is Ethereum's Gas Fee Now?

Ethereum's transaction fees continue to fluctuate, but they haven't changed much since proof
of stake rolled out—the update was not intended to change fees.2

What Is a Gas Fee on NFTs?

A gas fee is a blockchain transaction fee, paid to network validators for their services to the
blockchain. Without the fees, there would be no incentive for anyone to stake their ETH and
help secure the network.

Why Do I Have to Pay a Gas Fee?

The Ethereum gas fee exists to pay network validators for their work securing the
blockchain and network.1 Without the fees, there would be few reasons to stake ETH and
become a validator. The network would be at risk without validators and the work they do.

How Is the Gas Fee Calculated?

The gas fee is calculated using Gas Limit * Gas Price per Unit.1 So if the gas limit was
20,000 and the price per unit was 200 gwei, the calculation would be 20,000 * 200 =
4,000,000 gwei or 0.004 ETH.

2.5.2 The Bottom Line

Gas fees are used on the Ethereum blockchain and network as incentives for users to stake
their ETH. Staking works to secure the blackchain because it discourages dishonest
behavior. For staking their ETH, owners are given small payments as a reward for helping to
secure the blockchain and help it function.

Fees are determined by the amount of network traffic, supply of validators, and demand for
transaction verification. The higher the demand and traffic, the higher the fees. When traffic
and demand is lower, fees become lower.

80
2.6. What are transaction fees?

Crypto transaction fees are paid when you do an action on a blockchain. Actions can range
from simple things such as sending a cryptocurrency or digital asset to someone, to using
a DApp to execute a complicated program like taking out a loan. In almost all cases,
transaction fees are paid in a blockchain’s native cryptoasset. Bitcoin transaction fees are paid
in bitcoin and Ethereum transaction fees are paid in Ethereum. As you’d expect, simpler
actions have smaller fees while complicated actions cost more. Additionally, different
blockchains have lower or higher transaction fees for similar actions.

2.6.1 Why do we need transaction fees?

Transaction fees prevent blockchain networks from being flooded with transactions which
prevent legitimate usage of networks. Transaction fees are also paid out to people who help
run and maintain the security of the network. Finally, transaction fees serve as a mechanism
to distribute a potentially scarce resource — blockspace.
The amount of transactions that can be processed in a given time is called blockspace. Every
blockchain has an upper limit of transactions per second (TPS) that can be added. Bitcoin’s
TPS is approximately 5, Ethereum’s is 10, and Avalanche’s is 1000+.
Blockspace creates a supply and demand dynamic. If the demand for blockspace is lower
than the total achievable blockspace (e.g., for Bitcoin, there is less than 5 TPS), the
transaction fee will be low. Conversely, if the demand exceeds the transactions per second,
then the transaction fee will rise commensurate with the demand. Popular blockchains with
low blockspace will almost always have high transaction fees.
During events that create high demand for blockspace, such as NFT mints or even market
meltdowns, transaction fees can be as high as the equivalent of 300 US dollars as people
compete to get their transactions added to the blockchain before others.

2.6.2 How do transaction fees work?

As stated above, transaction fees are paid for actions that take place on a blockchain. Those
actions can be broken into two categories:
1. Adding data to the blockchain.
2. Computational effort performed by the blockchain.

Blockchains lacking general purpose smart contract functionality derive almost all of their
transaction fee from the first category. These are cryptocurrency-like blockchains such as
Bitcoin. For a more in-depth look at how Bitcoin transactions work read the article below.

Blockchains with general purpose smart contract functionality calculate transaction fees using
both categories. Ethereum is the most popular general smart contract blockchain.
Transactions on the Ethereum network are measured by computational effort, called ‘gas.’
For example, sending ETH from one address to another (one of the simplest transactions you
can make on the Ethereum network), may consume 20,000 units of gas. More complicated
transactions require more computational effort and, therefore, consume more gas. If your
transaction involves interacting with several smart contracts, for instance, you may consume
100,000 gas units or more. You can read more about Ethereum gas and how transactions are
calculated in the article below.

81
2.6.3 Customizing transaction fees
The best digital wallets allow you to customize your transaction fees. For example, here's
how Ethereum transaction fees work in the [Link] Wallet:
1. On the "Enter send amount" screen, tap on the "Network fee" icon at the top-left
2. Choose from one of the three following options:
'Eco' means you'll pay a lower fee, but your transaction will take longer
'Fast' strikes the optimal balance between cost and speed
'Fastest' optimizes for speed over cost
The [Link] Wallet constantly monitors the market rate for gas to arrive at the optimal
gas price for each preset mode, but you also have the option to manually customize your 'gas
price' for each transaction. Note that gas prices fluctuate based on Ethereum network
congestion, so whether your transaction is picked up by validators sooner rather than later
depends on the current market rate for gas. You can check gas rates using a tool like Eth Gas
Station and set customized fees based on the market rate for gas. Here's how to set
customized fees in the wallet:
1. On the "Enter send amount" screen, tap on the "Network fee" icon at the bottom-left
2. Select "Advanced fee options." You'll then be prompted to enter your precise desired
gas price for your transaction.
The [Link] Wallet allows you to control the transaction fees for other popular
blockchain networks, including Bitcoin

Blockchain is the next big thing in the tech space, gaining attention from investors,
businesses, and governments, among others. The highly versatile and flexible technology has
an array of features making it integral to various industries and organizations. One most
talked about and probably misunderstood characteristics of blockchain is “Anonymity.”
Blockchain is a decentralized public ledger with traceable transactions imparting it an
immutable nature. In the cryptoverse, anonymity and pseudonymity play important roles in
helping users protect their security and privacy. For personal or financial reasons, many
people use pseudonymous or anonymous addresses to keep their identities hidden on the
blockchain. This allows them to retain a degree of control over their personal information and
maintain their online activities private.
Both anonymity and pseudonymity offer valuable protections and can be used to enhance
privacy and security on the blockchain. It’s important to understand their role in helping you
safeguard your information and maintain control over your digital identity.

2.7 What is Pseudonymity & Anonymity?

Anonymity signifies that your true identity is hidden from the outer world. However, your
online activity is still visible—it cannot be traced back to you, either pseudonymous or
otherwise.
In the context of blockchain, anonymity can be achieved by using pseudonymous addresses,
which are unique strings of characters representing a user’s identity on the blockchain. These
addresses are generated through a cryptographic process and are not directly linked to a
person’s real-world identity. As a result, it is difficult to trace the activities of a particular
user on the blockchain back to their real-world identity.

With pseudonymity, you can create and use a fictional persona to represent yourself,
allowing you to interact with others without revealing your true identity. In the blockchain

82
world, this concept takes even more significance, as pseudonymity can be used to protect
identity while still allowing you to conduct transactions and engage in other activities on the
blockchain. Using a unique pseudonymous identity to represent yourself, you can keep your
personal information unrevealed while still participating in the decentralized network.
It’s noteworthy, that while pseudonymity can offer a high degree of privacy, it’s not the same
as anonymity. All the transactions you make with your pseudonymous identity can still be
linked back to that identity. Consequently, anonymity is a more potent version of privacy
than pseudonymity. However, it also has some downsides, which we will discuss later in this
blog.

2.7.1 Why are pseudonymity and anonymity crucial in the cryptoverse?

The concept of the pseudonym can be understood from the most infamous entity in the
blockchain world—Satoshi Nakamoto—the man behind the creation of bitcoin. Nobody
knows his true identity even a decade after bitcoin’s birth.
Bitcoin and Ethereum—the leading blockchain protocols in the world— have a
pseudonymous operational system. It signifies that user identity remains hidden, but the
activity linked to their wallet stays in the form of a cryptographic address. These addresses
serve to navigate the fund’s flow, which is imperative from the blockchain
security perspective.
On the other hand, some projects like privacy coins deploy complete anonymity. They
prevent transactions from being linked to a particular address, making it harder to trace funds
back to the originating address.

Additionally, they help protect the privacy and security of users. Using a pseudonym or
anonymous address to conduct transactions on the blockchain, users can keep their personal
information private and prevent it from being linked to their online activities. This can be
especially important for people concerned about their digital privacy and self-sovereignty or
who want to avoid being targeted by hackers and other malicious actors.

2.7.2 How do government regulations impact anonymous and pseudonymous

identities?

With blockchain, cryptos, and Web3 gaining prominence among users, the government’s
attention towards this has increased. Many governments, either alone or in partnership with
other governments, have started scrutinizing the sector, with many regulations coming up
frequently.
As the crypto world sieves through many parts of the real world, policymakers are grappling
with its incorporation into the existing financial system. One key concern is how to conduct
“know your customer” or KYC and anti-money laundering checks to hold users accountable
for illegal activity. Since most cryptocurrencies allow for pseudonymous and anonymous
transactions, regulators have primarily focused on regulating centralized
exchanges(CEX). CEX enables users to exchange traditional money (fiat) for
cryptocurrency.
However, government entities can regulate centralized exchanges; decentralized exchanges
with no centralized authority make it difficult to have KYC checks. In the case of DEXes,
there is no intermediary wallet for users to trust.

83
2.7.3 Pseudonymity and Anonymity: Boon or a Bane

As the cryptocurrency industry continues to grow and evolve, both supporters of anonymity
and those who advocate for greater “know your customer” and anti-money laundering checks
have the same goal in mind—maintaining the security of the blockchain and ensuring the
safety of cryptocurrency.

While some crypto enthusiasts may argue that maintaining full pseudonymity and
anonymity is essential for protecting the privacy and promoting free expression, others
believe that greater regulation is necessary to prevent illicit activity. In this rapidly changing
industry, developers and regulators are working to find a balance that preserves the
cryptocurrency community’s values while maintaining the blockchain’s security. It’s a
delicate balance, but one that is necessary to ensure the continued success and growth of the
industry.
Parting thoughts

As cryptocurrency transactions continue to rise in popularity, the values of decentralization

and anonymity stand as a pillar to their success. However, with this growth also comes some
points of concern. One key question is how much decentralization and anonymity are beyond
essential, particularly when the space still awaits government regulations and clarity of their
expression on the crypto and blockchain domain.

Anonymity admirers and regulatory authorities are still looking for a middle ground to
maintain blockchain security in its entirety. Chances are that both have to make some
compromises to ensure a secure crypto and blockchain space.

2.8 What Is a Block Reward?

Bitcoin block rewards are new bitcoins awarded to cryptocurrency miners for being the first
to solve a complex math problem and creating a new block of verified bitcoin transactions.
The miners use networks of computers to do this, and every time a new block is created it is
verified by all the other competing miners. Then a new math problem is introduced and the
miners start over.

2.8.1 Understanding Block Rewards

The block reward provides an incentive for bitcoin miners to process transactions made with
the cryptocurrency. Creating an immutable record of these transactions is vital for bitcoin to
work as intended. The blockchain is like a decentralized bank ledger—one that can't be
altered after being created. The miners are needed to verify the transactions and keep this
ledger up to date. Block rewards, and to a lesser extent, transaction fees, are their payment
for doing so.

Bitcoin was designed so that new bitcoins are created at a consistent pace. So the difficulty
of the math problem is adjusted every two weeks to ensure a steady output of new bitcoins—
roughly one block of transactions every 10 minutes.

2.8.2 Bitcoin's Block Rewards Vs. Ethereum's

Ethereum, bitcoin's main competitor as a cryptocurrency, also relies on block rewards to
provide incentives to miners. With Ethereum, the reward is a digital token called "ether,"
which is rewarded each time a miner succeeds in providing the mathematical proof of a new
block. As with bitcoin, miners are also awarded a transaction fee, known as a "gas" fee.

84
Unlike with bitcoin, there is no limit on the number of Ethereum ether tokens that can be
created, and they are created at a much faster pace—in seconds, versus about 10 minutes. So
the total number of blocks in the Ethereum chain is larger than in the bitcoin chain.

2.8.3 The Future of Bitcoin Block Rewards

To limit inflation, bitcoin creator Satoshi Nakamoto designed bitcoin to ultimately have only
21 million bitcoins. This is why the size of bitcoin block rewards is halved after the creation
of every 210,000 blocks, which takes around four years. At bitcoin's inception in 2009, each
block reward was worth 50 BTC. In May 2020, the block reward was halved a third time to
6.25 BTC. And as of May 2021, there were already 18.7 million bitcoins in existence, or
nearly 90% of the total planned supply.

2.9 Soft and Hard Fork

The decentralized nature of public blockchains (for example, Bitcoin and Ethereum) means
that participants on the network must be able to come to an agreement as to the shared state
of the blockchain(shared public ledger and blocks and the blockchain protocol). Unanimous
consensus amongst the network nodes results in a single blockchain that contains verified
data(transactions) that the network asserts to be correct. However, many times, the nodes in
the network can’t come in a unanimous consensus regarding the future state of the
blockchain. This event leads to forks (like a tuning fork used in experimental science),
meaning that point in which the ideal ‘single’ chain of blocks is split into two or more
chains which are all valid.

2.9.1 FORKS IN BLOCKCHAIN:

In simple terms, Forks in blockchain means copying the code and modifying it to create a
new software or product. In open-source projects Forks are very common and used widely.
So, cryptocurrencies like Ethereum and Bitcoin are decentralized and open software so that
anyone can contribute. As they are open-sources they rely on their communities to make the
software more secure and reliable. Also open source with the help of fork can make user
interface more interactive and look good, helping in gaining more users worldwide. In open
source the code is visible to everyone, anyone can modify, edit, access there is no copyright
claims for such actions.
For example: Tor browser is an open source software, Linux one of the most widely use
Operating system is an open source system, in similar way Bitcoin and Ethereum protocol
are also open sourced.

An example of blockchain fork

85
Moving Ahead:
Lets us see the different types of FORKS one by one:

TYPES OF FORKS

Basically forks are divided into two categories i.e. Codebase Fork and Live Blockchain
Fork. And then Live Blockchain Fork is divided into further two parts i.e. Intentional
Fork and Accidental Fork, as you can see in the above mentioned figure the Intentional
fork is then further divided into two parts i.e. Soft Fork and Hard Fork.

2.9.2 TYPES OF FORKS:

CODEBASE FORK: In codebase blockchain fork you can copy the entire code of a
particular software. Let us take BITCOIN as an example, so suppose you copied the whole
blockchain code and modified it according to your need, say that you decreased the block
creation time, made some crucial changes and created a faster software than BITCOIN and
publish / launch it has a new whole software named against you, by completing the whole
white paper work process. So in these way a new BLOCKCHAIN will be created from an
empty blank ledger. It’s a fact that many of these ALT COINS which are now running on
the blockchain are been made in these way only by using the codebase fork i.e. they have
made little up and down changes in the code of BITCOIN and created their whole new ALT
COIN.

LIVE BLOCKCHAIN FORK: Live Blockchain fork means a running blockchain is been
divided further into two parts or two ways. So in live blockchain at a specific page the
software is same and from that specific point the chain is divided into two parts. So in
context to this fork the Live Blockchain Fork can occur because of two reasons :

 ACCIDENTAL FORK / TEMPORARY FORK: When multiple miners mine a new

block at nearly the same time, the entire network may not agree on the choice of the

86
 new block. Some can accept the block mined by one party, leading to a different chain
of blocks from that point onward while others can agree on the other alternatives (of
blocks) available. Such a situation arises because it takes some finite time for the
information to propagate in the entire blockchain network and hence conflicted opinions
can exist regarding the chronological order of events. In this fork, two or more blocks
have the same block height. Temporary forks resolve themselves eventually when one
of the chain dies out (gets orphaned) because majority of the full nodes choose the other
chain to add new blocks to and sync with. Example (TEMPORARY FORK /
ACCIDENTAL FORK): Temporary forks happen more often than not and a usual event
that triggers this fork is mining of a block by more than one party at nearly the same
time.

 INTENTIONAL FORK: In intentional fork the rules of the blockchain are been
changed, knowing the code of the software and by modifying it intentionally. This gives
rise to two types of forks which can occur based on the backwards-compatibility of the
blockchain protocol and the time instant at which a new block is mined. So Intentional
fork can be of two types:
1. SOFT FORK: When the blockchain protocol is altered in a backwards-compatible
way. In soft fork you tend to add new rules such that they do not clash with the old
rules. That means there is no connection between the old rules and new rules. Rules in
soft fork are tightened. When there is a change in the software that runs on the nodes
(better called as ‘full nodes’) to function as a network participant, the change is such
that the new blocks mined on the basis of new rules (in the Blockchain protocol) are
also considered valid by the old version of the software. This feature is also called as
backwards-compatibility. Example (SOFT FORK): The Bitcoin network’s SegWit
update added a new class of addresses (Bech32). However, this didn’t invalidate the
existing P2SH addresses. A full node with a P2SH type address could do a valid
transaction with a node of Bech32 type address.

2. HARD FORK: When the blockchain protocol is altered in a non backwards-compatible

way. Hard fork is opposite of Soft fork, here the rules are loosened. When there is a
change in the software that runs on the full nodes to function as a network participant,
the change is such that the new blocks mined on the basis of new rules (in the
Blockchain protocol) are not considered valid by the old version of the software. When
hard forks occur, new currency come into existence (with valid original currency) like
in the case of Ethereum (original : Ethereum, new : Ethereum Classic) and Bitcoin
(original : Bitcoin, new : Bitcoin cash). Equivalent quantity of currency is distributed to
the full nodes who choose to upgrade their software so that no material loss occurs.
Such hard forks are often contentious (generating conflicts in the community). The final
decision to join a particular chain rests with the full node. If chosen to join the new
chain, the software has to be upgraded to make newer transactions valid while the nodes
who do not choose to upgrade their software continue working the same. Example
(HARD FORK): The new Casper update in the Ethereum Blockchain in which the
consensus protocol will change from a type of Proof of Work (PoS) to a type of Proof
of Stake (PoS). The nodes which install the Casper update will use the new consensus
protocol. Full nodes that do not choose to install the Casper update will become
incompatible with the full nodes that do.

87
[Link] for the occurrence of a blockchain fork:
 Add new functionality: The Blockchain code is upgraded regularly. Since most public
blockchains are open source, it is developed by people from around the world. The
improvements, issues are created, resolved and new versions are released when the time
is suitable.
 Fix security issues: Blockchain (and cryptocurrency on top of it) is a relatively new
technology as compared to the traditional currency (notes, coins, cheque), research is
still underway to fully understand it. So, versions are bumped and updates are released
to fix the security issues that arise in the way.
 Reverse transactions: The community can actually void all the transaction of a specific
period if they are found to be breached and malicious.

2.9.4 Future of the Blockchain Fork:

The future of blockchain forks is an area of great interest to many blockchain enthusiasts
and experts. While it is difficult to predict with certainty what will happen in the future,
there are some trends and developments that may give us an idea of what to expect.
 One possibility is that we may see more soft forks in the future, as they are generally
less disruptive to the network and require less consensus to implement. Soft forks can
be used to add new features to the blockchain or to improve its efficiency, without
creating a new cryptocurrency.
 Another possibility is that we may see more contentious hard forks in the future, as
different groups within the community have different opinions on the direction of the
blockchain. This could lead to more splits in the community, as some users choose to
continue using the old version of the blockchain while others switch to the new version.
 In recent years, there has also been a trend towards the development of interoperability
protocols and multi-chain architectures, which may reduce the need for forks. These
solutions aim to make it easier for different blockchain networks to communicate with
each other and share data, without the need for a hard fork.
 It is also worth noting that as the blockchain ecosystem continues to mature, there may
be less need for major updates or changes that require a fork. Instead, the focus may
shift towards incremental improvements and optimizations that can be implemented
through soft forks or other means.
 Overall, the future of blockchain forks is likely to be shaped by a combination of
technical developments, community dynamics, and market forces. As blockchain
technology continues to evolve, it will be interesting to see how the role of forks
evolves along with it.

Cryptocurrencies like Bitcoin (BTC) and Ethereum (ETH) are powered by a decentralized
open-source software called a blockchain. A fork is a change to the blockchain’s underlying
protocol. A blockchain fork is an important upgrade to the network and can either represent a
radical change or a minor one and can be initiated by developers or community members.

It requires node operators — machines connected to the blockchain that help validate
transactions on it — to upgrade to the latest version of the protocol. Every node has a copy of
the blockchain and ensures new transactions do not contradict its history.

88
A hard fork is a radical upgrade that can make previous transactions and blocks either valid
or invalid and requires all validators in a network to upgrade to a newer version. It’s not
backward-compatible. A soft fork is an upgrade to the software that is backward-compatible
and has validators in an older version of the chain see the new version as valid.

Effectively, a hard fork, more often than not, leads to a permanent chain separation, as the old
version is no longer compatible with the new version. Those holding tokens on the old chain
are granted tokens on the new one as well because they share the same history. Hard forks
can happen for a number of reasons.

[Link] hard forks

To understand what a hard fork is, it’s essential to first understand blockchain technology. A
blockchain is essentially a chain made out of blocks of data that work as a digital ledger in
which each new block is only valid after the previous one has been confirmed by the network
validators. Data on the blockchain can be traced all the way back to the first-ever transaction
on the network. This is why we can still see the first block on the Bitcoin blockchain.

A hard fork is essentially a permanent divergence from a blockchain’s latest version, leading
to a separation of the blockchain, as some nodes no longer meet consensus, and two different
versions of the network are run separately.

This essentially means that a fork is created on the blockchain where one path keeps
following its current set of rules, while the second path follows a new set of rules. A hard
fork is not backward compatible, so the old version no longer sees the new one as valid.

Hard forks are often seen as dangerous because of the chain split that often occurs. If a split
occurs between the miners who secure the network and the nodes that help validate
transactions, the network itself becomes less secure and more vulnerable to attacks.

A common way to undertake malicious action against a blockchain would be to perform a

51% attack, which is when a cabal of miners manages to have over 51% of the computing
power that secures a network and use it to alter the blockchain’s history. Some networks
created as a result of hard forks have, in fact, suffered numerous 51% attacks where bad
actors double-spent the same funds. These attacks have bad actors leveraging their superior
computing power in the network to reorganize blocks, allowing them to double-spend.

Another vulnerability that’s possible with hard forks is replay attacks. Replay attacks occur
when a malicious entity intercepts a transaction on a forked network and repeats that data on
the other chain. Hard forks without replay attack protection see both transactions become
valid, meaning someone can move another users’ funds without controlling them.

[Link] do hard forks happen?

If hard forks can drastically reduce the security of a blockchain, why do they happen at all?
The answer is simple: Hard forks are upgrades that are necessary to improve the network as
blockchain technology continues to evolve. Several reasons can be behind a hard fork, and
not all of them negative:

89
 Add functionality

 Correct security risks

 Resolve a disagreement within a cryptocurrency’s community

 Reverse transactions on the blockchain

Hard forks can also happen by accident. Often, these incidents are swiftly resolved and those
that were no longer in consensus with the main blockchain fall back and adhere to it after
realizing what had happened. Similarly, hard forks adding functionalities and upgrading the
network usually allow those who fall out of consensus rejoin the main chain.

2.9.7. Accidental hard forks

The Bitcoin blockchain has seen many accidental hard forks throughout its history. These are
more common than one would think and are often resolved so quickly that they are barely
noteworthy.

Most accidental hard forks occur whenever two miners find the same block at nearly the
same time. As consensus on the network is distributed, both initially see the block as valid
and keep mining on different chains before they or another miner adds a subsequent block.

That subsequent block dictates which chain becomes the longer one, meaning that the other is
abandoned to maintain consensus. Miners move on to the longest chain since the abandoned
one is no longer be profitable for mining Bitcoin on, as they would be mining a fork of the
network.

When these forks happen, the miner who found the abandoned block loses coinbase and
transaction fee rewards. However, no transactions would be invalidated as both blocks found
were identical and contained the same transactions.

Other accidental hard forks were part of code issues that led to short-chain splits. In 2013, for
example, a block with a larger number of total transaction inputs than previously seen was
mined and broadcasted, while some nodes did not process it, leading to a split. The issue was
resolved after some nodes downgraded their software to reach consensus and reject this larger
block.

2.9.8. Difference between hard forks and soft forks

Hard forks are not the only way to upgrade the software behind a cryptocurrency. Soft forks
are, by contrast, seen as a safer alternative that is backward compatible, which means that
nodes that do not upgrade to newer versions will still see the chain as valid.

A soft fork can be used to add new features and functions that do not change the rules a
blockchain must follow. Soft forks are often used to implement new features at a
programming level.

90
To better understand the difference between hard forks and soft forks, it can be thought of as
a basic operating system upgrade on a mobile device or a computer. After the upgrade, all the
applications on the device will still work with the new version of the operating system. A
hard fork, in this scenario, would be a complete change to a new operating system.

[Link] hard fork examples

There are numerous historical examples of hard forks in the cryptocurrency world and not all
of them happened with the Bitcoin blockchain. Here are some of the most popular hard forks
in history and how they influenced the industry.

2.9.11.SegWit2x and Bitcoin Cash

SegWit2x was a proposed upgrade designed to help Bitcoin scale. It was set to implement
Segregated Witness (SegWit) and increase the block size limit from one MB to two MB on
the cryptocurrency’s network.

The implementation of SegWit2x was decided in the controversial New York Agreement
reached on May 23, 2017. The agreement saw that a number of Bitcoin business owners and
miners representing over 85% of the network’s hash rate decided the future of BTC behind
closed doors.

SegWit would be implemented through a soft fork, while the block size limit would be
implemented through a hard fork later on. The proposal was controversial because it did not
include any developer behind the main codebase of Bitcoin, Bitcoin Core, and was seen as a
centralizing force — a group of businesses deciding the fate of the network without miners
and nodes reaching consensus. The agreement came after years of debate on scaling Bitcoin.

Small block proponents argued that larger blocks would make it harder to host a full node,
potentially centralizing the cryptocurrency. Those who supported larger blocks argued that
BTC’s rising transaction fees would harm its growth and price some users out of the network.

On Bitcoin’s network, user-activated soft forks are possible. In this scenario, wallet operators,
exchanges and other businesses running full nodes can move to a new version of the
blockchain that will have an activation point in the future, forcing miners on a network to
“fall in line” and activate the new rules. If they don’t, the network could end up splitting.
Bitcoin users campaigned for a user-activated soft fork at the time, in response to the closed-
door meeting dictating the future of Bitcoin and to stop a precedent from being set. They
called for implementing the Bitcoin Improvement Proposal (BIP) 148, which sought to
implement SegWit on the Bitcoin network and argued that SegWit2x was a contentious hard
fork that made the network vulnerable to a replay attack. It was released in March 2017 and
was set to be implemented on August 1, 2017.

Fearing that the SegWit2x plan would not be fulfilled and seeing the community support
SegWit, some big-block supporters decided to fork the Bitcoin blockchain on August 1, 2017.
The result was the creation of Bitcoin Cash (BCH). Its supporters did not see the split as the
creation of a rival network, but rather as the continuation of Satoshi Nakamoto’s original
vision.

91
The Bitcoin Cash blockchain was created with an eight MB block size that has since
increased to 32 MB. To this day, Bitcoin Cash supporters maintain that its low transaction
fees will help it scale and bank the unbanked, believing BTC will be left behind because of its
larger transaction fees.

The Bitcoin Cash hard fork saw the possibility of a hard fork enter the limelight, and shortly
after, numerous other Bitcoin forks were created. These include Bitcoin Gold (BTG), Bitcoin
Diamond (BTCD) and others.

[Link] DAO Hack

Another major historical hard fork was associated with the decentralized autonomous
organization (DAO) that was launched in 2016 on the Ethereum network. Ethereum runs a set
of smart contracts, which are essentially chunks of code that automatically execute whenever
a set of criteria has been met. These contracts make money programmable and are behind
decentralized finance applications (DApps).

At the time, the DAO raised $150 million worth of ETH in one of the earliest crowdfunding
efforts in crypto, before the initial coin offering (ICO) craze of 2017. It was essentially an
early iteration of the decentralized governance models DeFi protocols use, wherein token
holders vote on the future of the protocol.

After its launch, the DAO was hacked for $60 million worth of ETH from 11,000 investors.
At the time, Ethereum was trading below $10, so around 14% of all circulating Ether was
invested in the DAO, and the hack was a major blow to confidence in the network.

A debate within the Ethereum community ensued, as everyone scrambled to figure out how
to respond to the attack. Initially, Ethereum founder Vitalik Buterin proposed a soft fork that
would blacklist the attacker’s address and prevent them from moving the funds.

The attacker, or someone posing as them – responded to the community claiming the funds
had been obtained in a “legal” way and in accordance to the smart contract’s rules. They
claimed they were ready to take legal action against anyone who tried to seize the funds.
Tensions rose as the attacker said they would thwart soft fork attempts by bribing ETH
miners with the funds.

Debate once again ensued until a hard fork was proposed. The hard fork was ultimately
implemented and it rolled back the Ethereum network’s history to before the DAO attack
occurred, reallocating the stolen funds to a smart contract where investors could withdraw
their funds.

The move was extremely controversial, and in the eyes of some, affected the blockchain’s
censorship resistance and immutability: Investors were, in their eyes, being bailed out. Those
who saw things this way rejected the hard fork and supported an earlier version of the
network, now known as Ethereum Classic (ETC).

[Link] Wars: ABC vs. SV

Bitcoin Cash was created through a hard fork of the Bitcoin blockchain in August 2017, and
would later split into two networks as groups within its community feuded. On one side, there

92
was Bitcoin Cash ABC (BCHA), a development team trying to improve the technology
behind it. On the other side, there was Bitcoin Cash SV (BSV), a team supported by self-
proclaimed “Satoshi Nakamoto” Craig Wright, trying to raise the block size from 32 MB to
128 MB.

At block 556,767, the blockchain split in two, and the battle for the BCH ticker symbol
began. Miners on both sides deployed every resource they could to have a hash-rate
advantage over the other. Many were calling for a 51% attack on the other network to
reorganize its blocks, so its proponents would be forced to move to their side.

Cryptocurrency exchanges and other businesses revealed that they would attribute the BCH
ticker to the blockchain that came out on top. Some mining pools diverted all of their
resources to the hash wars, with Bitcoin Cash ABC ultimately having majority of the hash
rate and fending off any 51% attack attempts. It later claimed the BCH ticker on exchanges
and other services, with the other network choosing BSV as its ticker.

[Link] between Public and Private blockchain

1. What is Public Blockchain ?

Public blockchains are open networks that allow anyone to participate in the network i.e.
public blockchain is permissionless. In this type of blockchain anyone can join the network
and read, write, or participate within the blockchain. A public blockchain is decentralized
and does not have a single entity which controls the network. Data on a public blockchain
are secure as it is not possible to modify or alter data once they have been validated on the
blockchain.
Some features of public blockchain are :

 High Security –
It is secure Due to Mining (51% rule).

 Open Environment –
The public blockchain is open for all.

 Anonymous Nature –
In public blockchain every one is anonymous. There is no need to use your real name,
or real identity, therefore everything would stay hidden, and no one can track you based
on that.

 No Regulations –
Public blockchain doesn’t have any regulations that the nodes have to follow. So, there
is no limit to how one can use this platform for their betterment

 Full Transparency –
Public blockchain allow you to see the ledger anytime you want. There is no scope for
any corruption or any discrepancies and everyone has to maintain the ledger and
participate in consensus.

93
 True Decentralization –
In this type of blockchain, there isn’t a centralized entity. Thus, the responsibility of
maintaining the network is solely on the nodes. They are updating the ledger, and it
promotes fairness with help from a consensus algorithm .

 Full User Empowerment –

Typically, in any network user has to follow a lot of rules and regulations. In many
cases, the rules might not even be a fair one. But not in public blockchain networks.
Here, all of the users are empowered as there is no central authority to look over their
every move.

 Immutable –
When something is written to the blockchain, it can not be changed.

 Distributed –
The database is not centralized like in a client-server approach, and all nodes in the
blockchain participate in the transaction validation.

2. What is Private Blockchain ?

A private blockchain is managed by a network administrator and participants need consent
to join the network i.e., a private blockchain is a permissioned blockchain. There are one or
more entities which control the network and this leads to reliance on third-parties to
transact. In this type of blockchain only entity participating in the transaction have
knowledge about the transaction performed whereas others will not able to access it i.e.
transactions are private.
Some of the features of private blockchain are:

 Full Privacy –
It focus on privacy concerns.

 Private Blockchain are more centralized.

 High Efficiency and Faster Transactions –

When you distribute the nodes locally, but also have much less nodes to participate in
the ledger, the performance is faster.

 Better Scalability –
Being able to add nodes and services on demand can provide a great advantage to the
enterprise.

2.10.1 Difference between Public and Private blockchain :

[Link] Basis of Public BlockChain

Comparison Private BlockChain
In this type of blockchain In this type of blockchain
anyone can read, write and read and write is done upon
1. Access – participate in a blockchain. invitation, hence it is a

94
 Hence, it is permissionless permissioned blockchain.
blockchain. It is public to
everyone.
Network Actors
2. – Don’t know each other Know each other
Decentralized
Vs Centralized A public blockchain is A private blockchain is
3. – decentralized. more centralized.
The order of magnitude of
a public blockchain is
lesser than that of a private
blockchain as it is lighter The order of magnitude is
Order Of and provides transactional more as compared to the
4. Magnitude – throughput. public blockchain.

5. Native Token – Yes Not necessary

6. Speed – Slow Fast
Transactions per second Transaction per second is
Transactions are lesser in a public more as compared to public
7. pre second – blockchain. blockchain.
A public network is more
secure due to
decentralization and active
participation. Due to the A private blockchain is
higher number of nodes in more prone to hacks, risks,
the network, it is nearly and data breaches/
impossible for ‘bad actors’ manipulation. It is easy for
to attack the system and bad actors to endanger the
gain control over the entire network. Hence, it is
8. Security – consensus network. less secure.
A public blockchain
consumes more energy
than a private blockchain
as it requires a significant
amount of electrical Private blockchains
Energy resources to function and consume a lot less energy
9. Consumption – achieve network consensus. and power.
Proof of Elapsed Time
Some are proof of work, (PoET), Raft, and Istanbul
Consensus proof of stake, proof of BFT can be used only in
10. algorithms – burn, proof of space etc. case of private blockchains.
In a public blockchain, no
one knows who each
validator is and this In a private blockchain,
increases the risk of there is no chance of minor
potential collision or a collision. Each validator is
51% attack (a group of known and they have the
miners which control more suitable credentials to be a
11. Attacks – than 50% of the network’s part of the network.

95
 computing power.).
Potential to disrupt
current business models
through disintermediation.
There is lower
infrastructure cost. No Reduces transaction cost
need to maintain servers or and data redundancies and
system admins radically. replace legacy systems,
Hence reducing the cost of simplifying documents
creating and running handling and getting rid of
decentralized application semi manual compliance
12. Effects – (dApps). mechanisms.
Bitcoin, Ethereum,
Monero, Zcash, Dash,
Litecoin, Stellar, Steemit R3 (Banks), EWF (Energy),
13. Examples – etc. B3i (Insurance), Corda.

96