Many different crypto project are running decentralized computing as it’s a good piece to complete the distributed storage or messaging I previously documented. The principle is to be able to deploy a workload on someone else computed to serve a reliable web service. This layer is a IaaS layer like we can find on Azure, Aws, GCP, Ovh… This layer is an important piece of a decentralized cloud in construction in the web3.

In this blog post, I’ll review some of the projects and explain how to be part and use the one that seems the more reliable. As there are many different solutions and it has been a bit long to test all and publish them in a single blog post, this will be split into different one. The first one is about GOLEM.

Golem

Golem is a different network than flux with a smaller size, only 417 providers and 11TB of memory even if the project is from 2016. This is about 15 bare-metal servers in a data-center equivalent, about 1 single bay. The token is an ERC-20. Golem run with a really simpler tokenomic, you rent your hardware at the CPU per hour cost you want. For sure there is a competition between providers and this creates a market price. You can come with any type of machine, the consumer will select server corresponding to its need.

As a provider you will just get $GLM for renting your server. In the current usage context where there are only about 20 actives providers computing something (some peak to 50), you won’t get a chance to compute a lot at a fair price as there are 400+ providers available. The network has up to 800 providers.

In my point of view, golem is interesting when you have some spare workload. As an example, I’m running some bare-metal servers with available core/ram/hdd capacity available for my future need and not yet allocated. So it’d better than nothing to allocate these resources to golem and expect some little rewards. In this context these servers are providing a no-cost computing power and have no more impact on carbon emission, so better making them available than let them sleeping.

Currently, as a consequence, you can’t invest on a server for going to golem without facing loss. The CPU cost is currently around 0,015GLM / h equal to 10,95 $GLM per month for a core, equivalent to $3 currently. This is not especially low cost. There is also an environment per hour cost but I did found a clear definition of it. We see that the memory is not a factor of cost, here everything is about computing power, even if memory should be preferred as it is the more complex resource to manage in a data center. Golem seems to look at making it simple, it’s not a bad direction.

As Golem does not have a speculative business model, no PoW or mining, its carbon impact is really efficient. I consider it as a way to use available computing capacities, so we could consider it as negative in term of carbon production (but I won’t really validate this feeling I have).

Golem seems to have been made for task oriented applications, like FaaS more than running docker container, even if it is possible to run a docker container on it. Golem is currently processing files in / out. You can’t natively create a web service with Golem, this is a big limitation. But if you have scalable file processing (like 3D image calculation in the examples) it’s really powerful. But what you can do is sharing your internet connection with the golem provider, basically tunneling your container to your computer launching the processing. That way you can create a HTTP communication. Honestly it’s not as easy as running a container and accessing it. But it has an advantage : as a provider, you are not exposing you provider IP in case of malicious usage and this is important also.

I usually don’t like when a service is priced with the token, instead of a stable coin, but due to the batch orientation of golem, you use it to run short tasks and you will adjust you target cost on every batch. There is no bad surprise due to the token price variation.

Installing golem to provide Hardware

The Golem installation tutorial is easy to follow. You need to have a ubuntu 18.4 or 20.4 LTS and to have an Ethereum address fro receiving your rewards. During the installation, you will get the name for your instance and you can select your renting price. For this you may take a look to the current renting price you can see on the Golem stat page.

After the installation you can run golem as a background process and check the status:

[root ~] nohup golemsp run &
[root ~] tail -f nohup.out   # to see what going on CTRL+C to close
[root ~] golemsp status

You get the following status page:

Then you can tune the setting to limit the server usage or tune prices:

[root ~] golemsp settings set --help
...
OPTIONS:
        --node-name <node-name>             
        ...

[root ~] golemsp settings set --cores 5
[root ~] golemsp settings set --memory 24GiB
[root ~] golemsp settings set --disk 512GiB
[root ~] golemsp settings set --starting-fee 0.0
[root ~] golemsp settings set --env-per-hour 0.001
[root ~] golemsp settings set --cpu-per-hour 0.001
[root ~]  golemsp settings show
node name: "needless-measure"
Shared resources:
	cores:	5
	memory:	24 GiB
	disk:	512 GiB

Pricing for preset "vm":
	0.001000000000000000 GLM per cpu hour
	0.001000000000000000 GLM per hour
	0.000000000000000000 GLM for start
...

After a certain time you can see your node on the online explorer the refresh is not real time, so just wait.

Deploying your workload on Golem

The workload will be created in a docker container. You need to install some tools.

[root ~] apt-get install python3 python3-pip
[root ~] pip install gvmkit-build

Get the local running environment by downloading the last deb file from ya-runtime-dbg project.

[root ~] wget https://github.com/golemfactory/ya-runtime-dbg/releases/download/xxxx/ya-runtime-dbg_vxxxx_amd64.deb
[root ~] dpkg -i ./ya-runtime-dbg_v0.2.3_amd64.deb

Create a Dockerfile with your application content. For this the simpler way is to take a look at the project documentation. It can simply be something like:

FROM debian:latest
VOLUME /golem/input /golem/output
WORKDIR /golem/work

Create and convert the container image

[root ~] docker build -t golem-test .
[root ~] gvmkit-build golem-test:latest

Test it locally

[root ~] mkdir /tmp/workdir
[root ~] ya-runtime-dbg \
--runtime ~/.local/lib/yagna/plugins/ya-runtime-vm/ya-runtime-vm \
--task-package ~/docker-golem-test-latest-446e7d5452.gvmi \
--workdir /tmp/workdir

You should get a bash prompt from inside your container.

Then the image can be pushed on the golem registry. Save the hash link, you will need it to start the instance.

[root ~] gvmkit-build golem-test:latest --push
...
hash link 2a7f305747435332fc0ac91457bc59dfd3b3ab72ee67cbb09589cbc2
...

Then you can run it using a python script. I will no go into the details as you can follow the example available on this golem-hello-wold github. It contains a python script to simplify the launch. (let give you more details later)