Validate transmitter lengths against F values

[elatoskinas]

Motivation

Improves validations for OCR3 and CCIPConfig contracts

Solution

Covers validations:

• fChain <= F, since F represents the full role DON
• Allows setting empty transmitters in CCIPConfig to allow len(transmitters) <= len(signers), while still enforcing len(transmitters) >= 3 * fChain + 1
• Validates non-zero transmitters length in MultiOCR3
• Validates len(signers) >= len(transmitters) in MultiOCR3

Tooling implications

• When setting OCR configs on OffRamp contracts, the list from CCIPConfig must be filtered to exclude 0-bytes addresses. The reason for this is that the MultiOCR3Base disallows zero addresses and duplicates
• Signer and transmitter duplication must be checked in tooling scripts off-chain prior to setting CCIPConfig (otherwise it will result in OffRamp breakage)
• chainConfigs must be set before OCR3 configs due to the added fChain == F validation
• If fChain becomes higher than F after updates, existing OCR3 configs get invalidated without an on-chain check (since it is difficult to do). There should be an off-chain validation script that prevents this (first, F should be increased for all configs, only after which fChain can be increased)
• OffRamp transmitters.length should be validated such that it meets the 3 * fChain + 1 criteria off-chain, since fChain is not tracked in the OffRamp

Gas

Function Name	min	avg	median	max	# calls
validateConfig (without loop check)	7040	20701	8436	122591	11
validateConfig (with loop check)	7040	21006	9132	123442	11

[github-actions]

LCOV of commit 00f1248 during Solidity Foundry #8172

Summary coverage rate:
  lines......: 97.6% (2229 of 2283 lines)
  functions..: 94.5% (411 of 435 functions)
  branches...: 93.5% (529 of 566 branches)

Files changed coverage rate: n/a

[RensR]

Why is it not?

[elatoskinas]

Mainly because fChain is not part of the OCR config in the CCIPConfig logic, and not part of the blue/green deployments. We aimed to keep the OCR3 configs as consistent as possible.

fChain can be updated outside of b/g flows (valid updates would be decreases), which would prompt updates in MultiOCR3 through the non b/g path - that would complicate tooling since we typically only update MultiOCR3 in the b/g update path

[RensR]

These might be very restrictive assumes. Assume is only correct to exclude a very small set of inputs. The check below of > 0 is perfect for it. The check ocrConfig.transmitters.length <= ocrConfig.signers.length is already too restrictive as it discards half of all inputs it tried.

[elatoskinas]

Could release the assumes, but then the test would be more complex to cover unhappy paths (which are already covered by non-fuzz tests)

[elatoskinas]

We can punt this test improvement

[cl-sonarqube-production]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarQube