What are the bottlenecks and barriers to developing Dapps on Ethereum?

区块链大本营

特邀专栏作者

2020-01-07 09:00 (UTC+8)

This article is about 3710 words, reading the full article takes about 6 minutes

What are the unavoidable problems in developing Dapp on Ethereum?

AI Summary

Expand

What are the unavoidable problems in developing Dapp on Ethereum?

Editor's Note: This article comes fromBlockchain Camp (ID: blockchain_camp)Editor's Note: This article comes from

Blockchain Camp (ID: blockchain_camp)

Decentralized applications (Dapps) are widely regarded as disruptive innovations in areas such as banking (Di-Fi) and gaming. But even the most innovative solutions won't be recognized if they don't meet consumer expectations.

What consumers want is a smooth and mature user experience, and achieving this goal is another major challenge for Ethereum Dapp developers.

This article provides an overview of a typical Dapp architecture and points out some of the inherent limitations of today's standard Ethereum stack that make it difficult for developers to create a convincing user experience. Then I will introduce some innovations in the field of Ethereum infrastructure that can help developers overcome these challenges.

secondary title
Classic Ethereum Dapp Architecture
In general, a Dapp on Ethereum consists of three main parts:

Front-end code, written in Java.

Backend - typically a standard Ethereum blockchain node. The communication between the front end and the back end generally uses the JSON-RPC or GraphQL API provided by the node.

secondary title

Self-built backend node

In the early days of Ethereum, developers had to operate their own Ethereum nodes. After the Dapp is released, they must also operate production-grade nodes (or clusters of nodes). Operating a blockchain node is a heavy workload and will also burden the efficiency of developers.

Node as a Service (NaaS) Provider

This aforementioned challenge has led to the rise of "node-as-a-service" platforms from companies such as Infura, and relatively newer companies like Nodesmith, Quiknode, Blockdaemon, Ethernode, Chainstack, Alchemy, CloudFlare, and others.

These platforms provide developers with cloud-based Ethereum nodes, saving developers the effort of operating nodes. Solutions for development and production. These platforms offload system management, such as patches and updates, for the base operating system and the node software itself to developers.

secondary title

Inherent Limitations of Ethereum Nodes

Even if the node service can successfully replace the developer as a system administrator, it cannot help developers achieve a better user experience to build a better Dapp, because the architecture from the node service and the JSON-RPC and Inherent limitations of GraphQL interfaces.

Major limitations include:

1. The observed state information is inconsistent

In order to scale beyond the capacity of a single node while providing higher reliability, nodes as service platforms provide access to node pools through load balancers.
Since these nodes are all operating autonomously as peer nodes in the Ethereum network, when information is transmitted through the network at a certain moment, different nodes may be at different block heights, or even at different forks . This means that the Dapp may receive inconsistent information about the state of the blockchain, because the results of its requests are served by different nodes behind the load balancer.
Node service platforms usually try to solve this problem through session stickiness on the load balancer, which will always try to send the query of the specified frontend to the same backend node, but this method will fail in several situations:

When the front-end generates more requests than a single back-end node can handle;

When a network problem causes the frontend to disconnect from the backend and must reconnect;

Multiple node serving platforms will route different types of frontend requests (for example, sending transactions or searching chain history) to different sets of backend nodes optimized for that query type.

Then it is difficult for Dapp to handle chain reorganization because the front-end often accesses multiple back-end nodes, and the blockchain states obtained by these back-end nodes are inconsistent with each other. When tracing the chain history backwards, a Dapp may suddenly find that the parent block it was looking for no longer exists (because it is now interacting with another node on a different fork). Then Dapp developers have to write code to solve this problem (usually by repeatedly reconnecting until it finds a node). This adds unnecessary complexity to the Dapp and may result in discrepancies in the information presented to the user.
2. Searching for information on the blockchain is slow and limited
Dapps are limited in their ability to search transactions or on-chain history, as standard Ethereum nodes are not well suited to support precise searches or perform filtered listening of real-time data. To do this in a performant way, we need to do a lot of indexing of millions of blocks and transactions, but:
Ethereum nodes only index certain fields in the log sent by transaction execution (the fields to be indexed must be marked by the developer when deploying the contract)
Ethereum nodes do not index data for internal transactions (which happen when a smart contract calls a method of another contract)
Developers are reluctant to add additional index fields, because the cost of each transaction will increase for each additional index field, which will bring additional costs to contract users
Ethereum nodes perform searches using Bloom filters, so it is always a fuzzy search and will produce false positive matches. Exact matching requires additional processing by the front-end. The front-end must obtain the entire block or transaction of the fuzzy match, and retrieve it again to find the result of an exact match. Not only does this require developer effort, but it also wastes bandwidth between the frontend and the nodes

The available search syntax is very limited - only basic selections and simple substitutions are supported

Fetching search results is slow - performing searches across large blocks can take hours

JSON-RPC is a huge waste of bandwidth - returning far more data than you really need. The GraphQL interface uses less bandwidth, but does not provide streaming capabilities (the frontend must poll for updates)

3. Lack of atomicity

Again, the burden falls on the front-end code to repeatedly poll to figure out exactly what happened, while users of the Dapp experience delays and the need to refresh as the Dapp performs all this extra work.

4. The node is passive

Ethereum nodes are passive, meaning they cannot generate events or callbacks and invoke webhooks. All operations must be initiated by the frontend, which in turn must poll the nodes for updated information. The event stream reading capabilities of Ethereum nodes are too limited to meet the needs of most Dapps, and are only available in JSON-RPC interfaces, not GraphQL interfaces.

secondary title

Rethinking Dapp Infrastructure

What dfuse provides is a platform for higher-level blockchain APIs that allow them to do more work more easily than native APIs provided by blockchain nodes. It is designed on the basis of giving Dapp developers the functions they need to build modern blockchain applications through a fast and smooth interface, thereby providing an excellent user experience.

It is hoped that through the platform, all the above-mentioned limitations can be solved, and the limitations of traditional Ethereum nodes can be broken.

1. A consistent view

dfuse is an integrated hyperscale data platform, not a collection of multiple Ethereum nodes on a load balancer. The dfuse platform provides chain state information on all connections and at all points in time. Either see a block (detecting both a chain fork and reorganization), or not report the block at all (in the case of a block undergoing a rapid reorganization and not traveling far).

This way the Dapp never faces an inconsistent view of the chain state, and can focus on its main function instead of busy verifying the details of the blockchain.
2. High-speed, fine-grained search
It enables Dapp developers to search the historical records of the blockchain with extremely fine granularity, extraordinary speed and efficiency. It can also realize real-time filtering and streaming reading through GraphQL, gRPC and Websocket interfaces.
Fully index all Log fields - all data emitted by each transaction in the Log is directly applicable to high-precision search.
Full indexing of all internal transactions (sender, receiver, value, method, input parameters), thus fully tracking the operation of the contract in the tree structure of the entire call
Indexing does not incur any additional gas costs for your users - dfuse's indexing is an integrated feature of the dfuse platform and does not increase the resource cost of contract execution
The search finds exact matches, not fuzzy searches. No need to write additional front-end code to double-check search results, and no need to waste bandwidth to fetch unnecessary data in batches
Provides a structured query language, similar to Kibana or GitHub's query language, with complete boolean operations and the ability to drill down directly to the specific transaction or command you want

Provides excellent performance - in less than a second, according to the specified search criteria, search the entire chain history to find a set of exact matches

The best of both worlds with GraphQL providing concise responses without sacrificing streaming capabilities - our GraphQL interface provides full real-time filtered search to efficiently serve dynamic updates to users

Performance is consistent regardless of traffic on the Ethereum network

3. Atomic operations

Provides a stream read endpoint that understands all the complex states a transaction may enter and notifies you when it meets finality. Instead of wading through repeated polls or checking multiple data sources to track the status of transactions, you can simply push transactions up and stay connected to receive real-time status updates, thereby also providing real-time status of transactions to your users.

A good platform will give you an active backend that can initiate events. For example, a lambda function (or cloud function) of your choice can be invoked based on precise criteria you specify (via the aforementioned search and other features). This allows Dapps to implement an asynchronous architecture where data updates can be released to users smoothly and in real-time through multiple communication channels.