Try   HackMD

The Besu team is thinking about Ethereum's next upgrade through 4 different, but complimentary lenses:

  1. What do we need to accomplish with maximum coordination.
  2. What can we accomplish as independent teams, with eventual consistency.
  3. What items deserve planning.
  4. 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.
    • The Besu team has considered recent protests against EOF, but has not found them compelling enough to warrant revoking its SFI status in the Fusaka hardfork.

There are some operation repricings that we consider low hanging fruit, which we would like to see further researched for inclusion in Fusaka. We do not consider as necessary as PeerDAS and EOF are.

We Can Also Work On:

Forkless upgrades! Not all upgrades need to be coordinated at the protocol level, but they do require work from teams, which have finite bandwidth. We think we have capacity to pursue a few of them at the same time as the upgrades above.

  • Gas Limit Increase - 60Mgas/block and beyond. We should also have a regular, social process to consult with validators so we are aware of their capacity for future increases, especially solo stakers. When we see opportunities for growth we should follow close behind them.
  • eth/69 and eth/70 - these are wireline protocols that can be adopted without a hardfork, but still require network simulation and testing. These should be pursued and deployed if approved by testing and devops teams.
  • pre-merge history drop - to fully take advantage of eth/70, we are building the client features for users to drop blockchain history prior to the merge. The storage savings will be significant.

What to Plan:

We believe the theme of the Glamsterdam release should be MEV mitigation and stateless.

MEV Mitigation:

MEV mitigation includes censorship resistance more broadly. While the consensus layer continues to pursue the next phases of scaling, we believe the execution layer needs to focus on the still-existential threat to decentralization that is MEV.

  • ePBS and FOCIL - while these are primarily consensus layer features, we stand by to facilitate them with whatever is needed from the execution layer, because…
  • Encrypted Mempools or Sealed Transactions: there are multiple designs in progress that aim to mitigate value extraction through manipulating transaction ordering. Most of them rely on some sort of proposer-builder separation as well as a form of inclusion lists. This should be a research priority that happens alongside ePBS and FOCIL.
  • EIP-7793 : TXINDEX and EIP-7843: SLOTNUM opcodes - Making the EVM aware of where an originating transaction was positioned in a block, or on the chain, may be useful for the development of on-chain anti-censorship protocols. This seems like a low risk tool to provide to developers, that potentially has a mysterious and important upside; an anti-MEV playground.

Stateless Ethereum:

Besu is actively working on various topics around stateless . This includes development for the transition from the Patricia Merkle Trie to more stateless-friendly structures like Verkle or binary tries.

Additionally, we are working to make Besu compatible with both stateless and stateful modes, giving users more flexibility in how they operate their nodes. Discussions are ongoing within the Ethereum community on how to implement stateless, and Besu is closely following these while continuing to advance its own work.

Our goal is to ensure Besu remains a strong and adaptable Ethereum client, ready for the evolution towards stateless execution.

The Meta

Ethereum is a decentralized network implemented in decentralized, open-source software, built by decentralized software development teams.

We are playing on hardmode.

Our development processes are necessarily unique, as we are on the frontier of known software development lifecycles. Upon reflecting on Pectra, we think that we need a better understanding of failure modes and their repercussions.

Good progress is being made in pushing as much testing "to the left" as possible; we are starting to gate client entry to testnets by their passing of common test suites. We believe the next step is also the ability to roll-back and re-run testnet failures, to validate that our understanding of a problem is correctly mitigated. Good progress is also being made in formalizing the social process around the various steps of the EtherSDLC™, and considering specific roles that devs should play, and assigning rights and responsibilities accordant with those roles.

The failure of the Pectra upgrade on Holesky illustrated a mistake in our thinking; testnets are not the same thing as pre-production environments. While core devs think of networks like Holesky as testnets, fit for breaking, applications and service providers think of them as where they test their deployments before going to production. This incongruity needs to be corrected, so both audiences may be served during our development lifecycle.

Tooling that speeds up diagnosis of blockchain forks remains very high leverage, and is likely producible by a wide array of software developers, who may not necessarily require the same depth of Ethereum specific knowledge. Broad bounties for such tooling should be invested in; it will make those specialists more efficient.

Consensus mechanisms need rollback features. We believe these can be researched and implemented in ways that preserve credible neutrality, and we leave that research to our frens on the consensus layer teams. Things like attestation kill-switch APIs or temporarily pausing finalization during hardforks are all ideas that have merit, and we encourage their entertainment.


Two hardforks a year.   LFG.
                         - The Besu Team

Last changed by 
 
Justin Florentine
10
3
562

Read more

The Interminable Ambition of Scheduling

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.

Sep 26, 2024
Peering Refactoring

#Peering Refactor#

May 28, 2024
KZGamer - summoning Dankshard from the tabletop.

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.

May 8, 2023
Besu Tag-based Release in GAR-e

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.

Nov 22, 2021
Read more from Justin Florentine
Published on HackMD