dymension
dymension copied to clipboard
Problem: Multiple RollApp using same chain-id prefix
Context: A RollApp owner already deployed their RollApp, for example: escan_9999-2.
When they want to state-breaking upgrade chain (hard-fork, remake),... they might want to upgrade with chain-id changed, like escan_9999-3
but someone else already obtained this chain id value, this might causes confuse or potential fishing vulnerability.
Suggestion:
- When chain
escan_9999-2
is registered, the prefixescan_9999
(pre dash "-" symbol) is reserved and no one else can create any chain with id has prefixescan_9999
. And require extra step to override/upgrade/update chain id like using genesis sequencer key to submit a message to Hub that authorize the new chain id with same prefix can be created. - After that, the previous chain id should be halted forever.
- Example request update chain-id:
- Case 1: Going through governance
- Case 2: Force upgrade using cli
Implementation proposal:
- First phase:
- Prevent register same chain-id prefix
- Implement API to check if user's input chain-id, during roll app creation, using a registered prefix of chain id
- Prevent user
- Increase fee for chain registration (prevent spamming & taking all good/vanity chain-id)
- (accepted consequence: can not update chain id before phase 2 released + must provide guideline to launch new roll app with different chain-id prefix)
- Second phase:
- Implement update chain-id through gov or force update using sequencer or smt like that: from
x_y-A
tox_y-B
, with conditionB = A + 1
, at specific height (mainly the same as normal software upgrade proposal).
- Implement update chain-id through gov or force update using sequencer or smt like that: from
Additional Notes
- Add cli to check if chain-id is already registered.
- By splitting into multiple-phase implementation, you have more time for finding good implementation as well as time for testing carefully.
thx for the feedback, it's indeed an important feature. Moving it to dymension hub repo
related to #294
@VictorTrustyDev can be closed? solved by dydns?
Hey @mtsitrin, this resolved by #294