Single node or multiple node for a task on Crynux

[0xaaaaaron]

This is a long time discussion:

Many platforms use single node solution: easy to develop, easy to serve, however it does not guarantee correctness of computation. node can fake a result and return

Crynux Hydrogen network uses 3 node solution: harder to develop, require more computing resource, but it guarantee correctness of computation by consensus protocol and improve stability

[lukewwww]

The reason of having multiple nodes to run a single task is to achieve "decentralization", which gives us a functional system that is not controlled by a single party, and always accessible to every user.

If the system is controlled by a single party, he will drain profit from the system as much as he can, even if it requires him to do evil things that will hurt the users, or hurt the long term health of the ecosystem. Comparing to the extra computing resources, this is a much larger cost that is paid by all the users in the end, and it is invisible.

Indeed, there will always be extra costs to achieve consensus in a decentralized system (in our case, 3x computing resources), but we will see that the decentralized system is still economically optimum comparing to other solutions.

Let's break down the question into:

1. buying/rental cards VS spared cards

The spared cards are "free".

From the perspective of the card holders, they could accept a much lower price to run a task than the providers who are buying the cards to provide the service. Since they have already bought the cards for other purposes and the price paid to buy the card is not considered as the cost of running this service.

In its idle time, the card will make profit as long as the price paid is higher than the electricity consumed(the network bandwidth consumed is also the spared resource). So that the comparison is not "single node VS multiple nodes" but rather "card + network + electricity VS 3x of electricity".

2. centralized system VS decentralized system

If there is a centralized platform where the spared card holders could contribute their cards, the extra cost to verify the correctness of the computation result is still inevitable, since the card holders could cheat the centralized platform as well by providing fake computation results. The only difference is that the human could be used in the centralized platform. It is then "single node + human VS multiple nodes", and the human resource will definitely be more expensive than cards.

[lukewwww]

I was thinking if we could randomly choose some tasks to validate, instead of validating every task, most of the tasks could then be executed on a single node.

Before the Blockchain dispatches a task, it should decide whether the task requires validation based on a random sampling. The blockchain should send the task to 3 nodes if the task is chosen to be validated, and send it to only 1 node otherwise.

1. For this schema to work, the node should not know whether the task will be validated before it submits the result. The smart contract should not expose any info on the random sampling result, or the node selection result. I have not thought into the details, but I believe this could be implemented using ZKP, and it could already be practical for large scale using under the best ZK tech we have now.
2. The staking amount should be increased according to the sampling ratio, to make the network safe as before.

[lukewwww]

The discussion will be continued in #4

[0xaaaaaron]

multi-node consensus definitely has its value.
Meanwhile, many AIGC requests need multiple rounds of prompting to get ideal results.
Random seed, temperature and other hyperparameters introduce randomness to the results.

suppose user wants single-node solution and takes risk, should we offer this option?

Suppose there are 10% malicious nodes, users still have 99% chance to get a good result by requesting twice, which is still cheaper than three-node consensus.

[lukewwww]

Meanwhile, many AIGC requests need multiple rounds of prompting to get ideal results.
Random seed, temperature and other hyperparameters introduce randomness to the results.

The randomness should not be a problem in our current architecture. I think we can find solutions under our current design.

suppose user wants single-node solution and takes risk, should we offer this option?

Users will not care about whether it is single node or not, they just care how long a task will take, and how much will it cost. And as I mentioned above, we have "free" cards, so no matter how many nodes we're using for a single task, we will still be cheaper.

Suppose there are 10% malicious nodes, users still have 99% chance to get a good result by requesting twice, which is still cheaper than three-node consensus.

The problem is that the ratio of malicious nodes will not stop at 10%. if a node finds out that he could cheat the network without being found, he will immediately start as many nodes as he can to get more tokens for free, he doesn't even need more cards to do this. Then the ratio of the malicious nodes in the network will soon become 99%, and the network will be abandoned by all the users.