Before we get into the planning of how ReGenesis can be implemented and rolled out, here is a quick summary of what it is. Although the idea is not new, it has been proposed in the current form here: https://ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state/7582 There is also an explainer post: https://medium.com/@mandrigin/regenesis-explained-97540f457807
ReGenesis logically splits the Ethereum state into two disjoint parts - active state and inactive state. There are ReGenesis “events” occuring regularly, at pre-scheduled times, but not very frequently, for example, every 1 million blocks, which is roughly 6 months. At a ReGenesis event, the active state is reset to just the state root hash, and the entire state is considered inactive. After that, until the next ReGenesis event, new state items get added to the active state, existing state items in the inactive state are moved from inactive into the active state (activated), and there, in the active state, they may change their values. The only two ways to activate a piece of state, or add new data into the active state are transaction witness and block witness.Transaction witness
Transactions get a new attribute, witness, which is a string of bytes encoding a collection of merkle multiproofs. Any part of the these multiproofs that are still valid against the active state, are added to the active state before transaction is executed. (TODO: Explain more how and why only part of these multiproofs will be valid most of the time, and how to find the valid parts).Block witness
Blocks also get a new attribute, witness, which has the same encoding and capabilities as transaction witnesses, except that the valid parts of the block witness are added to the active state before executing any transaction in the block. One reason block witnesses are required is activation of miner’s coinbase address ...