Unveiling: The Main Pillars of Cryptographic Infrastructure

Introduction:
With the rapid emergence of cross-chain bridges, new testing frameworks, and other cryptographic protocols, effectively planning blockchain infrastructure remains a major challenge for users, developers, and investors. The term “blockchain infrastructure” can encompass a variety of products and services ranging from the underlying network stack to consensus models or virtual machines. In this article, we aim to:

1. Provide an overview of additional key components of blockchain infrastructure.
2. Break down these components into clear and understandable sub-parts.

Infrastructure Map:
We define the “ecosystem” of blockchain infrastructure as protocols designed to support the development of L1 and L2 in the following key areas:

1. Layer 0 infrastructure: (1) Decentralized cloud services (storage, computation, indexing); (2) Node infrastructure (RPC, staking/validators)
2. Middleware: (1) Data availability; (2) Communication/message delivery protocols
3. Development: (1) Security and testing; (2) Development tools (out-of-the-box tools, front-end/back-end libraries, language//IDE)

Layer 0 Infrastructure:
Decentralized Cloud Services:
Cloud services have been crucial to the development of Web2 – as the computational and data demands of applications grow, service providers dedicated to delivering these data and computations in a cost-effective manner become essential. Web3 applications have similar data and computational needs but wish to adhere to the spirit of blockchain. Thus, protocols that aim to create decentralized versions of these Web2 services have emerged. Decentralized cloud services have three core components:

1. Storage – Data/files are stored on servers run by multiple entities. These networks can achieve high fault tolerance as the data is replicated or sharded across multiple machines.
2. Computation – Like storage, computation is centralized in the Web2 paradigm. Decentralized computation aims to distribute computation across multiple nodes to achieve a higher degree of fault tolerance (if one or a group of nodes fail, the network can still process requests with minimal impact on performance).
3. Indexing – In the Web2 world, data is already stored on one or a group of servers owned and operated by a single entity, making it relatively easy to query this data. Because blockchain nodes are distributed, data can be isolated and scattered in different areas, often in incompatible standards. Indexing protocols aggregate this data and provide easy-to-use and standardized APIs to access it.

Several projects offer storage, computation, and indexing (Aleph and Akash networks), while others are more specialized (e.g., The Graph for indexing, Arweave/ Filecoin for storage).

Node Infrastructure:
1. Remote Procedure Call (RPC) is central to the functionality of many types of software systems. They allow one program to call or access another program on a different computer. This is particularly useful for blockchains, as they must serve a large number of incoming requests from various machines running in different regions and environments. Protocols like Alchemy, Syndica, and Infura provide this infrastructure-as-a-service, allowing builders to focus on high-level application development rather than the underlying mechanisms involved in relaying or routing their calls to nodes. Like many RPC providers, Alchemy owns and operates all nodes. The dangers of centralized RPC are apparent to many in the crypto community – it introduces a single point of failure that could jeopardize the liveness of the blockchain (e.g., if Alchemy goes down, applications will not be able to retrieve or access on-chain data). Recently, the rise of decentralized RPC protocols like Pocket has addressed these issues, but the effectiveness of this approach still needs to be tested at scale.
2. Staking/Validators – The security of blockchains relies on a group of distributed nodes to validate transactions on the chain, but someone must actually run the nodes that participate in consensus. In many cases, the time, cost, and energy required to run a node are so expensive that many people choose to opt-out and rely on other nodes to take responsibility for ensuring the security of the chain; however, this behavior poses serious problems – if everyone decides to push security onto others, no one will perform validation. Services like P2P and Blockdaemon run infrastructure that allows less mature or less well-funded users to typically participate in consensus by raising funds. Some argue that these staking providers introduce an unnecessary degree of centralization, but the alternative may be worse – without these providers, the barrier to entry for running nodes would be too high for the average network participant, potentially leading to higher centralization.

Middleware:
Data Availability:
Applications consume a large amount of data. In the Web2 paradigm, this data is usually provided in a centralized manner, either directly from users or third-party providers (data providers are paid directly by aggregating data and selling it to specific companies and applications, such as Amazon, Google, or other machine learning data providers).

DApps are also heavy consumers of data, but they require nodes to provide this data to users or applications running on the chain. To minimize trust assumptions, this data must be provided in a decentralized