Interoperability Between Fabric Networks

1. Interoperability Between Fabric Networks • https://jira.hyperledger.org/browse/FAB-13437 IBM Research, India *with contributions from Manish Sethi, IBM Blockchain

2. Agenda • Interoperability – our point of view • Atomic Commit • Use cases • Design goals • Existing techniques for atomic commit • Proposed technique • Transaction flow for atomic commit in Fabric • Pros, cons, and challenges

3. What is Blockchain Interoperability in our Point-of-View? We.Trade Tradelens KYC Land Records organization peers • Business ecosystems and processes may span multiple networks (e.g., trade logistics, trade finance and payments) coordination like nodes in a distributed database Channel 2 Channel 2 Channel 1 Channel 1 network & channel are interchangeably used throughout the presentation Fabric Network 2 Fabric Network 1 Why coordination is needed? • Atomic commit (e.g., delivery vs payment) • Trigger tx on an event (e.g., lock asset in one network and move to another network) • Verify a truth* (e.g., does invoice X with value Y exist on the network) • Linking assets (e.g., a mortgage asset created in one network is securitized and traded in another) Who can coordinate? • Clients • Peers • Both clients & peers Our Goal: Atomic commit of transactions between networks *can be solvedwithout modifying the platform

4. Atomic Commit: Use Cases client 1 client 3 client 2 • Atomic commit of a group of transactions each belong to a different network T1 T2 T3 organization peers Either commit all `3` transactions or none Network N3 Network N2 Network N1 Usecase 1: Usecase 2: Logistic Network: Transporter delivers goods to importer Finance Network: Importer pays transporter In a more complex scenario, importer may pay exporter (or exporter’s bank) upon receiving the delivery from transporter • X gives Y gold tokens in network A in exchange of Y giving X fiat currency tokens in network B

5. Atomic Commit: Design Goals • Minimal changes to the Fabric code base – changes in ledger component only • Coordination by the client/application – to support various use-cases; coordination among peers more complicated • Agnostic of different transaction types & data – token & endorsement, public & private data • Integrate well with existing features – dropping the ledger to rebuild, private data reconciliation • Leverage a well-known existing technique – for community acceptance • Interoperate with other non-Fabric platforms – in the future

6. Existing Techniques (1/5) 2-Phase Commit Protocol • Coordinator is trusted ☹ ; messages exchanged between nodes are trusted • Works if a single client wants to perform atomic commit between multiple networks • A new protocol based on 2PC that overcomes its shortcomings would be complicated and require many changes to Fabric 3-Phase Commit Protocol • Non-blocking • Can tolerate coordinator + member failure

7. Existing Techniques (2/5) Hashed Time Lock Contracts (HTLC) • Introduced to realize atomic swaps and making payments routable across two or more payment channels in Bitcoin lightning network • Key Idea: Conditional Commit • Our proposal is based on HTLC • Challenges in incorporating HTLC in Fabric • Endorsement model • Channel MSP and ACL (one organization in a network may not be able toquery ledger on another network if it is not a member). • No concept of blockchain time *Image Source: “Chain Interoperability”, VitalikButerin

8. Existing Techniques (3/5) Inter-Ledger Protocol (ILP) • Route payments atomically across multiple assets on different networks • Leverages the same concept of conditional hash-locked transactions and fulfillments Alice send money to Charlie via two connectors Connector-2 Alice Connector-1 pays pays pays ILSP ILSP Charlie Connector-1 Connector-2 Prepare Message [amount, executionCondition, expiryAt, destinationAddress, data] Execute Message [fulfillment] • To implement ILP we need the same building blocks as HTLC • Hyperledger Quilt implements ILP; can be extended to work with Fabric provided that HTLC is enabled • To implement this across multiple permissioned networks (and not just channels in Fabric), we also need to ensure that the identities of intermediaries / connectors are matched executionCondition, expiryAt, fulfillment are part of HTLC

9. Existing Techniques (4/5) Hashed TimeLock Agreements (HTLA) • HTLAs generalize the idea of HTLCs to include agreements that are enforced by a ledger • HTLAs enable secure Interledger payments through all types of ledgers, including those that do not support conditional transfers (i.e., HTLC) • Two parties using an HTLA over a ledger that does not support hashlocks and timeouts could proceed in the following manner. • The sender would send a message to the recipient telling them that they want to "prepare" a transfer with a given hashlock and timeout. • The parties agree that if the recipient presents the preimage of the hash before the timeout, the transfer is executed and the sender owes the recipient the money. • Debts are settled using simple transfers on the ledger • HTLAs as chaincodes in Fabric has risks due to our endorsement model • Once secret is revealed on the second network, endorsement could be denied on the first network to break atomicity; requires support for condition sharing to commit a locked transaction without going through endorsement • Requires the same building blocks as HTLC, in the case of Fabric

10. Existing Techniques (5/5) Federated Notaries, Relays, Relay Chain • Multiple notaries confirm the validity of information from one network on to another • Works under the assumption that the federated notaries can be collectively trusted • Requires the notaries to understand the blockchain protocol of both networks and also the underlying data model to validate information • Relays: Instead of relying on intermediaries, the networks themselves take on this role • Block from chain A is presented to a contract in chain B, that uses the standard verification procedure for chain A’s consensus algorithm to verify the block (performed on-demand) • Requires knowledge of the protocol and significant modifications to Fabric • Atomic swap can be supported as follows: • User X creates a contract in chain A permitting anyone to claim their assets as long as they provide requested target asset in chain B • User Y promises to pay X and locks X’s asset in chain A • User Y pays X in chain B; Relay automatically takes this as proof of Y’s delivery and completes payment to Y in chain A • Some known limitations and DoS attacks possible (B can lock A’s assets and prevent anyone else to trade with A, and also not settle with A) • Examples: BTCRelay, Polkadot

11. Atomic Commit: Proposed Technique • Hashed Block-To-Lock (HBTL) Protocol (inspired from HTLC) -- Conditional Commit in Fabric • After VSCC and MVCC checks (or) post order execution (token, enhanced MVCC), • the read-set is locked (no other tx can modify items in the read-set) • With state-based endorsement, the read set can be locked only if the endorser signature set matches the policy of each key in the read set • the write-set is put on hold, pending the fulfilment of a predefined condition, i.e., h == hash(secret) • When the secret is provided before a given block height, • the write-set is applied onto the ledger • the lock on read-set is released • After a given block height (if the tx is still waiting for the secret), • the lock on the read-set is removed • the write-set is discarded. later in the presentation, we show how time can used used instead of block height for the transaction expiration Let’s solve the atomic commit between Logistics and Finance network using Hashed BTL Protocol

12. Atomic Commit: Options for Timeout • Use block height to specify timeout • Similar to private data expiry • Challenge: Different chains may be adding blocks at different rates; client needs to set timeout to a large enough value to avoid losing assets because of timeout • Use an approximate notion of elapsed time • Create blocks only on timeout and not when block size limit is reached • Block height provides an approximate notion of elapsed time • Real-time • Bind blockchain time to real-world time (e.g., used for standard X.509 certificates expiration) -- https://jira.hyperledger.org/browse/FAB-3678 • Byzantine behavior could be complicated to address We will use block height to describe the protocol, but any approximate notion of elapsed time can be leveraged to implement timeout

13. Atomic Commit: Transactions Flow – Phase 1 (Secret holder submits Tx) Tx Type: CONDITIONAL_COMMIT T1 & T2 T1 -- Transporter delivers shipment to company X T2 -- Company X pays the transporter secret s, h h (1) Transporter creates a secret ‘s’ and shares the ‘h’, i.e., Hash(s) with X Transporter X (7) Inform X about the waiting T1 (2) endorsement for T1 with a HBTL using the hash ‘h’ & a BTL (2) endorsement for T2 with a HBTL using the hash ‘h’& a BTL (3) endorsement response of T1 (6) event (4) block Ordering service Ordering service Logistics Network Finance Network (5) each peer employs HBTL, i.e., performs VSCC => MVCC => locks read-set => adds write-set to waiting list Assumption: Transporter and X are part of both the networks

14. Atomic Commit: Transactions Flow – Phase 2 (non-secret holder submits) Tx Type: CONDITIONAL_COMMIT T1 & T2 T1 -- Transporter loads a shipment of company X into the shipping container T2 -- Company X pays the transporter (13) inform transporter about the waiting T2 Transporter X (14) Transporter query for T2 from the waiting list & performs any needed validation (8) X query for T1 from the waiting list & performs any needed validation (9) endorsement response of T2 (12) event Ordering service Ordering service (10) block Logistics Network Finance Network (11) each peer employs HBTL, i.e., performs VSCC => MVCC => locks read-set => adds tx write-set to waiting list (5) each peer employs HBTL, i.e., performs VSCC => MVCC => locks read-set => adds tx write-set to waiting list

15. Atomic Commit: Transactions Flow – Phase 3 (secret sharing & commit) T2.C -- Transporter shares the secret ‘s’ with Finance Network to commit T2 T1.C -- X shares the secret ‘s’ with LogisticsNetwork to commit T1 Tx Type: CONDITIONAL_SHARING T1.C & T2.C Shipper X (15) T2.C -- shares the secret ‘s’ to commit T2 (19) T1.C -- shares the secret ‘s’ to commit T1 (18) event with secret ‘s’ (22) event Ordering service (20) block Ordering service (16) block Logistics Network Finance Network (17) For T2 -- each peer checks whether ‘h’ == hash(s) and applies the write-set to ledger (21) For T1 -- each peer checks whether ‘h’ == hash(s) and applies the write-set to ledger

16. Atomic Commit: Pros of Proposed Approach • As the coordination is performed by clients involved in transactions, similar flow solves • Multi party atomic swaps (fabtoken) • Movement of assets/documents between networks (i.e., consume on N1 and create on N2) • Approach can be realized by minimal changes to the existing Fabric code base (majority of changes in ledger component only) • Two new transaction types – CONDITIONAL_COMMIT, CONDITION_SHARING • A lock list for keys in the ledger component (to restrict any writes on these keys by further transactions) • A waiting list of write-set in the ledger component • A new query type over QSCC to fetch the info about a waiting transaction (read-set, write-set) • Can interoperate with other blockchain platforms which implement HTLC such as bitcoin

17. Atomic Commit: Challenges (includes cons) • What if clients involved in an atomic commit are not a member in each other network? • What value should be assigned as a timeout, i.e., Block To Lock (BTL)? • BTL can be replaced with time as described later in this presentation • How to recover from a network or a client failure? • How clients can handle deadlocks? • What infrastructure is needed between clients to share the hash(secret) & to have other communication between them for coordinating the commit?

18. Resolving Challenges: Identity Discovery Problem: Clients involved in the atomic commit are not a member in other network Approach 1: Add a public key in each transaction. A client with the private key can query the waiting transaction and submit the secret Approach 2: Introduce citizens and visitorsMSPin the channel configuration & provide appropriate rw policy policy Citizens MSP Readers: Org1-MSP, Org2-MSP, Org3-MSP Writers : Org1-MSP,,Org3-MSP  policy Citizens MSP Readers: Org5-MSP, Org6-MSP Writers : Org5-MSP, Org6-MSP  policy policy Visitors-MSP From-Network-2 Readers: Org5-MSP, Org6-MSP Writers : Org5-MSP, Org6-MSP  Visitors-MSP From-Network-1 Readers: Org1-MSP, Org3-MSP Writers : Org1-MSP, Org3-MSP  Channel-1 Configuration Channel-2 Configuration

19. Resolving Challenges: Block To Lock Value • Block accumulation speed varies on each network • BTL per transaction should be assigned based on the block accumulation speed such that sufficient time is given to complete the transaction flow • Lower BTL => Risky as it could break the atomicity • Higher BTL => Client withdrawing in-between could end up locking the asset for a prolonged time • Need to design the data model in such a way that a prolonged lock does not affect other operations • In the private enterprise network, attacks are going to be rare (like a client intentionally withdrawing in between an atomic commit) • Assigning Higher BTL is safe (during attacks, assets are locked for a prolonged time but a rare scenario) what if we could introduce elapsedTime in Fabric?

20. Resolving Challenges: Time in Fabric instead of BTL • Current ordering service in Fabric creates and emit a block whenever • a timeout occurs (or) • the block size limit is reached (either the size or #tx) • As there are two events that could result in the block emission, we are unable to use the timeout value to get the approximate real timestamp • Proposed Approach: make Fabric ordering service to emit a block on a timeout and not based on the size (which has some performance issue but can be solved differently). Note that it is not necessary for the ordering service to emit strictly at the timeout boundary • When a peer receives a block, it can find the elapsedSeconds by calculating blockNumber * timeoutValue (this might have a significant drift from the real time as well) • The elapsedTime calculated by the slow peer would be behind the fast peer. Given that the peer is slow, we can assume that the peer is running in the past time. What we guarantee is that all peers timeout the lock when a particular block height is reached (i.e., block# * timeout > validSeconds) • This solution could enable us to use timelock for HTLC instead of BTL

21. Resolving Challenges: Time Instead of BTL (1/2) Tx Type: CONDITIONAL_COMMIT T1 & T2 T1 -- Transporter loads a shipment of company X into the shipping container Expiry Time: 30 seconds T2 -- Company X pays the transporter Expiry Time: 20 seconds Transporter X Whenever a block is processed, elapsedTime += BlockTimeout Whenever a block is processed, elapsedTime += BlockTimeout (3) endorsement response of T1 (9) endorsement response of T2 (4) block Ordering service Ordering service (10) block Block Timeout: 1 sec Block Timeout: 2 secs Logistics Network Finance Network (11) each peer employs HBTL, i.e., performs VSCC => MVCC => locks read-set => adds tx write-set to waiting list • Assumption: current block height is 20 • Lock is valid for 20 seconds • As the block timeout is 2 second, when the peer receives the block 30, the lock hold by this transaction expires (5) each peer employs HBTL, i.e., performs VSCC => MVCC => locks read-set => adds write-set to waiting list • Assumption: current block height is 20 • Lock is valid for 30 seconds • As the block timeout is 1 second, when the peer receives the block 50, the lock hold by this transaction expires

22. Resolving Challenges: Time Instead of BTL (2/2) T2.C -- Transporter shares the secret ‘s’ with finance network to commit T2 T1.C -- X shares the secret ‘s’ with logistics network to commit T1 Tx Type: CONDITIONAL_SHARING T1.C & T2.C Transporter X If ordering service has already created > 50 blocks, (i.e., 20 seconds has elapsed), it means that T1 is already expired. It means that X Failed to agree upon a sufficient delta time (similar problem do exist With other blockchain platform as well as it is the problem associated With HTL technique. If ordering service has already created > 30 blocks, (i.e., 30 seconds has elapsed), it means that T2 is already expired. Don’t share the secret. Only if there is a sufficient time left over, share the secret. (18) event with secret ‘s’ (19) T1.C -- shares the secret ‘s’ to commit T1 (15) T2.C -- shares the secret ‘s’ to commit T2 Secret sharing tx is prioritized over other while creating the next block Secret sharing tx is prioritized over other while creating the next block Ordering service (20) block Ordering service (16) block Logistics Network Finance Network (17) For T2 -- each peer checks whether ‘h’ == hash(s) and applies the write-set to ledger (21) For T1 -- each peer checks whether ‘h’ == hash(s) and applies the write-set to ledger

23. Interledger Protocol & HTLA

24. Interledger Protocol: Motivation • Use-Case:Payments across multiple assets in different ledgers • Alice wants to send some money to Charlie using cryptocurrency • Alice has bitcoin but Charlie wants ether. Bob agrees to trade for a commission. Alice Bob • Using Hashed Timelock Contract (HTLC), both transactions can commit atomically • Charlie creates secret ‘s’ & shares hash(s) with Alice • Bitcoin, Ethereum, Stellar, Corda supports Hashed Timelock Contracts pays pays Bob Charlie Challenges with above approach (why an interledger protocol is needed?): • How to find an intermediator (like Bob) who can trade for a lowest commission? • What if the trade has to happen over multiple blockchain network? • Bitcon -> Stellar -> Ether • How to find multiple intermediators? • How the intermediator pass messages between Bitcoin and Ethereum network? – for e.g., the secret in HTLC

25. Interledger Protocol: Key Idea • Special identities called connectors in each blockchain network • Networking protocol between connectors to pass messages (network packets) • Service providers (like ISP) to route traffic Connector-2 Alice Connector-1 Alice send money to Charlie via two connectors pays pays pays ILSP ILSP Charlie Connector-1 Connector-2 Prepare Message [amount, executionCondition, expiryAt, destinationAddress, data] Execute Message [fulfillment] executionCondition, expiryAt, fulfillment are part of HTLC

26. Interledger Protocol: what it is and what it is not? • Payment networks are disconnected • Internetworking for payment networks using interledger protocol • Interledger protocol is suitable to implement a decentralized exchange & multi party swaps (fabtoken) • Interledger protocol is not suitableto implement enterprise use-case in a private blockchain network Logistic Network: Transporter loads a shipment of company X into the shipping containerFinance Network: Company X pays the transport company Both the payment and event should happen atomically Image source: https://www.slideshare.net/Interledger/34c3-interledger-presentation-background-streaming-payments-and-implications

27. Background: Hashed Timelock Agreement • HTLAs generalize the idea of HTLCs to include agreements that are enforced by a ledger • HTLAs enable secure Interledger payments through all types of ledgers, including those that do not support conditional transfers (i.e., HTLC) • Two parties using an HTLA over a ledger that does not support hashlocks and timeouts could proceed in the following manner. • The sender would send a message to the recipient telling them that they want to "prepare" a transfer with a given hashlock and timeout. • The parties agree that if the recipient presents the preimage of the hash before the timeout, the transfer is executed and the sender owes the recipient the money. • Debts are settled using simple transfers on the ledger • HTLAs in Fabric has risks mainly due to our endorsement model

28. HTLA in the Endorsement Model: Smart-Contracts Logistic Network: Transporter loads a shipment of company X into the shipping container (event) Finance Network: Company X pays the transport company (payment) • Let’s atomically commit the following two transactions using HTLA • Logistics Network’s Smart-Contract: • store() -- store an agreement, i.e., pay transporter when h == hash(s) ➔ put(h, “pay transporter via bank finance A”) • execute(s) -- execute an agreement ➔ h = hash(s); agreement = get(h); execute the agreement • Finance Network’s Smart-Contract: • store() -- store an agreement–, i.e., load shipment S1 when h == hash(s) ➔ put(h, “load shipment S1”) • execute(s) -- execute an agreement ➔ h = hash(s); agreement = get(h); execute the agreement

29. HTLA in the Endorsement Model: Transaction Flow • Transporter creates secret ‘s’ and share only the hash(s) with Company X • Both Transporter and Company X should be a member in both networks • Transporter collects endorsement by invoking store() on the Logistics network’s smart-contract & submits to OSN • Company X collects endorsement by invoking store() on the Finance network’s smart-contract & submits to OSN • Transporter collects endorsement by invoking execute(s) on the Finance smart-contract • Two Possibilities • Company X could deny endorsing the transaction and acquire s (its fine as Transporter could deny endorsement on Logistics Network) (OR) • Company X endorse the transaction • Company X collects endorsement by invoking execute(s) on the Logistics network’s smart-contract • Two Possibilities • Transporter could deny endorsing the transaction (attack scenario if the transaction in Finance network is already committed) (OR) • Transporter endorse the transaction • When company X endorses but Transporter reject, we could get into trouble • As per the agreement, when ‘s’ is revealed, Transporter should endorser. • Dispute can be handled easily as the agreement is present in the ledger

30. Conclusion • HTLC in Fabric • Pros • Can work perfectly without any risk (as shown in the other slide) • Participating members in atomic transactions group need not be a member in other networks • Cons • Require changes in Fabric code base • HTLA in Fabric • Pros • No or minimal changes required in Fabric code base • Cons • Has some risk due to our endorsement model but dispute can be resolved as agreements are stored in the blockchain • Participating members in atomic transactions group must be a member in other networks • As no timeouts feature, even after a year or so, the secret should never be revealed