Golem Protocol Part I: Decentralized Exchange for Computing

This is a first article in the series exploring and explaining Golem protocol, its goals, development, and solutions. All of this is still a work in progress — done at the moment mostly by me and Paweł Peregud (Pepesza). This is only part of what is going on — for a bullet point summary from rest of the team scroll down to the end of this post.

Alex and Pepesza working on protocol (photo by Andrzej)

Though the prevailing objective of Golem is to be a worldwide supercomputer, one way to look at Golem is as a decentralized exchange for computing. Rather than exchanging Apples for Oranges or Bitcoin for Ether, we make it possible for peers to exchange the output of a computation for payment in GNT. And, thanks to the programmability of Ethereum, it may be just as easy to trade computations for something that isn’t a token, such as a Cappuccino. Okay, maybe not an actual cup of coffee, but a voucher that can be redeemed for a coffee beverage would be nice.

For developers and entrepreneurs the most pertinent components of Golem are Task Definitions, the Application Registry and Transaction Framework. Whereas Task Definitions are technical and never seen by requestors, the Application Registry and Transaction Framework are exposed to requestors and are the medium for Golem applications to interface with external applications, business processes and the Golem network. For a developer to be paid with coffee after their code is run, they need to provide a coffee-remuneration scheme which is compliant with the transaction framework and then publish their software to the application registry.

The developer will also need to ensure there is sufficient supply of coffee, produce their software and garner traction, but of course, this is the case for any business and is mostly out of scope.

Golem Task

Important! As we near the first release, our objective is to build an adaptable architecture which is versioned and can be improved over time. Thus, the described task functionality may change during development.

Before trying to elucidate how to use a golem task to transmute CPU computations into coffee, we need to first go over the life of a Golem Task:

1. Requestor calls the task processor which creates a task contract for a given application and input data
2. Candidate providers see a new task on chain, check their ACLs and pricing, and if appropriate, send work request to requestor
3. Requestor replies to each provider, acknowledging addition of the provider as a payee
4. Upon receiving acknowledgement, provider retrieves task input
5. After requestor acknowledges a sufficient set of valid providers, the requestor finalizes the provider set and sends subtask assignments to providers
6. Task input is processed by providers and encrypted output is uploaded for requestor; repeat from step 5 until task is complete or fails
7. A “polite” requestor finalizes task contract (anyone can finalize if requestor is rude)
8. Task finalization triggers code from transaction framework which, depending upon the transaction scheme, may allocate tokens to an application developer

At a high level the steps above are governed and operated per the Application Registry, Transaction Framework and ACL configuration of the requestors and providers. The application registry is where developers publish their software and is a common reference for both parties. The transaction framework is referenced in the application registry, such that all parties understand how payments will be settled when the task concludes.

For example, if a provider doesn’t allow running the application of the requested task, the provider won’t respond to the task. As far as transaction schemes are concerned, the default scheme in Brass is a passive scheme in which the application developer doesn’t remit a fee for the transaction. (We hope to introduce this as a more rational (>0) fee so that other software can configure the same scheme to require a fee)

To give more meaning to this process, lets define terms you’ve seen, and some you haven’t:

General Terms

• Task – A request to perform work in exchange for payment
• Requestor – A golem peer that creates a Task
• Provider – A golem peer that executes a Task
• Recipient Address – Address permitted to withdraw GNT owed after Task completion (different for each party)

Golem Peer

• Golem Agent – Client software run by all Golem peers
• Resource Provider – Service which is supported by golem agent software and maybe required for some applications (ex: storage provider)
• Ethereum – Ethereum is critical for Golem. Not because we like Ethereum (we do), but because account code can interact with other accounts, transactions are difficult to censor and Ethereum has inbuilt state replication.

Ethereum Account / EVM Code

• Task Processor – Ethereum account, sometimes called a ‘factory’ or ‘generator’ that is entrusted to create tasks, validate subtask outputs and perform settlement. In contrast to being defined by the Requestor, Task Contracts are created by a task processor to facilitate versioning and trusted execution of EVM code.
• Task Contract – Ethereum account created by task processor with references to the requestor, application, providers and task input.
• Application Registry – Ethereum account used by a Golem developer to register and update pertinent details of an application such as the transaction scheme, claimed author, required execution environment, code signatures and configuration.
• Transaction Framework – Set of code, accounts, transaction scheme and configuration necessary to process, settle and remit payment and/or deposits to the parties of a Task Contract.
• Transaction Scheme – Payment scheme chosen by application developer which can specify a fee requirement when settling payments.

Golem Agent Configuration

• Application ACL – List of allowed applications
• Author ACL – List of authors whose applications are allowed
• Environment ACL – List of allowed execution environments

Note: By default, execution is ‘denied by default’ if an entry can’t be found in a list; however an ACL can be configured to allow by default, in which case entries are denied if found and allowed if not found.

That’s a lot to cover and there is more – in future posts we’ll want to cover the execution environment, validation, smart contracts, consensus and incentive. What’s important isn’t cryptography, code or contracts though — its caffeine. Assuming one could order a Cappuccino via Ethereum, what will this look like?

With Golem the computations are paid for in GNT, so one option is to turn GNT into coffee. This is the best (and only) option for a provider. The easiest method is for the provider to configure the Recipient Address to be an account which will swap a coffee voucher for GNT. Presumably such a ‘smart contract’ would be called an Option and it would permit redeeming a given number of Cappuccinos in exchange for GNT. Indeed, we have already seen code in the wild that enables exchanging Ether for GNT, so why not coffee?

For the developer, another option is the transaction framework. Rather than requiring a fee, the developer creates a Transaction Scheme which binds an option contract to the Task so that the option for coffee is created when the task is created and settled when the task is completed. The critical difference between the two options is that the Provider must manually perform a withdraw in order to execute the option, whereas the Developer’s code is executed atomically when the task is complete.

All together Golem’s Application Registry and Transaction Framework can be used together with Ethereum to integrate Golem transactions with other systems. I believe this is one of the most promising aspects of blockchain technology and we look forward to seeing what people can build on Golem.

Note from the rest of the team — apart from Alex’s and Paweł’s work on protocols, we were focused on:

• writing contract for payments in testGNT
• increasing test coverage
• working on macOS version
• moving Docker image to DockerHub
• testing different file transfers solutions
• integrating devp2p with Golem
• testing Blender integration by Blender professionals
• recruitment
• planning work on UX/UI

All of which, at this stage, would not make an interesting blog post. Notably, the team in Warsaw is moving to new, bigger office this weekend.