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

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

But is everything so perfect regarding decentralization and security of infrastructures? No, and numerous cases of man-in-the-middle attacks are proof of that.

But to solve the security issue, let’s remember what WEB3 is. The core concept of WEB3 is to solve the security problems caused by centralization and to provide people with 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 figure it out.

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

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’re interested in smart contract development, you may use one or two node providers (for redundancy).

There are many WEB3 API providers; however, in many instances, these companies work with nodes behind the scenes. With these tools applied, you can get any pre-compiled and pre-computed data on the chain.

Moreover, it is simple 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 on trustworthy WEB3 APIs the most when creating applications.

💡 Difference between Node providers and WEB3 API providers: 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 let them write to and read from a blockchain using an API key.

What is the security threat for 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 in their accounts. Besides simply 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 circumvent this limitation.

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

Furthermore, by using these WEB3 provider APIs, you can easily link to nodes. Therefore, you do not have to worry about connecting to nodes when using these APIs. When interacting with these providers, you may also receive all sorts of valuable precalculated and precompiled on-chain data.

But such services do not entirely close 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 to have lost 16.5 WBTC (~$350,840). And about 23 cryptocurrency projects have already encountered 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 of 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 the WEB3

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

The main principles of blockchain are

• decentralization
• transparency
• trustlessness

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

We can see that users on the front end are sending 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 gateway, caching 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 3 principles of WEB3 because:

1. It centralizes access to the Blockchain, passing 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 based simply on trust. See for yourself in the following diagram.

The second issue is that the described infrastructure version allows for man-in-the-middle attacks, which criminals periodically use.

The following services can be attacked:

• • Domain or DNS registrars
  • JSON-RPC providers
  • Any third-party aggregated services

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

But is there a solution? Yes — configured on-prem 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 updated periodically with reduced snapshots to run as efficiently as possible. The ideal solution is automatically creating new nodes from the reduced snapshot when zooming. 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 main thing is to create a snapshot with the new version (as sometimes it may require some data 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 described problems.

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

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

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

Summing up

Web3 is still in its early stages. But the race for decentralization is already on. And you will be able to see that the most secure applications are likely to be the ones 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 & CTO at RPCFast and Dysnix