{'fraction_non_alphanumeric': 0.022712090848363394, 'fraction_numerical': 0.0026720106880427524, 'mean_word_length': 6.167464114832536, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Non‐blocking two‐phase commit using blockchain

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.