.avif)
Specific tasks demand specific solutions. That’s what typically blockchain projects are looking for when they contact us. This case is a brilliant example of the evolution of a client’s request during the research phase and the teams’ cooperation in facing complex challenges.
Within this article, you’ll find out how Dysnix works over the client’s tasks from the agreement to the support stages and what expected and additional benefits we generate for our customers.
Nansen.ai is a blockchain analytics platform that helps traders and blockchain projects by highlighting and informing them of the essential changes and trends happening in the blockchain (especially in crypto). They handle processing the petabytes of trading data circulating in their systems daily to provide the most valuable insights to their customers 24/7.
The requirements of Nansen while searching for solution providers were extremely high because of the tech-savviness of the company itself. They selected Dysnix because of the expertise that can significantly complement their internal team, ease of knowledge sharing, and inventive approach to technical problem-solving.
As a sign of a promising project, Nansen contacted us with a primary objective that sounded more like, “We think that we need this and that. What do you think about it?” After a brief talk over the topic, both sides understood that Dysnix could dive even deeper into the problem and solve it in the most optimized way.
So everyone got excited about the future communication and technical miracles to be manifested.
It took only two calls to establish all the connections between companies and agree upon the key points of cooperation. The COVID pandemic showed us how any topics and challenges could be discussed and successfully solved, no matter how far your colleagues are. So we didn’t waste too much time before the development.
From Dysnix’s side, we hand-picked two engineers, Cloud Architect and Senior DevOps Engineer, with blockchain experience. From Nansen’s side, they prepared the full scope of requirements and only a few assigned specialists to communicate with our team. Our client delegated 100% of the work to us and relied on us completely.
Dysnix was ready to dive in.
In the latest statement, Nansen.ai hired Dysnix to develop, implement, and support a reliable, autonomic, and secure infrastructure for the specific needs of the blockchain analytics platform. A high level of security was an essential point of the request.
Nansen needed a fail-safe and highly secure deployment for the Ronin blockchain validator node with secure private key storage.
The Ronin validator node Nansen planned to get couldn’t match their needs. It was a typical validator node that was tightly connected to the whole network and didn’t have all characteristics needed. The task of Dysnix was to implement such a blockchain environment that would add new features to the Ronin validator without any changes to the functionality of the node itself.
The Dysnix team planned a solution that will look like this:
Before we get into a closer review of the solution Dysnix engineers offered, let’s look at the top level of settled requirements.
The solution meets the following expectations and requirements of the client:
But we offered to go even further and add other improvements from the start:
Our offer is based on the high standards of work of Dysnix engineers and their dedication to the projects. As you can imagine, Nansen could hardly disagree with the offer we prepared for them.
After agreement upon the first part of the cooperation, Dysnix created a high-level SoW with a helicopter view of goals and future cooperation achievements. During the R&D phase and after 2-3 clarification sessions, where Nansen revealed more facts about the team Dysnix will work with and other details, our engineers made the final decision according to the architecture and in-depth detailed SoW.
With this version of SoW, Dysnix described low-level tasks in their tracking system and prioritized them into the roadmap. Engineers estimated the whole development process for 100-120 working hours. It perfectly fit the needs of Nansen.
Also, we had discussed that the SoW could be changed in the development process, and as we have foreseen, it happened indeed during the stages of development. Nevertheless, it didn’t affect the final result badly. On the contrary, we got even better results to be proud of.
As there left no points to discuss further, we got prepared for the actual invasion and hard work on the project. The workflow with the internal team of Nansen was naturally settled: if one side needed an answer, they asked direct questions and got all the explanations right away.
Engineers participating in the project were closely involved in the work of the in-house team. Also, they made every effort to make their activity transparent and understandable for every involved stakeholder. The Dysnix team is famous for making the working atmosphere easy-going thanks to three main points:
Throughout the active development phase, the Senior DevOps Engineer held demos, and the Cloud Architect conducted internal R&D and PoC deployment for better understanding and SoW adjustments.
Our engineers started to develop the documentation for the internal Nansen team from the preparation stage till everything was cleaned up on production. Thanks to the cooperative approach of in-house colleagues, we could set up our work fast, seeing the boundaries of responsibilities of each side.
We set up our dev environment to map the solution we planned to implement. We created Helm charts for this purpose and prepared all needed to test the connectivity with the validator.
Also, our engineers controlled all the setup settings and preparations of the infrastructure thanks to the IaC (Infrastructure as a Code) approach. This is one of the most important processes (or methodologies, if you like) we apply to keep our infrastructure easy-editable and make all changes or new features possible to implement in hours, not weeks.
Our engineers prepared everything for the backups and snapshots creation to keep all the information securely saved and protected. It’s essential to set these things up from the beginning and keep them at hand, as the Ronin blockchain won’t provide you with any snapshots. So we better keep our clients safe than sorry.
We concentrated on the main task of the project: to make the Ronin validator node isolated yet working. To reach that goal, we decided to implement the layer of so-called sentry nodes that would play two different roles in our infrastructure:
Thus, with this layer of sentry nodes, we implemented the one-way schema where the Ronin validator node can get information about what’s going on in the blockchain via a p2p connection to the sentry nodes. Still, nothing can connect a validator node directly from the internet.
This solution is fast enough and cost-efficient. It works fine with the existing blockchain infrastructure without delays or longer responses. We offer to proceed to the next level of implementation: to prepare the environment for the validator and connect it with sentry nodes.
After a few consultations and during the live sessions with our engineers, Nansen set up the validator nodes’ environment on their side. Our team supported and controlled the deployment of two validator nodes (the second served as the backup node) in the Google Kubernetes Engine and applied the best secure deployment practices. We advised duplicating the validators node to ensure the functionality from A to Z under any circumstances.
It seemed the mission was completed! The validator nodes were isolated, sentry nodes ran like clockwork, and the system was checked. It was only one step to the production left. Still, Dysnix engineers continued working over the IaC and Deployment as a code implementation to ensure:
Armored with these code bases, we could migrate to the production environment seamlessly and for a minimal time. And everything went as planned.
But while we were dealing with deploying the primary solution on production, Nansen prepared another exciting task for us that we couldn’t refuse to take…
Nansen management was so satisfied with the intermediary results that decided to strike the iron while it was hot. We got another request for deployment that wasn’t connected with the primary task directly.
Ronin archive nodes got into our list. As Nansen is a blockchain analytics company, they need fast and wholesome access to all blockchain data that can’t be stored elsewhere than in archive blockchain nodes.
We know that a typical Ronin archive node has some unpleasant limitations, e.g., typically, it needs around six hours to parse the analytics data from the blockchain for one day. That’s way too slow for Nansen. It’s obvious that we need some kind of “steroids” to make them function faster and still, with a high level of reliability and security, as the client wants. So Dysnix team had to “brush up” archive nodes slightly.
So to complete this task for an A+ grade, we’ve decided to play with it a little bit differently, still without any magic:
We’ve managed to decrease the time of the Ronin archive node daily update from six hours to 15 minutes. Nansen's team was pretty impressed with these results, and it helped them to boost their whole service, not only the infrastructure we’ve built for them.
The main development stage was completed, and we proceeded to the project’s enclosing actions.
It took around two weeks for all brushing up activities, clearing up everything on production, and improving the troubleshooting documentation for the internal Nansen team. We picked up the working docs we prepared at the beginning of our cooperation and checked if everything worked as expected.
Also, we had a series of live troubleshooting sessions where we showed how to deal with different issues with the load or environment settings to reach maximum productivity. In parallel, we edited our documentation to make it accurate according to the latest updates.
To sum up:
After this stage was done, we shook hands with Nansen and proceeded to the “passive” cooperation stage—the support.
After almost a year of work, the Dysnix team still supports the project.
We maintain the settled level of quality for Nansen, checking the most important indicators of the environment’s health. Also, we continue working on minor improvements that become available on the go.
To support our client efficiently, we build up monitoring, health checking, alerting, and upgrading systems that miss nothing out of sight.
The most pleasant and beloved platform Dysnix’s engineers use for monitoring is Grafana. First, the main indicators are selected for tracking goals and KPIs of environment functionality. Then we blend all the tracked information into the data pool and pull over the needed indicators on the controller’s screen.
We review the request volumes, the established connections, reloads, memory and CPU usage, and other indicators.
This and the following dashboards are also available for our client, but they are rarely checked. One Dysnix engineer can control and maintain this system without wasting too much time.
We also include these data in monthly reports for Nansen. It’s crucial to have stored data about the system's state, as if the problem occurs, our engineers can track the situation back to the normal state and restore everything as if nothing happens.
As security stays the most important demand of Nansen, we pay special attention to this matter. Thanks to the regular check-ups we conduct on the system, we ensure that it’s as safe as on the first day we’ve completed it.
Rolling timely updates is a semi-automated process we conduct for every supported client. We must ensure that everything works quickly and keep the system updated. Thus, the client appreciates that the system we created long ago stays efficient and improves with time.
This is the true goal of Dysnix support, isn’t it?
Solutions implemented by Dysnix have empowered the key competitive advantages of Nansen. As the main field of the client’s business is connected with blockchain analytics, we managed to influence the speed and secureness of inner processes. Improved infrastructure always causes visible benefits for the end customer’s experience and even decreases costs.
The main benefits we bring to the table can be summarized into the following categories:
Expected and planned values are the direct results of the SoW completed in full scale. Such as:
Regarding unexpected benefits and side effects, we can say that their value cannot be ignored. These points weren’t a part of the main quest for our team, but we’re used to doing everything we can to maximize the benefits for our clients.
From the technical standpoint, the Nansen tasks weren’t overcomplicated. Most of our processes were run in different variations at other projects. But anyway, we had to stay extremely cautious to keep everything 99.99% uptime and reliably secure. Thanks to our habit of situation modeling, planning, and “what-if” predictive thinking, we can prevent problems and catastrophes before they appear. Things that are established well—work well, as they say.
The second issue that kept our eyes open all the time was the change of plans of our client. That’s an absolutely normal situation when the plans switch their direction for 180 degrees at the end of the day, after a few rounds of interviewing, dozen working hours together with the in-house team, and making one or two experiments. The flexibility of our team causes the adaptability and deep customization of the solutions we provide. That’s why we’re not afraid of new ideas from our clients, ready to try them out with our tools and skills.
The short guide on how to get our help lies here:
We’re open to new opportunities, challenging projects, and extreme investigations. Our engineers will happily dig into the most problematic infrastructures and bring them to functional perfection. We know how to handle our job in the most challenging circumstances, so our clients have no reason to doubt our results. And we’re proud of it.
Things should work efficiently and bring profit.
