Base安全指南：4份协议审计与从漏洞披露到修复的响应流程
Base安全指南：4份协议审计与从漏洞披露到修复的响应流程
Base 安全体系由两部分构成：公开的协议审计报告与漏洞披露响应流程。Base 是构建在以太坊上的 rollup，每一次网络升级（硬分叉）上线前都经过专业安全团队审计，审计报告直接存放在代码仓库中，任何人都可以查阅；发现漏洞后，社区成员可通过官方漏洞赏金渠道提交报告，项目方按既定流程完成响应与修复。
📁 4份协议审计报告的存放位置
所有审计报告集中在 audits/ 目录，按硬分叉名称分文件夹存放，覆盖 Base 最近4次网络升级：
| 硬分叉 | 审计报告 | 审计范围 |
|---|---|---|
| Azul | audits/azul/README.md | 通过 Immunefi 审计竞赛（2026年4月21日–5月4日）公开评审，报告发布于 Immunefi 官方报告站 |
| Beryl | beryl-b20.pdf、beryl-precompiles-storage.pdf | B20 代币合约、预编译合约与存储实现 |
| Cobalt | cobalt-b20.pdf、cobalt-dynamic-upgrades.pdf | B20 相关合约、动态升级机制 |
| Denim | denim-200ms-blocks.pdf、denim-b20-v3.pdf | 200ms 出块节奏变更、B20 代币 v3 合约 |
💡 命名规律：
beryl-b20指 Beryl 升级引入的 B20 代币合约，denim-200ms-blocks指 Denim 升级将出块间隔压缩到 200ms 的改动——文件名本身就说明了审计保护的核心对象。
🔍 审计报告保护的是什么
每次升级在代码中都对应一个激活时间戳，集中定义在 crates/common/genesis/src/chain/upgrade.rs，例如 Denim 是第4个 Base 专属升级，激活后 L2 出块间隔变为 200ms（约31天1300万块的保留量，见 .env.mainnet 注释）。
新升级如何引入、涉及哪些代码层，完整说明在 docs/guides/UPGRADES.md；升级前后的行为差异则通过动作测试验证，例如 actions/harness/tests/upgrade/denim.rs 专门测试"批次跨越 Denim 200ms 出块节奏的推导恢复"这一边界场景。
审计的价值在于：审计报告 + 仓库内可复现的升级测试，让社区可以独立核对"审计发现的修复是否真的进入了发布代码"。
🛡️ 漏洞披露渠道：两条官方赏金路线
SECURITY.md 定义了 Base 的漏洞报告入口，与 Coinbase 的赏金计划打通：
- HackerOne 计划：覆盖 Base 网络与基础设施的链下组件和服务（节点、批处理器、共识服务等本仓库代码）。
- Cantina 计划：500万美元赏金，覆盖 Base 所有已部署的智能合约，按 Tier 0 / Tier 1 分级划定范围。
- 其他安全相关咨询可联系
security@coinbase.com。
判断该走哪条渠道只需记住一句话：链下软件找 HackerOne，链上合约找 Cantina。
🔄 从披露到修复的响应流程
提交报告 → 项目方分诊确认 → 修复与回归测试 → 版本发布 → 审计/验收验证
- 提交与分诊：报告进入对应平台后按策略文档评估严重级别与范围。
- 修复与回归：修复提交合入仓库，CI 执行完整检查（
just ci/just pr，覆盖范围见 docs/guides/TESTING.md），关键升级路径由 acceptance/ 验收场景做端到端验证。 - 发布与验证：通过 baseup 工具安装发布二进制，节点方可升级到修复版本；重大协议变更还会补充新的审计材料放入
audits/。
🧪 开发者如何参与安全验证
- 阅读 audits/ 中对应版本的 PDF，对照 docs/guides/UPGRADES.md 理解升级代码路径；
- 本地跑通升级动作测试：
actions/harness/tests/下按硬分叉组织的测试（如 azul/、beryl/、upgrade/）； - 发现疑似漏洞后，先查
audits/是否已有相关披露，再按 SECURITY.md 的对应渠道提交报告。
把审计报告当作"安全基线"、把披露渠道当作"问题上报入口"，这就是参与 Base 安全体系的最短路径。