BGD. Technical maintenance proposals

Development
39

a.DI v1.1 Shuffle activation


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:

Origin Network Ethereum Polygon Avalanche Arbitrum Optimism Base Gnosis Metis Binance Scroll
Ethereum - 4 2 1 1 1 2 1 2 1
Polygon 3 - - - - - - - - -
Avalanche 2 - - - - - - - - -
Arbitrum - - - - - - - - - -
Optimism - - - - - - - - - -
Base - - - - - - - - - -
Gnosis - - - - - - - - - -
Metis - - - - - - - - - -
Binance - - - - - - - - - -
Scroll - - - - - - - - - -

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:

Network CCC v1.1 implementation with Shuffle support
Ethereum 0x92f4736b72d131d836b3e4d4c3c23fe53150ce4d
Polygon 0x191f2bd27f1ce4318f9a0c6b82688c66cd7ad3ba
Avalanche 0x23f5150ace7382c7160a2192c3f9f77444f420d9
Arbitrum 0x92f4736b72d131d836b3e4d4c3c23fe53150ce4d
Optimism 0x92f4736b72d131d836b3e4d4c3c23fe53150ce4d
Base 0x92f4736b72d131d836b3e4d4c3c23fe53150ce4d
Gnosis 0x88e9f8e208ba5ae72b56861d63cbf70fd2320f5c
Metis 0x92f4736b72d131d836b3e4d4c3c23fe53150ce4d
Binance 0xda81fb369942e43d4797e79f2c4cbef9fe58b90a
Scroll 0x92f4736b72d131d836b3e4d4c3c23fe53150ce4d

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
2 Likes