I got nerd sniped by this tweet. @boredGenius got extremely close to pulling off an sstore2 modification to allow rewriting to the same key but had two issues that stopped them from wrapping it up. Nonces and selfdestruct ordering.

The nonce issue was that there wasn’t an easy way to keep track of them in the contract. The selfdestruct issue resolves around no matter when you call selfdestruct it happens at the end of the tx, this prevents you from redeploying to the same address in a single tx and thus changing the contract stored data.

I had an idea on how to fix the selfdestruct issue. If you were able to use two contracts and flip back and fourth between the two every write you could selfdestruct one and write to the other. In order to keep track of which one is active we run an EXTCODESIZE on either one, if it’s 0 we know we can deploy there and SELFDESTRUCT the other.

Now how do we work around the nonce issue? in comes @nicksdjohnson tweeting about nonce getting reset on SELFDESTRUCT. In order to know why this is important we have to go in to how the create3 library works. From the parent contract it uses CREATE2 (deterministic address based on calling address, hash of initcode, and salt) with some fancy static bytecode proxy that when called runs a CREATE (deterministic address based on calling address and nonce) on arbitrary bytecode. What does this get us? It gets us a chain of deterministic addresses with the final one having arbitrary bytecode. Perfect, you can see why it’s used by the sstore2 lib.

Here is how I combined the two and replaced the create3 proxy with the below:

contract CREATE07Proxy {
  error ErrorDestroyingContract();
  error ErrorDeployingToDeterministicAddress();

  function deployDataContract(bytes memory creationCode) external {
    address nonce1Address = addressOf(1);
    address nonce2Address = addressOf(2);

    address dataContract;

    if (nonce1Address.code.length == 0) {
      // deploy data at nonce 1
      assembly {
        dataContract := create(0, add(creationCode, 32), mload(creationCode))
      }
      if (dataContract != nonce1Address)
        revert ErrorDeployingToDeterministicAddress();

      if (nonce2Address.code.length != 0) {
        // selfdestruct data contract at nonce 2
        (bool success, ) = nonce2Address.call("");
        if (!success) revert ErrorDestroyingContract();
      }
    } else {
      // deploy data at nonce 2
      assembly {
        dataContract := create(0, add(creationCode, 32), mload(creationCode))
      }
      if (dataContract != nonce2Address)
        revert ErrorDeployingToDeterministicAddress();

      // selfdestruct data contract at nonce 1
      (bool success, ) = nonce1Address.call("");
      if (!success) revert ErrorDestroyingContract();

      // selfdestruct this proxy to reset nonce to 1
      // the next data write will redeploy this proxy
      selfdestruct(payable(tx.origin));
    }
  }

  function addressOf(uint8 nonce) internal view returns (address) {
    return
      address(
        uint160(
          uint256(keccak256(abi.encodePacked(hex"d6_94", address(this), nonce)))
        )
      );
  }
}

So we get flip flops between deterministic nonce 1 and 2, and after we deploy with nonce 2 we selfdestruct to reset the nonce. Once the above proxy was used instead of the default create3 proxy all the pieces were in place and I was able to rewrite data stored in a contract referenced by an arbitrary key.

In order to read the data it attempts to see if the address at nonce 1 has size > 0, loads nonce 1 if so, nonce 2 if not.

I have not done ANY optimizing or gas profiling. I simply wanted to see if I could do it.