_posts: add 跨链.md

_posts/2024-07-04-跨链.md

@@ -0,0 +1,71 @@
+---
+layout: post
+title: "跨链"
+date: 2024-07-04
+---
+
+#ckb #rgb #bitcoin #ethereum #blockchain 
+
+## 跨链
+
+跨链的一般定义：将资产从 chain A 转移到 chain B。
+
+跨链的一般问题：在同一条区块链上做状态转移时，共识机制保证了 state transition 的合法性。但共识机制只能覆盖当前链的 state transition，而无法覆盖到跨链的 state transition。也就是说，跨链行为并不天然地受到双边区块链的共识机制所约束。
+
+跨链的一般步骤：（1）锁定 chain A 上的资产；（2）发行 chain B 上的资产。
+
+接下来，我们分别从 chain A 和 chain B 的视角来梳理出 **需求**，进而提炼出 **问题**：
+- 从 chain A 的视角，锁定资产后，我们一定能凭借 “chain A locked assets” 的证据来在 chain B 上发行对应的资产
+- 从 chain B 的视角，发行资产前，我们一定要保证 chain A 上的锁定资产再也不能被花费，因为该资产已经跨链花费了
+
+我提炼出来的 **问题**：
+- chain A 如何 **锁定资产**，并在链下生成 **锁定证据**
+- chain B 如何 **验证锁定证据**，并在链上发行新资产（不想发散讨论发行新资产了）
+这跟校验模型很相似，链下执行（对应到 chain A 锁定资产），提交证明（对应到锁定证据），链上验证（对应到验证锁定证明）。
+
+### 跨链 1. 生成锁定证据
+
+- 如果 chain A 是 account-based chain，那么 **锁定资产** 可以通过将资产转移到共享合约，合约记录锁定资产的明细；链下通过 state root 和 storage proof 来生成 **锁定证据**；
+- 如果 chain A 是 UTXO-based chain，那么 **锁定资产** 可以通过给新的 UTXO 配置约定的 lock script；链下通过 transaction existing proof 生成 **锁定证据**。
+
+### 跨链 1.1 解析内部数据
+
+能够解析双方的合约内部数据，例如锁定资产的证明。这主要是体现在协议层，比如 RGB++ 的资产协议是 xUDT 格式。
+
+### 跨链 2. 验证锁定证据
+
+**验证锁定证据**，除了 **锁定证据** 外，它还需要知道 chain A 的 **全局状态根**，这样才能判断该证据是否发生在 chain A 的主链上。我觉得这才是跨链最困难的地方。构建出让 chain A 相信的全局状态根，本质上就是构建全局信任。目前，除了链内的共识机制、optimistic rollup challenge、ZK rollup，我还没看到其它方式能安全地构建出全局信任。因此，大部分跨链方案都或多或少引入**预言机 Oracle**。
+
+CSV 提出的局部共识是破局者 ------ 即使没有全局共识，仅仅借助局部共识也可以玩出花儿来。
+
+### 跨链 2.1 预言机 Oracle
+
+**预言机 Oracle** 也别有洞天，
+对于 PoW chain，链上预言机以极低的成本验证 PoW，再累加 PoW difficulty，很容易构建出安全性较高的预言机，该预言机提供的状态根的安全性跟累计的 PoW difficulty 正相关。
+对于 PoS chain，链上预言机得验证 validators 的签名，且由于 validators 可自由进入退出的特点，所以成本高。
+
+### 跨链 2.2 CSV 客户端校验 局部共识
+
+### RGB++
+
+我在群里的发言：
+
+BTC上的资产是 CSV （客户端验证）范式的资产，当你通过 RGB++将资产映射到CKB的时候，就类似于于你在 BTC 上将该资产『销毁』了（而不是『锁定』，我说的锁定是指保留实体但限制转移，销毁是指不保留实体），再重铸到CKB上。
+
+因为在 BTC 上已经销毁了，那么就不存在“通过Nervos链去控制BTC资产”这种说法了。
+
+当然，你也可以将资产再映射回BTC，那就相当于在CKB上销毁，再重铸到BTC上。
+
+私钥都是用户自己保管，没有安全风险。
+
+RGB++的牛逼之处就在于，它能保证『原链销毁』和『目标链重铸』的原子性，也不用托管用户的私钥或者其它东西
+
+
+原子性的保障是通过 UTXO之间的同构映射 做到的，涉及到 RGB++ 的细节和 CSV 范式哈，我尝试解释一下
+
+怎么保证 leap 过去后原链就没有了？
+leap 分两笔交易，一笔是在原链上发起「销毁交易」（或者叫「映射交易」），一笔是在新链上发起「重铸交易」。
+如果我们能保证这两笔交易的原子性，也就是二者是一对一绑定的，那么就保证了 leap 的原子性。
+
+RGB++ 将「销毁交易」的交易哈希插入到「重铸交易」，又将「重铸交易」的交易哈希插入到「销毁交易」，以此来绑定这两笔交易。
+有个细节，因为上述两项有循环引用，所以我们只能将「重铸交易」的 hash of partial transaction 插入到「销毁交易」，但这总体而言也是安全的。