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

2. 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.

3. … 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

4. 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

5. 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

6. 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

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

8. 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.
Associate
Premier
General
108+ Members, 260%
Growth in 11 months

9. 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

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

11. 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

12. Operating Blockchain Networks
Configuring for a replicated ledger

13. 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

14. 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

15. 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 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 ) V N …
123
456
789 N
Consensus network establishes order as …
123
456
789

16. 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 Δ

17. 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

18. Permissioned Ledger Access
Security and Privacy

19. 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

20. Where are we now? Hyperledger Fabric v1

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. Some Blockchain Platforms
Bitcoin,
Ethereum,
Hyperledger,
Fabric,
Sawtooth Lake,
Ripple,
Dash, (privacy-centric digital currency, based on bitcoin)
Lisk, (public blockchain based on delegated proof of stake, sidechains for each app to help with scale)
Steem, (public blockchain based on PoW, for social media platform)

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

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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)

36. 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

37. The Participants in a Blockchain Network
Systems Context

38. 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

39. The Components in a Blockchain
Component Model

40. 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.

41. Consensus Considerations

42. 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

43. 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 ?

44. 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

45. 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

46. 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

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

48. 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

49. 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

50. 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

51. 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.

52. 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.

53. 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.

54. 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

55. 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.