Try   HackMD

Vitalik's Minor Changes Wishlist

Out of scope

  • Data availability sampling and other sharding-related changes
  • Light client processing
  • The merge

Revamp effective balance / current balance accounting

Remove the current concept of effective vs current balance. Instead, keep (i) the balance inside the validator struct, and (ii) a counter of "duties fulfilled". Accounting for (ii) would be very simple: did you get the correct source? Add 1. Correct target? Add 1. Timely? Add 1.

Every 256 epochs (can be staggered), we update the validator balance based on the duties fulfilled count, and reset the duties fulfilled count. The inactivity leak is also implemented at this stage. Note that this comes at the cost of some coarseness: if an inactivity leak starts halfway through a period, offlineness before and after the start of the leak is equally penalized (if we want to remove this entirely, we could also have two duties counters, one for leaking periods and one for non-leaking periods).

This lets us remove hysteresis, and additionally makes it much easier to implement https://github.com/ethereum/eth2.0-specs/issues/2125/mp3 juice (quadratic leak per validator) and https://github.com/ethereum/eth2.0-specs/issues/1340/tubidy (optimized empty epoch processing).

Further down the line, the simpler math of duties accounting potentially makes it easier to do cryptographic optimizations. The most extreme is ZK-proving this entire part of the transition, but there is also a simpler path: use a Kate commitment instead of a Merkle tree to store duties, so duties accounting would only require ~2 ECADDs, not an ECMUL, per validator, and could be done in real-time instead of waiting for the end of an epoch!

Sidenote: if we do Kate commitments, then it becomes more challenging to have a

240-size array, so IMO we should consider reverting back to the older approach of assigning new validators the earliest unoccupied index instead of just extending the array forever.

Quadratic leak per validator

Implement https://github.com/ethereum/eth2.0-specs/issues/2125. Increases "friendliness" to honest-but-imperfect validators during a leak (eg. a validator that is online 95% of the time during a leak where malicious validators lose 40% would lose 0.1% of their deposit instead of 2%).

Optimize empty epoch processing

Implement https://github.com/ethereum/eth2.0-specs/issues/1340/y2mate (modified as appropriate for the new duties accounting). Ensures that non-canonical chains with few proposers and many skipped slots are easier to process.

Create single data structure for previous / current data

Right now (in phase 0 + future proposals) we have many pairs of the form (current_epoch_thing, previous_epoch_thing). This creates unnecessary code duplication. Instead, we should have a struct ActiveEpochData which contains all of the data that is stored in these structures, and in the beacon state we simply have current_epoch_data and previous_epoch_data.

Not everyone validates if there are >1M validators

In the event that >1M validators are active, come up with a way to randomly select some to be active and turn the others off (ie. don't give them rewards and allow them to drop offline). This serves two functions:

  1. Reduces theoretical max issuance to ~1M/year
  2. Reduces theoretical max load that clients need to handle by 4x

One potential path to implementing this is https://github.com/ethereum/eth2.0-specs/issues/2137

Last changed by 
 
vbuterin
1
1
630

Read more

A quick barycentric evaluation tutorial

One powerful technique when working with polynomials is taking a set of evaluations of that polynomial and using that directly to compute an evaluation at a different point. For example, if $P(x)$ is a degree-100 polynomial, you can use the evaluations $P(0), P(1) ... P(100)$ to directly compute $P(101)$, or $P(1247130)$, in $O(N)$ time, without ever reconstructing the polynomial. This post describes how this is done See also, this earlier and more detailed paper by Oxford researchers on the topic: https://people.maths.ox.ac.uk/trefethen/barycentric.pdf smashy road General technique Let $P(x)$ be the polynomial, and $x_1 ... x_N$ as the set of points for which we have evaluations of $P(x)$. Call these evaluations $y_1 ... y_N$. Think of $P(x)$ as a linear combination $\sum_i y_i L_i(x)$, where $L_i(x)$ is the polynomial that equals 1 at $x_i$ and 0 at all the other x-coordinates in the set. Now, let us explore how these $L_i$ can be computed. Each $L_i(x)$ can be expressed as:

Mar 8, 2025
Pragmatic destruction of `SELFDESTRUCT`

This post describes some reasons why the SELFDESTRUCT opcode brings more harm than good to the Ethereum ecosystem, and so should be neutered or removed in some way. To deal with the existing contracts that use SELFDESTRUCT, I propose some ways to eliminate the harmful aspects of SELFDESTRUCT with minimal disruption.

Feb 28, 2025
Untitled

--- eip: TBD title: Optional access lists author: Vitalik Buterin (@vbuterin), Martin Swende (@holiman) discussions-to: TBD status: Draft type: Standards Track category: Core created: 2020-08-29 requires: EIP 2718; Gas cost increases https://notes.ethereum.org/@vbuterin/BkrNbeAfD

Dec 31, 2024
A few paths to statelessness and state expiry

Two paths to a solution exist, and have existed for a long time: weak statelessness and state expiry: State expiry: remove state that has not been recently accessed from the state (think: accessed in the last year), and require witnesses to revive expired state. This would reduce the state that everyone needs to store to a flat ~20-50 GB. Weak statelessness: only require block proposers to store state, and allow all other nodes to verify blocks statelessly. The good news is that recently, there have been major improvements on both of these paths, that greatly reduce the downsides to both: Some techniques for how a ReGenesis-like epoch-based expiry scheme can be adapted to minimize resurrection conflicts Piper Merriam's work on transaction gossip networks that add witnesses to be stateless-client-friendly, and his work on distributed state storage and on-demand availability Verkle trees, which can reduce worst-case witness sizes from ~4 MB to ~800 kB (this is definitely small enough, because existing worst-case blocks that are full of calldata are already 12.5M / 16 ~= 780 kB and we have to handle those anyway). See slides, doc, code.

Jun 4, 2024
Read more from vbuterin
Published on HackMD