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 Background and Related Work The section at hand introduces blockchain fundamentals, discusses open and permissionless blockchains, and existing interoperability approaches. 2.1 From Bitcoin to Blockchains Following the posting of the Bitcoin whitepaper and corresponding software in 2008 and 2009, respectively [22,23], the term ’blockchain’ emerged as a general term encapsulating its technical architecture. The primary components: (1) a data structure of blocks, arranged in a backward-linked list or any graph, (2) a peer-to-peer network for data distribution, and (3) a consensus protocol, give rise to innovative properties. These notably include the ability to coordinate and validate all operations without trusted third parties or centralized control, open access to all data and operations, and permissionless access, whereby data and operations are not restricted to specific participants [9,1]. Ethereum and subsequent blockchains have enhanced these capabilities by incorporating smart contracts, acting as quasi Turing-complete programs [28,6]. Beyond payments and currency, smart contracts facilitate e-commerce, sales contracts, timestamping, and attestations, among other applications [16,18,11]. 2.2 Open and Permissionless Blockchains The progressive development and adoption springing from Bitcoin and Ethereum have yielded OPB with diverse characteristics. Table 1 catalogs five renowned OPB in the order of their public node count, highlighting the properties of their data structures, networks, and consensus protocols, as well as features pertinent to smart contracts. Data Structure. The original design of backward-linked blocks in Bitcoin is coupled with additional trees or graphs in most other OPB. Beyond transactional data from blocks, supplementary queries must be performed for nontransactional data or older data that has undergone pruning. For instance, separate tree structures are incorporated for state storage in Ethereum, where balances and smart contract variables can be accessed [19]. Network. Well-known OPB networks comprise approximately 1300 to 16000 nodes. With algorithmic operation and validation, an increased node count augments security, such as in mitigating the risks associated with 51% attacks and selfish mining [26,24], which are frequently observed in smaller Proof-of-Work systems, e.g. ’Bitcoin Gold’ [24]. Consensus Protocol. Between 2008 and 2022, a shift in the initially created protocols can be observed, veering away from Proof-of-Work towards Proof-ofStake, which introduces several trade-offs. While established blockchains such as Bitcoin and Ethereum have prioritized security and decentralization over the years, Cardano [15], Avalanche [21], and Solana [29] demonstrated enhancements in efficiency and scalability. This trend is mirrored in the development of novel consensus protocols based on by Proof-of-Stake [10,8] with higher efficiency, advantages to environmental impact, enhanced security, and potentially higher distribution and scalability. For example, Ethereum realizes Proof-of-Stake through GASPER, a combination of the consensus algorithm Caspar-FFG ("Casper the Friendly Finality Gadget") and LMD-GHOST (Latest Message Driven Greedy Heaviest Observed Sub-Tree)[7]. Based on Caspar-FFG, blocks are proposed in slots of 12 seconds, part of 6.4-minute epochs of 32 slots, by the staking network nodes. The node proposing a block is randomly chosen while other nodes are organized in randomly formed subnets to carry out validations that are aggregated in attestations. Typically, a block is finalized within two epochs with improvements toward single-slot finality[8]. In the case of chain splits, this design together with the fork choice rule has proven itself in practice, demonstrating improved efficiency, decentralization, and security[9]. Other blockchains focus especially on scalability, e.g. Solana. However, temporary protocol failures can be observed frequently, resulting in non-availability [12]. Smart Contract Support. Smart contract features are essential for data queries and software applications. Bitcoin offers a limited scripting language employed for programmable monetary transactions and the scalable lightning overlay network. The advent of general-purpose programming in Ethereum and similar platforms introduces a broader range of capabilities and complexity. Currently, most implementations are written and compiled for the Ethereum Virtual Machine, which is present in Ethereum and Avalanche. On the contrary, Cardano and Solana embrace markedly different paradigms. For instance, Cardano supports functional programming, preventing side effects and implementation errors, thus, possibly enhancing security and safety properties[10]. Author:
(1) Felix Härer[0000 −0002 −2768 −2342], Digitalization and Information Systems Group, University of Fribourg, Switzerland (felix.haerer@unifr.ch). This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. Table of Links Abstract and 1 Introduction Abstract and 1 Introduction 2 Background and Related Work and 2.1 From Bitcoin to Blockchains 2 Background and Related Work and 2.1 From Bitcoin to Blockchains 2.2 Open and Permissionless Blockchains 2.2 Open and Permissionless Blockchains 2.3 Interoperability Between Blockchains 2.3 Interoperability Between Blockchains 3 Cross-Chain Query Language and 3.1 Integrated Data Model 3 Cross-Chain Query Language and 3.1 Integrated Data Model 3.2 Grammar and Query Processing Architecture 3.2 Grammar and Query Processing Architecture 4 Evaluation of Implementation Feasibility and 4.1 Software and Hardware Configuration 4 Evaluation of Implementation Feasibility and 4.1 Software and Hardware Configuration 4.2 Query Processing 4.2 Query Processing 4.3 Discussion 4.3 Discussion 5 Conclusion and Outlook, Acknowledgment, and References 5 Conclusion and Outlook, Acknowledgment, and References 2 Background and Related Work The section at hand introduces blockchain fundamentals, discusses open and permissionless blockchains, and existing interoperability approaches. 2.1 From Bitcoin to Blockchains Following the posting of the Bitcoin whitepaper and corresponding software in 2008 and 2009, respectively [22,23], the term ’blockchain’ emerged as a general term encapsulating its technical architecture. The primary components: (1) a data structure of blocks, arranged in a backward-linked list or any graph, (2) a peer-to-peer network for data distribution, and (3) a consensus protocol, give rise to innovative properties. These notably include the ability to coordinate and validate all operations without trusted third parties or centralized control, open access to all data and operations, and permissionless access, whereby data and operations are not restricted to specific participants [9,1]. Ethereum and subsequent blockchains have enhanced these capabilities by incorporating smart contracts, acting as quasi Turing-complete programs [28,6]. Beyond payments and currency, smart contracts facilitate e-commerce, sales contracts, timestamping, and attestations, among other applications [16,18,11]. 2.2 Open and Permissionless Blockchains The progressive development and adoption springing from Bitcoin and Ethereum have yielded OPB with diverse characteristics. Table 1 catalogs five renowned OPB in the order of their public node count, highlighting the properties of their data structures, networks, and consensus protocols, as well as features pertinent to smart contracts. Data Structure. The original design of backward-linked blocks in Bitcoin is coupled with additional trees or graphs in most other OPB. Beyond transactional data from blocks, supplementary queries must be performed for nontransactional data or older data that has undergone pruning. For instance, separate tree structures are incorporated for state storage in Ethereum, where balances and smart contract variables can be accessed [19]. Data Structure. Network . Well-known OPB networks comprise approximately 1300 to 16000 nodes. With algorithmic operation and validation, an increased node count augments security, such as in mitigating the risks associated with 51% attacks and selfish mining [26,24], which are frequently observed in smaller Proof-of-Work systems, e.g. ’Bitcoin Gold’ [24]. Network Consensus Protocol. Between 2008 and 2022, a shift in the initially created protocols can be observed, veering away from Proof-of-Work towards Proof-ofStake, which introduces several trade-offs. While established blockchains such as Bitcoin and Ethereum have prioritized security and decentralization over the years, Cardano [15], Avalanche [21], and Solana [29] demonstrated enhancements in efficiency and scalability. This trend is mirrored in the development of novel consensus protocols based on by Proof-of-Stake [10,8] with higher efficiency, advantages to environmental impact, enhanced security, and potentially higher distribution and scalability. For example, Ethereum realizes Proof-of-Stake through GASPER, a combination of the consensus algorithm Caspar-FFG ("Casper the Friendly Finality Gadget") and LMD-GHOST (Latest Message Driven Greedy Consensus Protocol. Heaviest Observed Sub-Tree)[7]. Based on Caspar-FFG, blocks are proposed in slots of 12 seconds, part of 6.4-minute epochs of 32 slots, by the staking network nodes. The node proposing a block is randomly chosen while other nodes are organized in randomly formed subnets to carry out validations that are aggregated in attestations. Typically, a block is finalized within two epochs with improvements toward single-slot finality[8]. In the case of chain splits, this design together with the fork choice rule has proven itself in practice, demonstrating improved efficiency, decentralization, and security[9]. Other blockchains focus especially on scalability, e.g. Solana. However, temporary protocol failures can be observed frequently, resulting in non-availability [12]. Smart Contract Support. Smart contract features are essential for data queries and software applications. Bitcoin offers a limited scripting language employed for programmable monetary transactions and the scalable lightning overlay network. The advent of general-purpose programming in Ethereum and similar platforms introduces a broader range of capabilities and complexity. Currently, most implementations are written and compiled for the Ethereum Virtual Machine, which is present in Ethereum and Avalanche. On the contrary, Cardano and Solana embrace markedly different paradigms. For instance, Cardano supports functional programming, preventing side effects and implementation errors, thus, possibly enhancing security and safety properties[10]. Smart Contract Support. Author: (1) Felix Härer[0000 −0002 −2768 −2342], Digitalization and Information Systems Group, University of Fribourg, Switzerland (felix.haerer@unifr.ch). Author: Author: (1) Felix Härer[0000 −0002 −2768 −2342], Digitalization and Information Systems Group, University of Fribourg, Switzerland (felix.haerer@unifr.ch). This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. available on arxiv available on arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Too Long; Didn't Read

CTA: Download the FREE AI Productivity Shift report

What Are Open and Permissionless Blockchains?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

The Need for a Machine-actionable Rosetta Stone for (meta)data That Acts as an Interlingua

Understanding the Paxos Consensus Algorithm Part III: Raft’s Answer to Crashes, Partitions, & Delays

Understanding the Paxos Consensus Algorithm Part II: Handling Crashes, Partitions, and Lost Messages

Understanding the Paxos Consensus Algorithm - Part I: How Distributed Systems Reach Consensus

The HackerNoon Newsletter: Wikipedia Rules Everything Around Me (8/28/2025)

The Need for a Machine-actionable Rosetta Stone for (meta)data That Acts as an Interlingua

Understanding the Paxos Consensus Algorithm Part III: Raft’s Answer to Crashes, Partitions, & Delays

Understanding the Paxos Consensus Algorithm Part II: Handling Crashes, Partitions, and Lost Messages

Understanding the Paxos Consensus Algorithm - Part I: How Distributed Systems Reach Consensus

The HackerNoon Newsletter: Wikipedia Rules Everything Around Me (8/28/2025)

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps