safe-global / safe-modules

A collection of modules that can be used with the Safe contract
GNU Lesser General Public License v3.0
147 stars 73 forks source link

Improve Proxy Behaviour With the IR Optimizer #451

Closed nlordell closed 3 months ago

nlordell commented 3 months ago

This PR marks regions of assembly that previously weren't as memory safe - this allows the IR optimizer to do a few extra optimizations and improve overall gas consumption for the contracts.

Before

  Gas Benchmarking [@bench]
    SafeWebAuthnSignerProxy
      ⛽ deployment: 91107
      ✔ Benchmark signer deployment cost (517ms)
      ⛽ verification (Dummy): 12564
      ✔ Benchmark signer verification cost with Dummy verifier (108ms)
      ⛽ verification (Precompile): 13379
      ✔ Benchmark signer verification cost with Precompile verifier (109ms)

After

  Gas Benchmarking [@bench]
    SafeWebAuthnSignerProxy
      ⛽ deployment: 89900
      ✔ Benchmark signer deployment cost (518ms)
      ⛽ verification (Dummy): 12553
      ✔ Benchmark signer verification cost with Dummy verifier (110ms)
      ⛽ verification (Precompile): 13368
      ✔ Benchmark signer verification cost with Precompile verifier (113ms)

Note that writing to ptr instead of 0 and changing the position of the revert and return actually helps the compiler produce more optimal code :shrug:. Solidity optimizer is really a black box to me sometimes :sweat_smile:.

Additionally, marking the proxy implementation as "memory safe" has a net negative effect on the optimizer, so we intentionally don't mark it as such (even if the changes make it memory safe) ``` Gas Benchmarking [@bench] SafeWebAuthnSignerProxy ⛽ deployment: 90100 ✔ Benchmark signer deployment cost (529ms) ⛽ verification (Dummy): 12570 ✔ Benchmark signer verification cost with Dummy verifier (113ms) ⛽ verification (Precompile): 13385 ✔ Benchmark signer verification cost with Precompile verifier (113ms) ```

This PR is a DRAFT - as it would change the code in a meaningful way that would require us to re-audit it. If we decide that the audit competition is not enough for the SafeWebAuthnSharedSigner and we want an additional audit for that contract (likely), then we should merge this. Otherwise, the changes are not meaningful and can wait until a future version. Since we are re-auditing the SafeWebAuthnSharedSigner, we can include this small change as part of an incremental audit.