0xsequence / sstore2 Goto Github PK

Given that this sstore2 library was one of the initial reference points for the BytecodeStorage library that we developed at Art Blocks, I wanted to file this issue as a similar issue to mirror the one on our end (ArtBlocks/artblocks-contracts#422) for increased visibility for the maintainers of this library as to how it may be impacted by EIP 3540.

cc @ryley-o

i noticed that the gas cost of creationCodeFor for ~1500 bytes is ~7.2k gas

i'm assuming this is due to the 2x abi.encodePacked calls that would be allocating and building new bytes in memory each time

i saw creationCodeFor above 90k gas for about 20kb of data

i was thinking that if SSTORE2 could setup a region in memory with all the creation code prefilled followed by X bytes, and return a pointer to the start of X bytes, then devs willing to use assembly could potentially efficiently populate the X bytes themselves (a gas cost they would have to pay either way) then ask SSTORE just to deploy the result without further processing

i'll attempt to do this myself locally and report back on whether the approach helps

FYI the deploy cost of the same 1500 bytes was ~327k gas, so the overhead is ~2%

First of all, thanks for sharing this very clever way to economize gas costs :)

I got a question regarding the benchmarks: they were done after EIP-2929 changed EXTCODESIZE gas cost?

I am trying yarn add -D https://github.com/0xsequence/sstore2 but receiving the following error:

error An unexpected error occurred: "ENOENT: no such file or directory, open '/Users/clementwalter/Library/Caches/Yarn/v6/npm-@0xsequence-create3-3.0.0-606096fd114f8996131c0b395a3b42625c3cab47/node_modules/@0xsequence/create3/.yarn-tarball.tgz'".

I tried removing the node_modules, the yarn.lock, clearing yarn cache of my projet but nothing changed.

yarn version 1.22.15
node version v14.17.0

It would be useful

Howdy!

@ryley-o and I are team members over at Art Blocks, where we've been working on adding some of the fancier gas savings techniques re: storage, influenced by this SSTORE2 library, for our in-progress core contract updates and realized that for our purposes having the capability to perform "delete" operations as part of the library was important.

Would love to get input from your side as to whether or not this idea was already explored and decided against, and if so additional context on why. Or, if this wasn't yet explored for SSTORE2 (e.g. wasn't in scope) if you would be interested in / open to us sending a pull request to update your implementation to make use of a similar approach as is used in our implementation.

tl;dr, we've updated the approach used in the two SSTORE2 implementations that we're familiar with to add the added functionality of:

a) supporting safe-deletion in addition to writes and reads (this is important in our opinion if this type of pattern becomes widely adopted to allow for reduction of chain bloat where relevant, for example if one uploads one version of a file but they mess up the upload and then want to re-upload pre-launch).
b) allows for introspect-ability of who wrote a given block of data to chain which has some interesting properties that this enables, you can see more about my musings on this here: ArtBlocks/artblocks-contracts#307 (comment), which I've copied inline here:

The introspect-ability of this author/writer data is interesting because it enables some interesting use-cases for systems-of-applications (dApps that use multiple smart contracts). For example, in the case of the Art Blocks ecosystem, this introspect-ability allows us to potentially build in the future a tool that allows a collector to input into a given tool the contract address for a deployed script's data, and have that tool use this introspection to reverse-lookup the core-contract that the said script is associated with (e.g. is it an Art Blocks flagship core-contract, an Art Blocks Engine core-contract, an auxiliary registry Art Blocks contract that writes some other provenance related data to chain-state via BytecodeStorage, etc.).

Anyway, tl;dr, here is the current implementation of this SSTORE2 variant, any thoughts/feedback/input is greatly appreciated and would love to know if there is interest on your end in us sending a PR with these adjustments back into this library:
https://github.com/ArtBlocks/artblocks-contracts/blob/36a0598f498bbdfe63602c21f86a514b9b25b97a/contracts/libs/0.8.x/BytecodeStorage.sol