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.
    • Example: https://polkadot.network/blog/a-polkadot-postmortem-24-05-2021/

• 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.