How to solve the blockchain infrastructure security problem while creating a dApp

The race for WEB3 has started. Venture capitalists, cryptocurrency startups, engineers and visionaries develop WEB3 (or Web 3.0) powered by blockchain. A new frontier emerged, more democratic, decentralized, independent and ideal for data recovery.

But is everything so perfect when it comes to infrastructure decentralization and security? No, and many cases of man-in-the-middle attacks are proof of that.

But to solve the security problem, let’s remember what WEB3 is. The core concept of WEB3 is to solve the security problems caused by centralization and to give people authority over their data and identification. So at what level of technology are these unfortunate incidents of security breaches occurring in your blockchain infrastructure? Let’s find out.

To focus on the internal aspects of WEB3, technologies such as EVM, Solidity and JavaScript still play a huge role. However, we use Node providers and WEB3 API providers when discussing backend functions.

Node providers are companies that allow you to use their services instead of running your nodes. This is very convenient because instead of setting up your node and experiencing all the stress and expense that comes with it, you can send your dApp transaction requests over the Internet to the node provider. If you are interested in smart contract development, you can use one or two node providers (for redundancy).

There are many WEB3 API providers; on the other hand, in many cases these companies work with nodes behind the scenes. With these tools used, you can get all precompiled and precalculated data on the chain.

Moreover, it is easy to establish reliable communication and interaction between different applications through these WEB3 APIs. In addition, quality APIs keep coding consistent and stable. We therefore rely mostly on reliable WEB3 APIs when creating applications.

💡 The difference between node providers and WEB3 API providers: The WEB3 provider allows your application to communicate with a blockchain node by submitting JSON-RPC requests to a server. Node service providers run distributed node clients behind the scenes and allow them to write to and read from a blockchain using an API key.

What is the security threat to dApps developers?

Nodes are still relatively primitive technologies, but they are still valuable. For example, a WEB3 node cannot tell you what users have deposited into their accounts. In addition to only providing raw blockchain information, nodes cannot process multiple smart contracts. Furthermore, nodes have limited capabilities and can only process one chain. Fortunately, there are APIs available to help you work around this limitation.

APIs define and standardize apps’ interactions so you can use raw blockchain data. This is why WEB3 APIs are useful for dApp development. WEB3 APIs are a key component in the development of dApps; in addition to providing a simple interface, they allow a piece of software to interact with other applications. Because reliable APIs allow consistent coding in a stable environment, dApp developers don’t have to reinvent the wheel.

Furthermore, using these WEB3 provider APIs, you can easily connect to nodes. Therefore, you don’t need to worry about connecting to nodes when using these APIs. When you interact with these providers, you can also receive all kinds of valuable pre-calculated and pre-compiled data on the chain.

But such services do not completely close the developers’ requests in the security plans, and in most cases you have to pay in advance for their use.

The fact is that there are more and more cases of dApps being hacked using the man-in-the-middle attack we mentioned above.

This is when an attacker, using vulnerabilities in DNS servers (for example), switched servers to serve jsonrpc endpoints traffic.

One victim is known have lost 16.5 WBTC (~$350,840). And around 23 cryptocurrency projects have already faced a similar DNS attack.

A very simple solution allows you to protect yourself from such man-in-the-middle attacks. And we will return to this.

Also, if you have a development team, you can go your own way and try to build your solution, but you need a super-skilled team of like-minded people to make it work.

The difficulty with this process is that you can significantly overestimate your strength. A task that seems easy then raises many questions, which are solved by many years of experience in one’s work. Therefore, if you have a lot of time and resources, you should accept this path.

Violation of 3 main blockchain principles in WEB3

So let’s take a breath now and look at current security challenges in the WEB3 world from an infrastructure perspective.

The main principles of blockchain are

• decentralization
• openness
• distrust

But does it work in practice? Take a look at most popular dApp architecture.

We can see that users on the interface send requests to JSON-RPC providers (this could be Infura, Alchemy, Quicknode, etc.).

So the requests are routed to a shared environment where we have no control over the data transformation at the API port, cache engine, blockchain nodes or anything else.

And this is where the first problem arises because a shared environment means that many users, bots and hackers, in particular, work in the same environment. This is a real black box for the developer that attracts too much attention from attackers.

Well, this approach contradicts all three principles of WEB3 because:

1. It centralizes access to the Blockchain, sending everything through a shared environment;
2. It is not transparent – ​​we cannot verify responses from such an API;
3. Therefore, it cannot be called true mistrust since the security issues of such an infrastructure are only based on trust. See for yourself in the following diagram.

The second problem is that the described infrastructure version allows for man-in-the-middle attackswhich criminals use periodically.

The following services can be attacked:

• • Domain or DNS registrars
  • JSON-RPC providers
  • All Third Party Aggregated Services

A self-hosted cluster of blockchain nodes is the only solution

But is there a solution? Yes — configured local environment.

First, it uses a self-hosted cluster of blockchain nodes. All nodes are initialized from official genesis and synchronized using p2p. This ensures data consistency.

Nodes should be refreshed periodically with reduced snapshots to run as efficiently as possible. The ideal solution is to automatically create new nodes from the reduced snapshot when you zoom. If you initialize the node from scratch, this approach allows you to get a new node within 30 minutes instead of several days.

Another critical point is the automatic update of the blockchain software after its release – this can also be done. The most important thing is to create a snapshot with the new version (which sometimes may require some computing operations, which can take time), and then the new nodes should start automatically with the new snapshot and updated software.

Below is an infrastructure diagram that solves most of the problems described.

It is also important to monitor the synchronization state and exclude those nodes that are behind the upstream flow. This can, for example, be done with the help of health checks.

In addition to the fact that access can be restricted by IP address, it is worth mentioning that the good old JWT token can protect against domain registrar or DNS attacks. The JWT token is easily integrated into web3js and other libraries and should be implemented on the API gateway side of our blockchain cluster.

In this way, we make the blockchain endpoint secure and decentralized.

Summary

Web3 is still in its early stages. But the race for decentralization is already underway. And you’ll be able to see that the most secure applications are likely to be those that use the most innovative and open source approaches.

And therefore you should not ignore the basic principles of WEB3, because then your newly created dApp will not provide security to other participants. The only option currently available is an autonomous cluster of geo-distributed blockchain nodes.

Author:

Daniel Yavorovych

Co-founder and CTO at RPCFast and Dysnix