Future of NKNx - by ChrisT

The following is copied from Discord NKNx channel, by NKNx developer ChrisT:

ChrisT | nknx Today at 8:14 AM

Hey @everyone, I think you already recognized on the chat but if not be aware that current updating-processes (nodes and wallets) on NKNx are stopped until further announcements. That brings me to both of the problems we currently see with NKNx:

  1. The performance of the NKNx portal itself within the last weeks/months.
    As many of you know: the overall performance of NKNx is just bad. This is not because it has too many visitors, it is because it’s built-in node- and wallet updating function. For those who don’t know: NKNx establishes a connection to all of the nodes you store in the database (currently more than 60k) to get their status and save it to the database. If you do some math and assume that every node update will just take 0.5sec (contacting the node, await response, write to database) you will come to the conclusion that updating 60k nodes will take around 8 hours. Of course we already run the node updater in something called multithreaded mode but that leads to an overall poor performance of nginx and PHP itself.

  2. The “donation” on each fastDeploy node
    One and a half year ago we decided to introduced the “forced donation” feature on fastDeploy. This decision was mainly powered because of the fact that we won’t be able to pay server costs just by begging for donations. At this time the NKN token was valued at 3ct, so not a big deal for most of the miners. Now after the price hit 60ct+ it is a big deal for many small miners and doesn’t feel like the best solution for future services.

How to solve both problems?

Currently we’re thinking about converting NKNx to a SaaS platform. Meaning: every user is generally capped by the numbers of nodes/wallets he can watch through NKNx. Also the number of FastDeploys is limited. That gives small miners the opportunity to play around with NKN and get to know the project easily.

For the more heavy users we plan to establish different subscription tiers that enable higher limits and additional features like eMail notifications and the direct API-deployments for DigitalOcean, Google Cloud, Hetzner, etc. Also the smaller tiers won’t be able to see history data since their nodes won’t be updated by the server anymore.

But now I need your opinion! What do you think NKNx should become? Is our idea and the problems understandable for you? As always every message is appreciated!

1 Like

You could reduce the update time of each node to 10 seconds, or 1 minute, but to be reliable, mining a block per node every 3 weeks I don’t think anyone needs to see what happens in real time.

And you could also reduce the number of NKN in forced donations with fastdeploy, something like 50% or 25%

Edit: nStatus.org is still reliable? I am having discrepancies with some nodes

First of all, I really appreciate all the efforts you have done so far! NKNx is really making life easier for NKN miners.

Regarding the current problems and future, I want to share my thoughts (mainly on the tech side):

The first thing is, do you really need to constantly crawl node status, or is it enough to crawl when user visit the site? If you want each node’s mining history, you just need to parse the blockchain history once (for all users), then you can get each node’s mining history as long as you know the node ID. I can’t really think of other reasons to crawl node status when users don’t need.

The second thing is, instead of letting your server crawling and updating all node status, what about distributing all the work to user’s browser when they open the site? I can think of two ways here:

  1. If node has https cert, user can directly make rpc request to node using https rpc endpoint.
  2. If node does not have https cert, maybe you can run a simple program alongside nknd, which is simply a nkn multiclient, receiving messages and reply with local nknd status. Then you can create a nkn multiclient inside user’s browser and use it to query node status.

If all these methods fail, you can fallback to server query, but it should be rare. If you can make all these heavy work decentralized, your server pressure should be way less and can scale up easily.

The technical solution I mentioned should work together with the business model you proposed. It’s just a nice way to reduce your server load with minimal user experience change.

Hi, I’m new in here, and the first question I ask myself is: why can’t everyone run his own version of nknx for his own set of nodes?. Then nknx.org can update status from a lot less sourcess, and each admin can see faster/detailed info on their nodes… You won’t break the interaction between nodes or harm the network in any way, just the displaying of data. You should reduce substantially server load for the bigger nknx.org service and each individual would benefit from faster access to his own data…
Again, this is what I ask myself without knowing much of the history of the protocol itselfand howit evolved to what it is today.

One of the early version of nkn-dashboard is indeed run by each individual miners, especially if you have less than a few hundred nodes. But for large miners, client side queries might become too time consuming and some centralized database will be faster and more user friendly.

I saw that dashboard when looking for alternatives, but the last update is from late 2019… I assumed it was a dropped project… Is still operational?

Won’t relying solely on nknx.org be kinda like opossed to the decentralization goal?

The author was one of the NKNx team, and he is now focusing on nknx web dashboard. I tried that nkn-dashboard in late 2019, and it might need a bit of tinkering to get it fully working. But it is worth a try.

Hey there, I’ve just test the dashboard first time since 2019 and it still works :smiley:

When we’ll finish all the stuff with new nknx, I’ll try to refactor it bit

2 Likes

It´s working very well yet! Can you add an option to customize the names of the nodes? Thx

Well, I’ll give it a try!