fix: Multichain (Pt 2) fixes (#1549)

**Motivation:**

Results of internal review of the contracts primarily involved with
offchain/onchain interaction

**Modifications:**

* Add reentrancy guard to `OperatorTableUpdater`
* Add miscellaneous documentation surrounding design decisions
* Misc fixes

**Result:**

Cleaner and safer code

---------

Co-authored-by: Yash Patil <[email protected]>

Author: nadir-akhtar

docs/multichain/destination/CertificateVerifier.md

@@ -145,12 +145,14 @@ Verifies an ECDSA certificate by checking individual signatures from operators.
 
 *Requirements*:
 * The certificate MUST NOT be stale (based on `maxStalenessPeriod`)
-* The root at `referenceTimestamp` MUST be valid (not disabled)
-* The operator table MUST exist for the `referenceTimestamp`
+* The root at `referenceTimestamp` MUST exist
+* The root at `referenceTimestamp` MUST be valid
 * Signatures MUST be proper length
+* Each signature MUST be valid
 * Signatures MUST be ordered by signer address (ascending)
+* The operatorSet MUST be updated for the `referenceTimestamp`
+* There must be a nonzero number of operators for the `referenceTimestamp`
 * All signers MUST be registered operators
-* Each signature MUST be valid
 
 #### `verifyCertificateProportion`
 
@@ -401,9 +403,11 @@ Verifies a BN254 certificate by checking the aggregated signature against the op
 
 *Requirements*:
 * The certificate MUST NOT be stale (based on `maxStalenessPeriod`)
-* The root at `referenceTimestamp` MUST be valid (not disabled)
+* The root at the `referenceTimestamp` MUST exist
+* The root at the `referenceTimestamp` MUST not be disabled
 * The operator set info MUST exist for the `referenceTimestamp`
-* All merkle proofs MUST be valid
+* The `operatorIndex` must be valid for the non signer
+* All merkle proofs for nonsigners MUST be valid
 * The BLS signature MUST verify correctly
 
 #### `verifyCertificateProportion`
@@ -528,6 +532,6 @@ The operator table is updated every 10 days. The staleness period is 5 days. The
 1. Day 1: Table updated
 2. Day 2: Certificate passes
 3. Day 6: Certificate verification *fails*
-4. Day 7: A certificate is re-generated. However, this will stale fail as the `referenceTimestamp` would still be day 1 given that was the latest table update
+4. Day 7: A new certificate is generated. However, this will fail as the `referenceTimestamp` would still be Day 1 given that was the latest table update
 
 Note that we cannot re-generate a certificate on Day 7. This is why we prevent the `stalenessPeriod` from being less than 10 days in the `CrossChainRegistry`.

docs/multichain/destination/OperatorTableUpdater.md

@@ -23,7 +23,7 @@ Upon initialization, the `generator` is updated. The `generator` is represented
 
 The following values are set upon initialization: 
 
-* `generator` is an EigenLabs-run entity that signs off on `globalTableRoots`. The operatorSet is of size 1. 
+* `generator` is an EigenLabs-run entity that signs off on `globalTableRoots`. The operatorSet is of size 1. The `generator` is always expected to use BN254 signing keys, hence the use of the BN254OperatorSetInfo when setting the generator.
 * `globalRootConfirmationThreshold`: 10000. The threshold in basis points required for global root confirmation. Since the operatorSet is of size 1 a single signature is needed.
 * `generatorInfo`: The key material needed to verify certificates of the `generator`
 * `operatorSetConfig`: A configuration for the `generator` 

docs/multichain/source/CrossChainRegistry.md

@@ -68,6 +68,8 @@ function createGenerationReservation(
 
 Creates a generation reservation for a given `operatorSet`, which enables the operatorSet to be included in the `GlobalTableRoot` generation and transported to all destination chains. This function sets up the complete configuration for cross-chain operations in a single transaction.
 
+Note that the `operatorTableCalculator` must be deployed by the AVS onto the source chain prior to calling this function.
+
 *Effects*:
 * Adds the `operatorSet` to `_activeGenerationReservations`
 * Sets the `operatorTableCalculator` for the `operatorSet`
@@ -81,8 +83,6 @@ Creates a generation reservation for a given `operatorSet`, which enables the op
 * Caller MUST be UAM permissioned for `operatorSet.avs`
 * The `operatorSet` MUST exist in the `AllocationManager`
 * A generation reservation MUST NOT already exist for the `operatorSet`
-* At least one `chainID` MUST be provided
-* All provided `chainIDs` MUST be whitelisted
 
 ### `removeGenerationReservation`
 
@@ -134,7 +134,11 @@ function setOperatorTableCalculator(
 ) external;
 ```
 
-Updates the `operatorTableCalculator` contract for a given `operatorSet`. The `operatorTableCalculator` is deployed by the AVS and is responsible for computing the operator table bytes that will be included in cross-chain transports. For more information on the `operatorTableCalculator`, please see full documentation in the [middleware repository](https://github.com/Layr-Labs/eigenlayer-middleware/tree/dev/docs).
+Updates the `operatorTableCalculator` contract for a given `operatorSet`. The `operatorTableCalculator` is deployed by the AVS and is responsible for computing the operator table bytes that will be included in cross-chain transports.
+
+Note that, if the `operatorTableCalculator` fails to comply with the expected interface, the offchain transport system will simply ignore the active generation reservation for this operator set.
+
+For more information on the `operatorTableCalculator`, please see full documentation in the [middleware repository](https://github.com/Layr-Labs/eigenlayer-middleware/tree/dev/docs).
 
 *Effects*:
 * Updates the `_operatorTableCalculators` mapping for the `operatorSet`