Polkadot protocol proposals (RFC process)

We would like to introduce the RFC process for substantial changes on the polkadot protocol. With this we’re attempting to engage the community more into further developing the protocol and being part on decisions made to it.

This RFC process is our first shot and as we go along we will for sure adapt it more to the community’s needs, if that’s necessary.

In future, for any substantial change to the protocol, especially changes that touches one of the following categories will need to go through the RFC process.

Runtime Environment

  • Changes to Host API, Runtime API or other properties of the WASM environment

Consensus Algorithms

  • Changes to block production or finality algorithms

Networking

  • Changes to the networking protocols

For this, we prepared a template that should be filled out in order to start discussions with the community and maintainers of the protocol. The template should support you in giving your thoughts a structure and also provide enough information to everyone onboarding to a conversation about it.

After submitting your draft, the PR goes under a first review cycle of four weeks. In this period your template might be modified based upon feedback from the maintainers and the community. Significant modifications may trigger a new final comment period. Once agreed upon a decision your proposal will be either accepted, declined or postponed to a later time or once preparation work for this PPP is final. If accepted, you can open a PR for the implementation of your proposed change, which will then again go under review of the maintainers and community until it’s merged.

With that said, please refer to our PPP repo in future and follow the RFC process if you would like to propose a change to the polkadot protocol.

6 Likes

Runtime Environment

  • Changes to Host API, Runtime API or other properties of the WASM environment

What else is defined as the “property of the wasm env”?

I am mainly asking for FRAME/Staking changes that I am personally involved in. I generally try to communicate and gather feedback about both fore implementing big changes, specially the latter. Do they now fit in the same process?

I personally think FRAME is not part Polkadot’s RFC process, but pallets that are in the Polkadot runtime, including to Staking (and moreover governance etc.) could undergo the same RFC process.

1 Like

This is probably not exhaustive, and we should create an exhaustive list, but what comes to mind initially is:

  • Properties of the memory allocator (maybe included under host functions already)
  • Stack size limit
  • Memory limits
  • everything else negotiable in sc_executor::Config and sc_executor::Semantics: Config in sc_executor_wasmtime - Rust
1 Like

After submitting your draft, the PR goes under a first review cycle of four weeks. In this period your template might be modified based upon feedback from the maintainers and the community. Significant modifications may trigger a new final comment period. Once agreed upon a decision your proposal will be either accepted, declined or postponed to a later time or once preparation work for this PPP is final.

This is rather light on the details of the process for acceptance and the definition of ‘maintainers’. The natural choice of maintainers is the on-chain fellowship IMO.

Yes that is right. For now RFCs are mainly on the host part, because others need to implement this (which isn’t the case for the runtime). So, this is a good point to start with. However, having a similar process for the runtime will probably be required at some point as well. Let’s see what we learn by doing the RFC process for the host and how we can include the runtime at some point :slight_smile:

Exactly. The entire process and what it includes is kept a little bit opaque for now. We clearly need to come up with such a list and I also know that people already “requested” this. This will also make it crystal clear on what needs to go through a RFC to be changed. However, I wanted that we have something to start with. The discussion on what should be included can then maybe also start as some kind of RFC.

Yes! We should have made this more clear, it will be the fellowship :slight_smile: We just need to come up with some criteria on who is allowed to vote etc.

1 Like

Can you include some detail on how this relates to Substrate?

1 Like

I had some note about my thoughts of Substrate RFC Pallet repo re-structure - HackMD

1 Like

Thanks for sharing those ideas. Ack your point about everyone being ‘idea-rich’ & ‘time-poor’. However, a middle ground might be to post/track those ideas as W3F-RFP’s.

Still wondering if these proposals get implemented via Substrate, are to be pushed to Substrate separately or are independent of Substrate?

I think the bigger question here is what we consider the Polkadot Protocol.

For us in spec it is pretty clear that it is anything that concerns the host, so maybe we just have to communicate that better. IMHO the protocol could not care less if you use FRAME or something else inside the runtime and I do not think we should limit ourselves to this either.

So to answer your question, any change in the way the runtime integrates with the host that requires changes to the host itself should require an RFC.

Until we can find a trustless way to integrate the fellowship with a process like this, I do not see why we should not be honest and state that this is a GitHub-centric process for now.

I agree however that we should start discussing how to determine who should be a maintainer. Given however the extended scope of such a discussion, the need to start a process quickly outweighed the need to integrate it with the still experimental fellowship for now.

I also should mention that there has been no clear road to onboard the existing staff that has been maintaining the protocol spec so far into the fellowship, so this will also need to be part of the discussion going forward.

For a start we could just do some on chain vote and someone with merging rights merges based on the outcome. Not that complicated. For the long run we can use smoldot with GitHub - paritytech/pr-custom-review: GitHub Action for complex pull request approval cases that are not currently supported by the Branch protection feature in GitHub. to allow the fellowship members to approve directly.

Substrate is used to provide the Parity Polkadot node implementation. So, everything that is accepted as a RFC for Polkadot will also be implemented in the Parity Polkadot node code base or in Substrate if it is more fundamental. Not that complicated actually.

However, other node implementors will also need to add these changes to their node implementation to stay compatible with the protocol.

Agreed, not complicated.

So Substrate/other-node-implementors will need to come up with their own RFC process, or live with Parity deciding what belongs in Substrate?
Which is, actually, just the current state of play - correct?

To avoid doubt:
It would be out of scope of the Polkadot Protocol Proposals RFC process to propose moving part of the Parity Polkadot Protocol node code base into Substrate - because that is an implementation detail, and not a protocol detail.

Correct?

Substrate is a Parity product and it will stay this way AFAIK. So, Parity decides on what it adds to Substrate etc.

However, when there is a Polkadot RFC that requires changes in Substrate, we will implement it to support our Polkadot implementation.

Yes.