Solution architecture and details.
The nodes in the network can act as providers or requestors. Both the requestor and the provider share the same implementation of the Golem daemon.
The diagram above shows the architecture of the network. For the sake of simplicity, it shows just one requestor and one provider.
The requestor logic is implemented as a requestor agent, which is a piece of code that runs on the requestor's machine and communicates via REST with the Golem daemon's http server, usually running on the same machine.
Please note the "ALT" frames in the left part of the diagram above: there are two APIs that we support but a typical requestor agent contains application code in only one language and hence, will use only one of those alternatives.
For more information regarding a Golem requestor, have a look at:
The provider logic is implemented as a provider agent which is a piece of code that runs on the provider's machine and communicates via REST with the Golem daemon.
The provider can make its resources available to the requestors with the help of many types of execution units (exe-unit for short). Currently, Golem supports:
- VM exe unit (or VM runtime) that runs Docker images and allows for an interaction with the running container,
- and WASM exe unit (or WASM runtime) that runs WASM code
Please note the "ALT" frames in the diagram above: the provider uses only one exe unit at the same time out of the two available.
You can learn more about Golem providers here:
The payments between requestors and providers are made through Polygon, a Layer2 solution that greatly improves cost-effectiveness. However, a user can also opt to use the Ethereum mainnet if they should wish so.
More on that here: