Q&A with Piotr Janiuk (acting CEO/ CTO), Part I
One of our community members e-mailed Piotr some of these questions, and after some consideration, he decided to answer them - however, we believe that transparency and equal access to information are paramount for a healthy, thriving community.
This blogpost came up spontaneously. One of our community members e-mailed Piotr some of these questions, and after some consideration, he decided to answer them - however, we believe that transparency and equal access to information are paramount for a healthy, thriving community. So we prepared this blogpost to share with the wider audience.
Some of you might have read some answers before in our AMAs - every other month, we get together to answer all questions our community has. AMAs are one of the most effective ways we have of gauging the community’s sentiment, their concerns, the things they are interested in, and more. However, these questions are a nice reminder to the larger Decentralized Ecosystem that Golem is more alive than ever, constantly striving for the best, and our commitment are still as strong as when the research for this adventure started, in 2015.
Read the first half of the Q&A with Piotr below - maybe you find one answer you’ve been looking for!
Q: How committed is Golem in using Ethereum? On the assumption of Ethereum not scaling in the short-medium term will you consider building on another protocol?
PJ: By design, Golem is platform-agnostic regarding the underlying smart contracts engine. We started the project with Ethereum in mind. Back then, it was the only project which offered smart contracts execution in a decentralized manner.
From our perspective, the situation hasn't changed all that much. Nowadays there is more variety in terms of protocols that enable smart contract implementation and execution, but in our opinion, Ethereum continues to be the platform that’s more adaptable to our project’s needs and, at the same time, has the most promising future.
I refer to the famous "scalability trilemma" diagram, in which out of the three requirements (speed, security, and decentralization), one can pick only two. Relative thresholds between the two chosen features have to be set up, and the third one remains underutilized.
Even though the original trilemma statement is perhaps inherently true, Ethereum seems to be the project that should lower these thresholds significantly. Which, in turn, may result in both a secure and decentralized implementation tied to an acceptable level of scalability.
Additionally, Ethereum’s biggest asset is the large number of highly qualified and talented developers. It seems that Ethereum has captured the most active community in the generalized blockchain space in terms of building capabilities. We are still to see how PoS and Sharding, in conjunction with L2 solutions help solve the scalability issues in general. This is going to be an important checkpoint for us.
In conclusion, we stay open-minded, but for the time being our choice is Ethereum.
Q: Are you working on driving Golem user adoption in the short term or is the project contingent on a more scalable base protocol?
PJ: The short answer is both. We're still in beta, so short term adoption is essential. It allows us to battle-test each new version of our software and all the newly-introduced features, using a broad user base and set-up diversity that wouldn’t be achieved with our internal QA only.
It also improves project perception in general and our credibility within the space, subsequently increasing our chances of bringing talented developers aboard. At the same time, we are aware that some of the components currently implemented in Brass Golem are hard to improve to a production-grade state, so we are still too early in the product development cycle for mass adoption.
Golem is sometimes described as a prosumer market for computing power, which is limiting and binds Golem to a specific way of approaching network resources. To be clear, Golem allows such an approach but is not limited to it.
Specifically, Golem is a platform enabling its participants to describe and locate almost any computational resource which can be connected to the Internet as a standalone node. This includes Single-board computers as well as large Golem Unlimited clusters exposed to the network in the form of powerful endpoints.
This low-level layer corresponds to the discovery protocol. The protocol additionally allows users to describe formally both the pricing model for the resource as well as the details of the settlement, which results in their ability to create an agreement between the parties.
In short, the description above englobes the entirety of the protocol.
In terms of design principles, an important one is the expressiveness of this protocol. Developers should be able to easily define new classes of resources or payment schemes without any changes to the protocol itself. For example, this may pertain to describing the requirement of a resource being "green" (be that color or, for instance, a requirement that the resource is environment-friendly in some sense, specified in the description).
On the other hand, a class of high-level requirements can also be specified. This encompasses, for example, some level of confidentiality guarantees (e.g., nodes have a specified TEE, such as SGX enabled) or censorship resistance (node is a part of a P2P subnetwork). Other features might come along the way of our progress.
Last but not least, Golem already provides tools for "executing" the resources. At the moment, this boils down to apps run inside a Docker container. But in the context of the protocol, this set is going to be much richer, and at the same time, exposed to users via interfaces consistent with the protocol.
Q: What has been the response/ uptake in Golem unlimited?
PJ: Golem Unlimited’s code has been open sourced for months now; however, we have made a conscious decision to keep the project rather low profile for the moment. We wanted to have a working gateway to the main Golem network first. This has already been launched, so we're ready to communicate this platform widely.
In the meantime, despite limited product promotion, we were contacted by a few companies interested in Golem Unlimited. Companies which own data centers, large-scale commercial projects, and also research institutes. Some of these contacts resulted in further negotiations, and some of these projects have been directly mentioned in our AMA. We have also announced our partnership with Hoard, which will onboard game dev into the ecosytem via the Hoard Code Compiler powered by Golem Unlimited.
Internally, we've also implemented a few plugins to gain a better understanding of how Golem Unlimited's UX can be improved. These include, for example, a general MPI integration, and more specific integrations related to molecular dynamics and computational chemistry. Golem Unlimited is also interesting to community members who would like to utilize SGX and Graphene within this framework. SGX support via Graphene in Golem is one of our top priorities, which also translates to its implementation in Golem Unlimited.
Q: The Golem SDK is vital for Golem’s long-term success in order for developers to build on top of it. How far has the SDK come along since the AMA in January and are there any delivery dates?
PJ: At the moment, we're focused on two pieces of the SDK. The first one is the initial version of the Golem Unlimited SDK, which is going to be battle-tested and improved during the implementation of the game development integration mentioned above.
Another piece is the Task API. As stated in the answer to the second question, short-term user adoption is important for us. For this purpose, we're working on the so-called Simple Task API implemented according to the White Paper. It is a Python implementation, anchored in the Brass codebase that will allow developers to integrate with Brass Golem and Clay Golem. We've been working intensively on this API for a few months now, and it should be ready by Devcon5.
We believe that the step mentioned above is essential to pave the road for the integration of more generic Golem features within the existing codebase. For this purpose, we are developing a facade implementing a more generic Task API, pretty close to the API planned for the Stone Golem. This API is Rust-based, and it will allow a smooth transition from the current Brass approach to the more generic protocol already mentioned in question no 2.
As this is a part of our long-term plan, it may not be ready before the end of this year.
Q: What have been the recent developments in the Pay-as-you-go model in Golem? Have there been any new thoughts in combining game-theoretic approaches to the cross-checking model?
PJ: The model is simply one of the payment models considered in the protocol mentioned in the second question. In the context of the protocol, this will neither be the single model nor a privileged one, and a user will be able to choose a model suitable for the needs and the type of the resource being shared.
To make the current Golem implementation more attractive, we've already started implementing the Pay-as-you-go model in Brass. For the time being, it is limited only to the WASM, and RASPA use cases. The WASM integration can be constrained to produce only deterministic results, which makes the integration of this model less risky for the users. WASM should be added to one of the forthcoming Golem releases (the testnet version is planned for the 0.20 release).
This brings us to the second part of the current question: some sort of game-theoretical approach is necessary in markets utilizing decentralized networks. From our experience, there is no silver-bullet approach for all the classes of problems in the different markets. Our R&D team has been working on a redundant verification framework for some time now, and it is going to be evaluated both against the WASM use case, where we can rely on the results being deterministic, as well as against non-deterministic use cases such as rendering.
This approach encompasses a quite rich collection of use cases, but it can be extended further with the introduction of additional types of nodes in the network. Two examples that our R&D team takes into consideration now are nodes with higher trust guarantees based on reputation, and inherently trustworthy nodes (up to a point of course) for example, by exposing an execution environment based on SGX or other TEEs. This is still work-in-progress, and again, at first, the redundant verification framework is going to be released for the WASM use cases only.
One additional vertical which we have in mind is that users will be able to develop their services - assisting in increasing the general guarantees of computations in the network. At the moment, one of these services is Concent service developed by our team and is integrated within Brass Golem and utilizing GNT deposits. But ultimately, such services may and should be implemented by third parties.
In short, developers will be able to implement additional algorithms based on the game theory.
Q: Do you envisage golem token price volatility to negatively impact user adoption?
PJ: If pay-as-you-go is taken into account, then volatility doesn't matter that much, as the granularity of the payments may be fine-tuned to mitigate the risks associated with the volatile cryptocurrencies market. Other models may be more prone to price volatility, but as it will be up to the user to decide which pricing scheme to choose, users can make conscious choices based on their expected outcome.
We also have other ideas, which may prove useful in this context, e.g., short-term stable GNT. As opposed to stablecoins, the pool of stable GNT should be relatively small and correlated with the velocity of the token. However, this idea is not a priority for us, because we're only about to find out which settlement models and types of resources result in the most exposure to the volatility - or which generate most of the transaction volume. For some scenarios, there is no need to deal with the price velocity at all. Additionally, as mentioned in the answer to the previous question, third party services may be implemented to minimize the exposure of users to this specific risk.
At this moment, the primary token related problem, which impacts user adoption, is the general precarious UX state of blockchain technologies. These UX challenges manifest in many ways, ranging from acquiring the tokens for the first time (onboarding) to exchanging them for fiat (offboarding), or spending in a fiat-like way. We are aware that a significant number of companies in the space work on improving such challenges, so we'd rather wait for their results and push forward our main project, than focus on solving this general problem.
One class of solutions which we're looking into are gasless wallets. The sole fact of using crypto has UX trade-offs already, but having to use both the native token (for utility purposes) and ETH (for gas) is another problem. It makes the user experience of any dApp with custom token more challenging than it could be. The Constantinople upgrade added features to Ethereum tailored to solve this pain point, and both the theoretical frameworks and initial implementations are already there.
We hope you enjoyed this Q&A, and while we don’t intend to make this into a series, be on the lookout for the following parts of this session with Piotr, and maybe with other team members (besides our AMAs). As always, we would like to thank you for your support and we’ll continue working towards delivering bleeding edge technology for the betterment of our decentralized future.