🗞️ Add _options gas profiler

[St0rmBr3w]

In this PR:

This PR introduces a Gas Profiler for estimating the gas usage of LayerZero's lzReceive and lzCompose functions. It simplifies running Foundry scripts by adding pnpm commands that allow dynamic argument passing, making gas profiling more accessible and efficient for developers.

Some limitations are that Foundry does not accurately return L1 data fees on most L2s as referenced in foundry-rs/foundry/issues/6253, so the gas units returned are only part of the profile necessary to determine enforcedOptions, but would be curious if you have any ideas on making it better / more performant.

Key Features

1. Commands for Gas Profiling:

   • gas:lzReceive: Profiles the lzReceive function.
   • gas:lzCompose: Profiles the lzCompose function.

2. Dynamic Arguments:

   • Pass required parameters directly to the commands for custom configurations.

3. Detailed Output:

   • Provides gas usage metrics including average, median, minimum, and maximum values across multiple runs.

Usage Examples

lzReceive Gas Profiling

pnpm gas:lzReceive \
  <rpcUrl> \
  <endpointAddress> \
  <srcEid> \
  <sender> \
  <dstEid> \
  <receiver> \
  <message> \
  <msgValue> \
  <numOfRuns>

lzCompose Gas Profiling

pnpm gas:lzCompose \
  <rpcUrl> \
  <endpointAddress> \
  <srcEid> \
  <sender> \
  <dstEid> \
  <receiver> \
  <composer> \
  <composeMsg> \
  <msgValue> \
  <numOfRuns>

Benefits

• Simplifies repetitive gas profiling tasks.
• Ensures consistent metrics across multiple test runs.
• Allows for customization based on specific configurations and use cases.

This addition enhances developer tooling for LayerZero's protocol, providing actionable insights into gas optimization for enforcedOptions and extraOptions configuration.

Limitations

1. Overestimation of Gas:

• This implementation tends to overestimate gas usage by approximately 3,000 gas units.
• This is most likely due to Foundry leaking memory, which causes additional gas costs for subsequent calls in the same environment stack (e.g., multiple event logs). #Memory leak in forge vm.snapshot and vm.revertTo foundry-rs/foundry#6411 (comment)

EDIT: This was solved with the addition ofvm.lastCallGas().

3. Custom Safety Checks:

   • The implementation assumes the generic safety checks are in place (e.g., ensuring the caller is the endpoint and the call originates from the correct OApp).
   • If the receiver contract includes additional custom checks, these must be manually overridden in the script for accurate results.

4. Snapshot and Fork Dependency:

   • Results are dependent on the snapshot or fork state at the time of execution.
   • The gas profiling does not produce accurate results across multiple calls with different nonces. While calls execute successfully, the gas amount returned is often significantly lower, suggesting some state inconsistencies during resets.

   EDIT: This again is solved with the addition of vm.lastCallGas().

Recommendations

• Use private RPCs to avoid timeouts when running multiple test cases.
• Adjust test parameters (numOfRuns, msgValue, etc.) to match your specific use case for more reliable results.
• Validate custom receiver contract logic independently to ensure compatibility with this profiler.

Fixed

[St0rmBr3w]

Based on some feedback and back and forth with off-chain team, I think that the scope of this can be reduced slightly.

Fork testing might not even be needed if we strictly just need to predict the EVM L2 execution cost. Since L1 data fee is not something we're in a place to abstract right now, the _options param can essentially only predict the L2 execution cost (special exception for different compilers like zkSolc).

In the future, we may have teams try to estimate the L1 data fee, but for today L2 execution cost maximum's is likely the best possible state.

[ryandgoulding]

@St0rmBr3w is this ready for review or do you want to make some more updates based on your above comment? Thanks!