Further clarifying if any additional data beyond what is normally available on a full node is required to restore. The TLDR on that and implications:
- 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.
From questions asked on the all core devs gitter channel (edited for clarity):
jpitts:
Assuming the scenario described in the “rent-eip.md” gist, would the work done by RESTORETO be performed on full nodes? Clarifying that this would not require any kind of special storage outside of full nodes.An additional question regarding RESTORETO, how burdensome is this computation on the node? IMO, some of the misunderstanding about restoration may be rooted in misunderstanding that the entire state of the blockchain can be regenerated from a full node. even though it may not be immediately available.
holiman:
It would execute like any other opcode. Not sure I understand the Q. Whoever is rebuilding the state would need access to the full ‘preimage’ state at the point where it was removed, in order to put it back. The restoreto opcode is very simple
The burden is on the user to restore data properly – but he can use a custom contract to do that incrementallyjpitts:
so in this contract, the user would have the data needed?holiman:
The user needs to rebuild the same storage, identically, and then he can say ‘use this data, with that code, and restore that inactive contract over yonder’
For an archived multisig, restore is a one-off. For restoring cryptokitties, it might take monthsjpitts:
So basically the user either needs to have this data, or needs to get this data from some place which would hold it (perhaps at a cost). It takes more time because it has to be done in steps, only so much data can be restored in one txn.
Or is it that RESTORETO on a large enough piece of state would take months to complete?AlexeyAkhunov:
I think that noone will attempt to RESTORETO for very large contracts, it might be easier to start from scratch. It will probably be used to rescue some multisig wallets or something similarholiman:
The RESTORETO in itself is trivial, the preceding build-up of data is the potentially heavy operation
Well, “trivial”, hm, at least pretty simple
I also think it wouldn’t be used to restore gigantic contracts, but it’s kind of important that it could if there was a need for itjpitts:
This means that any necessary buildup operations could be performed by a community effort or service which could also store the evicted data.holiman:
Hm, build-up is sensitive though, dunno if it can be done non-centralized. You wouldn’t want someone putting in bad data
But yes, people could coordinate
If you make a restore-bazonk contract where anyone can submit data, and you get some wrong value in, the RESTORETO will fail later on, when storage hash is wrong