Integrate Statistical Data for Shared Nodes to assist buyers in selecting the most sustainable options

[ltraveler]

In the last validation (#113 -> #114), one of the shared node operators has produced a major validation failure. To prevent such cases, I suggest implementing a simple statistical system in the api key market that would display the statistics of shared node users and their validation status before and after.
This way, people could assess the quality of the node. This information could be retrieved directly from the payment address, utilizing the unique floating point after the integral part of the price. For example, if the price of the api key were 3 iDNA, we could represent the price as 3.14, using the fractional part as a unique ID for each node in the marketplace. The web application could retrieve this data directly from the blockchain.
After obtaining the list of all shared node users, we could also gather their status before and after the validation process and display those statistics in the market. This would be beneficial for potential buyers of shared node API keys, as it would help them assess the quality of the node.
We could also monitor the number of late submission errors experienced by a specific node, as it would serve as a more reliable factor directly associated with the shared node.

[an-trader]

It is also necessary to add to the shared node script to:

1. display server characteristics;
2. Report how many people have already rented the API key for the upcoming validation.

[ltraveler]

Regarding the number of API keys that have already been taken, I agree that it would be useful since we currently only have the "Slots Available" column. As for the characteristics, I believe that information wouldn't hold much significance because it could be easily manipulated. Additionally, if the validation statistics of a node are satisfactory, it indicates that the shared node operator cares about their node. In other words, the resources used can vary significantly, and this is not the dominant factor. The most reliable factor should be the user validation stat.

Actually, I have another idea that just came to mind. We could also monitor the number of late submission errors experienced by a specific node, as it would serve as a more reliable factor directly associated with the shared node.

[an-trader]

Aggregate information will not be superfluous.
Someone wants to see only statistics and that will be enough for him, and someone will want to see the whole picture.
For example:
There are 100 people per CPU or 500 people per CPU.
Maybe he was doing well before and was using 20 CPUs, but now he only has 1 CPU.

Right now the Shared node is selected blindly