UNIT IV HYPERLEDGER FABRIC & ETHEREUM

Architecture of Hyperledger fabric v1.1- chain code- Ethereum: Ethereum network, EVM,
Transaction fee, Mist Browser, Ether, Gas, Solidity.

Architecture of Hyperledger fabric v1.1

Hyperledger Fabric is an open-source platform for building distributed ledger solutions,
with a modular architecture that delivers high degrees of confidentiality, flexibility,
resiliency, and scalability. This enables solutions developed with fabric to be adapted for
any industry. This is a private and confidential blockchain framework managed by the
Linux Foundation.

What is Hyperledger Fabric ?

Hyperledger Fabric is designed for use in enterprise-level applications, and it is
characterized by its modular architecture, permissioned network, and smart contract
functionality, known as “chaincode”.
 The platform provides a high degree of security, privacy, and scalability, and it
supports the development of custom blockchain solutions for various use cases
across industries such as finance, supply chain, and healthcare.
 Hyperledger Fabric operates as a network of nodes, where each node performs a
specific function, such as validating transactions, maintaining the ledger, and
executing chaincode.
 Transactions are validated and ordered by a consensus mechanism, which
ensures the integrity and consistency of the ledger.

How does Hyperledger Fabric Work?

Components:
 Hyperledger fabric is an enterprise-level permission blockchain network. It is
made up of various unique organizations or members that interact with each
other to serve a specific purpose. For example, these organizations can be a
bank, financial institution, or a supply chain network. Each organization is
identified and they have a fabric certificate authority. These organizations are
called members.
 Each member of the fabric can set up one or more authorized peers to participate
in the network using the fabric certificate authority. All of these peers must be
authorized properly.
 There is a client-side application connected to the network written with the
software development kit (SDK) of any particular programming language.
Workflow:
For each and every transaction in the fabric, the following steps are followed-
1. Creation of the proposal: Imagine a deal between a smartphone manufacturer
company and a smartphone dealership. The transaction begins when a member
organization proposes or invokes a transaction request with the help of the client
application or portal. Then the client application sends the proposal to peers in
each organization for endorsement.
2. Endorsement of the transaction: After the proposal reaches the endorser peers
(peers in each organization for endorsement of a proposal) the peer checks the
fabric certificate authority of the requesting member and other details that are
 needed to authenticate the transaction. Then it executes the chain code (a piece
of code that is written in one of the supported languages such as Go or Java) and
returns a response. This response indicates the approval or rejection of the
following transaction. The response is carried out to the client.
3. Submission to ordering service: After receiving the endorsement output, the
approved transactions are sent to the ordering service by the client-side
application. The peer responsible for the ordering service includes the
transaction into a specific block and sends it to the peer nodes of different
members of the network.
4. Updating the ledger: After receiving this block the peer nodes of such
organizations update their local ledger with this block. Hence the new
transactions are now committed.

Hyperledger Fabric Consensus Algorithm

Hyperledger Fabric uses a consensus algorithm to achieve agreement among the
participants in a network on the contents of the shared ledger. The consensus algorithm in
Hyperledger Fabric is pluggable, which means that it can be replaced with a different
algorithm as needed.
The most commonly used consensus algorithms in Hyperledger Fabric are:
 Practical Byzantine Fault Tolerance (PBFT): PBFT is a consensus algorithm
that provides fault tolerance and reliability in a network. It is well-suited for
networks with a limited number of participants who are trusted and well-known.
 RAFT: RAFT is a consensus algorithm that is used to maintain a consistent state
across multiple nodes. It is well-suited for networks where the participants are
unknown and potentially untrusted.
 Solo: Solo is a consensus algorithm that is used for testing purposes in a single-
node network. It is not suitable for production use.
High-level transaction flow and basic components involved

Hyperledger Fabric Basic Transaction Flow

Here when clients submit the transaction proposal through the Fabric SDK, this proposal is

sent to all Endorsing Peers. These endorsing peers check the transaction verifies and executes

and generate the Read and Write set as output. Now, this response is again sent to the client.

The client collects all responses from all endorsing peers, and send them to Orderer.

Now, Orderer sees all transactions and orders them in ascending order and form a block. Now,

this block is sent to all committers which checks the transaction and add a new block in their

own copy of the ledger.

Fabric consist of below major components

 Membership Service Provider(MSP)

 Client

 Peer

 Orderer

Membership Service Provider (MSP)

The membership service provider (MSP), is a component that defines the rules in which,

identities are validated, authenticated, and allowed access to a network. The MSP manages

user IDs and authenticates clients who want to join the network. This includes providing

credentials for these clients to propose transactions. The MSP makes use of a Certificate
Authority, which is a pluggable interface that verifies and revokes user certificates upon

confirmed identity. The default interface used for the MSP is the Fabric-CA API. However,

organizations can implement an External Certificate Authority of their choice. As a result, a

single Hyperledger Fabric network can be controlled by multiple MSPs, where each

organization brings its own favorite.

There are two types of MSPs.

1. Local MSP: It defines users(Clients) and nodes(peers, orderers). It defines who

has administrative or participatory rights at that level.

2. Channel MSP: It defines administrative and participatory rights at the channel

level.
Client

Clients are applications that act on behalf of a person to propose transactions on the network.

The client uses a Fabric SDK in order to communicate with the network. The client

communicates with the SDK in order to Read or Write the data in a Fabric blockchain and an

in-state DB. Even the client is issued with a certificate from the CA authority in order to make

sure that a valid client has initiated the transaction over the network.
Nodes

A “Node” is only a logical function in the sense that multiple nodes of different types can run
on the same physical server. What counts is how nodes are grouped in “trust domains” and

associated with logical entities that control them.

There are three types of nodes:

1. Client: A client that submits an actual transaction-invocation to the endorsers, and

broadcasts transaction-proposals to ordering service. In short, clients

communicate with both peers and the ordering service

2. Peer: A node that commits transactions and maintains the state and a copy of the

ledger. A peer receives ordered state updates in the form of blocks from the

ordering service and maintains the state and the ledger. Besides, peers can have a

special endorser role. The special function of an endorsing peer occurs with
 respect to a particular chaincode and consists in endorsing a transaction before it

is committed.

3. Ordering-service-node or Orderer: a node running the communication service

that implements a delivery guarantee, such as atomic or total order broadcast.

Types of Peers

 Endorsing Peer: Endorsing peers is a special type of committing peers who have

an additional role to endorse a transaction. They endorse the transaction request

which comes from the client. Each endorsing peer possesses the copy of smart

contract installed and a ledger. The main function of Endorser is to simulate the

transaction. It is executed based on the smart contract on the personal copy of the

ledger, and generates the Read/Write sets which are sent to Client. Though during

simulation, the transaction is not committed to the ledger.

 Committing Peer: Peers who commit the block which is received from the

Ordering service, in their own copy of the blockchain. This block contains the list

of transactions where committing peer to validate each transaction and mark it as

either valid or invalid and commits to the block. All transaction either valid or

invalid are all committed to blockchain for future audit purpose.

 Anchor Peer: As Fabric network can extend across multiple organization, we

need some peers to have communication across an organization. Not all peers can

do this, but these are special peers who are only authorized to do so which are

nothing but Anchor peer. The anchor peers are defined in Channel configuration.

 Leading Peer: Leader peers are those who communicate or disseminate messages

from Ordering service to other peers in the same organization. These peers use

Gossip protocol to make sure that every peer receives the message. Leading peers

cannot communicate across an organization. If any Leading peer is not responding

or is out of network, then we can select a leading peer from available peer based

on voting or randomly choose one.

Orderer
In a Blockchain network, transactions have to be written to the shared ledger in a consistent

order. The order of transactions has to be established to ensure that the updates to the world

state are valid when they are committed to the network. Unlike the Bitcoin blockchain, where

ordering occurs through the solving of a cryptographic puzzle, or mining. Hyperledger Fabric

allows the organizations running the network to choose the ordering mechanism that best suits

that network. This modularity and flexibility make Hyperledger Fabric incredibly

advantageous for enterprise applications.

Hyperledger Fabric provides three ordering mechanisms: SOLO, Kafka, and Simplified

Byzantine Fault Tolerance (SBFT), the latter of which has not yet been implemented in Fabric

v1.0.

 SOLO

It is the Hyperledger Fabric ordering mechanism most typically used by

developers experimenting with Hyperledger Fabric networks. SOLO involves a

single ordering node. In this, the transactions are ordered in chronological order to

form a block.

 Kafka

It is the Hyperledger Fabric ordering mechanism that is recommended for

production use. This ordering mechanism utilizes Apache Kafka, an open source
stream processing platform that provides a unified, high-throughput, low-latency

platform for handling real-time data feeds. In this case, the data consists of

endorsed transactions and RW sets. The Kafka mechanism provides a crash fault-

tolerant solution to ordering service.

 SBFT

It stands for Simplified Byzantine Fault Tolerance. This ordering mechanism is

both crash fault-tolerant and byzantine fault-tolerant, meaning that it can reach

agreement even in the presence of malicious or faulty nodes. The Hyperledger

Fabric community has not yet implemented this mechanism, but it is on their

roadmap.
These three ordering mechanisms provide alternate methodologies for agreeing on the order of

transactions.

Other components which are part of the network and yet very important to understand are as

below

 Channels

A fabric network can have multiple channels. Channels allow organizations to utilize the same

network while maintaining separation between multiple blockchains. Only members(peers) of

the channels are allowed to see the transaction created by any member in a channel. In other

words, channels partition the network in order to allow transaction visibility for stakeholders

only. Only the members of the channel are involved in consensus, while other members of the

network do not see the transactions on the channel. The peer can maintain multiple ledgers.

And peer can be connected to multiple channels.

Blue ledger is maintained by P1 and P3, whereas Orange Ledger is maintained by P2 and P4,
but black ledger is maintained by P1, P2, P3 and P4.

The configuration of the channel is maintained by configtx.yaml file. Using this file we

generate channel.tx file and then create a channel using it. Chaincode is installed on all

participating peers in a channel, where as chaincode is instantiated on a channel. A channel

contains all the configurations of communication between peers. It holds the list of peers along

with who are endorsing, anchor, leader peers. When a client communicates with the network

using SDK, the SDK first gets a list of all endorsing peers to which the transaction request

needs to send. Using this list the SDK sends transaction requests to peers. Peers that do

participate in multiple channels simulate and commit transactions to different ledgers.

Orderers are also a part of channels.

 Identity
Each actors in a network peer, orderer, client, admin have some digital identity in the form of

certificate X.509. This identity is used to verify at each and every step of a transaction, in

order to check if the source of the transaction is from a valid source. In addition to the

multitude of endorsement, validity, and versioning checks that take place, there are also

ongoing identity verification happening during each step of the transaction flow.

 Policies

Policies reside in the Channel configuration, but in some cases, it resides in chaincode too. To

define, a policy is a function which accepts as input a set of signed data and evaluates

successfully or returns an error because some aspect of the signed data did not satisfy the

policy. More concretely, policies test whether the signer or signers of some data meet some

condition required for those signatures to be considered ‘valid’.

There are two types of policies

Signature Policy: It is powerful and specifies policy as a combination of evaluation of rules

for MSP principles. It supports a combination of AND, OR and NOutOf.

Implicit Meta policy: This is less flexible and only valid in context for configuration. It

aggregates the result of evaluating policies deeper in the configuration hierarchy, which are

ultimately defined by SignaturePolicies.

 Ledger
It is a current state of the business as a journal of transaction. A ledger consists of two

different parts, a world state, and a blockchain. A ledger is kept at all peers and, optionally,

at a subset of orderers. In the context of an orderer, we refer to the Ledger as to

OrdererLedger, whereas in the context of a peer we refer to the ledger as to PeerLedger.

PeerLedger differs from the OrdererLedger in that peers locally maintain a bitmask that tells

apart valid transactions from invalid ones.

Ledger consists of W-World State and B-Blockchain. Source: hyperledger-
fabric.readthedocs.io

The two different part of Ledger are:

World State: Each chaincode has its own World state and blockchain. It is a DB that holds

the current state of the ledger state. These states are expressed as key-value pairs. It holds the

fact of a business object. It can be created, update and delete. When application submits the

transaction, and when it comes to committing the valid transaction, it first commits in the

World state and then it is updated in ledger. State also has a version number. This version

number changes each time the state is updated. When a ledger is created the world state is

empty, as any transaction which represents a valid change in world state is recorded in

blockchain too. This means world state can be generated at any time from the blockchain. The

state is maintained by Peers only.

Blockchain: A transaction log that records all the changes that have resulted in the current

world state. Its data structure is different as once written cannot be removed. It is immutable. It

is a historical record of facts about how the objects arrived at the current state. It is structured

as a sequential log of interlinked blocks, where each block contains a sequence of transactions,

each transaction representing a query or update to the world state.

Each block header includes a hash of blocks transactions, as well as a copy of a hash of the

previous block’s header. Blockchain is always implemented as a file, not like that of the world

state which uses database. The first block in the chain is the genesis block. Though this is a

starting point of the ledger. It does not contain any transaction details. Instead, it contains

configuration transaction details containing initial state of the network channel.

Blockchain, the previous block is referenced by the current block. Source: hyperledger-
fabric.readthedocs.io

Each Block consists of

Block’s main sections. Source: hyperledger-fabric.readthedocs.io

Header: This consists of 3 fields

 Block number: An integer starting from 0, the genesis block, and incremented

by 1 for each new block appended.

 Current Block Hash: Hash of all transactions contained in a block

 Previous Block Hash: Hash of the previous block.

Data: This consists of a list of transactions arranged in order.

Metadata: It contains time when the block was written, certificate, public key and signature

of block writer. A block committer also adds a valid/invalid indicator for every transaction.

This information is not included in the hash of the block

Each Transaction in a block consists of

Source: hyperledger-fabric.readthedocs.io

Header: Contains essential metadata about the transaction. For example, Name of relevant

chaincode and its version.

Signature: Contains cryptographic signature created by the client application. It is used to

check if the transaction details have not been tampered and require application private key to

generate it.

Proposal: Encodes input parameters supplied by application to the smart contract which

creates proposed ledger update. When the smart contract runs, this proposal provides a set of

input parameters, which, in combination with the current world state, determines the new

world state.

Response: It captures before and after values of world state as Read/Write (RW) set. It is the

output of the smart contract.

Endorsement: This is the list of signed transaction responses from each required organization

sufficient to satisfy the endorsement policy. So here for one transaction proposal, we have

multiple endorsement responses.

Industry Use Cases For Hyperledger Fabric

1. Supply Chain: Supply chains are global or regional webs of suppliers, manufacturers,
and retailers of a particular product. Hyperledger Fabric networks can improve the
transaction processes of the supply chain by increasing the clarity and traceability of
transactions within the fabric. On a Fabric network, enterprises having authentication to
access the ledger can view the data of the previous transactions. This fact increases
accountability and reduces the risk of counterfeiting of the transactions. Real-
time production and shipping updates can be updated to the ledger. Which can help us to
track the product condition in a much faster, simpler, and efficient way.
2. Trading and Asset Transfer: Trading and asset transfer requires many organizations or
members like importers, exporters, banks, brokers. They work with one another. And even
in the era of digitalization a lot of paperwork is going on in this sector. But using
Hyperledger they can transact and interact with each other in a paperless way. The
Hyperledger fabric can add the same layer of trust as the document signed by a trusted
authority. This also increases the performance of the system.
Another benefit of Hyperledger fabric is that assets can be dematerialized on the blockchain
network with the help of Hyperledger fabric. Due to this traders or stakeholders will be able
to have direct access to their financial securities and they can trade it anytime.
3. Insurance: The insurance industry spends billions to avoid insurance frauds or falsified
claims. With the help of Hyperledger fabric, the Insurance company can refer to the
transaction data that is stored inside the ledger. Hyperledger Fabric can also make the
processing of claims faster using the chain code and automate the payment. This process
will be also helpful for multi-party subrogation claims processing. Where it can automate
repayment from the fault party back to the insurance company. Verification of identity or
KYC process will be easy using this private blockchain.
Benefits Of Hyperledger Fabric
1. Open Source: Hyperledger fabric is an open-source blockchain framework hosted by the
Linux foundation. It has an active community of developers The code is designed to be
publicly accessible. Anyone in the community can see, modify, and distribute the code as
they see fit. People across the world can come and help to develop the source code.
2. Private and Confidential: In a public blockchain network each and every node in the
network is receiving a copy of the whole ledger. Thus keeping privacy becomes a much
bigger concern as everything is open to everyone. In addition to this one, the identities of
all the participating members are not known and authenticated. Anyone can participate as it
is a public blockchain. But in the case of Hyperledger fabric, the identities of all
participating members are authenticated. And the ledger is only exposed to the
authenticated members. This benefit is the most useful in industry-level cases, like banking,
insurance, etc where customer data should be kept private.
3. Access Control: In the Hyperledger fabric, there is a virtual blockchain network on top
of the physical blockchain network. It has its own access rules. It employs its own
mechanism for transaction ordering and provides an additional layer of access control. It is
especially useful when members want to limit the exposure of data and make it private.
Such that it can be viewed by the related parties only. As an example when two competitors
are on the same network. The fabric also offers private data collection and accessibility,
where one competitor can control the access to its own data such that the data do not get
exposed to the other competitor.
4. Chaincode Functionality: It includes a container technology to host smart contracts
called chain code that defines the business rules of the system. And it’s designed to support
various pluggable components and to accommodate the complexity that exists across the
entire economy. This is useful for some of the specific types of transactions like asset
ownership change.
5. Performance: As the Hyperledger fabric is a private blockchain network, there is no
need to validate the transactions on this network so the transaction speed is faster, resulting
in a better performance.

Chain Code

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 the chaincode which is deployed to the

blockchain network. Smart contracts are defined within chaincode. Multiple smart contracts
can be defined within a single chaincode. When a chaincode is deployed, all smart contracts

available within the chaincode is made available to the application. We can see that a smart

contract is a domain specific program which relates to specific business processes, whereas a

chaincode is a technical container of a group of related smart contracts for installation and

instantiation. Every chaincode has endorsement policy attached to it, which applies to every

smart contract defined within it. This identifies which organization must sign a transaction

generated by Smart contract, in order to consider it valid. So, in short, every smart contract has

an endorsement policy attached to it. A smart contract can call other smart contracts within a

channel or across different channels.

What is Chaincode in Hyperledger Fabric?

A Chaincode (or “smart contract”) is an application that runs on top of the underlying
architecture to enforce business rules and maintain the state. This application can define its
own data structures, or use the types of services exposed by other chain codes running in
parallel on the same peer node.
 The node that participates in the consensus protocol validates blocks and
distributes them to other peers. Each node has access to all information required
for this task and runs an internal chaincode that enforces business rules.
 Chaincode is the program that is running on a peer node.
 There are many chaincodes out there and they all run the same way, enforcing
business rules on transactions.
 Chaincode can be written in any language supported by the underlying
platform.
Types of Chaincodes in Hyperledger Fabric
In Hyperledger Fabric, there are two different types of chaincodes:
 Orderer Chaincode: This type of chaincode is executed by an orderer node (a
peer with special tagging configured in the network identity). The orderer
executes this chaincode for each transaction and subsequently enforces the
business logic associated with this transaction by representing it as an “Order”
object. The order is then sent to the participants in the peer-to-peer network
(“Peer”) and they are responsible for processing it (as long as they confirm that
the transaction is valid). This type of chaincode is executed by an orderer node
(a peer with special tagging configured in the network identity). The orderer
executes this chaincode for each transaction and subsequently enforces the
business logic associated with this transaction by representing it as an “Order”
object. The order is then sent to the participants in the peer-to-peer network
(“Peer”) and they are responsible for processing it (as long as they confirm that
the transaction is valid).
 Core Chaincode: This type of chaincode is executed by a core node (a peer that
runs multiple chaincodes). The core node has special tagging configured in the
network identity. The core node executes this chaincode for each transaction but
represents it as a new message that is sent using the Messaging service. As
 mentioned above, chaincode will run on the peer nodes within the Hyperledger
Fabric network. When running a chaincode, there are several things that will be
enforced on transactions by chaincode. A peer group can be seen as a logical
cluster of peers that are connected to each other through a leader. Each peer in
this group will be running the chaincode of the same type.
Install and define a chaincode¶
Fabric chaincode lifecycle requires that organizations agree to the parameters that define
a chaincode, such as name, version, and the chaincode endorsement policy. Channel
members come to agreement using the following four steps. Not every organization on a
channel needs to complete each step.

1. Package the chaincode: This step can be completed by one organization or

by each organization.
2. Install the chaincode on your peers: Every organization that will use the
chaincode to endorse a transaction or query the ledger needs to complete this
step.
3. Approve a chaincode definition for your organization: Every organization
that will use the chaincode needs to complete this step. The chaincode
definition needs to be approved by a sufficient number of organizations to
satisfy the channel’s LifecycleEndorsement policy (a majority, by default)
before the chaincode can be started on the channel.
4. Commit the chaincode definition to the channel: The commit transaction
needs to be submitted by one organization once the required number of
organizations on the channel have approved. The submitter first collects
endorsements from enough peers of the organizations that have approved, and
then submits the transaction to commit the chaincode definition.
Step One: Packaging the smart contract
Chaincode needs to be packaged in a tar file before it can be installed on your peers. You
can package a chaincode using the Fabric peer binaries, the Node Fabric SDK, or a third
party tool such as GNU tar. When you create a chaincode package, you need to provide a
chaincode package label to create a succinct and human readable description of the
package.
If you use a third party tool to package the chaincode, the resulting file needs to be in the
format below. The Fabric peer binaries and the Fabric SDKs will automatically create a
file in this format.
 The chaincode needs to be packaged in a tar file, ending with a .tar.gz file

extension.
 The tar file needs to contain two files (no directory): a metadata file
“metadata.json” and another tar “code.tar.gz” containing the chaincode files.
  “metadata.json” contains JSON that specifies the chaincode language, code
path, and package label. You can see an example of a metadata file below:
 {"Path":"fabric-samples/asset-transfer-basic/chaincode-
go","Type":"golang","Label":"basicv1"}

The chaincode is packaged separately by Org1 and Org2. Both organizations use
MYCC_1 as their package label in order to identify the package using the name and
version. It is not necessary for organizations to use the same package label.
Step Two: Install the chaincode on your peers¶
You need to install the chaincode package on every peer that will execute and endorse
transactions. Whether using the CLI or an SDK, you need to complete this step using
your Peer Administrator. Your peer will build the chaincode after the chaincode is
installed, and return a build error if there is a problem with your chaincode. It is
recommended that organizations only package a chaincode once, and then install the
same package on every peer that belongs to their org. If a channel wants to ensure that
each organization is running the same chaincode, one organization can package a
chaincode and send it to other channel members out of band.
A successful install command will return a chaincode package identifier, which is the
package label combined with a hash of the package. This package identifier is used to
associate a chaincode package installed on your peers with a chaincode definition
approved by your organization. Save the identifier for next step. You can also find the
package identifier by querying the packages installed on your peer using the Peer CLI.

A peer administrator from Org1 and Org2 installs the chaincode package MYCC_1 on
the peers joined to the channel. Installing the chaincode package builds the chaincode
and creates a package identifier of MYCC_1:hash.
Step Three: Approve a chaincode definition for your organization¶
The chaincode is governed by a chaincode definition. When channel members approve
a chaincode definition, the approval acts as a vote by an organization on the chaincode
parameters it accepts. These approved organization definitions allow channel members to
agree on a chaincode before it can be used on a channel. The chaincode definition
includes the following parameters, which need to be consistent across organizations:
 Name: The name that applications will use when invoking the chaincode.
 Version: A version number or value associated with a given chaincodes
package. If you upgrade the chaincode binaries, you need to change your
chaincode version as well. Versions may contain any characters, but it is
typical to use a format such as v1.2.3 . The version is not checked by the peer,
it is only an indicator intended to help organizations coordinate as they update
their chaincode logic.
 Sequence: The number of times the chaincode has been defined on a channel.
This value is an integer, and is used to keep track of chaincode upgrades. For
example, when you first approve and commit a chaincode definition on a
channel, the sequence number must be set to 1. When you next upgrade the
chaincode or update the chaincode definition, increment the sequence number
to 2. The sequence number is used by the peer to ensure that all organizations
stay in sync regarding the chaincode definitions that they approve and
commit.
 Endorsement Policy: Which organizations need to execute and validate the
transaction output. The endorsement policy can be expressed as a string
passed to the CLI, or it can reference a policy in the channel config. By
default, the endorsement policy is set to Channel/Application/Endorsement ,
which defaults to require that a majority of organizations in the channel
endorse a transaction.
 Collection Configuration: The path to a private data collection definition file
associated with your chaincode. For more information about private data
collections, see the Private Data architecture reference .
 ESCC/VSCC Plugins: The name of a custom endorsement or validation
plugin to be used by this chaincode.
 Initialization: If you use the low level APIs provided by the Fabric
Chaincode Shim API, your chaincode needs to contain an Init function that is
used to initialize the chaincode. This function is required by the chaincode
interface, but does not necessarily need to invoked by your applications.
When you approve a chaincode definition, you can specify whether Init must
be called prior to Invokes. If you specify that Init is required, Fabric will
 ensure that the Init function is invoked before any other function in the
chaincode and is only invoked once. Requesting the execution of
the Init function allows you to implement logic that is run when the
chaincode is initialized, for example to set some initial state. You will need to
call Init to initialize the chaincode every time you increment the version of a
chaincode, assuming the chaincode definition that increments the version
indicates that Init is required.

If you are using the Fabric peer CLI, you can use the --init-required flag
when you approve and commit the chaincode definition to indicate that
the Init function must be called to initialize the new chaincode version. To
call Init using the Fabric peer CLI, use the peer chaincode invoke command
and pass the --isInit flag.

If you are using the Fabric contract API, you do not need to include
an Init method in your chaincode. However, you can still use the --init-
required flag to request that the chaincode be initialized by a call from your
applications. If you use the --init-required flag, you will need to pass the --
isInit flag or parameter to a chaincode call in order to initialize the chaincode
every time you increment the chaincode version. You can pass --isInit and
initialize the chaincode using any function in your chaincode.

Note that in most scenarios it is recommended to embed initialization logic

into chaincode rather than use the chaincode lifecycle mechanism described
above. Chaincode functions often perform checks against existing state, and
initialization state can be implemented like any other chaincode state and be
checked in subsequent chaincode function calls. Handling initialization state
within chaincode logic rather than with the chaincode lifecycle mechanism
has the benefit that you are not limited to a single initialization function,
rather you are in full control of initialization logic and can call your own
functions that initialize state from an application consistent with how all other
application functions are called.
The chaincode definition also includes the Package Identifier. This is a required
parameter for each organization that wants to use the chaincode. The package ID does
not need to be the same for all organizations. An organization can approve a chaincode
definition without installing a chaincode package or including the identifier in the
definition.
Each channel member that wants to use the chaincode needs to approve a chaincode
definition for their organization. This approval needs to be submitted to the ordering
service, after which it is distributed to all peers. This approval needs to be submitted by
your Organization Administrator. After the approval transaction has been successfully
submitted, the approved definition is stored in a collection that is available to all the
peers of your organization. As a result you only need to approve a chaincode for your
organization once, even if you have multiple peers.

An organization administrator from Org1 and Org2 approve the chaincode definition of
MYCC for their organization. The chaincode definition includes the chaincode name,
version, and the endorsement policy, among other fields. Since both organizations will
use the chaincode to endorse transactions, the approved definitions for both
organizations need to include the packageID.
Step Four: Commit the chaincode definition to the channel¶
Once a sufficient number of channel members have approved a chaincode definition, one
organization can commit the definition to the channel. You can use
the checkcommitreadiness command to check whether committing the chaincode
definition should be successful based on which channel members have approved a
definition before committing it to the channel using the peer CLI. The commit
transaction proposal is first sent to the peers of channel members, who query the
chaincode definition approved for their organizations and endorse the definition if their
organization has approved it. The transaction is then submitted to the ordering service,
which then commits the chaincode definition to the channel. The commit definition
transaction needs to be submitted as the Organization Administrator.
The number of organizations that need to approve a definition before it can be
successfully committed to the channel is governed by
the Channel/Application/LifecycleEndorsement policy. By default, this policy requires
that a majority of organizations in the channel endorse the transaction. The
LifecycleEndorsement policy is separate from the chaincode endorsement policy. For
example, even if a chaincode endorsement policy only requires signatures from one or
two organizations, a majority of channel members still need to approve the chaincode
definition according to the default policy. When committing a channel definition, you
need to target enough peer organizations in the channel to satisfy your
LifecycleEndorsement policy. You can learn more about the Fabric chaincode lifecycle
policies in the Policies concept topic .
You can also set the Channel/Application/LifecycleEndorsement policy to be a
signature policy and explicitly specify the set of organizations on the channel that can
approve a chaincode definition. This allows you to create a channel where a select
number of organizations act as chaincode administrators and govern the business logic
used by the channel. You can also use a signature policy if your channel has a large
number Idemix organizations, which cannot approve chaincode definitions or endorse
chaincode and may prevent the channel from reaching a majority as a result.

One organization administrator from Org1 or Org2 commits the chaincode definition to
the channel. The definition on the channel does not include the packageID.
An organization can approve a chaincode definition without installing the chaincode
package. If an organization does not need to use the chaincode, they can approve a
chaincode definition without a package identifier to ensure that the Lifecycle
Endorsement policy is satisfied.
After the chaincode definition has been committed to the channel, the chaincode
container will launch on all of the peers where the chaincode has been installed, allowing
channel members to start using the chaincode. It may take a few minutes for the
chaincode container to start. You can use the chaincode definition to require the
invocation of the Init function to initialize the chaincode. If the invocation of
the Init function is requested, the first invoke of the chaincode must be a call to
the Init function. The invoke of the Init function is subject to the chaincode
endorsement policy.
Once MYCC is defined on the channel, Org1 and Org2 can start using the chaincode.
The first invoke of the chaincode on each peer starts the chaincode container on that
peer.
Upgrade a chaincode¶
You can upgrade a chaincode using the same Fabric lifecycle process as you used to
install and start the chaincode. You can upgrade the chaincode binaries, or only update
the chaincode policies. Follow these steps to upgrade a chaincode:
1. Repackage the chaincode: You only need to complete this step if you are
upgrading the chaincode binaries.

Org1 and Org2 upgrade the chaincode binaries and repackage the chaincode.
Both organizations use a different package label.
2. Install the new chaincode package on your peers: Once again, you only
need to complete this step if you are upgrading the chaincode binaries.
Installing the new chaincode package will generate a package ID, which you
will need to pass to the new chaincode definition. You also need to change the
chaincode version, which is used by the lifecycle process to track if the
chaincode binaries have been upgraded.
 Org1 and Org2 install the new package on their peers. The installation
creates a new packageID.
3. Approve a new chaincode definition: If you are upgrading the chaincode
binaries, you need to update the chaincode version and the package ID in the
chaincode definition. You can also update your chaincode endorsement policy
without having to repackage your chaincode binaries. Channel members
simply need to approve a definition with the new policy. The new definition
needs to increment the sequence variable in the definition by one.

Organization administrators from Org1 and Org2 approve the new chaincode
definition for their respective organizations. The new definition references the
new packageID and changes the chaincode version. Since this is the first
update of the chaincode, the sequence is incremented from one to two.
4. Commit the definition to the channel: When a sufficient number of channel
members have approved the new chaincode definition, one organization can
commit the new definition to upgrade the chaincode definition to the channel.
There is no separate upgrade command as part of the lifecycle process.
 An organization administrator from Org1 or Org2 commits the new chaincode
definition to the channel.
After you commit the chaincode definition, a new chaincode container will launch with
the code from the upgraded chaincode binaries. If you requested the execution of
the Init function in the chaincode definition, you need to initialize the upgraded
chaincode by invoking the Init function again after the new definition is successfully
committed. If you updated the chaincode definition without changing the chaincode
version, the chaincode container will remain the same and you do not need to
invoke Init function.

Once the new definition has been committed to the channel, each peer will automatically
start the new chaincode container.
The Fabric chaincode lifecycle uses the sequence in the chaincode definition to keep
track of upgrades. All channel members need to increment the sequence number by one
and approve a new definition to upgrade the chaincode. The version parameter is used to
track the chaincode binaries, and needs to be changed only when you upgrade the
chaincode binaries.
Deployment scenarios¶
The following examples illustrate how you can use the Fabric chaincode lifecycle to
manage channels and chaincode.
Joining a channel¶
A new organization can join a channel with a chaincode already defined, and start using
the chaincode after installing the chaincode package and approving the chaincode
definition that has already been committed to the channel.

Org3 joins the channel and approves the same chaincode definition that was previously
committed to the channel by Org1 and Org2.
After approving the chaincode definition, the new organization can start using the
chaincode after the package has been installed on their peers. The definition does not
need to be committed again. If the endorsement policy is set the default policy that
requires endorsements from a majority of channel members, then the endorsement policy
will be updated automatically to include the new organization.
The chaincode container will start after the first invoke of the chaincode on the Org3
peer.
Updating an endorsement policy¶
You can use the chaincode definition to update an endorsement policy without having to
repackage or re-install the chaincode. Channel members can approve a chaincode
definition with a new endorsement policy and commit it to the channel.

Org1, Org2, and Org3 approve a new endorsement policy requiring that all three
organizations endorse a transaction. They increment the definition sequence from one to
two, but do not need to update the chaincode version.
The new endorsement policy will take effect after the new definition is committed to the
channel. Channel members do not have to restart the chaincode container by invoking
the chaincode or executing the Init function in order to update the endorsement policy.
One organization commits the new chaincode definition to the channel to update the
endorsement policy.
Approving a definition without installing the chaincode¶
You can approve a chaincode definition without installing the chaincode package. This
allows you to endorse a chaincode definition before it is committed to the channel, even
if you do not want to use the chaincode to endorse transactions or query the ledger. You
need to approve the same parameters as other members of the channel, but not need to
include the packageID as part of the chaincode definition.

Org3 does not install the chaincode package. As a result, they do not need to provide a
packageID as part of chaincode definition. However, Org3 can still endorse the
definition of MYCC that has been committed to the channel.
One organization disagrees on the chaincode definition¶
An organization that does not approve a chaincode definition that has been committed to
the channel cannot use the chaincode. Organizations that have either not approved a
chaincode definition, or approved a different chaincode definition will not be able to
execute the chaincode on their peers.

Org3 approves a chaincode definition with a different endorsement policy than Org1
and Org2. As a result, Org3 cannot use the MYCC chaincode on the channel. However,
Org1 or Org2 can still get enough endorsements to commit the definition to the channel
and use the chaincode. Transactions from the chaincode will still be added to the ledger
and stored on the Org3 peer. However, the Org3 will not be able to endorse
transactions.
An organization can approve a new chaincode definition with any sequence number or
version. This allows you to approve the definition that has been committed to the
channel and start using the chaincode. You can also approve a new chaincode definition
in order to correct any mistakes made in the process of approving or packaging a
chaincode.
The channel does not agree on a chaincode definition¶
If the organizations on a channel do not agree on a chaincode definition, the definition
cannot be committed to the channel. None of the channel members will be able to use the
chaincode.
Org1, Org2, and Org3 all approve different chaincode definitions. As a result, no
member of the channel can get enough endorsements to commit a chaincode definition to
the channel. No channel member will be able to use the chaincode.
Organizations install different chaincode packages¶
Each organization can use a different packageID when they approve a chaincode
definition. This allows channel members to install different chaincode binaries that use
the same endorsement policy and read and write to data in the same chaincode
namespace.
Organizations can use this capability to install smart contracts that contain business logic
that is specific to their organization. Each organization’s smart contract could contain
additional validation that the organization requires before their peers endorse a
transaction. Each organization can also write code that helps integrate the smart contract
with data from their existing systems.

Org1 and Org2 each install versions of the MYCC chaincode containing business logic
that is specific to their organization.
Creating multiple chaincodes using one package¶
You can use one chaincode package to create multiple chaincode instances on a channel
by approving and committing multiple chaincode definitions. Each definition needs to
specify a different chaincode name. This allows you to run multiple instances of a smart
contract on a channel, but have the contract be subject to different endorsement policies.

Org1 and Org2 use the MYCC_1 chaincode package to approve and commit two
different chaincode definitions. As a result, both peers have two chaincode containers
running on their peers. MYCC1 has an endorsement policy of 1 out of 2, while MYCC2
has an endorsement policy of 2 out of 2.
Ethereum
What is Ethereum?
Ethereum is a Blockchain network that introduced a built-in Turing-complete
programming language that can be used for creating various decentralized applications(also
called Dapps). The Ethereum network is fueled by its own cryptocurrency called ‘ether’.
 The Ethereum network is currently famous for allowing the implementation of
smart contracts. Smart contracts can be thought of as ‘cryptographic bank
lockers’ which contain certain values.
 These cryptographic lockers can only be unlocked when certain conditions are
met.
 Unlike bitcoin, Ethereum is a network that can be applied to various other
sectors.
 Ethereum is often called Blockchain 2.0 since it proved the potential of
blockchain technology beyond the financial sector.
 The consensus mechanism used in Ethereum is Proof of Stakes(PoS) , which is
more energy efficient when compared to that used in the Bitcoin network, that
is, Proof of Work(PoW). PoS depends on the amount of stake a node holds.
How Does Ethereum Work?
Ethereum implements an execution environment called Ethereum Virtual Machine (EVM).
 When a transaction triggers a smart contract all the nodes of the network will
execute every instruction.
  All the nodes will run The EVM as part of the block verification, where the
nodes will go through the transactions listed in the block and runs the code as
triggered by the transaction in the EVM.
 All the nodes on the network must perform the same calculations for keeping
their ledgers in sync.
 Every transaction must include:
 Gas limit.
 Transaction Fee that the sender is willing to pay for the transaction.
 If the total amount of gas needed to process the transaction is less than or equal
to the gas limit then the transaction will be processed and if the total amount of
the gas needed is more than the gas limit then the transaction will not be
processed the fees are still lost.
 Thus it is safe to send transactions with the gas limit above the estimate to
increase the chances of getting it processed.
Components of Ethereum Network :
Component-1 :
Nodes –
There are two types of nodes in an Ethereum network. They are as follows.
1. Mining Node –
These nodes are responsible for writing all the transactions that have occurred in
the Ethereum network in the block.

2. Ethereum Virtual Machine Node –

These are the nodes in the Ethereum network in which Smart Contracts (it is a
type of contract between supporter and developer in which there are a set of
rules based on which both the parties agree to interact with each other. The
agreement will be automatically executed when the pre-defined rules are met.)
are implemented. By default, this node utilizes a 30303 port number for the
purpose of communication among themselves.
Component-2 :
Ether –
 Ether is a type of cryptocurrency used in the Ethereum network just like a
bitcoin is used in a blockchain network. It is a peer-to-peer currency, similar to
Bitcoin. It tracks and promotes each transaction in the network.
 It is the second-largest cryptocurrency in the world. The first one is Bitcoin.
Other cryptocurrencies can be used to get ether tokens, but vice versa is not true.
 It means that ether tokens can’t be interchanged by other cryptocurrencies to
render computing power for Ethereum transactions. Ether is paid as a
commission for any execution that affects the state in Ethereum.
 It is used in the Ethereum algorithm as an incentive for miners who connect
blocks to the blockchain using a proof-of-work method.
 It is the only currency that can be used to pay transaction costs, which go to
miners as well. The block reward, as well as transaction fees, provide miners
with an opportunity to keep the blockchain rising.
 Aside from paying for transactions, ether is often used to purchase gas, which is
used to pay for the computation of any transaction on the Ethereum network.
Component-3 :
Gas –
 Gas is an internal currency of the Ethereum network. We need gas to run
applications on the Ethereum network, much as we need gas to run a vehicle.
  To complete every transaction on the Ethereum network, a consumer must first
make a payment—send out ethers—and the intermediate monetary value is
known as gas.
 Gas is a unit of measurement on the Ethereum network for the computing power
used to execute a smart contract or a transaction.
 The price of gas is very low compared to Ether. The execution and resource
utilization costs are predetermined in Ethereum in terms of Gas units,
called gwei.

Component-4 :
Ethereum Accounts –
There are two types of Ethereum accounts. They are as follows.
1. Externally owned account –
These accounts are used to store transactions.

2. Contract account –
As the name itself suggests, these accounts store the details of Smart Contracts.
Component-5 :
Nonce –
For externally owned accounts, nonce means the number of transactions via this account.
For a contract account, nonce means the number of contracts generated via this account.
Component-6 :
Storage Root –
It is the main root node of a Merkle tree. Hash of all details of the account is stored here.
The root of the Merkle tree is the verification of all transactions.
Component-7 :
Ethash –
The intended PoW algorithm for Ethereum 1.0 is Ethash. It’s the most recent version of
Dagger-Hashimoto, however, it’s no longer proper to call it that because many of the
algorithms’ initial characteristics have been dramatically altered in the previous month of
study and development. The original version may be found here.
Algorithm :
The algorithm follows the following general path as follows.
1. There is a seed for each block that may be determined by reading over the block
headers till that point.
2. A 16 MB pseudo-random cache may be computed from the seed. The cache is
saved by light clients.
3. We can construct a 1 GB dataset from the cache, with the condition that each
item in the dataset is dependent on just a few cache items. The dataset is stored
by full clients and miners. The dataset expands linearly over time.
4. Taking random slices of the dataset and hashing them together is what mining is
all about. Verification may be done with little memory by utilizing the cache to
renew just the parts of the dataset that you require, requiring just the cache to be
stored.

Ethereum Features
 Ether: This is Ethereum’s cryptocurrency.
  Smart contracts: Ethereum allows the development and deployment of these types
of contracts.
 Ethereum Virtual Machine: Ethereum provides the underlying technology—the
architecture and the software—that understands smart contracts and allows you to
interact with it.
 Decentralized applications (Dapps): A decentralized application is called a Dapp
(also spelled DAPP, App, or DApp) for short. Ethereum allows you to create
consolidated applications, called decentralized applications.
 Decentralized autonomous organizations (DAOs): Ethereum allows you to create
these for democratic decision-making.
These are Ethereum’s essential features. Before going deep into the Ethereum tutorial, let’s
discuss each of these features in more detail.
1. Ether
Ether (ETH) is Ethereum’s cryptocurrency. It is the fuel that runs the network. It is used to
pay for the computational resources and the transaction fees for any transaction executed on
the Ethereum network. Like Bitcoins, ether is a peer-to-peer currency. Apart from being used
to pay for transactions, ether is also used to buy gas, which is used to pay for the computation
of any transaction made on the Ethereum network.
Also, if you want to deploy a contract on Ethereum, you will need gas, and you would have
to pay for that gas in ether. So gas is the execution fee paid by a user for running a transaction
in Ethereum. Ether can be utilized for building decentralized applications, building smart
contracts, and making regular peer-to-peer payments.
2. Smart Contracts
Smart contracts are revolutionizing how traditional contracts work, which is why you need to
use the tutorial to become more familiar with them. A smart contract is a simple computer
program that facilitates the exchange of any asset between two parties. It could be money,
shares, property, or any other digital asset that you want to exchange. Anyone on the
Ethereum network can create these contracts. The contract consists primarily of the terms and
conditions mutually agreed on between the parties (peers).
The smart contract’s primary feature is that once it is executed, it cannot be altered, and any
transaction done on top of a smart contract is registered permanently—it is immutable. So
even if you modify the smart contract in the future, the transactions correlated with the
original contract will not get altered; you cannot edit them.
The verification process for the smart contracts is carried out by anonymous parties in the
network without the need for a centralized authority, and that’s what makes any smart
contract execution on Ethereum a decentralized execution.
The transfer of any asset or currency is done in a transparent and trustworthy manner, and the
identities of the two entities are secure on the Ethereum network. Once the transaction is
successfully done, the accounts of the sender and receiver are updated accordingly, and in
this way, it generates trust between the parties.
Smart Contracts Vs. Traditional Contract Systems
In conventional contract systems, you sign an agreement, then you trust and hire a third party
for its execution. The problem is that in this type of process, data tampering is possible. With
smart contracts, the agreement is coded in a program.
A centralized authority does not verify the result; it is confirmed by the participants on the
Ethereum blockchain-based network. Once a contract is executed, the transaction is
registered and cannot be altered or tampered, so it removes the risk of any data manipulation
or alteration.
Let’s take an example in which someone named Zack has given a contract of $500 to
someone named Elsa for developing his company’s website. The developers code the
agreement of the smart contract using Ethereum’s programming language.
The smart contract has all the conditions (requirements) for building the website. Once the
code is written, it is uploaded and deployed on the Ethereum Virtual Machine (EVM).
EVM is a runtime compiler to execute a smart contract. Once the code is deployed on the
EVM, every participant on the network has a copy of the contract. When Elsa submits the
work on Ethereum for evaluation, each node on the Ethereum network will evaluate and
confirm whether the result given by Elsa has been done as per the coding requirements.
Once the result is approved and verified, the contract worth $500 will be self-executed, and
the payment will be paid to Elsa in ether. Zack’s account will be automatically debited, and
Elsa will be credited with $500 in ether.
The Ethereum tutorial video includes a demo on the deployment of an Ethereum smart
contract.
3. Ethereum Virtual Machine
EVM, as mentioned above in this Ethereum tutorial, is designed to operate as a runtime
environment for compiling and deploying Ethereum-based smart contracts. EVM is the
engine that understands the language of smart contracts, which are written in the Solidity
language for Ethereum. EVM is operated in a sandbox environment—basically, you can
deploy your stand-alone environment, which can act as a testing and development
environment. You can then test your smart contract (use it) “n” number of times, verify it,
and once you are satisfied with the performance and the functionality of the smart contract,
you can deploy it on the Ethereum main network.
Any programming language in the smart contract is compiled into the bytecode, which the
EVM understands. This bytecode can be read and executed using the EVM. Solidity is one of
the most popular languages for writing a smart contract. Once you write your smart contract
in Solidity, that contract gets converted into the bytecode and gets deployed on the EVM,
thereby guaranteeing security from cyberattacks.
a) How Does EVM Work?
Suppose person A wants to pay person B 10 ethers. The transaction will be sent to the EVM
using a smart contract for a fund transfer from A to B. To validate the transaction; the
Ethereum network will perform the proof-of-work consensus algorithm.
The miner nodes on Ethereum will validate this transaction—whether the identity of A exists
or not, and if A has the requested amount to transfer. Once the transaction is confirmed, the
ether will be debited from A’s wallet and will be credited to B’s wallet, and during this
process, the miners will charge a fee to validate this transaction and will earn a reward.
All the nodes on the Ethereum network execute smart contracts using their respective EVMs.
b) Proof of Work
Every node in the Ethereum network has:
  The entire history of all the transactions—the entire chain
 The history of the smart contract, which is the address at which the smart contract
is deployed, along with the transactions associated with the smart contract
 The handle to the current state of the smart contract
The goal of the miners on the Ethereum network is to validate the blocks. For each block of a
transaction, miners use their computational power and resources to get the appropriate hash
value by varying the nonce. The miners will vary the nonce and pass it through a hashing
algorithm—in Ethereum, it is the Ethash algorithm.
This produces a hash value that should be less than the predefined target as per the proof-of-
work consensus. If the hash value generated is less than the target value, then the block is
considered to be verified, and the miner gets rewarded.
When the proof of work is solved, the result is broadcast and shared with all the other nodes
to update their ledger. If other nodes accept the hashed block as valid, then the block gets
added to the Ethereum main blockchain, and as a result, the miner receives a reward, which
as of today stands at three ethers. Plus, the miner gets the transaction fees that have been
generated for verifying the block. All the transactions that are aggregated in the block—the
cumulative transaction fees associated with all the transactions are also rewarded to the
miner.
c) Proof of Stake
In Ethereum, a process called proof of stake is also under development. It is an alternative to
proof of work and is meant to be a solution to minimize the use of expensive resources spent
on mining using proof of work. In proof of stake, the miner—who is the validator—can
validate the transactions based on the number of crypto coins he or she holds before actually
starting the mining.
So, based on the accumulation of crypto coins the miner has beforehand, he or she has a
higher probability of mining the block. However, proof of stake is not widely used as of now
compared to proof of work.
d) Gas
Just like we need fuel to run a car, we need gas to run applications on the Ethereum network.
To perform any transaction within the Ethereum network, a user must make a payment, in
this case paying out ethers, to get a transaction done, and the intermediary monetary value is
called gas.
On the Ethereum network, gas is a unit that measures the computational power required to
run a smart contract or a transaction. So, if you must do a transaction that updates the
blockchain, you would have to shell out gas, and that gas costs ethers.
In Ethereum, the transaction fees are calculated using a formula (see screenshot below). For
every transaction, there is gas and its correlated gas price. The transaction fees equal the
amount of gas required to execute a transaction multiplied by the gas price. “Gas limit” refers
to the amount of gas used for the computation and the amount of ether a user is required to
pay for the gas.

4. Decentralized Applications (Dapps)

Let’s compare decentralized applications with traditional applications. When you log in to
Twitter, for example, a web application gets displayed that is rendered using HTML. The
page will call an API to access your data (your information), which is centrally hosted. It’s a
simple process: your front end executes the backend API, and the API goes and fetches your
data from a centralized database.
If we transform this application into a decentralized application when you log in, the same
web application gets rendered, but it calls a smart contract-based API to fetch the information
from the blockchain network. So, the API is replaced by a smart contract interface, and the
smart contract will bring the data from the blockchain network, which is its back end.
That blockchain network is not a centralized database; it’s a decentralized network in which
the participants of the network (the miners) validate (verify) all the transactions that are
happening using the smart contract on the blockchain network. So, any transaction or action
happening on a Twitter-type application that has now been transformed will be a
decentralized transaction.
A Dapp consists of a backing code that runs on a distributed peer-to-peer network. It is a
software designed to work in the Ethereum network without being controlled by a centralized
system, as mentioned, and that is the primary difference: it provides direct interaction
between the end-users and the decentralized application providers.
An application qualifies as a Dapp when it is open-source (its code is on Github), and it uses
a public blockchain-based token to run its applications. A token acts as fuel for the
decentralized application to run. Dapp allows the back end code and data to be decentralized,
and that is the primary architecture of any Dapp.
5. Decentralized Autonomous Organizations (DAOs)
A DAO is a digital organization that operates without hierarchical management; it works in a
decentralized and democratic fashion. So basically, a DAO is an organization in which the
decision-making is not in the hands of a centralized authority but preferably in the hands of
certain designated authorities or a group or designated people as a part of an authority. It
exists on a blockchain network, where it is governed by the protocols embedded in a smart
contract, and thereby, DAOs rely on smart contracts for decision-making—or, we can say,
decentralized voting systems—within the organization. So, before any organizational
decision can be made, it must go through the voting system, which runs on a decentralized
application.
Here’s how it works. People add funds through the DAO because the DAO requires funding
in order to execute and make decisions. Based on that, each member is given a token that
represents that person’s percentage of shares in the DAO. Those tokens are used to vote in
the DAO, and the proposal status is decided based on the maximum votes. Every decision
within the organization must go through this voting process.

What are transaction fees?

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

Why do we need transaction fees?

Transaction fees prevent blockchain networks from being flooded with transactions which
prevent legitimate usage of networks. Transaction fees are also paid out to people who help
run and maintain the security of the network. Finally, transaction fees serve as a mechanism
to distribute a potentially scarce resource — blockspace.

The amount of transactions that can be processed in a given time is called blockspace.
Every blockchain has an upper limit of transactions per second (TPS) that can be added.
Bitcoin’s TPS is approximately 5, Ethereum’s is 10, and Avalanche’s is 1000+.

Blockspace creates a supply and demand dynamic. If the demand for blockspace is lower
than the total achievable blockspace (e.g., for Bitcoin, there is less than 5 TPS), the
transaction fee will be low. Conversely, if the demand exceeds the transactions per second,
then the transaction fee will rise commensurate with the demand. Popular blockchains with
low blockspace will almost always have high transaction fees.

During events that create high demand for blockspace, such as NFT mints or even market
meltdowns, transaction fees can be as high as the equivalent of 300 US dollars as people
compete to get their transactions added to the blockchain before others.

How do transaction fees work?

As stated above, transaction fees are paid for actions that take place on a blockchain. Those
actions can be broken into two categories:
 Adding data to the blockchain.
 Computational effort performed by the blockchain.
Blockchains lacking general purpose smart contract functionality derive almost all of their
transaction fee from the first category. These are cryptocurrency-like blockchains such as
Bitcoin.