genesis: add I/O/R chains to primary network registry#129
Open
hanzo-dev wants to merge 1 commit into
Open
Conversation
OracleVM, RelayVM, IdentityVM were previously registered as optional
VMs (loadable via CreateChainTx) but not part of the genesis-baked
primary network registry. Adding them to the registry means the VM
alias machinery + VMAliases map now know about all 14 primary-network
chains by canonical letter and alias set.
Order is append-only per the comment in registry.go — I/O/R land at
positions 12/13/14. Each row picks a unique alias triple:
I: identity, identityvm, id
O: oracle, oraclevm, feed
R: relay, relayvm, msg
This change does NOT bake I/O/R into FromConfig's primary-genesis
optIn loop — that would require new IChainGenesis/OChainGenesis/
RChainGenesis fields on genesiscfg.Config plus matching ichain.json/
ochain.json/rchain.json shards under genesis/configs/{net}/. I/O/R
continue to be instantiated via CreateChainTx post-genesis (as today).
What the registry update unblocks is the alias resolution path so
when those chains DO get created, the VM manager knows them by
canonical name without per-chain switch-ladder edits.
builder.Aliases() gets matching cases for the three new VMIDs so
when a future genesis bakes them, chain alias registration works
without further changes.
Existing tests in TestChainAliasesRegistryParity and TestVMAliasesRegistryParity
get three new rows each; both pass.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Add OracleVM (O-Chain), RelayVM (R-Chain), and IdentityVM (I-Chain) to the canonical primary-network chain registry at
genesis/builder/registry.go. These three chains were already registered as optional VMs innode/node/vms.go::registerOptionalVMs(loadable via CreateChainTx) but were absent from the registry, which means the alias machinery +VMAliasesmap didn't know about them by canonical letter or alias set.Order is append-only per the comment in registry.go — I/O/R land at positions 12/13/14. Aliases:
No alias collisions with existing rows (P/X/C/D/Q/A/B/T/Z/G/K).
What this does NOT do
FromConfig'soptInloop. Doing so requires:IChainGenesis,OChainGenesis,RChainGenesisfields ongenesiscfg.Config(andConfigOutput)ichain.json,ochain.json,rchain.jsonshards undergenesis/configs/{mainnet,testnet,devnet,localnet}/primaryChainShardFilesandchainSetingenesis/configs/configs.gobuilder.Aliases()registers their chain aliases without further switch-ladder edits.Builder.Aliases() update
Mirroring the existing 11-case switch ladder, I added three new cases for
constants.{IdentityVMID, OracleVMID, RelayVMID}so genesis-baked I/O/R chains get correct API + chain alias registration when that future-bake change lands.Test plan
go build ./genesis/builder/...— cleango test ./genesis/builder/... -count=1— 22 tests pass, 0 failTestChainAliasesRegistryParityextended with 3 new subtests (I/O/R) — all passTestVMAliasesRegistryParityextended with 3 new VMID entries — passesNotes
IdentityVMID,OracleVMID,RelayVMIDexist ingithub.com/luxfi/constants/vm_ids.go(lines 49-54). Same import already used by registry.go.builder.Aliases()lists"kms"as an API alias even though the Registry uses"key"— pre-existing divergence, not touched here. New I/O/R cases use the same alias triple in both Registry and Aliases() consistently.vms/platformvm/go.modandvms/xvm/go.modfiles exist on disk as untracked submodule splits (not committed). They shadow the parent module's directory tree and break the build. Moved them aside for local build; CI should not see them.