Comments (3)
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:
- Migration from some version of an Abacus Relay to another.
- 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.
Related Issues (20)
- Less flaky heuristic for determining if a Mailbox is initialized or not
- Epic: HaaS improvements
- Relayer should handle IGP gas to exceed block gas limit
- feat(cli): warp apply multisig submitter
- feat(cli): core apply multisig submitter
- fix(cli): Insufficient balance should display appropriate error
- [BUG] warp init outputting an empty {} HOT 1
- Validator checkpoint_latest_index.json is not set if the checkpoint latest index is 0
- E2E tests of Rust implementations should not require GCP credentials
- Epic: Solana scraper support
- Scraper sealevel support: fully implement `HyperlaneProvider` for `SealevelProvider`
- Successfully scrape Sealevel chains in e2e test
- Deploy scraper with Sealevel chains like Solana / Eclipse
- Scrape protocol fee hooks on all VMs
- fix(cli): Bug bash CLI 5.0 issues
- Deployment failed on Oasis Sapphire Mainnet(EVM)
- chore(cli): Increase coverage to cli e2e tests with warp apply
- modern C++
- Hyperlane Keep a extended proposeblock API with assignment check in proverset to support proposer and prover separation
- Document LayerZero Community Hook/ISM
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hyperlane-monorepo.