ReadyLayerOne - The next milestone: A Golem (R)evolution Synopsis

TL;DR(/W)

Roughly 18 months ago the Golem team looked back at lessons learned so far and the future ahead. What we came up with was the idea for a new architecture around a set of core principles, that later turned into a successful PoC presented at ReadyLayerOne. This new Golem comes with less imposed restrictions based on our assumptions and synergizes with our plans going forward, such as the migration of GNT to be an ERC-20 token. The code has been made open ( https://github.com/golemfactory/yagna ) and details on how we ran our PoC are available in this directory .

History and Lessons Learned

The Golem idea was conceived in 2014 when the team learned about the EVM requirements. Shortly thereafter, we verified and implemented the PoC, and presented it at Devcon0 . What we came up with were the basic building blocks of what Golem has grown into with Brass and onto Clay, using Ethereum for the transaction framework to settle the payments between participants.

Back then, we focused mostly on a three-sided prosumer market (requestors, providers and software developers building on top of the protocol), at the time we assumed that users should be allowed to (or forced) have valid results in the network. Therefore, a verification scheme was set up and implemented it in the protocol.

Golem’s ultimate aim is computing power and there are different types of resources that can provide this. We have built out some of these options so far:

• Golem Unlimited facilitating access to trusted subnetworks.
• Graphene allows users to run unmodified binaries in an SGX enclave.
• gWASM is for developers so that they can implement some code in the language of their choice and deploy it on the network.
• Task API, a python library containing a programming interface and utility functions where developers can deploy their own dockerized apps to the Golem Network without a need for them to be included in Golem releases. Effectively, it enables much more robust release cycles for specific Golem use-cases.

Needless to say, we have managed to gather a substantial amount of knowledge by building, learning from our predecessors, challenging our assumptions and by striving to always deliver to the best of our knowledge - we arrived at various conclusions and decided to implement the lessons learned into our project.

It was around late 2018 when we took a step back and re-evaluated our assumptions, looking at the project from a wider perspective. We began thinking about the architecture and what the principles of the project are and should be, then how we can use them to potentially build an even better Golem. This manifested itself to be what we’re discussing now, The Next Milestone (aka New Golem).

Through this presentation, Piotr Janiuk, our CEO/CTO explained what the future holds for Golem, and what we have built out so far in this regard.

The Next Milestone (aka New Golem): A Golem (R)evolution

We decided to call this presentation A Golem (R)evolution because, from the perspective of the users and community it’s a marked change and something new in Golem.

From the team’s standpoint, it’s been a long, evolving, and ongoing process that resulted in The Next Milestone.

What is New Golem

It’s a platform based on an ecosystem of protocols that enable the sharing of computational resources in exchange for the network’s native tokens.

In order to achieve this, Golem needs to locate resources and describe them. This is a complex mission, therefore, we have created a brand new protocol with new architecture and codebase allowing users to share these computational resources.

The architecture of this new protocol is based on the aforementioned lessons learned, and utilizing industry-standard architectural frameworks. The components are:

• Architecture principles
• Models
• Standards
• Building blocks

Currently, New Golem has a developer-centric approach, as we first need to attract developers for them to grow the platform, to determine what their needs are and build compelling apps. We are creating a platform for them to have a low barrier for entry where it’s relatively easy for them to integrate with the platform.

Golem Factory cannot decide which will be the killer use-case to power up the platform - only developers building applications have this knowledge. Industries, independent developers, and enthusiasts alike will be able to have a high-quality platform to use at their discretion, without limitations.

This platform should provide features that are not so easily found in other platforms. New Golem features a well-defined set of application design patterns and a demand-offer language. We have chosen to build the new codebase in Rust, a language known for its performance and safety. In addition, the package will be lighter, and onboarding will be significantly easier.

What we are building will allow developers to build the use-cases they need in a smoother way. Any developer with a laptop with Linux will be able to download the Golem SDK package and start tinkering with it: setting up a node and testing applications without time-consuming onboarding or challenges.

How will this look for integrators?

The protocols and standards are specified by Golem Factory and Golem Factory will also provide a set of open-source, reference framework software implementations. For this approach, applications come from independent developers and these developers will be able to choose the application design pattern relevant to their use-cases.

The integration of applications and Golem Network will be facilitated by four APIs, the Market API, Activity API, Payment API (built on Ethereum), and the Identity API. The client applications will interact with the APIs following generic scenarios.

New Golem Architecture

1. Open as in - open protocols, APIs and standards, where the community can implement things on their own and add to the ecosystem.
2. Modular as in - both golem factory and community can add modules - implementations of building blocks, and as long as the interfaces are met, the modules should plug together nicely.
3. Platform-agnostic as in - by having standardized interfaces we can have a .Net requestor app on WIndows executing a WebAssembly payload package on a Linux host.
4. Structured approach as in - we identify building blocks, we specify them, we implement them, we learn from experience, we update the building blocks, etc.
5. Industry standards where applicable - RESTful APIs, ProtoBuf for low-level GSB communication, OpenAPI/yaml for API specification.

From a very high level, the image below will provide you with a view of what architecture will look like:

Don’t worry if this looks cumbersome, we are planning to present part II of our The Next Milestone series explaining the architecture in detail very soon!

New Golem MVP

While development progresses towards the MVP, we are able to outline the core principles of what we are aiming to achieve:

On a slightly lower-level than the previous image of the architecture, we show our goals with the relation between requestor and provider nodes (above).

Included in this section of the presentation, we guide through the PoC internal demo. You can either wait till the conference organizers release the videos, or check it out in our GitHub.

TNM code: https://github.com/golemfactory/yagna

If you’re after details on how we ran the PoC, you can find it in this directory .

ERC20 Migration

When we started designing the GNT token, ERC-20 was not yet a recognized and popular industry standard. We wanted to keep the token as simple as possible so the approve functionality was skipped, as there were security and complexity concerns at the time. Since then, DEXes / DeFi / meta transactions flourished - and the ERC-20 standard grew in adoption thanks to them.

Right now, we see the migration to ERC-20 as a necessity, as the standard grows to adapt many solutions that make the user experience easier, but most importantly, help as well with scalability-related issues.

Additionally, migrating GNT to be an ERC-20 compliant token makes it possible to implement gasless transactions, improve on/off-ramping, add Layer-2 scaling solutions and finally add the token to DEXes and general DeFi (e.g. liquidity pools). This takes away our sole reliance on centralized exchanges to help us onboard new users.

Last but not least, due to the nature of centralized exchanges and their KYC requirements, more users are moving to decentralized counterparts. Being listed on DEXes allows the inclusion in the fast growing DeFi ecosystem (for example, Uniswap for liquidity or Opyn/Nexus Mutual for insurance).

While the migration process is not ready yet, we will start explaining the planning and other details shortly, and please stay tuned on the official channels for future information on dates, procedures and others. For now, there is no action required from our token holders as the Migration process has not started.

Where are we now?

• We've delivered an internal PoC for The Next Milestone in mid-April - this opened up the opportunity for us to re-group and plan our efforts to get to the MVP in a more efficient manner
• Part of it was restructuring our team to better align with the new goals, we're moving from 33% of the team working on New Golem towards having 100% of the team focused on these efforts
• Our ultimate goal is to provide a top-notch SDK with a relatively shallow learning curve. We plan to work very closely with external developers to learn about their needs and how to best cater them. The decentralized marketplace is one of the key value propositions of our platform (being able to buy/sell resources in a distributed, censorship resistant way), therefore we are progressing from our PoC where we used a centralized .Net implementation of the market towards the proper implementation. One of our teams is fully focused on building the decentralized marketplace.
• One of the Golem challenges is lowering the cost of the transactions that are being used for paying for computing resources. We're looking into several L2 solutions, AND most recently coming into the conclusion that ZK-rollup could offer the best fit. However, we remain on the lookout for the latest developments on this front.
• We consider our WASM ExeUnit MVP as ready. Now we will focus now on releasing the VM ExeUnit to provide the migration from Linux binaries to working apps in the most seamless way possible. We're also planning to start the effort on other ExeUnits, most specifically, supporting secure enclaves.

If you want to learn more about that before the video is released, feel free to check our latest blogpost onThe Next Milestone or some of the answers taken from the Reddit AMA, collected for an easier read in theAMA summary.