Transactions Between Distributed Ledgers Ivan Klianev Transactum Pty Ltd High Performance Transaction Systems Asilomar, California, 8-11 October 2017
The Time for Distributed Transactions Has Come Thanks to the Possibility of Leaderless Byzantine Consensus
Safety of Byzantine Consensus Unlike Two Phase Commit Does Not Depend Critically on Assumptions About: Trust Liveness Connectivity Adversary Attacks Random Behavior
Cross-Blockchain Transactions Architecture Two Connected Permissioned Blockchain Networks Blockchain Network A Blockchain Network B Escrow Sender Ledger A Recipient Ledger B Via - a business entity, which operates nodes in both networks
Cross-Blockchain Transactions Architecture Network-executed Escrow Contract TIMEOUT Escrow OR Escrow Sender Ledger A RECEIPT from RECIPIENT LEDGER Sender Ledger A On Timeout: Return the tokens Back On Receipt: Move the tokens Forward
Cross-Blockchain Transactions Step 1 Blockchain Network A Blockchain Network B Escrow Sender Ledger A Recipient Ledger B Account Sender transfers X tokens to account Escrow and starts an Escrow contract
Cross-Blockchain Transactions Step 2 Blockchain Network A Blockchain Network B Escrow Sender Ledger A Recipient Ledger B Account on ledger A transfers X tokens to account on ledger B
Cross-Blockchain Transactions Step 3 Blockchain Network A Blockchain Network B Escrow Sender Ledger A Recipient Ledger B Account on ledger B transfers X tokens to account Recipient
Cross-Blockchain Transactions Step 4 Blockchain Network A Send a Receipt Blockchain Network B Escrow Sender Ledger A Recipient Ledger B Network B sends a Receipt to network A
Cross-Blockchain Transactions Step 5 Blockchain Network A Blockchain Network B Escrow Sender Ledger A Recipient Ledger B Network A transfers the tokens on escrow to account
Cross-Blockchain Transactions Final State Blockchain Network A Blockchain Network B Escrow Sender Ledger A Recipient Ledger B Account on ledger A contains X tokens as before the transaction
Cross-Blockchain Transactions Spoiled Safety - a Trigger Blockchain Network A Blockchain Network B Escrow Sender Ledger A Recipient Ledger B Transfer to account Recipient is successful but delayed by a Byzantine-faulty Leader
Cross-Blockchain Transactions Spoiled Safety - Response TIMEOUT Blockchain Network A Blockchain Network B Escrow Sender Ledger A Recipient Ledger B The delay triggers a Timeout event: The Escrow contract returns the tokens back to account Sender
Cross-Blockchain Transactions Spoiled Safety - Outcome Blockchain Network A Send a Receipt Blockchain Network B Escrow Sender Ledger A Recipient Ledger B Account on ledger A has lost X tokens Account Sender has incorrectly received a Receipt
Classic Distributed vs.cross-blockchain What May Spoil the Safety In a Byzantine consensus network only the Protocol Leader does not tolerate any fault Possible Fault / Problem Tolerance by Protocol Roles 2PC 2PC PBFT Participants Coordinator All Replicas PBFT The Leader Process Crash-Fail YES Network Partition YES Hardware-Caused Random Behavior YES Software-Caused Random Behavior YES Operator Dishonesty to Another Operator YES Operator Dishonesty to Account Holder N/A YES Operator Dishonesty to Any Other Party N/A YES DDoS Attack on Process YES Process Hack YES
Leaderless Byzantine Consensus Reinforces the Liveness It has not been seen in practice, but it is not a fiction In 2010, Leslie Lamport was granted a patent for Synchronous Leaderless Byzantine Consensus We devised an environment and algorithm for Asynchronous Leaderless Byzantine Consensus
Asynchronous Consensus Contradicts CAP Theorem Bitcoin Network Workaround Utilizes the existence of multple communication paths Ensures consistency and availability regardless of partitions CAP Theorem still applies to Bitcoin Network A lasting partition of Internet between the two hemispheres would let spend each bitcoin once in each hemisphere
Asynchronous Consensus Contradicts CAP Theorem Our Workaround Circumvention of network partition between two nodes combining: Prevented stop-faults Use of indirect routes Use of signed messages Node 1 Example: Partition between Node 1 and Node 2 Byzantine nodes: Node 3 and Node 5 Network Behavior: Node 2 multicasts a message Missing Message Node 3 and Node 5 do not respond Node 4 responds sending the missed Message Node 2 Node 3 Node 5 Node 4
Asynchronous Consensus Contradicts the FLP Result Our Workaround Step 1: Eliminate the need of Proposer Fact: Consensus in FLP theorem is about the value of 1 bit It requires: Non-deterministic choice Proposer making the choice In contrast: Outcome of transactions ordering is a composite value It allows: Deterministic composition Consensus without a Proposer
Asynchronous Consensus Contradicts the FLP Result Our Workaround Step 2: Prevent Stop-faults of a Node Node as Cluster of Highly Available Functional Groups Client Communication Group Consensus Communication Group Consensus & Transaction Manager Group Data Partition Group 1... Data Partition Group N
Asynchronous Consensus Contradicts the FLP Result Our Workaround Step 2: Prevent Stop-faults of a Node Node as Cluster of Highly Available Functional Groups It ensures that a Stop-faulty process cannot prevent: Sending of consensus protocol messages High availability of transactions inside the node It implements ACID transactions with NoSQL engines, where: Replication of data does not affect the throughput¹ Multi-shard transactions improve the throughput² ¹,² http://www.hpts.ws/papers/2015/lightning/highly_available_atomic_consistency.pdf
Asynchronous Leaderless Byzantine Consensus Protocol Works in Two Phases and needs N = 2F + 1 Prologue Phase One Phase Two Epilogue Receiving Tx Requests Distribution of Received Tx Requests Distribution of Proposals for Tx Commits Transmitting Tx Responses Client 1 Client 2 Client 3 Node 1 Node 2 Node 3 Asynchronous Leaderless Byzantine Consensus Protocol Phases
Conclusion We presented Cross-Blockchain Transactions that guarantee both Safety and Liveness using Architecture for Leaderless Consensus
Thank You Ivan Klianev Transactum Pty Ltd