Table of Links
Abstract and 1 Introduction
2 Background and Related Work and 2.1 From Bitcoin to Blockchains
2.2 Open and Permissionless Blockchains
2.3 Interoperability Between Blockchains
3 Cross-Chain Query Language and 3.1 Integrated Data Model
3.2 Grammar and Query Processing Architecture
4 Evaluation of Implementation Feasibility and 4.1 Software and Hardware Configuration
4.2 Query Processing
4.3 Discussion
5 Conclusion and Outlook, Acknowledgment, and References
2.3 Interoperability Between Blockchains
Interoperability is widely acknowledged for transactions spanning multiple blockchains, established in cross-chain swaps and similar concepts practically implemented in so-called ’bridges’. Furthermore, efforts towards standardizing inhomogeneous data have commenced not only for query languages.
Cross-Chain Swaps. Swaps are typically initiated via a protocol on an originating blockchain, where tokens or arbitrary data are locked to prevent further transfer at the onset. A reciprocal transaction is then issued on a secondary blockchain to the initiator of the cross-chain swap, meaning another party often compensates for the tokens with a different asset on the second chain. This transaction includes a cryptographic proof with a secret that releases the tokens on the initial chain. Finally, the counterparty retrieves tokens from the originating chain. A wide array of protocols and variants have been developed on this foundational principle [20,25]. For atomic cross-chain swaps [13,30], atomicity is assured for all transfers involved in a cross-chain swap. Practical implementations in bridges, however, may exhibit different properties and assurances, not necessarily providing atomicity or other guarantees for the completion of the exchange. Bridges are primarily utilized for cryptocurrency exchanges; for example, Multichain[11], Portal[12], and others[13] facilitate cross-chain swaps between Ethereum, Avalanche, among others. However, cross-chain swaps and bridges lack standardization and do not provide uniform access or queries.
Inhomogeneous Data. Standardization efforts are underway to tackle the issue of inhomogeneous data, with sparse prior work addressing non-uniform access. For Ethereum, one study [19] explores a conceptual schema derived from the primary data structures of the blockchain. In [5], a query language is proposed for the content of blocks and transactions. This language design leans on SQL syntax and supports concepts such as projection and selection within Ethereum. For data analysis, a framework and its implementation based on Scala have been suggested [2], employing SQL or NoSQL alongside aggregation functions and similar analysis methods.
Another approach [7] details a data warehouse and ETL process for analyzing Ethereum data using standard SQL with a multi-dimensional data model for attribute dimension queries and data aggregation support. Although this and similar studies might connect to multiple blockchains, they fail to provide homogeneous data access, queries, or simultaneous access to data across multiple blockchains.
Additional work based on SQL includes [17], a study that uses multiple blockchains to populate a standard MySQL database with the third-party service Google BigQuery. However, the reliance on third-party services as data sources presents another commonly observed issue in previous research, where the validation of blockchain data is either impossible or severely restricted. Other methods comprise public connectors between blockchains, blockchains integrating with others, and hybrid approaches [3].
Interoperability Limitations in Prior Research. Present solutions face limitations in terms of (L1.) data access not being homogeneous, (L2.) incompatibility of node software functions and APIs not providing standardized queries, (L3.) software not being able to view and access data on one or more blockchains in parallel, and (L4.) missing verifiability of the blockchain data. The current emphasis is placed on cross-chain swaps and isolated data analysis as opposed to data integration. The query language proposed herein seeks to mitigate these restrictions by suggesting an integrated data model for uniform access (L1.), a grammar and concrete syntax for standardized access (L2.), a processing architecture supporting multiple blockchains in individual queries (L3.) as well as operating multiple nodes locally for verifying transactions (L4.).
Author:
(1) Felix Härer[0000 −0002 −2768 −2342], Digitalization and Information Systems Group, University of Fribourg, Switzerland ([email protected]).
[11] https://multichain.org/, 2023-06-30
[12] https://www.portalbridge.com/, 2023-06-30
[13] https://l2beat.com/bridges/tvl#active, 2023-06-30
