#bedrock $BR 前阵子我遇到一件挺尴尬的事。某个 DeFi 协议发公告说要升级合约，要求用户手动迁移流动性。我按照教程操作，结果授权环节出了岔子，一笔 gas 费烧掉之后迁移失败了。再试一次，又失败。最后我在社群问了一圈，发现不是个例，是合约升级的兼容性问题。折腾了半个多小时才搞定，从那以后我对“协议升级”这四个字多了一层戒备。$ETH
后来看 @Bedrock 的文档，我专门去查了它的合约升级机制。
Bedrock 2.0 的架构里，核心合约比如 uniBTC 和 brBTC 的发行逻辑，并不是可以随意更换的。升级权限掌握在多签手里，而且多签方不是 Bedrock 自己一家。每次升级需要多个独立方共同签名才能执行。这套机制虽然不能完全消除“项目方作恶”的风险，但至少把门槛提高了。一个人说了不算，得一群人同意才行。
更让我留意的是，Bedrock 在升级这件事上，把很多参数做成了可配置而不是可替换。什么意思呢。有些协议要改一个收益率参数，就得把整个合约换掉，风险高、操作复杂。Bedrock 在设计之初就把常见参数比如费率、激励分配、池子权重等做成了可配置项，通过治理投票就能调整，不需要动核心合约。这样既保证了灵活性，又降低了升级带来的风险敞口。
我翻了一下它的历史审计报告。Bedrock 的核心合约经历了多家审计公司的交叉审计，包括慢雾和 CertiK。审计不能保证百分之百没漏洞，但多轮审计至少说明团队在安全投入上没有敷衍。$BTC
还有一个细节。Bedrock 的合约升级时间锁。任何非紧急的升级，触发之后会有一定的时间延迟才能生效。这个窗口期给了社区反应的时间。如果某个升级提案存在争议，社区可以在这段时间内发现问题并提出异议。这种设计在 DeFi 领域不算罕见，但真正严格执行的项目其实不多。
后来看 @Bedrock 的文档，我专门去查了它的合约升级机制。
Bedrock 2.0 的架构里，核心合约比如 uniBTC 和 brBTC 的发行逻辑，并不是可以随意更换的。升级权限掌握在多签手里，而且多签方不是 Bedrock 自己一家。每次升级需要多个独立方共同签名才能执行。这套机制虽然不能完全消除“项目方作恶”的风险，但至少把门槛提高了。一个人说了不算，得一群人同意才行。
更让我留意的是，Bedrock 在升级这件事上，把很多参数做成了可配置而不是可替换。什么意思呢。有些协议要改一个收益率参数，就得把整个合约换掉，风险高、操作复杂。Bedrock 在设计之初就把常见参数比如费率、激励分配、池子权重等做成了可配置项，通过治理投票就能调整，不需要动核心合约。这样既保证了灵活性，又降低了升级带来的风险敞口。
我翻了一下它的历史审计报告。Bedrock 的核心合约经历了多家审计公司的交叉审计，包括慢雾和 CertiK。审计不能保证百分之百没漏洞，但多轮审计至少说明团队在安全投入上没有敷衍。$BTC
还有一个细节。Bedrock 的合约升级时间锁。任何非紧急的升级，触发之后会有一定的时间延迟才能生效。这个窗口期给了社区反应的时间。如果某个升级提案存在争议，社区可以在这段时间内发现问题并提出异议。这种设计在 DeFi 领域不算罕见，但真正严格执行的项目其实不多。