Additional "freeze" stage for amendment process

Hello All,

Regarding the current four-phase amendment process.

I can imagine a situation where we are a couple of blocks from the end of the promotion phase and, hypothetically, we may be 0.001% away from reaching a quorum.

In this situation, we don’t know if the chain will migrate to the new protocol until the proverbial 11th hour. Teams who build tools/products or operate services on top of Tezos would need to coordinate around a significant event that may not happen.

If we create a fifth and final stage in the amendment cycle called, for example, “freeze”.

If the promotion reaches quorum, then we would have a “freeze” period of perhaps two weeks. This time would allow developers and infrastructure operators to plan and prepare for the protocol transition knowing for sure that the new protocol will come into effect at a specific block height.

If the proposal fails to reach quorum in the promotion phase or gets voted down in the promotion phase, the cycle resets back to the proposal phase immediately.

9 Likes

Depending on the complexity of the protocol upgrade the teams involved in tooling as well as the ones building a product on Tezos will inevitably have to start their development cycle as early as possible. Having a “freeze” stage for two weeks would most often not be enough time to complete the development process but it might provide some leeway for the teams when they’ll have to come to a decision and commit.

Here’s a Gitlab issue based on exactly what you’ve described - https://gitlab.com/cryptiumlabs/tezos/issues/26

Looks like some work has already been done for it, too!

3 Likes

Awesome! Thanks for finding this, I was not aware.

Hi @pascuin

I tend to agree that two weeks is too short. As a client library developer, we would (and we have done for Babylon) speculatively add support for the next protocol on the presumption that it will become the new economic protocol. With this view, we have a lot more than two weeks, but we do get a final two weeks to firm things up (less for us as library devs as we need to release earlier so that downstream builders get time to upgrade to our new libraries.)

This is a bit bothersome in that we might end up throwing that work away if the proposal ultimately fails, but this is the negative take. The positive take on this is that we (builders generally) may have helo surface issues in the new protocol sooner because we started building on the new protocol earlier. I think this was the case for Babylon 1.0 V Babylon 2.0.

If we make the period too long, developers such as ourselves may wait for the final freeze phase to do any work. This is not good, as the builder’s building activity help find edge cases, bugs or sharp corners in a new protocol.

The sooner we start building/integrating the better for the protocol. The only downside I see here is that it’s labour intensive to build against new protocols earlier on in the process.

TLDR;

Having a longer freeze phase would be good IMO, but I worry about creating an incentive for developers and builders to wait to build on the new protocol until the end of the process.

1 Like

In terms of tooling development I agree that this should be started as soon as it starts to become clear that the proposed protocol upgrade is favoured. But also there we have to keep the resources of these individual teams in mind.

I see the problem more with projects building on Tezos as with the changing landscape they need to be aware of every protocol upgrade and the potential changes that might impact their service thus investing maintenance effort and not evolving their product.

All in all I agree that having such an additional period that is also shorter than a the other proposal stages makes sense and as we’ve seen there has also been development effort to that regard.

I definitely would be in support of adding a post-promotion phase to give people time to complete their migration work once they have certainty promotion passed.

I don’t think it should be too long as I agree that we don’t want to encourage people to wait before they start their migration work. And for library devs it would be optimal to have a reasonable beta version complete early enough that users of the library could use it to test their solutions during the migration phase.

Longer term we might want to lengthen our phases, but for now a short sanity check post promotion makes a lot of sense.

It would make sense to let the proposal export the length of this period. That way, an upgrade that make changes requiring a lot of adaptation of the tools can export a longer period.

6 Likes