Distributed computing with centralized payments? Does anyone know if such a system exists?
So, I will admit that I used to be excited about Ethereum. In theory, it was going to provide a distributed computing platform with distributed payments. In practice, is sucks big time.
One cool thing about computing like this is that you don't need to rely on AWS or Google or Azure. You could spin up arbitrary servers all over in the world. Your own computer could, in its idle time, perform useful computation for pay. (Especially useful if your heat is already electric.) That's pretty neat, and makes sense from an environmental perspective (because it means making less hardware for the same computation.)
Of course, Ethereum fails on its promise because it's too slow and too hard to use, Ethereum fees are hilariously ludicrous, and they're still not 100% proof-of-stake. One big problem is because it relies on a cryptocurrency instead of trusting big financial institutions.
Like, there is no reason you can't have something like this that relies on a centralized payment processor! You just have to trust, say, Visa not to cheat. (That's easier for me to trust than, say, the EVM or Solidity code not to have bugs.)
But as far as I'm aware, such a thing doesn't exist in general. This exists for niches (e.g. Blender rendering farms that allow you to trade render hours) but I can't think of something for general computation. So... Does anyone know if such a thing does exist?
(i ask it here because I feel other forums would go "uhh ethereum is the future just u wait" and i am simply tired of that)
wbn wrote (edited )
Haha, neat. This question touches upon things that I’ve thought about in depth in a way that is almost unreasonably on-the-nose. It’s so on-the-nose that I honestly can’t help myself from diving in deep on the topic, so here we go.
A couple of years ago, I joined a cryptocurrency startup knowing almost nothing about the space besides some very surface-level knowledge about Bitcoin. They told me they were working on “proof of stake,” and I looked into it a little and saw that there were some problems with it conceptually, but was broadly excited for it to save cryptocurrency from its power consumption problems. (At the time, I was not nearly as concerned about the energy consumption of proof of work as I am now.) So I was on board with the space for a while, I went to some meetups and conferences, met a lot of people working on different projects. However I started to get really frustrated about the way that everyone was focusing on Ethereum being the one true path forward, because the EVM stood out to me as being a flawed idea with a miserable history that should be obvious to anyone who researched into it even a little. So I grew disgruntled and quit shortly after the launch of ETH2 “mainnet”. I reckon it’ll be at least another couple of years before ETH proof of stake becomes viable, although honestly the amount of grifters and willfully uninformed people in the space makes me angry to even think about, so I’ve tuned out at this point.
I digress though. In response to your question, I think the really hard part of what you’re asking about is that you need whatever workload you’re running to be trivially verifiable. That is, you need to be able to look at the input, the program, and the output, and be able to tell if the computation was performed correctly (verifiable). Otherwise, the party to whom you’re delegating the computation could produce a fake or misleading result. Plus, you need to be able to do this while using less computational effort than actually running the program yourself (trivially), because otherwise there is no point in having someone else do it for you.
In ETH, this is pretty simple - all computation done on the EVM is so trivial that it should barely take any time at all for anyone with a computer to verify. The high cost and slow throughput is due to the fact that this computation needs to be run on every computer in the entire network of nodes participating in Ethereum. In Ethereum, the integrity of any block (and the computations described therein) is cryptographically linked to all of the blocks that came before it, so a bad computation in the history of the blockchain at any point undermines the integrity of the chain as a whole. Therefore the EVM is kept simple and deterministic so that anyone can verify the computation and reject any transactions that cannot be verified. The integrity of the system as a whole relies on at least 51% of the hashing power being controlled by honest actors, in the same way as Bitcoin, yada yada yada, I’m pretty sure you’re familiar with this concept.
However you can’t build a general purpose computing platform atop this concept in the way that you are used to from cloud platforms and VMs and serverless and stuff. The EVM simply doesn’t have the capabilities of a processor instruction set like x86 or ARM, and even if you could cross-compile the program you want to run for an EVM target, the resulting program would likely be too large and complex to store, much less execute, on the chain. But if you get rid of the chain, you need to have some other means of confirming that the person who processed your computation was honest about it.
(edit: I think I got the specifics of this next paragraph wrong, I believe im still right in principle though and I want to return to it and correct it, but you shouldn’t take what im saying here at face value)
This brings us back to the problem of trivial verifiability. You might remember Folding@home, one of the most famous distributed computing projects that came before Bitcoin or Ethereum, which let you use your “spare computing cycles” (scare quotes here because there is indeed an additional energy cost to doing this, but that’s a different topic) to help out researchers who need to compute mathematically difficult problems like protein folding. Of course the researchers need some way to verify that the output of the computation was correct, otherwise a malicious person could participate in the network and jeopardize the results of their research. So they had to come up with various methods of verification, some of which are outlined in this helpful StackExchange post, but the thing is it’s still not perfect! They have to rely on heuristics and sometimes guesswork to verify the results, and this is specific to their workload - for any type of program, you have to manually develop a verification regime that is both rigorous and less costly than actually running the program yourself. Developing a general-purpose verification method would be equivalently hard to solving the halting problem: you either need a huge theoretical breakthrough in computer science, or you need to restrict the system to the point where it’s unusable for modern computational needs (like Ethereum does).
The alternative to this is placing your trust in an authority that can track and ban suspected malicious actors in the distributed computing system. There are some other things you can do too, like running the same computation across 2 or more remote workers and comparing the results, but this inevitably requires some sort of proof of work/stake to operate correctly, lest an attacker just flood the system to try and get their malicious nodes to serve the same N requests.
So that’s kind of where we stand today, you either need a highly specialized workload or to trust some authority. I guess since you trust Visa more than Ethereum or the major cloud vendors, you could ask them if they’re willing to rent out some extra space in their compute cluster to you?
Jokes aside, I have one addendum that might possibly be useful to you. During one of those conferences I attended when I was a young, naive, doe-eyed blockchain acolyte, I met a guy who was working on a project that sounds maybe a little like what you’re looking for, if you squint at it right. It was called Burner Machine and it lets you launch your own TAILS-style anonymous VM in the cloud. Unfortunately (and unsurprisingly), you can only pay for it in crypto, which means it’s something i basically don’t want to touch out of principle (and I suspect you probably don’t either). The same guy I talked to also gave a presentation about his project versus AWS focusing on platform risk; most of this went over my head and I suspect it was mostly puff anyway. But in case you find such a project interesting, there it is.