Unraveling Golem’s The Next Milestone, Part III

In the previous parts of this blogpost (Part I and Part II) we have introduced the fundamental concepts of the New Golem market and the generic Demand and Offer Specification language.

This new post lays out the elements of New Golem’s reference architecture, and illustrates how they interact to form a working ecosystem. This is an important base knowledge to have, before delving into the details of low-level Golem APIs (Application Programming Interfaces - acronym for software intermediaries that allow two applications to talk to each other).

Daemon & CLI (Command Line Interface)

To participate in the Golem network, a machine must host a component called Daemon. The Daemon is a piece of software which runs in the background and implements all the fundamental mechanics of the Golem ecosystem. It is responsible for:

• Node identity, account and key management
• Communication with other nodes in the Golem network
• Implementation of the low-level APIs
• Management of payments and integration with payment platforms (yes, the new Golem architecture allows various payment platforms, like plain Ethereum, or Layer-2 solutions)

So the Daemon will be the first component which must be up on a Golem node. It implements both Requestor and Provider APIs and features.

The reference architecture includes a CLI to control the state of the Daemon and a number of its administrative functions. So, you’ve used a CLI to setup the Daemon instance, and now you are ready to run the Agent apps...

Provider Agent

In order to advertise resources onto the Golem Market, the Offers need to be published and the incoming Demands processed, so that the Agreements with the Requestors can be negotiated. Then, the activity execution needs to be controlled, and finally, payment notes must be issued in order to receive payments for services. All these responsibilities are the domain of the Agent application on the Provider side.

So, as a Provider, you launch and configure your Provider Agent apps and let them do all the market, execution and payment control.

Requestor Agent App

Now that we fleshed out the provider agent, which component is responsible for formulating the Demand for computing resources available in the Golem network? There is an application on the Requestor side, which “knows what it wants”, ie. puts the specification of required resources, as well as acceptable commercial terms, in what we call a Demand, and issues it to the Golem market (using APIs published by the Daemon).

As the matching Offers arrive from the market, this Requestor Agent app selects the candidate Providers based on its market strategy, conducts negotiations and confirms the Agreement. Subsequently, it controls the execution, and validates the results in order to accept incoming invoices.

The Requestor Agent Apps will most likely be use-case specific, ie. tailored either for a specific task, or at least coupled with a specific ExeUnit type.

ExeUnits

All computing resources offered in the Golem network are wrapped by an abstract interface which allows to control the execution, and queries the state of the execution. We call the instances of this abstraction Execution Environments or ExeUnits.

After an Agreement (which entitles the Requestor to use resources offered by the Provider) is signed an Activity is created. As part of this Activity, an ExeUnit instance is launched, and the Golem APIs allow the Requestor to control the execution of payload in this ExeUnit instance.

Think of the ExeUnit as a host which is capable of eg. running binary modules in a given format. So we may have eg. WASM ExeUnits (capable of running WASM modules), VM ExeUnits (capable of running VM machines on which software packages can be deployed and run, etc.)

The attributes and parameters of ExeUnits are specified via their Properties (remember the Specification Language described in previous post?). It is via the Properties in an Offer, that the Providers indicate they are willing to host payload in a given ExeUnit. And it is via the constraints against those Properties in a Demand, that the Requestors announce their requirements. This also explains how a variety of different types of computing resources can be traded on an open Golem market.

...all this together

All the modules described above, working together, comprise the logical Golem network. The Golem Factory is currently building an implementation of this reference architecture - we called it Yagna:

The diagram above indicates high-level relationships between Yagna modules. The next post will unveil some details regarding the APIs published by the Daemon, and how a model “negotiation-execution-payment” flow is handled by those APIs.

For more information about Golem, head over to our website

Got feedback on this blogpost? send us an email or join our Discord!

Want to start a discussion about it? Reddit's the best place for it!

Follow us on Twitter to get the latest announcements & progress updates