Tooling to migrate existing Optics v2 xApps to Abacus about hyperlane-monorepo HOT 3 CLOSED

Learnings from a Discord discussion:

The biggest issue here is that by upgrading to a new set of inboxes that are version V+1 and unenrolling inboxes from version V, any unprocessed inbound messages from version V inboxes are now totally void. The hard part is that right now, the domainToInbox mapping in XAppConnectionManager implies there can only be one inbox per domain. This actually isn't totally enforced at the contract level, because it's possible to enroll multiple inboxes for a single domain, it will just result in the domainToInbox being incorrect.

If we want to maintain the 1 inbox per domain invariant, things get kinda hard / messy:

If the application can guarantee that it doesn't have any unprocessed messages from version V inboxes that the application cares about and that the application only sends/receives inter-chain messages to itself, then it can upgrade by: on each chain, upgrading all outbox pointers to the version V+1 outboxes, then waiting for any possible messages from version V inboxes to be processed that may have been sent right before the outboxes were upgraded to V+1, and then finally once the application is confident there are no messages from version V inboxes that need to be processed, upgrading all inboxes to the V+1 inboxes. This is really hard to do between ensuring there are no unprocessed messages, ensuring that any un-processable messages are not an issue (i.e. think about messages that revert), and needing to submit a bunch of setOutbox and enrollInbox messages from an owner address in a specific order. This isn't really reasonable for a DAO or even a multisig to execute.

Alternatively, upgrading can be made a lot easier by not enforcing a 1 inbox per domain invariant on the XAppConnectionManager. If we perform the upgrade essentially as suggested by this issue by enrolling all the version V+1 inboxes first (not removing support for the previous inbox versions V), and then set the outbox to the version V+1, there is no downtime and no unprocessed messages are voided.

from hyperlane-monorepo.

We have made sufficient changes that there are now to kinds of migrations that we should talk about:

1. Migration from some version of an Abacus Relay to another.
2. Migration from the Optics Relay to an Abacus Relay.

This ticket should now encompass only 2), 1) should be covered by #416

For the existing apps on Optics v2, they will need contract upgrades to support things like gas payments, and thus the upgrade path probably looks closer to:

• Create an AbacusConnectionManager that enrolls both existing Optics v2 replicas and Abacus Inboxes/Outboxes
• Upgrade xApp Routers to the latest versions and set the abacusConnectionManager atomically (that will allow existing messages to continue to be relayed)

Obviously this is a pretty invasive operation and thus should be tested rather thoroughly. Special attention should be placed on the storage layout.

from hyperlane-monorepo.

Outdated

from hyperlane-monorepo.