原文标题：《WhatITalkAboutWhenITalkAboutBridges》
撰文：0xjim
编译：ChinaDeFi
入门
你是否曾经徒步旅行并尝试在不使用桥的情况下过河？我有，我可以告诉你这感觉很糟糕。
与现实世界中的桥一样，加密货币桥(以及它们更华丽的表亲：「互操作性协议」和「通用消息层」)提供了相同的价值。
它们把区块链连接在一起。如果没有桥，那么从一个链移动到另一个链会是一种非常痛苦的用户体验。
但加密桥不仅仅是连接，它们还允许在区块链之间翻译语言和规则。
桥使数据能够在不同的环境之间进行传输和解释。它们允许链之间的互操作性。
「但是，未来会是多链的吗?」你可能会有这个疑问。
嗯，是的。
必须而且永远会有多个区块链——从Cosmos到Avalanche到Aptos到以太坊的多个活动区域。
这些区块链需要一个通信层来协调结算。否则，他们将永远彼此隔离。
使用re:meme在链上制作的Meme
仅在过去的30天里，就有大约50亿美元的价值通过桥传输。此外，桥公司正受到投资者的青睐。
CoinShares：上周数字资产投资产品净流出6150万美元，为连续第7周资金流出:6月5日消息，据CoinShares报告显示，上周数字资产投资产品净流出6150万美元，为连续第7周流出，流出总额到达了3.29亿美元，占管理资产总额的1%。其中，比特币投资产品净流出270万美元，以太坊投资产品净流出270万美元，做空比特币的投资产品净流出630万美元。上周资金流出主要来自于TRON投资产品，流出金额达到了5100万美元。CoinShares猜测是由于TRON投资产品提供商下架了该产品。[2023/6/5 21:17:02]
资料来源：德尔福数字研究
但是，在过去的一年里，也发生了价值超过20亿美元的漏洞利用攻击——他们要么是利用核心机制设计，要么是利用智能合约漏洞。
圣杯
该如何定义一个「理想的」桥呢?
在加密领域摸爬滚打了一年之后，我觉得安全可靠的机制设计才能恢复用户的信心。
资料来源：德尔福数字研究
最安全的桥设计应该是信任最小化的，桥继承了它连接的两条链的安全属性。
这是通过链上验证来完成的：目标链(即接收桥接交易的链)验证源链的共识，并看到指定的交易确实包含在它们的区块链中。
这通常是由目标链的验证者运行源链的链上轻客户端来完成的。轻客户端检查提交的默克尔根并看到指定的交易确实已经由源链的活动验证者集签名。然后，目标链的验证者可以确认交易的有效性，并将交易包含在他们的区块链中。
浮士德式的交易
运行一个链上轻客户端是又复杂又昂贵。它是不可扩展的——因为每个验证者都需要为每个源链运行一个轻客户端。这样就很难扩展到新的链，而且对一些人来说几乎是不可能的——因为不同的共识签名方案在所有执行环境中都不受支持(例如，以太坊验证Tendermint共识)。
G7数字部长会议开幕，将讨论制定AI开发与使用规则:金色财经报道，据共同社，七国集团（G7）数字与技术部长会议29日在日本群马县高崎市开幕。鉴于人工智能（AI）写文章及绘画的生成式AI使用迅速扩大，会议将讨论制定AI开发与使用的规则。此外还将共商在乌克兰数字领域展开支援事宜。会议将于30日汇总联合声明。据报道，议题还包括如何具体实现扩大国际数据流通带动经济增长的“可信的数据自由流通”（DFFT）构想。这是日本2019年提出的理念，力争就创设国际框架达成共识。[2023/4/30 14:35:11]
迄今为止，只有Cosmos应用链上的IBC实现了大规模的链上轻客户端(GravityBridge、RainbowBridge、ComposableFinance和Snowbridge都难以扩展)。
想要在这一点上成功，就只有通过极端的标准化才能实现——每个应用链都需要运行Tendermint共识，并遵守IBC标准。
在一个拥有不同共识机制、签名方案和虚拟机的多链世界中，链上轻客户端验证是不可能的。
因此必须做出权衡：为了获得可行性/可扩展性，需要做出多少信任假设?
这就是许多桥项目与「魔鬼」达成的协议——建立所谓的信任范围，这取决于权衡的程度。
资料来源：LiFi博文
链下验证
如果无法进行链上轻客户端验证，那么唯一可能的设计空间就是在链下进行。
这就是协议在实现上有所不同的地方。
一方面，你有TeamHuman——Multichain、Wormhole、RoninBridge。这些都要求多重签名实现，需要实体验证交易，并验证(即签名)其有效性。通过阈值后，交易就被认为是已验证的。
A股收盘：深证区块链50指数上涨2.01%:金色财经消息，A股收盘，上证指数报3265.65点，收盘下跌0.64%，深证成指报11634.22点，收盘上涨0.25%，深证区块链50指数报3393.75点，收盘上涨2.01%。区块链板块收盘上涨1.37%，数字货币板块收盘上涨0.87%。[2023/3/24 13:24:26]
这些实现需要实体运行完整的节点(比轻客户端更强大)来进行验证。当然，这些人仍然可以撒谎，但假设是大多数人进行统治，所以实体不会通过不诚实来维护他们的声誉。
TeamHuman的隔壁邻居是TeamEconomics——Celer,Axelar,deBridge,Hyperlane,Thorchain(等等)。这些类似于多重签名，但增加了一层权益证明。现在不是信任实体(这里称为验证者)共同签署交易的有效性，而是有了不撒谎的经济动机，因为如果作恶，验证者的质押将被大幅削减。
这些实现通常还要求验证者运行源链的完整节点(但不是强制的)。理论上，TeamEconomics比它们连接的底层区块链更安全，但在实践中，我还没有看到它发生。
接下来是TeamGameTheory——LayerZero和像Nomad和Synapse这样的Optimistic桥。这些实现将桥接分解为两个独立的工作，并抑制了两个工作执行者之间的协调。
对于LayerZero，他们创建了UltraLightNode，这本质上是一个按需交付的即时轻客户端。预言机传递区块头，中继者传递交易证明。两者结合在一起执行链上轻客户端的职责，但成本较低，因为它们不是连续运行的。
Optimistic桥也有两个链下代理：一个更新者和一个观察者(用Nomad的话说)。更新程序传递了一个源链的默克尔根，并且有一个挑战期(例如10分钟)，在此期间任何观察者都可以对所传递的默克尔根的有效性提出质疑。错误的更新者将被削减他们的质押。
在这两种实现中，链下代理都需要运行一个完整的节点来验证交易。在这两种实现中，两个代理之间的合谋也会导致错误的交易被通过。
然而，Optimistic桥需要一个「诚实的少数人」假设来正确验证交易——这意味着任何人(理论上)都可以是一个代理，因此系统只需要一个诚实的参与者就可以工作。
Web3沉浸式社交应用VUZ完成2000万美元B轮融资:10月13日消息，迪拜Web3沉浸式社交应用VUZ宣布完成2000万美元B轮融资，Caruso Ventures、Vision VC Fund、e&capital、DFDF (Dubai Future District Fund)）、WIN（Webit Investment Network）、SRMG、Elbert Capital和Yasta Partners、Faith Capital、Panthera Capital等参投，迄今融资总金额已超3000万美元。
VUZ通过提供沉浸式内容来弥合物理世界和虚拟世界之间的差距，目前已登陆iOS和Android应用商店。[2022/10/14 14:27:00]
目前，LayerZero已经允许链下代理，依靠机构的可信赖声誉使系统正常工作。随着时间的推移，LayerZero希望应用程序指定<预言机—中继者>对，以抑制共谋。
最后，还有TeamSecurity—Datachain/LCPNetwork。他们利用像IntelSGX这样的安全飞地(TEE)来执行加密的链下轻客户端验证——他们称之为轻客户端代理。在这种情况下，信任完全依赖于TEE的安全性，就像之前看到的SecretNetworkexploit一样，通过从SGX侧通道获得主解密密钥，是可以破坏网络历史的所有隐私的。
归根结底，都是由某人或某物进行验证的。
而目标链验证者需要相信验证是正确完成的——因为它们无法验证自己。
链上验证
如果真的有一种方法来执行链上轻客户端验证呢?
这就是TeamMath的用武之地——Polymer、Succinct、ElectronLabs和zkBridge。这些项目处于零知识SNARK研究的前沿，使用简洁的证明来扩展桥的链上验证。
华盛顿邮报：推特正在通过广泛的法律请求调查马斯克的社交圈:8月2日消息，据华盛顿邮报：推特正在通过广泛的法律请求调查马斯克的社交圈，包括硅谷精英投资者Chamath Palihapitiya、David Sacks和Steve Jurvetson的信息。(金十)[2022/8/2 2:52:33]
从技术上讲，对源链共识(以及不同的签名方案)的验证是在链下完成的。SNARK证明由链下prover生成，表明已执行此验证，然后在目标链上进行链上证明。
SNARK不会出错，因为是…数学嘛。
这是桥的圣杯！
但没那么快。
ZK轻客户端是一项新兴技术，目前范围有限。
也就是说，Succinct正在为以太坊到Gnosis的桥(双向)而活，ElectronLabs正在致力于Cosmos到以太坊的桥(单向)，而Polymer正在开发一个跨越L1和L2的轻客户端网络(全方位)。
为了扩展到其他共识机制，是需要新电路的，这项工作很困难。
此外，ZK轻客户端需要确定的终结性，他们不能使用工作量证明链，如比特币。话虽如此，也有一些解决方案正在处于开发状态，比如在轻客户端本身的电路中编码非确定性。
(为了详尽起见，我将在TeamMath中添加Rollup桥，它证明了每个状态转换，甚至比证明共识的ZK轻客户端更信任最小化)。
发人深省的真相
通过对桥数百小时的研究，我得出的结论是，「最佳」桥的答案并不简单——尤其是在近期和中期。
这个领域刚刚起步。人们总是固执地认为什么才是最成功的技术解决方案。
我最终倾向于一种务实的方法。最终胜出的将不是最好的技术，而是最好的产品——由一个团队构建，这个团队确切地知道他们的用户想要什么(在这种情况下，是开发人员)，并构建一种体验和GTM，以交付价值。
作为一个开发加密应用程序的人，我知道应用程序开发人员想要什么。我认为一个好的桥产品应该是这样的：
技术的混合
技术本身不是产品——它使产品成为可能。安全模型的混合搭配可以为用户创造两全其美的体验。
我认为TeamMath是正确的方向，但有效范围是有限的，他们为了最小化信任而以可扩展性为代价(即扩展到新链的能力)。
TeamGameTheory和TeamMath联手的方法可能是我们需要的全明星阵容。
实现交易第一阶段的Optimistic桥——具有挑战期和诚实的少数信任假设。信任最小化的ZK桥，用于在返程中进行验证。
另一种方法是构建模块化堆栈，随着时间的推移插入额外的安全模型(如LayerZero、Connext和Hyperlane)，以进行相应的混合和匹配。
另一个实体承担最终风险
当谈到桥时，最终性是关键。桥接协议需要在将交易传递到目标链之前绝对确定交易已经在源链中发生。
没有办法执行回滚跨链。
在即时终结链中，这会在几秒钟内发生(即一个区块)。然而，其他链需要更长的时间才能达到最终确定，有些需要一个缓冲期，以考虑重组的概率/经济可行性。
deBridge的最终确定性定义
在从以太坊发送交易的情况下，用户不会等待~12分钟得到最终确定并确认交易。对于Optimisticrollup，因为有7天的挑战起，所以这种情况会加剧。
最终确定性的延迟将需要从用户中抽象出来，其他参与者将需要承担重新组织的风险。
可配置的风险偏好
除了抽象出延迟之外，还需要从用户中抽象出风险的变化。
应用程序应该控制其风险阈值，并根据用例、金额和目标链自定义阈值。例如，BSC上的NFT转移应该与Cosmos上的清算不同。
LayerZero、Synapse和Hyperlane允许应用程序确定它们的风险偏好。
对于LayerZero，应用程序可以选择一个他们信任的<中继者-预言机>对，和一个计时器。
对于Synapse，应用程序可以根据用例选择它们的欺诈窗口。
对于Hyperlane，应用程序甚至可以选择他们想要的共识机制(TeamHuman、TeamEconomics、TeamGameTheory——称为InterchainSecurityModules）
这就是像Socket和LiFi这样的桥聚合器特别有用的地方，因为不同的桥实现最终也可以由应用程序配置。
BD很重要
从技术上讲，这不是一个产品，而是一个团队的优先事项。
每个项目都资本充足，进入熊市，吸收顶尖人才，并在密码学的前沿进行创新。
然而，在它们之上并没有应用程序。应用程序在哪里?
迄今为止，只有代币传输协议(Connext,Hop,Across,Stargate)取得了成功。NFT游戏资产市场和跨链治理中备受赞誉的用例还尚未被实现。
这不是一个「建立它，他们就会来」的空间。桥是开发者平台，需要在其之上建立充满活力的应用生态系统。
没有应用，就没有用户。这就是为什么业务开发和集成对于项目的成功至关重要。
应用程序将跟随资金。决定获胜者的可能不是技术，而是关系、集成和业务因素。
对于资产、链连接和用例，桥的使用可能遵循幂律。
坦率
桥的强度取决于它最弱的连接链(即，可能容易受到51%的攻击)。这对未来的多跳桥是一个巨大的阻碍。
大多数智能合约实现都是可变的。升级是半定期进行的。总有某人/某物有管理权限。
一个允许应用程序配置其风险偏好的桥，也将引入攻击向量，攻击者可以渗透到应用程序的合约中，并禁用恶意交易的任何验证过程。
协议争议由治理或多重签名解决。人为错误被引入方程式。
即使是ZK桥也没有完全信任最小化。我们相信电路是正确编写的。相信prover软件没有错误。相信目标智能合约可以正确地解释电路。项目品牌的力量，以及缓慢而系统地发布安全代码都应该理想地解决这些问题。
对开发人员保持坦率和理智的诚实将大有裨益。
前面的路
我相信在未来2-3年内，我们将看到应用特定rollup的部署出现爆炸式增长。
有很多解决方案可以为这种爆炸式增长提供服务：OPStack、ArbitrumNova+Nitro、Fuel、PolygonSupernet、Avalanche及其子网、Scroll、PolygonHermez、ConsensyszkEVM、Starknet、zkSync、Celestia、Astria、Saga、Dymension等。
然而，桥似乎是所有这些解决方案中缺失的部分。
我们如何确保app-rollup到app-rollup的桥接？Slush、ConstellationLabs和SovereignLabs(以及LaGrange和Herodotus)等公司在创建应用程序rollupSDK时都在考虑这个问题。
我们如何为这些应用程序即服务rollup解决方案提供开箱即用的桥?Hyperlane正在研究这个问题，但这是一个很难解决的问题。
我们如何在不牺牲用户/开发体验的情况下，优化多链资本效率，同时消除桥漏洞呢?
这些问题都有待观察。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。