Alex Sunnarborg writes this week in Coindesk about “Golem”, which is building a blockchain based market that allows people to “rent” cycles on any participating computer. This is said to be a “global supercomputer”, which will supposedly “[deliver] all necessary resources to complete any computing task.”
Despite their puffery, this is hardly a new idea. This idea actually predated the web (), and has been implemented many times in many forms. These solutions use a variety of charging schemes, including attempts at matchmaking and auctions.
In fact, the main technical “innovation” is an electronic market for these cycles, and I’m not sure just how original that idea really is in any case.
(Putting on my academic hat, I’m highly unamused by the complete lack of citation or acknowledgment of any previous work. Tsk.)
There are two obvious questions to ask. First, does the blockchain add something important to this technology? And second, based on several decades of experience, how well will this work?
Using the blockchain makes the system peer-to-peer, so everyone can sell and buy cycles from anyone at any time. Earlier systems have careful controls to assure that all users are authenticated, and that the network is collaborating on security and payment schemes.
These “centralized” gatekeepers are essential for certain uses, such as sharing within a corporate network or other protected domain (think about a large government lab such as Oak Ridge), while excluding outsiders and preventing leaks. I don’t think that using a blockchain helps these cases, and certainly isn’t really necessary.
But how well might this work? Who needs large amounts of computing power, but doesn’t want to buy computers or virtual machines?
This is often called “high throughput computing” in the supercomputer arena, problems where you need a slew of cycles every once in a while, and it’s OK if there is come latency, and also if there is a bit of variability (i.e., not everything finishes at a the same time). There are some problems that this suits very well, and others that don’t work this way. See the copious documentation from your local supercomputing center.
Unfortunately, there may not be all that many problems that fit this model—and most of them are already solved by conventional server farms and other schemes. It is possible that a blockchain-based solution might be cheaper (as their whitepaper suggests), but I don’t think there is all that much room to undercut big server farms. (In any case, the big guys can always run the blockchain technology, too, and wipe you out.) So I have to wonder if there is a market for this.
There are going to be some other challenges. First of all, who needs cycles, anyway? Most of us have plenty of idle cycles. We are often constrained by storage, or bandwidth, or other non-computation constraints (e.g., security, software licenses, funding).
Of course, it is possible to extend Golem to stuff other than cycles, but accounting and resource management will get complicated. I can imagine the project going down a rabbit hole as they try to support more and more complicated “contracts” for some combination of cycles, storage, bandwidth, and other stuff.
(And speaking of “complexity”: if Golem succeeds, and attracts zillions of nodes all over the world, that will be a mother of a matchmaking problem! You can wave your hands, and say the market will magically fix it. But I think there will be many weirdnesses and inefficiencies in resource allocation and matching.)
There may well be significant legal issues. For one thing, I guarantee you that it is against policy to run this on work or school computers, because you don’t own those resources, the organization will decide.
Even trickier is the question of liability for how your computer is used. It’s easy to say, let me “rent” my computer to some stranger on the internet. But, whether you like it or not, you are legally responsible for what is computed by your system, so how do you protect yourself from serious liability?
Take their example application from the white paper, CGI rendering on a remote computer (, p. 6)
“CGI rendering is the first and very illustrative case of real Golem usage. Rather than using costly cloud-based services or waiting ages for one’s own machine to complete the task, CGI artists can now rent compute resources from other users to render an image quickly. The payment from a requestor (in this case, a CGI artist) is sent directly to providers who made their resources available. In addition, when the artist’s machine is idle, it can itself accept tasks from other users.”
Let’s try out a few problematic cases of this scenario, where
- the imagery is copyrighted or stolen
- the imagery is proprietary or classified
- the imagery is construed as pornography
- the imagery is defamatory, hate speech, or religiously prohibited
In any of these cases you could very well be in serious trouble for allowing it to be rendered on your machine, even by someone else, someone from another jurisdiction.
The Golem “solution” to this problem is to somehow have an array of (trusted?) “validators” who “review and certify applications as safe and trustworthy” or malicious. You can choose among the various “white lists” to accept only “safe” code.
(It is not at all clear what incentives these “validators” have or what their motives might be. Where will they come from, and why would I trust them?)
But in any case, this mechanism is entirely irrelevant to my problematic examples above: it’s not the application (Blender in this case), it’s the data and the use of the application that are the problem—which the “validators” never see and don’t rate.
Unfortunately, I am very sure that some of the eagerest uses of this system will be doing stuff that they can’t easily do on conventional server farms. Such as cracking codes, mining stolen data, or just operating an extralegal business. And I’m very sure that the authorities will gladly roast you for hosting anything that is illegal in your local jurisdiction, even if someone else did it.
I note that the older, “centralized” systems have extensive hierarchical organization. Users are authenticated by one or more participating organizations, which trust each other to vet the users and their activity. There is a very good reason to want the network to be “trusted”.
The “trustless” blockchain system does not have this precaution, so every seller is on his own. You attorney will probably advise you to “just say, no”.
Bottom line: it is questionable if anyone needs this service, and only a fool would let untrusted parties use his computer.
Also, it’s not that original an idea, and the blockchain is not especially useful for this service.
Just say no.
- Golem, The Golem Project: Crowdfunding Whitepaper. Release Candidate, 2016. https://golem.network/doc/ReleasecandidateGolemwhitepaper.pdf
- Litzkow, Michael J., Miron Livny, and Matt W. Mutka. Condor – a hunter of idle workstations. In Proceedings – International Conference on Distributed Computing Systems, 1988, 104-111. https://www.scopus.com/inward/record.uri?eid=2-s2.0-0024138827&partnerID=40&md5=02f61dd59214ff19ae10ac4ba77b5dec