Premium
Non‐blocking two‐phase commit using blockchain
Author(s) -
Ezhilchelvan Paul,
Aldweesh Amjad,
Moorsel Aad
Publication year - 2019
Publication title -
concurrency and computation: practice and experience
Language(s) - English
Resource type - Journals
SCImago Journal Rank - 0.309
H-Index - 67
eISSN - 1532-0634
pISSN - 1532-0626
DOI - 10.1002/cpe.5276
Subject(s) - blockchain , computer science , commit , two phase commit protocol , blocking (statistics) , protocol (science) , compensating transaction , correctness , abort , distributed computing , vulnerability (computing) , computer security , computer network , distributed transaction , database , transaction processing , operating system , database transaction , programming language , medicine , alternative medicine , pathology
Summary The two‐phase commit (2PC) protocol has long been known to have a provably inevitable vulnerability to blocking or non‐progress amidst server crashes, even when the distributed database system guarantees the most demanding timing‐related or “synchrony” requirements. Our aim here is to eliminate this vulnerability by using a blockchain for coordinating 2PC execution. We present the impossibilities, the possibilities, the cost, and the trade‐offs in this blockchain‐based approach to blocking‐free management of distributed transactions. We prove that a non‐blocking and blockchain‐coordinated 2PC protocol can exist only if both the blockchain and distributed database systems meet synchrony requirements; otherwise, although blocking remains eliminated, transactions can unnecessarily abort. We present a blockchain‐coordinated 2PC protocol and provide rigorous arguments for its correctness under the synchrony requirements. We then implement this protocol on the Ethereum Testnet and demonstrate, through our experiments, that the monetary cost of executing smart contracts is quite small, that the protocol performance slows down when using a public blockchain like Ethereum, and that even major violations of synchrony requirements lead only to relatively small increases in unnecessary aborts. We thus identify a trade‐off between improving protocol performance and admitting a risk that transactions could occasionally abort unnecessarily.