|
QuarkJets posted:Normally supercomputers charge by computational time, which captures what you described. But it's very easy to spoof that to be whatever you want, if you exclusively own the hardware. They pay by CPU hour, which is by computation. You can pretty easily instead attach a computational amount to each piece of work and then pay out based on what you complete. The tricky part won't be tracking what you've done, it'll be ensuring that you actually did it vs just made up something random. No plan would care if it took you 6 seconds or 6000 and pay you by that, they'd just pay you based on what you churned out.
|
#
?
Sep 21, 2018 02:04
|
|
|
|
| # ? Apr 24, 2024 07:06 |
|
|
Lockback posted:They pay by CPU hour, which is by computation. You can pretty easily instead attach a computational amount to each piece of work and then pay out based on what you complete. The tricky part won't be tracking what you've done, it'll be ensuring that you actually did it vs just made up something random. "Cpu hour" is computational time, it accounts for the fact that different computations take different lengths of time. "per computation" implies that time per computation is not a factor, which is not done anywhere that I know of I think that attaching a certain amount of computational time (e.g. CPU hours) to a job submission is fine. But say that I want as many digits of pi as possible and I say that I want 100 cpu hours attached to the task. Even with verification of outputs, some systems will produce a different number of digits in the same amount of computational time. How do you identify bad actors in such a situation? "You can't" may be an acceptable answer, but it would be great to solve the problem anyway
|
|
#
?
Sep 21, 2018 02:25
|
|
|
QuarkJets posted:"Cpu hour" is computational time, it accounts for the fact that different computations take different lengths of time. "per computation" implies that time per computation is not a factor, which is not done anywhere that I know of BLOCKCHAIN!
|
|
#
?
Sep 21, 2018 02:33
|
|
|
I switched my PC to Folding @ Home and it "pays" a variable amount based on how loaded the PC was. If it gets all the GPU time it credits more than if I'm playing games. The way it verifies is sending the same job to multiple computers, there are apparently enough fast computers volunteering for the duplicate work to still be worth it though. Edit: To elaborate further I think it determines a work unit should take 2 hours and it slides the points around based on if it's faster or slower. craig588 fucked around with this message at 03:30 on Sep 21, 2018 |
|
#
?
Sep 21, 2018 02:41
|
|
|
QuarkJets posted:Even with verification of outputs, some systems will produce a different number of digits in the same amount of computational time. How do you identify bad actors in such a situation? "You can't" may be an acceptable answer, but it would be great to solve the problem anyway Comfy Fleece Sweater posted:BLOCKCHAIN! craig588 posted:The way it verifies is sending the same job to multiple computers, there are apparently enough fast computers volunteering for the duplicate work to still be worth it though. Yeah, the answer to the "bad actors" issue is to simply farm out the same computation to multiple nodes, and then look for a consensus result. The real question is can you get that consensus using a small enough duplication factor so that the cost of doing the same thing X times doesn't let the monetary cost exceed simply running it on AWS or another HPC farm whose one-run output you implicitly trust. Idle buttcoin farms will work for very low wages, but generally won't work for free or at a loss (unless you pay them in fake crypto coins, I suppose...).
|
|
#
?
Sep 21, 2018 17:40
|
|
|
Man I hate to contribute to this thread, but cryptonerds did make my machine learning box pay for itself. Plus I guess it's not really crypto if we're talking about legit computation.DrDork posted:Yeah, the answer to the "bad actors" issue is to simply farm out the same computation to multiple nodes, and then look for a consensus result. The real question is can you get that consensus using a small enough duplication factor so that the cost of doing the same thing X times doesn't let the monetary cost exceed simply running it on AWS or another HPC farm whose one-run output you implicitly trust. Idle buttcoin farms will work for very low wages, but generally won't work for free or at a loss (unless you pay them in fake crypto coins, I suppose...). This seems pretty simple to me; the answer is you can beat bad actors easily enough as long as you split the computation into discrete jobs and only pay out an address once it has completed N jobs. The way I imagine it, before payout the system randomly duplicates some % of the jobs and gives them to other actors to check. If you don't trust the checkers, you can establish trust by checking a fraction of their checks, recursively going up the tree with progressively fewer checks until you get to some "central" authority - presumably the original issuer of the job since their interest is aligned here. At payout time, you randomly check X% of jobs for that actor. If any fail, the actor forfeits the entire payout. The math works out such that as long as N is greater than 1/X cheating will be entirely unprofitable. If you cheat 100% of the time you'll never get paid. If you cheat more intelligently just some of the time, you may have a chance of getting away with it, but you'll also have to contribute real compute to ensure that chance isn't zero. In the end you will wind up forfeiting more real compute than you gain from cheating, regardless of what fraction of your results are fake. Naturally you'd want some buffer room in either N or X to account for the checker trust system, but in total you can get the overhead to be pretty low. At a 1% checkrate you only need 100 jobs per payout to secure the system - achievable for most distributed tasks if you're targeting weekly or monthly payouts for a typical actor. You'd need a reverse-check system to prevent the job issuers themselves from maliciously marking everyone as cheaters at the root level, and one for preventing actors from DDoSing the system by spamming fake results for no benefit. I think this idea can be applied to the former in the same way with little overhead since the issuer isn't checking a large number of results. I presume the latter is already solved in existing blockchain protocols somehow.
|
|
#
?
Sep 21, 2018 20:41
|
|
|
|
| # ? Apr 24, 2024 07:06 |
|
|
Eyes Only posted:Man I hate to contribute to this thread, but cryptonerds did make my machine learning box pay for itself. Plus I guess it's not really crypto if we're talking about legit computation. I'm not really convinced that a public blockchain structure would offer any advantages over simply centrally controlling the distribution of jobs and verification work. With that sort of central control, you don't have to worry about malicious job issuers and you can simply kick out bad actors after a certain number of infractions, and ban their GPU identifiers to prevent them from creating a new account. You could even create a "trust" system where verification jobs are performed by the most reliable users who have built up solid reputations. Using a public structure would let you create a system that would theoretically run itself, I suppose, but it seems like it would have a hard time competing with more reliable managed systems that could afford to do less validation.
|
|
#
?
Sep 22, 2018 02:15
|
|
