Notice: Polkadot has migrated to AssetHub. Balances, data, referenda, and other on-chain activity has moved to AssetHub.Learn more

View All Big Spender
Discussion#1953
Referendum#201

KAGOME – the C++ implementation of Polkadot Host milestone 2

inBig Spender
2 years ago
treasury
infrastructure
Executed

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:

To learn more about KAGOME and the importance of client diversity in the Polkadot ecosystem, you can:

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
  • BEEFY
  • 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)

2 years ago

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.

2 years ago

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

2 years ago

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.

PleaseLogin to comment

Requested

DOT
168.43K DOT

Proposal Passed