Solving Challenges in Golem with gWASM

In this new webinar created by Jakub Konka (one of Golem’s R&D researchers), viewers take a deep dive into the inner workings of gWASM.  

As you know in the last year or so Golem brought WebAssembly (WASM) to Golem to offer developers greater flexibility, security, and ease for launching decentralized applications on the network. As Golem continues to develop and iterate, Golem is still on task and en route to building a lighter, safer, more sustainable, and efficient future for offloading p2p computing tasks not only with WASM but, in the future, with the addition of WASI as well. All of these adjustments have one purpose; to create a better environment to support developers in application creation.

Previously to verify the accuracy of returned results that were executed on the Golem Network a developer would need to create a verification function to predict the intended outcome of running the task. A feature that is fundamental to smart contracts is also at the core of WASM and that is the deterministic nature of these technologies. Therefore, the developer sends one task to two providers and compares the results. If the results are in sync the requestor then knows the task was accurately executed. However, if the returned results are incongruent the task can be sent to a third provider for no additional charge. When two out of the three tasks match, the third provider with the incorrect returned value is considered a “liar”, and their reputation is negatively impacted on the network. The developer is charged more to run two computations instead of one but it’s a small price for the saved time.

When using the WASI extension which is best suited for operating within a system program. The ability to script outside of browsers lowers the number of systems that requestors need to manage. The provider is protected from malicious attacks on host files. As the owner of a runtime sequence, the provider

designates the specific folder that the particular module is granted access to. Thus the code the requestor is sending can not escape that folder. Folders can be saved and loaded but only in the designated area in which the module has access. In this environment none of the tasks are completed from cached memory, preventing the requestor from accessing the remaining host files. The provider is that much more secure with accepting, and running tasks. Additionally, our current sandboxing setup mandates JavaScript glue code matching, to connect incompatible system modules to execute the created WASM module at the provider end. The integration of WASI affords the opportunity to lean out this process by removing the dependency on JS, thus streamlining this effort.

WASM is a mega platform, and can be a bit tricky but the robustness of the platform affords developers the ability to launch a WASM module on the Golem Network, but there are some challenges. In the webinar Jakub reviews these difficulties that the integration provides. One such example that Jakub addresses is that a large WASM program can be detrimental if the program is too large. Take care not to overload the program or the memory can explode! The system isn’t perfect but it’s solid.

Golem continues to make key strides to provide solutions, propel the network, improve protocols, and create compelling environments for developers to build new applications to run on the Golem Network. Continue to stay apprised of Golem’s developments as progress is made towards The Next Milestone.