Build your decentralized applications with gWASM

Building decentralized applications can be easy. In the next paragraphs you will find out how we simplified a previously cumbersome process by launching our latest meta-use case, gWASM.

When your application or service work load hits limits, you think of changing machines, enlarging cluster or moving to a cloud. Instead of that you can integrate with gWASM and delegate your computations to Golem Network infrastructure.

gWASM stands for WebAssembly on Golem. It is intended to be a bridge between applications and extensible infrastructure. It gives your applications or services easy access to external and decentralized computational power. This access happens in anelastic manner, meaning that you rent as much infrastructure as you need and when you need.

gWASM being decentralized means that you are not bound to a single provider. Switching between providers and making new contracts is automated and quick. The cherry on top? This competitive marketplace offers good prices.

Why WebAssembly?

The WASM format popularity is growing at a fast pace. It has been supported supported by all the major web browsers for some time lately, other use cases have been  emerging - including Golem, Ethereum’s migration from EVM to eWASM, as Substrate’s runtime architecture, and more.

WebAssembly binaries are executed in the same way on various OSes: meaning it is almost deterministic. It allows better control so we can handle randomness and temporal operations and therefore make it truly deterministic. WASM brings of these benefits, without sacrificing performance, whilst the speed is comparable to native execution.

Cross-compilation of Rust, C, C++, js programs is a convenient way to create the WebAssembly code you need to create the gWASM task. In the gWASM setup, we use WebAssembly for remote computations, which is a different approach than the usually known -  for web browsers. It has its specific requirements but both remote and web browser WASM execution have similar security requirements. The WebAssembly binary is executed in a container which provides a pretty good protection level for target infrastructure.

How does gWASM work?

The applications integrated with gWASM consist of the main application, which we call the client application as it is a client for Golem, and the WebAssembly binary, which is distributed and executed by workers - the computational power providers. The client application itself does not need to be WebAssembly code. But in order to be integrated with Golem, it must communicate with the running Golem Client - to request computational tasks. For this purpose, you can use one of the three approaches: connectors, gwasm-runner tool or directly connecting to the running Golem Client. The WebAssembly binary is delegated to remote machines - called providers in the Golem Network - along with the input data, and executed there. The real value of Golem reveals when executing many such tasks in parallel. The task distribution is performed by the Golem platform. The client application is not burdened with the distribution, participating as a so-called requestor in Golem Network.

You could request computational tasks in Golem Network manually. The goal for the client application is to automate this process. For Golem there is no difference if the task was requested manually or by the application. It is a simple approach, however, gives great results. In this integration, from the point of view of your application, Golem becomes a backend.

There is no general way to parallelize computations. Due to this, it is the application's responsibility to divide one big task into smaller chunks that can be computed on a single node. This scheme follows the map-reduce pattern, or split-execute-merge as we call it. Simply put, when the application needs to split a big task, the chunks are executed by the nodes within the Golem Network, but the application needs to combine the results upon their return.

Use cases

gWASM can be used for more than one purpose. We will describe a few of them to give you a feeling what it is about.

1. Decentralized applications: The applications with gWASM backend are actually already decentralized applications. The client application can be light enough to be installed on a regular computer and it can be delivered to a broader user base. With gWASM, creating your own decentralized applications is simpler than ever.

2. Custom algorithms: As long as you maintain a program that can be executed in parallel, you can try to cross-compile it and run in gWASM. Some examples might be scientific computations, simulations or mathematical modelling. If you have some programming skills, you can modify your code and immediately run it. In this case gWASM acts as the computational cluster. However, it has an elastic size and does not require maintenance.

3. Applications: enhance your application with gWASM backend. You simply need to determine the components that are heavy CPU-consuming and try to cross-compile them. If the computation can be executed in parallel, then it is possible to integrate with gWASM and delegate those components as WebAssembly binaries to remote nodes. In that way, your application gains easy access to external resources.

4. Bursting: if your existing infrastructure often hit limits with the workload, you’d usually think of scaling it up or moving to a cloud. gWASM will provide bursting in the future, a solution that allows your application to offload excessive computations to the Golem Network when the infrastructure load is close to the limits. This way, you will use the Golem Network only if it is needed.

5. Services: if you host a service that requires larger infrastructure for computations, then, similar to the applications case, you can offload the excessive workload to the Golem Network. Integrate the service with gWASM so you do not have to invest in additional infrastructure. Worried about adding complexity to your users? No need, gWASM is a transparent layer that will not be noticed by them, and they won’t need to join the network or run nodes.

What’s more?

A good starting point to learn more about gWASM is our docs. We have also collected some examples of gWASM applications here. These docs show how to connect to Golem and what are the proposed ways to design solutions.

The gwasm-runner tool is quite important as well. It speeds up the development of applications as it handles Golem’s communication relieving you of these tasks, so you can focus on designing how to split tasks and merge results. You can read the docs or visit GitHub pages on this.

For more complex applications, you might use gwasm-api connector - a library that interfaces the communication with Golem. Currently, only the Rust implementation is available, but we are working on others.

We developed gWASM support on our product Golem Unlimited. Its purpose is to set up internal computational networks based on LAN connections. For instance, it can utilize office computers and organize them in a kind of cluster. The gwasm-runner tool has the advantage that it can run programs locally, on GU cluster or Golem Network. To get started with it, you can check our devcon materials.

The work on gWASM is ongoing, and the way ahead looks very promising. Along with improving the performance, marketplace and UX we also plan to replace our current WebAssembly sandbox, based on SpiderMonkey, with Wasmtime - WASI implementation. It is still under development but the work moves fast forward and we hope to integrate it soon. It perfectly fit to remote computations like Golem and we are happy to contribute to this magnificent project. This move to WASI is important to us, as it will standardize how WASM interacts with OSes, among other benefits as being part of a large community of partners helping each other, governed by Bytecode Alliance. Our goal is to constantly make gWASM better and better. We invite you to try it out, your feedback will help a lot through our quest, and we would very much appreciate it. If you can spare some minutes, please share your thoughts with this survey.