PRIVATE BLOCKCHAIN [roomie Introduction, Key characteristics, Need of Private Blockchain, Smart Contract in a Private Environment, State Machine Replication, Consensus Algorithms for Private Blockchain -PAXOS and RAFT, Byzantine Fauits: Byzantine Fault Tolerant( BFT) and Practical BFT Introduction to Hyperledger, Tools and Frameworks, Hyperledger Fabric, ‘Comparison between Hyperledger Fabric & Other Technologies Hyperledger Fabric Architecture, Components of Hyperledger Fabric: MSP, Chain Codes, of Hyperledger Fabric, Creating Hyperledger Network, Case Study of Supply Chain Management using Hyperledger Transaction Flow, Working 5.1__ Introduction * Private blockchains are permissioned. + Access controls—or more specifically, how you access the blockchain—are the primary distinction between public and private blockchain, ‘+ Because private blockchains are permissioned, a third party or central administrator must approve access before @ user can access the blockchain. ‘© Private blockchains restrict read access and the ability to cr actions to a limited number of users or nodes. In private blockchains, a single organization will be in charge of the network and be able to control who can access and join it, © tis, in essence, a partially decentralized system. Bitcoin, Ethereum, or Litecoin are common examples of native currencies on public blockchains. It acts as a vital component of the system that rewards individuals for giving their approval. Private blockchains, on the other hand, usually do not. In comparison to public blockchain, there are more transactions per second, 5.2__Key Character Complete privacy: Private blockchain concentrates on privacy issues. «Private Blockchains tend to be more centralized, «Improved Scalability - The flexibility to add nodes and services on demand can be a huge benefit to the organization.Ce ge eS lockchain (MU) vigh performance and que 5:2 private slockehalt actions participating In the ledger, the pe, tami when the nodes are distributed locally but there are fewer nodes Is quicker, + Private blockchains are esi sal «Robust architecture « In or are designed to withstand any ks currently have one of the most stable network structures. They ; . Problem: 4 preventing malicious activity, They therefore include a high level of security mechanisms that aid in le and c vet ans can Process thousands of transactions per second. Bracice,pivate networks eurenly hove one ofthe mot TBE 5.3__Need of Private Blockchain + Private Blockchains are i a] ia intended for by muti tor buses that want greater control over their data and greater privat Furthermore, because they are designed differently, + Businesses interested in these solutions, ; . which 6 Blockchain on ther own pivateinacenceen We can refer to as network participants, frequently agree to host they do not have the concept of gas fees. If we want to establish lish chi ; ears 'annels of communication between a few parties who do not trust one another and who nother's transactions, we need private blockchain concepts. When a lot of unt i rusted parties need to work together to solve a problem, private blockchain is very helpful Private blockchains are undoubt wi ity r edly the technolo: ree in fi és eae aa gy for you if you're interested in a field where confidentiality is of It saves a lot of resources.A private system actually requires very litle attention and is relatively easy to maintain. Asa result, they only consume a small portion of the resources available on public blockchain platforms. You can therefore reduce the amount of resources (both financial and human) required for these solutions. + Itempowers enterprise companies. It offers very low transactional fees.in most cases, a fee may not even be necessary at all. In actuality, this is @ superb justification for beginning with private blockchains. Furthermore, in many cases, these blockchains do not have a native token for the network. + It provides network regulation, Actually, without a regulatory system, enterprise companies cannot function Therefore, there should be a proper way to carry out specific tasks, and breaking the rules will have negative effects. As a result, it guarantees the participants greater security. 5.4 Smart Contract in a Private Environment With 2 smart contract, the terms of the agreement between the parties are expressed dlrecty in code or programmable logic sing a general-purpose, high-level programming language rather than on paper. Similar to how bitcoin scripts are executed, these types of contracts are executed more easily in a blockchair system. Nevertheless the bitcoin script was easy to understand in comparison to the smart contract septs 5.5 State Machine Replication Before discussing state machine replication, understand why is neede? We know single server architecture,Private Blockchain (cea) Sewer) reply 0%) Fig. 5.5.2 But there can be a single point failure. Here comes the need of state machine replication. foquost x Gent Barver(() Sea gener / Fig. 5.5.2 State machine replication gives safety and liveness by creating replicas of state of servers. { Itis an interactive protocol Among servers. 27 Replicas maintain tye same state © replicas stap/in the same state. © Replicas execute operations in the same order. Replicas send replies to clients, Clients vote on replica replies. ‘The replication of state machines assists us in reaching a consensus in a permission model. Assmart contract does not have to be executed on each node. Instead, the chosen subset of the contract executor executes it and propagates it with further nodes to make sure that all nodes in the network are informed of the contract's state consistently and in real time. Consensus is ensured in a permission blockchain context via the distributed state machine replication technique. Fig. 5.5.3Blockchain (MU) What is a state machine ? Asta ir te machine executes a sequence of commands, : ; T ‘ansforms its state and may produce some output Outputs of the state i mach eae) ines are solely determined by the initial state and by sequence of commands that it has Giate Machine Consensus | = roves ose i wea] NN, t | q sivo Machin hens Fig. 5.5.4 Typically, replicated logs are used to create replicated state machines. ‘Upon receiving commands from clients, the server's consensus module adds them to its log.. Whenever commands have been correctly replicated, the state machine on each server executes them in log order. Let us look at a scenario of a replicated state machine. ‘We have a number of clients, and services are replicated into three machines. So the replication degree is three. We have a consensus module, and when a client wants to issue a command, it sends a cqmmand to one of the Consensus Module a. went [eo] et etx] Loo sent [xe 3 | xa zeta | (Get es] na Peet Fig. 5.5.5 + Replicated log ensures state machines execute the same commands in the same order. Consensus module guarantees agreement on command sequence in the replicated log, e as a deterministic state machine b) Replicate ©) Provide all replicas with the same input Tealockchain (MU) 5.6 Con: nee Private Blockchain Sus Algorithms for Private Blockchain -PAXOS and RAFT 5.6.1 PAXOS Consensus Algorithm + _L-Lamportintroduced.it asthe fyst consensus algor value under the network gr crash problems. Paxos lets all nodes agree on the same * The goal was to selec Value despite node failures, network failures and delays, * By delivering them to the other nodes, certain nocles offer values. The acceptance or rejection of those values must bbe decided by each node. » Bui concurrent processes and uncertainty of timing, order of events and inputs can be a problem * And also failure and recovery of machines or processors, of communication channels will be a major concern, Consensus Problem : * Consensus is impossible to solve in asynchronous systems means it is impossible to distinguish a failed process from one that is just very very slow. Hence the rest of the alive processes may stay unsure when it comes to deciding, '* But consensus is important since it maps to many important distributed computing problems. So can we solve the ‘consensus problem ? '* Paros does solve the consensus problem. It is the most popular consensus solving algorithm. + The only entirely safe and mostly live agreement protocol known, + Paxos is a family of distributed algorithms used to reach consensus, U% We know consensus is agreeing on one result. Once a majority agrees on a proposal, that is the consensus. The reached consensus can be eventually known by everyone. ine np reply prepare reject (as already saw a higher proposal number), where np is previous proposal else npen reply prepare accept, (this node will not accept any lower than n proposal. * Acceptors record the PREPARE ID they got on disc as well. Node is the leader if the majority of responses are Positive. Start a new round if nobody has the majority YZ Phase 2: + If the majority of the acceptors respond YES to the proposer’s prepare requests, the proposer will issue accept requests for each of those acceptors for proposals with numbers n and v, where v is the value of the proposal with the largest number among the responses, Value v ok? raasecvsima, 77 WW O67 NP Zt a NyiraiH '* _ Recipient log on disk and responds OK. Delay the procedure and restart Paxos if the leader is unable to get the support of the majority. ~ Phase 3: If leader hears OK from majority, it lets everyone know of the decision (learnit © send (decide, v) to all nodes Value v ok? vi Please elect me! ¢ — Recipient receive decisions and log it on disk, pect ls ¢ Delay the procedure and restart Paxos if the leader is unable to get the support of the majority.‘Blockchain 5-0 ‘+ Raft Is a consensus algorithm that is designed to be easy to understand. + Itis designed to be an alternative to Paxos. Its easier to implement. + Raft need to run on 5 servers to tolerate the failure of two of them. Raft algorithm was developed by Diego Ongaro and John Ousterhout at Stanford University. Raft was designed to Y Diego Ongaro and John Ousterhout st Stan have a better understanding about Consensus To be achieved considering that its predecessor, the Paxo® Algorithm, developed by Lesli Lamport is very tough to understand and implement. The RAFT algorithm is similar to pOFT but in RAFT only leader node can establish communication with other nodes and takes decision about the state of the transaction, Rat algorithm dvides time Into small terms of random length. Each Yerm is identified By @ monotonically increasing number, called term number. Each node exists in one of the three states: leader. {and candidate, Raft divides consensus into three phases : © Leader Election : If existing leader fails then a new leader needs to be elected. follower © Log replication : The leader replicates log to other nodes so that all the copies will be up-to-date. © _ Safety : If one of the nodes has committed a log entry at 2 particular index, no other node can apply @ different log entry for that index. + Initially, there is just one leader and all of the other nodes are followers. Followers are passive and only reply to requests from leaders and candidates. The leader handles all client requests. Ifa client communicates with ToTOWer the follower redirects it to the leader. Candidate state is used to elect a new leader. ‘* Randomized timer is used to elect the leader in each term. If leader is not elected in a term, candidates will time ‘out and initiates the election for the next term, Leader, candidates log should be most up-to-date compared to log at followers. If candidate's log is less up-to-date compared to potential follower, then follower rejects the candidate, 5 © Node begins as a follower and if it does not receive heartbeat message from leader within election time then it assumes that the leader is dead. It then takes candidate state to send out a "RequestVote". If candidate node gets majority approvals from follower nodes, then it becomes leader. © Only leader can append log entries aé per client requests. After receiving request from client, leader appends entry to its log. This new entry then leader sends to all the follower nodes. When majority of followers confirms this message, leader commits the message and sends heartbeat message to client and followers. This consensus mechanism is used in Quorum for consortium setting. How RAFT works ? © ARAFT cluster has one and only one elected leader © which communicates with client directly © which responsible for managing log replication on the other servers of the cluster. © which leads until it fails or disconnects, in which case a new leader is elected. SF harmanagPrivate Blockch Fig, 5.6.2: A Raft Cluster © One leader and several followers andl all client requests go through the leader. © Aclient sends a request Fig. 5.6.3 ‘© Leader stores requests on its log and forwards it to its followers. © Followers store the request on their logs and acknowledge its receipt. _& Leader Election 1. Leader sends “heartbeats” to other nodes saying that its online : they update their state machines Fig. 5.6.4 2. Ifother nodes no longer receive ‘heartbeat, they start an election cycle. 3. Followers decide to elect a new leader. 4, First candidate to timeout becomes new leader. © Log Replication 1. Leader accepts client requests and appends them to its log, 2. Leader ensures all other nodes have followed that request ie leader replicates its log to other servers. 5.7 __ Byzantine Faults : Byzantine Fault Tolerant (BFT) and Practical BFT 5.7.1 Byzantine Fault Tolerant (BFT) © Consensus achievement is the process by which network participants regularly agree on the current state of a specific blockeBlockchaln (MU) private Blockchain 0 Over distri stributed networks, itis possible to reach con: wsensus, to the concept of Byzantine fault tolerance, but it f not an easy task. This issue gave = + Lamport, Pease, and Sho: ee ee oper the Byzantine Generals Problem in 1982 to guarantee that malfunctioning lict information are manac oe ged inside a system. 'yzantine Fault Problem / Byzantine Generals Problem? This problem rey js *bresents.an issue of computer networking over an unreliabletink © Atheoretical problem ki rT find it difficult to co }own as The Byzantine Generals’ Problem illustrates how several Byzantine generals might mimunicate while deciding on their next course of action. ‘The Byzantine Gener Races als problem demonstrates the value of blockchains and explains why they are important. It will rstanding why a blockchain operates as it does. First we will disc uss the unsolvable Two Generals Problem. Following that, we'll expand on that to the Byzantine Generals’ Probl é roblem and talk about Byzantine Fault Tolerance in distributed and decentralized systems: ‘Two Generals Problem «This problem was first published in 1975. In this problem we will call these two nodes as generals. In this situation the generals in their armies have come upon a city that they wish to attack. Each general's army on its own is not enough to defeat the enemy's army successfully, thus they need to cooperate with an attack atthe same time the problem arises because two generals are separated by a significant distance. ‘+ So think of this as if they are like on opposite sides of the city. «General 1 is considered as a Leader and the other is considered the Follower. In order for them to communicate and decide on a time of attack, General 1 has to send a messenger across the enemy's camp that will deliver the time of attack to General 2. «But this could mean that the messenger could get captured and the message would be lost forever. «sThis will result in General 1 attacking while General 2 and his army hold thelr grounds assuming the first message goes through. «General 2 must still acknowledge that he received a message so he sends a messenger back. «Thus repeating the previous scenario where the messenger can get caught. «This opens up an infinite loop where both parties are sending acknowledgements back and forth with neither General knowing whether or not the message was received. ; aay «iF General 1 receives a message how General 2 ill know that the message was received without an additional acknowledgement message. «General 1 presents a repeating problem because General's problem is currently unsolvable, «And still a newer problem was iterated off ofthis one, which is Byzantine Generals Problem. Byzantine Generals Problem © We have already learned about this problem in Module 1.Private Blockchai lockchain (MU) 5-11 Te Lamport, Robert Shostak and Marshall Pease This problem was introduced in 1982 in a paper written by Les! which were a group of researchers, Ws a special case of the Two Generals Problem that has been generalized. lem deals with reliable computer systems ferent parts of the system to ensure Similar to the Two Generals problem, the Byzantine Generals probl handling malfunctioning components that give conflicting information to di consensus within the distributed computing system. 1e on a time to attack their common enemy. The difference now is that more than two generals need to agre i 1m: when to launch ‘© The same situation is described, but this time, more than two generals are required to agree 0 an attack against their common enemies. + One or more of the generals may be a traitor inthis situation, which would allow them to lie about their decision, adding another layer of complexity (eg, they say that they agree to attack at 08,00 but instead they do not yadigm described in the Two ‘An arrangement of commander and lieutenant replaces the leader-follower pat Generals Problem. * The commander and each lieutenant must reach consensus here in order for the action to be taken. + The issues that could develop when communicating a decision from one general to another are while conveying the message, the messenger could be arrested; What if the message was altered by a forger? ; How can a general be certain that he received the message from the expecting general? ; What if other generals turn traitor and tell their troops to strike but then they flee? How can the system be confident that every general will launch a simultaneous attack from their predetermined location? Is there any other option but to have complete trust in one another? ‘With its Byzantine fault tolerance (BFT) consensus method, blockchain appears to solve this issue. Byzantine Fault Tolerance (BFT) Algorithm ‘+ BFT algorithm is based on state machine replication, ‘* In distributed systems, ensuring that computers can establish consensus on specific facts in a reliable manner is a very real difficulty that byzantine fault tolerance seeks to address. Ly” An method that resists a system to enter the Byzantine Generals’ problem is known as Byzantine Fault Tolerance orn. 27 BET system is able to continue operating even if some of the nodes fails communicate who acts maliciously. ‘© The general's team needs an algorithm that can follow the following guidelines i ‘order to guarantee the success of the generals’ team: The next action of the plan must be approved by all troop generals; the generals must be dependable and committed to the establishment ; the impact of network traitors on generals must be avoided ; they must adhere to the system's algorithm ; no matter what the traitors do, the generals must agree on something or make a choice ; at no point during the action, the system or network should result in a 51 percent attack. «The basic operation of a BFT algorithm is : © Phase 2 : Client sends a request to the primary. The primary can then validate the message and propose @ sequence number for it. TeaW lockchain (wy sh Privat Blockchain imary node mmessece eg nt Pre“PrePare message to all backup nodes. This allows the backup nodes fo '9€ and receive the sequence number. © Phase3: haghed a ne Nodes sends prepare message to all other backup nodes. This allows replicas tent A°03t[Prepapare] Prepare_| Commi || Rey Primary z 8 i a =i a ’ Fig, 5.7.1 : Working of BFT © Phase 4: All replicas multicast a commit. The replicas have agreed on an ordering and have acknowledged the receipt of the request, aaa | © Phase § + Each functioning replica sends a reply directly to the client. This bypasses the case where the a reply directly to the client. asses the case where th primary fails between the request and reply. ae L eon + The amount of network communications among participants in the BFT-based consensus method grows as the number of participants rises. This is so because each transaction’s processing requires participation from every participant in the BFT-based consensus method as shown in Fig. 5.7.1.1, and the process itself is made up ofa variety of steps. Due to the fact that the completion of the consensus process slows down as more participants this feature of the BFT-based consensus method may cause performance and scalability issues. © If malicious clients have the necessary access, they may corrupt the system state. © No consideration is given to fault-tolerant privacy 5.7.2 Practical BFT '* Another famous consensus algorithm is Practical Byzantine Fault Tolerance or PBFT. * It was published by Miguel Castro and Barbara Liskov in 1999, which is the solution to the Byzantine General problems. + Paxos and Raft are not by default Byzantine fault tolerant, though there are variants of them like BFT-Paxos, This blockchain consensus mechanism which is widely used presently, but the confidence of blockchain node in PBFT cannot be guaranteed. It requires large amount of communication resources in the process of reaching consensus. «Byzantine general problem. In this case, all general nodes are at equal level and gets their work directions from the leader node. The leader node is primary node and all other nodes are considered as secondary or backup nodes, Selection of leader is randomly in round-robin manner. Client node sends transaction request to leader node. This ‘qzaived Tequest ie then broadcasted by leader node to all the secondary/backup nodes.