[pallet-revive] immutable data storage #5861
Conversation
Signed-off-by: Cyrill Leutwiler <[email protected]>
Signed-off-by: Cyrill Leutwiler <[email protected]>
Signed-off-by: xermicus <[email protected]>
Signed-off-by: xermicus <[email protected]>
Signed-off-by: xermicus <[email protected]>
Signed-off-by: xermicus <[email protected]>
Signed-off-by: xermicus <[email protected]>
Signed-off-by: xermicus <[email protected]>
Signed-off-by: xermicus <[email protected]>
Signed-off-by: Cyrill Leutwiler <[email protected]>
Signed-off-by: Cyrill Leutwiler <[email protected]>
Signed-off-by: xermicus <[email protected]>
Signed-off-by: xermicus <[email protected]>
xermicus
added
R0-silent
Signed-off-by: xermicus <[email protected]>
|
bot fmt |
|
@xermicus https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7457393 was started for your command Comment |
|
@xermicus Command |
Co-authored-by: Alexander Theißen <[email protected]>
Signed-off-by: Cyrill Leutwiler <[email protected]>
Signed-off-by: xermicus <[email protected]>
Signed-off-by: Cyrill Leutwiler <[email protected]>
Signed-off-by: xermicus <[email protected]>
Signed-off-by: xermicus <[email protected]>
Signed-off-by: xermicus <[email protected]>
|
bot fmt |
|
@xermicus https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7494314 was started for your command Comment |
|
@xermicus Command |
Yeah I reverted them to remove the noise. The formatter just gets invoked on save - I guess those were a recent addition and the CI hasn't updated the toolchain for a while |
Signed-off-by: Cyrill Leutwiler <[email protected]>
Signed-off-by: Cyrill Leutwiler <[email protected]>
| // The 2 items added are code info and immutable data | ||
| let info_deposit = | ||
| Diff { bytes_added: self.encoded_size() as u32, items_added: 1, ..Default::default() } | ||
| Diff { bytes_added: self.encoded_size() as u32, items_added: 2, ..Default::default() } |
There was a problem hiding this comment.
While the new approach is correct it has a slight wrinkle: We charge for the storage item even if no immutable data is used by the contract. I think this change here should be reverted and the charging of the item should be done in set_immutable_bytes, too: Charge for the item iff immutable_bytes > 0 .
This PR introduces the concept of immutable storage data, used for Solidity immutable variables.
This is a minimal implementation. Immutable data is attached to a contract; to keep
ContractInfofixed in size, we only store the length there, and store the immutable data in a dedicated storage map instead. Which comes at the cost of requiring an additional storage read (costly) for contracts using this feature.We discussed more optimal solutions not requiring any additional storage accesses internally, but they turned out to be non-trivial to implement. Another optimization benefiting multiple calls to the same contract in a single call stack would be to cache the immutable data in
Stack. However, this potential creates a DOS vulnerability (the attack vector is to call into as many contracts in a single stack as possible, where they all have maximum immutable data to fill the cache as efficiently as possible). So this either has to be guaranteed to be a non-issue by limits, or, more likely, to have some logic to bound the cache. Eventually, we should think about introducing the concept of warm and cold storage reads (akin to EVM). Since immutable variables are commonly used in contracts, this change is blocking our initial launch and we should only optimize it properly in follow-ups.This PR also disables the
set_code_hashAPI (which isn't usable for Solidity contracts without pre-compiles anyways). With immutable storage attached to contracts, we now want to run the constructor of the new code hash to collect the immutable data duringset_code_hash. This will be implemented in a follow up PR.