Framework for building Substrate-compatible Runtimes in Go (Parachains & Solochains)
Hi everyone,
My name is Chris Veselinov, CTO of LimeChain, and I’m writing this thread to propose the development (and funding) of a Go Runtime.
With this proposal, we’re looking to diversify and simplify the blockchain (parachain) development process, making the ecosystem more approachable/beginner-friendly and potentially more stable.
The ultimate/end goal is creating a framework in Go, which is an alternative to Substrate. However, it will be technically challenging to go for the direct implementation without abstracting components into different modules. Given that a modular approach has been taken, the practical goal would be to formalize those modules into a framework that can be reused by other developers.
This is why we propose to develop a framework for building Go Runtimes.
We recently got a W3F grant to research the technical feasibility of the project, as we encountered some Go-related challenges along the R&D process. We were able to get those out of the way and you can look at our efforts here.
Please see the official proposal document here. Any feedback or comments are highly appreciated.
About us: LimeChain is a blockchain development company founded in 2017 with a focus on building core blockchain infrastructure, developer tooling and dapps. We dove into the Polkadot ecosystem about 2 years ago with Subsembly - a framework used to design and implement Substrate runtimes in AssemblyScript, again funded by the W3F. Due to AssemblyScript limitations, we were able to partially deliver on the framework specifications.
Thanks on behalf of the whole LimeChain team!
Comments (7)
Comments (7)
What is the value in your ultimate end goal of implementing an alternative Polkadot runtime? One of the fundamental value propositions of the Polkadot protocol is that there is a single implementation of the runtime that is distributed in a portable format (Wasm) so that all clients, regardless of their specific hardware architecture, can share the exact same implementation of the runtime. How do you see the Polkadot community benefiting from your proposed Polkadot Go Relay Chain Runtime in practice? Regarding the framework for building Go runtimes that you propose, I'm quite curious to learn more details about the 7th milestone that you have proposed, and I am concerned that the effort that will be required to implement such a thing is underrepresented in the materials you have provided. Can you please provide more details regarding the vision for this framework? Do you intend to implement FRAME in Go, or do you intend on building a wholly new framework. If the latter is the case, what is your vision for the new framework?
Hi there,
My name is Rado, senior core dev at LimeChain, and I will try to clarify our proposition:
-
What is the value in your ultimate end goal of implementing an alternative Polkadot runtime?- As quoted in the document proposal, we believe that having multiple implementations is beneficial for the Polkadot ecosystem. The independent development and maintenance of multiple clients makes the network more resilient to attacks and bugs. When you have one client implementation, it enforces the Polkadot ecosystem to rely on that single client to be infallible.
-
How do you see the Polkadot community benefiting from your proposed Polkadot Go Relay Chain Runtime in practice?- We believe that having a Framework for building Go-based Runtimes, thus implying the existence of Polkadot Runtime in Go would lower the barrier to entry for developers and make the Polkadot ecosystem more accessible and more competitive.
- As mentioned above, having another Runtime implementation of the specification gives diversity and allows the potential salvation of critical bugs, network resiliency and security.
- A relevant example is a need for client diversity in Ethereum. Earlier this year Prysm accounted for >65% which was an issue for the Ethereum ecosystem.
”If a client with 66%+ of market share has a bug and forks to its own chain, it'll be capable of finalising. Once the fork finalises, the validators cannot return to the real chain without being slashed. If a minority client forks, the 50%+ majority client can obtain a 66%+ majority. With no client having a market share over 33%, these scenarios are avoided.” (source: clientdiversity.org)
-
Regarding Milestone 7- Our proposal is phase-based where each phase has milestones. The described proposal covers the development of phase 1 and the design/architecture of phase 2. After we deliver the milestones for the runtime implementation in Go (Milestone 1-6), we intend to begin focusing on Phase 2 by delivering Milestone 7, which is a prequel of the next phase. Once we deliver Milestone 6, we will have a working Go-based Runtime which we will redesign to become a framework. We have added Milestone 7 to this proposal (Phase 1) to show the commitment of our team on delivering the initial goal - Framework for Go runtimes. We have not finalised whether the framework will be based on FRAME, but it will have a similar modular design (as Substrate) through which developers will be able to pick and choose the modules (BABE, GRANDPA, etc.) they need for their blockchain.
What is the value in your ultimate end goal of implementing an alternative Polkadot runtime? One of the fundamental value propositions of the Polkadot protocol is that there is a single implementation of the runtime that is distributed in a portable format (Wasm) so that all clients, regardless of their specific hardware architecture, can share the exact same implementation of the runtime. How do you see the Polkadot community benefiting from your proposed Polkadot Go Relay Chain Runtime in practice? Regarding the framework for building Go runtimes that you propose, I'm quite curious to learn more details about the 7th milestone that you have proposed, and I am concerned that the effort that will be required to implement such a thing is underrepresented in the materials you have provided. Can you please provide more details regarding the vision for this framework? Do you intend to implement FRAME in Go, or do you intend on building a wholly new framework. If the latter is the case, what is your vision for the new framework?
Hi there,
My name is Rado, senior core dev at LimeChain, and I will try to clarify our proposition:
What is the value in your ultimate end goal of implementing an alternative Polkadot runtime?How do you see the Polkadot community benefiting from your proposed Polkadot Go Relay Chain Runtime in practice?”If a client with 66%+ of market share has a bug and forks to its own chain, it'll be capable of finalising. Once the fork finalises, the validators cannot return to the real chain without being slashed. If a minority client forks, the 50%+ majority client can obtain a 66%+ majority. With no client having a market share over 33%, these scenarios are avoided.” (source: clientdiversity.org)
Regarding Milestone 7