Conversation
|
|
||
| - Is globally unique within a Movement network | ||
| - Is used directly in transaction operations | ||
| - Is derived from the account's authentication key at creation |
There was a problem hiding this comment.
Is the same address derived on any chain, i.e. cross-chain replay risk? the security considerations imply this is the case, maybe worth mentioning here
| ## Introduction | ||
|
|
||
| Blockchains in the "movement" namespace are identified by their numeric `chain_id`; | ||
| each network is maintained by a set of validators with its own REST API and |
There was a problem hiding this comment.
how do you find out those endpoints from just the chainId? is there a canonical registry, like the ethereum-lists/chains registry on github?
| each network is maintained by a set of validators with its own REST API and | ||
| indexer endpoints. Movement is a Layer 2 network built on Move, featuring | ||
| parallel execution for high throughput. | ||
|
|
There was a problem hiding this comment.
I'd recommend adding a ## Governance section to explain who approves/decides chainIds, who governs the registry of chainIds, and who governs the protocol upgrades/forks/changes.
|
|
||
| Blockchains in the "movement" namespace are identified by their numeric `chain_id`; | ||
| each network is maintained by a set of validators with its own REST API and | ||
| indexer endpoints. Movement is a Layer 2 network built on Move, featuring |
There was a problem hiding this comment.
I would probably explain better here the exact parameters of:
- how the Layer 2 anchors to Eth (these vary widely across eth L2s)
- what, if any, access to those "anchoring" mechanics are available to accounts and devs on the movement L2, e.g. how natively can tokens or assets be moved between Eth mainnet or other L2s and movement
- what, if any, interop with sui or other Move-runtime is built in
|
|
||
| ### Backwards Compatibility | ||
|
|
||
| Not applicable |
There was a problem hiding this comment.
You might want to mention either in this section or in ## Security Considerations how collisions with EVM chainIds are handled, since, e.g., movement:250:0x1234deadbeef and evm:250:0x1234deadbeef addresses can both be valid addresses... and maybe even generated from the same private key (i.e. replay attacks?)
bumblefudge
left a comment
bumblefudge
left a comment
There was a problem hiding this comment.
This is technically valid/complete as is, but I would recommend addressing the questions I raised because the dual-VM layer2 with its own chainId registry is kind of a special-case and a developer just thinking of it as an eth L2 or a move [L1] chain might well footgun themselves...
2 participants
Add Movement namespace
This PR introduces the Movement namespace to the ChainAgnostic namespaces registry.
Added Files
movement/README.md- Namespace profile for Movement Networkmovement/caip2.md- CAIP-2 chain identification specification for Movementmovement/caip10.md- CAIP-10 account identification specification for MovementSummary
Movement is a Layer 2 network built on Move, featuring parallel execution for high throughput. This PR establishes the
movementnamespace for identifying Movement-based chains and accounts.Chain Identification (CAIP-2)
Chains in the Movement namespace are identified by their numeric
chain_id, which is assigned at genesis and requires no transformation to be used as a CAIP-2 reference.movement:126movement:250Account Identification (CAIP-10)
Movement accounts are identified by 32-byte hexadecimal addresses with a
0xprefix. Account identifiers follow the formatmovement:<chain_id>:<address>.Example:
movement:126:0xd5fb7899ac1e3b4a51bfbf0dcafaa78453bb8e9a64a93a8e47fedad6b8c48171Resolution
Chain IDs can be resolved by querying the REST API of any Movement fullnode:
The
chain_idfield in the response provides the identifier.Account existence can be verified via:
References