谁有权改 Layer2 的合约？代理、时间锁与升级权限的链上核查顺序

Layer2 不是装好就固定不动的软件。桥合约、排序器逻辑、证明验证器都可能被替换，替换动作在链上都是一笔交易。搞清楚“谁有权按下这个按钮、按下之前有没有等待期”，是判断一条二层链风险的关键一步，而且这件事完全可以在区块浏览器上查。

升级在链上长什么样

以太坊上的合约代码本身写死后不可修改，要换逻辑只能换一个地址，把用户合约做成一层代理：代理合约只负责把调用转发给“实现合约”，实现地址存在一个存储槽里。改逻辑就是调用代理的升级函数，写进一个新地址。OP Stack、Arbitrum 等各类二层的项目合约入口几乎都是这种形态，所以你在浏览器里看到的地址，往往只是代理，真正的逻辑在它背后指向的另一个地址。

要确认这一点，可以看代理地址的字节码是否很短、是否包含委托调用（delegatecall）痕迹；也可以查 EIP-1967 约定使用的实现槽位，槽位的十六进制位置是固定的，直接把对应存储值读出来就是实现合约地址。若项目没有遵循该标准，就只能从升级事件里找线索。升级执行时合约会发出事件，老实现地址和新实现地址都会出现在日志参数里，因此即使页面没标注，沿着浏览器里代理地址的“事件”标签也能还原出整条升级时间线：什么时候换过实现、每次是谁发起的、当时还顺带改了哪些配置项。这份时间线比任何宣传页都直接，因为它就是链上发生过的事实序列。

三个角色决定权限有多大

第一个角色是 proposer 或 updater，有权把新的状态根、批次或证明提交上链。第二个角色是升级者（常写作 guardian 或 admin），有权更换实现合约与关键参数。第三个角色是拥有这些权限的容器：可能是一把多签钥匙，也可能是一个时间锁合约，甚至是治理投票系统。

区别在于时间。如果升级者是一把 2/3 多签，一次合约更换可以在几分钟内完成，用户不会有任何预警窗口；如果多签之上还套了一个时间锁，提案必须先进入队列，等待一段固定延时才能执行，这段时间就是用户查看公告、选择提款的机会。也有的链把参数调整权限（比如给某个地址发放提交批次和提交证明的许可）放在延时较短的一把钥匙上，而把“换掉整套逻辑”的权限放在延时更长的流程后面，这种分层值得单独确认。

一份可执行的核查顺序

先在浏览器里打开这条链的桥或 Rollup 合约地址，看它是不是代理、实现地址是哪个，并记录两者的交易历史里有没有近期升级。接着从合约的方法列表里找权限相关函数，常见的名字包括设置实现地址、授予或撤销 proposer 与 prover 角色、设置挑战期长度等；调用它们的调用者地址，就是你要继续追的对象。然后打开那个地址：如果它显示为多签合约，通常能看到成员列表和签名阈值；如果是时间锁合约，通常能看到延时参数与待执行队列。

有三点容易误判。第一，查到多签成员是公开地址，不等于这些地址对应的自然人身份可确认，密钥归属仍需项目方披露。第二，时间锁的延时参数是链上事实，但“是否真的提前公告”是流程事实，只能在官方公告渠道核对。第三，链上权限清单是某一时点的快照，任何一次升级都会改写它；把核查结论用于决策前，最好同时看一眼该链最近几个月的升级记录。

以上是读机制、读链上字段的方法说明，不构成投资建议，也不表示任何合约在权限设计上更为安全。合约地址、角色命名与延时参数在不同链、不同版本上都有差异，请以该链官方文档与链上当前状态为准。