作者：0xOar

出品：Seer Labs

前言：

最近频繁的跨链安全问题引起了市场的广泛关注。本文希望从产品设计的角度告诉读者为什么这条轨道有这么多的产品安全问题。需要注意的是，文章中指出的问题并不存在于每个项目中。大多数问题在设计中都有相关的应对策略，主要目的是希望更多的人能理解轨道的复杂性。

让我们带您了解通用跨链桥是如何设计的，然后告知这些跨链桥可能遇到的安全问题。(推特@0xOar）

01

万变不离其宗的跨链方案

事实上，之前的研究报告已经向您解释了几种不同类型的信息跨链解决方案。无论最终如何，从产品设计的角度来看，只有侧链（广义上的侧链，在本文中rollup也可以概括为侧链、别杠、哈希时间锁定、公证人三种机制。

（一）侧链

这三种方案中侧链方案的安全性最高，如各种方案rollup和polkadot平行链。主链和侧链之间共享安全性。但侧链方案一般要求原链与目标链同构，使适用场景少得多。这就是为什么V上帝认为他同意多链，但他不同意跨链的原因，因为无法共享安全的跨链方案有太多的问题。

（二）哈希时间锁定

这种方案号称是点对点的最去中心化的异构跨链方案，但是成本较高，用户等待时间过长，导致当前的采用率并不高。且当我们依然需要一个第三方充当换币中间节点时，也需要一个所谓的中间共识层去满足安全性和去中心化的要求。

(三)公证人机制

这是目前最常用的异构跨链桥方案。市场上大部分产品基本都是同根同源的，从产品设计的角度来看几乎没有区别。主要区别可能集中在信息验证、公证人共识算法、托管钱包签名算法等方面。使用体验和安全性差别不大。因此，从安全的角度来看，安全风险也有很多共同点。

本文将重点总结和分析公证人机制跨链桥面临的一些共同安全风险。

02

产品逻辑过程的公证机制

在了解公证人机制面临的各种风险之前，我们需要从产品的角度了解这类方案的主要设计逻辑。

（一）简述

从设计理念的角度来看，这个方案其实很简单。当我们面对异构资产跨链的需求时，最直观的方案实际上是映射。映射意味着成为用户A将ETH从以太坊到Fantom上次。我们不需要实际转移资产，也不需要在那里Fantom重新发行(这也做不到)。而是先用户A的ETH存储一个无法移动的地址，然后根据存在的地址存储用户A的ETH数量，再在Fantom上发行对应的1:1的映射资产。映射资产代表了以太坊原链上那些ETH使用权。锚定有1:1，Fantom上述用户也承认该资产的价值。

最简化的跨链流程

(二)设计难点

会有很多问题，最大的问题是多签钱包的管理，因为ETH从以太坊到Fantom如果用户的话，上面是充币A如果你想回来，那将涉及到提币。

去中心化和安全性充提币已成为最大的难点。

1.谁来管钱？2.谁来发起？3.谁来监控交易？.如何确认用户有用户转账？.如何确认用户的钱真的是用户自己想提出的？.如何防止重放攻击？.如何再次提交失败交易？.多签经理作恶怎么办？.停机怎么办？

不敢想，越想越复杂。跨链桥技术不仅涉及多签，还涉及资产发行、跨链监控、异步验证，甚至需要发行独立的中间共识层(新链)。

因此，为了进一步简化用户的理解难度，我将整个跨链过程分为两部分：充币和提币。以帮助您进一步了解。

(三)进一步细化流程

1.充币

首先，下图中绘制的过程只是我自己的设计方案，没有仔细论证。目的是探索设计逻辑中可能出现的安全问题，不能作为成型方案使用。这都是胡说八道。

如图所示：原则上，从原始链到目标链的货币收费交易将包含这些步骤。（1）用户充值到托管地址（2）监听器监听交易BP(共识节点也是多签管理员)发起交易(3)合同验证BP签名的正确性（4）是否有通过节点容错机制（5）如果没有打回去，如果有的话根据映射地址的关系为目标链地址充值（6）BP确认这笔充值交易(7)在拜占庭后将映射代币转移到用户在目标链上的地址

需要特别注意的是，这个过程旨在讨论一般的异构跨链，因此与之相比anyswap该计划增加了让用户在中间共识层绑定地址关系的步骤。这主要是因为不同的异构链交易以不同的方式附带信息。为了统一处理，用户只需先绑定映射关系。如果是这样EVM链交易不需要这一步，只需在发起交易时直接附上目标链地址即可。

回到正题，从以上流程可以看出，从第二步开始，就会遇到各种逻辑验证问题，以及在不同的情况下处理问题。

主要验证逻辑包括:(1)监控发起资产的映射和转移到交易后的用户A目标链交易的验证（2）目标链交易的启动和交易结果的验证，当然，除了我过程中绘制的验证逻辑外，还应包括对假币充值问题的验证和不同的呼叫token需要处理的特殊问题。为了更好地总结后续可能存在的安全隐患，我们将继续了解提币过程。

2.提币

硬币演示的过程是目标链映射资产回到原始链资产的逻辑。需要特别注意的是，许多代币已经发现了多个链的版本，也就是说，许多代币在多个链上都有原始代币。因此，一些桥梁项目经常建立资产池。当资本池充足时，用户感觉不到anyDAI这种映射资产的存在直接被目标链版本所取代token，但这并不影响整体逻辑。因此，分析继续.

如图所示，从目标链提币到原链的交易流程如下:(1)用户发起交易(将等量映射资产转移到目标链托管钱包)(2)验证BP身份，由某个BP发起提币请求(3)确认提币权限和签名(4)拜占庭后完成请求，将钱从原链托管钱包转移给用户A(5)如果由于节点验证错误或停机等问题，需要重新启动。从以上流程可以看出，主要验证逻辑包括:(1)启动和签名权限验证(2)问题出现后的容错机制

（四）安全风险

1.设计逻辑安全问题

在仔细了解了跨链桥的设计后，我们可以发现跨链桥在设计逻辑上面临着许多挑战。总结问题主要包括三个方面（问题最后标明相关盗窃案例）

（1）充币

a)货币收费合同权限漏洞导致收费直接转移。这是一个愚蠢的问题，几乎所有的合同项目都会遇到，b)假币充值问题，有些项目没有跨链Token验证真实性，导致fakeTOKEN -> realTOKEN（anyswap），说实话，这也有点蠢。d)假币充值问题，ETH等原始资产不同ERC20合同，很多攻击都是对的ETH造成特殊处理不当fakeETH -> realETH，这就是为什么WETH等wrapped资产流行的原因。（thorchain）c)不同的Token虽然都是ERC20标准，但具体实现方式不同，或有其他逻辑（rebase，fallback等)，开发者在适应时没有做好研究，比如（WETH、PERI、OMT、WBNB、MATIC、AVAX)转账完成后再调用sender自定义的fallback额外操作函数增加了跨链桥判断的复杂性（anyswap2022.1.18）

(2)跨链新闻转移

在a链充币完成后，到b链资产到账前，跨链桥的处理像是一个独立的区块链系统，即需要一个共识机制，一般用dpos，以下是假设dpos在这种情况下需要考虑的问题，但我怀疑所有的节点都是项目方的，首先有集中的风险。a)监听充币消息，谁来第一个发起跨链处理提案，随机？还是轮流？还是按照中间共识层的顺序？b)若数据源来自多个公证人如何验证充币的正确性infura等数据提供商，则infura是单点风险，最安全的是各自维护节点，成本巨大。c)如何确认跨链处理？（b到了)，还没有处理好几种情况.i.跨链桥没有发起处理ii.跨链桥发起处理，但验证&共识失败了iii.跨链桥验证通过，但不在b发起链上交易iv.b链上有交易，但失败了(资金不足或其他情况)

(3)多重签名验证

大多数问题频发的重灾区都是代码逻辑问题a) 3/5签名，我随便构造不在多签列表里的签名，也算 1（chainswap）。b)名义上，集中化问题是多签，实际上掌握在项目方手中，集中化风险巨大c)签名验证方法，不同链上的开发模式不同，导致开发者在对接时难免会有遗漏，wormhole例子: solana上述验证签名函数是系统合同中的函数。通常情况下，应调用系统合同。系统合同的地址应写在代码中。他们将系统合同地址作为参数传输到这里。当黑客提取货币时，他们传输了一个虚假的系统合同地址，绕过了验证签名，并成功地提取了货币。

（4）退款

a)如同（2）-c跨链状态有很多可能性，在任何情况下都需要为用户提供退款anyswap用户将首先在源链上发送货币anyToken，然后在目标链上发送给用户anyToken，然后是源链anyToken burn掉下来，这样的目的是用户无论出了什么问题都可以持有anyToken表示你持有的资产。在这个过程中，有三个链(源、目标、跨链桥)和四个原始资产(源链和目标链Token/anyToken），代码逻辑问题很容易出现。b) Thorchain在2021.7.在23个漏洞中，黑客利用代码逻辑构建了一个巨大的虚假充值。跨链桥无法处理，进入退款逻辑，导致黑客获得巨额退款。

2.其它安全风险

但逻辑过程所能显示的问题只是业务逻辑问题，而不是全部。从安全的角度来看，我们还应该考虑其他三个方面的风险

(1)系统性风险

比如原链充币一开始成功，后来回滚，这是一个巨大的问题，v讨论过，资产来自Solana跨到Ethereum，跨链完成后solana回滚，用户资产翻倍，没有解决办法。但例如rollup这种和Ethereum共享安全layer2，就不会有这种问题。

(2)前端风险

a)假网站，比如oxdao.fi 0xdao.fi oxdai.fi等b)Xss攻击，即跨站脚本攻击，是一种代码注入攻击，例如www.xxxx.finance/?params=hackerscode12345，虽然网站确实是官方网站，但如果前端开发不注意预防，网站上携带黑客代码xss，此代码将在页面上执行，导致用户授权黑客转账交易签名，所以不要打开来历不明的链接。c)Cors跨站服务攻击，在严格的同源策略中，浏览器只允许加载本网站的内容，即www.xxxx.finance所有显示的所有内容和调用接口都应该来自xxxx.finance但目前绝大多数项目都允许跨站调用，即xxxx可调用前端quickswap相反，界面给开发带来了便利，但也带来了风险.假如我来了xxxx.finance，在浏览器缓存中存储一些敏感数据，然后我访问恶意网站xxxx同源策略没有限制，可以随意获取恶意网站xxxx缓存中存在数据。

(3)额外功能的风险

一些跨链桥项目不仅提供跨链资产，还提供跨链合同调用，这带来了额外的复杂性。攻击者在那里a链条发起一对b链上x跨链桥无论调用合同x合约是啥就直接调用了，没想到x合同是跨链桥b链上的多签合同是将多签账户改为攻击者自己的地址。实施成功后，黑客可以随意控制跨链桥b链上的资金（poly network）。

03

结语

1.本报告的目的是帮助用户更清楚地了解跨链桥的安全风险，而不是恶意渲染跨链桥有多容易受到攻击。

2.公证机制的跨链桥方案至少是目前体验最好、应用最广、成本最低的方案。任何产品都会经历从伤疤到成熟的过程，区块链产品的攻击往往是逻辑问题。随着时间的推移和经验的增加，这些问题会越来越好。

请注意扫描二维码添加社区产品Jackson个人推特讨论@0xOar