KAGOME – the C++ implementation of Polkadot Host milestone 2
KAGOME treasury proposal 2
KAGOME is a C++ Polkadot Host implementation that provides an alternative to Polkadot-SDK to run relay chain validator client. In this treasury proposal, the Quadrivium team is seeking further funding for the development and initial security audit of KAGOME.
Why another Host implementation?
With KAGOME and other client implementations, we bring clients diversity to Polkadot, which allows for:
- Reducing the risks of bugs in a single client implementation, such as halted Kusama parachain block production, or Polkadot dispute storm
- Bringing innovations (e.g. 2x faster erasure coding)
- Expanding the development community to other languages
To learn more about KAGOME and the importance of client diversity in the Polkadot ecosystem, you can:
- Watch the most recent presentation during Polkadot Decoded 2023.
- Read some of the recent tweets from the Polkadot account about client diversity.
- Get familiar with the Alternative Polkadot Host implementations RFP by Web3 Foundation.
How is KAGOME aligned with the Polkadot 2.0 vision?
Accoring to Polkadot’s Co-Founder Robert Habermeier: “The 2.0 era will be defined by a decentralized collective of developers designing and building in the open. This marks a transition from a few agents building software to many agents - sometimes competing, sometimes collaborating, but all working to move things forward” (source)
Moreover, in the recent announcement by Parity technologies it was announced that “Parity will be zeroing in on delivering Polkadot's next-gen technology, improving the developer experience, and fostering a strong developer community” and emphasized importance of diverse builders in ecosystem.
The KAGOME team has proven to be one of the most experienced and competent teams in the ecosystem, when it comes to understanding how the Polkadot protocol works. This fact reduces the dependency on a single team developing Polkadot protocol.
Our team has remained relatively unchanged over the past 3-4 years, allowing us to develop the most advanced alternative relay chain client. Today KAGOME:
- Participates in the Kusama 1000 validators program, securing the Kusama network as one of its validators. (Source: Twitter, Validator)
- Serves as a permanent validator in Westend. (Source: Westend)
- Boasts the fastest Erasure coding implementation. (Source: Twitter)
Reflecting on previous proposal submission
This is the resubmission of Referendum 146, which did not pass despite receiving much positive feedback highlighting the team's competence and the high quality of our previous work. Therefore this proposal was adjusted with the following changes:
- DevOps and QA support will be handled without Soramitsu's involvement.
- The Quadrivium team will take over quality assurance.
- The existing development team will temporarily maintain the CI/CD process until a new DevOps engineer is hired.
- Optimized Scope resulting in 33% cost reduction:
- The proposal duration has been shortened from 6 months to 4 months, focusing on the most urgent and impactful features: BEEFY, Async backing, and WasmEdge integration.
The scope of proposal
The proposed scope is already being implemented. The full scope of the proposal is following:
- Asynchronous backing
- already implemented, being tested
- BEEFY
- voting is done, only slashing is left (as in Substrate)
- New WASM Engine (WASM Edge)
- Security Audit (by SRLabs)
- General maintenance and minor improvements
- DevOps and QA
Requested DOT: 168432
Please review the full proposal with detailed tasks descriptions and price breakdown:
https://docs.google.com/document/d/17ZmueuaMjXY3_SRBHxWtKNHzpLNtSd_KGVfeTII6Nbc/
About Quadrivium
Quadrivium is a team of original C++ developers who developed KAGOME and C++ Libp2p while being part of Soramitsu. Soramitsu received a Web3 Foundation grant and a Kusama treasury proposal to develop KAGOME. In August 2023, the entire development team spun off from Soramitsu to form Quadrivium, which will continue the development of KAGOME.
About SRLabs
SRLabs is a Security Audit company that will be conducting an initial audit of KAGOME. SRLabs already has years of experience in auditing Substrate, which makes it a perfect fit for checking KAGOME In addition, Web3 Foundation will be participating as technical advisor and will provide mentoring and technical support to ensure the completeness of milestones and conforming the specification.
Comments (4)
Requested
Proposal Passed
Summary
0%
Aye
0%
Nay
Aye (137)0.0 DOT
Support0.0 DOT
Nay (27)0.0 DOT
It is extremely important that Polkadot has multiple host implementations. They provide resilience and decentralization. We have seen this in the past with Ethereum, when one implementation could not produce blocks but others could. I have interacted with Kamil and his team in the past and have always been impressed with their technical chops and professionalism. I am voting Aye on this proposal. Note: all comments are my own personal opinion and do not necessarily reflect the position of W3F.
Hi Kagome, Thank you for submitting this proposal. While this is an ambitious project, we struggle to understand the current demand for this proposal’s deliverables. In the future, we believe Kagome may be useful in the event an actor attempts to brick the Polkadot client for resilience purposes. We also note that this proposal has similar deliverables to your previous submission for ~$400k less cost. That said, we view OpenGov, and in particular the Root and Whitelist tracks, as sufficient frameworks to manage the potential impacts of this hypothetical scenario in the interim. Best, Ivy
Hi @Ivy ,
Thank you for your feedback. I understand that you have concerns about the current demand for Kagome and its deliverables, as well as its cost and ability of OpenGov to manage impact of bad scenario. I would like to address each of these concerns in turn.
Current demand
You mentioned that you struggle to understand the current demand for Kagome's deliverables. However, I believe that there is a clear need for multiple robust and resilient Polkadot clients. In the past, there have been several cases where a bug in a single implementation has caused network issues (e.g halted Kusama parachain block production, or Polkadot dispute storm).
In addition, the role of Parity in the development of Polkadot is decreasing. This means that it is increasingly important to have other teams with the knowledge and expertise to develop and maintain Polkadot clients. Our team is one of a few teams that has this expertise.
Cost
You also mentioned that this proposal has similar deliverables to our previous submission for ~$400k less cost. This is correct. We were able to reduce the cost of the proposal by removing some of the deliverables, such as SASSAFRAS, libp2p optimizations, and storage optimizations. We made these changes in response to feedback from the previous proposal review. While we think, that removed features are quite important, they are not as urgent to implement as features listed in the current propsal.
We believe that the cost of the proposal is fair and reasonable, given the scope of work and the expertise of our team. We are also committed to delivering on our milestones and meeting the needs of the Polkadot community.
OpenGov abilities to manage possible bugs in other implementations
I agree that OpenGov is a powerful mechanism, but I believe that it is not sufficient to mitigate all of the risks associated with this scenario.
In the past OpenGov was a measure to fix the result of a bug, not the root cause of it. If an actor is able to exploit a bug in the Polkadot client to brick the network, OpenGov can only be used if a network can upgrade to a new runtime. However, If there is an issue in the Host level (e.g., consensus or networking layer), OpenGov is powerless to do anything including runtime upgrade, unless there is a fix introduced to the Host implementation.
I hope that this response addresses your concerns and that you will reconsider your vote. Thank you for your time and consideration.