合约升级：绘制谁能改变规则的权限图
合约升级研究要回答谁能改变影响资产行为的代码或参数。读取表面代币接口只是开始，应追踪代理、实现、管理员、授权路径以及延时和紧急权限，再讨论部署是否不可变或去中心化。
OpenZeppelin 代理参考介绍多种升级组件和模式。这些是可能采用的构件，不证明某项目确实采用其中一种，也不证明权限配置安全。
绘制权限链
确认实际部署地址，结合部署记录和状态判断是否存在代理关系。如果存在，保存观察区块对应的实现。今天展示的实现代码，不一定是过去某笔交易生效时的代码，历史与当前分析必须分开。
继续追踪授权。管理员可能是另一个合约、多签账户或治理流程，沿关系找到可理解的控制条件。仅写“由治理控制”不够，因为另一个紧急密钥可能绕过通常流程。
| 图中节点 | 需要保留的证据 |
|---|---|
| 用户接触的部署 | 地址、网络、区块 |
| 实现 | 代码身份与版本关系 |
| 升级授权方 | 批准变化的角色或账户 |
| 授权方控制 | 签名者、阈值或治理规则 |
| 延时与例外 | 正常等待及绕过权限 |
| 历史变化 | 交易、原状态和新状态 |
代码升级与参数管理分开。代码固定的部署仍可能允许修改设置；反过来，存在升级结构，也可能有明确限制后的权限安排。应按实际配置而非标签判断。
假设案例：延时升级与立即改参并存
假设虚构协议宣传两天升级延时，普通升级确实经过时间锁；但另一个角色可以立即修改影响转账的参数。若研究笔记写成所有规则变化都需要两天，就超过证据范围。
正确图谱应分别画出延时的代码升级和立即的参数修改路径。紧急角色控制者无法核实时，继续标未知，不因为论坛评论猜测就归给某团队。这里的主体和时间均为假设，不描述真实协议。
如果研究截止后实现变更，应保留历史版本，另开新版本复核任务。不能用最新实现悄悄覆盖旧笔记，否则读者无法知道当时结论依据什么。
将宣传改写为可核查问题
收集项目关于不可变、治理和管理权的说法，再转成具体问题：哪个函数、哪个授权方、多久延时、有哪些例外？宽泛口号很难验证，精确权限主张才可以对照代码和状态。
近期升级与角色变更事件可作线索，随后确认结果状态。事件日志帮助定位变化，但不能代替核查当前相关权限。注明结论依赖已验证源码、字节码分析、正式部署资料还是第三方总结。
公开研究可能不包含完整代码审计，应明确范围。即使无法判断实现的全部后果，查清谁能改变规则仍有价值，但权限图不能保证代码安全，也不意味着已经审查所有执行路径。
边界与常见错误
未知控制者、复杂委托、未披露流程和跨网络依赖，都可能使部分图谱无法完成。用未知节点交付部分图，不要把缺证据翻译为不存在权限。
常见错误包括只读实现代码、把多签标签当成已核实签名政策、把某项延时扩大到所有动作，以及认为代码固定就意味着经济行为固定。本方法支持带日期的控制依赖描述，不预测授权人会怎样行动，也不产生现货收益预期。
常见问题
源码已验证是否证明部署无法改变？
不是。源码对应性与升级权限回答不同问题，还需检查部署关系和相关授权。
有时间锁就能证明所有动作都延迟吗？
不能。应检查哪些动作经过时间锁，以及是否存在独立角色或紧急路径。