RMN Home #1451
RMN Home #1451
Conversation
| uint64 minObservers; // required to agree on an observation for this source chain | ||
| uint64 chainSelector; // ─────╮ The Source chain selector. | ||
| uint64 minObservers; // ──────╯ Required number of observers to agree on an observation for this source chain. | ||
| uint256 observerNodesBitmap; // ObserverNodesBitmap & (1<<i) == (1<<i) iff nodes[i] is an observer for this source chain. |
There was a problem hiding this comment.
@gtklocker does it mean that we can have a max of 256 observers per src chain?
There was a problem hiding this comment.
Yes, that should be plenty right?
LCOV of commit
|
| } | ||
| /// @notice This array holds the digests of the configs, used for efficiency. | ||
| /// @dev Value i in this array is valid iff it's not 0. | ||
| bytes32[MAX_CONCURRENT_CONFIGS] private s_configDigests; |
There was a problem hiding this comment.
do we really care about efficiency here? CCIPConfig has just the one mapping with OCR3ConfigWithMeta holding configCount (same as this version) and digest
There was a problem hiding this comment.
I'll modify the comment. The real reason for this layout is that Solidity doesn't let you assign complex memory structs to storage. It does allow you to copy them from calldata, as that's not memory. This is how we can store the config to storage without manually copy-pasting each attribute (very error prone, not readable, inefficient) like we do in CCIPConfig. Imo RMN uses the superior solution here. We would have used a single list if this wasn't the case
| Config config; | ||
| } | ||
|
|
||
| struct VersionedConfigWithDigest { |
There was a problem hiding this comment.
is there a way to combine VersionedConfigWithDigest + VersionedConfig into RMNConfigWithMeta (just so analogous with OCR3ConfigWithMeta)
There was a problem hiding this comment.
I just tried, the struct is too complex and will always result in a stack too deep if we use the same format as OCR3ConfigWithMeta
| } | ||
|
|
||
| struct VersionedConfig { | ||
| uint32 version; | ||
| uint32 version; // The version of this config, starting from 1 it increments with each new config. |
There was a problem hiding this comment.
could we align with OCR3ConfigWithMeta in the sense that the version is just called configCount? Fine if we adjust CCIPConfig to use version instead of configCount as well
| } | ||
| } | ||
| /// @notice The total number of configs ever set, used for generating the version of the configs. | ||
| uint32 private s_configCount = 0; |
There was a problem hiding this comment.
CCIPConfig avoids this by incrementing based on the existing config (if no config, start at 1). Could probably do the same here?
There was a problem hiding this comment.
It can only do so by not supporting green-green, which imo is a huge feature loss
| /// @param newConfig The new config to set. | ||
| /// @param digestToOverwrite The digest of the config to overwrite, or ZERO_DIGEST if no config is to be overwritten. | ||
| /// This is done to prevent accidental overwrites. | ||
| function setSecondary( |
There was a problem hiding this comment.
I can't see a fundamental reason why the same pattern (either explicit functions per state transition like you have it now in RMNHome OR single updateConfig with validateStateTransition for all transitions in CCIPConfig) can't be used in both contracts so we should pick one to reduce the cognitive load
| (_getConfigDigestPrefix() & PREFIX_MASK) | ||
| | ( | ||
| uint256( | ||
| keccak256(bytes.concat(abi.encode(bytes32("EVM"), block.chainid, address(this), version), staticConfig)) |
There was a problem hiding this comment.
@gtklocker I did bytes.concat to not abi.encode the static config twice, that should be completely safe as the previous items have a static length? Alternatively we could hash it and then include the hash in the abi.encode?
| _validateDynamicConfigParsed(abi.decode(encodedDynamicConfig, (DynamicConfig)), staticConfig.nodes.length); | ||
| } | ||
|
|
||
| function _validateDynamicConfigParsed(DynamicConfig memory dynamicConfig, uint256 numberOfNodes) internal pure { |
There was a problem hiding this comment.
Added this helper to not have to parse the static config twice (once for static checks, once for dynamic checks)
|
|
closed in favour of #1459 |
Still WIP, but overal structure should be pretty solid