如何判断团队是否还能改动合约

问题之下的问题

“团队能改动合约吗”其实是三个问题，把它们混在一起，正是人们得到的答案让人困惑的原因。

• 代码本身能否被替换？这就是可升级性，也是最大的那根杠杆。
• 代码里的某个数值能否在不替换代码的情况下被改动？费率、上限、地址、转账是否被暂停。
• 谁被允许拉动这两根杠杆，有没有什么东西能拖慢他们？单一密钥、多签、投票、延时。

一个合约可以是不可变的，同时允许某个地址掏空储备——只要代码这么写。一个合约可以是可升级的，而实践中仍然安全——只要升级需要一周加一次投票。单凭这个词本身，什么也说明不了。

第一步：源码是否公开，是否对得上

在区块浏览器上，未验证的合约只显示字节码，别无其他。已验证意味着有人上传了源码，且它编译出来正好是那段字节码。如果源码未经验证，到此为止：你没法核查其他任何东西，别人是在要求你信任一张截图。

已验证的源码是必要条件，不是充分条件。公开的东西可能是诚实的，同时仍然赋予部署者你不会接受的权力。

第二步：它是不是代理合约

代理合约持有你的资金，并把每一次调用转发给第二个持有逻辑的合约。改掉第二个地址，行为就完全变了，而你交互的那个地址纹丝不动。多数升级是这样实现的，多数能通过审计的卷款跑路也是这样实现的。

• 浏览器通常会标出来：一个“Read as Proxy”标签页，或者一条说明该地址是代理的提示。
• 在源码里，找一个设置实现地址的函数——名字各异，形状不变。
• 如果它是代理，唯一要紧的问题就是谁能调用那个函数，以及生效有多快。

第三步：拥有者能做什么

把源码里由 owner 或 admin 角色守卫的函数读一遍，把它们当作一份清单：这些事可以在你不同意的情况下发生在你身上。各项目的命名不同，形状到处都一样：

• 铸造。能否在已公布的规则之外创造新单位？写在文档里的供应上限不是上限；写在代码里的才是。
• 提取。有没有一条路径，能让抵押品在没有用户要求的情况下离开？
• 暂停。转账或赎回能被停掉吗？谁来重启？
• 费用。代码里有没有上限，还是费率可以被设成任意值？
• 名单。某个地址能被禁止卖出吗？代币就是这样变成单向门的。

对每一项，有用的追问不是“他们会不会这么做”，而是“什么能拦住他们”。答案要么是代码里的一条规则，要么什么都不是。

第四步：谁持有密钥，什么能拖慢它

单个外部账户意味着一个人、一封钓鱼邮件、一次被迫的签名。多签更好，而且数字很重要：五取三是一个委员会，三取一是穿了戏服的单点。延时锁并不阻止某个动作；它给你预告，而这正是要点——你可以在它生效之前离开。

代币投票治理把问题又挪了一次：现在的问题是谁持有代币。如果少数几个地址就能通过任何议案，那么投票只是多绕了几步的形式。

审计能解决什么，不能解决什么

审计检查代码是否做了作者想让它做的事，以及能否被攻击者攻破。它不告诉你这个设计本身是不是你想要的。一份合约可以干净地通过审计，同时仍然包含一个掏空储备的拥有者函数——因为那个函数是有意为之且已披露的。读报告要先读范围：审了什么、审的是哪个提交、排除了什么。

省时间的顺序

• 源码验证了吗？没有就到此为止。
• 是代理吗？是的话，查清谁能换实现、多快生效。
• 拥有者函数：铸造、提取、暂停、费用、拉黑。逐项记下。
• 密钥持有者：单一密钥、真实数字的多签，还是投票。
• 延时：有没有延时锁，够不够你据此行动。
• 最后才读审计，而且先读范围再读结论。