You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+214-6Lines changed: 214 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,17 +1,25 @@
1
1
<divalign="center">
2
2
<pre>
3
-
MOVEMENT => MAPTOS
3
+
MOVEMENT => MOVEMENT APTOS
4
4
</pre>
5
5
</div>
6
6
7
7
# `movement-to-movement-aptos`
8
8
9
-
Logic and validation of migration from [`movement`](https://github.com/movementlabsxyz/movement) state to [`movement-aptos`](https://github.com/movementlabsxyz/movement-aptos-core).
9
+
`movement-to-movement-aptos` herein abbreviated as `mtma` is the logic and validation of migration from [`movement`](https://github.com/movementlabsxyz/movement) to [`movement-aptos`](https://github.com/movementlabsxyz/movement-aptos-core).
10
10
11
11
## Getting started
12
12
To run or work with existing migration tools check the [CLI documentation](./docs/cli/README.md).
13
13
14
-
We otherwise recommend reading the [checks](./checks/README.md) and working down into the migration from there.
14
+
To get an initial grounding, we recommend spending 10-15 minutes reading the [checks](./checks/README.md) 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.
15
+
16
+
Once you have completed the above, review the following:
17
+
18
+
-**[Strategies](#strategies):** describes the different layers of abstraction against which the migration is performed and validated, as well as the reason for each.
19
+
-**[Environments](#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](#strategies)**. All **[Migrations](#migrations)** should be available in in all **[Environments](#environments)**.
20
+
-**[Migrations](#migrations):** describes the available migrations which have been implemented under the **[Strategies](#strategies)** above.
21
+
-**[Contexts](#contexts):** describes the different contexts (resp.) in which a **[Check](#checks)** can be run. Not all **[Checks](#checks)** make sense in all contexts. For example, some **[Checks](#checks)** only make sense in the `tracking` context.
22
+
-**[Checks](#checks):** describes the available checks for migration correctness. These are often implemented for a specific **[Strategy](#strategies)** but unified under the [`migrator`](#migrator) strategy.
15
23
16
24
## Contributing
17
25
@@ -26,9 +34,209 @@ Please see [CONTRIBUTING.md](CONTRIBUTING.md) file for additional contribution g
26
34
## Strategies
27
35
The migration is organized into passes, which are categorized as follows:
28
36
29
-
-[`node`](/migration/core/node) for migration passes that take place with access to node processes, memory, and disk.
30
-
-`transaction` is suggested but not broken out for all over-the-wire/transaction-based migration passes.
31
-
-[`migrator`](migration/core/migrator) for migration passes that take place with direct or indirect access to all other levels of abstraction--everything that is needed to migrate.
37
+
### [`node`](/migration/core/node)
38
+
Migration passes that take place with access to node processes, memory, and disk.
39
+
40
+
### [`migrator`](migration/core/migrator)
41
+
Migration passes that take place with direct or indirect access to all other levels of abstraction--everything that is needed to migrate.
42
+
43
+
> [!NOTE]
44
+
> 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.
45
+
46
+
## Environments
47
+
48
+
Environments are the different contexts in which **[Migrations](#migrations)** are expected to run.
49
+
50
+
> [!WARNING]
51
+
> Currently, this and its subcategories are suggestive. All **[Strategies](#strategies)**, **[Migrations](#migrations)**, and **[Checks](#checks)** have been written ad hoc and are mostly concerned with a local testing environment.
52
+
>
53
+
> Whether or not there is sufficient complexity to realize these Environments in types remains to be seen.
54
+
55
+
### `testing`
56
+
An environment intended for local `cargo`-based testing of the **[Migrations](#migrations)** and **[Checks](#checks)**.
57
+
58
+
### `box`
59
+
An environment intended for running **[Migrations](#migrations)** and **[Checks](#checks)** on a node which is participating in the migration and on which the appropriate signing keys are available.
60
+
61
+
### `provisioner`
62
+
An environment intended for running **[Migrations](#migrations)** and **[Checks](#checks)** from a node which shall provision the new network.
63
+
64
+
## Migrations
65
+
66
+
Migrations are subdivided by **[Strategy](#strategies)**.
67
+
68
+
> [!WARNING]
69
+
> 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.
70
+
71
+
> [!NOTE]
72
+
> 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.
73
+
74
+
### [`node`](./migration/core/node)
75
+
At the time of writing, we have planned or developed the following `node` migrations.
`mtma-node-replay` is a migration which replays transactions from `movement` on a `movement-aptos` executor to derive the intended state.
96
+
97
+
> [!WARNING]
98
+
> Currently, this migration is not passing on any **[Checks](#checks)** because of an issue with regenesis which prevents appropriately reading the execution config after replaying on the new `movement-aptos` executor.
99
+
100
+
### [`migrator`](./migration/core/migrator/)
101
+
At the time of writing, we have planned or developed the following `migrator` migrations.
Runs the [`post-l1-merge`](https://github.com/movementlabsxyz/movement-migration/issues/48#issuecomment-2828043486) OTA framework migration.
135
+
136
+
> [!WARNING]
137
+
> This is currently not available on this branch.
138
+
139
+
## Contexts
140
+
141
+
Contexts are the contexts in which checks are expected to run.
142
+
143
+
> [!WARNING]
144
+
> This category and its subcategories are currently suggestive.
145
+
146
+
> [!CAUTION]
147
+
> Not all **[Checks](#checks)** are intended to run in all Contexts.
148
+
149
+
### `snapshot`
150
+
The context wherein the migration and its checks have access to a safe version of the node which they may modify.
151
+
152
+
### `tracking`
153
+
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.
154
+
155
+
## Checks
156
+
157
+
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.
158
+
159
+
> [!WARNING]
160
+
> 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.
161
+
162
+
> [!NOTE]
163
+
> 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.
164
+
165
+
166
+
> [!NOTE]
167
+
> Several checks from [`primata/e2e-criteria`](https://github.com/movementlabsxyz/movement-migration/pull/47) are omitted here as they are still in fairly early development.
168
+
169
+
### `snapshot`
170
+
171
+
> [!WARNING]
172
+
> We would like to pull each of these out into a separate unit-test written crate a la [`balances-equal`](./checks/migrator/checks/balances-equal/) and generally reorganize the [`checks`](./checks/) to better match the updated ontology described herein.
173
+
>
174
+
> 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.
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.
0 commit comments