Skip to content

Runtime Upgrade time lock #489

@n13

Description

@n13

We need to avoid a Drift style attack msig takeover for runtime upgrades

Design goals

  • Runtime upgrades allow us to update the runtime with important improvements and bugfixes
  • Nodes have no work upgrading servers
  • Can't be hacked - time lock prevents instant upgrades and theft
  • Time lock increases as chain matures - could be a function of block height, as block height increases, time to upgrade runtime also increases
  • In catastrophic circumstances we can still do what other chains do, everyone upgrades their node binary to basically create a hard fork
  • Time lock allows miners to vote down an upgrade or a similar mechanism where the collective can reject an upgrade

I think time lock alone growing from 24h to later a few days to later a week will be enough to prevent extraction attacks on this vector

The principle is always: You can vote with your feet.

Runtime upgrade is a great feature, but we will make sure it can't be exploited and it won't make the chain a centralized chain.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions