MOVEMENT => MOVEMENT APTOS
movement-to-movement-aptos herein abbreviated as mtma is the logic and validation of migration from movement to movement-aptos.
We have a video motivating, abstracting, and demonstrating this repository. Please review it here.
To run or work with existing migration tools check the CLI documentation.
To further your initial grounding, we recommend spending 10-15 minutes reading the checks and working down into various elements of the API from there. This should provide you with a sense of both the high-level requirements against which we are attempting to implement and validate as well as the approaches we are taking to perform the migration.
Once you have completed the above, review the following:
- Strategies: describes the different layers of abstraction against which the migration is performed and validated, as well as the reason for each.
- Environments: describes the different contexts (resp.) in which migration and check logic is run. These are usually wrapped up under the enum for a given Strategy. All Migrations should be available in in all Environments.
- Migrations: describes the available migrations which have been implemented under the Strategies above.
- Contexts: describes the different contexts (resp.) in which a Check can be run. Not all Checks make sense in all contexts. For example, some Checks only make sense in the
trackingcontext. - Checks: describes the available checks for migration correctness. These are often implemented for a specific Strategy but unified under the
migratorstrategy.
| Task | Description |
|---|---|
| Upcoming Events | High-priority event issues with planned completion dates. |
| Release Candidates | Feature-complete versions linked to events. |
| Features & Bugs | High-priority feature and bug issues. |
Please see CONTRIBUTING.md file for additional contribution guidelines.
The migration is organized into passes, which are categorized as follows:
Migration passes that take place with access to node processes, memory, and disk.
Migration passes that take place with direct or indirect access to all other levels of abstraction--everything that is needed to migrate.
Note
An additional class of strategies chain and transaction have been suggested but not broken out for all over-the-wire/transaction-based migration passes. Simply use the migrator instead.
Environments are the different contexts in which Migrations are expected to run.
Warning
Currently, this and its subcategories are suggestive. All Strategies, Migrations, and Checks have been written ad hoc and are mostly concerned with a local testing environment.
Whether or not there is sufficient complexity to realize these Environments in types remains to be seen.
An environment intended for local cargo-based testing of the Migrations and Checks.
An environment intended for running Migrations and Checks on a node which is participating in the migration and on which the appropriate signing keys are available.
An environment intended for running Migrations and Checks from a node which shall provision the new network.
Migrations are subdivided by Strategy.
Warning
This section is a WIP in progress. Its contents are intended as aspirational. However, links below to CLIs and documentation should ultimately be valid and currently link to informative material.
Note
Multiple CLI paths are often shared for usability. Owing to the compositional approach this repository uses to CLI development, the logic should assumed be the same at each CLI path unless otherwise noted below or in the CLI documentation itself.
At the time of writing, we have planned or developed the following node migrations.
- CLI
mtma-node-null is a migration that does not attempt to make any changes to the the existing databases. It is a copying of node state files.
- CLI
mtma-node-replay is a migration which replays transactions from movement on a movement-aptos executor to derive the intended state.
Warning
Currently, this migration is not passing on any Checks because of an issue with regenesis which prevents appropriately reading the execution config after replaying on the new movement-aptos executor.
At the time of writing, we have planned or developed the following migrator migrations.
- CLI
Rewraps the mtma-node-null migration for the migrator.
- CLI
Runs the pre-l1-merge OTA framework migration.
Warning
This is currently not available on this branch.
- CLI
Runs the post-l1-merge OTA framework migration.
Warning
This is currently not available on this branch.
Contexts are the contexts in which checks are expected to run.
Warning
This category and its subcategories are currently suggestive.
Caution
Not all Checks are intended to run in all Contexts.
The context wherein the migration and its checks have access to a safe version of the node which they may modify.
The context wherein the migration is presumed to already have run and the checks will continue to track a certain set of criteria against live traffic.
Checks are the criteria for migration correctness. Ultimately, they are intended to be used under mtma checked-migration to ensure a performed migration satisfies correctness as defined by the criteria described in the Checks.
Warning
This section is a WIP in progress. Its contents are intended as aspirational. However, links below to CLIs and documentation should ultimately be valid and currently link to informative material.
Note
Multiple CLI paths are often shared for usability. Owing to the compositional approach this repository uses to CLI development, the logic should assumed be the same at each CLI path unless otherwise noted below or in the CLI documentation itself.
Note
Several checks from primata/e2e-criteria are omitted here as they are still in fairly early development.
Warning
We would like to pull each of these out into a separate unit-test written crate a la balances-equal and generally reorganize the checks to better match the updated ontology described herein.
The need for separate crates is driven by some awkward Tokio behavior when dropping various runtimes associated with the movement and movement-aptos embedded runners.
- CLI
- Tests
Checks whether the global storage from movement is present in movement-aptos.
- CLI
- Tests
Checks whether the global storage from movement is injective into the codomain of movement-aptos state keys.
- CLI
- Tests
Checks that both movement and movement-aptos global storage are not empty.
- CLI
- Tests
Checks that both movement and movement-aptos accounts are equivalent in bcs representation. Amongst other things, this should ensure that asymmetric cryptography for accounts is preserved.
- CLI
- Tests
Checks that both movement and movement-aptos balances for the native token are equal.
Note
This category is completely suggestive. We haven't implemented anything here yet.
There are three subdirectories which progressively build on one another for node logic.