It is assumed that there are three accounts a.bit, b.bit and z.bit registered on the chain, and now there are two users who 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 services they use will respectively construct transactions for users to sign. The content of the transaction is to insert the account to be registered after 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 lead to the failure of one of the transactions. Suppose that the transaction of registering c.bit succeeds and the transaction of registering d.bit fails. The user who registers d.bit has to re sign the transaction by the registration service he uses. This is because when registering d.bit, the accountcell (b.bit) needs to be consumed, but now the accountcell (c.bit) needs to be consumed. The transaction structure and content have changed and must be re signed.
This will lead to 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.
clear up problems
To solve the problem, the first thing is to clarify the problem
What is the fundamental reason why the above problem is a problem? Is the transaction failure caused by referencing the same cell? If so, we will focus our thinking on how to avoid transactions referring to the same cell. Further thinking, we may have to overthrow the design of ordered linked list.
So if we boil the problem down to,Transaction failure is not a problem. Users need to constantly sign transactions, what happens? Then we will focus on how to avoid users signing constantly. And it doesn’t seem difficult.
We introduce the mechanism of keeper to solve this problem.
Keeper is: 1) An off chain program that anyone can run without permission. 2) Keeper is a part of DAP. Different keepers serve different daps. 3) It will issue transactions and modify the status of the CKB chain according to the status of the CKB chain.
After the introduction of keeper, the technical process of multiple users registering Das accounts at the same time becomes:
1) The user initiates a transaction and releases a command 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, 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 a transaction by monitoring the status of the chain. Take the two instructions cell as input, create the corresponding accountcell (c.bit) and accountcell (d.bit) in output, and insert them into the appropriate position in the ordered linked list together.
It can be seen that by packaging multiple account registration requests and inserting them into the linked list, the problem of multiple signatures of users can be effectively avoided.Should our understanding of keeper only package the registration request to avoid cell competition? It’s not.
Since the keeper is an off chain program that anyone can run without permission (it should be designed as such), when multiple people run the keeper, there will be cell competition between the Keepers: each keeper is doing the same work, changing the user’s instruction cell into the corresponding accountcell and inserting it into the appropriate position in the linked list, They’re competing for cell again.
This seems frustrating. Cell competition is everywhere. But on reflection, this is no longer a problem at all. Keeper is a program. The transaction they send fails. If necessary, they can automatically sign a new transaction. The failure of the transaction will not upset them or make them lose anything. And this just solves the problem we want to solve:How to avoid users’ continuous signature.
So far, we have completely solved the problems caused by cell competition left over from the previous article.
Further thoughts on keeper:
1) Keeper is more like a collection of executable functions. The user’s instruction cell is the call information of a function. Keeper + verification script on the chain constitutes the DAP under the complete Ethereum thinking framework: to interact with DAP is to send a transaction, call the function interface exposed by DAP and pass in the corresponding parameters.
2) The keeper module is an indispensable module of DAPP on CKB – “off chain computing” module.
3) After all, running keeper requires server cost, so who will run keeper? If no one runs keeper, doesn’t DAPP work?
- As DAPP developers, they have sufficient reasons and motivation to ensure the normal operation of DAPP, so they will run it, but it is not absolute. Even if only DAPP developers run, the stability of the developer’s offline services will directly affect the availability of DAPP.
- Therefore, we should encourage everyone to think more about how to run keeper from an economic point of view. This is exactly what Das does: any keeper that converts the user’s instruction cell into accountcell to help the user complete registration,Can share a certain proportion of the registration fee。 In fact, in DAS, a lot of logic processing is done in this way to motivate keeper.
4) Combined with the understanding that keeper is a set of executable functions, a small amount (or 0) keeper reward + CKB network miner fee are combined, which is the overall cost of user contract interaction. further more,Keeper reward can be understood as the cost related to “offline computing”, and CKB network miner fee can be understood as the cost related to “online verification”.For Ethereum, both verification and calculation are carried out on the chain, but we can still logically split the cost into two parts: Calculation and verification. Therefore, in terms of details, CKB and eth are very different, but at a certain level of abstraction, they are consistent.
Tim Yang (Yang Min), founder of DAS, developed on nervos CKBDas decentralized account service。 Through this product development, Tim Yang explained his design ideas and development process to you through a series of articles on understanding CKB application development from DAS, so that you can understand how to build product level applications on the world’s first public chain CKB based on utxo architecture.
Recommended reading:Learn about CKB application development from DAS (I) — how to ensure the uniqueness of Das account
If you have more experience on using Das products and developing on CKB, please go to nervos talk forum to discuss: