stretch goal: gas optimizations on bulk checkout

owocki commented 4 years ago

see analysis here https://twitter.com/owocki/status/1270746582355329029

mds1 commented 4 years ago

We haven't deployed to mainnet yet, so one easy option is compiling with the optimizer set to a high number of runs. IIRC the number of runs is an estimate of how many times the contract will be executed. Higher number means more expensive deployment gas cost, but lower per-usage gas cost.

This may add some risk of introducing bugs while compiling so I recommend asking the diligence team about this before using in production

apbendi commented 4 years ago

@mds1 are there known security risks with running solc with optimizations? I thought it was considered safe.

mds1 commented 4 years ago

I recall reading that from the screenshot below, which is from Dharma's audit of their smart wallet by Trail of Bits. It's from October 2019 so may be outdated by now.

Original report: https://github.com/trailofbits/publications/blob/master/reviews/dharma-smartwallet.pdf

mds1 commented 4 years ago

FWIW, Dharma decided the gas savings of optimization outweigh the risks for their users

apbendi commented 4 years ago

huh that's great to know @mds1 I feel like the compiler should warn about those risks!

mds1 commented 4 years ago

Results of compiler optimization tests are below, using solc 0.6.7. Notes:

Each row is a fixed number of optimizer runs (off = no optimizer)
Values are the amount of gas used for a donate() call to the BulkCheckout contract for the transaction described by the column header (e.g. 10 Dai donations = donate Dai to 10 different grants)
DAI and USDC are really just minimal ERC20s, not actual DAI and USDC
Testing was run on a local ganache instance

        Deployment   1 DAI donation   1 ETH donation   3 DAI donations   3 ETH donations   1 ETH/1 DAI/1 USDC donation   10 Dai donations   10 ETH donations
off     1642726      73897            40804            150596            68116             134308                        284596             163708
2000    1026515      70843            38677            143880            64181             128519                        265063             153445
10000   1123627      70573            38563            143070            63839             127865                        262381             152323
100000  1229333      70573            38563            143070            63839             127853                        262369             152311

The best case improvement is the 10 dai donations case but the savings is only ~20k gas, so gas improvements from the optimizer are not significant and likely not worth implementing

owocki commented 4 years ago

only about 10% savings ... pooooo.. (but thx for trying!)

ScopeLift / gitcoin-web

stretch goal: gas optimizations on bulk checkout #49