ADI Shuffle Update

Share on X
Raw-Ipfs
For

865.71K

Against

0

Voters

Voting power

Support

aci.eth

374.58K

For

ezr3al.eth

224.07K

For

areta...v.eth

108.58K

For

0x2cc...54Df1

46,218.39

For

winte...e.eth

44,707.69

For

Payload 1/10
Show more
Created

5 Aug 2024, 2:12 PM

Open for voting

6 Aug 2024, 2:29 PM

Voting closed

9 Aug 2024, 2:30 PM

Passed

Finished

10 Aug 2024, 4:02 PM

Executed

ADI Shuffle Update

Created

5 Aug 2024, 2:12 PM

Open for voting

6 Aug 2024, 2:29 PM

Voting closed

9 Aug 2024, 2:30 PM

Passed

Finished

10 Aug 2024, 4:02 PM

Executed

Author

BGD Labs @bgdlabs

Creator

0xf71fc92e2949ccF6A5Fd369a0b402ba80Bc61E02

Copy

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 NetworkEthereumPolygonAvalancheArbitrumOptimismBaseGnosisMetisBinanceScroll
Ethereum-421112121
Polygon3---------
Avalanche2---------
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:

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.

by BGD Labs