> the first is that how do you verify that the hardware owner is running the real job an not NOOP'ing and sending false results?
Consensus. Have _n_ nodes perform the same work (if it’s deterministic), and only accept (and pay) if all the nodes match - or at least the nodes that were part of the majority
I don’t think this would be considerably different from SETI or folding@home, which have been going on for around twenty years.
For my senior project in college one of our ideas was a distributed render farm that operated like what we’re talking about. There were some additional issues there (transfering assets, preventing node owners from extracting the output [say a studio was “letting” fans donate compute time to render a feature film], etc).
If you can pay for a single fully trusted node to do the calculation once, the cost of n nodes redundantly calculating the same result in order to establish trust must require those untrusted nodes to be cumulatively cheaper than the one trusted node, in order for there to be an economic incentive to do so, no?
My assumption is that you would have to be faithful in a low number of untrusted nodes in order for that to end up cheaper.
The cases of folding and SETI are particularly different because there are institutions which have in interest in funding these programs in part due to their goal being a public cause. The same clearly doesn’t apply to micro tasks if you will.
But I can imagine cases in which you can accept bad actors giving bunk results for some percentage of the calculations you run. As long as you’re rotating nodes often enough (provided that they’re from distinct actors) I’m imagine it could work out to be economically more feasible to spend the time to work around that bad data than it would be to directly hire fully trustable compute power.
> Consensus. Have _n_ nodes perform the same work (if it’s deterministic), and only accept (and pay) if all the nodes match - or at least the nodes that were part of the majority
It would work well for problems that are computationally hard to solve, but easy to verify solutions for. Unfortunately, such problems are ubiquitous in cryptocurrency, but rare in machine learning.
Well, not really. Training a model is one such task. It's hard to train a network but easy to verify that it has good performance (training vs inference).
The real problem here, I believe, and I've seen this idea pop up several times on hackernews, is that almost no machine learning tasks are progress free.
If the cryptocurrency is just paid out to the person who solves the task first in a non-progress free problem, then the person with the fastest GPU would mine all the coins and nobody else can participate. One of the key ideas behind proof of work is that if two people have the same compute, and person A has a headstart, if person A has not succeeded by the time person B starts, they'll have the same probability of mining a block.
People seem to be just jumping on the crypto bandwagon and trying to come up with "useful" proof of work, but it's a pretty difficult task.
Consensus for every computation would be 2x as expensive, but you may be able to achieve something like it with randomly assigning 10% of the calculations to be double-checked, and double=checking more (all?) of a node's computations if it has an inconsistent result.
BOINC has quite a sophisticated system, but it's a long time since I looked at the details. I believe new participants are subject to greater scrutiny.
> Consensus. Have _n_ nodes perform the same work (if it’s deterministic), and only accept (and pay) if all the nodes match - or at least the nodes that were part of the majority
Consensus. Have _n_ nodes perform the same work (if it’s deterministic), and only accept (and pay) if all the nodes match - or at least the nodes that were part of the majority
I don’t think this would be considerably different from SETI or folding@home, which have been going on for around twenty years.
For my senior project in college one of our ideas was a distributed render farm that operated like what we’re talking about. There were some additional issues there (transfering assets, preventing node owners from extracting the output [say a studio was “letting” fans donate compute time to render a feature film], etc).