ReGenesis - resetting Ethereum to reduce the burden of large blockchain and state

[AlexeyAkhunov]

@vbuterin

What’s wrong with this? Transaction senders already set gaslimits based on how many operations of what kind their transaction will include, and we know the theoretical limits for the witness size for a call (~8 kB theoretical max, ~4 kB practical max assuming computational bounds on address grinding, ~1 kB practical max if grinding is impossible eg. many contract storage cases).

Ok, this comparison implies that there will be a deterministic procedure for generating the transaction witness that the miner must follow. I will think about it, thank you for the idea!

[vbuterin]

Isn’t the property that there exists exactly one (down to the byte) valid witness for a given set of keys in a given tree one of the desired properties of the binary tree + witness format that we’re going for already? eg. SSZ binary trees definitely have that property; it’s a good property to have because it makes preventing consensus failures much easier. Or is there something big that I’m missing that makes that very hard?

[AlexeyAkhunov]

@vbuterin

Isn’t the property that there exists exactly one (down to the byte) valid witness for a given set of keys in a given tree one of the desired properties of the binary tree + witness format that we’re going for already?

It exists if you specify exactly what is the active state and inactive state at the moment of creating the witness. When I was thinking of tx witness being created by transaction senders, it needed to be reasonably flexible about what snapshot of the active state they used (otherwise the transaction needed to be recreated after every block, which is impractical). If the witnesses for transactions are generated by the miners, then it is possible to establish a deterministic procedure of how tx witness is constructed as transaction’s execution goes on (because in this case, the active state is fixed). So yes, this could work. I have not thought about it from this angle before, so thank you for bringing this up

[villanuevawill]

To add to the general discussion and connect it to the topic of stateless mining… If we achieve stateless mining, then ReGenesis may not be relevant depending on the migration strategy (discussed at the end of this comment).

The general direction I have seen, is we eventually want our execution layer to live on n-shards (EVM, EVM 2.0, Ewasm is still unsure). To continue to support n-shard execution and validator shuffling (along with increasing decentralization by making the burden to mine minimized), stateless mining would be a critical path in the future. To accomplish stateless mining, some semblance of a transaction-based witness approach (or access-list based) and DSA-free (SSA) would be needed.

1. User submits a tx with the signed witnesses and an access list
2. Miner still creates a multiproof from the combined witnesses and only needs to include the user signed witness in a block if the miner needs to apply attribution for a missing witness or an access-list, state access mismatch. Alternatively, the user may only need to include an access list (no witnesses) and the miner may request witnesses from a third party or state provider (this takes some of the burden off the user but could have other concerns).
3. DSA-free approach enforces the validity of step 2) and protects the user from front-running or other issues. Additionally, a transaction can have an expiration period and therefore can still access a changed witness from the previous n-blocks which gets us quite close to DSA functionality and what we have today.

The main discussion I want to introduce here, is whether witness size reduction provided by ReGenesis is crucial enough for the short term and also for the health of full nodes (quicker setup)? If we are going to introduce stateless mining anyways on the roadmap, would this be extra throwaway work and prevent us from exploring state provider networks sooner (for miners or users)? Or will we likely never see a path for the original eth1 shard to migrate to stateless mining?

If we did migrate to DSA-free (or SSA), then it would require some extra complexity. For example, newly deployed contracts would only be DSA-free or there would be an n-block period of time until DSA is no longer supported. This seems tricky and may end up being better to keep the eth shard as DSA and subsequent shards as DSA-free. As a result, ReGenesis would still be beneficial to the original eth shard. Any thoughts on the general direction here?

[villanuevawill]

One other followup/discussion to bring up. In previous discussions around the eth1-eth2 merge, block producers for the eth1 shard initially hold state, but validators who are shuffled rapidly and verifying the blocks were not assumed to hold any state. With respect to ReGenesis, would we now expect validators (not the BPs) to download state to the previous ReGenesis period?

[MaverickChow]

With reGenesis, doesn’t that mean dirty laundered ETH (whether it be obtained from terrorism or scam/fraud or robbery/extortion/etc) from version 1 would now become clean ETH in version 2, as a major downside?

And subsequent reGenesis to newer versions will also make ‘clean’ previously unclean ETH?

[lithp]

@MaverickChow

With reGenesis, doesn’t that mean dirty laundered ETH (whether it be obtained from terrorism or scam/fraud or robbery/extortion/etc) from version 1 would now become clean ETH in version 2, as a major downside?

In short, no.

The long answer is that no variant of ReGenesis decreases transaction linkability. ETH might move between the active and inactive state, and it might even move between different state trees, but the ETH isn’t moving between accounts. ReGenesis does not change who owns which ETH and someone who is paying attention will have no trouble keeping track of ETH movements.

[dankrad]

@AlexeyAkhunov

Any attacker that tries to “trap” the user, will have to come up with more sophisticated ways to redirect the transaction’s state access outside of the implicit state, and eventually, the attacker will fail.

I think the statement “eventually the attacker will fail” is only true in a very theoretical sense, as in when the entire state has been incorporated. As an example, a contract could have a variable X that can be externally set, and upon calling it would always check the state of the address X. The attacker now can set this two any part of the state that isn’t in the current temporary state yet.

@AlexeyAkhunov

Users may need to repeat transactions (due to Dynamic State Access) until they eventually achieve the desired state transition

See above, there could well be a class of contracts that can be completely DOSed in practice with this approach.