The process of decentralization is gradually gaining speed and now it is decentralized applications that are becoming increasingly popular. Let’s remember that the decentralized application system has several levels. The lowest level of the system is precisely the blockchain. This is followed by: the infrastructure level, the scaling level and the level of decentralized applications, of which there are more and more every day. The working scheme of this entire ecosystem is as follows: a user – blockchain – decentralized applications. Between the blockchain and decentralized applications there is a bridge or blockchain endpoint. No matter how cool the blockchain layer is, if problems arise between the application layer and the blockchain layer, then the user will have problems.
Today there are several ways to solve the infrastructure problem in order to create a bridge. Firstly, most companies use Metamask, which can connect to some endpoints. In addition, there are separate services that provide blockchain as a service, for example, Dysnix can build cloud infrastructures for blockchain projects. Another way is the desire of some companies to build their own infrastructure, either on their own equipment or on some cloud platform.
Problems and solutions
Most of the projects that are launched nowadays aim to create good applications and at the same time make the right choice of blockchain. However, despite this, problems often begin to arise in production. For example, public endpoints may begin to slow down. In other words, the problem of public endpoints not meeting stability requirements occurs quite often, and applications certainly suffer. Let us remind you that there are indicators that allow you to evaluate the quality of the endpoint. These indicators are: Uptime – stable operation time and Latency – response speed. Consequently, if during operation these indicators do not meet the requirements, the user will perceive the application as poor and not fast enough. And at very low rates the application becomes practically inoperable. The user, not knowing that the problem is in the infrastructure, becomes sured that the application itself is bad.
We cannot ignore the fact that users often try to use a self-hosted solution, considering this option more profitable and safer. You can schematically imagine what this option looks like. Let’s imagine a situation where a blockchain project – a decentralized application – has grown, and the public endpoint used no longer meets the requirements. The user inevitably faces the question of the possibility of using his own infrastructure. So, there is a certain user, there is GSLB (global server load balancing) and there are several separated blockchain nodes that are located in different regions or countries. Naturally, the further the user is from the infrastructure, the worse the Latency indicator. Therefore, GSLB is precisely needed in order to control the situation with the traffic that will come from the user and manage this traffic. If, for example, problems arise in one of the regions (overload or even failure), then some of the requests may go to another region. And such management works well if you have your own infrastructure. In such a situation, it is very convenient to use Kubernetis, which allows you to quickly scale and solve many problems that arise.
Despite the fact that GSLB makes it possible to ensure balancing between regions, redistributing traffic in the event of some kind of imbalance, this is not enough. If the frontend server that serves RPS traffic loses connection with the blockchain nodes because they are overloaded or “down,” then users will experience problems. In such situations, a Fallback service is needed. This infrastructure solution must be provided in cases where it is possible to customize the front-end of the application. In other words, if the application itself cannot connect to your endpoint, then on its side you can make a fallback to other endpoints, and this solution is the most stable.
Monitoring
Blockchain infrastructure cannot be understood using standard metrics. For example, there are indicators that DevOps engineers are used to using, but in the case of a blockchain, the indicators inside it are important – synchronization speed, number of transactions per second, number of peers. The main problems of blockchain: slow start, slow disks, slow peers. Scaling solution is an infrastructure solution to the listed problems.
The period of operation of a variety of blockchains has shown that they often behave quite unpredictably. For example, there may be a sharp growth of the blockchain, the number of users becomes many times higher than in the previous similar period. Since it is impossible to predict this using standard methods, machine learning can come to the rescue. It is with the help of machine learning that we can analyze those specific blockchain indicators mentioned above, predict the behavior of the blockchain and be prepared for unexpected surges in traffic.