Unit Iii BCT

III UNIT-III – BLOCKCHAIN TECHNOLOGY Page No.
:1
BLOCKCHAIN TECHNOLOGY
UNIT III:
Bitcoin Basics:Bitcoin Blockchain, Challenges and solutions, proof of work, proof of stake, alternatives to Bitcoin
consensus, Bitcoin scripting language and their use. Blockchain Network, Life of Blockchain application, Soft & Hard
Fork, Private and Public Blockchain.
BITCOIN
There are a number of currencies in this world used for trading amenities. Rupee, Dollar, Pound Euro, and Yen are
some of them. These are printed currencies and coins and you might be having one of these in your wallet. But
bitcoin is a currency you can not touch, you can not see but you can efficiently use it to trade amenities.
It is an electronically stored currency. It can be stored in your mobiles, computers, or any storage media as a virtual
currency.
Bitcoin is an innovative digital payment system. It is an example of a cryptocurrency and the next big thing in
finance.
 It is a virtual currency designed to act as money and outside the control of any person or group thus eliminating
the need for third-party in financial transactions.
 It is used as a reward for the miners in bitcoin mining.
 It can be purchased on several exchanges.
There are 3 ways you can get a bitcoin in your electronic storage:
1. Trade Money For Bitcoin: Say that the value of a bitcoin is 1 lakh rupees, so if you want a bitcoin, you can
trade a bitcoin in place of 1 lakh rupees. This Bitcoin will further be stored in your electronic storage media
which you can further use.
2. Trade Goods For Bitcoin: Say that the value of a bitcoin is 1 lakh rupees and you have a commodity that has
its value as 1 lakh rupees, so you can trade that commodity in place of a bitcoin, and the bitcoin will be stored
in your electronic storage media.
3. Mine Bitcoins: Other than trading, you can also mine bitcoins. Since it is a decentralized currency, there is no
authority that brings bitcoins into the market. Bitcoins only come into the market by mining them.
Brief History:
“Satoshi Nakamoto” is presumed to be the pen name for the person or people who designed the original bitcoin.
Bitcoin was first introduced in the year 2009 as a medium of exchange. Bitcoin then started as a peer-to-peer
network to generate a system for electronic transactions. Since then, there has been a rapid growth in the usage as
well as the value of bitcoin which is a popular system of digital currency.
Features:
 Distributed: All bitcoin transactions are recorded in a public ledger known as the blockchain. There are nodes
in the network that maintain copies of the ledger and contribute to the correct propagation of the transactions
following the rules of the protocols making it impossible for the network to suffer downtime.
 Decentralized: There is no third party or no CEO who controls the bitcoin network. The network consists of
willing participants who agree to the rules of a protocol and changes to the protocol are done by
the consensus of its users. This makes bitcoin a quasi-political system.
 Transparent: The addition of new transactions to the blockchain ledger and the state of the bitcoin network is
arrived upon by consensus in a transparent manner according to the rules of the protocol.
 Peer-to-peer: In Bitcoin transactions, the payments go straight from one party to another party so there is no
need for any third party to act as an intermediary.
 Censorship resistant: As bitcoin transactions are pseudo-anonymous and users possess the keys to their bitcoin
holdings, so it is difficult for the authorities to ban users from using their assets. This provides economic
freedom to the users.
 Public: All bitcoin transactions are available publicly for everyone to see. All the transactions are recorded,
which eliminates the possibility of fraudulent transactions.
 Permissionless: Bitcoin is completely open access and ready to use for everyone, there are no complicated
rules of entry. Any transaction that follows the set algorithm will be processed with certainty.
 Pseudo-anonymous: Bitcoin transactions are tied to addresses that take the form of randomly generated
alphanumeric strings.
RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

III UNIT-III – BLOCKCHAIN TECHNOLOGY Page No.:2
Value of Bitcoin
A normal piece of paper and a currency note is physically the same but the value of the note is decided by an
authority or a centralized government. But Bitcoin is a currency that does not have any centralized government or
authority to control and decide its value. It is a decentralized digital currency.
 As of now, the value of 1 bitcoin is 23,54,953.68 Indian Rupees but this value fluctuates as there is no
centralized authority to control it.
 In December 2011, the value of a Bitcoin was estimated to be 2 US dollars, in December 2013, it went up to
about 1000 US dollars.
How Do Bitcoin Transactions Work?
Bitcoin transactions are digitally signed for security. Everyone on the network gets to know about a transaction.
Anyone can create a bitcoin wallet by downloading the bitcoin program. Each bitcoin wallet has two things:
 Public key: It is like an address or an account number via which any user or account can receive bitcoins.
 Private key: It is like a digital signature via which anyone can send bitcoins.
The public key can be shared with anyone but the private key must be held by the owner. If the private key gets
hacked or stolen then bitcoin gets lost.
A bitcoin transaction contains three pieces of information:
 Private key: The first part contains the bitcoin wallet address of the sender i.e. the private key.
 Amount of bitcoin to be transferred: The second part contains the amount that has been sent.
 Public key: The third part contains the bitcoin wallet address of the recipient i.e. the public key.
Bitcoin transactions are verified by the nodes on the network. Once the transaction is verified and executed
successfully, the transaction is recorded in a distributed public ledger called a blockchain. A bitcoin can also be
considered as an invisible currency with only the transaction records between different addresses.
How Do Bitcoins Come Into Market?
Bitcoins are a decentralized currency, they aren’t printed, like rupees, they’re produced by people, and big
companies, running computers all around the world, using software that solves mathematical problems.
 Bitcoins are mined using the computing power of the distributed network. This network also processes
transactions made using Bitcoin.
 Bitcoins are mined on the basis of computing power, so they take time to be generated.
 To keep it valuable, it has been stated that only 21 million bitcoins can be created by miners. By the year 2140,
all the bitcoins will be created.
 Around the world, thousands of computers with very high computing power are processing transactions and
securing the network by solving complex mathematical calculations and collecting new bitcoins in exchange.
How Does Bitcoin Mining Work?
In the Bitcoin network, there are nodes that use the computing power of their CPU to process the transactions. The
following are the steps followed while mining a bitcoin:
 The user initiates the bitcoin transaction by listing the details like the number of bitcoins to be sent, and the
public address, and affixing the private key to generate a digital signature. The encrypted information to the
miners present on the network.
 The miners will verify the transaction to check whether there is sufficient balance to carry out the transaction.
 The faster the CPU of a miner, the greater the chances for the miner to get rewarded for verifying the
transaction. The miner’s job is only to provide the CPU, there is no manual intervention from the miner. The
bitcoin program will run automatically on the system.
 Once the transaction is verified, the number of transactions is broadcasted to the network of miners who can
copy or download the block.
 These blocks through timestamps are stored in sequential order to form a blockchain.
 Each miner in the network must have an updated copy of the blockchain ledger in order to earn bitcoins.
How Do You Buy Bitcoin?
There are three ways to get a bitcoin:
1. Buying: Many marketplaces like Bitcoin exchanges allow users to buy or sell bitcoins using different currencies.
If one does not want to mine a bitcoin, it can be bought using a cryptocurrency exchange. Most people will not be
able to purchase the entire BTC due to its price, so it is possible to buy portions of BTC on these exchanges in fiat
currency like U.S. Dollars. The following steps can be followed to buy bitcoin outside the online exchanges:
 Each person who joins the bitcoin network is issued a public key and a private key.
 When a person buys a bitcoin or sends/receives it, the person will receive a public key.
 The person can only access the bitcoin using the private key (it has) with the public key (it received).

2. Mining: People on the bitcoin network compete among themselves to mine bitcoins using computers to solve
complex maths puzzles. This is how bitcoins are created.
3. Transfer: Bitcoin can be transferred from one account to another just like digital cash using mobile applications
or computers.
How is Bitcoin Used?
Below are some of the ways of using bitcoin:
 Payment: Bitcoin is accepted as a mode of payment for goods and services at many merchants, and retailers. To
use bitcoin, wallets are required. cryptocurrency wallets contain private keys to the bitcoin, which need to be
entered while conducting a transaction.
 Investing: portfolio: Bitcoin grew in popularity which made Investors and Individuals interested in investing in
the cryptocurrency Bitcoin. Individuals can invest in Bitcoin to help diversify their portfolio of stocks and
bonds.
Benefits of Bitcoin
The following are some of the advantages of using bitcoins:
 User anonymity: Bitcoin users can have multiple public keys and are identified by numerical codes. This
ensures that the transactions cannot be traced back to the user. Even if the wallet address becomes public, the
user can generate a new wallet address to keep information safe.
 Transparency: Bitcoin transactions are recorded on the public ledger blockchain. The transactions are
permanently viewable, which gives transparency to the system but they are secure and fraud-resistant at the
same time due to blockchain technology.
 Accessibility: Bitcoin is a very versatile and accessible currency. It takes a few minutes to transfer bitcoins to
another user, so it can be used to buy goods and services from a variety of places accepting bitcoins. This
makes spending bitcoin easy in another country with little or no fees applied.
 Independence from central authority: Bitcoin is a decentralized currency, which means there is no
dependence on any single governing authority for verifying transactions. This means that the authorities are not
likely to freeze or demand back the bitcoins.
 Low transaction fees: Standard wire transfers involve transaction fees and exchange costs. Since bitcoin
transactions do not involve any government authority so the transaction fees are very low compared to bank
transfers.
Drawbacks of Bitcoin
The following are some of the cons of using bitcoin:
 Volatility: There are various factors that contribute to the bitcoin’s volatility like uncertainty about its future
value, security breaches, headline-making news, and one of the most important reasons is the scarcity of
bitcoins. It is known that there is a limit of 21 million bitcoins that could ever exist which is why some regard
bitcoin as a scarce resource. This scarcity makes bitcoin’s price variable.
 No government regulations: Unlike the investments that are done through central banks, bitcoins transactions
are not regulated by any central authority due to a decentralized framework. This means that bitcoin’s
transactions don’t come with legal protection and are irreversible which makes them susceptible to crimes.
 No buyer protection: If the goods are bought using bitcoins and the seller does not send the promised goods
then nothing can be done to reverse the transactions and since there is no central authority so no legal protection
can be provided in this case.
 Not widely accepted: Bitcoins are still only accepted by a small group of online merchants. This makes it
unfeasible to rely completely on bitcoin as a currency and replace it with traditional bank transactions.
 Irreversible: There is a lack of security in bitcoin transactions due to the anonymous and non-regulated nature
of the bitcoin transactions. If the wrong amount is sent or the amount is sent to the wrong recipient then nothing
can be done to reverse the transactions.
CHALLENGES AND SOLUTIONS
Cryptocurrency and blockchain technology have taken the financial world by storm, offering a new level of financial
freedom and independence to millions of people. However, widespread adoption of cryptocurrencies faces several
challenges and limitations, including:
1. Lack of Understanding and Trust: Many people still do not understand how cryptocurrencies and blockchain
technology work, leading to concerns about security and volatility that can deter potential adopters. Possible
solutions include increasing public education and outreach, improving user interfaces and customer experience,
and implementing stronger security measures to build trust in the technology.

2. Complexity of Usage: The process of buying, storing, and using cryptocurrencies can be complex for many
people, leading to a barrier to adoption. Possible solutions include the development of simplified, user-friendly
wallets and exchanges, increased integration with traditional financial systems, and partnerships with existing
institutions to provide accessible entry points for new users.
3. Regulatory Uncertainty: The regulatory landscape for cryptocurrencies remains uncertain in many countries,
creating uncertainty for potential adopters and businesses considering incorporating cryptocurrencies into their
operations. Possible solutions include clear and consistent regulation and guidance, collaboration between
regulators and the crypto industry, and advocacy for the technology at a governmental level.
4. Interoperability and Scalability: Cryptocurrencies must be able to seamlessly interact with existing financial
systems and scale to handle increased usage if they are to reach mass adoption. Possible solutions include
development of standardized protocols and API, integration with existing financial infrastructure, and investment
in research and development to improve scalability.
 Addressing these challenges and limitations is crucial for the widespread adoption of cryptocurrencies. For this to
happen, the crypto industry, governments, and regulators need to work together, and the technology needs to keep
getting better and more advanced.
 Bitcoin and other prominent cryptocurrencies have gained much attention over the last several years. Globally
known as digital coin and virtual currency, this cryptocurrency is gained and traded within the blockchain system.
The blockchain technology adopted in using cryptocurrency has raised eyebrows within the banking sector,
government, stakeholders, and individual investors. The rise of the cryptocurrency within this decade since the
inception of Bitcoin in 2009 has taken the market by storm. Cryptocurrency is anticipated as the future currency
that might replace the current paper currency worldwide. Even though the interest has caught the attention of
users, many are not aware of its opportunities, drawbacks, and challenges for the future. Research on
cryptocurrencies is still lacking and still at its infancy stage.
 Bitcoin is the oldest and currently the highest valued cryptocurrency in the market. According to
Coinmarketcap.com, BTC’s present market capitalization is US$825.61 billion. However, bitcoin and many other
cryptocurrencies are faced with several challenges and hurdles. Some of these issues are well-known and are
spoken of quite often, but some have an ethical, social, technological, and political impact, and BTC is currently
facing these issues. This article provides a list of the 10 most prominent challenges faced by bitcoin is presently
facing.
Volatility
Bitcoin has been incredibly volatile since it was created. Experts predict that the price of BTC coins might reach as
high as a million in a few years, and some say that it might even go down to zero. This environment has made bitcoin
extremely popular among investors who believe that the price may rise even more, but it some fall significantly.
Cybertheft
Several guidelines exist to make BTC almost impossible to steal, but taking advantage of this system requires intricate
knowledge about bitcoin’s working system and significantly more effort on the part of the user. In fact, many reports
suggest that buyers lose their investments on exchanges and mining losses. Also, exchanges can be hacked despite the
presence of a smart wallet.
Inability to self-regulate
Due to the lack of accountability on bitcoin, it is difficult to regulate its market behavior solely depending on the
financial incentives. This causes several problems like smart contracts and other hacks plaguing the market, scammers
can create fake investment crowdfunding and then run off with the money, and other related consequences. If bitcoin
cannot be regulated internally, buyers will easily lose confidence to invest.
Tax issues
Presently, under the law, BTC is considered as intangible property, which means they are subjected to capital gains
taxes. If the investors buy bitcoin and sell it at a higher price, they will be required to show the difference in their taxes.
Every time the investors buy something with BTC, it will be a taxable event.
Scalability
The underlying technology behind Bitcoin is blockchain, which limits the amount of information that can be contained
in each block to 1 megabyte of data. This limitation allows the network capacity of three transactions per second. As
more and more transactions are executed, the more difficulty the network will face to keep up the records, resulting in
serious processing delays.
Very less mainstream adoption
Over the years, it has become easier to buy, sell, and use bitcoin, but still there are not many user-friendly investors to
encourage mainstream adoption. If an average person would want to buy BTC, he or she would have to open an

account in a bitcoin exchange like Coinbase, linking their checking account, and then wait several days for the
transaction to clear.
New technology
Cryptocurrency is still a new technology, which came into existence about 10 years ago. These technologies are
changing every day, influencing the market to evolve. The future of BTC is still unclear. Buyers contemplate the
incoming conditions of bitcoin and hesitate to invest.
Reputation for criminal use
In the early days, bitcoin was well known on the Dark Web for money-laundering activities, or to purchase illegal
items. As the only source of anonymous payment, bitcoin became an easy choice for people dealing with drugs, illegal
weapons, and other related items.
Fraud
In addition to hacking, there is a significant amount of fraud in the bitcoin market. With the rise in the popularity of
bitcoin, scammers have created fake exchanges to steal money. Several law-abiding organizations have warned
against these scam activities where unsuspecting investors are duped into fake exchanges.
Limited use
Since bitcoin has turned out to be a new mode of payment, only a few institutions and nations recognize it as an
authorized mode of transaction and as a viable currency.
Patchwork regulation creates uncertainty
Finally, a lack of clear and uniform cryptocurrency regulation — both within and across countries — creates
tremendous uncertainty for long-term investors. It is still unclear in the U.S., for example, when a cryptocurrency falls
under the regulatory framework of a security subject to Securities and Exchange Commission regulations and when it
is deemed to be an asset or commodity like bitcoin and ether have claimed.
Proof Of Work
Proof of work (PoW) is a form of adding new blocks of transactions to a cryptocurrency's blockchain. The work, in
this case, is generating a hash (a long string of characters) that matches the target hash for the current block.
The crypto miner who does this wins the right to add that block to the blockchain and receive rewards.
Cryptocurrency started with proof of work since it's the consensus mechanism used by the first
cryptocurrency, Bitcoin (BTC 6.14%). It's well-known for its security but also for inefficiency and a heavy
environmental impact.
Example of proof of work
Here's an example of how Bitcoin uses proof of work to maintain the integrity of its blockchain.
When Bitcoin transactions occur, they go through a security verification and are grouped into a block to be mined.
Bitcoin's proof-of-work algorithm then generates a hash for the block. The algorithm Bitcoin uses is called SHA-256,
and it always generates hashes with 64 characters.
Miners race to be the first to generate a target hash that's below the block hash. The winner gets to add the latest block
of transactions to Bitcoin's blockchain. They also receive Bitcoin rewards in the form of newly minted coins and
transaction fees. Bitcoin has a fixed maximum supply of 21 million coins, but, after that, miners will continue
receiving transaction fees for their service.
The proof-of-work algorithm used by Bitcoin aims to add a new block every 10 minutes. To do that, it adjusts the
difficulty of mining Bitcoin depending on how quickly miners are adding blocks. If mining is happening too quickly,
the hash computations get harder. If it's going too slowly, they get easier.
Proof Of Stake
Proof of stake (PoS) is an approach used in the cryptocurrency industry to help validate transactions.
When a transaction occurs with a cryptocurrency, a corresponding change on the blockchain on which the
cryptocurrency is based needs to occur. All cryptocurrencies use blockchain technology at the foundation, providing a
distributed ledger of transactions. Blockchain provides a set of distributed nodes in a decentralized approach and
validating that a transaction has occurred requires some form of consensus to ensure integrity.
Validating transactions to the cryptocurrency's blockchain ledger can occur in many different distributed approaches
known as consensus algorithms, including PoS and proof of work (PoW). Both methods achieve the same result of
validating a transaction by adding a new block to the underlying blockchain of the cryptocurrency.
Benefits of proof of stake
The PoS consensus mechanism offers several benefits to the cryptocurrency platforms that support the approach,
including the following:
 Smaller resource requirements. The ability to add a node to the blockchain, requires less computing power.
 Lower energy utilization. With the need for less computing power comes a corresponding decline in the amount
of energy consumed in order to validate a transaction.
 Speed. A node can be added quicker with PoS, enabling faster transaction throughput.
 Scalability. The PoS-based approach has the potential to be more scalable than PoW as the requirements and
resources to have a stake may be lower than the hardware and energy costs of PoW.
Challenges of proof of stake
While there are numerous benefits to using PoS, there are some challenges, including the following:
 Potential for undue influence. A key promise of cryptocurrencies is that they are decentralized. With the need to
stake coins, it is possible that a large stakeholder could exert significant influence on the validation of transactions
on a blockchain network.
 Staking conditions. With PoS, it is possible that the stake will be tied up in a smart contract for a longer period.
 Security concerns. There are concerns that PoS is less secure as there is less effort required for validation and the
potential for influence from large stakeholders. PoS also does not have the same volume of transactions or history
as PoW, and as such has not yet been tested at the same scale.
Proof of stake cryptocurrencies
In the ever-growing world of cryptocurrencies, there is an expanding list of those that use PoS as a consensus
mechanism, including the following:
 Avalanche (AVAX). Avalanche aims to help enable the development of dApps (decentralized applications) and
was created in September 2020.
 Cardano (ADA). Cardano provides smart contract capabilities and was founded in 2015 by the co-founder of
Ethereum, Charles Hoskinson.
 Cosmos (ATOM). Cosmos was created by the Interchain Foundation (ICF) in 2014 to build an open source
blockchain technology.
 EOS (EOS). EOS has its own blockchain that was first publicly released in January 2018 with the aim of
accelerating smart contracts.
 Ethereum (ETH). Ethereum is one of the most widely owned and used cryptocurrencies and moved to PoS in
September 2022.
 Peercoin (PPC). Peercoin claims to have been the first to implement the PoS approach and got its start in 2012.
 Solana (SOL). Solana launched in 2017 and aims to be an efficient platform for transaction processing.
Proof of work vs. proof of stake

Proof of work was the first cryptocurrency consensus mechanism. An alternative, proof of stake, came out in 2012
with the launch of Peercoin (CRYPTO:PPC). It chooses transaction validators based on how many coins they've
staked, or locked up, to the network.
Because proof of stake doesn't require nearly as much computing power as proof of work, it's more scalable. It can
process transactions more quickly for lower fees and with less energy usage, making proof-of-stake cryptocurrencies
more environmentally friendly. It's also much easier to start staking crypto than mining since there's no expensive
hardware required.
Alternatives To Bitcoin Consensus
 Alternative Consensus According to the long wait requirement for confirmation of a transaction in Bitcoin, we
are encountering a trade-off between latency and confidence in a transaction.
 Algorand is a new cryptocurrency designed for confirming transactions on the order of one minute.
 BA* is a Byzantine agreement protocol that Algorand utilize it to reach consensus on a new block with low
latency and without the possibility of forks.
 BA* uses verifiable random functions to randomly select users in a private and non-interactive way.

Algorand solves three main challenges:
 First, it avoids Sybil attacks, where an adversary creates many pseudonyms to affect the Byzantine agreement
protocol. For this purpose, Algorand assigns a weight to each user based on the money in their account. Therefore,
as long as more than 2/3 of the money is owned by honest users Algorand can avoid forks and double-spending.
 Second, Algorand scales to millions of users by the help of BA*. Scalability is achieved by choosing a small set
of representatives randomly selected from the total set of users called a committee to run each step of its protocol.
The committee users are chosen randomly based on the user’s weights.
 At the end, Algorand avoids denial of service attacks and maintain operation even if an adversary disconnects
some of the users. The reason that BA* selects committee members in a private and non-interactive way is to
avoid adversary from targeting committee members. Since membership selection is non-interactive, an adversary
does not know which user to target until the user starts negotiating in BA*.
 In order to prevent an attack to a committee member once that member sends a message in BA*, committee
members speak just once. Based on this algorithm, all users equally participate and new committee members are
elected for each step of the Byzantine agreement protocol.
 Bitcoin-NG (Next Generation) is another blockchain protocol designed to solve the scalability limits of Bitcoin
about the trade off between throughput and latency. BitcoinNG is a Byzantine fault tolerant blockchain protocol
which is robust to extreme churn and scales optimally.
 Performance improvement of Bitcoin-NG is the result of decoupling Bitcoin’s blockchain operation into leader
election and transaction serialization. Bitcoin-NG divides time into epochs and each epoch has a single leader.
This leader is elected randomly and infrequently.
 The responsibility of the leader is to serialize transactions unilaterally and generate blocks until a new leader is
chosen. The protocol introduces two types of blocks.
 Key blocks are for leader election and microblocks contain the ledger entries. Bitcoin also had leader election for
generating blocks, but in Bitcoin there were a long system freeze during the time between leader elections.
 However, Bitcoin-NG ensures that the system is able to continually process transactions by its leader election
mechanism.
BITCOIN SCRIPTING LANGUAGE AND THEIR USES
 Bitcoin Script is the programming language used by Bitcoin to create smart contracts. It's a simple, stack-based
language that allows users to create various conditions for spending their Bitcoin. In this blog, we'll cover the
basics of Bitcoin Script, how it works, and some examples of its use.
Bitcoin Script Overview
 Bitcoin Script is a lightweight programming language that is used to define the conditions under which Bitcoin
transactions can be spent. It's a simple, stack-based language that can be thought of as a set of instructions that
specify how Bitcoin transactions are to be processed.
 The language is used to create "locking" scripts that define the conditions that must be met before Bitcoin can be
spent. These conditions can include things like requiring multiple signatures, a specific time frame, or a specific
transaction output.
How Bitcoin Script Works
 Bitcoin Script is executed by the Bitcoin nodes that process transactions. When a transaction is sent to the Bitcoin
network, each node checks the locking script associated with the transaction to ensure that the conditions are met
before the Bitcoin can be spent.
 If the conditions are not met, the transaction is rejected. If the conditions are met, the transaction is added to the
blockchain, and the Bitcoin is transferred.
 Bitcoin Script is designed to be simple and lightweight, which makes it fast and efficient. However, its simplicity
also means that it has some limitations. For example, Bitcoin Script does not have loops, which means that it
cannot perform repetitive tasks.
Examples of Bitcoin Script
Here are some examples of how Bitcoin Script can be used:
1. Multi-signature wallets - This is a popular use case for Bitcoin Script. Multi-signature wallets require multiple
signatures before Bitcoin can be spent. For example, a 2-of-3 multi-signature wallet would require two out of
three parties to sign the transaction before it can be processed.
2. Time-locked transactions - Bitcoin Script can also be used to create time-locked transactions, which can be useful
in a variety of scenarios. For example, a time-locked transaction can be set up to only be processed after a
specific date and time.

3. Escrow transactions - Escrow transactions are another common use case for Bitcoin Script. An escrow
transaction allows two parties to send Bitcoin to a third party, who will hold the Bitcoin until certain conditions
are met. For example, the Bitcoin might be released to one party once a product has been delivered.
4. Bitcoin wallets - Bitcoin wallets like Electrum, Bitcoin Core, and Trezor all use Bitcoin Script to create and
verify transactions.
5. Bitcoin exchanges - Bitcoin exchanges like Coinbase, Binance, and Kraken all use Bitcoin Script to process
transactions on their platforms.
6. Decentralized applications (dApps) - Many decentralized applications built on top of the Bitcoin network use
Bitcoin Script to create smart contracts. For example, the Lightning Network, which is a layer-2 scaling solution
for Bitcoin, uses Bitcoin Script to enable instant micropayments.
7. Bitcoin payment processors - Bitcoin payment processors like BitPay and CoinPayments use Bitcoin Script to
process payments and verify transactions.
8. Gambling sites - Some online gambling sites use Bitcoin Script to create provably fair games. These games use
cryptographic algorithms to ensure that the outcome of each game is fair and random.
9. Blockchain explorers - Blockchain explorers like Blockchair and Blockchain.info use Bitcoin Script to parse and
analyze transactions on the Bitcoin network.
BLOCKCHAIN NETWORK
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 understanding 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.
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 implements 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
applications consume the ledger and smart contract services provided by the blockchain 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.
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.
Certificate Authorities
We 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.
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 grant 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.
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:
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.
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.
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.
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.
 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.
 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.
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.
 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.
Applications and Smart Contract Chain code
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 order-er 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 chain code, S5. Think of 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.
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.
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.
A sufficient number of organizations need to approve a chaincode definition (A majority, 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.
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.
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.
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.
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.
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.
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.
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.
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.
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 organization 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 peer 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.
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?
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.
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:
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.
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 visual styles – channel C1 is represented with
blue circular end points, whereas channel C2 is represented with red connecting lines:
 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.
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.
 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 to 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 exist 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.
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 scoped 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.
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.
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 network 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.
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.
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.
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.

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 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.
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 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!
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:

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.
NETWORK COMPONENTS
Here’s a quick summary of the network components we’ve discussed:
 Ledger. One per channel. Comprised of the Blockchain and the World state
 Smart contract (aka chaincode)
 Peer nodes
 Ordering service
 Channel
 Certificate Authority
LIFE OF BLOCKCHAIN APPLICATION
Blockchain technology is mostly about the transactions that we make digitally for ourselves. Eventually, these
transactions make their way to the various blocks that become part of the Blockchain later on. So, it is important to
understand the transaction life cycle in Blockchain technology.
This lifecycle follows the journey of a single transaction as it makes its way through each stage in the process of
joining the blockchain. Transaction in simple words is the process of sending money by the sender and the receiver
receiving it. The Blockchain transaction is also quite similar, but it is made digitally.
Let us understand the various stages in a blockchain transaction life cycle with the help of an example.
Sourav and Suraj are two Bitcoin users. Sourav wants to send 1 bitcoin to Suraj.
1. First, Sourav gets Suraj’s wallet address (a wallet in the blockchain is a digital wallet that allows users to
manage their transactions). Using this information, he creates a new transaction for 1 bitcoins from his wallet
and includes a transaction fee of 0.003 bitcoin.
2. Next, he verifies the information and sends the transaction. Each transaction that is initiated is signed by a
digital signature of the sender that is basically the private key of the sender. This is done in order to make the
transaction more secure and to prevent any fraud.
3. Sourav’s wallet then starts the transaction signing algorithm which signs his transaction using his private key.
4. The transaction is now broadcasted to the memory pool within the network.
5. This transaction is eventually accepted by the miners. These miners, group this transaction into a block, find
the Proof of Work, and assign this block a hash value to be mapped into the blockchain.
6. This block is now placed on the Blockchain.
7. As this block gains confirmation, it is accepted as a valid transaction in the network.
8. Once this transaction is accepted, Suraj finally gets his bitcoin.
The below diagram is a pictorial representation of the various stages in a transaction life cycle as discussed above.
Transaction life-cycle in Blockchain
SOFT & HARD FORK

BLOCKCHAIN FORKS
 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.
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 GeeksforGeeks blockchain fork
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.
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 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.
Reasons 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.
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.
 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.
PRIVATE AND PUBLIC BLOCKCHAIN
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.
 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.
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.
Difference between Public and Private blockchain
Basis of
S.no Public BlockChain Private BlockChain
Comparison
1. Access In this type of blockchain anyone can read, In this type of blockchain read and write is
write and participate in a blockchain. Hence, done upon invitation, hence it is a
it is permissionless blockchain. It is public to permissioned blockchain.

everyone.
2. Network Actors Don’t know each other Know each other
3. Decentralized A public blockchain is decentralized. A private blockchain is more centralized.

Vs Centralized
4. Order Of The order of magnitude of a public The order of magnitude is more as

Magnitude blockchain is lesser than that of a private compared to the public blockchain.
blockchain as it is lighter and provides
transactional throughput.
5. Native Token Yes Not necessary
6. Speed Slow Fast
7. Transactions pre Transactions per second are lesser in a public Transaction per second is more as
second blockchain. compared to public blockchain.
8. Security A public network is more secure due to A private blockchain is more prone to
decentralization and active participation. Due hacks, risks, and data breaches/
to the higher number of nodes in the network, manipulation. It is easy for bad actors to
it is nearly impossible for ‘bad actors’ to endanger the entire network. Hence, it is
attack the system and gain control over the less secure.
consensus network.
9. Energy A public blockchain consumes more energy Private blockchains consume a lot less
Consumption than a private blockchain as it requires a energy and power.
significant amount of electrical resources to
function and achieve network consensus.
10. Consensus Some are proof of work, proof of stake, proof Proof of Elapsed Time (PoET), Raft, and
algorithms of burn, proof of space etc. Istanbul BFT can be used only in case of
private blockchains.
11. Attacks In a public blockchain, no one knows who In a private blockchain, there is no chance
each validator is and this increases the risk of of minor collision. Each validator is known
potential collision or a 51% attack (a group of and they have the suitable credentials to be
miners which control more than 50% of the a part of the network.
network’s computing power.).
12. Effects Potential to disrupt current business models Reduces transaction cost and data
through disintermediation. There is lower redundancies and replace legacy systems,
infrastructure cost. No need to maintain simplifying documents handling and
servers or system admins radically. Hence getting rid of semi manual compliance
reducing the cost of creating and running mechanisms.
decentralized application (dApps).
13. Examples Bitcoin, Ethereum, Monero, Zcash, Dash, R3 (Banks), EWF (Energy), B3i
Litecoin, Stellar, Steemit etc. (Insurance), Corda.
----------------UNIT-III----------------

Unit Iii BCT

Uploaded by

Document Informationclick to expand document informationBlock Chain Technology Unit 3 Notes

Document Informationclick to expand document information

Copyright:

Available Formats

Unit Iii BCT

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit Iii BCT

Uploaded by

Copyright:

Available Formats

III UNIT-III – BLOCKCHAIN TECHNOLOGY Page No.

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

Proof of work vs. proof of stake

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

What is a blockchain network?

The sample network:

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

Adding Network Administrators

Creating a channel for a consortium

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

Peers and Ledgers

Applications and Smart Contract Chain code

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

Simplifying the visual vocabulary

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

De-centralized transaction distribution

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

Transaction life-cycle in Blockchain

SOFT & HARD FORK

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

An example GeeksforGeeks blockchain fork

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

FUTURE OF THE BLOCKCHAIN FORK:

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

2. Network Actors Don’t know each other Know each other

3. Decentralized A public blockchain is decentralized. A private blockchain is more centralized.

4. Order Of The order of magnitude of a public The order of magnitude is more as

5. Native Token Yes Not necessary

6. Speed Slow Fast

RAJESWARI COLLEGE OF ARTS AND SCIENCE FOR WOMEN,BOMMAYAPALAYAM-MS.K.RATHI DEVI-DEPT. OF CS

You might also like