MultiOffRamp - size optimizations

[elatoskinas]

Motivation

Optimizes the contract size for the merged MultiOffRamp + CommitStore to be able to fit the deployment size limits

Solution

Currently the margin is at -0.972KB with 3600 optimizer runs. The contract size fits the space with 1800 optimizer runs.

The contract size can further be reduced, and the optimizer runs increased after the Nonce Manager is integrated into the MultiOffRamp

Each optimization is split into a separate commit. Complete list:

• Remove in-depth message validations -> these will be moved off-chain (ticket already created)
• Move isCursed to shared internal function
• Move forked chain check, curse check and source config enabled check to common internal function
• Move source chain config + curse check to single shared function (used in both exec & commit)
• Move zero address check to internal lib
• Remove global pausing from the multi-offramp -> there are 4 alternative methods of achieving pausing:
  • Per-lane: using IMessageValidator (execution-only), disabling the source chain config, cursing the lane via RMN
  • Globally: implementing the global pause in the RMN
  • The savings are significant, at around ~0.8KB
• Split StaticConfig and DynamicConfig set events
• Get rid of Any2EVMMessageRoute and use 2 internal functions to solve stack depth (same as the OffRamp changes)
• Other contract size golfing: variable caching, inlining
• Compile with lower optimizer runs for the multi-offramp
• Update: OCR3 no longer needs a uniqueReports distinction
• Other fix: OCR3 now uses sequenceNumbers

[github-actions]

I see you updated files related to contracts. Please run pnpm changeset in the contracts directory to add a changeset.

[github-actions]

Go solidity wrappers are out-of-date, regenerate them via the make wrappers-all command

[github-actions]

LCOV of commit bc9743a during Solidity Foundry #5617

Summary coverage rate:
  lines......: 98.8% (1460 of 1477 lines)
  functions..: 96.0% (289 of 301 functions)
  branches...: 92.9% (619 of 666 branches)

Files changed coverage rate: n/a

[RensR]

Honestly not super fan of this as it makes the calls with multiple zero checks pretty unreadable

[elatoskinas]

Removed this. The overhead is 0.056KB without the optimization, but I agree regarding the readability

[RensR]

Do we still need the separate price seq num? Are these always sequencial without any gaps in OCR3? If so, we could force strict ordering based on seqNums?

[elatoskinas]

Creating a separate ticket for this

[RensR]

Approved pending zero check undo and let's continue the discussion on potential OCR3 seq num improvements