From 33667f1120633f020fcafb90eaed33dc80816237 Mon Sep 17 00:00:00 2001 From: geoknee Date: Wed, 13 Aug 2025 17:06:22 +0100 Subject: [PATCH 1/3] decoupled features: add addendum on MinBaseFee and why toggles don't always make sense --- protocol/decoupled-features.md | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/protocol/decoupled-features.md b/protocol/decoupled-features.md index f6986362..686cf76d 100644 --- a/protocol/decoupled-features.md +++ b/protocol/decoupled-features.md @@ -238,3 +238,36 @@ prior to implementation. [kona-overrides]: https://github.com/op-rs/kona/blob/main/bin/node/src/flags/overrides.rs [op-overrides]: https://github.com/ethereum-optimism/optimism/blob/develop/op-service/flags/flags.go#L16-L24 + + +# Addendum +The "minimum base fee" (h.f MinBaseFee) feature was the first feature which we tried to apply the above philosophy to. +Some unforeseen issues cropped up which are recorded here to provide extra guidance on how +to implement decoupled features in future. + +The implementation of the MinBaseFee feature calls for i) some business logic changes and ii) some API and data structure +changes. It so happens that the business logic changes can be considered mostly independently of any other feature or +hardfork: Right at the end of the block sealing process, just modify an existing numerical field according to some +modified rules. However, the API and data structure changes can _not_ easily be specified (let alone implemented) without +some dependence on other features. Moreover, without some radical reworking of how we specify the protocol in general, +when specifying MinBaseFee we open up the possibility that other features need to either + depend on it or be a dependency of it themselves. + +Looking at the changes in detail will illuminate the point. MinBaseFee requires a modification to the block extraData field. +If we can commit to including the feature as the _first feature_ in Jovian, we can specify MinBaseFee by +extending the Isthmus block schema. This allows us to specify MinBaseFee by introducing an additional byte at offset 9 to +`block.extraData`. + +So far so good, but this is working entirely under the old paradigm where features are tightly coupled to forks. This runs the +risk that it would be difficult to reschedule or disable the feature. +Can a feature toggle help, here? Well, if we lean into that idea then we can't safely specify the feature +as we did above. This is because we could imagine another (fictional) feature, call it MaxBaseFee, +which _also_ seeks to extend the `block.ExtraData` field with a new byte of data. The ordering of the two features implies a different byte offset for each of the minimum and the maximum base fee byte. + +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 should 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. + + + + From 734f48859e87020dd7cf42f615b4dcebfcd0d10c Mon Sep 17 00:00:00 2001 From: geoknee Date: Wed, 13 Aug 2025 17:24:27 +0100 Subject: [PATCH 2/3] add link --- protocol/decoupled-features.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/decoupled-features.md b/protocol/decoupled-features.md index 686cf76d..29c5e466 100644 --- a/protocol/decoupled-features.md +++ b/protocol/decoupled-features.md @@ -245,7 +245,7 @@ The "minimum base fee" (h.f MinBaseFee) feature was the first feature which we t Some unforeseen issues cropped up which are recorded here to provide extra guidance on how to implement decoupled features in future. -The implementation of the MinBaseFee feature calls for i) some business logic changes and ii) some API and data structure +The [specification of the MinBaseFee feature](https://github.com/ethereum-optimism/specs/pull/747) calls for i) some business logic changes and ii) some API and data structure changes. It so happens that the business logic changes can be considered mostly independently of any other feature or hardfork: Right at the end of the block sealing process, just modify an existing numerical field according to some modified rules. However, the API and data structure changes can _not_ easily be specified (let alone implemented) without From ea89d93f0f7839f8e12d4a3f6b05d29ff836b617 Mon Sep 17 00:00:00 2001 From: geoknee Date: Wed, 13 Aug 2025 17:25:38 +0100 Subject: [PATCH 3/3] tweak --- protocol/decoupled-features.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/decoupled-features.md b/protocol/decoupled-features.md index 29c5e466..772ba896 100644 --- a/protocol/decoupled-features.md +++ b/protocol/decoupled-features.md @@ -266,7 +266,7 @@ which _also_ seeks to extend the `block.ExtraData` field with a new byte of data 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 should 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. +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.