EthQL: Transform How You Interact with the Ethereum Blockchain

ICYMI, last week 1200 developers came together in San Francisco for the 2019 GraphQL summit: a global event dedicated to innovations in GraphQL and best in-class implementations. Among Web2 giants like Microsoft, AirBnB, Paypal and globally recognized media brands like the New York Times, one voice represented Web3: Infura Developer Tools Architect, Kris Shinn.

Shinn delivered an insightful talk on how Infura is trying to transform the way it interacts with Ethereum data through its contribution to EthQL. Shorthand for “Ethereum plus GraphQL,” EthQL is a collaborative project that aims to advance a GraphQL schema and standardize it for the Ethereum blockchain.

This post recaps Shinn’s talk. It establishes the data problem posed by Web3 and Ethereum, proposes how GraphQL can solve these problems and demonstrates ways to experiment with EthQL now to start pulling more meaningful data off the blockchain.

First, let’s establish some context to set up the problem. What is ‘Web3’? And What is ‘Ethereum’?

If you’re reading this post, you’re probably familiar with traditional web architecture. A server sends a data request on behalf of clients and then disseminates that data to the clients as they need it. That way the server can have protected credentials for premium APIs and you have a single source of requests to your external APIs.

But this architecture is aging. Modern applications and billion dollar industries are built on architecture that is nearly 30 years old. We’ve progressively integrated more services through APIs, trusting our data to a shrinking number of tech giants who have now become responsible for protecting and respecting the world’s data.

For better or worse, traditional web architecture is a system built on trust; trust that our apps are talking to the right authorities, that the data is secure, that the data is correct and has not been altered.

Enter ‘Web3’: a truly decentralized web built with security at the center. In Web3 architecture, applications are networked peer-to-peer rather than connected to a single centralized server. As a result, clients each make individual requests to external APIs containing data needed by the client. This network is built around ‘verification’, rather than ‘trust’ and because it does not possess a single centralized infrastructure, it’s more robust. It’s difficult to hack and less vulnerable to DOS. That means an increased resistance to network downtime, fraud and third party interference.

Web3 is a new decentralized web made for the next generation of networked applications. Any blockchain-based application is built on a Web3 platform. While the tech is still emergent, many industries have spent the last few years prototyping blockchain-based applications. Decentralized finance (DeFi) is the most popular current use case, but every sub vertical — from enterprise efficiency to real estate — has at least one prototyped blockchain application.

Ethereum: a Web3 Platform with Programmable Tokens

When you think of ‘Ethereum,’ you probably think about cryptocurrency. The most famous implementations of early blockchain technology were the creation of cryptocurrencies like Bitcoin, Ethereum and Litecoin. But Ethereum is more than a cryptocurrency. It’s an open peer-to-peer platform that allows developers to build decentralized applications. Enabling those applications to issue programmable tokens is simply a feature of the platform.

The platform is connected to a global network of thousands of nodes. Programs written to execute on Ethereum are called Smart Contracts and they allow you to transfer value, save data or execute bits of logic that interact with the blockchain.

Infura’s Place in the Ethereum Ecosystem

Infura is a Web3 infrastructure company with a mission to provide developers with the best tools and infrastructure to build and run applications on the decentralized web. Founded in 2016, we were one of the earliest entrants into Web3. As Ethereum already had a strong reputation and a thriving community, we decided to start there. Today, providing fast on ramps to the Ethereum and Interplanetary File System (IPFS) networks through easy-to-use APIs is our core business. Our products allow developers to interact with the Ethereum blockchain without having to spin-up and maintain their own infrastructure. By using Infura, developers save time, money and resources. They can connect instantly to Web3 and focus on building killer software on top of it.

To optimize their applications, developers need to be able to read Ethereum data. This is currently made possible primarily by using a lightweight open source protocol called JSON RPC 2.0.

The Problem With JSON RPC

There are two layers of network protocol needed to make all of this work: the underlying peer-to-peer layer and the external operational layer.

The peer-to-peer layer (P2P) is focussed on keeping data in sync and takes care of the consensus mechanisms. The “operational” layer is designed for applications to interact with the node: send transactions, query data, and interface with administrative functions. JSON-RPC 2.0 is the protocol used in that operational layer. It’s built to scale over a number of transports (HTTP, Websockets, and IPC) and provides a simple interface for interacting with a network node. As this protocol was never built specifically to query a node, using it to send data requests produces a number of problems:

1. There’s no native typing. Implementing return data in JSON could be different per implementation;
2. There are defined calls and data returns, but there is nothing that natively indicates the relationship between the data;
3. Data selection is not supported;
4. It routinely over-fetches and under-fetches data. Over-fetching means that an API call returns data that the application is not interested in and this can impact how efficiently the client puts together the response. Under-fetching means that an application may need to make multiple or dependent calls in order to fetch the data it needs. Both cases can result in returning way more data than is useful or necessary for each query, creating a big efficiency problem.
5. Raw output is returned to the user in a serialized encoding that was designed for efficient storage and transport. Developers need to encode data before querying and then decode the response to get useful data out.

In a world where we are trying to optimize for mobile and reduce the amount of network congestion to produce snappy and efficient apps, the difficulty in getting data off the blockchain efficiently makes writing efficient Web3 apps complex. In the absence of a proper query layer, JSON-RPC continues to be the most widely adopted API in Ethereum today. Developers compensate for the lack of standards with client libraries that abstract away all of the different variants of implementation.

GraphQL: A Better Way to Query the Blockchain

To improve and simplify the user experience for developers, we need a strongly typed, standardized way to both interact with and query data from the blockchain. Using GraphQL as an alternative interface to JSON RPC can solve a number of key problems:

1. Standardize the return type by providing a strongly typed schema that could have standard implementations;
2. Offer an explicit and consistent way to model the data on the blockchain;
3. Increase efficiency by eliminating over-fetching and under-fetching;
4. Easily extend and layer on additional functionality, while retaining the core API.

Specific, Accurate and Efficient

Ethereum data is comprised of five key components. Below, we outline the definition of three such components and compare the return from JSON RPC and GraphQL for the related request.

Blocks

Blocks are a top-level data structure. All data is organized into blocks and provide a point-in-time reference for Logs and Transactions.

• Query: “Get the latest block”
• Return:

Transactions

The “action” for blockchain. Transactions create Logs (or Events), transfer value between accounts (even 0 value) and is the primary Calls method on Contracts (accounts).

• Query: “Get the latest block with transactions”
• Return:

Logs (or Events)

A log is simply an event that occurs. They’re used for record keeping on the network and return values for the UI.

• Query: “Get logs from a transaction”
• Return:

Each example demonstrates how much more specific and efficient the return is when using GraphQL is used to request data. More importantly…

…the data is decoded!

Want fast access to the Ethereum and IPFS networks? Head to Infura.io and sign up to our Core service to start playing around for free.

Need more request volume and direct support? Check out Infura+ to pick the right plan for your project.