Learn about CKB application development from DAS (2): Make good use of Keeper

At the end of the previous article " 1. How to ensure the uniqueness of the DAS account ", we mentioned the cell competition that still exists. The specific questions are as follows:

Assuming that there are three accounts a.bit, b.bit, and z.bit registered on the chain, now two users want to register c.bit and d.bit respectively, and the registration time is very close. According to the rules, when registration occurs, the registration service they use will separately construct a transaction for the user to sign. The content of the transaction is to insert the account to be registered into b.bit.

The problem is that both transactions will try to consume AccountCell (b.bit), and a Live Cell can only be consumed once, which will inevitably cause one of the transactions to fail. Assume that the transaction to register c.bit is successful, and the transaction to register d.bit fails. The user who registered for d.bit had to be required to re-sign the transaction by the registration service he used. This is because when registering d.bit, AccountCell (b.bit) was originally required to be consumed, but now it needs to be changed to consume AccountCell (c.bit). The content of the transaction structure has changed and must be re-signed.

This will result in a very bad user experience. In fact, when the number of registered users increases, most users have to sign transactions again and again until they can register successfully.

Clarify the problem

To solve the problem, the first thing is to clarify the problem

What is the root cause of the above problem? Is the transaction failure caused by referencing the same Cell? If so, we will focus our thinking on how to avoid transactions referencing the same Cell. Thinking about it further, we may have to overturn the design of an ordered linked list.

So if we attribute the problem to transaction failure is not a problem, users need to continue to sign transactions is the problem , what will happen? Then we will focus our thinking on how to prevent users from signing continuously. And this doesn't seem difficult.

Keeper

We introduce the Keeper mechanism to solve this problem.

Keeper 是：

1) 一个有任何人都可以无需许可运行的链下程序。
2) Keeper 是 dApp 的一部分，不同的 Keeper 服务于不同的 dApp。
3) 它会根据 CKB 链上的状态，发出交易，修改 CKB 的链上状态。

After the introduction of Keeper, the technical process for multiple users to register for DAS accounts at the same time has become:

1) The user initiates a transaction and releases an instruction cell containing registration information, such as "I want to register c.bit" and "I want to register d.bit". At the same time, the lock of these Cells is always_success, and anyone can consume them. This transaction does not insert the user's account to be registered into the ordered linked list.
2) Keeper will send out a transaction by monitoring the state on the chain. Use these two instruction Cells as input, and create the corresponding AccountCell (c.bit) and AccountCell (d.bit) in the output, and insert them into the appropriate position in the ordered linked list together.

It can be seen that by this way of packaging multiple account registration requests and inserting them into the linked list, the problem of multiple signatures by users can be effectively avoided. So our understanding of Keeper, should we just package the registration request to avoid cell competition? actually not.

Since Keeper is an off-chain program that anyone can run without permission (it should be designed to be so), when multiple people run Keeper, there will be cell competition between Keeper: each Keeper is doing the same Work, turn the user's instruction Cell into the corresponding AccountCell and insert it into the appropriate position in the linked list. They are going to compete with the Cell again.

This seems frustrating, Cell competition is everywhere. But thinking carefully, this is no longer a problem at all. Keepers are programs. The transactions they send have failed. If necessary, they can automatically sign new transactions. Failure of the transaction will not make them irritable, nor will it make them lose any money. And this just solves the problem we want to solve: how to avoid users' constant signatures.

At this point, we have completely solved the problems left over from the previous article and caused by Cell competition.

Further thoughts on Keeper:

1) Keeper is more like a collection of executable functions, the user's instruction Cell is the call information of one of the functions. The Keeper + verification script on the chain constitutes a complete dApp under the Ethereum thinking framework: interacting with the dApp is to send a transaction, call the function interface exposed by the dApp, and pass in the corresponding parameters.
2) The Keeper module is an indispensable module for dApps on CKB-the "off-chain computing" module.
3) After all, running Keeper requires server costs, so who will run Keeper? If no one is running Keeper, won't the dApp not work?

• As dApp developers, there are sufficient reasons and motivation to ensure the normal operation of dApps, so they will run, but it is not absolute. Even if only dApp developers run, the stability of the developers' off-chain services will directly affect the availability of dApps.
• Therefore, we recommend thinking about how to encourage everyone to run Keeper from the perspective of economic incentives. This is exactly what DAS does: Any Keeper that converts the user's command Cell into an AccountCell to help the user complete the registration, can share a certain percentage of the registration fee . In fact, in DAS, a lot of logic processing is in this way to motivate Keeper to complete.

4) Combined with the understanding that Keeper is a collection of executable functions, a small amount (may be 0) Keeper reward + CKB network miner fee, combined together, is the total cost of interaction between the user and the contract. Furthermore, Keeper rewards can be understood as costs related to "off-chain computing", and CKB network miner fees can be understood as costs related to "on-chain verification". For Ethereum, verification and calculation are performed on the chain, but we can still logically split its cost into two parts: calculation and verification. So in terms of details, CKB and ETH are very different, but at a certain level of abstraction, they are consistent.

DAS founder Tim Yang (Yang Min) developed DAS decentralized account service on Nervos CKB. Through this product development, Tim Yang explained his design ideas and development process through the series of articles "Understanding CKB Application Development from DAS" to let everyone know how to become the world's first public chain CKB based on UTXO architecture. Build product-level applications on the Internet.

Recommended reading: Learn about CKB application development from DAS (1)

If you have more experience of using DAS products and insights on CKB development, please go to the Nervos Talk forum to discuss:

• https://talk.nervos.org/