乐趣区

关于区块链:从-DAS-开始了解-CKB-应用开发二善用-Keeper

在上一篇文章《一、如何保障 DAS 账户的唯一性》中的最初,咱们提到了依然存在的 Cell 竞争问题。具体问题如下:

假设链上曾经注册有 a.bit、b.bit、z.bit 三个账户,当初有两个用户别离想要注册 c.bit,d.bit,且注册工夫很凑近。依照规定,注册产生时,他们应用的注册服务会别离结构交易让用户签名,交易的内容为将要注册的账户插入到 b.bit 之后。

问题在于,两笔交易都会试图将 AccountCell(b.bit) 生产掉,而一个 Live Cell 只能被生产一次,那么就会导致必然其中一笔交易会失败。假设注册 c.bit 的交易胜利了,而注册 d.bit 的交易失败了。注册 d.bit 的用户不得不被他所应用的注册服务要求从新签名交易。这是因为注册 d.bit 时,本来须要将 AccountCell(b.bit) 生产掉,而当初须要改为生产 AccountCell(c.bit),交易构造内容产生了变动,必须从新签名。

这将导致十分蹩脚的用户体验。事实上,当注册的用户数量变多时,大部分用户不得不一次又一次的签名交易,直到他能注册胜利。

廓清问题

要解决问题,首要的是廓清问题

下面的问题之所以是个问题,基本之处在于什么呢?是在于援用了雷同的 Cell 导致的交易失败吗?如果是这样,咱们就会将思考聚焦在如何防止交易援用雷同的 Cell。进一步思考上来,咱们可能就要颠覆有序链表这个设计了。

那如果咱们把问题归结为, 交易失败并不是问题,用户须要一直签名交易才是问题 ,会怎么样呢?那咱们就会将思考聚焦在如何防止用户一直地签名。而这仿佛并不艰难。

Keeper

咱们引入 Keeper 这个机制来解决这个问题。

Keeper 是:1) 一个有任何人都能够无需许可运行的链下程序。2) Keeper 是 dApp 的一部分,不同的 Keeper 服务于不同的 dApp。3) 它会依据 CKB 链上的状态,收回交易,批改 CKB 的链上状态。

引入 Keeper 之后,多个用户同时注册 DAS 账户的技术过程就变成了:

1) 用户发动一笔交易,开释一个蕴含注册信息的指令 Cell,比方「我要注册 c.bit」,「我要注册 d.bit」。同时,这些 Cell 的 lock 是 always_success,任何人都能够生产它们。这笔交易并不会将用户要注册的账户插入到有序链表中。
2) Keeper 通过监听链上状态,会收回一笔交易。将这两个指令 Cell,作为 input,并在 output 中创立对应的 AccountCell(c.bit),AccountCell(d.bit),一起将他们插入到有序链表中适合的地位。

能够看到,通过这种将多个账户注册申请打包一起插入链表的形式,能够无效地防止用户屡次签名的问题。 那咱们对 Keeper 的了解,应仅仅是将注册申请打包解决来防止 Cell 竞争吗?其实不然。

因为 Keeper 是任何人都能够无需许可来运行(他理当被设计为如此)的链下程序,那么当多集体运行 Keeper 时,Keeper 之间又会呈现 Cell 竞争问题:每个 Keeper 都在做雷同的工作,将用户的指令 Cell 变成对应的 AccountCell 插入到链表中适合的地位,它们又要去竞争 Cell 了。

这仿佛让人丧气,Cell 竞争无处不在。但认真思考,这压根就不再是问题了。Keeper 是程序啊,它们收回的交易失败了,有必要的话,它们能够主动签名新的交易。交易失败不会让它们焦躁,也不会让它们有任何损失。而这,正好解决了咱们想要解决的问题: 如何防止用户一直的签名。

至此,咱们便彻底解决了上一篇文章遗留的,由 Cell 竞争所带来的问题。

对 Keeper 的进一步思考:

1) Keeper 更像是一个可执行函数汇合,用户的指令 Cell 就是对其中某个函数的调用信息。Keeper + 链上验证脚本,形成了残缺的以太坊思维框架下的 dApp:与 dApp 交互,就是发送一笔交易,调用 dApp 裸露进去的函数接口,传入对应的参数。
2) Keeper 模块是 CKB 上 dApp 不可或缺的模块 ——「链下计算」模块。
3) 运行 Keeper 毕竟须要服务器老本,那么谁又会来运行 Keeper 呢?如果没有人运行 Keeper 了,那 dApp 不就无奈工作了吗?

  • 作为 dApp 开发者有充沛的理由和能源去保障 dApp 的失常工作,所以他们会去运行,但也不是相对的。甚至如果只有 dApp 开发者运行,那开发者的链下服务稳定性,会间接影响 dApp 的可用性。
  • 所以,咱们更倡议从经济激励的角度去思考如何激励大家来运行 Keeper。这也正是 DAS 的做法:任何将用户的指令 Cell 转变为 AccountCell,从而帮用户实现注册的 Keeper, 都能够分享到肯定比例的注册费用 。事实上,在 DAS 中,大量的逻辑解决都是以这样的形式去激励 Keeper 实现的。

4) 再联合 Keeper 是可执行函数汇合这个了解,大量的(也可能为 0)Keeper 处分 + CKB 网络矿工费,两者合并到一起,就是用户与合约交互所须要付出的总体老本。更进一步,Keeper 处分能够了解为「链下计算」相干的费用,CKB 网络矿工费可了解为「链上验证」相干的费用。 对于以太坊而言,验证和计算都是在链上进行,但咱们仍能够从逻辑上将其费用拆分成计算和验证两局部。所以从细节上看,CKB 和 ETH 差异很大,但在某个形象层级来看,他们又具备一致性。

DAS 创始人 TimYang(杨敏)在 Nervos CKB 上开发了 DAS 去中心化账户服务 。借着这次的产品开发,TimYang 通过《从 DAS 开始理解 CKB 利用开发》系列文章,向大家论述他的设计思路和开发历程,让大家理解如何在世界上第一个基于 UTXO 架构的公链 CKB 上构建产品级利用。

举荐浏览: 从 DAS 开始理解 CKB 利用开发(一)—— 如何保障 DAS 账户的唯一性

如若您有更多对于 DAS 产品的应用心得,以及在 CKB 上开发的见解,欢送返回 Nervos Talk 论坛探讨:

  • https://talk.nervos.org/

退出移动版