decoupled features: add addendum on MinBaseFee and why toggles don't always make sense #323
Conversation
|
|
||
| Is it possible to specify such features in a _relative_ manner? For example, we could simply state that MinBaseFee adds an extra byte to the end of `block.extraData`, regardless of how many bytes it has. This seems like a very bad idea, since the block schema is part of the public API of the OPStack, and it would make building against that API extremely painful if the semantics of that schema depend on the ordering of this feature compared to other features. Getting from a relative specification of the hardfork to an absolute one (as is necessary for consumers of the API) would then require a much greater mental overhead and would be error prone. | ||
|
|
||
| While features may be toggled entirely independently, but those that modify APIs may not be. In those cases, we are left with having to specify an ordering of certain features, which means optimistically tying them to a specific hard fork. It is inevitable that rescheduling or disabling such features will be painful, and unfortunately feature toggles aren't really helping in that scenario. |
There was a problem hiding this comment.
we are left with having to specify an ordering of certain features
I think there is another option: if there are conflicting combinations of feature flags, return an error. For example, if two features modify block.ExtraData in the same position, then it is an error for them both to be enabled. This technique can be used in development, punting decisions around feature ordering to allow maximum flexibility in hardfork planning.
There was a problem hiding this comment.
punting decisions around feature ordering
In practice, this means introducing a "reconciliation" or "ordering" step before shipping the hard fork to resolve conflicts.
Let's say there are two independent developers implementing conflicting features A and B behind feature toggles. When it comes time to decide on the ordering, there are four outcomes:
A before B |
B before A |
|
|---|---|---|
| Same Hardfork | Merge toggles into a single toggle: AThenB, and update the spec for B accordingly |
Merge toggles into a single toggle: BThenA, and update the spec for A accordingly |
| Different Hardfork | Remove the feature toggle for A, and update the spec for B accordingly |
Remove the feature toggle for B, and update the spec for A accordingly |
By adopting this "reconciliation" strategy that makes ordering decisions by merging toggles at the latest possible time in the development cycle, I think we can preserve the benefits of feature toggles outlined in the original design doc without making exceptions for changes to the public API (which most features will likely do anyway).
There was a problem hiding this comment.
It's like embedding version control in the code, which is probably fine in our case since I assume there's consensus that that long-lived feature branches are untenable. (fwiw I would be in favor of just using version control and feature branches, but I won't die on that hill)
No description provided.