1.2 Introduction

Current public blockchains (such as Ethereum and Filecoin) were launched as maximally decentralized, but quickly became re-centralized around elements that solved user pain points. The most prominent centralization success has been centralized exchanges, although the exponential adoption of decentralized exchanges renders that this centralized feature of public blockchain systems (centralized exchanges) will soon become decentralized [4].Thus, after exchanges, we turn towards what will now become the largest, most mission-critical, yet still centralized feature of the public blockchain design space: the database layer, herein also referred to as the query layer. The query layer is mission-critical for all decentralized applications.

Figure 1.2.1: Current Decentralized Application Architecture.

End-user client applications typically interact with a public blockchain through the following process: a transaction is signed by the user’s private key [5] via a client-side light client [6] and subsequently propagated by a full node, whose uptime is promised by the application itself or a third-party service provider, to additional full nodes, including validators of the public blockchain, who then compute the result of that transaction and package both the transaction and its results into their ensuing block, should the fee paid to the validator incentivize them to choose that transaction over additional transactions. The process of sending a transaction is herein referred to as writing to the blockchain. The most significant barrier of writing to the blockchain is the optimization of the transaction fee paid to the network [7], as variant fees for transaction inclusion exist for frequently used blockchains, which manifests itself in either failed transactions [8] or over-paid transactions [9], both of which perpetuate the poor user experiences that public blockchains are known for.

Across all public blockchain virtual machines of mainstream usage, writing to the blockchain generates events and logs [10] that exist as a result of transactions and the interactions with smart contracts; events and logs serve the primary purpose of the generation of return values for decentralized application user interfaces. However, the management of events and logs and their resultant states emitted from smart contracts is a time-intensive, computationally heavy process, for which the overwhelming a majority of developers do not possess resources to execute. Smart contract and decentralized application developers are best suited optimizing for the secure execution of their contracts, as well as finding product-market fit for those products. The market for specialized index and query services has grown at an exponential pace [11], but the market leaders are centralized service providers, whose operators and shareholders are subject to the regulation of the states in which they operate. These index and query service leaders are incentivized to form monopolies to extract excess fees and profits, ultimately passing the cost to users and developers at large. Decentralized applications reliant on centralized service providers are subject to gatekeeper and platform risk that can create an unfavorable developer experience. For any consumer application, all it requires is one poor user experience for a user to never trust a product again [12]. All of a developer’s work can be destroyed overnight.

The APIS provides a protocol for the decentralization of index and query services for reading data from and writing data to the blockchain, which will include gas optimization indices to help developers and users write to the blockchain as efficiently as possible, thus ensuring a fully decentralized architecture for the decentralized web, its builders, and its users.