Making Blockchain Real for Business Praveen Jayachandran IBM Research – India.

Blockchain defined Total Bitcoin Opportunity Total Blockchain Opportunity Blockchain is a design pattern made famous by its use in Bitcoin. But its uses go far beyond. Blockchain can reimagine the world's most fundamental business interactions and open the door to invent new styles of digital interactions. IBM is adopting Blockchain to a very broad range of business applications What’s new e here is the SHARED LEDGER – up to this point each participant had their own Ledger This sharing is the foundation for innovative business solutions, This introduces an interesting set of technical challenges, including (1) participant identity and privacy & (2) transaction privacy Let’s look at this in some more detail.

… Inefficient, expensive, vulnerable Problem: Difficult to monitor asset ownership and transfers in a business network Party A’s records Party D’s records Bank records This is the “BEFORE” picture representing the “status quo” for business networks. Each participant keeps their own ledger(s) which are updated to represent business transactions as they occur. This is EXPENSIVE due to duplication of effort and intermediaries adding margin for services. It is clearly INEFFICIENT, as the business conditions – the contract – is duplicated by every network participant It is also VULNERABLE because if a central system (e.g. Bank) is compromised due to an incidents this affects the whole business network. Incidents can include fraud, cyber attack or a simple mistake. Party C’s records Party B’s records Auditor records … Inefficient, expensive, vulnerable

Shared, replicated, permissioned Solution … shared, replicated, permissioned ledger Party A’s records Party D’s records Bank records Shared, replicated, permissioned The novel Blockchain architecture give participants the ability to share a ledger which is updated every time a transaction occurs through peer to peer replication. Cryptography is used to ensure that network participants see only the parts of the ledger that are relevant to them, and that transactions are secure, authenticated and verifiable. Blockchain also allows the contract for asset transfer to be embedded in the transaction database determining the conditions under which the transaction can occur. Network participants agree how transactions are verified through consensus or similar mechanisms. Government oversight, compliance & audit can be part of the same network. Participants SAME AS BEFORE – this is not a disintermediation play CONSENSUS– means all participants agree that a transaction is valid PROVENANCE– means participants know where the asset came from and how it’s ownership has changed over time IMMUTABILITY– means no participant can tamper with a transaction once it’s agreed. If a transaction was in error then a NEW transaction must be used to reverse the error, with both visible FINALITY– means that there is ONE place to determine the ownership of an asset or completion of a transaction. This is the role of the SHARED LEDGER. Party C’s records Party B’s records Auditor records … Consensus, provenance, immutability, finality

Key Concepts and Benefits of Blockchain for Business Shared Ledger` Security Append-only distributed system of record shared across business network Ensuring appropriate visibility; transactions are secure, authenticated & verifiable Business terms embedded in transaction database & executed with transactions Smart Contracts Consensus All parties agree to network verified transaction Reduces Time Removes Cost Reduces Risk Enables New Business Models So Blockchain technology comprises these four main blocks, that can lead to increased efficiencies, and cost reduction across the business network. We will “unpack” CONSENSUS PRIVACY & SMART CONTRACT in the next couple of slides. Shared LEDGER has been already covered, and a SMART CONTRACT enables the business rules implied by the contract to be embedded in the Blockchain and executed with the transaction Other benefits include : Improve discoverability When everyone on an exchange can view the same ledger, it is easy to broadcast an intention (or offer) by appending it. For example, in a trading network, all asks and bids would be visible to every network participant. Automate trusted processes Unlike a centralized system where only the network operator can create a generalized solution that fits every user’s needs, Blockchain networks allow each participant to create customized solutions using their own proprietary business logic while running on the same common ledger. Ensure trusted record-keeping By design, no one party can modify, delete, or even append any record to the ledger without the consensus from others on the network, making the system useful for ensuring the immutability of contracts and other legal documents. Transaction time from days to near instantaneous Overheads and cost intermediaries Tampering, fraud & cyber crime IoT Integration into supply chain

Degree of Centralisation Censorship-resistant Privacy Scale to large number of nodes Scale in transaction throughput One global blockchain Many interacting blockchains Figure source: “Distributed Ledger Technology: Beyond Blockchain”, A report by UK Govt Chief Scientific Adviser

IBM’s point-of-view on Blockchain Open source standard to lower adoption risk Encourage Innovation through modular architecture IBM Supports Linux Foundation’s Hyperledger project BUILT IN THE OPEN BLOCKCHAIN ≠ BITCOIN Ensure greater trust by provisioning only permissioned members and users Enable more optimized forms of consensus to keep the ledger in sync PERMISSIONED ENTERPRISE READY Privacy, confidentiality, auditability, performance and scalability. Engage with governments and regulators to encourage the broad adoption of blockchain in industry IBM Blockchain is conducting business in 2017 across three areas Community development of blockchain fabric (Hyperledger Fabric and Composer projects) Cloud deployment which expands Fabric with value added features Client engagements and transformative solutions

The Linux Foundation Hyperledger Project A collaborative effort created to advance blockchain technology by identifying and addressing important features for a cross-industry open standard for distributed ledgers that can transform the way business transactions are conducted globally. www.hyperledger.org Associate Premier General 108+ Members, 260% Growth in 11 months

International Trade & Supply Chain: Use Cases and Client Examples WORKFLOW AUTOMATION & COMPLIANCE SUPPLY-CHAIN VISIBILITY Automate current inefficient, manual and error-prone workflows in documentary trade finance Provide single view for purchase order life-cycle across the supply-chain as the truth TRADE/SUPPLY-CHAIN FINANCE SUPPLY-CHAIN PROVENANCE Improve the efficiency of commercial financing business by sharing data in a secure and transparent manner Provide provenance across the supply-chain cutting through complex distribution and processing ecosystems Channel Financing Invoice discounting Trade finance Trade Logistics Food Safety

How Applications use the Ledger The key elements of a Blockchain application

Blockchain Applications and the Ledger developer Application develops D develops invokes Accesses (Rest API) emits Smart Contract * event ‘get’ ‘put, ‘delete’ Delete can only delete from the World State, not the Blockchain! A developer will create an application and smart contract (could be different developers) The application will invoke calls within the smart contract Those calls are processed by the business logic within the smart contract - a ‘put’ or ‘delete’ command will go through consensus protocol selected and added to the blockchain - a ’get’ command can only read from the world state but is not recorded on the blockchain To read from the blockchain a smartcontract must use the Rest APIs oh Hyperledger in the same way a application would An application can access Block information via rest APIs such as get block height each ‘put’ or ’delete’ invoke recorded emits block World/Ledger state … txn txn txn txn Blockchain Ledger * Smart Contract implemented using chain code

Operating Blockchain Networks Configuring for a replicated ledger

Consensus and the Blockchain Network Operator peer O deployed to and executes on peer nodes configures, operates Exact network structure depends on consensus mechanism. e.g. PBFT has leader, validating and non-validating peers Smart Contract sc sc sc … … … sc … Application invoke SC The Consensus network is in the Hexagon containing the Validating nodes & Non-validating nodes. Each operation only needs to be sent into the network once where it is then distributed around the network. The items being inputted into the network are abound the edge, Smart Contracts, Applications and configurations by a Blockchain Operator. … sc consensus msg sc sc sc … … consensus messages flow between appropriate peers to ensure the Blockchain SC transactions are kept in order; world state is kept consistent through local transaction replay … Consensus Network

How a PBFT Network Works (1/4) – Submission … 789 123 456 N Transaction submitted to network Non-validating peer 789 N V Validating peer V VL Validating Leader … 456 789 123 V N Transaction submitted to network Transaction submitted to network 456 123 … 123 456 789 VL In the Hexagon is the consensus network. It has a central core of validators who press the transaction and reach consensus and a set of non-validating nodes who will receive a copy of the results and output. Validating leaders are found through an election process in PBFT, more on what they do in next slide. The first step is submitting the transactions. Around the edge are 3 participants inputting 3 transactions each (transaction numbers 1, 2, 3, 4, 5, 6, 7, 8 & 9) These are then distributed around the validators so each have a copy of all the transactions However, these transactions may arrive at validators at different times (e.g. 456 arrive first on the left side validators but last on the right side validator) so the validators will have differing orders of transactions V N … 456 123 789 N

How a PBFT Network Works (2/4) – Ordering … 123 456 789 N Non-validating peer 789 N V Validating peer V VL Validating Leader … 123 456 789 V N 456 123 … 123 456 789 VL The Validating leader for this block is the one that decides the final order for the transactions. This validating leader has received the transactions in order 123456789 so sends this order to the other validators. Each validator then re-arranges the transactions they already had into the order set by the validating leader Each submitters transactions will stay in the order that they submitted them but may not be consectuive (e.g 145267839) V N … 123 456 789 N Consensus network establishes order as … 123 456 789

How a PBFT Network Works (3/4) – Execution … N Non-validating peer 789 123 456 N Δ V Validating peer V VL Validating Leader … 123 456 789 V N Δ … 123 456 789 VL This is the point the validators then execute the transactions Each validator independently runs the transactions in the order set previously and adds the results to a delta (Δ) in the world state. The delta can be rolled back if consensus is not achieved Δ V N … 123 456 789 N Consensus network establishes order as … 123 456 789 Δ

How a PBFT Network Works (4/4) – Distribution … N Non-validating peer 789 123 456 N V Validating peer V VL Validating Leader … 123 456 789 V N … 123 456 789 VL The validators then update the non-validators to that they have a copy of the latest blockchain and world state V N … 123 456 789 N Consensus network establishes order as … 123 456 789

Permissioned Ledger Access Security and Privacy

Security and privacy mechanisms Privacy of user-participation { Auditable mechanisms to grant users credentials to (anonymously) authenticate their transactions and secure their connection to the network. Membership Services Contract Privacy Accountability Non-repudiation { Auditable mechanisms to enable users to conceal their contracts and associated transactions to unauthorized nodes, while guaranteeing correctness. Mechanisms to offer these features are: -- membership services with support for privacy, that issue credentials for the users to make use of the system, and -- contract confidentiality mechanisms that ensure that contract logic is accessible only by authorized entities. Both mechanisms are auditable: -- membership services auditors are able to trace transactions of an individual, or the owner of a transaction -- contract auditors are able to read and verify content of a (confidential) contract and transactions associated to this Contract Confidentiality Mechanisms Auditability

Where are we now? Hyperledger Fabric v1

What We Have Learned Better support for confidentiality Scalable in number of participants and transaction throughput Eliminate non-deterministic transactions Enable pluggable data store Ability to upgrade fabric and chaincode Remove SPF and enable multiple providers of Membership Services

membership peer orderer v1.0 Architecture membership No SPoF No SPoT enroll peer SDK orderer Endorser Committer Ledger Events Chaincode Relay Order TXs in a batch according to consensus keys Proposal Batch Submit Tx state

Research Challenges – Data Layer Wide range of blockchain applications have different demands on Data model Query/analytics requirements Hyperledger supports a pluggable datastore (noSQL, RDBMS, …) What transactional capabilities and query interfaces are useful for blockchain apps? Can we optimize DBs for blockchain? Blockchain naturally supports provenance How was data used/accessed? Did data use adhere to specified policy? Data ownership Multiple organizations provide data, what is value for each data source? Incentive schemes for data providers Applications Smart Contracts Security Consensus Ledger

Queries from Data Owners Queries from Chief Data Officer Blockchain is a natural warehouse of data from multiple organizations in a business ecosystem Queries from Data Owners How was my data used? Was it used as per agreed upon contract? What kind of queries were well supported by my data? Prove that my payment is computed accurately? What was the change in access patterns as well as query results between & after data update? Queries from Chief Data Officer Generate verifiable data usage reports? Extract and group path for each query for pricing ? What is the incremental value gained (in terms of query served) after I acquired/updated Dataset B? How do I plan for scale given the data access, query and user patterns Data Provenance Metadata : Link to Atomic Original Data Packet, Date, Time, Purpose, Source of Acquisition & updates Data Transformation Provenance: Operation ID, Description, Previous & Subsequent Operation ID Data Access and Query Processing Request Details – Who, When, What, How & Why Current hyperledger fabric logs all transactions and data, but limited query capability on the log Who onboarded a customer on shared KYC solution? Give me list of containers that a truck has carried and routes followed. Who are the participants who handled a container and when? Shared replicated log of transactions and data Provenance & Governance chain

Research Challenges – Security and Privacy Support confidential transactions and contracts rather than allow entire network to see all information User anonymity Data privacy – challenging as blockchain depends on replication Ideas that leverage Secure Multiple Party Computation (MPC) and zero knowledge proofs Information leakage from linking transactions (many papers analyzing bitcoin transactions) Security vs scale Systems security Blockchain increases attack surface for data theft How to prevent malicious contracts from stealing data? Applications Smart Contracts Security Consensus Ledger

Research Challenges - Consensus Rich literature for over 25 years Bitcoin solved the problem of consensus in an open permissionless network Bitcoin network processes about 2-5 tx/sec Deliberately computationally expensive (proof of work) Many suggestions for scaling bitcoin, but in the 10x range In comparison: banking network 4000 tx/sec, paypal 100 tx/sec Bitcoin designed to scale in number of nodes, but not in number of transactions per second processed Permissioned networks scale in transactional throughput, but not in terms of number of nodes (e.g., byzantine fault tolerant algorithms) Exploration of consensus algorithms – different fault models, assumptions, scale Applications Smart Contracts Security Consensus Ledger

Research Challenges – Smart Contracts How to author smart contracts? Templates (Barclays’ Smart Contract Templates) Declarative specification (Digital Asset Modeling Language, xml-based) Finite State Automata / State machine Natural language? Verification of smart contracts (DAO hack in Ethereum) [NDSS ‘18] Generate verifiable compliance reports Legality of smart contracts? Other issues: Standardization Interoperability Applications Smart Contracts Security Consensus Ledger

Some Blockchain Platforms Bitcoin, https://bitcoin.org Ethereum, https://ethereum.org/ Hyperledger, https://www.hyperledger.org/ Fabric, https://wiki.hyperledger.org/projects/fabric.md Sawtooth Lake, https://wiki.hyperledger.org/projects/sawtooth-lake.md Ripple, https://ripple.com/ Dash, https://www.dash.org/ (privacy-centric digital currency, based on bitcoin) Lisk, https://lisk.io/ (public blockchain based on delegated proof of stake, sidechains for each app to help with scale) Steem, https://steem.io/ (public blockchain based on PoW, for social media platform)

Thanks! http://www.ibm.com/blockchain https://wiki.hyperledger.org

T E C H N O L G Y Party A’s records Bank’s records Auditor’s records Party B’s records Inefficient Expensive Vulnerable Digitally signed, encrypted transactions and ledger All parties have same replica of the ledger Party A Bank Auditor Party B Consensus Immutability Smart Contracts Provenance Finality I M P L C A T O N S Reduces Time Capital Markets Securities trading / settlement Syndicated loans, Commercial paper Commercial Banking Trade Finance Trade Logistics Retail Banking Payments: Cross border remittances Lending: Mortgage contracts Supply Chain Provenance Logistics Reduces Risk Removes Cost Enables New Business Models An emerging platform for transaction services that will fundamentally change and reimagine the way we do business

Permission-less vs Permissioned Blockchains Access Open read/write access to database Permissioned read/write access to database Scale Scale to a large number of nodes, but not in transaction throughput Scale in terms of transaction throughput, but not to a large number of nodes Consensus Proof of work/ proof of stake Closed membership consensus algorithms Identity Anonymous/pseudonymous Identities of nodes are known, but transaction identities can be private/anonymous/pseudonymous Asset Native assets Any asset/data/state *Modified from coindesk.com

Traceability/Provenance in Food Supply Chains Build a transformative end-to-end food traceability system, that cuts through the complex distribution and processing eco-system, to provide provenance of food items across the supply-chain (“farm to fork”). Benefits Increased trust Pinpoint source of compromised food, reducing the unnecessarily broad recall Improved co-ordination in food supply chain Handle changing regulations easily using smart contracts Supplier Distributor Consumer Product QR Code Information supply chain … Auditor

Financial Services Sector: Use Cases and Client Examples PAYMENT NETTING (FX) SETTLEMENT SYSTEMS Reduce trade settlement time by automating the end-to-end multi-party interactions Settlements through virtual currency Provide efficiency and resiliency across global FX markets in a standardized manner Low liquidity securities trading & settlement LOYALTY POINTS CONTRACT MANAGEMENT Build a peer-to-peer reward point trading system between banks, credit card users, gift shops, for seamless exchange of loyalty reward points Accelerate the Design, Management and Execution of Contracts among business partners on the Blockchain

Payment Netting Service with CLS Global market limited by Lack of standardized payment netting process (for trades not settled within the current CLS environment) Manual intervention for institutions to complete the process Inconsistent netting approaches, resulting in higher costs and increased intra-day liquidity demands CLS Group has partnered with IBM to release a payment netting service called CLS Netting This will be used for buy-side and sell-side institutions’ FX trades that are settled outside the CLS settlement service. Hyperledger based platform which delivers a standardized suite of post-trade and risk mitigation services for the entire FX market. “It (CLS Netting) is a significant step forward in reducing risk and providing further efficiencies and resilience across the global FX market.” David Puth CEO, CLS Group

Securities Settlement in Low Liquidity Markets with JPX Automating end-to-end multi-party interactions from trade execution to settlement on the blockchain for low liquidity trading Depository Stock Exchange Trade + Audit Bank A Investor Benefits Reduced settlement time Reduced settlement risk Lower cost transactions Bank B Investor Inter-Bank Payment Network Bank C Investor Securities Depository Clearing & settlement by chaincode Corporate Actions (Dividend, Stock Split, Etc) Settlement (Fund)

Blockchain Solution for Supply Chain Financing What? Improve the efficiency of supply chain financing or invoice discounting by sharing data in a secure and transparent manner on Blockchain How? Blockchain enables Comprehensive View of key operational data: Purchase Order > Transaction Approval > Shipments > Invoices > Remittances Benefits Process Efficiency Faster near real-time streamlined processing Dispute avoidance/faster resolution Capital Efficiency & Risk Reduction Lesser operational risk through automated duplication checks Transparent & efficient flow enables longer credit period New Markets New Products Attract customers deeper in the supply chain (tier 2, tier 3, logistics, ..) New financing products driven by better visibility Buyer Supplier IBM Global Financing 4000+ Partners and Suppliers 2.9M Invoices / year $44B Financed / Year $100M Capital tied up any time! 25,000 Disputes / year $31K Avg. disputed invoice value 44 days Avg. time to resolve a dispute

The Participants in a Blockchain Network Systems Context

The Participants in a Blockchain Network Regulator U Blockchain User B2B transactions Blockchain performs oversight Certificate Authority accesses security certificates D Blockchain Developer creates applications This shows the major participants within a Blockchain network and what they are doing within the network Details on next slide operates access to data Traditional Data Sources O Blockchain Network Operator access to logic Traditional Processing Platforms

The Components in a Blockchain Component Model

Blockchain Components Ledger … contains the current world state of the ledger and a Blockchain of transaction invocations Smart Contract f(abc); encapsulates business network transactions in code. transaction invocations result in gets and sets of ledger state a collection of network data and processing peers forming a Blockchain network. Responsible for maintaining a consistently replicated ledger Consensus Network Membership E T manages identity and transaction certificates, as well as other aspects of permissioned access Events creates notifications of significant operations on the Blockchain (e.g. a new block), as well as notifications related to smart contracts. Does not include event distribution. These are the major components within Hyperledger Blockchain, Additional Details: Membership – This is eCerts & tCerts. tCerts are equivialant to one time use certificates to be stored on the blockchain for the users linkable but hidden identity. Wallet – this term is used throughtout blockchain fabrics and does not store the money, only identification (eCert & tCerts) Systems Management i provides the ability to create, change and monitor Blockchain components Wallet securely manages a user’s security credentials Systems Integration responsible for integrating Blockchain bi-directionally with external systems. Not part of Blockchain, but used with it.

Consensus Considerations

Non-Deterministic Number Errors If each smart contract calls out to external system to receive information or uses a non-deterministic variable, it can prevent consensus being achieved. All external data sources should return the same result for the same calls and variables must be deterministic, any non-deterministic values must be defines as part of the transaction V VL N … 123 456 789 1005 1006 A consideration to be made when writing applications that will call upon external systems is the external system may not give the same result If different results are received by different vlidators, they will not reach consensus They should request the result before submitting the transaction and then submit the result as part of transaction 1007 External System Requested current mileage of moving car 1008

N V VL Duplicating Results +100 If each smart contract stores calls out to alter information in an external system, it could lead to duplication The UUID of each transaction or the nonce can be used so only one instance of the call will be added to any external system V VL N … 123 456 789 The inverse of the non-deterministic problem If each smart contract calls out to an external system, every validator will try to update the external system The external system should use a transaction ID to prevent duplication or External System +100 or +400 ?

Hyperledger Fabric Model Permission Issuer Ledger Transaction (defining contracts) Peer Peer Ledger fabric Client Application AliceApp Ledger Ledger Peer Validating Entities Peer Ledger Transaction (invoking contracts) Ledger Ledger fabric Client Peer Peer Application BobApp Permissioned system; strong identity management Distinct roles of users, and validators Users deploy new pieces of code (chaincodes) and invoke them through deploy & invoke transactions Validators evaluate the effect of a transaction and reach consensus over the new version of the ledger Ledger = total order of transactions + hash (global state) Pluggable consensus protocol, currently PBFT & Sieve

Security & privacy features Privacy of user-participation Each user has control over the degree to which its transaction activity will be shared with its environment Contract Privacy Contract logic can be confidential, i.e., concealable to unauthorized entities Accountability Non-repudiation Users can be accounted for the transactions they create, cannot frame other users for their transactions, or forge other users’ transactions. Privacy of users: Privacy of users relates to privacy of individuals, defined as the right to determine the degree to which that individual will interact and share information with its environment. Transactional privacy is strongly associated to anonymity and unlinkability of transactions. Privacy of contracts: Privacy of contracts is related but not covered by the privacy of the contract creator. Here we require anonymity of that contract being possible (as decided by its creator), and multiple transactions associated to that contract being unlinkable as such. Though strongly related, this property goes further than user transaction unlinkability, as transactions related to a contract can be owned by different users. One can capture this by simply saying that the logic behind a contract, i.e., what it does and how often it is used is concealable by unauthorized entities. Accountability/Non-frameability: Accountability = Users can be set accountable for transactions they create, Non-repudiation = Users cannot deny having created a transaction Accountability and non-repudiation imply the following properties: Non-frameability = Users cannot be blamed or set accountable for transactions they did not create Unforgeability = Users cannot modify other users’ transactions Auditability: Auditability, is the property to which auditors can access and verify every transaction they are authorized to do so. Auditability Auditors are able to access & verify any transaction they are legally authorized to

Transaction and Identity Privacy Transaction Certificates, Tcerts Disposable certificates, typically used once, requested from Transaction CA Tcert derived from long term identity - Enrollment Certificate, Ecert Only Transaction CA can link Ecert and Tcert Permissioned Interactions Consumer shares public Tcert to provider Provider invokes chain code transaction as usual, but Signs with provider’s private Tcert for authentication Encrypts with provider and consumer Tcerts for subsequent access Consumers can subsequently access ledger data using their private key Secure chaincode (smart contract) Chaincode can also be signed and encrypted, to keep verify and secure contract details Signing is by contract owner/author Encryption ensures only validators can see and execute transaction chain code

Next Generation Consensus Details of the proposed HyperLedger next generation consensus protocol

Next Generation Consensus Protocol Validation role will be split into 2 independent roles: Endorsement Endorsing a transaction verifying that its content obeys a given smart contract. Endorsers “sign” the contract Consensus Consenting the inclusion of a verified transaction in the ledger. Consensus controls what goes in the ledger making sure that the ledger is consistent

Peers and roles Generic peer: observes and stores the ledger Endorsing peer: receives a transaction proposal for endorsement, responds granting or denying endorsement Consenting peer: approves the inclusion of transaction blocks into the ledger

A sample transaction (1/6) Smart Contract E2 C E1 E3 Client App 1 (PROPOSE) A A B D E0 A B A B Blockchain Network The Client App proposes a transaction for Smart Contract A to the Endorsing peer E0. Endorsement policy: “E0, E1 and E2 must sign”. E3 is not part of the policy

A sample transaction (2/6) Smart Contract E2 C E1 E3 Client App 2 (TRANSACTION-VALID, anchor) A A B D E0 A B A B Blockchain Network 2. Endorsing peer E0 endorses a tx and (optionally) “anchors it” with respect to the ledger state version numbers. An “anchor” contains all data read and written by contract that are to be confirmed by other endorsers.

A sample transaction (3/6) Smart Contract E2 C E1 E3 Client App 1 (PROPOSE, anchor) A A B D E0 1 (PROPOSE, anchor) A B A B Blockchain Network 3. The client requests further endorsement from E1 and E2.The client may decide to suggest an anchor obtained from E0. to E1 and E2.

A sample transaction (4/6) Smart Contract E2 C E1 E3 Client App A A B D E0 3 (TRANSACTION-VALID) A B 3 (TRANSACTION- VALID) A B Blockchain Network 4. The Endorsing peers E1 and E2 send the endorsement to client.

A sample transaction (5/6) Smart Contract E2 C E1 E3 Client App A A B D E0 4 (BROADCAST) A B A B Blockchain Network 5. Client formats the transaction and broadcasts it to the consenters for inclusion in the ledger

A sample transaction (6/6) Smart Contract E2 C E1 E3 Client App A B A D E0 5 (DELIVER) 5 (DELIVER) A B 5 (DELIVER) 5 (DELIVER) A B 5 (DELIVER) Blockchain Network 6. The consensus service delivers the next block in the ledger with the consented transaction.