Open Tx 的代理实现

参考:Open Tx Protocol Brainstorm (1)~(5)

Open Tx 的完全实现需要两个核心的协议设计与实现:通用的 OTX lock script 协议和支持 OTX 交易广播的 P2P 网络协议。二者对于 Nervos 网络来说都是非常重要且需要广泛考虑思考的设计。因此它的实现必然是长期和渐进式的。本文提出了一种使用现有的 lock script,且不改变网络协议的前提下实现 Open Tx 功能的方案。

用默认 lock script 实现 OTX

Nervos CKB 默认的 lock scriptsecp256k1_sighash_all,它在执行的时候会强制对交易的所有输入输出进行摘要验证,因此无法满足 Open Tx 对交易的部分内容约束,对其他内容忽略的基本要求。标准的 OTX 交易应该只约束(摘要签名)自己关心的 input / ouput,然后把部分交易广播出去,等候其他 OTX 交易与它合并为完整交易。

但如果用户把 OTX 聚合的工作交给指定的代理,而不是一个无需许可的聚合者网络。那么 OTX 的设计问题就可以得到大幅简化。我们既不需要新的 lock script 也不需要一个升级的 P2P 网络。

其基本思想也很简单,用户向指定代理发起一个 OTX 请求,该代理聚合 OTX 交易后,将未签名的原始交易返回给用户签名,完成签名后一起上链。对于这笔交易的每一个 lock script 来说,他们都以 sighash_all 的规则覆盖了交易的完整内容,但从业务层面讲,用户又是以 OTX 的方式发起的交易。

举个栗子

手续费代付

假设用户持且仅有一个 SUDT Cell,capacity 为 142,资产为 1000 DAI。用户希望以 1 个 DAI 作为手续费,支付给另一个用户 100 个 DAI。代理方愿意收取这 1 个 DAI,为收款方创建一个 142 CKB 大小的 SUDT Cell,并支付给矿工 0.1 个 CKB 作为手续费。这个场景让用户可以仅持有稳定币,不必购买链上原生代币也可以使用区块链。

image
* 图中使用相同颜色标记了资产的流动,可以看出 Agency 代付了交易手续费和 cell 创建费用

业务流程举例

  • 用户在 dApp webpage 上提交业务
  • 后端生成/收集 agency cell,组装交易,一起将 raw tx 发送给前端
  • 用户确认后对整个交易进行签名
  • 后端收到用户签名后,使用 agency cell 的 lock script 对应的私钥对交易进行签名
  • 交易上链

适用范围

该方案主要适用于少量用户场景,尤其单用户与单聚合者(代理)进行业务时的场景。而多用户场景由于需要将聚合后的 raw tx 返回给多个用户签名,他们如果没有在一定时间内响应,那么该交易即会失败。但不论如何,这个方案在完整的 OTX 解决方案上线之前,可以在某些场景内得以实际的应用。通过这个方案的使用,也可以对 OTX 的需求进一步细化,有利于后续 OTX 完整协议的设计与开发。

3 Likes