Update excess fee inhibitor to 65536

[lightclient]

Back in #12 we realized that we need to keep users from submitting requests before fork. The simple way to do this is add a flag to the system contract and set the flag the first time the system call happens.

The downside is that the flag gate imposes an extra 5000 gas on ever user call to the contract forever in the future.

To avoid this, we decided to make the fee too great for anyone to actually pay before the fork. On the first system call, the contract will notice the excess count is the special value and reset it to zero.

We stick with that idea in this PR, but update the value from 1181 to 16384. Originally 1181 was decided because it's the largest value we can use in fake_exponential without it overflowing. Unfortunately we realized that 1181 is a number that might be possible to obtain in the future. The cost is bound mostly by the five sstores in the user routine. If the gas limit changes significantly or storage becomes much cheaper, it's possible to imagine a world where post-Prague, a user could submit 1181 requests in a single block at 1 wei and avoid the fee spike from occurring.

To address this, I'm proposing we bump to 65536. This number is proposed somewhat arbitrarily, but it returns a fee of 923226766505217739920341538189009691485399699651503388307248448916147782597 -- so safe to say even though it does overflow during the calculation, it produces a fee that is also impossible to meet before the fork and increases the number of requests needed to organically trigger the short circuit by an order of magnitude.

If we're okay with relying on this fee calculation overflowing, we could potentially choose an even larger number for this inhibitor. Part of the reason I picked this value is foundry seems to have issues with arbitrarily large numbers here.

[mkalinin]

a user could submit 1181 requests in a single block at 1 wei and avoid the fee spike from occurring

Contracts’ constructors call sstore(EXCESS_SLOT, EXCESS_INHIBITOR), thus the fee will be incredibly high even for the first call to add a new request routine, won’t it?

[lightclient]

Contracts’ constructors call sstore(EXCESS_SLOT, EXCESS_INHIBITOR), thus the fee will be incredibly high even for the first call to add a new request routine, won’t it?

Correct, but the issue is after the fork, the code is still there to check the excess value against the inhibitor. When the fee is set back to 1 wei, it may be possible to make the 1181 requests.

I guess what we could actually do here is set the flag on the system side since it would completely stop any possibility of reach the inhibitor number and on the system side we are not really sensitive to gas cost. The extra storage element would forever and always need to be in the witness though (our we'd need to also filter it out). Not sure if the trade off is worth it.

[lightclient]

close in favor of #26