Created at 2am, Mar 13
HephaestionCrypto
0
Atomicity and Abstraction for Cross-Blockchain Interactions
dvIcmowropcT8kxysnMCxjErKrvPl5NhWIXCJKTQY3E
File Type
PDF
Entry Count
93
Embed. Model
jina_embeddings_v2_base_en
Index Type
hnsw

A blockchain facilitates secure and atomic transactions between mutually untrusting parties on that chain. Today, there are multiple blockchains with differing interfaces and security properties. Programming in this multi-blockchain world is hindered by the lack of general and convenient abstractions for cross-chain communication and computation. Current cross-chain communication bridges have varied and low-level interfaces, making it difficult to develop portable applications. Current methods for multi-chain atomic transactions are limited in scope to cryptocurrency swaps.This work addresses these issues. We first define a uniform, high-level interface for communication between chains. Building on this interface, we formulate a protocol that guarantees atomicity for general transactions whose operations may span several chains. We formulate and prove the desired correctness and security properties of these protocols. Our prototype implementation is built using the LayerZero cross-chain bridge. Experience with this implementation shows that the new abstractions considerably simplify the design and implementation of multi-chain transactions. Experimental evaluation with multi-chain swap transactions demonstrates performance comparable to that of custom-built implementations.

This is a two-phase protocol. A transaction is coordinated by a Proposer which is a smart contract on one of the blockchains. At a high level, the protocol follows the well known two-phase commit template for distributed database transactions. In the first phase, the proposer obtains agreement from all blockchains to freeze the portion of their state that is relevant to the operations in the transaction. In the second phase, the proposer executes operations from the transaction layer-by-layer, canceling the transaction if any individual operation fails. We prove that protocol executions are strictly serializable. In terms of the closely related concept of linearizability, this guarantees that every transaction appears to take effect instantaneously, which provides atomicity with respect to other cross-chain transactions that follow this protocol and any contract operations that may be invoked independently.
id: ef99cba62fb677aa1f3f07fbcdbb6aa8 - page: 7
Two features sharply distinguish this protocol from two-phase commit protocols on databases. First, as the proposer and all operations operate on blockchains, we may assume that the likelihood of a machine failure is negligible, because of the protections provided by the replication that is built into blockchains. This is in sharp distinction to two-phase commit protocols on distributed databases, which are complex largely because they must handle various machine failure scenarios involving the Proposer and the databases. As a result, our atomicity protocol is significantly simpler than database commit protocols. The second distinction arises from the inherently trustless setting. Thus, any atomic protocol must contend with the potential for malicious behavior. This aspect is absent from traditional database protocols. It has two consequences. First, if the Proposer issues an operation on a remote blockchain, there is no guarantee that this operation will actually be executed. Our
id: 4eb4c3d5357fe252e8d1c88f449b788e - page: 7
Second, our protocol relies on locking smart contract state. As the locking operations must be public, it is necessary to build in access controls to ensure
id: 9d7e72fe722b8546d6687a918f01131d - page: 7
7 that a malicious attacker cannot lock smart contracts to create a denial-of-service situation. To summarize, in the database domain, two-phase commit protocols focus on two types of failure: machine failures (i.e., machine crashes) and semantic failures (i.e., a failure within an operation, such as a divide-by-zero error). In our blockchain domain, machine failures may be ignored but, in their place, we must consider failures of trust, which arises from the potential for malicious attacks that aim to disrupt correctness or deny service. 5.3 Blockchain Assumptions We assume that two functionalities are provided by each blockchain that participates in transactions.
id: 9044afa9fc70605c127749daec664417 - page: 7
How to Retrieve?
# Search

curl -X POST "https://search.dria.co/hnsw/search" \
-H "x-api-key: <YOUR_API_KEY>" \
-H "Content-Type: application/json" \
-d '{"rerank": true, "top_n": 10, "contract_id": "dvIcmowropcT8kxysnMCxjErKrvPl5NhWIXCJKTQY3E", "query": "What is alexanDRIA library?"}'
        
# Query

curl -X POST "https://search.dria.co/hnsw/query" \
-H "x-api-key: <YOUR_API_KEY>" \
-H "Content-Type: application/json" \
-d '{"vector": [0.123, 0.5236], "top_n": 10, "contract_id": "dvIcmowropcT8kxysnMCxjErKrvPl5NhWIXCJKTQY3E", "level": 2}'