Unraveling Golem’s The Next Milestone, Part II

Missed out on Part I? Check it out here

It is about time we delve into the fundamental architectural concepts which constitute the foundations of New Golem.

The ideas of the Golem Network have evolved over the years to finally form a generic logical vision of a decentralized computation resources marketplace - by “computing resource” we mean almost any hardware device running almost any software, which can be communicated with using a computer network. The Next Milestone (dubbed Yagna internally) is the first implementation of these concepts. It is the Reference Implementation, which demonstrates the Golem Network mechanisms, is modular, and allows enhancements and applications to be developed by independent developers & integrators. All the New Golem-compliant applications are expected to follow certain basic patterns and protocols, so let’s dive in...

New Golem Market Fundamentals

Let us reiterate how we see a decentralized computing resources marketplace - which Golem Network essentially is meant to be.

The network participants play two roles:

• Requestor - a party which intends to consume specific computing resources and pay for it in Golem Tokens,
• Provider - a party that is willing to share its own computing resources in exchange for Golem Tokens.

The New Golem network’s main purpose is to allow Requestors and Providers to find each other in a decentralized manner. To achieve that, both Requestors and Providers need to have a way to express their intents on the market, ie. “What do I want to buy?”, “What resources do I have to offer?” In other words, Requestors need to formulate their Demands, while Providers need to express their Offers.

Exactly after they are formulated, the Demands and Offers need to be published in the Golem Network market, which will match and route them, so that Requestors are put in contact with potential Providers to negotiate the “terms of business”.

The above vision implies that both Requestors and Providers are able to express their intents with regards to their required services, resource volumes, commercial terms, etc.

Taking into account the sheer variety of what we can consider a “shareable computing resource” (which can be anything from a chunk of storage through a Virtual Machine, to a complex computing service like eg. a Hadoop cluster), we have come up with a way to achieve the aforementioned vision: the Demand & Offer Specification Language.

Demand & Offer Specification Language

Rather than trying to come up with specifications for all conceivable computing resources, our team at Golem decided to define a generic specification model. This model can be extended by any integrator willing to add new classes of computing resources to the Golem ecosystem.

As long as the Demands & Offers are composed following a specific set of rules, they can be published on the Golem Network. Then the matching business proposals may appear thanks to the Golem Market protocol, which is designed to abstract from specific use-cases. In effect, the Golem Market is universal and does not limit the variety of computing resources that can be specified and offered.

Both Demand and Offer are composed of:

• Properties - which indicate the attributes of the resource requirement, pricing and payment terms, Requestor/Provider themselves, etc.
• Constraints - which express conditions that the other side’s Properties must meet. Constraints are expressed in a syntax similar to LDAP Filters, but with some Golem-specific nuances added.
  

A sample Demand may look as follows:

#properties

golem.com.term.expiration_dt="2020-06-15T23:20:50.52Z"
golem.srv.comp.wasm.task_package="hash:sha3:44aba2d41021fac2a3b7af8a3ccfc0a3d4a435f9187ea7d5c162035b:http://54.231.6.186:4500/app-44aba2d4.yimg"

#constraints

(&
    (golem.inf.mem.gib>0.5)
    (golem.inf.storage.gib>1)
    (golem.com.pricing.model=linear)
    (golem.srv.runtime.name=wasmtime)
)

A sample Offer may look as below:

#properties

#Supported Payment model "payu" = *Pay* as you *U*se
golem.com.payment.scheme="payu"
golem.com.payment.scheme.payu.interval_sec=6

#Price = 0 + 0.01 * <exe unit duration in secs> + <exe unit cpu usage in cpu secs> * 0.01
golem.com.pricing.model="linear"
golem.com.pricing.model.linear.coeffs=[0, 0.01, 0.01]
golem.com.usage.vector=["golem.usage.duration_sec", "golem.usage.cpu_sec"]

# Offered memory is 1GB
golem.inf.mem.gib=1
# Storage for image + input files + output files is 10GB.
golem.inf.storage.gib=10

# Offered runtime is wasmtime version 0.0.0
golem.srv.runtime.name="wasmtime"
golem.srv.runtime.version@v="0.0.0"

# constraints
()

The fundamental rule of the New Golem Market is - for a Demand and an Offer offer to match, the Offer’s properties must match the Demand’s constraints and vice versa. Based on this “constraints-properties check”, the Golem decentralized market protocol shall route Offers to matching Demands’ Requestors.

Note that the Demand & Offer content above has been formatted to be human-readable. The actual artifacts circulated in Golem Network have a different format.

Property Standards

The Demand & Offer Specification Language is designed to be generic and abstract from any specific use-case. We want the Golem ecosystem to support almost any class of resources that developers and integrators may come up with. But what properties should a Provider put in their Offer to successfully “sell” their resources? And which ones should a Requestor refer to in their Demand to find a suitable service Provider?

For this purpose and as part of the Reference Implementation, Golem will be publishing Standardized Property sets to document the syntax and semantics of the properties implemented in New Golem. These Standards are not a closed set, instead, they serve as a repository of common properties, and as a guideline for developers on how new resource classes should be specified in the Golem Ecosystem.

An example entry from Property Standards is shown below:

All in all, and simply put - any interaction in the Golem Network begins with Demands and Offers being published and Requestors finding their candidate Providers. In the next post, we will look at how The Next Milestone sets Demands & Offers in motion and what happens next.

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