Background
As we have to add support for appchain transaction re-execution on the Supra-L1, we need to manage specific categories of data at the move-layer and to maintain this data, new Move modules are required.
We need to implement the following new modules under the supra-framework package. Detailed specifications are provided in the Modules Specifications section:
- Microchain Registry Module
- Funnel Nodes Registry Module
Modules Specifications
1. Appchain Registry
A module that keeps a record of registered microchains. It will be deployed under the supra-framework package on the L1.
Appchain States
Each appchain can exist in one of the following states:
- Unknown: The chain has never been registered.
- Active: Registered and fully operational.
- Inactive: Registered but decommissioned from L1.
Permissions
Only supra-governance can:
- Register a new appchain.
- Change the state of an existing appchain to
Inactive.
- Update the metadata link of a registered appchain.
Behavioral Rules
-
When a new appchain is registered, or an existing appchain is transitioned to Inactive state; the updated information becomes effective only after the next epoch change, and L1 supra-validators must respect the updated state.
-
L1 supra-validators must process blocks only for appchains in the Active state and stop processing blocks for appchains that are moved to Inactive.
Chain ID Requirements
- Every registered appchain must have a unique chain ID.
- Certain reserved ranges of chain IDs will be disallowed; registrations using those ranges must be rejected.
- Current
chain_id type is u8, and it's being discussed with Isaac that we can plan to update to u16, therefore, in module accept chain_id with u16 type.
2. Funnel Nodes Registry
A move module that keeps a list of registered funnel nodes' IP/DNS addresses. It will be deployed under the supra-framework package on the appchain.
Permissions
Only appchain-governance can:
- Add new funnel nodes.
- Remove existing funnel nodes.
- Replace one funnel node with another.
Behavioral Rules
- Any update to the funnel node registry becomes effective only after the next epoch change.
- For relaying blocks to L1, the appchain will elect exactly one funnel node at a time from the registered list.
Background
As we have to add support for appchain transaction re-execution on the Supra-L1, we need to manage specific categories of data at the
move-layerand to maintain this data, new Move modules are required.We need to implement the following new modules under the
supra-frameworkpackage. Detailed specifications are provided in theModules Specificationssection:Modules Specifications
1. Appchain Registry
A module that keeps a record of registered microchains. It will be deployed under the
supra-frameworkpackage on the L1.Appchain States
Each appchain can exist in one of the following states:
Permissions
Only
supra-governancecan:Inactive.Behavioral Rules
When a new appchain is registered, or an existing appchain is transitioned to
Inactivestate; the updated information becomes effective only after the next epoch change, and L1supra-validatorsmust respect the updated state.L1
supra-validatorsmust process blocks only for appchains in theActivestate and stop processing blocks for appchains that are moved toInactive.Chain ID Requirements
chain_idtype isu8, and it's being discussed with Isaac that we can plan to update tou16, therefore, in module acceptchain_idwithu16type.2. Funnel Nodes Registry
A move module that keeps a list of registered funnel nodes'
IP/DNSaddresses. It will be deployed under thesupra-frameworkpackage on the appchain.Permissions
Only
appchain-governancecan:Behavioral Rules