Interoperability Between Fabric Networks https jira hyperledger orgbrowseFAB13437

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

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

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

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

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

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 2 PC that overcomes its shortcomings would be complicated and require many changes to Fabric 3 -Phase Commit Protocol • Non-blocking • Can tolerate coordinator + member failure 6 / 14

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 to query ledger on another network if it is not a member). • No concept of blockchain time 7 / 14 *Image Source: “Chain Interoperability”, Vitalik Buterin

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 pays Connector-1 Connector-2 Connector-1 ILSP pays ILSP Connector-2 Alice send money to Charlie via two connectors pays Charlie Prepare Message [amount, execution. Condition, expiry. At, destination. Address, data] Execute Message [fulfillment] execution. Condition, expiry. At, fulfillment are part of HTLC • 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 8 / 14

Existing Techniques (4/5) Hashed Time. Lock 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. 1. The sender would send a message to the recipient telling them that they want to "prepare" a transfer with a given hashlock and timeout. 2. 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. 3. 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 9 / 14

Existing Techniques (5/5) Federated Notaries, 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 Do. S 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 10 / 14

Atomic Commit: Proposed Technique • Hashed Block-To-Lock (HBTL) Protocol (inspired from HTLC) -- Conditional Commit in Fabric 1. 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) 2. 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 later in the presentation, we show time can used instead of block height for the transaction expiration 3. 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. Let’s solve the atomic commit between Logistics and Finance network using Hashed BTL Protocol 11 / 14

Atomic Commit: Options for Timeout 1. 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 2. 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 3. 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 12 / 14

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

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

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

Atomic Commit: Pros of Proposed Approach 1. 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 N 1 and create on N 2) 2. 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) 3. Can interoperate with other blockchain platforms which implement HTLC such as bitcoin 16 / 14

Atomic Commit: Challenges (includes cons) 1. What if clients involved in an atomic commit are not a member in each other network? 1. 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 1. How to recover from a network or a client failure? 1. How clients can handle deadlocks? 1. What infrastructure is needed between clients to share the hash(secret) & to have other communication between them for coordinating the commit? 17 / 14

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 visitors MSP in the channel configuration & provide appropriate rw policy Citizens MSP Readers: Org 1 -MSP, Org 2 -MSP, Org 3 -MSP Writers : Org 1 -MSP, , Org 3 -MSP Visitors-MSP From-Network-2 Readers: Org 5 -MSP, Org 6 -MSP Writers : Org 5 -MSP, Org 6 -MSP policy Channel-1 Configuration Citizens MSP Readers: Org 5 -MSP, Org 6 -MSP Writers : Org 5 -MSP, Org 6 -MSP policy Visitors-MSP From-Network-1 Readers: Org 1 -MSP, Org 3 -MSP Writers : Org 1 -MSP, Org 3 -MSP policy Channel-2 Configuration 18 / 14

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 elapsed. Time in Fabric? 19 / 14

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 elapsed. Seconds by calculating block. Number * timeout. Value (this might have a significant drift from the real time as well) • The elapsed. Time 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 > valid. Seconds) • This solution could enable us to use timelock for HTLC instead of BTL 20 / 14

Resolving Challenges: Time Instead of BTL (1/2) T 1 -- Transporter loads a shipment of company X into the shipping container Expiry Time: 30 seconds Tx Type: CONDITIONAL_COMMIT T 1 & T 2 -- Company X pays the transporter Expiry Time: 20 seconds Transporter X Whenever a block is processed, elapsed. Time += Block. Timeout (4) block Logistics Network (3) endorsement response of T 1 Ordering service Block Timeout: 1 sec (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 (9) endorsement response of T 2 Ordering service Whenever a block is processed, elapsed. Time += Block. Timeout (10) block Block Timeout: 2 secs 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 21

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

Interledger Protocol & HTLA 23 / 14

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 pays Bob pays Charlie • 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 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

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 Alice pays Connector-1 Connector-2 Connector-1 ILSP pays ILSP Connector-2 pays Alice send money to Charlie via two connectors Charlie Prepare Message [amount, execution. Condition, expiry. At, destination. Address, data] Execute Message [fulfillment] execution. Condition, expiry. At, fulfillment are part of HTLC 25 / 14

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 suitable to implement enterprise use-case in a private blockchain network Logistic Network : Transporter loads a shipment of company X into the shipping container Finance Network : Company X pays the transport company Both the payment and event should happen atomically Image source: https: //www. slideshare. net/Interledger/34 c 3 -interledger-presentation-background-streaming-payments-and-implications

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. 1. The sender would send a message to the recipient telling them that they want to "prepare" a transfer with a given hashlock and timeout. 1. 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. 1. Debts are settled using simple transfers on the ledger • HTLAs in Fabric has risks mainly due to our endorsement model

HTLA in the Endorsement Model: Smart-Contracts • Let’s atomically commit the following two transactions using HTLA Logistic Network : Transporter loads a shipment of company X into the shipping container (event) Finance Network : Company X pays the transport company (payment) • 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 S 1 when h == hash(s) ➔ put(h, “load shipment S 1”) • execute(s) -- execute an agreement ➔ h = hash(s); agreement = get(h); execute the agreement

HTLA in the Endorsement Model: Transaction Flow 1. Transporter creates secret ‘s’ and share only the hash(s) with Company X 1. Both Transporter and Company X should be a member in both networks 1. Transporter collects endorsement by invoking store() on the Logistics network’s smart-contract & submits to OSN 1. Company X collects endorsement by invoking store() on the Finance network’s smart-contract & submits to OSN 1. 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 1. 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 1. 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

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