跨链协议安全性的重要性及LayerZero的不足

跨链协议的安全性问题近年来备受关注。从过去两年各区块链上发生的安全事件造成的损失金额来看，跨链协议相关的安全事件损失位居榜首。解决跨链协议安全问题的重要性和紧迫性甚至超过了以太坊扩容方案。跨链协议之间的互操作性是Web3生态系统连接成网的内在要求。这类协议通常获得巨额融资，其总锁仓价值(TVL)和交易笔数也在刚性需求驱动下日益增长。然而，由于大众对这些协议的辨识度不高，难以准确评估它们的安全等级。

让我们先来看一个典型的跨链产品设计架构。在Chain A和Chain B之间的通信过程中，由Relayer执行具体操作，Oracle则对Relayer进行监督。这种架构的优点是避免了传统方式中需要第三条链（通常不部署dApp）来完成共识算法以及多个节点验证的复杂过程，因此能为终端用户带来"快速跨链"的体验。由于架构轻便，代码量少，且可以直接使用现成的Chainlink作为Oracle，这种类型的项目容易快速上线，但同时也容易被模仿，技术门槛几乎为零。

然而，这种架构至少存在两个问题：

1. 将数十个节点的验证过程简化为单一Oracle验证，大幅降低了安全系数。

2. 在简化为单一验证后，必须假设Relayer和Oracle是相互独立的。这种信任假设难以永久成立，不符合加密货币原生理念，无法从根本上保证二者不会合谋作恶。

某些跨链协议采用了这种基本模式。作为独立安全类型的"超轻量级"跨链方案，它们仅负责传递消息，并不对应用的安全性负责，也没有能力承担这种责任。

即便允许多方运行中继器，也无法彻底解决上述问题。首先，去中心化并不仅仅意味着运行者数量增加或人人都可以接入。需求端一直都是无需许可的，让供给端也变成无需许可并不是划时代的变革，这只是市场端的变化，与产品本身的安全性关系不大。某些协议的Relayer本质上只是负责转发信息的中介，与Oracle一样，都属于受信任的第三方。试图通过将受信主体从1个增加到30个来提高跨链安全性是徒劳的，不仅没有改变产品特性，还可能引发新的问题。

如果一个跨链代币项目允许修改配置的节点，那么就有可能被攻击者替换为其自己的节点，进而伪造任意消息。从结果来看，使用这种协议的项目仍然可能面临巨大的安全隐患，且这种问题在更复杂的场景下会更加严重。在庞大的系统中，只要有一个环节被替换就可能引发连锁反应。某些跨链协议本身并不具备解决这个问题的能力，如果真的出现安全事故，它们很可能会将责任推给外部应用。

如果某个协议不能像Layer1、Layer2那样共享安全性，那它就不能被称为基础设施。基础设施之所以"基础"，是因为它能共享安全性。如果某个项目自称是基础设施，那就应该像其他基础设施一样为其所有生态项目提供一致的安全性，即所有生态项目共享该基础设施的安全性。因此，准确地说，某些跨链协议并不是基础设施，而是中间件。接入这种中间件SDK/API的应用开发者确实可以自由定义他们的安全策略。

一些研究团队曾指出，假设应用所有者（或拥有私钥的人）不会作恶是不正确的。如果恶意行为者获得了跨链协议配置的访问权限，他们可能会将预言机和中继器从默认组件更改为由他们控制的组件，从而操纵使用该机制的智能合约，导致用户资产被盗。

此外，有研究表明，某些跨链协议的中继器存在关键漏洞。虽然目前处于多重签名状态，这些漏洞只能由内部人员或已知身份的团队成员利用，但仍然存在潜在风险。这些漏洞可能允许从多重签名发送欺诈性消息，或在预言机和多重签名签署消息或交易后修改消息，都可能导致所有用户资金被盗。

回溯比特币的本源，我们可以看到中本聪在白皮书中提出的核心理念：一种完全的点对点电子货币系统，允许在线支付直接从一方发送到另一方，无需通过金融机构。这一理念强调了去中心化和无需信任的特性，这也成为后来所有基础设施开发者共同追求的目标。

然而，某些跨链协议在实际运作中要求Relayer、Oracle这两个角色不会合谋作恶，同时要求用户将使用该协议构建应用的开发者视为可信赖的第三方。参与"多签"的受信主体都是被事先安排好的特权角色。更重要的是，在整个跨链过程中没有产生任何欺诈证明或有效性证明，更不用说将这些证明上链并进行链上验证。因此，这些协议实际上并不满足"中本聪共识"，不能被称为真正的去中心化和无需信任的系统。

在面对安全问题时，一些跨链协议的回应态度往往是"否认"再"否认"。然而，历史告诉我们，比特币之前就有很多电子货币尝试，但都失败了，因为它们都没有达成去中心化、抗攻击和自带内在价值的目标。跨链协议也是如此，无论融资规模多大、用户流量多高、"血统"多么纯正，只要产品无法实现真正的去中心化安全，大概率会因为抗攻击能力不足而最终失败。

构建真正去中心化的跨链协议是一个复杂的挑战。一些新兴的解决方案，如使用零知识证明技术来升级跨链协议，可能会为这一领域带来新的突破。然而，关键在于协议开发者是否认识到自身存在的问题，并愿意采取必要的措施来改进。