免责声明:金色财经所有资讯仅代表作者个人观点,不构成任何投资理财建议。请确保访问网址为(jinse.cn) 举报

    从Bool Network看去中心化的比特币跨链桥如何真正落地

    作者:Faust & Abyss,极客 Web3

    摘要:自从各种跨链桥横空出世以来,紧随的各种黑客攻击事件几乎从未停止,2022年Axie官方跨链桥被盗6.2亿美元一事更是震撼了世人,无数人开始思考如何解决跨链桥的安全与免信任,但时至今日,这个领域依然存在许多悬而未决的问题。

    但与公链赛道一样,跨链桥在设计思路上同样存在“不可能三角”,而且实质今日仍然无法打破。为了在成本与UX上具备优势,绝大多数跨链桥都采用了类似于多签的见证人模型,而这种方案从落地的第一天起,就是黑客眼中的香饽饽

    惨痛的历史经验告诉我们,没有添加防护措施的见证人桥迟早会出事,但这种桥在整个比特币生态已然是家常便饭,让人感到毛骨悚然。

    本文将要介绍的Bool Network,在为跨链桥项目方提供动态轮换的见证人基础上,结合隐私计算和TEE封装密钥,尝试在传统见证人桥的安全模型上进一步优化,解决跨链桥的去中心化问题,这也许能为比特币跨链桥带来破局的希望。

    比特币生态的现状:到处都是多签

    跨链桥的本质,是向B链证明A链上有人发起了跨链请求,且当事人按照规定支付了费用。要证明这件事,可以有不同的实现路径。

    轻客户端桥往往在链上部署智能合约,在链上Native的验证跨链消息,这种桥的安全性最高,但成本也最高昂,而且无法在比特币链上实现(目前打着比特币ZK桥旗号的项目方,只能保证BTC跨到其他链时走ZK桥,BTC再跨回去时无法通过ZK桥来实现)

    BitVM为代表的乐观桥,通过欺诈证明来确保跨链消息被如实处理,但这种方案落地难度极大。绝大多数比特币跨链桥最终都采用了见证人的模式,在链下指定几个见证人,由见证人验证并确认所有的跨链消息。

    DLC.link为代表的DLC桥,虽然在预言机/见证人多签基础上引入支付通道的思路,最大程度限制见证人作恶的场景,但还是无法在根源上彻底抹除多签的隐患。

    (跨链桥不可能三角主要指:1.可扩展性:能否支持任意消息的传递

    2.无需信任:不引入或尽量少引入信任假设

    3.易适配性:落地难度,能适配包括比特币在内的不同公链)

    最终我们会发现,在BitVM落地前,除了闪电网络/支付通道或RGB++这类基于客户端验证或同构绑定的项目以外,其他的比特币跨链桥骨子里都是多签。

    历史早已证明,如果不解决多签跨链桥乃至于大型资管平台的去信任问题,出现资金被盗事件将只是时间问题。

    对此,一些项目方让见证人超额抵押资产,以潜在的Slash来作为惩戒条件,或是让大机构充当见证人提供信用背书,弱化跨链桥的安全隐患。但归根结底,基于见证人模式的安全模型和多签钱包基本一致,最终都要按照阈值,比如M/N来判定其信任模型,容错率比较有限。

    如何设置和处理多签,如何让多签尽可能去信任,如何杜绝见证人做恶或抬高外界的攻击成本,将是比特币二层跨链桥需要长期思考的议题。

    有没有什么办法可以让多签参与者难以串谋作恶,并且让黑客难以从外界盗取密钥?Bool Network尝试通过一套基于ZKP-RingVRF算法和TEE的综合方案来解决见证人桥的安全问题。

    Bool网络:专为跨链桥等设计的隐私计算基础设施

    其实,无论是KYC或是POS或是POW,本质都是为了去中心化和反女巫,防止重要的管理权限集中在少数人手上。POA和KYC之上使用多签/MPC方案,虽然可以通过大机构的信用背书来缓解安全风险,但这种模式和中心化交易所没有本质区别,你还是要信任这些被钦定的见证人不挪用跨链桥资金池里的钱,这其实就是联盟链,从根本上违反了区块链的Trustless精髓。

    基于POS的多签/MPC方案比POA更去信任,准入门槛远比后者低,但还是会面临各种各样的问题:比如节点的隐私泄露。

    假设现在有几十个节点组建的见证人网络,专门服务于某个跨链桥,由于这些节点需要频繁的交换数据,其公钥和IP地址或是其他的身份信息容易对外暴露,攻击者可以针对性的构建攻击路径,最终往往会导致某些节点的密钥被盗。此外,见证人也可能内部串谋,当节点数量比较少时,这种事很容易发生。

    那么我们该如何解决上述问题?你可能会本能的联想到,要加强密钥的保护措施,防止被外界窥探到。一种比较可靠的方法是把密钥封装在TEE(可信执行环境)当中

    TEE允许节点设备在本地的安全区域内运行软件,系统中的其他组件无法访问其数据,你可以把私密数据或程序隔离在安全的执行环境中,防止机密数据被泄露或是被恶意操纵。

    这里的问题是,如何保证见证人的确是在TEE中存放密钥并生成签名的?其实只要让见证人出示TEE的远程证明信息,就可以验证它是否跑在TEE里,我们只需要在任意一条链上验证TEE证明即可,成本几乎可以忽略不计。

    前不久Scroll也宣布采用TEE作为ZKEVM之外的辅助证明器,并验证了其Sepolia测试网上的全部区块

    (Bool Network节点设备内部构造示意图)

    当然,除了TEE之外,问题还没完。就算你引入了TEE,假如见证人的总量不多,比如说只有5个,我们还是会遇到各种问题,即便封装在TEE中的密钥无法被“看到”,由少数人组成的见证人委员会还是无法保障抗审查性和可用性。比如上述5个节点如果集体跑路,让跨链桥陷入瘫痪,这个时候桥接资产无法顺利的lock-mint或赎回,基本等价于永久冻结。

    在综合考量了兼容性、去中心化、成本等因素后,Bool Network提出了这样一种构想:

    我们通过资产质押的方式,构建出一个Permissionless的候选见证人网络,只要你质押足额的资产就可以加入进来;当网络规模足够大,比如说接入了几百上千台设备后,我们定期从网络中随机抽取一些节点充当跨链桥的见证人,以此来规避见证人“阶级固化”的问题(这种思路在现在的POS以太坊身上也有体现)

    那么该如何让抽签算法具备随机性呢?传统的POS公链如Algorand、Cardano通过引入VRF函数,周期性的让VRF函数输出伪随机数,通过输出结果抽取出块人。但传统VRF算法往往无法保护隐私,有哪些人参与了VRF计算过程、VRF输出的随机数关联着的被选中者都有谁,几乎暴露在阳光下。

    跨链桥的动态见证人与POS公链动态选拔出块人要考虑的问题不同,公链的出块人即便身份泄露了,往往也无伤大雅,因为攻击者的作恶场景有限,会受到许多限制条件的约束;

    而跨链桥见证人身份一旦泄露,黑客只要获取到其密钥,或是这些见证人内部勾结,就会让整个桥接资产资金池彻底陷入危机。Anyway,跨链桥和POS公链的安全模型是差了十万八千里的,必须更重视见证人的身份保密。

    我们本能的想法是,最好把见证人名单隐藏起来,而Bool Network在这方面采用了原创的环状VRF算法,把选中的见证人身份隐藏在全体候选人中,其整体细节比较复杂,我们将其简化后表述如下:

    1.所有的候选人在进入Bool网络前,先在以太坊或Bool自己做的一条链上质押资产,留下一个公钥作为注册信息。这个公钥又称为“永久公钥”。全体候选人的“永久公钥”构成的集合,在链上公开可见。这个永久公钥说白了就是每个人的身份信息;

    2.每过几分钟~半小时,Bool网络会通过VRF函数,随机挑选出几个见证人。不过在此之前,每个候选人要在本地生成一次性的“临时公钥”,同时生成ZKP,证明该“临时公钥”与链上有记录的“永久公钥”有关联;换句话说,通过ZK证明自己存在于候选人名单中,但又不透露是哪一个人;

    3.“临时公钥”的作用在于什么?正是为了隐私保护。如果直接从“永久公钥”集合中抽签,公布抽签结果时,大家会直接知道哪些人当选,这个时候安全性会大打折扣。

    如果大家都临时提交一次性的“临时公钥”,再从“临时公钥”集合中选出几个中签者,你最多只知道自己中签,因为你不知道其他中签的临时公钥对应着谁。

    4.这还不算完。Bool 网络打算这么搞:直接让你不知道自己的“临时公钥”是啥。这该怎么做呢?只要把临时公钥明文放在TEE里加密成“乱码”后再发出去就行。

    我们可以把“临时公钥”的生成也放到TEE里执行,由于TEE可以把数据和计算加以保密,你根本不知道TEE里发生了啥。当“临时公钥”生成完毕后,会加密成“乱码”再发到TEE外部,这时你根本不知道自己的“临时公钥”的原文是啥,只能看到一个加密后的密文(需要注意,第二段提到的,证明临时公钥和某个永久公钥有关联的ZKP,也和临时公钥一起被加密了)。

    5.候选人要把乱码形态的“临时公钥”密文,发送给指定的Relayer节点。Relayer负责解开这些乱码形态的密文,从中还原出全部的“临时公钥”原文。

    这里有个问题,就是Relayer知道每个密文的发送者是谁,只要他把每个密文解析成“临时公钥”,自然而然就知道了每个“临时公钥”对应着哪个人。所以,上述工作也要在TEE里做,几百人的公钥密文进入TEE,出来后变成了公钥原文,就像混币器一样,可以有效保护隐私

    6.Relayer得到了原始的“临时公钥”后,把它们统一归集,提交给链上的VRF函数从中抽选出中签者,也就是从这些“临时公钥”中挑出几个中签人,组建下一届的跨链桥见证人委员会。

    这样一来整体的逻辑其实就清晰了:我们定期的从见证人临时公钥集合中随机挑选几个,充当跨链桥的临时见证人,这个设计被命名为DHC(动态隐藏委员会)。

    因为每个节点都运行TEE,MPC/TSS的私钥片段,还有见证人运行的核心程序、所有的计算过程,都隐藏在TEE环境内,每个人都不知道具体的计算内容包括什么,就连被选中的人自己都不知道被选中,这样可以从根本上防止串谋或者外部攻破。

    Bool Network跨链消息的生命周期

    在介绍完了Bool隐藏见证人身份和密钥的大体思路后,让我们来梳理下Bool Network的工作流程。我们假设左边是源链右边是目标链,上面的整个图构成了资产从源链到目标链的全流程生命周期,由此我们从数据流转的角度剖析一下Bool Network跨链的4个过程:

    首先,提款人在源链发起提款动作后,消息被Realyer发送到Messaging Layer层;消息在到达Messaging Layer层后,由动态委员会对消息进行验证,确定消息在源链确实存在且有效,然后进行签名。

    可能有人要问,既然前面提到,每个人都不知道自己有没有被选到见证人委员会里,怎么才能把消息传递给指定的人并让他们签名呢?其实这很好解决,既然不知道有谁是选中的见证人,那我们干脆就全网广播,把待处理的跨链消息传递给每一个人。

    最开始我们曾提到,每个人的临时公钥都是在本地TEE里生成和封装的,在TEE外部看不到临时公钥。要验证自己的临时公钥是否被选中,这部分逻辑直接部署在TEE内,只要把待处理的跨链消息输入TEE,TEE内部的程序就会确定是否要对消息进行签名确认。

    在TEE内对跨链消息签名后,还不能直接把数字签名发出去,因为如果你把签名直接往外发,大家会发现你对跨链消息附加了签名,猜到你是选中的见证人之一。所以,要想办法让外界不知道你是否对跨链消息签名了,最好的办法就是对签名信息本身加密,就和前面提到对临时公钥加密的思路类似。

    总结就是:Bool Network会通过P2P传播,把待签名的跨链消息传递给所有人,选中的见证人在TEE内对消息进行验证和签名,然后把加密后的密文广播出去,其他人收到了密文后,再放进TEE内解密,重复上述流程,直到所有被选中的见证人都签名完毕,最后被Relayer解密成TSS签名的原始格式,完成跨链消息的确认和签名流程。

    核心在于,几乎所有的活动都在TEE内进行,从外部看根本不知道发生了什么。每一个节点都不知道见证人有谁,不知道自己是不是选中的见证人,从根本上防止了串通作恶,并大幅度增加了外部攻击的成本

    要攻击基于Bool Network的跨链桥,你需要确定动态委员会里的见证人都有谁,但你根本就不知道它们是谁,这时你只有攻击整个Bool网络才行。像ZetaChain等单纯基于POS和MPC的跨链桥基础设施,其见证人身份全部暴露,假设阈值门限是100/200,你最少只需要攻击网络中一半的节点。

    但换到Bool身上后,因为有了隐私保护,理论上你必须攻击所有的节点才行。再加上Bool所有节点都运行着TEE,此时的攻击难度会再度抬升。

    并且,Bool Network本质还是见证人桥,见证人桥只需要在目标链上提交一个签名,就可以完成跨链处理流程,成本最低。由于没有Polkadot那样多余的中继链设计,避免了二阶验证的冗余,Bool的跨链速度可以很快。这种跨链模式同时兼备了资产跨链和消息跨链的需求,有着较好的兼容性。

    如何评价Bool的产品设计思路?

    这里我们抛出两个观点,首先资产跨链是ToC的产品,其次跨链桥是竞争大于合作的。从长期看,因为跨链协议的壁垒较高,需求较为同质化,跨链桥相关的资金集中度会越来越高,这是因为跨链协议有着较为强大的护城河壁垒,包括规模效应和转换成本。

    Bool身为比跨链桥更底层的专用基础设施,实际上比上层的跨链桥项目方的商业前景更广阔,它甚至还可以承担预言机的功能,而不仅仅把场景局限在跨链消息验证,理论上还进入全链oracle的赛道,真正的构建去中心化oracle并提供隐私计算服务。

    jinse.cn 2
    好文章,需要你的鼓励
    jinse.cn 2
    好文章,需要你的鼓励
    参与评论
    0/140
    提交评论
    文章作者: / 责任编辑:

    声明:本文由入驻金色财经的作者撰写,观点仅代表作者本人,绝不代表金色财经赞同其观点或证实其描述。

    提示:投资有风险,入市须谨慎。本资讯不作为投资理财建议。

    金色财经 > 极客 Web3 > 从Bool Network看去中心化的比特币跨链桥如何真正落地
    • 寻求报道
    • 金色财经中国版App下载
      金色财经APP
      iOS & Android
    • 加入社群
      Telegram
    • 意见反馈
    • 返回顶部
    • 返回底部