before tournament 3

[evvvritt]

to help improve gas estimate and understanding killing baddies (2 vs 1):

• remove lvl 1 (if possible)
  • remove current lvl 3 song (baby one)
• reduce level times (?)
  • 20s 25s 35s 40s ?? (note 4 levels) = 120 ??
  • or less since ~120 is bad estimates from smart wallets
• increase body size a little again? still think too small on mobile
• expand themes outside of base? (everett)

[okwme]

contract based accounts can only do maximum 18MM gas whereas we're using the following manual estimate for gas:

        txData.gas = 6_000_000 + params[3].length * 1_400_000

where params[3].length is the number of proofs. This is an overestimation by about 50% so when we need 10MM we estimate roughly 15MM (this is because the more accurate version throws an error that prevents mm from accepting it as correct, fuck mm)

Currently the maximum number of proofs is 24 (1 + 2 + 3 + 8 + 10), which according to the calculation results in 39.6MM (although in reality the gas used in this tx is closer to 26 as reported by base wallet team).

wrt times there are some constraints to consider. 2—4 body simulations (levels 1—3) consist of 10 sec chunks so we can't easily split them into 5 sec intervals like the suggested 25s. For the time being let's assume we do it as 20s, 25s, 35s and 40s. This would reduce proofs to 20 (2 + 3 + 7 + 8) which would still be 34MM. If we took a more aggressive approach, like 10s, 20s, 25s, 30s this would be 14 (1 + 2 + 5 + 6) which would be 25.6MM estimate and 17MM actual gas. I'm not sure if this is already enough for the smart contract to not fail since the accurate estimate is under 18MM but it may be dangerous since it's still on the verge.

Another solution is to forgo the limitation of generating proofs in the browser. This is the restriction that has created the current 10s and 5 sec chunk limitations. One extreme would be to make a single proof per game that verified 1250s over all current 1—5 levels. It's unclear how long this proof would take to generate on the sindri system, but assuming ~5 sec for 1MM constraints whereas this would be ~10MM constraints I'd assume a proving time of ~50sec. Not ideal, especially considering this becomes a complete dependency on proving networks.

Instead of an extreme approach, we could also consider just changing the level 4 and level 5 prover to run 10s chunks. This would make it less feasible to generate the proof in browser but not necessarily impossible (I think it prevents Safari but not chrome). Without reducing the levels in any other way this would result in a reduction of proofs to 15 (1 + 2 + 3 + 4 + 5) which would be 27MM (actually 18). Again this is on the verge of limitations for contract based sponsored transactions. If we simultaneously reduce the levels as follows: 0s, 10s, 20s, 30s, 40s proofs would reduce to 10 (1 + 2 + 3 + 4) which would put our estimates at 20MM (actually around 13M). Reducing this far may allow us to remove the manual over-calculation as well. Since it's just changing the duration of the proof used for level 4 and 5 it is a pretty small change in all of the architecture and testing as well.

I'll start trying this solution out.

[okwme]

ok got a working version where with just a swap of the 5 sec chunks to 10 sec chunks. Tested without removing level 1 which would result in maximum 15. I think it's worth trying to deploy this solution in a non-disruptive way (no upgrade necessary) just to see if the base contract based wallets start working.

[okwme]

update: successfully deployed the reduced proving system to live base mainnet, see a reduction of gas costs for longest possible number of proofs (15) reduced to estimate of 27MM (actually ~20MM) from previous amount of 39.6MM (not bad!) with no need to deploy full upgrade to the game logic. This is actually a pretty amazing improvement for the amount of disruption and only needing 3 hours of work!

I'm going to checkpoint this work and make it live on the front end as well before continuing with the possible full upgrade that reduces the total number of levels and changes body size again. Open question is whether I try to combine the full upgrade (AnybodyProblemV3.sol) into a fix for the tournament since it's not currently tracking weekly play correctly atm. Since we're not allowing trustless prize deployment this isn't an issue and it's an open question whether we need this ever.