小区电梯老出故障，业主群里有人发了改造方案。我起初觉得票数多就能开工，后来才发现还要报价、评审、施工测试和验收。链上治理也容易被看快了：一份提案公开，只说明讨论有了正式载体，主网代码并不会立刻跟着变化。

Dusk把协议改动整理成DIP，也就是Dusk Improvement Proposal。官方流程从Idea开始，想法成形后进入Draft并获得编号；接着做出原型或技术成果进入Feedback；临近完成时转入Staging。涉及代码的DIP会先放到Nocturne测试网，收到共识后才标为Active，并把成果并入生产环境。#dusk

我喜欢这套流程的一点，是DUSK协议变更需要留下完整档案。提案要写动机、技术规格、取舍、向后兼容、测试、安全影响和实现链接。半年没有继续开发的Stagnant提案还可能进入Dead。以后回看一次升级，社区能够追到当时讨论过哪些风险，而非只看到新版本公告。
但“任何人能提交”不能直接推出“任何人都能改规则”。DIP编辑会参与审阅、编号、合并并跟踪实施；节点运营者还要安装包含改动的软件。当前公开说明没有给出一套按$DUSK 持仓计算的投票门槛，也没有把“取得共识”写成明确百分比。我不会把开放讨论包装成已经完成链上治理。

关注@Dusk 的升级时，我会分开核对四件事：DIP处于哪个状态、实现代码是否公开、Nocturne测试结果能否复查、主网节点何时采用。群里点赞只能说明想法受欢迎，Active和实际部署才说明Dusk规则走到了哪一步。