yangby-cryptape/README.md Secret

## README.md

      
    Raw
  

              README.md
            
          
    BTC Simplified Payment Verification (SPV) on CKB

Requirements

BTC SPV on CKB 需要的需求有：

更新必须进行合法性验证。
所有权和使用权分离。
尽量避免读写竞争问题。
可以用来验证 BTC TX 。
支持一定高度的 Revert (or Reorg）。

Refs:

原始需求文档： BTC 轻节点需求 on Notion

SPV Client contracts 需要 4 个 Operations:

Initialiaze
Append
Revert (or Reorg)
Destory (only owner)

SPV Client 还需要提供 library，包含 1 个 function:

Prove if a TXID in SPV Client.

Detailed Design

SPV Cell

⚠️ 我看目前设计选了 MMR ，我先这么写了，看后续有无别的想法，因为我还没看完别的 SPV clients 实现。
一个 SPV Cell 的 Data 包含：
- index （用来做 Multi SPV Cells ）
- min height
- max height
- hash of the max height header
- MMR root digest
- total diff from 0 to max height

A SPV Client Contains Multi SPV Cells

使用 Multi SPV Cells 的设计，是为了解决上面需求中的 "3. 避免读写竞争" 和 "5. 支持 Revert" 。
将一个 BTC SPV Client 设计成 $N+1$ 个 Cells ，其中：


$N$ 个 SPV Cells


所有 SPV Cells 的 min height 都是相同的，这里记做 $H_{min}$ 。


所有 SPV Cells 的 max height 都是不同的，分别是：

$H_{min} + a_{0}$
$H_{min} + a_{0} + a_{1}$
$\cdots$
$H_{min} + a_{0} + a_{1} + \cdots + a_{n-2}$
$H_{min} + a_{0} + a_{1} + \cdots + a_{n-2} + a_{n-1}$

其中 $a_{i} \gt 0$ ，代表每次更新 SPV 对应的 BTC height interval 。

如果每个 BTC block 都立刻更新，就是 $a_{i} = 1$ 。
如果同步服务出现了异常中断，再恢复时可以设置 $a_{i} \gt 1$ 来提速同步。

或者 reorg 的时候，不可能再去一个一个补，肯定也是一次多个 heights 快速同步，即 $a_{i} \gt 1$ 。


$1$ 个 Index Cell
由于有 Multi SPV Cells ，循环更新，所以需要：

每个 SPV Cells 里记录自己的 Index Number ，
有一个 Index Cell 来保存当前最新的一个 SPV Cell 的 Index Number 。


Update 操作

假设 Index Cell 里记录 Latest SPV Cell 的 index 为 $t$ 时，更新 SPV Client 更新：

CellDep 包含：

index 为 $t$ 的 SPV Cell


Inputs 包含：

index 为 $t+1$ （如果 $t+1 = N$ 则取 index 为 $0$） 的 SPV Cell
Index Cell


Outputs 包含：

index 为 $t+1$ （如果 $t+1 = N$ 则取 index 为 $0$） 的 SPV Cell
更新 Cell Data
Index Cell
将 index 修改为 $t+1$（如果 $t+1 = N$ 则为 $0$）


Witnesses 包含：

从 index 为 $t$ 的 SPV Cell 的 max height 开始的新的 headers 。


验证逻辑：

检查 Index Cell 里 index 为 $t$

检查 Witnesses 包含的 tip headers 是连续的，且验证 POW
检查 Witnesses 包含的 tip headers 可以和 index 为 $t$ 的 SPV Cell 连上
检查 将要更新的 SPV Cell 的 index 为 $t+1$


总结下，每次更新的时候需要检查 Input，CellDep 和 Output 的 index ：

$i_{\mathrm{Output}} = i_{\mathrm{Input}}$
$i_{\mathrm{Output}} \equiv i_{\mathrm{CellDep}} + 1 \pmod{N}$
$i \in {0, 1, \dots, N-1}$


Users 使用

用户如果要验证一笔高度在 $h$ 的 TX ，那么选择任何包含这个高度的 SPV Cell 都可以。
但建议选择 Index Cell 里记录的 Latest SPV Cell ，因为这个 Cell 的下一次更新时刻，距离当前时间最长。
这样可以 "3. 避免读写竞争" 。

Reorg 操作

用 $C_{i}$ 来表示 max height 为 $H_{min} + a_{0} + a_{1} + \cdots + a_{i-1} + a_{i}$ 的 SPV Cell 。
假设目前要从 $C_{r}$ 处进行 reorg （即 $C_{r}$ 是合法的，之后的全要 revert ），那么：

CellDep 包含：


$C_{r}$ 的 SPV Cell


Inputs 包含：


$C_{r+1}$ 的 SPV Cell

$C_{r+2}$ 的 SPV Cell
$\cdots$

$C_{N-1}$ 的 SPV Cell
指向 $C_{N-1}$ 的 Index Cell


Outputs 包含：


$C_{r+1}$ 的 SPV Cell
更新 Cell Data 为最新 tip 对应的数据

$C_{r+2}$ 到 $C_{N-1}$ 的 SPV Cells
清空数据，等待后面 turns 再写入新数据
Index Cell
修改为 指向 $C_{r+1}$


Witnesses 包含：

从 $C_{r}$ 开始的，到要 reorg 到的最新 tip 之间的所有的 headers 。


验证逻辑：

检查 Index Cell 指向的是 $C_{N-1}$

检查 Witnesses 包含的 tip headers 是连续的，且验证 POW
检查 Witnesses 包含的 tip headers 可以和 $C_{r}$ 连上
检查 Witnesses 包含的 tip headers 比当前 $C_{N-1}$ 拥有 better total diff 。


Revert 操作

如果 Reorg 操作受到 CKB Block Size Limit 或 Cycles Limit 影响无法做到，那么只能先强行进行 Revert 操作，然后重新同步。
考虑到单纯的 revert 意味没有验证 better total diff ，所以这个操作应该是需要 Owenrship 的。
我理解这个操作不可以有，因为违背了需求 "2. 所有权和使用权分离。" 。
所以对于 reorg 不了的，无论是

计算或数据 超出 CKB 的 limit ，无法验证；
还是预先 Multi SPV Cells 个数设置太少了， reorg 不到。

我的建议是用户应该另部署一套 SPV Client 。

Usecase: How to verify a TX or TXID in BTC chain?

用户如果需要在一个 script 里校验 TX 或 TXID 在 BTC chain 上（仅限于 SPV Cell 的 min height 和 max height 之间的 TX），则：

CellDeps 包含：

包含 有该 TX 的 Block 的 SPV Cell


Witnesses 包含：

TX data （如果不需要验证 data ，可以直接用 TXID ）
TX 的 Merkle Proof
TX 所在 Header
TX 所在 Header 的 MMR Proof


验证逻辑：

[Optional] 用 TX data 计算出 TXID 。
用 TX 的 Merkle Proof，TXID 和 Header 里的 merkle root 进行校验：TX 在 Header 里。
用 TX 所在 Header 的 MMR Proof， TX 的 Header 和 SPV Cell 里的 MMR root digest 进行校验：header 在 SPV Cell 里。

References:

Bitcoin Block Headers


## TestnetDeployment.md

      
    Raw
  

              TestnetDeployment.md
            
          
    SPV Testnet Deployment Information

Contracts


SPV Contract

Sources Code: Commit ac8c573
Data Hash: 0xfa4930708687e1b4299206aa782c909e367f3f4044f4fc4f02a1bcd85aefd372
Type Hash: 0xc8a30fe3e8101cb4163e70b4eb1e42d477ae7094524a30bfdf1c90be41876d28
Deployment Transaction: 0x151c5bc95b03cdc690b05a6513abc15e7aa27aa78cf4d3ec0033953bdae36504


Always Success Contract

Sources Code: Tag v0.114.0
Data Hash: 0x28e83a1277d48add8e72fadaa9248559e1b632bab2bd60b27955ebc4c03800a5
Type Hash: 0x30e67780f97211364c4f8107b14d4944f920c25e1c6f7a5a524c2538465fc4b7
Deployment Transaction: 0x9660b35c0a97fc47debb73f68a4868d8108e226a669219b62cc34a8c213c9d57


SPV Instances


Bitcoin Testnet SPV Instance

Deployment Transaction: 0x6e91b3983c94f39816985d06599de63a9733473443951c689ed9e54a9dab9aee


Bitcoin Mainnet SPV Instance

Deployment Transaction: 0x046edf9dcacdd03e06970516cbdb41d7d7a19baa58307a6a0e3626e53ddaa81d