The Besu team is thinking about Ethereum's next upgrade through 4 different, but complimentary lenses: What do we need to accomplish with maximum coordination. What can we accomplish as independent teams, with eventual consistency. What items deserve planning. How would we change the way we work. Fusaka Should Include: PeerDAS - scaling the base layer throughput and providing far greater data availability for rollups is a requirement for Ethereum to stay market competitive. As an execution client, we expect to have much less work to do for PeerDAS than our frens on the consensus client teams, but agree to treat that work as the highest priority. EOF - Ethereum deserves more than a mere binary format, and developer tooling deserves richer metadata about smart contracts. Users deserve a modicum of contract validation at the base layer. At some point, the inability to remove or replace opcodes in a non-breaking fashion becomes untenable, leading to kruft, which is worse than complexity. The EVM has a forced conversion problem. Solving it is worth the work that EOF requires.In order to mitigate the loss of workarounds used to transfer value between contracts, we suggest including EIP - 5920: PAY opcode at the same time that EOF is delivered.

EIP authors and champions are an important force for Getting Shit Done. They are the ones who wrangle all the other devs and really direct our effort and energy. When a scheduling opportunity presents itself, we expect them to pounce on it, as proved by recent jokes about our inability to ship a “small fork” (this hasn’t been done since the days of the difficulty bomb). Lets call this force Ethereums Ambition. Currently the only counter force to the Ambition is when the content of a hard fork “feels too big”, which is subjective and an inherent Appeal to Authority. This is where Ambition meets (perceived or predicted) Reality, and those with the most experience and history tend to have the most seasoned intuition on what will “fit”. Things that "won't fit" are likely to take much longer than our hoped for 1-2 hard forks per year. Some aspects of this tension between the Ambition and Authority are features, some are bugs. I think the open, subjective, free form discussions of what is most important to Ethereum at the moment, and in the foreseeable future, are good and effective and working as designed. We all know “feels too big” when we see it, but we also have differing ideas on what SHOULD fit, and different priorities on what is best for Ethereum next. This to me looks like a recipe for stalemate. When more EIPS are CFI’d than will fit, we search for a solution by simply grinding each other down with the repeated, sometimes stale, conversations. We can joke about our lack of restraint, but that’s on us. We are the only ones who can control that, and are thus responsible for it. I think we can develop a more efficient, objective, repeatable process for scheduling so we can leave some air in the room for the deeper problems.

-or- Modularization: No really. We should do this. Situation The 24.5.0 release, which dropped on 5/14 was initially scheduled as a 24.3.1 release at the end of March. It took 7 weeks and 4 release candidates before we were confident that the issue had been addressed sufficiently enough to warrant a release, and wasn't going to make things worse. A full analysis of this situation is beyond the scope of this recommendation, however reading the corresponging post-mortem is strongly suggested as background for this strategy. During this release cycle, we experienced regressions due to multiple peering and syncing factors, some of which interacted with each other. This sub-optimal behavior was present in 24.3.0 and was eventually noticed by the community, after which a speedy response was impossible. Complications lack of observability - it still remains difficult to trace each devp2p handshake and/or disconnection. The sync pipelines are even more opaque, making collaboration between devs very difficult. lack of tooling - we don't have any ethereum specific diagnostic tools that work with besu for the peering, rlpX, and syncing domains. Developers are limited to using general purpose tools like debuggers and logging.

In many tabletop games, there are often gameplay mechanics that only require a success or failure result. Boardgames, roleplaying games, and miniatures wargaming often have the notion of a "target number." If you hear phrases like "hitting on threes" or "four +es" around your table, you are experiencing one of these mechanics. This allows for a unique situation; to play the game, you only need to know if you have succeeded or failed when the dice is rolled. The actual value on the die only matters in the context of the success criteria. Once the players know if it is a success or failure, they can proceed with the game. The value that is rolled is not strictly relevant. If we had a device that could determine the result of a roll in success/failure terms, we could withold the values on the dice from the user. This gives us a source of entropy that can be used, but not revealed. The game mechanics act as a filter or obfuscation layer. Examples: Shadowrun is a tabletop RPG set in a fantasy cyberpunk universe. All skill checks require the player to roll a number of six-sided die (D6s) and count how many were fives or sixes, which are considered hits. The players is trying to maximize the number of hits, not any particular die roll. Bolt-Action and its Weird-War sister Konflikt '47 are miniature wargames with similar rulesets. A key part of the combat flow is determining how hard it is to hit your target. A unit may fire on another, and only score hits for dice that come up four or more, depending on conditions like range, cover, etc. In this case, again, players only need to know the quantity of successes; dice rolled which met or exceeded the target number.

Branch Based Releases (commit.py) Besu currently does branch based release strategy. Regardless of the branch being released from, during a release a new release branch is created and pushed to origin. This triggers an additional (arguably unnecessary) build PR for the merge back to the “releasing branch” (master, release-, etc). It also forces a “quiet period” where we do not / cannot merge to the branch-to-release. The branch based flow also submits an additional post-release PR to merge the next project version property (so that build artifacts are -SNAPSHOT). Lastly, this process requires at least 2 contributors to complete the release process because 2 rounds of PR approvals are necessary to proceed. This may or may not be a feature, more on this later. Overall, the branch flow requires 3 CI builds and 2 PR approvals to complete a release. It seems that this flow was built to support quarterly releases, but was generalized for regular releases also. Tag Releases (tag.py) Overhead savings Tag releases are commit based rather than branch HEAD based. When releasing from master, there is no branch management, PRs or approval required to release. There will be a single build of the release tag by circle-ci. The release process is hands-off and automated all the way up to the release on github. This is a substantial time savings and much lower friction compared to the branch based release strategy.