Try   HackMD

EIP draft: SET_INDESTRUCTIBLE

---
eip: <to be assigned>
title: SET_INDESTRUCTIBLE opcode
author: Vitalik Buterin (@vbuterin)
discussions-to: <URL>
status: Draft
type: Standards Track
category: Core
created: 2020-08-30
---

Simple Summary

Add a SET_INDESTRUCTIBLE opcode that prevents the contract from calling SELFDESTRUCT.

Specification

Add a context-wide variable locals.indestructible (ie. a variable that lives in the same "space" as memory, stack, PC…), initialized to False.

Add a SET_INDESTRUCTIBLE opcode at 0xA8, with gas cost 2 (G_base) , that sets locals.indestructible to True. If in the current execution context locals.indestructible is True, the SELFDESTRUCT opcode throws an exception.

Motivation

The intended use case would be for contracts to make their first byte of code be the SET_INDESTRUCTIBLE opcode if they wish to serve as libraries that guarantee to users that their code will exist unmodified forever. This is useful in account abstraction as well as other contexts.

Unlike EIPs that disable the SELFDESTRUCT opcode entirely, this EIP does not modify behavior of any existing contracts.

Forwards Compatibility and Security

This breaks forward compatibility with some forms of state rent, which would simply delete contracts that get too old without paying some maintenance fee. However, this is not the case with all state size control schemes; for example this is not an issue if we use ReGenesis.

If SELFDESTRUCT is ever removed in the future, this EIP would simply become a no-op.

Copyright and related rights waived via CC0.

Last changed by 
 
vbuterin
1
2087

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&apos;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