大家好，又见面了，我是你们的朋友全栈君。
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 背后技术实现的介绍，如果有任何想法想要分享，或是想要了解更多，都可以在留言区一起讨论
