在上一篇文章《一、如何保障 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/