Technical Articles | What are the bottlenecks and thresholds for developing Dapps on Ethereum?

Source | CSDN Blog

Editor-in-Chief | Carol

Production | Blockchain Camp (blockchain_camp)

Decentralized applications (Dapps) are widely considered to bring disruptive innovation to areas such as banking (Di-Fi) and gaming. However, even the most innovative solutions will not be recognized if they fail to meet consumer expectations.

• Coinbase CEO: the next decade of cryptocurrencies
• From Web2.0 to Web3.0: Is Web3.0 a wake-up call or an alarmist?
• Compared with the original chain of the original chain in 2020, MOV, more than the original, Bystack, more than the original

Consumers need a smooth and mature user experience, and achieving this goal is another major challenge for Dapp developers on Ethereum.

This article will outline a typical Dapp architecture and point out some of the inherent limitations of today's standard Ethereum stack, and it is these limitations that make it difficult for developers to create compelling user experiences. Then I will introduce some innovations in the field of Ethereum infrastructure that can help developers overcome these challenges.

Classic Ethereum Dapp Architecture

Generally speaking, Dapp on Ethereum contains three main parts:

• Smart contracts, usually written in Solidity, are built using frameworks such as the Truffle Suite and deployed on the Ethereum blockchain.
• Front-end code, written in Java.
• Back-end-typically using standard Ethereum blockchain nodes. The front-end and back-end communication usually uses the JSON-RPC or GraphQL API provided by the node.

There are also various libraries that facilitate communication between the front end and Eth nodes, the most popular of which are web3.js and ethers.js. There are also many web3 libraries for other languages ​​(Java, Python, Rust …).

Self-built backend nodes

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

Node Service (NaaS) provider

This challenge mentioned above has led to the rise of "node service" platforms for companies such as Infura and the relatively new companies such as Nodesmith, Quiknode, Blockdaemon, Ethernode, Chainstack, Alchemy, CloudFlare, and others.

These platforms provide developers with cloud-based Ethereum nodes, which saves developers the energy of operating nodes. Solutions for development and production. These platforms allow developers to share the system management of the underlying operating system and the node software itself, such as patches and updates.

Inherent limitations of Ethereum nodes

Even if the node service can successfully replace the developer's role as a system administrator, it cannot help the developer to realize the user experience to build a better Dapp. This is because the architecture from the node service and the JSON-RPC and The inherent limitations of the GraphQL interface.

The main limitations include:

1.The observed state information is inconsistent

In order to expand to the capacity of a single node while providing higher reliability, the nodes as a service platform provide access to the node pool through a load balancer.

Since these nodes all operate autonomously as peer nodes in the Ethereum network, when the 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 status of the blockchain, because the results obtained by its requests are provided by different nodes behind the load balancer.

The node service platform usually tries to solve this problem through session stickiness on the load balancer. It always tries to send the query of the specified front end to the same back end node, but this method will fail in many cases:

• When the front end generates more requests than a single backend node can handle;
• When a network problem causes the front end to be disconnected from the back end, and must be reconnected;
• Multiple node service platforms route different types of front-end requests (for example, sending transactions or search chain history) to different groups of back-end nodes optimized for that query type.

Then, because the front end often visits multiple back-end nodes, and the blockchain states obtained by these back-end nodes are not consistent with each other, it is difficult for Dapp to handle chain reorganization. When tracing back the chain history, the Dapp may suddenly find that the parent block it wants to find 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 can lead to discrepancies in the information presented to the user.

2.Searching for information on the blockchain is slow and limited

Dapp's ability to search for transactions or on-chain history is limited because standard Ethereum nodes are not suitable to support accurate search or perform filtered monitoring of real-time data. To operate in a high-performance way, we need to index a large number of millions of blocks and transactions, but:

• Ethereum nodes only index certain fields in the log issued by the transaction execution (the fields to be indexed must be marked by the developer when the contract is deployed)
• Ethereum nodes do not index data for internal transactions (which occurs when a smart contract calls a method of another contract)
• Developers are unwilling to add additional index fields, because the cost of each additional index field per transaction will increase relatively, which will bring additional costs to the contract user
• Ethereum nodes use Bloom filters to perform searches, 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 exact match result. This not only requires the energy of the developer, but also wastes the bandwidth between the front end and the nodes
• The search syntax available is very limited-only basic selections and simple substitutions are supported
• Fetching search results is slow-performing a search in a large range of blocks can take several hours
• JSON-RPC is a waste of bandwidth-the data returned is far more than you really need. The GraphQL interface uses less bandwidth, but does not provide streaming capabilities (the front end must be polled for updates)

3. Lack of atomicity

In most modern environments, such as relational databases, transactions are generally atomic, but not on Ethereum (or other blockchains). Each transaction goes through a series of state transitions, and in the process may encounter multiple problems or failures. Dapps must call multiple APIs and query many different data sources (blocks, mempool, network status) in order to track the life cycle of a transaction until it is completed.

Again, this burden falls on the front-end code, figuring out exactly what is happening through repeated polling, and Dapp users will experience delays and need refreshes as the Dapp performs all of this extra work.

Nodes are passive

Ethereum nodes are passive, which means they cannot generate events or callbacks and call Webhooks. All operations must be initiated by the front end, and the front end must also poll the nodes for updated information. The event stream read function of the Ethereum node is too limited to meet the needs of most Dapps, and is only available in the JSON-RPC interface and not available on the GraphQL interface.

Rethinking the Dapp infrastructure

dfuse provides a higher level blockchain API platform. Compared with the native API provided by blockchain nodes, they can more easily complete more tasks. It is designed to give Dapp developers the functionality they need to build modern blockchain applications through a fast and smooth interface, thereby providing an excellent user experience.

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

1.Consistent views

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 you see a block (while detecting a fork and reorganization of the chain), or you don't report the block at all (in the case that the block undergoes rapid reorganization and spreads not far).

In this way, Dapp will never face an inconsistent view of the chain state, and can focus on its main functions, rather than busy verifying the details of the blockchain.

2.High-speed, fine-grained search

Enables Dapp developers to search the history of the blockchain with extremely fine granularity, extraordinary speed and efficiency, as well as real-time screening and streaming reading through GraphQL, gRPC and Websocket interfaces.

• Fully index all Log fields-All data sent in the log by each transaction is directly applicable to high-precision search.
• Fully index all internal transactions (sender, receiver, value, method, input parameters) to fully track contract operations throughout the tree structure of the call
• Indexing will not bring any additional gas costs to your users-dfuse indexing is an integrated feature of the dfuse platform and will not increase the cost of resources for contract execution
• The search finds exact matches, not fuzzy results. No need to write additional front-end code to repeatedly check search results, and no waste of bandwidth to get unwanted data in batches
• Provides a structured query language, similar to the query language of Kibana or GitHub, with full boolean operations and the ability to dive directly into the specific transaction or command you are looking for
• Provides excellent performance-you can search the entire chain history in less than a second, according to the specified search criteria, to find a set of exact matches
• GraphQL provides a concise response without sacrificing streaming capabilities. The best of both worlds-our GraphQL interface provides a complete real-time filtered search that effectively provides users with dynamic updates
• Consistent performance regardless of traffic on the Ethereum network

Atomic operations

Provides a streaming read endpoint that understands all the complex states a transaction may enter and notifies you when it meets finality. There is no need to laboriously track the status of transactions by repeatedly polling or checking multiple data sources. You only need to push transactions up and stay connected to receive real-time status updates, which can also provide your users with real-time status of transactions.

4.Proactive back end

A good platform will provide you with an active backend that can launch events. For example, you can call your chosen lambda function (or cloud function) according to the exact criteria you specified (through the search and other functions described above). This allows the Dapp to implement an asynchronous architecture, and data updates can be released to users smoothly and in real time through multiple communication channels.

5.A modern platform for cutting-edge Dapps

dfuse provides a modern infrastructure layer for your Dapp, namely:

• fast
• Scalable
• Provides high-precision, fine-grained, real-time access to blockchain events
• Supports active Webhook callbacks
• Supports atomic operations
• Highest reliability in the industry

Therefore, when encountering the above problems when developing Dapp on Ethereum, you can try to solve the problem with different tools. Only after going through product grinding and user training can more more sophisticated, practical and mature Dapps be released.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!