Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Technical design of account calibration #554

Open
Keith-CY opened this issue Nov 20, 2023 · 0 comments
Open

Technical design of account calibration #554

Keith-CY opened this issue Nov 20, 2023 · 0 comments
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@Keith-CY
Copy link
Member

Keith-CY commented Nov 20, 2023

This issue comes from #464 where a workflow of how to calibrate accounts between frontend and backend was roughly proposed.

sequenceDiagram
    participant Frontend
	participant Backend
    loop
    Frontend ->> Frontend: H = Hash(Address set)
    Frontend ->> Backend: get_balance(H)
    Backend ->> Frontend: H is not found
    Frontend ->> Backend: subscribe_address_set(address set)
    Backend ->> Backend: H = Hash(Address set)
    Frontend ->> Backend: get_balance(H)
    Backend ->> Frontend: balance of address set H
    Frontend ->> Frontend: address set grows to address set'
    Frontend ->> Frontend: H' = Hash(Address set')
    end
Loading

The account calibration is required by the account model of UTXO/Cell model.

To exploit UTXO/Cell model, an account is typically a set of addresses, e.g., a HD-wallet, so each UTXO can be assigned to a debutante address and the identity of recipient is hard to predicate.

It should be a general fundamental of DApp built on CKB, so address calibration should be delivered within Kuai natively.

Here is how it will be supported in Kuai:


In the backend, an account should be located by a hash(address set) and mapped to a set of addresses. The mapping is ephemeral and will be discarded if it's not accessed for a long time. So redis is quite suitable for this case.

The following features are required:

  1. cache multiple entries, each one can be mapped by a hash key;
  2. each entry has a ttl and will be removed when timeout. The ttl should be refreshed on accessing;
  3. the size of entries is limited, and the one that remains the least ttl will be removed once a new entry is inserted;
maxmemory 1G
maxmemory-policy volatile-ttl # remove stale entries first
SET accounts {hash(address_set)} addresses {address_list]} EX 600 # insert an entry with 600s lifetime
GET accounts {hash(address_set}) # get an entry
EXPIRE accounts {hash(address_set)} # refresh ttl

It's quite simple, so I think a singleton could hold all logic.

@Keith-CY Keith-CY added the documentation Improvements or additions to documentation label Nov 20, 2023
@Keith-CY Keith-CY self-assigned this Nov 20, 2023
@Keith-CY Keith-CY changed the title Technical design of address sets management Technical design of account calibration Nov 20, 2023
@Keith-CY Keith-CY moved this to 🆕 New in CKB JS Backlog Nov 22, 2023
@Keith-CY Keith-CY moved this from 🆕 New to 📋 Backlog in CKB JS Backlog Nov 29, 2023
@Keith-CY Keith-CY moved this from 📋 Backlog to 🔖 Ready in CKB JS Backlog Nov 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
Status: 🔖 Ready
Development

No branches or pull requests

1 participant