比特派苹果下载官网|cbridge

作者：比特派苹果下载官网

2024-03-07 17:43:03

Celer cBridge主网上线：无缝桥接跨链和跨层流动性 - 知乎

Celer cBridge主网上线：无缝桥接跨链和跨层流动性 - 知乎切换模式写文章登录/注册Celer cBridge主网上线：无缝桥接跨链和跨层流动性律动BlockBeats关注区块链、数字加密行业，首选媒体—律动BlockBeatsCeler cBridge v1.0 版本今天正式主网上线！用户可以立即使用 cBridge 在 Ethereum、Arbitrum 和 Binance Smart Chain 以及 Polygon 进行高速低成本跨链和跨层转账。cBridge 将会在短期内支持更多的 layer2 和 layer1 区块链的跨链转账。此外，任何人都将能够通过运行 cBridge 节点加入 cBridge 网络以提供跨链跨层流动性，同时通过收取手续费产生收益。cBridge 是一个重要的里程碑，它标志着 Celer 将在未来的多链多层区块链扩容生态下，提供重新聚合分散流动性的关键核心基础设施，从而极大提升可交互性和可组合性。为什么 cBridge 是未来区块链多链多层扩容的关键基础设施？区块链扩容是一场与魔鬼的交易游戏任何新的计算机系统出现之后，随着在实际中的不断应用，哪些系统特性更为重要，哪些系统特性不那么重要，会很快被检验出来。一旦在当前某些限制条件下，系统达到了性能上限，为了进一步迭代和改进系统，系统设计者总是不得不放宽约束与「魔鬼」做交易：牺牲不太重要的特性以改进系统更重要的特性来适应使用需求的发展。这就是计算机系统设计中的「权衡」原则。通常，这种交易游戏是通过在现有系统之上添加额外的抽象或「层」来实现的。系统设计者总是会先尝试了解哪些属性是真正不兼容且可相互交易的。通过理解不同的特性，导致了计算机科学史上的各种「不可能 N 角」和「定理」。在区块链的背景下，每个人都可能听说过「去中心化、可扩展性和安全性」不可能三角。但需要指出的是，这些众所周知的 xxx 三角，通常并未描述所有可能的选择，我们完全可以跳出既定框架去寻找新的权衡和特性，以交换我们想要的主要特性。例如，区块链可扩展性的两条流行路径是： 1. 在「区块链可扩展性三难困境」的边界内，向「魔鬼」出卖一定程度的去中心化； 2. 创造性地跳出不可能三角，通过「出卖」互操作性和可组合性来换得新的可拓展性。第一条路其实就是是侧链和 DPoS 区块链链的设计原则，第二个则是 layer-2 扩展技术的基本思路（包括状态通道和 rollup 链）。不管哪条技术路线，随着它们的发展，我们不难看到，未来一定属于多链且多层的架构。在这样的多链多层架构下，原本作为一个相对完整单一系统的区块链，其流动性和可组合性将被隔离并孤立到多个独立的 layer2 和 layer1 链中。可是，「出卖」互操作性和可组合性如同出卖了区块链的灵魂的一部分。流动性割裂将极大地降低整体应用生态的完整性，比如本可以组合的 DeFi 乐高将会被严重破坏，在各个链之间转账只有通过中心化交易所辅助，或者需要消耗极高的时间和费用成本才能实现，而跨链函数调用更是无从谈起。对于很多长尾用户和使用场景来说，这样的跨链跨层交互成本成为了极大的区块链使用壁垒。这不可避免的会导致长尾用户的流失，从某种程度上，极大地违背了真正的去中心化愿景。cBridge：赢下与魔鬼交易终局之战所幸在计算机系统设计中，我们的交易游戏永远不是一锤子买卖。我们可以通过出卖别的东西，去赎回大部分因为多链多层架构而丧失的可组合性和互操作性。Celer cBridge 的出现，让这种赎回成为了可能：cBridge 在多链/多层之上提供了一个新的抽象层，允许用户以完全无信任的方式以更低的费用和时间成本，进行高速的桥接流动性和状态函数调用桥接，从而赎回了大部分原本将被出卖的可交互性和可组合性。那么作为回报，我们出卖给什么给了魔鬼？cBridge 作为 Celer 的状态通道架构的自然延伸，每一个 cBridge 节点能够帮助用户桥接流动性的前提条件，是需要事先在每个可能成为用户目标的桥接链上锁定足够的流动性，以便从用户所在链上接受流动性，并在不需要任何中心化信任的情况下立即向用户想去的目标链上「推送」流动性。虽然听上去锁定流动性不是一个好事，但这个交易其实我们是暴赚的。这是因为 cBridge 节点可以利用转账手续费和「规模经济效应」来极大减少流动性锁定的不利影响。跨链和跨层桥接定价的模型和经济学原理需要一篇单独的文章去探讨。我们这里举几个简单的例子来说明不论是大额还是小额交易，这种规模经济效益总能够让用户和 cBridge 节点运营商达到一个双赢的结果。首先，对于小额，比如百美金级别的跨链、跨层交易，如果不使用 cBridge，而使用原生桥接，交易成本将会达到$50-$200，占总交易金额约 40%-50%。作为 cBridge 的运营节点，如果收取 5%-10% 的手续费，用户都会毫不犹豫的选择使用 cBridge 作为桥接通路。但 cBridge 节点亏钱了么？并没有。以下桥为例（比如从 Arbitrum 转入 Ethereum），如果一个节点帮助桥接一万笔 $100 的下桥交易，虽然对于每一个交易，都比用户使用原生桥价格低很多，但化零为整，节点运营商获取的总手续费是$50,000 - $100,000。而当桥接节点对流动性进行重新平衡的时候，他只需要进行一次原生下桥操作去重新平衡流动性，总花费$50-$200，最终至少净赚$49,800。其次对于较大规模的交易，cBridge 主要的作用则是极大地加快流动性桥接的速度（尤其是在各类 rollup 下桥过程中）。收费则可以根据合理风险矫正收益来定价，一般比无风险收益要高不少。比如桥接$1,000,000 的交易，假设现在的无风险利息达到了年化 10%，cBridge 节点最少可以获得和无风险收益匹配的收益，也就是$2,000。最后，以上两个简单的例子都是简单假设桥接传输是单边进行的，流动性耗竭之后需要彻底对流动性进行重新平衡。事实上，上桥和下桥永远将是同时存在的，所以流动性在实际应用过程中会比上面假设的两个例子要平衡得多。因此，实际情况下 cBridge 节点收益会更高。这样，我们就通过 cBridge 的架构允许用户在不同的链上无缝移动资产和状态，由此恢复了大部分为了扩容而牺牲的可组合性，在这场与魔鬼的交易中取胜！最后我们想强调的是，cBridge 是完全非托管和去信任的。这意味着用户在使用过程中无需信任任何 cBridge 节点。您可以在我们之前关于帖子中找到更多技术信息 Celer State Channel 和 cBridge。cBridge 主网启动包括什么？这次 cBridge 主网发布包括两方面，面向用户的界面和全节点软件。用户可以通过 cbridge.celer.network 立即开始使用 cBridge，在以太坊、Arbitrum、BSC 以及 Polygon 的任意两个链之间即时进行资产跨链。作为新推出的产品，我们始终欢迎来自社区的用户体验反馈。对于那些想要尝试运行 cBridge 节点并加入流动性桥接网络，同时获得一些不错收益的人来说，cBridge 节点软件是一个完全开源的平台，并且人人可以运行，您可以移步我们的 github 获取相关软件和运行方法（https://github.com/celer-network/cBridge-node）。Celer 的开发社区人员将一直在 Discord 上回答社区的问题并提供支持。但是，与任何新推出的系统一样，我们希望您在 cBridge 节点上逐步部署流动性，以给到系统一些时间进行磨合并接受安全考验。cBridge 的未来迭代cBridge v1.0 版本只是一个开始，未来版本将提供更多功能：- cBridge 节点的开放网络。对于那些想尝试运行 cBridge 节点并加入 cBridge 网络以提供跨链跨层流动性，同时通过收取手续费产生收益的用户，一旦我们经过一些时间的检验，cBridge 节点网络将很快完全开放给任何第三方加入！- 支持更多链。cBridge 将根据用户的需求，逐步扩展支持到其他 layer1 和 layer2 链。- 动态定价策略 SDK。cBridge 的一个关键组成部分是如何根据当前的供需情况、交易规模、目标链上的可用流动性为桥接定价。一个好的定价策略可以帮助优化收益率和产生可持续的流动性。我们不希望每个 cBridge 运营商都拥有完全相同的费用策略，因此，我们将为每一个 cBridge 节点开放一个基于插件的 SDK，以便轻松插入他们自己的策略和可用的决策因素。- 状态和智能合约调用桥接。代币转移和流动性桥接只是第一步。cBridge 未来将朝着跨链跨层异步函数调用的状态桥接发展。发布于 2021-07-23 10:53小蚁区块链去中心化binance赞同 2添加评论分享喜欢收藏申请

Celer Network

r NetworkHOMEPRODUCTTECHNOLOGYBUILDBLOGCOMMUNITYCAREERBlockchains ConnectedEvery dApp, Every Asset, Every UserFastSecureLow costWhat is CelerCeler is a blockchain interoperability protocol enabling a one-click user experience accessing tokens, DeFi, GameFi, NFTs, governance, and more across multiple chains. Developers can build inter-chain-native dApps using the Celer Inter-chain Messaging SDK to gain access to efficient liquidity utilization, coherent application logic, and shared states. Users of Celer-enabled dApps will enjoy the benefits of a diverse multi-blockchain ecosystem with the simplicity of a single-transaction UX, all from a single chain.Learn More Use Celer Celer IMSimple, secure, and seamless multi-blockchain interoperabilityCeler IM (Inter-chain Messaging framework) fundamentally changes how multi-blockchain dApps are built and used. Instead of deploying multiple isolated copies of smart contracts on different blockchains, developers can build inter-chain-native dApps with efficient liquidity utilization, coherent application logic, and shared states. IM pairs Celer's Message Bus contracts deployed on different chains with the State Guardian Network, a Tendermint-based relayer blockchain, to send a message or invoke a smart contract function cross-chain.Learn more Use Cases cBridgeFast, secure and low-cost multi-blockchain asset bridgeCeler cBridge is a decentralized and non-custodial asset bridge that supports token transfer across 40+ blockchains and layer-2 rollups. Built on top of the Celer Inter-chain Messaging Framework, cBridge has processed more than $14B cross-chain asset transfer volume for more than 540K unique users, and is quickly growing and expanding into more blockchains and layer-2s.Use APPLearn more List Token PetiHigh liquidity efficiency, MEV protection, and zero slippagePeti is an omnichain liquidity protocol that provides the smoothest experiences for traders and the best liquidity efficiency for institutional market makers. For traders, it is often expensive, if not impossible, to execute large-size omnichain trades due to the high slippages of AMM pricing combined with limited depth of the liquidity pools of cross-chain bridges. Using Peti, traders now can utilize the “just-in-time” liquidity to execute omnichain trades with zero slippage.Learn more Build on CelerCeler IM SDKBuild exciting inter-chain dApps such as:Cross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceCross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceCross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceCross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceCross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceCross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceCross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceCross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceCross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceCross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceCross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceCross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceCross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceCross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceCross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceCross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceCross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceCross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceCross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceCross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceCross-chain yield farmingOne-click one-tx cross-chain swapsMetaverse games that use items from multiple chainsCross-chain state synchronizationCross-chain fee aggregationToken bridgingCross-chain liquidity provision and managementNFT bridgingCross-chain NFT bidding and purchasingCross-chain NFT collateralizationCross-chain governanceSDK Docs Talk to a Builder cBridge SDK Integrate cBridge as part of your application workflowIntegrate cBridge SDK for seamless asset bridging within your dAppEnable your protocol’s token for multi-chain expansionSDK Docs List your token Chains Supported Tokens SupportedPRODUCTSCeler IMcBridgePetizhanweiBUILDCeler IM SDKcBridge SDKExploreTechnologyBlogCareerzhanweiBug BountyBug Bounty - ImmuneFiBug Bounty - SGN(To Be Launched Soon!)Contact UsProduct SupportcBridge PartnershipCeler IM PartnershipPress InquiriesBrand AssetsCommunityContact: info@celer.networkPrivacyTerms© Copyright 2018-2023 Celer Network.All Rights Reser

Rollup Bridge 介绍（三）：Celer cBridge - 知乎

Rollup Bridge 介绍（三）：Celer cBridge - 知乎切换模式写文章登录/注册Rollup Bridge 介绍（三）：Celer cBridge沈绮虹 Daisy作者：Cyan Ho，imToken 资深区块链工程师本文受众：对 Rollup 有所了解的区块链爱好者Celer cBridge 是一个跨链资产转移方案，cBridge 同时支持了 L1 与 L2、以及 L1 与 L1 之间的资产桥接。我们可以从 cBridge 的 Web App 上看见他们已经支持了许多知名的 L1 与 L2 项目。cBridge 支持的链种本篇文章会侧重在 cBridge 背后的技术实现，包含运作原理、合约实践以及节点运维的介绍。运作原理cBridge 主要使用了 HTLCs 技术来实现跨链的资产转移，对于 HTLCs 不熟的读者，可以先参考这篇文章了解其原理以及应用场景：https://bcoin.io/guides/swaps.html 运作流程cBridge 在其合约 GitHub 的文件里描述了 cBridge 的运作流程，以下为节选部分：发送方在源链上发起 transferOut 交易cBridge 节点通过使用发送方设定的 hashlock，在目的地链上发起 transferIn 交易发送方在源链上确认交易cBridge 节点在目的地链上确认交易为了帮助理解，我将步骤画成如下的流程图：cBridge 运作流程图以下会针对四个关键步骤依序进行细节说明：第一步：发送方发起 transferOut 交易整个 cBridge 跨链的资产转移流程会由源链的发送方（即使用 cBridge 进行转帐的使用者）发起。发送方会负责产生 hash lock，设定转帐的时限，并与转帐的信息（token 地址、token 数量、目的地链代号、收款人地址）一同向部署在源链的 cBridge 合约发起 transfer out 请求。合约接收到请求后会先将要转帐的 token 数量，从发送方身上移转到合约身上，唯有提供 hash lock 的解答，或是转帐时限到期后，才能将 token 取出。第二步： cBridge 节点发起 transferIn 交易在链下的 cBridge 节点会持续监控各个链上 cBridge 合约的动作，当它发现源链上有一笔新的 transfer out 请求，它会在链上取得这笔 transfer out 的细节，主动对部署在目的地链上的 cBridge 合约发起 transfer in 请求。其中收款方为 transfer out 指定的收款人地址，并使用与 transfer out 相同的 hash lock，以及较短的取款时限（约为源链上设定时限的 2/3），并将 transfer out 指定的 token 数量扣掉 cBridge 节点转发的成本和手续费后，从 cBridge 节点身上转移至目的地链上的 cBridge 合约。此时 cBridge 节点并不知道 hash lock 的答案，要等到发送方在第三步完成源链上 transfer out 的拨款，并揭露 hash lock 的答案后，cBridge 节点才有能力执行目的地链上 transfer in 的拨款。第三步：发送方确认交易发送方确认 cBridge 节点有在目的地链上提交相应的 transfer in 请求后，就可以进入源链上 transfer out 的拨款阶段。发送方首先要对源链的 cBridge 合约提交 transfer out 的 hash lock 答案，合约验证答案无误后，会将 transfer out 指定的 token 数量转移给 cBridge 节点，完成源链上 transfer out 的拨款。第四步：cBridge 节点确认交易在链下的 cBridge 节点监控到发送方已经在源链上完成 transfer out 拨款后，随即拿著发送方拨款时揭露的 hash lock 答案，到目的地链上的 cBridge 合约提交 hash lock 答案，完成 transfer in 的拨款，此时目的地链的收款人就会收到来自源链发送方的款项，完成跨链的资产转移。细节步骤虽然看起来有点繁琐，但对于 cBridge App 的用户来说只要进行两次签名操作（第一步发送 transfer out 交易，第三步对 transfer out 拨款），并等待一些时间（3~5 分钟），过程中完全不需要切换钱包的网络，使用起来的体验是非常简单顺畅的。退款机制不管是 transfer out 或是 transfer in 都会设定一个有效时限，当有任何一方没有履行义务时，在设定的时限之后，双方都有能力可以直接要求 cBridge 合约退回事先放进去用来转帐的 token，不需要提供 hash lock 的答案。退款机制能够保护双方的资产，不会因为对手方不作为而导致资产被永久锁在 cBridge 合约上。另外值得注意的是，目的地链的 transfer in 会比源链的 transfer out 更早过期，有可能 cBridge 节点已经对 transfer in 进行退款，使用者才对 transfer out 进行确认拨款，此时也会对使用者造成损失。目前 cBridge Web App 设定的 transfer out 过期时限为 12 小时，其对应的 transfer in 约为 12 * 2/3 = 8 小时，时间相对充足，一般正常的转帐只需要数分钟，如果过程中有出现非预期的状况，还可以有足够的反应时间处理。简单的操作体验背后的成本眼尖的读者可能已经发现，cBridge 运作步骤中的第三与第四步，与典型的 HTLCs 不同。典型的 HTLCs 是发送方先到目的地链揭露 hash lock 的解答，确认收款人能够收到拨款，cBridge 节点才能到源链取回它在目的地链预先垫付给收款人的款项。Celer 官方说明这是为了提升使用者体验，如果走典型的 HTLCs 流程，使用者在确认 transfer out 拨款的步骤中，必须要切换钱包的网络至目的地链，还需要事先在目的地链上的钱包里准备足够的 gas token 来支付拨款所需的交易手续费，对使用者来说非常不方便。因此 cBridge 调整了最后两个步骤的顺序，让使用者只需要在源链进行操作，来大幅提升使用者的体验。但这样的调整并非没有成本，它会为使用者带来额外的风险。试想一个情境：当使用者在源链上完成 transfer out 拨款，cBridge 节点收到使用者的款项后，却没有在目的地链上将 transfer in 拨款给收款人（可能是恶意、gas token 不足或是当机），等到目的地链上的 transfer in 过期，cBridge 节点甚至有能力对 transfer in 进行退款的操作，cBridge 节点有机会可以无偿得到使用者转帐的 token。这部分必须仰赖使用者自己采取行动去降低风险，当使用者发现在 transfer in 有效区间内等了足够久的时间，收款人都还没有收到款项，使用者必须要自己主动到目的地链提供 hash lock 答案，完成 transfer in 拨款的动作，以防止资产被恶意取走。安全分析总结以上，我们针对发送方和 cBridge 节点在 cBridge 四个操作步骤中可能产生的安全问题，进行分析与整理：如果发送方执行了第一步但 cBridge 节点没有往下执行，此时发送方的资产会单方面地被扣押在源链的 cBridge 合约中，必须要等待 12 小时之后，才能进行退款。如果 cBridge 节点执行了第二步但发送方没有往下执行，此时发送方和 cBridge 节点的资产分别会被扣押在源链和目的地链的 cBridge 合约中，必须等到转帐过期后，才能各自进行退款。值得注意的是，cBridge 节点在目的地链上的 transfer in 有更短的过期时间（8 小时），能够比发送方更早完成退款。如果发送方执行了第三步但 cBridge 节点没有往下执行，此时发送方已将资产转给 cBridge 节点，但目的地链上的收款人还没有收到对应的款项。如果这个状态一直持续到目的地链上的 transfer in 过期后，cBridge 节点甚至有能力进行退款取回 transfer in 的资金，而造成发送方单方面的损失。这个状况会给发送方带来安全疑虑，发送方需要在 transfer in 过期前（8 小时内），自行（或委托他人）到目的地链上完成 transfer in 的拨款。正常 cBridge 的转帐流程能在十分钟以内完成，如果发送方拨款给 cBridge 节点后，收款人却迟迟没有收到款项，这时候就需要提高警觉了。如果 cBridge 节点执行完第四步但交易一直没有成功（例如 gas 不足），此时发送方仍然有资金损失的风险。因此建议发送方在完成拨款之后，要随时留意转帐的状态与经过的时间，以保护自己的资金安全。合约实践cBridge 合约实践很简单，提供了 transferOut、transferIn、确认以及退款的功能，不多不少，都是 cBridge 运作流程中的核心动作，而且这些方法都是公开可以让任何人去使用的。因此当节点在转帐过程中出现问题时，使用者能够直接对合约进行操作，保护自己的资产。cBridge 合约方法界面特别要注意的是合约方法 transferOut 的第一个参数 address _bridge。这个参数要填入能够服务这次跨链转帐需求（例如支持 1,000 USDT 从以太坊转账至 Polygon）的 cBridge 节点地址，换句话说，使用者在进行跨链转帐之前，必须先决定好要找哪个 cBridge 节点来服务。Celer 官方提供了一个网关服务，负责 cBridge 节点的路由，使用者只要将转帐的信息丢给该服务，它会选出符合使用者转帐需求，且当下状态最好的 cBridge 节点（例如成功率高、手续费低等等），使用者就能在进行 transferOut 时填入 Celer 网关推荐的 cBridge 节点。由于 Celer 官方并未提供网关的相关信息，有技术背景的读者可以试着去操作 cBridge Web App，了解其背后的实践细节。此外，合约里也有一些大家可以去关注的重要事件：LogNewTransferOut 事件：transferOut 完成时会发出的事件，会纪录这笔 transfer out 的 transferId。LogNewTransferIn 事件：transferIn 完成时会发出的事件，会纪录这笔 transfer in 的 transferId 以及其对应的 transfer out 的 transferId（srcTransferId）。在 cBridge 合约上不管是要进行确认或是退款，都需要提供 transferId，因此 transferId 在 cBridge 的应用中是至关重要的信息。除此之外，透过这两个事件的观察，能够帮助我们将跨链的 transfer out 与 transfer in 关联起来，有利于持续追踪转帐的状态，并在意外发生时有应对的能力。cBridge 合约事件界面节点运维Celer 官方开源了 cBridge 节点的实践，任何人虽然都可以跑起自己的节点，但 cBridge 现阶段有白名单机制，想担任 cBridge 节点来服务使用者必须要先跟官方接洽。担任节点的好处在于可以从每一笔跨链转帐中赚取一定比例的手续费，但也要考量到运维节点的成本，Celer 官方很贴心地在 cBridge 节点 GitHub 文件里详细列出了运维节点需要注意的事项，包含机器建议配备，支持的币种和最少需要提供的流动性，各条链的建议配置，运维节点的最佳操作等等，节点甚至还有内建统计数据的 API ，让运维者能够随时监控节点的交易状况。从 GitHub 文件的详细程度以及考量了运维节点的各个面向，可以感受到 Celer 官方对社群的用心。对于运维 cBridge 节点有兴趣的读者，建议一定要好好将 GitHub 文件过一遍。结语以上是对于 cBridge 背后技术实现的介绍，如果有任何想法想要分享，或是想要了解更多，都可以在留言区留言一起讨论编辑于 2021-09-23 18:35tokenRollup赞同 2添加评论分享喜欢收藏申请

跨链桥百家争鸣，安全易用还看 Celer cBridge - 知乎

跨链桥百家争鸣，安全易用还看 Celer cBridge - 知乎切换模式写文章登录/注册跨链桥百家争鸣，安全易用还看 Celer cBridge知乎用户SmMwyk比特币诞生十余载，区块链行业获得了长足的发展。其中以公有区块链为底层基础设施，经过市场的长时间的洗礼和考验以后，逐渐形成了「以太坊为核心，其他公链众星拱月」的局面。但是，演化仍在继续：一方面，以太坊底层性能不足，交易缓慢、Gas 费用高昂，诸多新兴公链（如 Solana、Near、Avalanche、Fantom 等）在不可能三角上进行了相应的取舍，对其进行了补充和扩展；另一方面，这些公链之间互不连通，从而导致它们成为了一个个割裂的价值小岛——亟需一座座桥梁将它们连通起来，释放整个加密资产流动性和可互操作性的最大潜力。不可或缺的「跨链」近期，DeFi、NFT、GameFi等 DApp 呈现大爆发局面，加密资产正逐渐获得专业机构和普通大众的关注和青睐，从业者仿佛看到了区块链光明的应用前景。但是，以太坊「一家独大但性能受限」犹如达摩克斯之剑悬挂在人们头上；而多个公链/二层解决方案之间的价值无法自由快速流通，使得某个应用只能在特定的链上运行，无法扩展到整个行业。所以表明上各个公链虽然“热闹非凡”，事实上它们却是“价值孤岛”，这与区块链“价值互链网”的美好愿景南辕北辙，不利于区块链行业的整体发展。因此，想要形成一个真正的价值互联网，就必须解决链与链之间价值流通的障碍，这就需要打破链间孤岛的跨链技术。而最近Chainswap、Anyswap和THORChain 等跨链协议接连被攻击，据统计损失超过 3000 万美元，表明了该领域仍然处在早期，相关协议的安全性及可用性等需要验证。其中 ChainSwap 是一个支持项目在以太坊、币安智能链和火币生态链之间实现无缝桥接的跨链资产桥；Anyswap 是一个基于 FusionDCRM 技术的去中心化跨链交换协议，也是目前 DeFi 用户最常用的跨链工具之一.....互联网是信息自由流通的网络，而区块链跨链网络则是价值自由流通的网络。独立的区块链网络终究要走向互联互通的未来，即 Web3.0 时代。如何将已有的的和未来将要开发区块链网络都联系起来成为统一的整体（也就是万物互联）是跨链网络最重要的问题。常见跨链技术简介跨链技术本质上是一种将 A 链上的数据 D（或信息 I，或消息 M）安全可信地转移到 B 链并在 B 链上产生预期效果的一种技术。跨链当前主要的落地场景为「跨链资产转移」，主要包括1）资产兑换：A 想用 X 链的代币兑换成 Y 链代币，B 想用 Y 链代币兑换 X 链代币，经系统撮合，两者互相兑换成功。2）资产转移：A 想把 X 链的资产转移到其他区块链上，在 X 链上锁定，在新的链上重新铸造等量等值的币。常见跨链模型主流区块链跨链技术方案主要分为四大类，分别是「公证人机制」、「侧链/中继」、「哈希锁定」以及「分布式私钥控制」，其原理简单介绍如下：公证人机制（Notary schemes）: 公证人也称见证人机制，本质上是一种中介的方式。在解决跨链交易确认时引入一个或者一组节点作为公证人参与到双方交易确认的事件中，由这个共同信任的中介进行跨链消息的验证和转发。代表项目为瑞波的 Interledger 协议。哈希锁定（Hash-locking）: 哈希锁定技术主要是支持跨链中的原子资产交换，是闪电网络提出的一种新的技术实现形式，指在智能合约的基础上让双方先锁定资产，如果都在规定的时间内输入正确哈希值的原值，即可完成交易。代表项目为闪电网络。侧链/中继链（Sidechains / Relays）: 侧链是指完全拥有某链的功能的另一条区块链，侧链可以读取和验证主链上的信息（例如一条链 B 能够拥有另一条链 A 的所有功能，则称链 B 为链 A 的侧链，链 A 为链 B 的主链，其中主链 A 并不知道侧链 B 的存在，代表项目：BTC-Relay）。而中继链则是侧链和公证人机制的结合体，中继链具有访问需要和验证进行互操作的链的关键信息并对两条链的跨链消息进行转移，代表项目为 Cosmos 和 Polkadot。分布式私钥控制（Distributed private key control）：基于密码学里面一个多方计算和门限密钥的一个共享技术。将私钥分为N份，同时分给N个参与者，只有收集了K个私钥的分配，才能够恢复出一个完整的私钥，才可对私钥中资产进行解锁。代表项目为 Wanchain。公证人机制、侧链/中继、哈希锁定以及分布式私钥控制方案在去中心化、安全性、吞吐量、延时、易开发性和模块化之间有着不同的取舍。目前跨链协议处于早期探索阶段，这仍是一个规模较小的市场，随着相关技术的成熟，市场需求将逐渐兴起，未来将呈现「百家争鸣」的场景。Celer 打造的跨链桥 cBridge在众多跨链方案中，由 Celer Network 主导开发的跨链桥 cBridge 值得关注，这背后不仅仅是Celer 团队长期深耕Layer 2 领域积累了丰富的开发经验。据介绍，cBridge 是一个支持高速低成本的跨链支付网络，允许用户通过该网络在任何以太坊 Layer 2 系统、以太坊主链、以及其他 Layer 1 或 Layer 2 之内或之间进行价值转移。Celer cBridge 的用例包括：在以太坊各个 Layer 2 之间的「快速低成本支付」而无需通过 Layer 1。支持的Layer 2网络包括 Optimistic Rollups（如Optimism、Arbitrum 和 Celer Rollup）， PoS 侧链（如 Matic 和 SKALE）等；在 Layer 1 和 Layer 2 之间的「快速资产转移」，无需经历长达数天的提现等待期；在无需通过主链的情况下，实现该条主链的 Layer 2 和另一条主链之间的「双向桥接」；与跨链路由的 Celer 状态通道网络「无缝连接」。在技术上，cBridge 和Celer原有的cChannel状态通道共享底层技术（哈希时间锁)。对现有协议进行扩展，使其可以在多条链上同时运行。相比于官方跨链桥，cBridge 能极大限度降低交易最终性延迟性和交易成本，继承了cChannel节点越多容量越大、兼容多个区块链并且支持所有基于 EVM 执行原理的公链（如以太坊、Thunder Token、Oasis Lab）、DFINITY 和波卡等的几大优势。cBridge 跨链工作机制一个典型的通过cBridge跨链的过程如下：用户向cBridge门户服务(gateway service)发出跨链请求，服务提供一个转发节点(relay node)的地址和所收取的手续费。用户通过链A上的cBridge合约向转发节点的地址发送一笔带哈希锁的转账，并指定一个过期时间锁。转发节点通过链B上的cBridge合约向用户的地址发送一笔带同样哈希锁的转账 (扣除一些手续费)。用户在发现这笔来自转发节点的转账后，在链A公布secret，解开哈希锁，把资金释放给转发节点。转发节点在链B用同样的secret解开哈希锁，把资金释放给用户，完成跨链过程。如果用户不公布secret，双方都可以在时间锁过期后，各自通过合约退回自己的资金。分析这一流程可以得出，相比常见的多签跨链，cBridge的资金安全完全不依赖第三方，不会出现近期其他跨链桥由于多签验证人权限设置失误、私钥被推出等导致的的被黑问题。在第一个公开版本中，门户服务相对中心化，但之后也可以转向去中心化。而且即使没有门户服务，用户和转发节点之间也可以点对点地通过合约完成跨链。另外，cBridge的手续费和跨链币种更加灵活，对不同的跨链需求可以有不同的定制方式。cBridge 优势综合而言，cBridge 具备以下优势：开发团队技术实力强大，Celer Network 为状态通道标准提出者。项目核心团队实力不俗，毕业于世界顶级名校。Celer Network 同时为币安 Binance Launchpad 的明星项目。低延时，比如Arbitrum上的用户可以直接向Polygon上的地址完成跨链转账。整个过程的在几十秒内完成，无需经过很长的提现挑战期。不仅能够连通多个 Layer 1 区块链，还支持所有基于 EVM 执行原理的二层网络、侧链/状态通道等，做到「多链多层」。根据最新的消息，Celer cBridge 主网发布包括两部分，分别是面向用户的界面和全节点软件。在该基础上：1）普通用户通过 cbridge.celer.network 便可以使用 cBridge，在以太坊、Arbitrum 和 BSC以及Polygon任意链或层之间即时进行资产跨链；2）有意愿运行 cBridge 节点并加入流动性桥接网络的人员可以到相应的 Github 仓库获取相关软件和运行方法，在参与网络建设的同时从中获取一定的收益。cBridge 的未来迭代包括：打造一个「cBridge 节点开放网络」，很快完全开放给任何第三方加入；根据用户和社区需求，「将支持更多的一层和二层区块链」；「动态定价策略 SDK」，为任何 cBridge 节点开放一个基于插件的 SDK，方便它们插入自己的策略和可用的决策因素；「状态和智能合约调用桥接」，在完成代币转移和流动性桥接后，cBridge 未来将朝着跨链跨层异步函数调用的状态桥接发展。基于上面提到的四种跨链机制和相关代表项目，我们对比了相关代表项目和cBridge在多方面的异同，供读者了解：不止于跨链，Celer 互连区块链的野心回到 cBridge 的开发方 Celer Network，它致力于以链下扩容技术为基石，构建匹配互联网规模的区块链应用入口平台，让所有人都能够在该平台上便捷快速地开发、运行与使用高性能的分布式区块链应用——其让 DeFi 便宜可用的「原地扩容」技术深得众多用户支持。Celer 另一个最新的成果为 Layer2.finance，它是一个无需迁移 DeFi 应用的扩容方案。基于 Optimistic Rollup，用户可以通过对 Layer 1 上的 Rollup 合约进行存款交易来将资金存入 Layer2.finance 的 Rollup 链，但是 Layer2.finance 不会将 DeFi 协议本身迁移到 Layer2。Layer2.finance 主网已于 4 月下旬正式上线，第一批支持的 DeFi 协议为 Compound、AAVE 和 Curve。近期 Layer2.finance v1.0 版本测试网也已经上线，版本即将上线多链支持、支持即时（JIT）策略仓位执行和灵活滑点缓冲、策略风险防火墙、灵活的费率接口、去中心化治理、流动性挖矿等多个最新功能。同时它在 7 月 7 日 - 20 日期间举行了「稳定性测试大赛」，系统简单地根据用户的操作次数进行奖励，从而对系统在高压环境下的表现进行检测。根据《理想中的跨链桥，是什么样？》一文，Layer 2 的跨链为进阶需求，不仅仅是区块链之间的跨链，更能连通多个 Layer2 网络，即：「防止流动性被割裂，防止DeFi 的可组合性被拆散」，Optimism 等四大通用型 Layer2 之间势必需要一种资产快速流动的通道，甚至是 Layer2 与异构链的资产流动通道。从Layer 1 路由一遍效率实在太低，而 Layer 2 的共识机制也注定了短期无法承载前述「打包+铸造 / 销毁」的方案，所以状态通道似乎理所当然的成为了可行方案中最能够被期待的那个（状态通道小额、高频的跨 Layer2），e.g. Celer Network, Connext。从 cBridge 到 Layer2.finance、原地扩容技术、Celer SDK 等多个成果，表明了 Celer Network 在扩展二层网络的探索和突出贡献。cBridge 在打通各个区块链，提供原生互操作性和可组合性中具备重要意义，其扩容方案让太坊各个区块链和 Layer 2 之间进行快速低成本支付，将在日益增长的加密市场中发挥重要作用，真正让 DeFi 实现金融平民化。引用内容：Celer Network 官网：https://www.celer.network/关于跨链技术的分析和思考：https://mp.weixin.qq.com/s/fgRPwzVPB3Si5aHSCACvAgCeler cBridge——面向Layer-1和Layer2互联未来的高速低成本价值转移网络：https://mp.weixin.qq.com/s/QzkR-XlH-2DhHbFApemz4w日渐成熟的以太坊 Layer 2 扩展方案对比评估：https://www.chainnews.com/articles/003295982317.htm理想中的跨链桥，是什么样：https://bihu.com/article/1052541316发布于 2021-07-29 02:32区块链技术跨链赞同 6添加评论分享喜欢收藏申请

Welcome to cBridge - Celer cBridge

一周年巡礼：安全和迅速是cBridge长期的追求_腾讯新闻

一周年巡礼：安全和迅速是cBridge长期的追求

7 月 18 日，Celer 官方 Twitter 发布了一条推文：旗下产品 cBridge 跨链资金总量已经超过 95 亿美金。对于跨链桥赛道而言，这是一个极为难得的成绩，cBridge无疑已跻身跨链桥赛道T1行列。更值得一提的是，至今 cBridge 还未出现过安全事故。

行至如今，cBridge 已经顺利走过一个年头。而于 2018 年成立的 Celer 已经是加密协议中的“活化石”。我们也可以在其协议名称「Celer」中领略到团队在其立项之初的初心和愿景。

在拉丁语中，Celer 意为「迅速」。

自问世之后，Celer 以技术作为驱动力，从状态通道做起，后又参与了 Rollup 技术的实践，致力于 Layer2 扩容领域。在多链格局初现苗头时，Celer 又在 2021 年 7 月推出了名为「cBridge」的跨链桥，并在之后的一年中陆续支持了 34 条公链和 129 种 Token 的资产/信息跨链。

我们可以清晰直观地感受到：Celer 所做之事都是为了用户能够更加「迅速」地完成链上操作——更迅速地使用区块链，更迅速地在各条区块链之间辗转腾挪，为投资者提供更加迅速的链上操作体验。

伊始：产品方向的转变

多链并行发展是一个几乎所有人都看得到的结果。这一切都来源于以太坊在承接了大量用户后所展现出的性能不足。自 BSC 推出之后，大量公链推出的目标几乎都是为了承接来自以太坊的外溢流量。

Celer 产品方向的转变也从那时开始。

Celer 推出 cBridge 的愿景更多是为了解决链上用户日益增长的跨链刚需。本质而言，cBridge 的推出依然在践行着 Celer 团队本身的理念——「迅速」，而 cBridge 的推出速度也印证了 Celer 技术团队在技术创新层面的实力。

一年后，cBridge 成绩如何？

上文已经提到，在稳定的资产跨链和良好的用户体验，以及从未出现过安全问题的情况下，cBridge 跨链资金总量已经达到 95 亿美金，陆续支持了 34 条公链和 129 种 Token 的资产/信息跨链。

而在跨链桥 TVL 总锁定价值层面，据 DeFiLlama 数据显示，目前 cBridge TVL 约 3 亿美金，最高 TVL 曾到达过 7.5 亿美金。TVL 大幅下跌的时间节点在 5 月左右，显然受到了加密市场 LUNA/UST 崩溃的影响。

如果我们从 ETH 本位的角度来看 cBridge 的表现，就会发现 cBridge 的 TVL 与加密市场整体状况有着强关联性，且在加密市场下跌之时，用户使用率和采用量并没有受到非常严重的影响。在人们对于加密市场的信心稍稍恢复后，ETH 兑 cBridge TVL 的数量就会回升。

对于选择 cBridge 的用户而言，其最大优势便是 Celer 团队在技术层面对于安全的考量和在人性层面对于安全的追求。

对安全的追求：cBridge 的制胜法宝

在公链们各显神通的时候，一个不可忽视的事实是：负责链与链之间资产跨链以及通信的跨链桥由于跨链技术的复杂性和不成熟，逐渐被黑客们当成了提款机。

2021 年 8 月，跨链互操作协议 Poly Network 遭到黑客攻击，使用该协议的 O3 Swap 遭受了严重的损失，总损失高达 6.1 亿美元。

2022 年 1 月，Multichain 正式声明协议的跨链桥存在安全风险，部分代币存在被黑客攻击的风险，并敦促用户尽快取消授权。而 Qubit Finance ETH-BSC 跨链桥被黑客攻击，损失超过 8000 万美元。

2022 年 2 月，以太坊和 Solana 两大区块链的重要跨链桥 (Wormhole) 被黑客攻击，损失超过 3.2 亿美元。

2022 年 3 月，Axie Infinity 侧链 Ronin 验证者节点和 Axie DAO 验证者节点被破坏，导致在两笔交易中从 Ronin 桥接了 173600 ETH 和 2550 万美元的 USDC。

......

有关跨链桥的黑客事件不胜枚举，直至如今，跨链桥的相关事故仍在不断发生。而难能可贵的是，在推出的一年时间中，cBridge 从未曾出现过安全事件。

关于安全，Celer 团队在这一年中也从未停下脚步：

SGN 网络

治理攻击是一个非常常见黑客攻击手段。在 Axie Infinity 侧链 Ronin 跨链桥被攻击的案例中我们可以看到，Ronin 验证者节点和 Axie DAO 验证者节点被破坏，黑客利用此漏洞拿走了桥中的 173600 枚 ETH 和价值 2550 万美元的 USDC。

对此，Celer 团队的解决方案是使用状态守卫者网络（State Guardian Network，以下简称 SGN）来保障 cBridge 的安全性。由 Celer 创建的 SGN 是一条基于 Tendermint（PoS）的区块链，它将为 cBridge提供 Layer1 级别的安全保障。

中间延迟

「中间延迟」是 Celer 专门设置的一个双重保障，跨链 DApp 可以在延迟的抉择上做出不同的选择和权衡。

原因显而易见——因没有延迟而导致跨链桥瞬间被黑客搬空的例子也很常见，Celer 希望杜绝因一次交易而清空整个池子流动性的情况出现，从而降低桥的整体系统性风险。

风控系统

在安全观念的执行中，Celer 团队也为 cBridge 设置了多道安全屏障：搭建风控系统（监控桥的整体流动性，资产信息以及变化）、限流（单位时间内不能超过某一个特定的阈值，超过了会顺延时递）、24 小时监控、200 万美金的 BUG 悬赏等。

那么，加密世界存在绝对安全吗？答案是否定的。在这片黑暗森林中，没有人会向你保证“绝对安全”，但 Celer 团队对于安全的追求是长期的。只有坚持着对“绝对安全”的持续追求，Celer 所代表的「迅速」才会被更好地践行。

升级：从应用到生态

上文提及，在经历加密市场的崩溃后，链上需求逐步减少，跨链桥的采用率相应变低。本质原因则是链上利润不足，DeFi 无法为链上投资者提供与其面临风险一致的利润回报，投资者便也会丧失兴趣，不愿意将资金投入到 DeFi 当中。

但当有足够的利润摆在人们面前时，投资者的链上活动和跨链行为便会迅速增长。Layer2 Arbitrum 奥德赛活动的火热便是一个很好的例子，在活动最热的时间点，Arbitrum 的链上 Gas 费用甚至超过了以太坊。

不过，需要重视的是，链上投资者对于跨链的需求是多层次且复杂的——从简单的资产跨链到信息跨链，再到对于构建跨链生态的需求。并且，跨链的频率和场景正在迅速增长。

为了匹配更丰富且复杂的跨链需求，正当时的 Celer 推出了 Celer 消息跨链框架（以下简称为 Celer IM）。Celer IM 是面向开发者的工具和基础设施，即插即用，开发者不需要修改已部署合约的任何代码，只需要一个简单的合约插件便可以将原 DApp 转变为原生跨链 DApp，彻底打通应用层之间的壁垒。

一个很简单的例子便是：SushiSwap 的用户可以通过一次简单的交易将 Arbitrum 上的 ETH 交换为 BSC 上的 BNB。在交易背后，智能合约是如此执行的：

通过 SushiSwap（Arbitrum）将 ETH 兑换为 USDT；

作为 Celer IM 框架的一部分，Arbitrum 上的 USDT 通过 cBridge 桥接到 BSC；

通过 Celer IM 向 SushiSwap（BSC）发送执行将 USDT 兑换为 BNB 的链间消息。

当前大多支持多链的 DApp 的常见做法是通过简单地在多条链上复制相同的代码来实现，但每条链上的 DApp 的流动性、应用程序逻辑和状态彼此完全隔离。我们甚至可以将他们看作是两条链上两个不同的去中心化应用。如此一来，流动性/资金效率低便成为了无可争辩的事实。

Celer IM 允许 DApps 实现在多条链之间的流动性共享和连贯的应用程序逻辑，提升流动性/资金效率，在多链的格局下，践行着团队对于「迅速」的追求。

起航：成为跨链龙头

在大航海时代之前，由于通讯技术和交通工具的不发达，每个文明就像一个孤岛，只与相邻的文明进行简单且直接的交流。而随着时间的推进，航海家们对于未知的探索，各个文明逐步被连接起来。就像如今的多链生态，随着以太坊性能的不足以及更多开发者对于高性能公链的追求，不断有新的公链正在被推出，而跨链桥便也成了刚需。

Celer 秉持着「安全至上，技术创新迅速」的追求，cBridge to C，Celer IM to B，双管齐下，搭建了愈发完善的区块链互操作基础设施，走入了我们的每一次跨链操作中。

也正如哥伦布所言，「世界属于勇者」，是亦步亦趋，还是勇敢去探索新的大陆，Celer 的选择是后者。对于 cBridge 而言，星辰大海的征途才刚刚开始。

*深潮CryptoFLow 是深潮TechFlow旗下价值投研平台，本文所提观点不构成任何投资建议。

Celer cBridge: Fast and Low-cost Value Transfer Network for an Interconnected Layer2 and Layer1 Future – Celer Network

Celer Network

HomeWebsiteAbout CelerTechnologyCommunityWeekly Report

127

Celer Network Follow

Celer cBridge: Fast and Low-cost Value Transfer Network for an Interconnected Layer2 and Layer1 Future

2021-02-15

4 min read

Figure1. Illustration of Celer cBridge architecture

We are thrilled to introduce Celer cBridge, a multi-chain network that enables instant, low-cost and ANY-to-ANY value transfers within and across Ethereum’s layer-2 chains, Ethereum main chain and in the future, other layer-1s, and layer-2 on top of those other layer-1 chains.

A summary of some immediate use cases of Celer cBridge are：

Instant and low-cost multi-hop value transfer between multiple different layer-2 networks on Ethereum, including Optimistic Rollups, such as Optimism, Arbitrum and Celer Rollups, and PoS Sidechains such as Matic and SKALE, without going through underlying layer-1 blockchain. Instant entering and existing layer2 from/to Ethereum layer-1 without long delay. Two-way bridging between layer-2 on one blockchain and a completely different layer-1 blockchains without going through the corresponding root layer-1 at all. Seamless connection to Celer State Channel Network in any single chain with full cross-chain routing support.

Why is cBridge important?

We are moving towards a multi-chain world as dApps and token assets are distributed over more and more loosely joined systems with different tradeoffs on security, throughput, latency, developer friendliness and modularity. These systems include different layer-1 blockchains, such as Ethereum, Cosmos and Polkadot, shards on those chains, and then different layer-2 scaling solutions on top, such as Optimistic Rollup, ZK Rollup and sidechains.

While transactions within each system are relatively smooth, value transfers across these chains are usually expensive and slow. For example, moving funds out of an optimistic rollup chain may require many days of delay. Transferring tokens from one rollup to another rollup system is even more expensive and time-consuming.

To keep liquidity flow efficiently between these loosely coupled systems without long delay and trust-based custodian, a universal value network that connects parallel chains and flattens different layers becomes increasingly needed.

cBridge is such a universal value transfer network. As illustrated in Figure 1, utilizing cBridge along with Celer State Channel, a client on Arbitrum rollup on top of Ethereum can transfer to a client on Polkadot via multiple cBridges that first relay liquidity from Arbitrum to Optimism Rollup, then to layer-1 Ethereum, then several hops across Celer State Channel Network on top of layer-1 Ethereum, and then to Polkadot. This can all happen within milliseconds that are spent in speed-of-light message passing and with minimal costs.

To take a closer look at the speed improvement: performing the above series of operations without cBridge will take approximately half a month, which is approximately 1,000,000X slower than doing it via cBridge. On the cost side, cBridge provides the same cost profile as state channel and instead of incurring costs on a per transaction basis, the cost can be associated with the amount of value transferred and liquidity used across the network. This drastically reduces costs for smaller-sized liquidity movements in the order of $100s to $1000s. It is clear that constructs like cBridge is crucial to enable a unified active liquidity across these systems and allow mass audiences to use applications in different tradeoff universes.

How does cBridge work?

As illustrated in Figure 1, we build cBridge by extending Celer Network’s state channel network’s functionality. To bridge liquidity instantly across multiple chains, we modified the off-chain communication protocol to enable “multi-homing”. For example, node A in Figure 1 simultaneously has presence on Optimism rollup, Arbitrum rollup, Celer rollup and Ethereum layer-1. Node A essentially connects to users who wants to bridge liquidity on all of the four chains and provides the bridging liquidity to bridge between layer-2 and layer-2 to layer-1. It is also important to note that multi-homing nodes (e.g. Node B) also can connect to state channel “subnets” on each chain individually and the connection between these multi-homing nodes essentially formed a “backbone” network across different chains.

Figure 2. Simplified Example for cross-chain liquidity bridging

Figure 2 shows a simplified example of the cross-chain state channel network where A from chain-1 transfers funds to D at chain-3 through a cross-chain multi-hop payment. The different chains can be a mix of Arbitrum/Optimsim rollup chain, eth2 shard, or any EVM compatible chain. Intermediate nodes (B and C) act as off-chain service providers (OSPs) that offer liquidity and payment routing service to the end users (A and D). In this example, B hosts service in chain-1 and chain2, C hosts service in chain-2 and chain-3.

If all nodes are cooperative, the cross-chain payment can be settled end-to-end instantly. If any node along the path is uncooperative or malicious, other nodes can force settle the payment on the chain through the CelerPay contracts. Our online architecture documentation has detailed descriptions on the single-chain CelerPay contracts and payment protocol. To extend them to support cross-chain payment, we need to deploy the contracts on each chain, add chain-id as a higher layer of address space, and add protocol to convert payments across different chains. Back to the example above, payAD, payAD*, and payAD** share the same src/dst addresses, payment value, and hash lock condition, but have different local token addresses and resolver contract addresses. These conversions are done at the ingress service node (B and C).

How is cBridge different?

cBridge extends our existing production-ready state channel core code that has been battle-tested in gaming applications with one million users. Alternative solutions to cBridge include various cross-layer-1 non-custodial bridge contracts and other layer-2 bridges such as Vector built by our friends from Connext. See below table for a quick comparison.

Feature SupportNon-custodial Bridge ContractVector from ConnextcBridge from CelerGeneralized conditional transferNo, mostly simple hash lockYes, no built-in conditionYes, with optimized built-in conditionsCost of repeated paymentHighLowLowMulti-hop value routingNoNoYesFull duplex concurrencyN/ANoYesNon-EVM chain supportN/APlug-in neededPolkadot substrate supported. Plug-in needed for othersState backupN/ANoYes, via Celer SGNChallenge watchtowerN/ANoYes, via Celer SGNSoftware ScalingN/ASingle nodeEasy clustering

How to use cBridge?

The implementation is added as a part of our Celer State Channel Network. To add a new chain to Celer Bridge Network, one can simply deploy CelerPay contracts on any EVM-compatible chain or deploy corresponding plug-in in non-EVM compatible chains (e.g. Celer substrate module on Polkadot). After that, a cBridge node operator then starts Celer Node servers on each chain, and uses the CLI tool to populate the multi-homing config (example) into each OSP database. Here is an end-to-end example for configuring and setting up a cBridge node across three networks/chains.

Celer cBridge is production-ready and the on-chain component is not changed from Celer State Channel Network’s CelerPay contracts. As the layer-2 system rolls up, we will release a user-friendly web interface for mass audiences to use cBridge Network shortly.

Have questions?

Ask us in our Discord channel!

Follow Celer Network:

Website| Telegram | Twitter

Meetup | Github | Discord

分享此文：TwitterFacebookLike this:Like Loading...

Celer Network Follow

About Celer

News

no-categorize

Technology

« Update on State Guardian Network Mainnet Phase One

Layer2.finance: Get DeFi Mass Adoption Today, Scaling Layer-1 DeFi “In-place” with ZERO Migration »

illumineX Integrates Celer IM for Seamless Cross-Chain Swaps

Celer Network

Feb 23, 2024

1 min read

Celer cBridge Expands Support for BRC-20: Bridging between BTC…

Celer Network

Jan 2, 2024

2 min read

Celer Partners with AltLayer as Part of Their Interoperability…

Celer Network

Nov 23, 2023

2 min read

cBridge 2.0: Coherent Blockchain Interoperability Powered By The State Guardian Network – Celer Network

Celer Network

HomeWebsiteAbout CelerTechnologyCommunityWeekly Report

Celer Network Follow

cBridge 2.0: Coherent Blockchain Interoperability Powered By The State Guardian Network

2021-09-22

14 min read

Since the release of cBridge 1.0, it has seen a continuous doubling of volume week over week. Starting at $10M of total volume for the first month, it reached $170M in the second month with now over $10M of daily volume. At this point, we are seeing around a 45% APY just on fees for the liquidity provided. Exciting? Absolutely—and we are just getting started!

Enter cBridge 2.0: an innovation-packed major upgrade. cBridge 2.0 introduces the best-in-class cross-chain token bridging experience with deep liquidity for users, highly efficient and easy-to-use liquidity management for both cBridge node operators and Liquidity Providers who do not want to operate cBridge nodes, and new exciting developer-oriented features such as general message bridging for cases like cross-chain DEX and NFTs. All of the above is made possible by extending the existing functionality and services provided by the Celer State Guardian Network (SGN) powered by validators and stakers in the system with value capture.

TL;DR: How is cBridge 2.0 better?

For folks not interested in the shadowy super-coder technical stuff, here is a quick summary of improvements and additions brought by 2.0.

For users

Deep liquidity: supports much larger transfer sizes. Simpler to use: offer an option to reduce two-step operations to a single click.Native gas token unwrapping: e.g. transfer WETH from BSC to unwrapped ETH on Arbitrum. Extend to even more tokens and chainsInsured bridge node Service Level: did you initiate a transfer but the bridge node was not available? Slash cBridge node’s bond to cover your opportunity cost!

For LPs and cBridge node operators

LPs don’t have to run a cBridge node: in cBridge 1.0, the only way to provide liquidity is to run a cBridge node. In 2.0, we added a second mode where the SGN itself acts as a “cBridge node.” For LPs satisfied with PoS-consensus-level security based on CELR token economics in the SGN, they can directly delegate liquidity to the network without operating a node themselves. Simple Liquidity Provider (LP) experience: No minting synthetic tokens, no volatile token pair AMM pool, no high impermanent loss, no complicated rebalancing. Simply add liquidity to the chain of your choice and start to earn fees! High liquidity efficiency: No double liquidity locking, fully utilize liquidity with the highest yield.Incentivized liquidity rebalance: lopsided liquidity movement? No worries! An AMM-style bonding curve and a flexible liquidity mining mechanism are in place to incentivize LPs and arbitrageurs to rebalance liquidity cross-chain. High Quality-of-Service node scheduling: For LPs operating self-custodial cBridge nodes, the SGN becomes the decentralized layer to allocate user transfer requests to different LPs through policies that incentivize high-quality service and competitive pricing.

Fo staker and validators participating in State Guardian Network

Value capture: In return for their active services and roles in supporting cBridge 2.0, PoS stakers and validators in the SGN directly capture the value of cBridge via fees paid to the block producer facilitating user’s bridging request. This is very much like fee being paid for any PoS blockchain validators. Governance: Various system parameters including pricing curve, fee percentage, and more are governed through a decentralized governance process built in the active service SGN.

For developers:

White-label frontend SDK: Allows multi-chain dApp to have a built-in cross-chain experience.Cross-chain messaging for NFT and more: Allows developers to build applications beyond simple cross-chain asset transfers, including cross-chain DEX and NFT cross-chain minting.

So, how do we achieve all of these cool improvements and innovations? What bridging design tradeoff space do we cover in the 2.0 architecture? At a high level, how exactly do all of these things work?

Answer: The State Guardian Network (SGN).

In cBridge 2.0, we extend the SGN to support two different bridging operation models that can cater to LPs and users with different preferences. In this blog, we provide an architectural overview with detailed technical specifications to follow.

Refresher on the State Guardian Network

The Celer State Guardian Network (SGN) has been an essential part of Celer Network’s architecture. In Celer’s layer-2 scaling architecture, the SGN is a specialized Proof-of-Stake (PoS) chain that serves the purposes of monitoring L1 transactions related to L2 state and faithfully passing layer-2 information back to layer-1 when needed.

In the Celer State Channel, the SGN helps store channel states and respond to malicious settlements on L1 when needed. In the Celer layer2.finance rollup chain, the SGN extends as a decentralized block producer network to pass call data and state roots back to the L1 blockchain and submit fraud-proof from any SGN node even when the entire PoS consensus fails.

CELR holders can stake their tokens into the SGN by becoming a validator or through delegation and actively provide the above-mentioned services. SGN participants receive staking rewards as well as fees in exchange for the services they help provide.

The SGN as a cBridge node gateway and Service Level Agreement (SLA) arbitrator

Design Choices and Limitations of 1.0

In cBridge 1.0, when a cBridge node joins the network, it registers to a gateway service with various information such as fee schedule and liquidity status. This gateway will continuously monitor the status and performance of the cBridge node. When a user request is made, it is directed to the gateway. The gateway evaluates the registered nodes based on liquidity availability, historical bridging success rate, fee, and more. Then it suggests the most suitable bridge node for the request. In 1.0, we chose to use a centralized gateway to quickly learn operation experiences on various scheduling policies.

Basically, what the 1.0 gateway provides to the user is really an “FYI” suggestion to use certain cBridge nodes. Although cBridge 1.0 is built with non-custodial architecture and users NEVER need to put trust in nodes for their fund’s security, there is indeed a user experience issue related to node availability. As an example, if after a user sends a conditional transfer to a node but the node goes offline before the two-step HTLC transfer is complete, they will have to wait until the conditional transfer times out, without any penalty to or compensation from this offline cBridge node.

We solve both of these limitations in 2.0 via the SGN.

Decentralized bridge node scheduling via the SGN

In 2.0, we first decentralized all of the gateway logic by migrating it as a service on top of the SGN. Instead of registering with a centralized gateway service, cBridge nodes will register with the SGN with their fee preference, availability of liquidity, and more.

When a user request is made, this is the “happy” system flow:

The user queries the current state of the SGN to get an estimated transaction fee and liquidity availability. If the estimation is acceptable, the user sends the first half of the HTLC transfer with max fee tolerance specified.The SGN monitors and picks up the transaction. It assigns one or more registered cBridge nodes to the transaction based on node selection rules. This transaction assignment is written on the SGN chain and also marked on the user’s HTLC transfer. The assigned node picks up the assignment and responds by completing the rest of the conditional transfer.The SGN continues to monitor and track the transaction and once the transaction is successfully completed, the state related to this transaction is purged from the SGN chain.

This allows for a much more scalable cBridge node onboarding process with a consensus-based and unbiased node selection process. But we didn’t stop there.

Bridge node SLA bond and slashing mechanism

As opposed to 1.0’s gateway, the SGN-as-a-gateway architecture monitors the whole process of the cross-chain transaction. As a decentralized PoS chain, the SGN can now offer more than just a “friendly suggestion.” It can also enforce penalties to registered cBridge nodes that cannot complete transactions assigned to them “as promised.”

When a cBridge node registers with the SGN, it can put down an “SLA bond” (i.e. a bunch of tokens with value) associated with some SLA promises (e.g. availability, fee level, and liquidity reserve) in a pool contract. If the SGN determines that this node violates the SLA, such as being offline with an assigned transfer, the SGN can slash the bond as compensation to the user for the degraded user experience and liquidity opportunity cost. (remember, no fund loss for users is possible, this is just for “fund getting stuck” cost.)

During node selection, the value available in the SLA bond is a key factor in how the node is prioritized in the transfer assignment process. Honest and reliable cBridge nodes are heavily incentivized to invest in a reasonable SLA bond to increase their chances of getting selected in the bridging process. On the other hand, less reliable nodes will be driven out of the system or will only be called upon as a last option. Finally, cBridge nodes can only be de-registered with the SGN once there are no pending cross-chain transactions.

With the SLA bond slashing capability powered by the decentralized “SGN gateway,” the node availability challenge, and more generally, the SLA assurance concerns, are solved. This is aimed to facilitate a healthy, fast-growing, and decentralized cBridge node operator network for liquidity providers who want to maintain their self-custodial liquidity.

Some may argue that the SLA bond is not a 100% self-custodial setting due to the possibility of having the SLA bond wrongly slashed because of the possibility of a PoS consensus failure.

While this is true, we want to highlight that the SLA bond only needs to be a very tiny portion of the total liquidity in order to become highly efficient in ensuring a smooth user experience and a self-healing cBridge node operator ecosystem. This is a very worthwhile tradeoff to make and most importantly, the entire transfer process stays 100% non-custodial.

Node selection rule

The principle of the node selection rule design is to optimize for user experience. We build an empirical Node Quality Score formula to incorporate multiple factors such as the parameters in a node’s SLA (fee, response time) as well as historical performance. (e.g. success rate, average response time) When selecting nodes for user requests, we prioritize the nodes according to this score. We expect this formula to iterate and optimize over time with empirical operation experiences through protocol governance.

The SGN as a Shared Liquidity Pool Manager

Provide liquidity without running a cBridge node

The above improvements are designed more for self-custodial LPs who are capable of running their own cBridge nodes. However, we recognize that there are a large number of LPs and users who want to provide liquidity without running a cBridge node themselves and are satisfied with the security level provided by the SGN’s PoS consensus with CELR staking. In addition, through a shared liquidity pool model, the entire network liquidity can be easily bootstrapped to facilitate a much better user experience much faster.

So in cBridge 2.0, we are introducing an entirely new model of operation where the SGN manages shared liquidity pool contracts on multiple chains. This effectively treats the SGN and its managed liquidity pool as a single “node” along with all the other non-custodial LP-managed nodes and gives an option to the LPs to delegate liquidity easily without the hassle of running a node.

So, without any ambiguity, what security level does this model offer?

PoS-level security and decentralized governance

In cBridge 2.0, shared liquidity pool contracts are managed through the SGN’s PoS consensus. CELR staking weighted multi-signatures are needed to move funds in the pool contracts and malicious or faulty nodes will be slashed out of their staking token. It is only when nodes with more than ⅔ of the total stake are malicious, that the fund pool will be at risk. We want to stress that as the number of cBridge transactions grows and the total value captured by the network grows, it will be a naturally increasing economic deterrent for any node to try to behave maliciously.

The validator governance model in the SGN is open and decentralized: the SGN allows new validators to be elected and join the validator set through the staking governance process without any special coordination processes.

Simple Liquidity Provider (LP) experience and high liquidity efficiency

So how do LPs manage their liquidity in this model? Existing solutions require LPs to put canonical token liquidity along with another protocol-controlled settlement token in on-chain AMM pools. But this model has a few drawbacks:

Some models require LPs to use a highly volatile settlement token and therefore inherently expose LPs to a significant impermanent loss. Even in the case of minting synthetic tokens through canonical liquidity tokens, LPs still suffer from complicated operational overhead when adding, removing, and rebalancing liquidity across multiple chains. In the case where “bonder” liquidity is required, the liquidity efficiency is lower because the liquidity requirement for any transfer is double what’s necessary.

cBridge 2.0 provides a simple LP experience and high liquidity efficiency through a new design to solve the “liquidity attribution problem.” To understand our system design, we will first explain what “liquidity attribution” means. In any multi-chain bridging system, when a user sends funds from a source chain to a destination chain, LP(s) (or aggregated pools) essentially pay funds to the user on the destination chain while receiving funds from the user on the source chain. Now, let’s say there is an LP providing liquidity to the system on chain A. When a user sends funds from chain B to chain A, the LP’s liquidity essentially is “redistributed”: their liquidity on chain A is reduced and their liquidity on chain B is increased. The liquidity attribution problem is defined as “how does the system allow every LP to know where all of their liquidity is?” and hence how to effectively manage the liquidity to optimize for transaction fee yield.

An AMM pool-based solution tracks LPs liquidity implicitly via the distribution of settlement tokens and canonical tokens in the AMM pool. The bridging fabric (e.g. TSS validators or L2-to-L1 messaging protocols) only manages the minting and burning of the settlement tokens cross-chain. The user will always need to pay for an AMM swap from the settlement token to the canonical token on the destination chain; sometimes even on the source chain as well. When a lopsided liquidity movement happens in the network, it makes sense to move liquidity from the liquidity-abundant chain to the liquidity-scarce chain to arbitrage the slippage. Arbitragers will have an incentive to rebalance the liquidity by sending funds from the liquidity-scarce chain to the liquidity-abundant chain.

Active LPs have stronger incentives due to that they don’t need to pay additional bridging fees to harvest the arbitrage gain. However, the rebalancing process for LP is quite complicated. As an example, if we denote the liquidity-scarce chain as S and liquidity-abundant chain as A, an LP would need to take the following steps:

Remove liquidity from the AMM pool in S. Move the settlement token from S to A. Sell the settlement token to the canonical token on A at a premium Move the canonical token back to S. Purchase the settlement token on S. Add liquidity back into the AMM pool on S.

The above steps not only cause operational overhead but can also incur significant transaction and time costs. (e.g. in the case of the bonder model)

In cBridge 2.0, we argue that the bridging fabric (in our case the SGN) is specialized and can be highly optimized to have fundamentally lower costs when compared to on-chain smart contract operations. Therefore, in the cBridge 2.0, every LP’s liquidity in the system is explicitly tracked. Adding liquidity is super simple: just one transaction to add the canonical token into the liquidity pool contract and the SGN will record each LP’s liquidity amount in the SGN’s chain state. In essence, the SGN maintains a table of (chain_id, LP_address, token_type, balance) in its chain states.

When processing cross-chain transfer requests, the SGN will use the entire pool’s liquidity to calculate the slippage and pricing. (more on this in the next section) The SGN then treats LPs as “virtual cBridge nodes” and allocates the transfer request against the LP’s liquidity. A simplified conceptual understanding is that, for every transfer request, every destination chain’s LP’s balance is reduced proportionally to their available liquidity while their liquidity balance is increased on the source chain. Of course, various methods including random sampling and approximation algorithms are used to minimize state changes and hence costs, all while maintaining statistical fairness among LPs. More details are in our technical documentation.

The same arbitrager-based rebalance incentives applies, but this design additionally gives LPs the utmost flexibility when managing their liquidity. Every LP can clearly see exactly how their liquidity is distributed at any given time. This allows them to be fully informed when choosing to remove or add liquidity to any chains. This significantly simplifies the liquidity rebalancing process from 6 steps to 3 steps with no AMM swap costs:

The LP removes liquidity from A directly in canonical tokens. Due to system-wide pricing difference, with this first step, the LP locks in the arbitrage gain.The LP moves the canonical tokens from A to S.The LP adds the canonical tokens on pools in S.

It is still possible for LPs to remove all liquidity from a single chain or any combination of specific chains. In cBridge 2.0, the way to do this is to trigger an internal cross-chain transfer and treat the LP as a user and transfer their liquidity to the desired chains and then remove the liquidity. Note that in this case, the LP will shoulder the system slippage for the cross-chain transfer. However, this is no different than directly swapping settlement tokens for the on-chain AMM-based solutions and in fact, has a lower cost.

What’s more, as described in this model, LPs use canonical token liquidity directly and therefore do not suffer from high impermanent loss. Plus, it provides the highest level of liquidity efficiency without any additional bonder liquidity lockup requirement.

Cross-chain bridge pricing to incentive balanced liquidity

In a cross-chain bridging system, liquidity for the same canonical token exists on multiple chains. As the demand for the same canonical token shifts for different chains, the inherent pricing between the same token on different chains also dynamically changes. This is based on the underlying costs to use those native bridges to move across different chains and the supply-demand balance of liquidity on those different chains.

It is very important for any bridging solution to be able to capture this inherent pricing shift with a properly designed bonding curve. This creates important incentives for LPs to leverage the “economies of scale” and rebalance liquidity across multiple chains to maintain a network with sufficient and balanced liquidity to process all of the user requests.

Continuing with our design principle of having an “intelligent fabric,” we build a Curve-inspired bonding curve pricing mechanism inside the SGN. When a user transfers tokens from one chain to another, the SGN will calculate the received token based on the available liquidity on the source and destination chains. In addition to the slippage and pricing, a flat fee is deducted from the transaction as payment to LPs.

Specifically, for any pair of chains, i and j, let xiand xjbe the balance on-chain i and chain j for a given token, respectively. Then the following invariant should always hold true when we calculate the pricing and slippage of token transfers between chain i and chain j:

A is a per-chain-pair constant. For the same chain pair, A is the same for all tokens.D is a variable. The initial D can be obtained by solving a cubic equation against D given the initial liquidity on the two chains. After that, D should be iteratively updated based on liquidity status. wi and wj are the relative weights for the two chains, which is used to control the pricing asymmetry for the transfers. Note that the configuration of weights is per-chain-pair and should satisfy wi+wj=2.

The reason we have these weight parameters in the bonding curve is to capture the inherent asymmetry of certain chains. For example, transferring into optimistic rollups, such as Arbitrum and Optimism, is much simpler and lower cost than the 7-day delay of transferring out. Therefore, we can control the weight in the bonding curve to reflect this inherent difference created by each and every chain.

In the above red asymmetric curve with the blue symmetric reference line, we can see the curve creates more slippage for transfers from chain i to chain j when the imbalance happens. If wi=1, wj=1, it reduces to the Curve invariant.

It is also possible to treat an entire network of similar canonical liquidity as a single multi-variable bonding surface. More analysis is needed on the effects of these two different potential designs in terms of slippage effectiveness and cost of operation.

General cross-chain messaging

cBridge 2.0 creates an intelligent cross-chain fabric based on the SGN. This fabric can do more than just cross-chain asset transfers. Under the asset bridging functionality is actually a general cross-chain messaging framework where the SGN monitors certain events on the source chain and posts a PoS consensus secured notarization on the destination chain.

We will be gradually opening up this underlying functionality to developers as an SDK to build use cases for not only on-chain bridging, but for other use cases like cross-chain NFT, cross-chain DeFi aggregation, and more.

Network Value Accurral

Unlike many tokens where protocol token holders do not take on active duty of the protocol’s daily function, it is obvious that CELR token stakers and validators are indispensable in the smooth operation of cBridge via the SGN’s new extension, as explained in both of the above models.

As such, users and LPs in cBridge 2.0 are required to pay fees to the SGN in return for its services. This is very much like fee being paid for any PoS blockchain validators. These fees are distributed to the CELR stakers in the SGN nodes who generate the block. Specifically:

In the model where the SGN acts as a bridge gateway and as a SLA arbitrator, a part of the total transaction fee is actually fee paid to the SGN for its work of scheduling nodes and SLA arbitration.In the model where the SGN acts as a shared liquidity manager, a part of the total transaction fee is the fee due to SGN for its work in helping processing all of the cross-chain transfers.

There are also a number of system parameters and configurations that require governance-based updates and tuning to ensure the smooth and continuous operation of the system. CELR will also be acting as a governance token for this new component in Celer’s ecosystem.

Closing notes on multi-chain bridge design tradeoffs

Finally, we provide our perspective on the cross-chain bridging design tradeoff space. We believe that the biggest tradeoff in cross-chain bridging design is about the control of liquidity in the system.

Some may argue that a self-custodial-only bridging solution is the “purest” and “safest” bridging design. While we recognize the principle of this argument, we want to highlight that the reliable operation and operational security of cBridge set a fairly high bar for liquidity providers. We are, of course, confident about this model’s long-term potential and that is why we designed the self-custodial “SGN as a cBridge node gateway and Service Level Agreement (SLA) arbitrator” model.

In the meantime, we believe in our design philosophy of covering the entire tradeoff space and presenting all of the available options in an unbiased manner so both users and LPs can select their best options. This is why cBridge 2.0 also comes with the model of “The SGN as a Shared Liquidity Pool Manager” with the hope to bootstrap liquidity faster to achieve wider adoption.

After all, no matter if it is a white cat or a black cat; as long as it can catch mice, it’s a good cat.

Launch Plan

Blockchain interoperability is new as evidenced by the previous hacking incidents in this space. We, as Celer community, treat security with the highest standard and strives to keep our long records of safe launches and operations for the network.

cBridge 2.0 will be launching in phases. In Oct 2021, we plan to launch the “SGN as a Shared Liquidity Pool Manager” mode as the Phase One testnet with at least two security audits on the system and smart contract.

After the testnet and audits, we will launch a $1M bug bounty program along with a gradual rollout mainnet.

After that, we will proceed to “SGN as a cBridge node gateway and Service Level Agreement (SLA) arbitrator” mode as the Phase Two.

分享此文：TwitterFacebookLike this:Like Loading...

Celer Network Follow

About Celer

News

Technology

#Blockchain #Ethereum

« The layer2.finance v0.1 Mainnet Launches: Democratize DeFi, Simple and Zero Fees

cBridge 2.0 Community-driven Upgrade Incoming! »

illumineX Integrates Celer IM for Seamless Cross-Chain Swaps

Celer Network

Feb 23, 2024

1 min read

Celer cBridge Expands Support for BRC-20: Bridging between BTC…

Celer Network

Jan 2, 2024

2 min read

Celer Partners with AltLayer as Part of Their Interoperability…

Celer Network

Nov 23, 2023

2 min read

多链无缝衔接——最全跨桥操作指南汇总（附教程） - 知乎

多链无缝衔接——最全跨桥操作指南汇总（附教程） - 知乎首发于Web3.0研究院切换模式写文章登录/注册多链无缝衔接——最全跨桥操作指南汇总（附教程）Web3.0区块链数字货币 Web3.0Arbitrum 的跨链桥使用教程 1.准备MetaMask钱包https://metamask.io/download.html 安装MetaMask注：有私钥的可以选择导入私钥创建钱包，没有私钥的可以选择创建钱包，记得备份好助记词与私钥，如果忘了也可以进入钱包后导出私钥。2.配置Arbitrum One主网参数（1）可以访问http://bridge.arbitrum.io/，点击页面中间的"添加/切换到Arbitrum网络"，将自动添加网络。（2）手动添加方式：选择自定义RPC，进入参数配置页面，按步骤依次填写，如下所示：网络名称：Arbitrum One（也可自定义）新增RPC URL：https://arb1.arbitrum.io/rpc链ID：42161代码：ETH区块浏览URL：https://explorer.arbitrum.io参数配置好后，点击下方保存，即成功创建Arbitrum One钱包，如果想要继续增加钱包，可以通过导入以太坊钱包私钥来创建，也可以直接点击创建账户，创建完成后记得保存私钥即可3.Arbitrum跨链桥使用教程Arbitrum跨链桥使用起来很简单，不过只能从以太网络L1转到L2的Arbitrum网络，只能转ERC20的资产。跨链之前也需要准备一些GAS费的代币，比如要从以太网络L1跨链资产去Arbitrum主网，首先需要保证以太网络的钱包中有ETH，其次资产跨到Arbitrum主网后，也需要保证Arbitrum主网钱包中有ETH才能正常使用，所以如果需要跨过去的资产不是很多，直接多跨一些ETH过去即可，然后用ETH去换购其他资产。Arbitrum网址：https://bridge.arbitrum.io/3-1 链接钱包在开始之前，请准备一个MetaMask钱包，输入网址，点击【Connect Wallet】链接钱包，连接MetaMask钱包，再确认连接即可。3-2使用跨链桥钱包链接好以后，就可以使用了，可以看到左侧是L1的资产，右边是L2资产。比如：我们从以太网络跨链2.4个ETH到L2 Arbitrum网络。可以看到钱包资产有2.411个ETH，因为跨链也需要消耗ETH的GAS费，所以预留一些GAS费。在数量处输入2.4，点击【desposit】会出来一个提示的弹窗，点击【PROCEED】继续进行，在MetaMask钱包弹出窗口中点击【Confirm】确认。3-3查到账资产确认之后等几分钟就可以了，下方是跨链记录，等右边L2资产出显示出资产就是到账了，然后去MetaMask钱包切换Arbitrum网络查看资产即可。3-4跨链其他ERC20资产如果需要跨链其他资产去Arbitrum网络的话，点击ERC-20，点击ADD Token，输入ERC20 Token的合约地址，比如USDT的，然后键盘按下【回车键】确认添加成功后可以看到USDT资产，然后授权Approve，输入数量，点击【desposit】等即可，和跨链ETH操作一样。3-5L2跨到L1如果需要将L2 Arbitrum网络的资产跨链到L1以太坊网络，在MetaMask钱包选择Arbitrum网络。打开Arbitrum跨链桥地址，可以看到L2账户的资产数量，输入数量，点击【withdraw】按提示操作即可。但是Arbitrum资产转到L1以太网络，需要等到45818个区块，也就是好几天，着急到账的可以考虑其他跨链桥产品。智能合约风险任何智能合约中都有可能存在漏洞，导致用户资金的损失。价格风险一旦以太币或代币从L1→L2或L2→L1被桥接，资金价值可能会因为市场波动而发生变化。Celer Network(cBRIDGE)的跨链桥使用教程使用cBridge完成跨链的具体操作如下：（以从Arbitrum跨链至BSC为例）进入网站：https://cbridge.celer.network/#/transfer点击“Connect Wallet”并在钱包中确认连接。连接成功后，右上角即会显示目前的主网和钱包地址。如图，本文以从Arbitrum向BSC转移USDC为例。如果希望更换公链或币种，在红框处选择即可。在红框处输入希望转出的金额，如果有一个活跃的中继节点有足够的流动性可以满足这笔交易，即可看到在目的地链上收到的金额和这次转账的手续费点击“transfer”、点击“APPROVE”，然后在钱包中确认以允许合约调用钱包中的USDC Token。批准成功后，点击“Submit Transfer”并在钱包中确认进行跨链。当交易被中继节点确认后，点击弹出窗口中的“Release Fund”即可提取这笔资金。资金提取成功后，弹出窗口即会显示如下内容，切换至BSC主网即可查看资金是否到账。HopProtocol跨链桥交互指南官方项目地址：https://hop.exchangeHop是一款针对Mainnet/polygon/Arbitrum/Optimism/Xdai的跨链工具。截止9月30日，通过Hop跨链的资产超过1亿美金。Hop的跨链是分别在不同链上生成h资产，并组成流动性池，满足用户的跨链需求，一定程度下会出现某条链上的某个资产被提空，导致无法跨链的情况。交互准备Hop目前支持的4种跨链资产分别是USDC/USDT/DAI/MATIC，这里我用的是三种稳定币进行跨链。钱包里必须有相应的ETH支付gas。1.稳定币跨链交互链接好钱包以后，在【send】页面选择需要跨链的币种以及需要把资产转移到哪条链即可，首次操作需要进行一次授权。由于目标是刷空投交互，建议选择polygon/optimism/arbitrum三条链互转，gas成本比较低。跨链会收取手续费，L2的gas费很低。提交的跨链交易可以通过点击右上角查看具体进度，全程只需一次确认即可完成跨链，整个过程还是非常顺畅的（不包括首次的授权）2.LP交互除了跨链转账交互，Hop还可以通过提供LP的方式交互，LP交互需要两步完成，这个过程和日常玩defi的过程类似3.获得h资产h资产需要在convert页面获取，AMM或者hop Bridge都可以。区别在于hop bridge只支持直接从mainnet铸造，AMM可以直接在L2上进行swap，考虑到交互成本，建议使用AMM渠道。4.组LP通过上一步获得的h资产和对应的币组成LP，添加流动性，即算完成了LP添加。5.LP抵押（stake）最后一步，在pool页面完成LP添加，获得LP凭证，在stake’页面进行抵押，即完成LP交互以上就是Hop的两种交互方式，目前hop尚未发币，有潜在发币的可能，老铁们可以根据需要选择Biconomy Hyphen跨链桥交互指南Biconomy 在 7 月底从 Mechanism Capital、DACM 以及 Coinbase Ventures 等筹集到 900 万美元后，在本月又面向开发者上线跨链转账基础设施 Hyphen，还将在今年后半年推出原生代币 BICO，以实现社区治理并激励利益相关者。随着 StarkEx3.0 主网上线使 L2 用户轻松与 L1 交互、Arbitrum 计划本月底推出主网公测版、L2 扩容方案 Hermez Network 被 Polygon 收购将发展成为后者基于 ZK-Rollups 的以太坊 L2 扩展解决方案等一系列进展的落地，以太坊网络的 L2 扩容以及让 L2 与 L1 获得更好交互体验的愿景正在迅速「由虚转实」，而区块链开发工具提供商 Biconomy 推出的跨链转账基础设施 Hyphen 主网也已正式上线，目前支持以太坊主网和 Polygon 之间的跨链操作。目前主流的解决方案下，用户从 L2 撤回资金到 L1 以及像从 Optimistic Ethereum 提款到以太坊等操作往往需要数十分钟乃至几天的时间才能完成。而 Biconomy 新推出的 Hyphen 即意图解决这一痛点，优化用户将资金从 L2 撤至 L1 以及 EVM 链、各种 L2 间的跨链资金转移低效的现状。Hyphen 如何实现跨链转移？简单来说，Hyphen 为开发者提供了一套简单的 API，允许提供跨链转移操作，目前暂时仅支持 Polygon 和以太坊网络之间 USDC 和 USDT 代币的转移。实现方式就是，Hyphen 会在两条链上维持代币流动性，在一条链上接收到用户的代币后，再在另外一条链上转移代币，若单向输出过多，还会自动平衡流动性。由于需要维持流动性的缘故，也因此，用户在跨链转移时需要支付费用给流动性提供者。从 Hyphen 跨链实现方式可以看出，用户在将资金从一条链转移至目标链时需要支付的跨链转移费用包括流动性提供者费用（转移资金的 0.1%）以及用户支付给 Biconomy 用来从目标链上收到资金的交易费用（与目标链 Gas 费用相关）。经测试，若要通过 Biconomy 将 USDC 从从以太坊转至 Polygon 需要经过以下三个阶段，分别为在以太坊上同意 USDC 支付、存款给 Biconomy 部署在以太坊上的流动性智能合约以及在 Polygon 收到转账，共需要支付四部分费用，其中前两个阶段（属于跨链转账之前的准备工作）中用户需在以太坊上支付两次 Gas 费。之后在存款完成后进行跨链操作，需要支付流动性提供者费用和目标链上的交易费用，测试发现单纯跨链转账所需要的时间来看，大概在 10 秒之内可以完成。同理，从 Polygon 转至以太坊也需要在 Polygon 上同意支付 USDC 后在 Polygon 上存款要转移的资金，然后再从以太坊上接收。从智能合约层面上，Biconomy 已在所有支持的链上部署了 LiquidityPoolManger 合约，所有流动性都将存储在这些链上。另外，Biconomy 中的链下服务器，也就是执行器节点（Executor Node），会不断监控智能合约的任何存款交易。而执行器节点有两个主要组件，分别为 Watch Tower 和 Executors，Watch Tower 会监控 LiquidityPoolManager 智能合约，在发现存款交易后就会通知 Executor 组件。Executor 接收到信号后，会验证存款交易并在另外一条链上发起转账交易，完成跨链操作。Connext--NXTPL2层跨链指南Rollup Bridge：Connext NXTPNXTP（Noncustodial Xchain Transfer Protocol）由 Connext 研究开发而成，是一个简洁的跨链、跨 Rollup 的资产转移协议，其运作所需的资料都存在链上，秉持著去中心化的精神。技术性文档：https://nxtp-docs.connext.network/Connext进行L2层跨链转账1.我们首先打开官方推荐的站点https://www.xpollinate.io/ 进行L2跨链转账操作.打开站点后, 我们应该先连接自己的钱包, 我们推荐使用metamask钱包. 连接钱包前, 先确认,钱包的网络是不是已经切换成转出链的网络.2.这里,我选择了使用polygon网络,转账2个DAI到xDAI网络.3.点击swap后, 钱包有多次要求签名确认转账的操作, 都需要点击确定. (如果因为网络原因,没有点击的话,可以在钱包的活动标签下面,看看是不是有没有签名操作没有完成.)4.稍微等待几分钟(根据链上的速度决定,网络不拥堵的情况,一般就2~3分钟), 点击Sign to claim Transfer,完成转账.注意,如果之前你刷新页面,或者关闭了页面.都可以在 Active Transactions 下找到正在进行的转账, 可以点击Action下的操作,完成整个转账步骤.5.点击Sign to claim Transfer后, 转账就完成了, 等待几秒钟后, 余额就显示在目标链上了.6.这里还有一点高级用法. 在转账前点击Advanced Options点开.Wormholecrypto 跨链桥交互指南官网：https://wormholenetwork.com/wormhole V2已经支持sol、eth 、bsc 、Terra四链资产互转，值得期待。1.准备工作2.目标选择收件人链和地址。3.发送令牌将代币转移到虫洞代币桥。4.兑换代币完成Transfer Token的操作。注：对于不支持迁移的资产，可以在http://v1.wormholebridge.com上找到 v1 UI.allbridge跨链桥交互指南项目官网：https://allbridge.io/项目简介：allbridge是APYSwap生态下的跨链桥，支持EVM与非EVM链上资产互通。支持公链：ETH MATIC AVAX BSC HECO CELO SOL支持资产：根据公链不同，支持跨链的资产略有差异1.准备工作准备好相应的钱包，并选择需要进行跨桥的不同链的资产。主要的钱包有如下几个：2.数量选择确定相应的地址、金额等3.进行确认和等待接受4.完成操作。等1-4完成操作后，就完成了一个跨桥的基本操作。AnySwap V2跨链桥交互指南由于 Anyswap 跨链桥具有技术先进性、性能安全性和使用便利性，很多公链系统已经开展了与 Anyswap 的合作。目前已经开展深度合作的公链包括了 Ethereum、BSC、Fantom、Heco、Fusion、OkexChain、Arbitrum、xDAI 和 Polygon 等。Anyswap 跨链桥：https://anyswap.exchange/swap#/bridge1. 钱包网络设置需要为浏览器安装MetaMask，且为MetaMask设置BSC和OKExChain主网网络。具体设置参数如下所示。钱包下载和主网设置请大家自行查询前文。对于主网，用户也可以通过http://chainlist.org 自动添加网络。2.如何使资产跨链？（1）链接好钱包（2）选择跨链桥（3）选择发出的主网及代币（4）选择接受的主网及代币（5）以上完成了跨桥基本操作。值得注意的是：（1）跨链手续费 0.1 %, 最小跨链手续费 40 USDC, 最大跨链手续费 1,000 USDC；（2）最小跨链金额 45 USDC；（3）最大跨链金额 5,000,000 USDC；（4）预计跨链到账时间10-30分钟；（5）1,000,000 USDC以上大额跨链到账时间12小时。如果需要跨回去，则进行换个方向即可。跨链交换聚合器和限制有效流动性。公链的崛起，各种DeFi 项目在多个链上大量冒出，因此资产常需要在转移到不同的链上运用，大大提升了跨链的需求，以前往往会透过中心化交易所、跨链兑币项目的方式来进行转移，过程中可能因手续费、滑点造成损失，也有资产在转移过程中被交易所卡住，浪费时间等等的问题。XY Finance 替使用者节省了时间、金钱，提供一站式跨链转移，找到最优的兑币流程。官网地址：xy.finance（1）首先选择某主网的钱包，进行链接（2）进行交易或跨桥（1）选择某主网需要进行跨桥的代币；（2）选择需要进行跨链的代币；（3）输入相应的接受地址；（4）确定点击“swap”这里面的代币，可以先选择相应的主网，目前支撑的有以太、BSC、马蹄、以及Fantom四种。自此，完成了swap的相关操作。———————————————————————————————以上，喜欢请点赞、关注我币圈赛道提前布局、区块链各领域早期价值发现、小道消息、项目评级、实时热点讨论聚焦defi、元宇宙、gamefi、SocialFi及Web3.0赛道，顺带撸羊毛。最近行情大家也知道，请转战TGhttps://t.me/xunbaoxiaofendui发布于 2021-10-22 23:46区块链(Blockchain)空投羊毛赞同 144 条评论分享喜欢收藏申请转载文章被以下专栏收录Web3.0研究院DeFi项目空投致力于预防传销、曝光黑心资金盘、侦查行业内幕，打击不良操盘手，播报最新资讯、百余盘面币界跟踪、分享干货套路······ 区块链投资提前洞悉商机，决战未来，布局区块链，布局财富

cBridge SDK - Celer cBridge

Celer cBridgeSearch⌃KWelcome to cBridgeIntroductionArchitectural BenefitsState Guardian NetworkSGN and cBridgeFungible Token Bridging ModelscBridge SecurityTutorialCross-chain TransferLP GuideSGN V2 Staking GuideSGN V1 Unbonding GuideSmart Contract as LPAptos Bridging GuideApe Chain Bridging GuideFlow Bridging GuideDeveloperCircle Cross-chain USDC Transfer Protocol(CCTP)cBridge SDKcBridge Pool-Based Transfer (xLiquidity)cBridge Canonical Mapping Transfer (xAsset)cBridge Transfer Web WidgetcBridge Aptos Transfer (xAsset Only)Custom Transfer URL SchemescBridge APIs for SuiReferral Specific TransfercBridge Limit ParametersAPI ReferenceNFT BridgeIntroductionNFT Bridge FeeList Your TokensSimple Listing ProcessReferenceFAQAudit ReportsContract AddressesPowered By GitBookcBridge SDKcBridge SDK allows new and existing applications to integrate a rich subset of features that are available in the cBridge 2.0. Simple imported libraries and packages allow you to quickly implement the cBridge transfer functionality into new and existing applications. cBridge Testnet WebsiteYou can try our testnet website during the SDK integrationcBridge Testnet EndpointThe testnet endpoint is: https://cbridge-v2-test.celer.networkcBridge Mainnet EndpointWhen you have finished implementation and testing on testnet, you are welcome to use cBridge mainnet for production test. The endpoint is: https://cbridge-prod2.celer.app/SDK Working FlowThe following graph reveals a general cBridge SDK integration inside your application. In most cases, you need to support only two functions(red lines in the graph):1.Send request to cBridge gateway through cBridge SDK2.Send corresponding on-chain transaction to cBridge contractInstallationIt's highly recommended to communicate with cBridge gateway by using grpc-web.1.You don't need to put any effort for response value mapping. Since all messages are defined in protobuf, enum value could be used directly such as Completed instead of an integer value 1. It helps preventing bugs and errors due to random mapping issues2.Inside cBridge gateway, there are some post APIs needing serialized byteArray as input. It takes some steps to prepare format accepted request information. Just in case you prefer RESTful api request, we will provide some examples for you accordingly3.Since cBridge iterates frequently, the best way to keep everything updated is using grpc. You can always check the latest grpc generated files and keep in touch with the newest cBridge gatewayYou can always use REST apis when communicating with cBridge gateway. We will provide examples and details in each api reference.1. Install the grpc-web To begin development with cBridge SDK, each developer needs to install grpc-web for cBridge gateway communication yarnnpm// Install via yarnyarn add grpc-web// Install via npmnpm install grpc-web2. Download cBridge type-script client and contract Download auto-generated protobuf files(including xxx_pb.d.ts, xxx_pb.js) in cBridge typescript client repo. You can find all needed messages including client, request constructs and contracts there.3. Import cBridge SDK into your projects.Import the file and type-defined messages, then they can be used in your project. The following is code snippet for type-script client usage in JavaScript project.// import getTransferConfig request message import { GetTransferConfigsRequest GetTransferConfigsResponse} from "../ts-proto/sgn/gateway/v1/gateway_pb";// import grpc-web WebClientimport { WebClient } from "../ts-proto/sgn/gateway/v1/GatewayServiceClientPb";const request = new GetTransferConfigsRequest();const client = new WebClient(`https://cbridge-prod2.celer.app/`, null, null);const response = await client.getTransferConfigs(request, null);API ReferenceOnce you have integrated cBridge SDK into your project, dive into the specifics of each API by checking out our complete documentation.API ReferenceNeed help?If you're looking for help, try join the community DiscordDeveloper - PreviousCircle Cross-chain USDC Transfer Protocol(CCTP)Next - DevelopercBridge Pool-Based Transfer (xLiquidity)Last modified 6mo agoOn this pagecBridge Testnet WebsitecBridge Testnet EndpointcBridge Mainnet EndpointSDK Working FlowInstallation1. Install the grpc-web 2. Download cBridge type-script client and contract 3. Import cBridge SDK into your projects.API ReferenceNeed help?

Follow

比特派苹果下载官网|cbridge

比特派苹果下载官网|cbridge

Celer cBridge主网上线：无缝桥接跨链和跨层流动性 - 知乎

Celer Network

Rollup Bridge 介绍（三）：Celer cBridge - 知乎

跨链桥百家争鸣，安全易用还看 Celer cBridge - 知乎

Welcome to cBridge - Celer cBridge

一周年巡礼：安全和迅速是cBridge长期的追求_腾讯新闻

Celer cBridge: Fast and Low-cost Value Transfer Network for an Interconnected Layer2 and Layer1 Future – Celer Network

cBridge 2.0: Coherent Blockchain Interoperability Powered By The State Guardian Network – Celer Network

多链无缝衔接——最全跨桥操作指南汇总（附教程） - 知乎

cBridge SDK - Celer cBridge

最近的新闻

您可能喜欢的文章

比特派app官方版下载|cbi银行

imtoken安卓官方下载|cfl

区块链钱包样板——让数字资产管理更加简单

为什么Tp钱包无法连接到互联网？

数字货币短期如何

量子通信在数字货币发展中的应用和前景

TP冷钱包生成地址不一致解决方法及注意事项