Notice: Polkadot has migrated to AssetHub. Balances, data, referenda, and other on-chain activity has moved to AssetHub.Learn more
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)
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 7First of all, thank you very much for your thoughtful response.
I'm concerned that your first point only reinforces my confusion:
This is very true, but the client and the runtime are not at all the same, and, in fact, one of the distinguishing characteristics of the Polkadot Protocol is that it is technically only possible for there to be a single implementation of the runtime at a time - because the definition of the runtime is itself an element in runtime storage, the runtime definition is under the guarantees of the consensus protocol. This is why I do not understand in practice how the alternative Polkadot runtime will benefit the community - I believe that the time would be better spent reviewing, auditing, and contributing to THE implementation of the Polkadot runtime that is written in Rust/Substrate/FRAME.
I do not understand this logic at all:
Just because such a framework exists, it does not at all imply that it would be put into any particular use or be adopted by any particular community.
I agree with this statement, but I also stand by my assertion that the time would be better spent contributing to the canonical definition of the runtime (FRAME).
Thank you again for your thoughtful proposal and responses, but it is my opinion that this proposal does not add much value to the Polkadot community. I'm concerned that a lot of the thinking that has gone into this proposal has been based on faulty assumptions (e.g. conflating the client and the runtime) and that enough thought has not been put into the truly challenging part of the proposal (i.e. designing a framework for building Substrate-compatible runtimes in Go).