# EIP draft: history storage contract ``` --- eip: <to be assigned> title: Long-term history accessibility author: Vitalik Buterin (@vbuterin) discussions-to: <URL> status: Draft type: Standards Track category: Core created: 2020-09-03 --- ``` ## Simple Summary Store historical block hashes in a contract, and modify the `BLOCKHASH` opcode to read this contract. ## Motivation There is increasingly a desire to remove the need for most clients to store history older than some relatively short duration (often between 1 week and 1 year) to save disk space. This requires some form of layer-2 network to help clients access historical information. These protocols can be made much simpler if blocks contained a quick Merkle path to historical blocks. Additional secondary motivations include: * The protocol can be used to make more secure efficient light clients with flyclient-like technology (while the "optimal" flyclient protocol is fairly complex, large security gains over the status quo (trusted "canonical hash trees") can be made cheaply) * Improving cleanness of the protocol, as the BLOCKHASH opcode would then access state and not history. ## Specification | Parameter | Value | | - | - | | `FORK_BLKNUM` | TBD | | `HISTORY_STORAGE_ADDRESS` | `0xfffffffffffffffffffffffffffffffffffffffe`| At the start of processing any block where `block.number >= FORK_BLKNUM` (ie. before processing any transactions), run `sstore(HISTORY_STORAGE_ADDRESS, block.number - 1, block.prevhash)`. When `block.number >= FORK_BLKNUM + 256`, change the logic of the `BLOCKHASH` opcode as follows: if `FORK_BLKNUM <= arg < block.number`, return `sload(HISTORY_STORAGE_ADDRESS, arg)`. Otherwise return 0. ## Rationale Very similar ideas were proposed before in EIP-98 and EIP-210. This EIP is a simplification, removing two sources of needless complexity: 1. Having a tree-like structure with multiple layers as opposed to a single list 2. Writing the EIP in EVM code The former was intended to save space. Since then, however, storage usage has increased massively, to the point where even eg. 5 million new storage slots are fairly negligible compared to existing usage. The latter was intended as a first step toward "writing the Ethereum protocol in EVM" as much as possible, but this goal has since been de-facto abandoned. ## Backwards Compatibility The range of `BLOCKHASH` is increased by this opcode, but behavior within the previous 256-block range remains unchanged. ## Test Cases TBD ## Implementation TBD ## Security Considerations Adding ~2.5 million storage slots per year bloats the state somewhat (but not much relative to the hundreds of millions of existing state objects). However, this EIP is not intended to be permanent; when eth1 is merged into eth2, the BLOCKHASH opcode would likely be repurposed to use eth2's built-in history accumulator structure (see [phase 0 spec](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#slots_per_historical_root)and [basket random](https://basketballrandom.com)). ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
Last changed by  
 
vbuterin
355

Read more

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. A history: SELFDESTRUCT is not necessary SELFDESTRUCT (originally called SUICIDE) was introduced very early on in Ethereum's history; in fact, it was present even in this pre-announcement "spec" of the Ethereum protocol from December 2013. At the time, there was little rigorous thought being done about long-term state size management. However, there was (in my [Vitalik's] head) a general impression that to prevent state from filling up with vestigial garbage without limit, we need it to be possible for any object that can be created to be destroyed. Externally-owned accounts (EOAs), the thinking goes, would automatically be destroyed when their balance drops to zero, and contracts could have a self-destruct clause in the code to delete themselves when they are no longer needed. A gas refund would encourage them to do this. In January 2014, Andrew Miller pointed out something that in retrospect was face-palmingly obvious: in the Dec 2013 spec, EOAs were vulnerable to replay attacks. If I had 100 coins and I sent you 10, you could simply republish this transaction on-chain ten times to clear my entire balance. This was quickly fixed with nonces. However, the addition of nonces removed all hope of EOAs being deleted: the nonce could not be reset to zero. In 2015, some schemes were proposed a small world cup to get around this and potentially allow accounts that send away all of their ETH to be safely deleted. However, by then it was clear that almost no contract developers were actually using the self-destruct feature: figuring out when to self-destruct is too hard and the rewards are too little. By 2019-21, it has become clear that we need some other form of state management, whether rent or "expiring" long-untouched parts of the tree (aka "partial statelessness"). But if we have such a scheme, and it works, then we no longer need to care about giving contracts the ability to delete themselves voluntarily.

2/19/2024
Data Availability Sampling Phase 1 Proposal

WIP The purpose of this document is to describe in more detail a proposal for how phase 1 can be structured based on a "data-availability-focused" approach. The main addition to the beacon chain will be a Vector of ShardDataHeader objects, one for each shard. A ShardDataHeader is a small object which represents a large amount of underlying data (roughly 0-512 kB in size). A block is only valid if the underlying data that the ShardDataHeader points to is available - that is, it has been published to the network and anyone can download it. However, to preserve scalability, clients will not try to download the full underlying data of every ShardDataHeader to verify the block. Instead, they will verify that the data is available using an indirect technique called data availability sampling. Parameters Parameter Value Description

2/19/2024
An explanation of the sharding + DAS proposal

Along with proof of stake, the other central feature in the eth2 design is sharding. This proposal introduces a limited form of sharding, called "data sharding", as per the rollup-centric roadmap: the shards would store data, and attest to the availability of ~250 kB sized blobs of data. This availability verification provides a secure and high-throughput data layer for layer-2 protocols such as rollups. To verify the availability of high volumes of data without requiring any single node to personally download all of the data, two techniques are stacked on top of each other: (i) attestation by randomly sampled committees, and (ii) data availability sampling (DAS). ELI5: randomly sampled committees Suppose you have a big amount of data (think: 16 MB, the average amount that the eth2 chain will actually process per slot, at least initially). You represent this data as 64 "blobs" of 256 kB each. You have a proof of stake system, with ~6400 validators. How do you check all of the data without (i) requiring anyone to download the whole thing, or (ii) opening the door for an attacker who controls only a few validators to sneak an invalid block through? We can solve the first problem by splitting up the work: validators 1...100 have to download and check the first blob, validators 101...200 have to download and check the second blob, and so on. The validators in each of these subgroups (or "committees") simply make a signature attesting that they have verified the blob, and the network as a whole only accepts the blob if they have seen signatures from the majority of the corresponding committee. But this leads to a problem: what if the attacker controls some contiguous subset of validators (eg. 1971....2070)? If this were the case, then even though the attacker controls only ~1.5% of the whole validator set, they would dominate a single committee (in this case, they would have ~70% of committee 20, containing validators 2001...2100), and so they would be able to control the committee and push even invalid/unavailable blobs into the chain. Random sampling solves this by using a random shuffling algorithm to select the committees. We use some hash as the seed of a random number generator, which we then use to randomly shuffle the list [1..6400]. The first 100 values in the shuffled list are the first committee, the next 100 are the second committee, etc.

1/16/2024
Moderate refund removal alternatives

This document lays out some possible options for alternatives to EIP 3298 (removal of refunds) that try to preserve some of the legitimate goals and positive incentives that refunds provide. Why perhaps not total removal? Total removal is the simplest option and it accomplishes the desired effects, but it also has some downsides that have been identified by the community. The two strongest critiques of total removal of refunds that I have seen are: Zero -> nonzero -> zero storage use patterns There are two major examples of this: Mutex locks on contracts, where before contract A calls contract B, it first flips a storage slot to some nonzero value. When contract A itself is called, it checks that that storage slot is empty; if it is not, the call fails. This prevents re-entrancy. When the call finishes, the storage slot is flipped back to zero. Approving an ERC20 token for exactly the desired amount and then immediately spending that amount.

4/3/2023
Read more from vbuterin
Published on HackMD