ADI Shuffle Update

Simple Summary

Proposal to update a.DI with the new Shuffle mechanism, included into the v1.1 release presented HERE.

Motivation

a.DI v1 has one constraint, that even if not major, limits the scalability of the system: whenever a new underlying bridge provider is added to the set of a communication path, each message on that path will be passed through all the bridges, no matter if the consensus required on the recipient side is lower. For example, currently all messages Ethereum → Polygon are sent via CCIP, LayerZero, Hyperlane, and the Polygon native bridge, even if the consensus required on the Polygon side is 3-of-4. This means that even if consensus was reached already before the slowest bridge delivers the message (Polygon native in this case), the cost incurred is of the whole set of 4 bridges, not only 3.

a.DI v1.1 (and more specifically its Shuffling feature) introduces a mechanism for, whenever a message needs to be sent, the system choosing pseudo-randomly a sub-set of all the available bridges for that specific path (e.g. Ethereum → Polygon) with optimal bandwidth size, and only forwards the message via those bridges.

By doing this:

• Cost is reduced on all those configurations with optimal bandwidth < bandwidth.
• Any bottleneck to add new underlying bridge providers is removed, as increasing bandwidth doesn’t really have any effect on the optimal bandwidth of the path.
• Security-wise, the pseudo-random nature of the shuffling mechanism improves the system, in the line of other rotation-based systems like validators-selection in PoS blockchains.

Specification

This proposal upgrades a.DI on every supported network with the new implementation containing the Shuffle mechanism; afterwards, it configures the new parameters required.

The upgrade adds a new _optimalBandwidthByChain mapping on CrossChainForwarder that will store the optimal bandwidth for every supported chain. This will be used to determine how many adapters will be used to pass a message to a destination network

The OptimalBandwidth used to update a.DI will be:

The method used to initialize a.DI with the new bandwidth configurations is:

function initializeRevision(
  OptimalBandwidthByChain[] memory optimalBandwidthByChain
) external reinitializer(3) {
  _updateOptimalBandwidthByChain(optimalBandwidthByChain);
}

The new CrossChainController implementations for every supported network are the following:

Security

Certora audit report on the Shuffle update can be found here

References

• Implementation: CrossChainController Shuffle update payloads implementation
• Tests: CrossChainController Shuffle update tests
• Diffs: CrossChainController implementation address change diffs
• Discussion

Copyright

Copyright and related rights waived via CC0.