0% found this document useful (0 votes)
54 views21 pages

Blockchain Intermedio

Fresco Blockchain Intermedio Slides
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
54 views21 pages

Blockchain Intermedio

Fresco Blockchain Intermedio Slides
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 21

Blockchain Intermedio

Prelude
Welcome to the course Blockchain Intermedio. This course is a continuation of the
course - Blockchain - Potentes Nexus.

If you want to touch upon blockchain basics, please visit the previous course.
However, if you are ready to dive deeper into blockchain, then let's proceed with
the next set of topics.

Distributed System
An understanding of distributed systems is critical to understanding blockchain
technology, as blockchain is a distributed system at its core. A distributed system
can be centralized or decentralized.
A distributed system is a network of autonomous computers(processors) that are
connected together to form a system in which they communicate and share resources
to perform a specific task.
The independent computing units of the distributed systems are known as Nodes.
Coordination among different nodes in the presence of corrupted nodes or in case of
network failure is the primary challenge faced by the distributed systems.

CAP Theorem
CAP Theorem
CAP Theorem is a design principle/ tool that is used to design a Distributed
Systems. It states that Distributed systems cannot achieve Consistency,
Availability, and Partition Tolerance simultaneously.

Consistency: At any given time, all nodes in the network must return the same,
recent value.

Availability: Every working node in the network must return a response to a request
within a specific amount of time.

Partition Tolerance: The network continues to operate, even if the nodes are
partitioned and cannot communicate with each other for an arbitrary length of time.

Byzantine General's Problem


In Byzantine General's Problem, a group of generals plans to attack a city from
different parts, for the attack to be successful all the generals have to attack
simultaneously.
The Generals coordinate their attack by communicating through messages. The
messages passed between generals can get changed or altered by a treacherous
general.
In Distributed systems, the generals are analogous to nodes and the treacherous
generals are the malicious/corrupted node also known as Byzantine nodes.
Distributed systems like blockchains have to devise solutions to overcome this
problem and become Byzantine fault-tolerant systems.

Consensus in Centralized vs Decentralized Systems


The consensus is a fault-tolerant mechanism used in blockchain and other
distributed systems to reach to an agreement to add or commit a transaction to the
database by all the participating nodes.
Consensus mechanisms make a distributed system truly trustless.
Centralized distributed systems achieve consensus under the fail-stop assumption.
This requires that the distributed system agrees on a value in the face of node and
link failures but not if a node behaves maliciously.
Decentralized systems are required to operate under Byzantine node failure where a
failed node may act maliciously, i.e., they may not respond, or they may send
incorrect information.
Bitcoin
Bitcoin is a decentralized cryptocurrency that was likely developed in response to
the 2008-2009 global financial crisis.
Bitcoin is a public blockchain and doesn't have a centralized controlling authority
like a Bank or Government.
The total amount Bitcoins that could ever be mined and circulated is fixed to 21
million.
This way, the value of each Bitcoin is dependent only on the supply and demand in
the market and is free from centralized control and manipulation.
The transactions are verified and added to the bitcoin blockchain using fault-
tolerant Consensus algorithms like Proof of Work and Proof of Stake this prevents
the double-spending problems.

Background of Blockchain
Background of Blockchain
The concept of blockchain was first introduced in a white paper published by a
person. A group of people known by the name Satoshi Nakamoto in 2008.
This paper proposed the term ‘chain of blocks’. Later, the term ‘chain of blocks’
evolved into the word blockchain.
Blockchain is a distributed, decentralized database(ledger) in which transactions
can be added as blocks through consensus mechanisms.

Blockchain Defined
Blockchain is a distributed, peer-to-peer ledger that is immutable, append-only,
cryptographically-secure, and updateable only through agreement or consensus among
peers.
Blockchain is a distributed and decentralized, peer to peer ledger system that is
almost immutable and is secured cryptographically.
The data can only be appended to the blockchain but cannot be edited or deleted.
Data once added to the blockchain is distributed and copied to all the peers in the
distributed system and is stored permanently.
The transactions in a blockchain are verified and added by using different
consensus algorithms like Proof of Work and Proof of Stake.

Blockchain vs Traditional Database


Properties Blockchain Traditional Database
Operations Only insert operations Perform C.R.U.D operations
Replication Complete replication of block on every peer Multi-master or Master-
slave
Consensus Majority of peers agree on the outcome of the transactions Distributed
transactions (2 phase commit/Consistency vs Availability)
Invariants Anybody can validate transactions across the network Integrity
Constraints

Business Value of Blockchain


From a business standpoint, a blockchain can be defined as a platform where peers
exchange value / electronic cash without the need for a centrally-trusted
arbitrator.

For example, for cash transfers, banks act as a trusted third party. In financial
trading, a central clearinghouse serves as an arbitrator between two trading
parties.

Disintermediation allows blockchain to be a decentralized consensus mechanism where


no single authority is in charge of the database.

Decentralization provides quicker transaction speeds, cost savings, and greater


trust.
Blockchain Architecture
The basic architectural components of a blockchain are nodes, transactions,
blocks , and the consensus mechanism.

Nodes: Nodes are the autonomous computing units that form the peer-to-peer
blockchain network. The blockchain is stored on each node of the network.
Transactions: A transaction generally contains details about the exchange of some
information or digital assets that are recorded in a blockchain. The transactions
are bundled into a block and added to a blockchain. Transactions are the building
blocks of the blockchain.
Example :
In case of Bitcoin, a transaction is an exchange of value from one address to
another.

Blockchain Architecture
Blocks: Blocks are collections of transactions that are bundled together to be
added to the blockchain. Blocks are created by the process of Mining. You'll learn
more about Blocks and the Mining process in the later topics.
Consensus Mechanism: It is a set of rules that are satisfied to verify and add
transactions to blockchain. There are several consensus algorithms that are used to
verify transactions like Proof of Work and Proof of Stake.

Limitations of Blockchain
The major disadvantages of blockchain technology are:

complexity: Blockchain is a rather new technology and there are so many


technologies like cryptography, networking involved in blockchain which makes it
difficult to adapt.
size and storage: Blockchain is a peer-to-peer network and the nodes are scattered
all across the globe this makes them huge and hard to maintain. All the nodes in a
blockchain store a copy of the database. Sometimes these databases can be huge and
are difficult to store.
scalability: It is difficult to scale blockchains horizontally because different
nodes on the network have different computing power.
regulation: Blockchain is a disruptive technology and has the ability to change
traditional banking and monetary systems. So many countries and governments have
laws that do not allow the use of blockchains in some forms or other.

Block Structure
Block Structure
Block is a collection of transactions bundled together to be added to the
blockchain.
A block is divided into two parts, a block header containing the metadata used for
verifying the block and the** transactions** to be added to the blockchain.

Block header
The important components of the block header are.

version - the version of the block structure


previous block header hash - a hash representing the address of the previous block
Merkle root hash - a cryptographic hash of all of the transactions included in this
block
time - represents the time when the block created
nBits - the difficulty level for block creation.
nonce ("number used once") - a random value that is added to a hashed block that,
when rehashed, meets the difficulty level restrictions.
Users create transactions and submit them to the network, where they sit in a pool
waiting to be included in a block.

Mining
Mining is a process of verifying transactions, bundling them into blocks, and
adding those blocks to the blockchain.
The nodes in the network that verify transactions are called mining nodes or simply
Miners.
The process requires the nodes to run consensus algorithms like Proof of Work and
Proof of Stake.
Solving Proof of Work problems requires extensive computing power, so the miners
are rewarded with tokens like bitcoin and ethereum for solving them.

Distributed Ledgers
Distributed ledger describes shared database; so, all blockchains come under the
league of distributed ledgers or shared databases.

All blockchains are distributed ledgers but all distributed ledgers need not be a
blockchain.

A blockchain is known as a particular type of shared database that consists of


transaction blocks.

R3's Corda is an instance of a distributed ledger that doesn't utilize transaction


blocks.

Types of Blockchain
Blockchain can be divided into several types based on different criteria.

Based on ownership : Public, Private and Consortium.


Based on permissions: Permissioned and Permissionless.
Based on support for programming: Turing incomplete and Turing Complete.

Public Blockchains
These type of blockchains are not owned by any single person or organizations.
They are public, and anyone running the blockchain can become a node of the
blockchain network.
All nodes have a copy of the blockchain and can participate in mining and auditing
process.
in these type of blockchains the transactions are verified and added to the
blockchain using decentralized consensus mechanisms.
Examples of public blockchain are Bitcoin and Ethereum

Private Blockchains
These blockchains are owned and controlled by a particular individual or
organization.
That is, they are open only to a consortium or group of individuals or
organizations who have decided to share the ledger among themselves.
There are various blockchains now available in this category, such as HydraChain
and Quorum.
Optionally, both of these blockchains can also run in public mode if required, but
their primary purpose is to provide a private blockchain.

Consortium blockchains
These type of blockchains are not governed by a single person or organization.
They are controlled by a group of Organizations.
All the transactions are verified by all or some of the participating members of
the different organizations.
Examples of these type of Blockchains are r3 and EWF
Permissioned vs. Permissionless Blockchains
Permissioned blockchains are usually private blockchains which require special
permissions to become a node of the blockchain network.
Some public blockchain networks can also be permissioned, anyone can read from
these blockchains but special permissions are needed to add transactions.
Example of a public permissioned blockchain is Ripple. In Ripple, anyone can
perform transactions, but only permissioned nodes can verify and add them to the
blockchain.
Permissionless blockchains are the public blockchains in which anyone can become a
node and can participate in the process of mining using various consensus
algorithms.
Most public blockchains like Bitcoin and Ethereum are permissionless

Sidechains
Sidechains are emerging mechanisms that allow tokens and other digital assets from
one blockchain to be securely used in a separate blockchain and then be moved back
to the original blockchain if needed.
Sidechain functionality holds tremendous potential to enhance the capabilities of
existing blockchains.
A sidechain is a separate blockchain that is attached to its parent blockchain
using a two-way peg.
The two-way peg enables interchangeability of assets at a predetermined rate
between the parent blockchain and the sidechain.
The original blockchain is usually referred to as the main chain and all additional
blockchains are referred to as ‘sidechains’.

Benefits of Blockchain
Decentralization: As a consensus mechanism is used to agree on the validity of
transactions, there is no need for a trusted third party or intermediary to
validate transactions.
Transparency and trust: Additionally, every node has a private copy of data on the
blockchain, making the system transparent. As a result, the need to derive trust
from a central entity is eliminated, thus decentralizing trust.
Immutability: As a consequence of decentralized storage and data integrity assured
by cryptographic hashing, it is extremely difficult to change the data once it is
finalized. This results in a permanent auditable ledger of transactions.

Benefits of Blockchain
High availability: As each node stores a copy of the blockchain locally, the
networks functions even if some of the nodes are not available.
Simplification of current paradigms: In many industries, such as finance or health,
multiple entities maintain their own databases, this makes it difficult to update
and audit data. Blockchain solves the problem as it has a shared ledger stored in
all the nodes of the network. Blockchain makes the process of auditing faster.
Cost saving: Because blockchain does not require a trusted third party or clearing
house, overhead costs, such as fees paid to intermediaries, can be eliminated.

Consensus
Consensus is the backbone of every distributed system, as all nodes of the system
have to agree on the transaction order. In systems where participants can be
trusted, a fail-stop tolerant algorithm like PAXOS suffices. Such systems can only
tolerate nodes that stop on failure but do not behave maliciously.
Blockchains typically use Byzantine consensus algorithms, as the nodes are not
centrally controlled. Additionally, the choice of the consensus algorithm is
governed by the size and type of blockchain in use. In other words, that is not all
consensus mechanisms are suitable for all types of blockchains.
Practical Byzantine Fault Tolerance (PBFT) Algorithms: this method relies on the
exchange of messages among nodes that follow a distributed protocol to come to an
agreement. These algorithms put a limit on the number of nodes in the network
because the communication overhead increases as the network grow.

Consensus
Leader election-based consensus mechanisms: This arrangement is decentralized and
requires nodes to compete in a leader-election lottery and the winning node that
wins proposes a final value. For example, Bitcoin’s proof-of-work the PoW used in
Bitcoin falls into this category.
In public permissionless Blockchains, the election-based consensus is typically
used, as PBFTs cannot support the number of nodes needed in a public blockchain.
Permissioned Blockchains usually use PBFT algorithms or even non-byzantine
consensus as they support higher transaction throughput.

Consensus Requirements
Various requirements must be met to provide the desired results in a consensus
mechanism, including the following:

Agreement: All honest nodes decide on the same value.


Termination: All honest nodes terminate execution of the consensus process and
eventually reach a decision.
Validity: The value agreed upon by all honest nodes must be the same as the initial
value proposed by at least one honest node.
Fault-tolerant: The consensus algorithm should be able to run in the presence of
faulty or malicious nodes (Byzantine nodes).

Types of Consensus
Proof of Work (PoW): This type of consensus mechanism relies on proof that adequate
computational resources have been spent before proposing a value for acceptance by
the network.

This scheme is used in Bitcoin, Litecoin, and other cryptocurrency blockchains.


Currently, it is the only algorithm that has proven to be astonishingly successful
against any collusion attacks on a blockchain network, such as the Sybil attack.
Proof of Stake (PoS): This algorithm works on the idea that a node or user has an
adequate stake in the system; that is, the user has invested enough in the system
so that any malicious attempt by that user would outweigh the benefits of
performing such an attack on the network.

This idea was first introduced by Peercoin, and it is going to be used in the
Ethereum blockchain version called Serenity.
Another critical concept in PoS is coin age, which is a criterion derived from the
amount of time and number of coins that have not been spent.
In this model, the chances of proposing and signing the next block increase with
the coin age.

Types of Consensus
Delegated Proof of Stake (DPoS): This is an innovation over standard PoS, whereby
each node that has a stake in the system can delegate the validation of a
transaction to other nodes by voting.

It is used in the BitShares blockchain.


Proof of Elapsed Time (PoET): Introduced by Intel in 2016, PoET uses a Trusted
Execution Environment (TEE) to provide randomness and safety in the leader election
process via a guaranteed wait time.

It requires the Intel Software Guard Extensions (SGX) processor to ensure the
security guarantee for it to be secure.
Proof of Deposit (PoD): In this case, nodes that wish to participate in the network
have to make a security deposit before they can mine and propose blocks.
This mechanism is used in the Tendermint blockchain.

Types of Consensus
Proof of Importance (PoI): This idea is significant and different from PoS. PoI not
only relies on how large a stake a user has in the system, but it also monitors the
usage and movement of tokens by the user to establish a level of trust and
importance.

It is used in the NEM coin blockchain.


Federated consensus or federated Byzantine consensus: This mechanism is used in the
stellar consensus protocol.

Nodes in this protocol retain a group of publicly-trusted peers and propagate only
those transactions that have been validated by the majority of trusted nodes.

Types of Consensus
Reputation-based mechanisms: As the name suggests, a leader is elected by the
reputation it has built over time on the network.

It is based on the votes of other members.


PBFT: This mechanism achieves state machine replication, which provides tolerance
against Byzantine nodes.

Various other protocols including PBFT, PAXOS, RAFT, and Federated Byzantine
Agreement (FBA) are also being used or have been proposed for use in many different
implementations of distributed systems and blockchains.

Central vs. Decentralized Systems


Centralized systems have a client-server architecture in which a central server
controls the flow of all the information and all the clients are connected to the
server. The clients have to request the server to get the data.
Examples: Most Websites and Web Applications have Client/Server based architecture.
Decentralized systems have a peer-to-peer(p2p) architecture in which each node is
an autonomous computing unit that can handle data independently and make its own
decisions. There is no central hub controlling the data.
In decentralized systems the final behavior of the system is finalized based on the
decisions of individual nodes.
Example: Blockchain is a major example of a decentralized system. Gnutella a p2p
file-sharing network

Types of Decentralization
Architectural (de)centralization: How many physical computers is a system made up
of? How many of those computers can it tolerate breaking down at any single time?
Political (de)centralization: How many individuals or organizations ultimately
control the computers that the system is made up of?
Logical (de)centralization: Does the interface and data structures that the system
presents and maintains, look more like a single monolithic object, or an amorphous
swarm? One simple heuristic is: if you cut the system in half, including both
providers and users, will both halves continue to operate as independent units
fully?

Decentralization in Blockchain
Decentralization is a core benefit and service provided by blockchain technology.
By design, blockchain is a perfect vehicle for providing a platform that does not
need any intermediaries, and that can function with many different leaders chosen
through consensus mechanisms. This model allows anyone to compete to become the
decision-making authority. This competition is governed by a consensus mechanism.
Decentralization is applied in varying degrees from a semi-decentralized model to a
fully decentralized one depending on the requirements and circumstances.
Decentralization can be viewed from a blockchain perspective as a mechanism that
provides a way to remodel existing applications and paradigms, or to build new
applications, to give full control to users.

Benefits of Decentralization
The major advantages of using Decentralized systems are:

High availability and virtually no downtime because each node is an independent


computing unit and there are always some nodes available for system functioning.
Complete autonomy and trustless systems. In decentralized systems, the data is
stored and added based on the consensus of all or some of the nodes. There is no
need to place trust in central authority (like Centralized Servers, Banks, and
Governments).

Challenges to Decentralization
While there are many benefits of decentralization, including transparency,
efficiency, cost-saving, development of trusted ecosystems, and in some cases
privacy and anonymity, some challenges, such as security requirements, software
bugs, and human errors need to be examined thoroughly.
For example, in a decentralized system such as Bitcoin or Ethereum where security
is typically provided by private keys, how can one ensure that a smart property
associated with these private keys cannot be rendered useless if the private keys
are lost or, due to a bug in the smart contract code or the decentralized
application becomes vulnerable to attack?
Before embarking on a journey to decentralize everything using blockchain and
decentralized applications, it is essential to understand that not everything can
or needs to be decentralized.

Smart Contracts
Smart contracts refer to immutable computer programs that run deterministically in
the context of an Ethereum Virtual Machine as part of the Ethereum network
protocol, that is, on the decentralized Ethereum world computer.
A smart contract is a secure and unstoppable computer program representing an
agreement that is automatically executable and enforceable.
A smart contract is a business logic or a legal agreement that is coded using a
programming language.
Another fundamental idea is that smart contracts are automatically executed when
certain conditions are met.

Smart Contract Functionality


Smart contracts can:

Function as ‘multi-signature’ accounts, so that funds are spent only when a


required percentage of people agree.
Manage agreements between users, say, if one buys insurance from the other.
Provide utility to other contracts (similar to how a software library works).
Store information about an application, such as domain registration information or
membership records.

Smart Contract Security


In the field of smart contract programming, mistakes are costly and easily
exploited.
It is important to utilize security best practices and design patterns when coding
smart contracts to avoid introducing vulnerabilities into the code.
As with other programs, a smart contract will execute exactly what is written,
which is not always what the programmer intended.
Furthermore, all smart contracts are public, and any user can interact with them by
creating a transaction.
Any vulnerability can be exploited, and losses are almost always impossible to
recover. It is therefore critical to follow best practices and use well-tested
design patterns.

Smart Contract Security


Defensive programming is a style of programming that is particularly well suited to
smart contracts. It emphasizes the following, all of which are best practices:

Minimalism/simplicity
Code reuse
Code quality
Readability/audibility
Extensive testing

Oracles
Oracles are systems that provide external data sources to Ethereum smart contracts.
The term Oracle comes from Greek mythology, where it referred to a person in
communication with the gods who could see visions of the future.
In the context of blockchains, an oracle is a system that can answer questions that
are external to Ethereum.
Ideally oracles are systems that are trustless, meaning that they do not need to be
trusted because they operate on decentralized principles.

Oracle
Oracle
Oracles, ideally, provide a trustless (or at least near-trustless) way of getting
extrinsic (that is, “real-world” or off-chain) information, such as the results of
football games, the price of gold, or truly random numbers, onto the Ethereum
platform for smart contracts to use.
They can also be used to relay data securely to DApp frontends directly.
Oracles can, therefore, be thought of as a mechanism for bridging the gap between
the off-chain world and smart contracts.
Allowing smart contracts to enforce contractual relationships based on real-world
events and data broadens their scope dramatically.

Drawback of Oracles
Oracles can also introduce external risks into Ethereum’s security model.
Consider a “smart will” contract that distributes assets when a person dies.
This is something frequently discussed in the smart contract space and highlights
the risks of a trusted oracle.
If the inheritance amount controlled by such a contract is high enough, the
incentive to hack the oracle and trigger distribution of assets before the owner
dies is very high.

Oracle Data
Examples of data that an oracle might provide:

Parametric triggers indexed to natural hazards: Triggering of catastrophe bond


smart contracts, such as Richter scale measurements for an earthquake bond.
Benchmark reference data: Incorporating interest rates into smart financial
derivatives.
Exchange rate data: For accurate pegging of cryptocurrencies to fiat currency.
Weather data: Insurance premium calculations based on weather forecasts.
Sporting events: For prediction market resolution and fantasy sports contracts.

Oracle Functions
All oracles provide a few key functions, by definition. These include the ability
to:
Collect data from an off-chain source.
Transfer the data on-chain with a signed message.
Make the data available by putting it in a smart contract’s storage.
Once the data is available in a smart contract’s storage, it can be accessed by
other smart contracts through message calls that invoke a “retrieve” function of
the oracle’s smart contract; it can also be accessed by Ethereum nodes or network-
enabled clients directly by “looking into” the oracle’s storage.

Tokens
Often restricted to specific businesses, organizations, or locations, physical
tokens are not easily exchangeable and typically have only one function.
With blockchain tokens, these restrictions are lifted or, more accurately,
completely redefinable.
Many blockchain tokens serve multiple purposes globally and can be traded for each
other or other currencies on global liquid markets.

Token Usage
As the following list shows, currency is just the first “app”:

Currency - A token can serve as a form of currency, with a value determined through
private trade.
Resource - A token can represent a resource earned or produced in a sharing economy
or resource-sharing environment; for example, a storage or CPU token representing
resources that can be shared over a network.
Asset - A token can represent ownership of an intrinsic or extrinsic, tangible or
intangible asset; for example, gold, real estate, a car, oil, energy, etc.

Token Types
Access - A token can represent access rights and grant access to digital or
physical property, such as a discussion forum, an exclusive website, a hotel room,
or a rental car.
Equity - A token can represent shareholder equity in a digital organization (For
example, a DAO) or legal entity (For example, a corporation).
Attestation - A token can represent a certification or attestation of fact by some
authority or by a decentralized reputation system (For example, marriage record,
birth certificate, college degree).
Utility - A token can be used to access or pay for a service.

Token Types
Native or Built-in Tokens
Built-in tokens like bitcoin, ether, etc., are used as Digital Currency for
transactions, as incentives and rewards for mining blocks,

Application Tokens
Blockchains like Ethereum have specific tokens called Gas that are used to interact
with the application layer. These tokens can be used as a computational fee.

Asset-backed Tokens
These are a form of digital currencies that have a certain value and can be
exchanged with real-world currencies and assets like Gold for a fixed price. These
exchanges are controlled by third parties.

Cryptography in Blockchain
Cryptography is mainly of two types, symmetric and asymmetric.
Blockchain technology utilizes cryptography as a means of protecting the identities
of users, ensuring transactions are executed safely and securing all information
and value stores.
Therefore, anyone using blockchain can have a high level of confidence that once
something is recorded on a blockchain, it is done so legitimately and in a manner
that preserves security.

Symmetric Cryptography
Cryptography is the method of disguising and revealing, otherwise known as
encrypting and decrypting, information through complex mathematics. This means that
the information can only be viewed by the intended recipients and nobody else. The
method involves taking unencrypted data, such as a piece of text, and encrypting it
using a mathematical algorithm, known as a cipher. This produces a ciphertext, a
piece of information that is completely useless and nonsensical until it is
decrypted.
Both encryption and decryption typically employ a key, a series of bytes controlled
by a user.
When the same key is used for both encryption and decryption, the key is typically
safeguarded securely.
This method of encryption is known as symmetric key or private key cryptography.

Asymmetric Cryptography
Public-key cryptography, also known as asymmetric cryptography, represents an
improvement on standard symmetric-key cryptography as it allows information to be
transferred through a public key that can be shared with anyone.
Rather than using a single key for encryption and decryption, as is the case with
symmetric key cryptography, separate keys (a public key and a private key) are
used.
Documents encrypted using a user’s public key can be decrypted using the private or
vice versa.
It is impossible to figure out the private key is based on the public key.
Therefore, a user can send their public key to anyone without worrying that someone
will gain access to their private key.
The sender can confidently encrypt files and rest assured that they will only be
decrypted by the intended party.

Blockchains are also dependent on hashing.


Hashing is a cryptographic method of converting any kind of data into a string of
characters.
As well as providing security through encryption, hashing creates more efficient
storage of data, as the hash is of a fixed size.

Digital Signature
Digital Signature
Digital Signature is a way of verifying the authenticity of digital messages and
documents over the Internet.
Digital signature uses hash functions and asymmetric cryptography to check the
sender for certain information.
A private key is used to sign the message or document and a public key is used by
the recipient to verify the signature and ensure that the right information is
received.
In case of blockchains like Ethereum the public key is the Externally owned account
address.
The private key is stored locally and is not shared to other users.

Blockchain Governance
Blockchain Governance
Generally, governance is about decisions that ultimately affect “stakeholders”.
It’s about the processes and coordination mechanisms that stakeholders use to make
decisions.
It includes the establishment, maintenance, and revocation of the legitimacy of
decisions, decision-making processes, norms, and other mechanisms for coordination.
Blockchains are distributed systems. They are necessarily consensus protocols,
which means that different nodes in the network (For example, computers on the
internet) have to run compatible software.

Blockchain Governance
Public blockchains typically have “communities” that rely on them and govern the
blockchain protocol.
“Node operators” are the owners and managers of nodes that run blockchain
protocols.
Most node operators do not want to write much software code, and it is challenging
for anyone to independently write compatible implementations of a consensus
protocol, even if they have technical specifications.
As a such, node operators rely on software repositories (usually hosted on
Microsoft/Github servers) to provide them with the required software.

Trademark
“Core developers” of a blockchain are software developers who work on the software
that implements a protocol.
Developers have processes that assure the quality of the software they release.
They are generally very committed to maintaining the legitimacy of their software
repositories because they want people to use their software (as opposed to someone
else’s).
Blockchains are typically associated with trademarks.

Trademark
A blockchain’s trademark may or may not be registered, but blockchain communities
use trademarks for marketing their blockchain and for making it easy for users to
identify which blockchains they interact with.
For a blockchain community to successfully govern its blockchain, the members need
to coordinate their activities.
At a minimum, this means that node operators, developers, and the users of the
trademark have to work together.

Blockchain Governance
Blockchains can have significant communities that form diverse ecosystems that
include many participants and stakeholders that aren’t core developers, node
operators, and users of trademarks.
These stakeholders might consist of block explorers and other low-level service
providers, exchanges, speculators, application developers, users, journalists, and
passive observers, to name just a few.
On the other hand, blockchain communities might also be just a team of core
developers running their nodes, promoting their protocol in hopes of one day having
a more significant community.

Blockchain Governance
This says something about the decisions that blockchain governance necessarily
makes: Core developers have to choose how to release software, that node operators
have to decide what software to run, that trademark users have to determine how
they use the blockchain’s trademark, and that these decisions have to be
coordinated by the blockchain community.
But it notably says nothing about the processes, norms, coordination mechanisms,
and politics that will inevitably drive these decisions for any large blockchain
community.

Forking
Forking
Forking is the splitting of the main blockchain into two or more chains (like a
fork). This can happen due to many reasons.
When some members of the blockchain community do not agree with the rules, and a
consensus cannot be reached regarding the future state of the blockchain.
When there is a new software update or change in the consensus algorithm.
Example: Bitcoin cash and Ethereum classic

Types of Forks
Types of Forks
Hard Fork
This introduces a new set of rules and software updates to the forked blockchain
network.
Hard Forks usually change the consensus algorithm and block architecture, this
makes it backward-incompatible with the original blockchain software.
Soft Fork
These types of forks introduce software updates that are backward-compatible with
the software and architecture of the original blockchain.
In Soft Fork, the consensus mechanism is usually similar to the parent chain.

Power Law
As a general rule, there is naturally a “power law” distribution, where a majority
of blockchains have relatively small communities relative to a small number of
blockchains with relatively large communities.
This “power law” rule means that even though forks are possible, there will only
ever be a small number of forks that are ultimately successful enough to be
considered a“major” blockchains”.
As a result, the blockchain governance regimes of a small number of major
blockchains will determine governance outcomes for the entire blockchain category.
This is why we need to be concerned about the governance of every major public
blockchain.

Is Blockchain Really Needed?


Is a blockchain needed? When is a blockchain required? In what circumstances is
blockchain preferred over traditional databases? To answer these questions, go
through the simple set of questions presented here:

Is high data throughput required? If the answer to this question is yes, then use a
traditional database.
Are updates centrally controlled? If yes, then use a conventional database.
Do users trust each other? If yes, then use a traditional database.
Are users anonymous? If yes, then use a public blockchain; if not, then use a
private blockchain.
If consensus is required to be maintained within a consortium then use a private
blockchain, otherwise, use a public blockchain.
Answering all these questions can provide an understanding of whether or not a
blockchain is required.

Ethereum is a public Blockchain similar to Bitcoin.


Unlike Bitcoin which is only used as a digital currency, Etherum has a broader
range of functionalities.
It is a programmable blockchain and supports Turing Complete Programming Languages.

Ethereum has its own cryptocurrency called Ether. It also has another token called
Gas which is used as a fee for program executions.
Using these Turing complete languages you can develop Smart Contracts and DApps
(Decentralized Applications) on Ethereum.
Ethereum has an Ethereum Virtual Machine which runs the programs on the Ethereum
Blockchain.
It has its own Proof of Work (PoW) consensus algorithm called the Ethash.

Ethereum Accounts
An Ethereum account is an address that stores the “state” of ownership of ether
tokens, and transaction between these accounts is the change in ownership of
tokens. There are two types of Ethereum Accounts.

Externally Owned Accounts (EOAs)

These accounts are associated with human users.


They have a private key associated with them.
They have ether balance.
They are capable of sending transactions.
They have no associated code.
They are controlled by private keys.
Accounts contain a key-value store.

Ethereum Accounts
Contract Accounts (CAs)

CAs have Ether balance.


They have associated code that is kept in memory/storage on the blockchain.
They can get triggered and execute code in response to a transaction or a message
from other contracts. It is worth noting that due to the Turing-completeness
property of the Ethereum blockchain, the code within contract accounts can be of
any level of complexity. The code is executed by Ethereum Virtual Machine (EVM) by
each mining node on the Ethereum network. EVM is discussed later in the chapter in
the EVM section.
Also, CAs can maintain their permanent state and can call other contracts. It is
envisaged that in the serenity release, the distinction between externally owned
accounts and contract accounts may be eliminated.
They are not intrinsically associated with any user or actor on the blockchain.
CAs contain a key-value store.

Ethereum DApp
Ethereum started as a way to make a general-purpose blockchain that could be
programmed for a variety of uses.
But very quickly, Ethereum’s vision expanded to become a platform for programming
DApps.
DApps represent a broader perspective than smart contracts.
A DApp is, at the very least, a smart contract and a web user interface.
More broadly, a DApp is a web application that is built on top of open,
decentralized, peer-to-peer infrastructure services.
A DApp is composed of at least: Smart contracts on a blockchain. and A web frontend
user interface.
In addition, many DApps include other decentralized components, such as: *A
decentralized (P2P) storage protocol and platform A decentralized (P2P) messaging
protocol and platform

Ethereum Network
Mainnet - Mainnet is the current live network of Ethereum.

The current version of mainnet is Byzantium (Metropolis), and its chain ID is 1.


Chain ID is used to identify the network.
A block explorer which shows detailed information about blocks and other relevant
metrics is available at https://etherscan.io.
This can be used to explore the Ethereum blockchain.

Ethereum Network
Testnet - Testnet are public networks that are used by Developers to test Smart
Contracts/Decentralize Applications in a production like environment.
This test blockchain is used to test smart contracts and DApps before being
deployed to the live production blockchain.
Moreover, being a test network, it allows experimentation and research.
There are different testnets namely Rpopsten, Rinkeby, Kovan and Gorli. Ropsten is
widely used as it closely represents the mainnet.
Private net - As the name suggests, this is the private network that can be created
by generating a new genesis block.

This is usually the case in private blockchain distributed ledger networks, where a
private group of entities start their blockchain and use it as a permissioned
blockchain.

Ethereum Programming Languages


Programming Languages

Code for smart contracts in Ethereum is written in a high-level language such as


Serpent, LLL, Solidity, or Viper and is converted into the bytecode that EVM
understands for it to be executed.
Solidity is one of the high-level languages that has been developed for Ethereum
with JavaScript-like syntax to write code for smart contracts.
Once the code is written, it is compiled into bytecode that's understandable by the
EVM using the Solidity compiler called solc.

Problem statement
Since there is corruption and cheating everywhere , Tamilnadu government asked DPK,
Father of blockchain to create a Voting smart contract.
So that the voting process will happen smoothly and no malicious activities will
happen.
The results also will be announced after the voting portal closes.
So no waiting period will be there.
Your task is to create a smart contract based on the above conditions and deploy it
in the ethereum blockchain.
Step 1 – Installation

Give truffle init inside the project folder to initialise


Create a Election.sol file where your smart contract logic goes in.
Inside the migration folder create a new file called 2_deploy_contracts.js.
Inside that file ,copy paste this.
module.exports = function(deployer) {
deployer.deploy(Election);
};
5.Now your setup is ready.

Problem statement Contd.


Step 2 – Building the Contract

Your task is create 3 candidates namely Deepak,Nehal,Gokx.


Create a structure for the candidate like id,name,voteCount.
Create 2 mapping variables voters and candidates.
Voters should contain the address and a bool.
The function vote should not allow for double voting.
So check this condition first.
The voters can vote for the above 3 candidates only.
Now if they have voted add the vote count to the respective candidate.

Problem statement Contd.


Step 3 – Testing and Validation

First open the terminal and type ganache-cli.


You can see 10 dummy addresses in it.
In another terminal type truffle-compile.
Your contract gets compiled if error occurs debug ur contract.
Don’t close the ganache-cli terminal.
After successful compilation in the same terminal give truffle-test to test the
contract
You can see the passing and failing tests here
Type sh tester.sh it will generate 2 files .
One is the block history(ganache.txt) and the other one is * your test results
(log.txt).

Web3
Web3 generally refers to the next generation of the worldwide web.
It has been adopted by the Ethereum ecosystem and co-opted to refer to a
decentralized web.
Put simply then, Web3 is Web2 without the centralized servers and data silos.
In time, the decentralized architecture will simply become an infrastructure
choice, just like MongoDB vs. Firebase or REST vs. GraphQL is today — your EC2
instance might be replaced by Ethereum, and your static assets could be stored on
Swarm.
The changeover will be gradual, on Web 2.0, we’ll increasingly see sites whose
back-ends utilize Web 3.0-like components such as Bitcoin, BitTorrent, NameCoin.
Eventually, the Web 3.0 platform, Ethereum, will likely be used by sites that wish
to provide transactional evidence of their content, for example, voting sites,
exchanges, and prediction markets.

DApps and Web3.js


A Dapp is a decentralized app, meaning that there is no centralized server.
Instead, “backend” code runs on a decentralized peer-to-peer network of nodes and
“frontend” code is served from a distributed CDN.
The Ethereum network is made up of nodes that each, contain a copy of the
blockchain.
To call a function on a smart contract, a node needs to be queried and given the
smart contract address, the function that will be called, and the variables to be
passed to that function.
Ethereum nodes only speak a language called JSON-RPC, which has limited natural
language characteristics.
Web3.js is a collection of libraries that allow you to interact with a local or
remote Ethereum node, using an HTTP or IPC connection.

Hyperledger Foundation
Hyperledger is an open-source project that came out of the Linux Foundation and was
created to help advance cross-industry blockchain technologies.
Open source is a software licensing model. This means that the user has the rights
to the code and is free to use it, enhance it, or even redistribute it, provided
this is done on an open-source basis.
This enables an organization to adapt the technology to achieve true usability with
minimal effort.
Many applications that are backed by open source technologies can be assembled,
like building blocks, to solve business problems.

Hyperledger Fabric Design Principles


Design Principles: Modular and extensible approach: This implies modularity in all
components of all frameworks. Components defined by Hyperledger for all projects
include (but are not limited to) the following: Consensus layer

Smart contract (chain code) layer.


Communication (gossip) layer.
Data store (persistent, log, and ledger data).
Identity services (root of trust—to identify the participants).
APIs.
Pluggable cryptography.

Hyperledger Fabric Design Principles


Interoperability: This principle is around backward interoperability and NOT the
interoperability between the various Hyperledger project-powered blockchain systems
or business networks.

Focus on secure solutions: Enterprise and therefore business network security is


paramount, hence the focus on security-and not just of the crypto abstraction-but
the interaction between components and the structure that governs the permissioning
nature of permissioned blockchains. Most industries embarking on the permissioned
blockchain are established and regulated industries.

Hyperledger Fabric Design Principles


Token (or coin or crypto-asset) agnostic approach: This is discussed in great
length in the governance section, but Hyperledger projects do not use crypto-
assets, cryptocurrency, tokens, or coin-like constructs as incentive mechanics to
establish trust systems. While there is a notion of asset tokenization that
represents a physical, virtual, or dematerialized asset, tokenization of assets is
a vastly different concept than a systemic token that is generated in the system as
virtualization of incentive economics.

Focus on rich and easy-to-use APIs: The focus here is to ensure that blockchain
systems have not only enterprise middleware access, but access to business
networks, existing participants, and new systems without exposing the details of
blockchain-powered business networks.

Hyperledger Fabric Reference Architecture


Hyperledger Fabric follows a modular design, and the following are some of the
possible components or modules that can be plugged in and implemented. Note that
this list is not exhaustive:

Membership services: This module is essentially a permissioning module and acts as


a vehicle to establish a root of trust during network creation, but this is also
instrumental in ensuring and managing the identity of members.

Membership services are essentially a certificate authority as well as utilized


elements of the Public Key Infrastructure (PKI) for things such as key
distribution, management, and establishing federated trust as the network grows.
The membership services module provides a specialized digital certificate authority
for issuing certificates to members of the blockchain network, and it leverages
cryptographic functions provided by Hyperledger Fabric.

Hyperledger Fabric Reference Architecture


Transactions: A transaction is a request to the blockchain to execute a function on
the ledger. The function is implemented by a chaincode. Cryptography ensures the
integrity of transactions by linking the transaction to previous blocks and
ensuring the transactional integrity, if protected, by linking the cryptogram or
hash from previously linked blocks. Each channel in Hyperledger Fabric is its
blockchain.

Smart contract or chaincode services: Chaincode is an application-level code stored


on the ledger as a part of a transaction. Chaincode runs transactions that may
modify the world state. Transaction logic is written as chaincode (in the Go or
JavaScript languages) and executes in secure Docker containers. The transaction
transforms data, scoped by chaincode on the channel from which it operates.
Hyperledger Fabric Reference Architecture
Chaincode is installed on peers, which require access to the asset states to
perform reads and writes.
The chaincode is then instantiated on specific channels for specific peers. Ledgers
within a channel can be shared across entire networks of peers or include only a
particular set of participants.
Peers can participate in multiple channels.

Hyperledger Fabric Reference Architecture


Events: The process of validating peers and chaincodes can produce events (pre-
defined events and custom events generated by chaincode) on the network that
applications may listen for and take actions on.

These events are consumed by event adapters, which may further deliver events using
vehicles such as WebHooks or Kafka.
Fabric-committing peers provide an event stream to publish events to registered
listeners. As of v1.0, the only events that get published are Block events.
A Block event gets published whenever the committing peer adds a validated block to
the ledger.

Hyperledger Fabric Reference Architecture


Consensus: Consensus is at the heart of blockchain and enables trust system. In
general, the consensus service allows digitally signed transactions to be proposed
and validated by network members.

In Hyperledger Fabric, the consensus is pluggable and tightly linked to the


endorse-order-validation model that Hyperledger proposes.
The ordering services in Hyperledger Fabric represent the consensus system. The
ordering service batches multiple transactions into blocks and outputs a hash-
chained sequence of blocks containing transactions.

Hyperledger Fabric Reference Architecture


Ledger: Another component is a distributed encrypted ledger, including an append-
only data store.

This provides the ability to query and write data across distributed ledgers. There
are two options:
Level DB (default embedded KV DB) supports keyed queries, composite key queries,
and key range queries.
Couch DB (external option) supports keyed queries, composite key queries, key range
queries, plus full data-rich queries.
Client SDK: A client SDK enables the creation of applications that deploy and
invoke transactions atop a shared ledger.

The Hyperledger Fabric Reference Architecture supports both Node.js and Java SDK.
A software developer kit is like a programming kit or set of tools that provide
developers with the environment of libraries to write and test chaincode
applications.
SDKs are critical in blockchain application development. Specific capabilities
included in the SDK are the application client, chaincode, users, events, and
crypto suite.

Hyperledger Fabric Runtime Processing Flow


Transaction proposal (application SDK)

Transaction proposal is submitted by application SDK.


It receives a transaction proposal response (includes ReadWrite set) post
endorsement.
It submits the transaction (includes ReadWrite set) to the ordering service
Transaction endorsement

The transaction is sent to the counter-parties represented by endorsing peers on


their channel.
Each peer executes the transaction by calling the specified chaincode function and
signs the result, which becomes the read-write-set of the transaction.
Each peer may participate in multiple channels, allowing concurrent execution.

Hyperledger Fabric Runtime Processing Workflow


Transaction submitted to the ordering service

The ordering service accepts endorsed transactions and orders them according to the
plug-in consensus algorithm, and then delivers them on the channel.
Peers on the channel receive transactions and validate before committing to the
ledger.
Transaction validation

Validates each transaction and commit block.


Validates the endorsement policy.
Validates ReadSet versions in state DB.
Commits the block to the blockchain.
Commits the valid transaction to state DB.

Use Case 1 – Business Hiring


Adoption for business hiring will likely be a staged process. Before long, DLT will
be used to verify a wide range of data.
Resume/CV
Education Credentials
Employment History
Professional Licenses and Certification
Criminal History
Credit Reports
Personal and Professional References

Use Case 2 – Legal Agreements


Smart contracts can transform the way businesses process function globally.

By using this transformative technology, legal service or law firm can implement a
variety of contracts as self-executing programs on a blockchain.

The following options are some of legal agreement types that utilize blockchain:

Real Estate Deeds


Rental Contracts
Trusts
Powers of Attorney
Sales Contracts

Use Case 3 – Counterfeits (Auto Parts)


The global market for counterfeit auto parts is ~USD 12 billion.

A solution that uses blockchain can reduce the prevalence of counterfeits for the
aftermarket auto parts.

Users can utilize smartphones for scanning an aftermarket part and quickly identify
if it is genuine. By recognizing the item at the time of buying, users can
authenticate and buy real products.
Use Case 4 – Healthcare (Disparate Recordkeeping)
Disparate record-keeping systems can result in patient consent forms and medical
histories that are incomplete, conflicting or ambiguous.

Blockchain-stored records can offer full longitudinal health records for people,
providing all patients control over their data through verifiable consent.

With blockchain, every patient record reflects the best-known medical facts — from
genomics data to diagnostic medical imaging — and can be reliably transferred when
needed, with no need for a central gatekeeper.

Use Case 5 – Healthcare (Clinical Trial Management)


Clinical trial management generates mountains of data, requiring healthcare
administrators to keep reliable, consistent records for peer review and to meet
regulatory requirements.
Blockchain tools, in concert with an Electronic Data Capture (EDC), can allow
clinical data to be automatically aggregated, replicated and distributed among
researchers and practitioners with greater auditability, provenance tracking and
control compared to complicated, conventional systems.

Use Case 6 – Airport Personnel Management


Passenger and cargo safety are paramount in every form of transportation, but crew
training and certification can involve multiple agencies over long periods of time.
Every transport terminal is a hive of activity as well, with personnel employed by
a wide range of companies with duties including fuel delivery, ticket taking,
catering, shuttle-cart driving, cleaning and more.
Each requires vetting for security, and their activities must be coordinated.

Use Case 6 – Airport Personnel Management


With its shared, immutable ledger that prevent entries from being changed or
falsified, blockchain can provide the verification and insight that transportation
companies need.
Certificates and licenses can be stored for each crew member, verified and updated
as additional training occurs.
Blockchain provides a central management mechanism, with visibility into common
information necessary for settling disputes over pay, work status or other issues
that may arise.

Use Case 7 – Asset Registration with Government


We rely on the government to accurately record and track our homes, businesses,
cars and more, verifying ownership and ensuring smooth financial transactions.
Accurate and accessible registries are crucial to engendering trust and
transparency in government.
Despite this need, today’s registries suffer from slow, duplicative processes and
an over-reliance on error-prone, incomplete and manual data entry.

Use Case 8 – Self Sovereign Identity


From licensure to passports to publicly funded medical services, establishing and
verifying identity is vitally important for both citizens and government agencies
themselves.
The financial and personnel costs of providing rigorous identity services, though,
are enormous.
The great need for identification documents and verification of existing
credentials arises partly from the difficulty in linking enough verifiable personal
data on which to base any government-issued identification.
What sounds like a simple task is complicated by records in different formats, of
varying provenance, and containing sometimes-conflicting data.

Use Case 9 – Trade Finance


Banks struggle with manual processes and stringent requirements for managing,
tracking and securing domestic and cross-border trade transactions.
For example, processes for corporate trade financing letters of credit are
typically paper-based and fragmented.
This can make financing even more challenging for the 50 percent of smaller
enterprises that may have no credit sources.
Blockchain-based smart contracts can automatically store, secure and exchange
contract details and financial terms; coordinate trade logistics and payments on an
integrated real-time network; and streamline digital trade processes.

Use Case 10 – Cross Border Payments


Cross border payment transactions can be costly and take days to complete.
Fluctuations in foreign exchange rates and fragmented banking systems can create
friction and lead to high reconciliation and dispute resolution costs.
With blockchain, banks can create secure, low-cost and high volume cross-border
payments without sacrificing margins. They can also access new markets and
currencies with reduced risk.
TCS has achieved cross border security settlement using its private blockchain
network. You can learn more about it here

Course Summary
Finally, you have arrived at the end of the course. Let's list down the topics that
you explored in this course.

Distributed systems
Blockchain and its elements
Types of Blockchain
Consensus
Decentralization
Smart contracts
Tokens
Cryptography
Governance
Ethereum
Web3
Hyperledger fabric
Use cases

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy