joshieDo

solidity does not optimize the access into the slot. doesn't feel much different than caching `array.length` no ?

one could take it a step further... ~~and assuming that users approve without `uint256.max` which is not true~~: ERC20 & ERC4626. ```diff diff --git a/.gas-snapshot b/.gas-snapshot index 80ae19b..b77e761 100644 ---...

I'm not sure invariant testing is the best for this kind of scenario. We have `x` on the dictionary, but we need `x+1`, so we're stuck on somehow getting `x+1`...

op-reth **does not** use snap sync elsync mode from op-node triggers a staged-sync style on op-reth. this is just an optimized way of executing large ranges of blocks (eg. from...

As it is, it does. At the moment `main` will only read 20 bytes to decompress an address if `TransactionKind` is `Call`. However, we could replicate this behaviour by manually...

### context: `Compact` encodes to ``. `TransactionKind` occupies 1 bit on the bitflag header of this transaction type. On decoding, if the bit is set: we read 20 bytes, otherwise...

At first glance I see an issue here: ``` Acc1 -> [Tx1,Block1Reward,Tx3] ``` `Tx1` is an integer, while `Block1Reward` is what? But either way, if we're putting them both in...

Ok got it, bringing the summary I got from discord: we'd be incrementing the `CumulativeTxCount` for the reward resulting in the following: ``` Tx1=1 Tx2=2 Block1Reward=3 Block2Reward=4 Tx3=5 Block3Reward=6 ```

we have something similar for db codecs. Also has built-in fuzzing support using `trailofbits/test-fuzz`. Maybe it's interesting here as well? https://github.com/foundry-rs/reth/blob/c0db65c86fd1c5ddde03a3b7d0a487ed93c178ec/crates/interfaces/src/db/codecs/fuzz/mod.rs#L30-L45 and here: https://github.com/foundry-rs/reth/blob/c0db65c86fd1c5ddde03a3b7d0a487ed93c178ec/crates/codecs/derive/src/compact/generator.rs#L18-L31

Still missing `ExecutionStage`