刚刚过去的 6 月，加密世界经历了一轮横跨多个环节的安全事件。
PeckShield 最新发布的月度安全报告显示，6 月共发生 40 起重大黑客攻击事件，总损失高达 7587 万美元，更值得警惕的是，这些攻击并没有集中在某一种攻击路径上，反而覆盖了钱包签名实现缺陷、L2 协议漏洞、第三方服务供应链攻击，多条防线在同一个月份内相继失守。
当 Web3 安全风险从单一入口扩展到整条链上交互路径，每一位用户都不得不重新思考一个问题：我的 Crypto 资产，究竟还安全么？
一、私钥之外，钱包底层签名实现的重要性
6 月发生在 Cardano 生态钱包 SecondFi 上的安全事件，是最直观的例子。
SecondFi 的前身是 Cardano 生态钱包 Yoroi。6 月 21 日至 23 日，攻击者从部分 SecondFi 用户地址中转走约 1600 万枚 ADA，涉及约 374 个钱包，按照事发时价格计算约为 240 万美元。SecondFi 随后表示，通过紧急措施另外保护了约 1.29 亿枚可能受到影响的 ADA。
这起事件最特殊的地方在于，受影响用户并没有主动把助记词交给攻击者，问题出在钱包底层的签名实现，按照安全机构 BlockSec 的分析，错误地从公开交易消息中推导签名 nonce，遗漏了标准实现所要求的秘密 nonce prefix。
这就使得每当用户使用受影响版本的钱包签署交易时，发布到链上的公开签名数据，都会暴露足以推导地址私钥的信息，因此攻击者不需要入侵用户手机，也不需要获得助记词，只需要分析公开的链上数据，就可能恢复对应地址的签名私钥。
从用户的角度看，钱包仍然在正常运行，毕竟助记词没有弹窗泄露，密码没有被破解，交易也确实由本人发起，但从密码学层面看，只要用户地址通过受影响版本产生过一些有效签名，公开的交易与签名数据就可能帮助攻击者推导出该地址的签名私钥。
说到底，钱包安全还要看是否正确生成私钥、是否严格按照密码学标准完成签名，以及这些关键代码能否被外部审查和验证，这也是核心钱包组件保持开源的重要性所在。
当然，这是特定钱包特定版本的实现缺陷，不是所有自托管钱包的普遍问题。以 imToken 的 TokenCore 为例，其核心代码仓库公开托管在 GitHub，覆盖密钥管理、地址派生和交易签名等底层钱包功能。
虽然开源并不意味着代码一定不存在漏洞，更不意味着用户可以完全放弃警惕，但对于钱包中最敏感的密码学和签名组件，开源至少提供了一个重要前提，那就是安全研究人员、开发者和社区可以检查代码、复现问题并持续测试，而不是只能相信一个无法验证的黑盒。
对于普通用户而言，这类事件也对应着几条更现实的安全原则。
- 首先，钱包应当始终通过官方网站或官方应用商店下载，并及时更新安全版本；
- 其次，不宜把所有资产都放在同一个日常交互钱包中，大额长期资产可以使用硬件钱包或独立冷钱包保存，与经常连接 DApp 的热钱包隔离。
- 更重要的是，一旦钱包官方确认出现密钥生成或签名实现层面的漏洞，仅仅把原来的助记词导入另一个钱包，通常并不能解决问题；
因为将同一组助记词导入其他钱包后，原来已经暴露的地址和私钥并不会发生变化。受影响资产需要转移至一个从未通过漏洞版本签名的新地址；对普通用户来说，更稳妥的做法通常是按照官方应急流程重新创建一组全新的钱包和助记词，再完成资产迁移，而不是自行反复导入或操作原有地址。
二、L2 不只是「更便宜的以太坊」，也是一整套复杂的信任链
除了钱包，6 月的多起事件还将风险指向了越来越复杂的 L2 系统。
6 月 14 日和18 日，两个与 Aztec 相关的旧版 Rollup 部署先后遭到攻击，合计损失约 435 万美元。
需要特别说明的是，遭到攻击的是已经进入遗留状态的 Aztec Connect 等旧版部署，并不等同于当前 Aztec Network 主网本身遭到攻击，但两起事件暴露的问题，对整个 ZK Rollup 领域都颇具警示意义。
在其中一起事件中，攻击者利用交易数量与实际处理数据之间的不一致，让系统在证明内部记入了一笔存款，却绕过了 L1 上对应的余额扣减流程。
另一起事件则源于零知识证明电路中的约束缺失，系统验证了一份形式上有效的证明，却没有确保该证明使用的私有状态树，与以太坊上真正用于结算的公开状态根完全一致，攻击者因此可以围绕一棵伪造的状态树生成证明，并从 L1 合约中提取资产。
这类问题很难用传统的「合约是否存在某一行漏洞代码」来概括。毕竟零知识证明可以证明某个计算过程符合既定规则，但前提是规则本身正确而完整，如果开发者忘记约束某个关键变量，证明仍然可能在数学上有效，却证明了一个与真实结算状态并不一致的结果。
Taiko 随后发生的安全事件，则暴露了另一种 L2 信任链风险。
6 月 22 日，Taiko 基于 SGX 的证明验证流程遭到利用，造成约 170 万美元损失。根据 BlockSec 的分析，攻击者使用了一把曾被提交至公开 GitHub 仓库的 SGX enclave 签名私钥，同时利用链上验证合约未拒绝 DEBUG 模式 Enclave 的缺陷，将恶意证明者注册为合法实例。
攻击者随后伪造 L2 状态证明，让以太坊上的合约接受了一项并不存在的 L2 状态，最终从桥接资金中提取资产，说到底，是因为用于签署可信执行环境的密钥被公开，远程认证规则又没有完整检查运行环境属性，最终使一份「通过认证」的证明失去了原本应有的可信含义。
与此同时，Base 在 6 月 25 日至 26 日连续出现主网区块生产停滞，Base 在事后复盘中表示，两次中断源于同一个区块构建逻辑缺陷：一笔执行失败的交易没有正确清理此前记录的状态，导致后续交易被错误计算 Gas，并生成了包含无效状态转换的区块。由于其他节点无法接受该区块，网络最终停止继续推进。Base 表示，事故期间链的完整性没有受到破坏，用户资金始终安全。
这并不是一起资产盗窃或外部攻击，而是一次影响网络可用性和恢复能力的技术故障。但从更广义的安全角度看，可用性本身也是 L2 安全模型的一部分。
因为对用户来说，一条链是否安全，不只取决于黑客能否伪造资产，还取决于区块能否持续生产，跨链桥能否正常工作，节点能否快速恢复，以及系统出现故障时，用户是否仍然拥有可行的退出路径。
所以用户在使用 L2 时，也不应只比较手续费和空投预期。对于规模较小、刚刚上线或安全机制仍在快速变化的 L2，尽量避免长期存放超出实际使用需求的大额资产；跨链前应确认使用的是官方桥，并了解提款时间、暂停机制和紧急退出方式；遇到网络停止出块、跨链异常或官方发布安全预警时，不要反复提交交易或继续桥接资产。
更稳妥的做法，是将不同用途和不同风险级别的资产分散管理，而不是把全部流动性押在同一条 L2、同一个跨链桥或同一种退出机制上。
三、合约没被攻破，第三方服务也可能把攻击带给用户
如果说钱包和 L2 的问题仍然发生在较为底层的技术组件中，那么 Polymarket 的事件则说明，距离用户最近的网页前端，同样可能成为资金入口。
6 月 25 日，Polymarket 表示，其使用的一家第三方供应商遭到入侵，攻击者借此向部分用户访问的 Polymarket 前端注入了恶意脚本。
根据安全机构及链上分析人员的统计，事件造成约 300 万美元用户资产损失，涉及约 11 个钱包。被盗资金随后从 Polygon 跨链至以太坊，并被兑换为约 1893 枚 ETH，不过后续 Polymarket 表示已经移除受影响的依赖，并将向受影响用户全额退款。
这起事件的关键在于，用户访问的可能仍然是正确的 Polymarket 域名，现有披露也并未指向 Polymarket 核心智能合约漏洞，问题主要出在网页加载的第三方前端依赖。
这也是一面镜子，如今多数 Web3 应用都不是完全运行在链上的，用户看到的网页，如交易界面，仍然大量依赖传统互联网基础设施和第三方软件包，其中任何一个依赖被攻击，都可能让合法网站向用户展示错误信息、替换收款地址，或者诱导钱包签署恶意交易。
因此，「网址是真的」并不必然等于「此刻加载的所有代码都是安全的」，「合约通过审计」也不等于用户与合约之间的整条交互路径都没有风险，面对这类前端和供应链攻击，普通用户很难独立检查网页加载的每一段代码，但仍然可以通过降低单次交互权限，限制潜在损失：
- 使用独立的 DApp 交互钱包：长期储蓄钱包尽量不要直接连接各种 DeFi、NFT、预测市场和空投网站，日常交互钱包只存放近期准备使用的资金，即便前端或授权出现问题，影响范围也相对有限；
- 签名前关注实际操作，而不是只看网页按钮：网页上写着「登录」「领取」或「确认订单」，并不代表钱包中弹出的签名也是同一件事；
- 网页出现异常时，不要依赖惯性继续操作：页面突然要求重新导入助记词、下载额外插件，或显示的交易内容与网页描述不一致，应暂停交互，通过项目的多个官方渠道确认情况，并检查或撤销不再使用的历史授权；
从钱包产品的角度看，这也意味着钱包承担的角色正在发生变化。
它不应只是一个保存私钥和弹出签名窗口的工具，还需要尽可能帮助用户理解交易意图、识别异常授权、展示资产变化，并在高风险交互发生之前提供足够清晰的警告。
但钱包也无法替用户消除所有风险。更现实的安全模型，是钱包、协议、L2、第三方服务商和用户共同缩小攻击面，而不是把全部责任推给任何一方。
写在最后
过去，人们常说，谁掌握私钥，谁就掌握链上资产。
这句话仍然成立，但并没有覆盖用户资产从「产生交易意图」到「完成链上结算」之间的全部过程，今天的 Web3 安全已经不只是保护一组助记词，而是保护从钱包生成密钥、展示交易、执行签名，到网络验证和最终结算的整条路径。
当然，这并不意味着用户需要远离所有链上交互，对于用户而言，真正有效的安全习惯，意味着需要把资产用途、风险级别和交互场景分开管理：长期资产重隔离，日常交互小额度，陌生 DApp 低授权，高风险操作多验证。
毕竟，当安全风险从一个点扩展为一条链，用户的防御，也必须从保护好私钥，升级成一套完整的习惯。
与大家共勉。