Change max_proposal_period parameter to 260

[Gavin]

Proposal

This is a proposal to change max_proposal_period parameter to 260.

The Rust code used to make the wasm is here: https://github.com/Luminara-Hub/govproposals/blob/main/testnet_max_proposal_period.rs

@brentstone has reviewed this code, @spork.Knowable has tested it locally. Now we are testing the parameter change on the Housefire testnet: https://explorer75.org/namada-housefire/proposals/23

Context

At the beginning of this week, I started a discussion post about updating the max_proposal_period parameter to 260.

Luminara committed to making a PGF proposal for the latest Donor Drop allocations that waits a 60-day grace period before executing and distributing the allocations, but max_proposal_period is 84 epochs (21 days), and 260 (65 days) are needed. We (Knowable) would like to increase max_proposal_period to 260–not just to fulfill Luminara’s commitment, but for the betterment of Namada at large.

History

When Knowable proposed the mainnet parameters, we chose 84 epochs (21 days) because that’s the longest we could imagine the community needing for a governance proposal. We hadn’t anticipated that there could be novel ways of using enactment delays to distribute PGF.

The benefit of increasing this parameter is that we could make a commitment in an up-front governance proposal, while having more control over delaying the proposal execution timing.

Potential issue

Someone could make a governance proposal with a very long voting period

• this seems unlikely–at least until it’s worth 2000 NAM to advertise something using a governance proposal
• a future solution could be a new max_proposal_voting_period parameter to complement the existing min_proposal_voting_period, and then we could constrain the voting period without constraining the enactment delay

There have been no concerns from the folks in the Validator Circle, the replies on the forum post, and in messages with @brentstone and @cwgoes from Heliax.

[cwgoes]

I thought a bit about potential concerns or attacks and don’t see any major ones here. Let’s do it!

[Gavin]

Updates:

1. max_proposal_period was successfully changed to 260 on Housefire testnet via testProp23. testnet json is here; Rust code is here
2. testProp24 was successfully launched on Housefire testnet, which includes a 240-epoch grace period

We are preparing to launch this proposal on mainnet
We will use this json file: https://github.com/Luminara-Hub/govproposals/blob/main/mainnet_max_proposal_period.json

[Gavin]

Prop15 has launched, voting to begin in just over 5 hours from now when Epoch 501 begins.

Voting for validators will last until the end of Epoch 512, so in total will have 72 hours to vote

[ChainflowPOS]

All for extending the proposal period, but I do think we should soon implement a longer voting period minimum. It currently feels like the windows are too short, considering the validators can only vote within the first 2/3rds of time for the proposals.

[Gavin]

agree! there’s a social commitment to increasing the minimum to 7.25 days in the Phase 5 proposal, which would be just about 5 days voting min for validators

Mainnet parameter discussions: Knowable's proposal

Thanks @brentstone! I think I can say that we (Knowable) are ready to proceed with these parameters. Noting that: max_proposal_code_size (cc @Rigorous) turns out to be what we intended, being denominated in bytes in the code (but good catch, Rigorous! the docstring had mistakenly noted kb). Governance voting period would only be 3 day minimum voting at launch, which we think that should later increase to 7.25 days at the same time that transfers are enabled. Governance grace period would be 0…

[Gavin]

Prop15 has passed

Thanks to Namada voters