A path forward for Penumbra Improvement Proposals (UIPs)

UIPs - Penumbra Improvement Proposals
1

Hello all!

I wanted to address this new section of the forum specifically for how Penumbra ecosystem members might propose developing the protocol. We at Radiant Commons wanted to propose a method for issuing Penumbra Improvement Proposals (UIPs) as a result. It could be a straightforward method that the community can converge on agreement as a standard procedure - I want to offer this first version as a potential path to be taken, then deliberate over what we think is the correct one.

My proposed path for a UIP could be as follows:

  1. A proposal starts in the forum
    1. A numbered UIP could be issued here in the forum, following the sequence number of previous UIPs submitted - meaning that if there is a previous proposal numbered UIP#X, the subsequent proposal could be listed as UIP#X+1.
    2. The Title of the Proposal could detail some nominal amount of information about what is being proposed, i.e. UIP#X - Proposing ABC changes to XYZ module as a part of the Penumbra Protocol
    3. The Proposal could articulate clearly up front whether or not it is consensus-breaking or not by being listed as one of the two following types:
      1. Client-side Only - Not a consensus-breaking upgrade or modification to the protocol and thus only specific to the software that interacts with the Penumbra protocol, i.e. not state-breaking.
      2. Protocol Upgrade - A consensus-breaking change that will require a coordinated upgrade by validators in order to advance the state of the chain with new parameters and software in place.
        1. This second type could also require an on-chain signaling proposal as a later step in the process wherein staked UM can be used to signal agreement to the proposed protocol changes.
    4. The Proposal could detail what the proposed changes and improvements are in detail, I propose that these follow a traditional but stripped down Requirements format entailing:
      1. What is the problem that the proposal is addressing
      2. Why is this important to address
      3. What is the proposed solution and how does it improve upon the current situation
      4. How could the solution be approached
    5. Once there is rough consensus on a) what the form of the improvement should take and b) whether or not the Proposal should move forward, discussion over implementation of the Proposal could be moved into a Github repository that can be created in the Penumbra Github directory, wherein the rest of this process is followed
  2. UIP Github Repository (to be created)
    1. Once rough consensus in the UIP section of the forum has been reached, an issue could be created within a UIP repo in the Penumbra github
    2. The naming should correspond to the UIP#, i.e. UIP#X should correspond to an issue titled by the same name
    3. The issue could detail the technical implementation details that would then be deliberated upon in the issue in the form of comments
    4. Consensus over how to implement the technical aspect of the upgrade could then be reached the issue corresponding to an UI, and the software developed for staging
    5. Once the software is developed and is accepted as complete, it could be merged with the main corresponding branch of development for the protocol unless it is consensus breaking in which case:
      1. if the change is consensus breaking, a signaling proposal corresponding to the UIP could be issued on-chain with an explicit block-height in mind in anticipation of a new version of the software being adopted by the validators running consensus for Penumbra. This on-chain proposal should correspond to the original UIP numbering, i.e. if the originating proposal is UIP#X, the on-chain proposal should be listed as UIP#X.
      2. If it is clear that a consensus-breaking proposal will pass, validators could adopt the new software package developed as a result of the on-chain Proposal at the corresponding blockheight.
  3. Once this process has been completed, confirmation of the Proposal’s passage could be mentioned in a final comment on the forum post, detailing its passage.

Our hope is that we can agree on either this or a similar process being that which Penumbra can use for improving the protocol’s software - it is by no means a hard-and-fast set of rules. Either way, Radiant Commons would like to see this process started so that we can see improvements to Penumbra follow a loose and decentralized consensus procedure prior to their implementation.

I look forward to everyone’s feedback! This is just a proposal for what we could do, I’d love to see us agree on what could make more sense than what I’ve written above.

1 Like
2

This sounds good, one suggested tweak:

I don’t think this will be workable, since it means there are multiple sources of truth about the numbering. Instead, the forum should have un-numbered Pre-UIPs, and at the point that the UIP moves from a discussion stage to a specification stage, it should get a number by submitting a PR to the UIP repo marked as “draft”.

This means the forum posts should be “Pre-UIP: TOPIC NAME” for early discussion, then the UIP itself is in the version controlled system with PR reviews etc.

3

I initialized a new Github repo modeled after the Celestia Improvement Proposal process, and initialized UIP-1, UIP-2, UIP-3.

UIP-1 is the UIP process itself; I lightly amended the Celestia process to match Penumbra, and set it as an initial starting point. However, it’s a living spec, so it can be amended based on discussion in this forum thread if there are any suggested changes or alterations of the process.

In my opinion, starting with an existing process has the key advantage that we can follow the lineage of successful decentralized technical coordination: CIPs are derived from the EIP process for Ethereum, in turn derived from the Python Improvement Proposal process for Python, and so on.

Here’s the repo link:

There can be a rendering of the contents hosted at https://uips.penumbra.zone soon, it just needs to have Github actions configured.

1 Like