Ethereum 1 dot X: a half-baked roadmap for mainnet improvements

[Flash]

@jpitts

Myself, @tjayrush, @5chdn, and many others participating in the “Data Ring” could take a look at this and begin a discussion about possible incentivized nodes of this type.

Brilliant, I’ll look out for it! Thanks for the reply.

[jpitts]

Clarifying about the 1.x “recoverability”, I see that this has been clearly proposed, just not in the “half baked roadmap” summary. IMO it still seems unclear how exactly a user recovers, and where exactly the data necessary to perform the operation would exist.

From a core devs gitter discussion today:

Recoverability is, imo, really elegantly solved. We iterated over several models, but the final one that is in @fjl’s gist is really really nice

Felix Lange / fiji proposed a RESTORETO opcode in his storage rent gist:

A key description of the mechanism is from Page 56 of @AlexeyAkhunov’s Ethereum state rent - rough proposal dated Nov 26, 2018:

When rent is not paid, contracts leave a “hash stump”, which can be used to restore the contract using opcode RESTORETO. This is different from semantics after Step 3, where linear cross-contract storage would be lost. At this step, linear cross-contract storage can also be recovered with RESTORETO.

@holiman’s TLDR description:

This scheme makes it possible to resurrect arbitrary size contracts, since you can spend infinite time on rebuilding the data-structure. Other types of resurrect, with proofs included in the transaction that does the restoration, has a practical limit on how much data you will be able to supply

[jpitts]

I have gleaned more details from asking on the all core devs gitter channel.

The Q&A is summarized in Discussion about “eviction archive” nodes.

TLDR:

• The restoring user must restore their state in a series of steps, calling the proposed RESTORETO opcode within a contract.
• RESTORETO accepts 1. addr of the hash stump left on eviction, and 2. addr of a contract from which code is taken.
• This user needs to have the evicted state data, or needs to get this data from some eviction archive service. This data is used in the contract.
• RESTORETO is not burdensome on any nodes, but is burdensome on the user depending on the size of state being restored.

[cdetrio]

@jpitts

@Flash

Is there any more information on how and where this archival data will exist? I’d be interested to read the current consensus on it. I’m not a big fan of the idea that you’ll have to pull data stored in extravagantly large nodes that only a few people control.

There does seem to be a gap in the 1.x proposals regarding “the state that is stored somewhere”, and it does need to be clearly addressed. Perhaps nodes of this type could be called “evicted state archive”, and can be incentivized so that there can be more operators running them.

There’s two different things here:

1. A tweak to the syncing protocol so that clients only keep recent blocks/logs. When a client fast syncs, it will only download recent blocks. Historical blocks would remain available on say Bittorrent; historical blocks are only needed for clients to do a full sync (run all transactions from genesis, but prune historical account states from the db; these clients can only respond to RPC queries like eth_getBalance for the latest block), or archive sync (run all transactions from genesis, and keep historical account states in the db to quickly respond to RPC queries about account states at blocks from long ago). This is the “Chain Pruning” proposal: Pruning historical chain segments · GitHub. Technically it is not even a hard fork, nothing about the EVM changes, just the sync protocol.

2. Adopting storage rent and evicting contract storage from the state. Here is a storage rent EIP with a RESTORETO opcode: EIP-1682: Storage Rent by holiman · Pull Request #1682 · ethereum/EIPs · GitHub. If a contract gets evicted and a user wants to restore it, they need to pass some data to RESTORETO. They can fetch this data from an archive node (an ethereum node that can respond to RPC queries about historical account states, see above). This is a hard fork, it changes the EVM.

@jpitts

Clarifying about the 1.x “recoverability”, I see that this has been clearly proposed, just not in the “half baked roadmap” summary. IMO it still seems unclear how exactly a user recovers, and where exactly the data necessary to perform the operation would exist.

The data needed to restore evicted contracts exists in historical account states. The archive nodes that we have today can provide this data:
geth --syncmode full --gcmode archive
parity --no-warp --pruning archive