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
+117-5Lines changed: 117 additions & 5 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,12 +34,116 @@ 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
-
-[`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.
31
42
32
43
> [!NOTE]
33
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.
34
45
46
+
## Environments
47
+
48
+
> [!WARNING]
49
+
> 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.
50
+
>
51
+
> Whether or not there is sufficient complexity to realize these Environments in types remains to be seen.
52
+
53
+
### `testing`
54
+
An environment intended for local `cargo`-based testing of the **[Migrations](#migrations)** and **[Checks](#checks)**.
55
+
56
+
### `box`
57
+
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.
58
+
59
+
### `provisioner`
60
+
An environment intended for running **[Migrations](#migrations)** and **[Checks](#checks)** from a node which shall provision the new network.
61
+
62
+
## Migrations
63
+
64
+
Migrations are subdivided by **[Strategy](#strategies)**.
65
+
66
+
> [!WARNING]
67
+
> 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.
68
+
69
+
> [!INFO]
70
+
> 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.
71
+
72
+
### [`node`](./migration/core/node)
73
+
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.
94
+
95
+
> [!WARNING]
96
+
> 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.
97
+
98
+
### [`migrator`](./migration/core/migrator/)
99
+
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.
133
+
134
+
> [!WARNING]
135
+
> This is currently not available on this branch.
136
+
137
+
## Contexts
138
+
139
+
## Checks
140
+
141
+
> [!WARNING]
142
+
> 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.
143
+
144
+
> [!INFO]
145
+
> 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.
146
+
35
147
## Organization
36
148
37
149
There are five subdirectories which progressively build on one another for node logic.
0 commit comments