fix: Optimism execution #789
Conversation
crates/revm/src/optimism.rs
Outdated
| // input must not be an deposit transaction | ||
| debug_assert!(!input.is_empty() && input[0] != 0x7E); |
There was a problem hiding this comment.
Can we just return U256::ZERO if either of these two conditions are met? This makes the function more abstract as opposed to it only being used for non-deposit, non-empty transactions.
There was a problem hiding this comment.
Sure changed that, but I was wondering what the expected behavior should actually be for an empty transaction? If anything, shouldn't it return (0 + l1FeeOverhead) * l1Basefee * l1FeeScalar / 1000000? To be consistent with hypothetical one-byte transactions?
| .checked_div(U256::from(1_000_000)) | ||
| .unwrap_or_default() | ||
| / U256::from(1_000_000) |
There was a problem hiding this comment.
Would prefer if we kept this as a checked div just in case.
There was a problem hiding this comment.
checked_div only checks if the divisor is 0. Since it is always hardcoded to one million, I don't think checked div would make any difference.
However, checked operations might make sense before multiplication and addition, as there should be no overflows there.
* use l2 base fee * use optimism handler when activated * fix panic for eth execution with optimism flag * use is_none * address review comments
This PR fixes the issues with the Optimism execution described in #781:
Handler::optimism()is used instead ofHandler::mainnet()when theoptimismfeature is enabled andenv.cfg.optimismistrue.env.block.basefee * (gas.spend() - gas_refund).tx_l1_costonly whenenv.cfg.optimismistrueand the corresponding transaction is not an Optimism deposit transaction. This supports regular Ethereum transactions whenenv.cfg.optimismisfalseandenv.tx.optimism.enveloped_txbeingNonefor non-deposit transactions otherwise.