Magickbase / ckb-explorer-public-issues

CKB Explorer Issues
https://explorer.nervos.org/
3 stars 2 forks source link

Display asset allocation #697

Open Keith-CY opened 3 weeks ago

Keith-CY commented 3 weeks ago

Any assets on CKB can be allocated on CKB or BTC due to the RGB++ protocol, so there's a confusion about the distribution.

E.g. the seal token https://explorer.nervos.org/xudt/0x178fb47b597a56d48b549226aff59f750b4784250c7f40f781b64ef090a8a0a7

It shows 40906 holders on CKB

image

It consists of CKB holders and CKB Cells of BTC holders. It's correct from the perspective of CKB. But it's confusing for users since the real holders should be CKB holders and BTC holders

Here I would suggest showing the following data

  1. Holder Addresses: CKB holders + BTC holders:
  2. Holder Allocation(tooltip or something): protocol count
    secp256k1 cell count of secp256k1 lock
    omnilock ... of omnilock
    joyid ... of joyid lock
    rgb++ ... of rgb++ lock
    lock hash ... of unknown lock hash
Sven-TBD commented 3 weeks ago

@Kirl70 Could you add a pop up for the address acount

image

PRD : https://vs0cjf.axshare.com/?id=8k4520&g=14&p=_697_update_a_new_way_for_showing_holders

cc @rabbitz

Kirl70 commented 3 weeks ago

Design Draft: https://www.figma.com/design/6XNoimRDbFTTNm016rbIdU/Magickbase?node-id=39141-49780&t=P4fGDu7Ra10gUDUX-1

image
Daryl-L commented 3 weeks ago

Chinese translation

Sven-TBD commented 3 weeks ago
en zh
Holder Allocation 地址分布
There are {{CKBHolderAmount}} CKB Holders and {{BTCHolderAmount}} BTC holders of current asset. 当前地址有{{CKBHolderAmount}} CKB地址持有人及{{BTCHolderAmount}} BTC 地址持有人
secp256k1 secp256k1
omnilock omnilock
joyid joyid
rgb++ rgb++
lock hash lock hash
Daryl-L commented 3 weeks ago

Need a API data returned as follow

{
  ckbHolderAmount: 1000,
  btcHolderAmount: 1000,
  lockHashes: [
    {
      lock: "secp256k1",
      holderAmount: 100
    }
  ]
}
Keith-CY commented 3 weeks ago

Need a API data returned as follow

{
  ckbHolderAmount: 1000,
  btcHolderAmount: 1000,
  lockHashes: [
    {
      lock: "secp256k1",
      holderAmount: 100
    }
  ]
}

I would suggest an API as

{
  "holders": {
    "btc": "number",
    "ckb": {
      "secp256k1": "number",
      "omnilock": "number",
      "others": "number"
    }
}

The total count of ckb holders can be calculated in the frontend

Daryl-L commented 3 weeks ago

Need a API data returned as follow

{
  ckbHolderAmount: 1000,
  btcHolderAmount: 1000,
  lockHashes: [
    {
      lock: "secp256k1",
      holderAmount: 100
    }
  ]
}

I would suggest an API as

{
  "holders": {
    "btc": "number",
    "ckb": {
      "secp256k1": "number",
      "omnilock": "number",
      "others": "number"
    }
}

The total count of ckb holders can be calculated in the frontend

The lock hashs should be returned an array, for convenience to add new lock And I think it is both ok whether to return the ckb holder amount or to calculate from the lock hashes, and I would prefer the data returned from the backend

{
  ckbHolderAmount: 1000, // optional
  btcHolderAmount: 1000,
  lockHashes: [
    {
      lock: "secp256k1",
      holderAmount: 100
    }
  ]
}
Daryl-L commented 2 weeks ago

https://github.com/Magickbase/ckb-explorer-frontend/pull/382

rabbitz commented 2 weeks ago
  1. Create table udt_statistics:
Columns:
Index:
  1. Categorize and aggregate UDT holders' addresses in udt_accounts by lock script code_hash.

  2. Refresh udt_statistics data when udt_accounts data changes.

rabbitz commented 2 weeks ago

udt info add holder_allocation pr: https://github.com/nervosnetwork/ckb-explorer/pull/1978

[staging] e.g.

https://ckb-explorer-staging.magickbase.vercel.app/xudt/0x78e21efcf107e7886eadeadecd1a01cfb88f1e5617f4438685db55b3a540d202

{
    "data": {
        "id": "3355130",
        "type": "udt",
        "attributes": {
            "symbol": "UBBQT",
            "full_name": "Unique BBQ TEST",
            "icon_file": null,
            "published": true,
            "description": null,
            "type_hash": "0x78e21efcf107e7886eadeadecd1a01cfb88f1e5617f4438685db55b3a540d202",
            "type_script": {
                "args": "0x30d3fbec9ceba691770d57c6d06bdb98cf0f82bef0ca6e87687a118d6ce1e7b7",
                "code_hash": "0x25c29dc317811a6f6f3985a7a9ebc4838bd388d19d0feeecf0bcd60f6c0975bb",
                "hash_type": "type"
            },
            "issuer_address": "ckt1qzda0cr08m85hc8jlnfp3zer7xulejywt49kt2rr0vthywaa50xwsqga7eurwgfm534kew3092y28sp3mwlqpqcptqy24",
            "udt_type": "xudt",
            "operator_website": null,
            "email": null,
            "total_amount": "99008765590000000",
            "addresses_count": "405",
            "holder_allocation": {
                "ckb_holders_count": "540",
                "btc_holders_count": "98"
            },
            "decimal": "8",
            "h24_ckb_transactions_count": "9",
            "created_at": "1711928465602",
            "xudt_tags": [
                "rgbpp-compatible",
                "layer-2-asset",
                "supply-unlimited"
            ]
        }
    }
}
Keith-CY commented 2 weeks ago

I will propose a simple implementation before the API is all ready


PR from @Daryl-L is ready: https://github.com/Magickbase/ckb-explorer-frontend/pull/382/files

Daryl-L commented 2 weeks ago

https://github.com/Magickbase/ckb-explorer-frontend/pull/383

rabbitz commented 1 week ago

Readme: https://ckb-explorer.readme.io/reference/udt-holder-allocation PR: https://github.com/nervosnetwork/ckb-explorer/pull/1991

Request
curl --location --request GET 'https://ckb-explorer-api-staging.magickbase.com/api/v1/udts/0xe6396293287fefb9f26d98eb0318fe80890908f0849226ad0c8cab2d62f1e351/holder_allocation' \
--header 'Accept: application/vnd.api+json' \
--header 'User-Agent: Apifox/1.0.0 (https://apifox.com)' \
--header 'Content-Type: application/vnd.api+json' \
--header 'Host: ckb-explorer-api-staging.magickbase.com' \
--header 'Connection: keep-alive' \
--header 'Cookie: AWSALB=bv4bxoRUlPUZdhJKtM3Ljsyfgl8OjV+Ap8aEykOkf0J7Y/mV91GU8LL2Om5OtDHrqomuPcx4D0TXI7sWJHf0UIt2vqKs9JPY+6AxEn+avIXiy9uviR2ntW3P/8/0; AWSALBCORS=bv4bxoRUlPUZdhJKtM3Ljsyfgl8OjV+Ap8aEykOkf0J7Y/mV91GU8LL2Om5OtDHrqomuPcx4D0TXI7sWJHf0UIt2vqKs9JPY+6AxEn+avIXiy9uviR2ntW3P/8/0'

Response

{
    "btc_holder_count": 0,
    "lock_hashes": [
        {
            "name": null, # contract name
            "code_hash": "0x75ac906998b047602967d7f89505bb9817e405b89f868111ded51d672f9e260e", # contract code hash
            "holder_count": 8
        },
        {
            "name": "secp256k1_blake160",
            "code_hash": "0x9bd7e06f3ecf4be0f2fcd2188b23f1b9fcc88e5d4b65a8637b17723bbda3cce8",
            "holder_count": 1
        },
        {
            "name": null,
            "code_hash": "0xb8d8fbfd27e538ea0f74e16cccf576740d830daa1202045bcf82c96f1ed48ee7",
            "holder_count": 17
        },
        {
            "name": "JoyID",
            "code_hash": "0xd23761b364210735c19c60561d213fb3beae2fd6172743719eff6920e020baac",
            "holder_count": 120
        },
        {
            "name": "omni_lock v2",
            "code_hash": "0xf329effd1c475a2978453c8600e1eaf0bc2087ee093c3ee64cc96ec6847752cb",
            "holder_count": 901
        }
    ]
}

@Daryl-L @Keith-CY The interface has been updated on staging, and the UDT data has been refreshed.

FrederLu commented 7 hours ago

The data on Staging is normal. https://ckb-explorer-frontend-in-magickbase-repo-4h1oyyizz-magickbase.vercel.app/xudt/0x37146d3967d7e9aae77bc16d7070d2e89a659b2d8fc1df57247bf29bd8c7f1b5 Image

https://pudge.explorer.nervos.org/xudt/0x37146d3967d7e9aae77bc16d7070d2e89a659b2d8fc1df57247bf29bd8c7f1b5 Image BTC data on Testnet shows abnormalities.

rabbitz commented 4 hours ago

The data on Staging is normal. https://ckb-explorer-frontend-in-magickbase-repo-4h1oyyizz-magickbase.vercel.app/xudt/0x37146d3967d7e9aae77bc16d7070d2e89a659b2d8fc1df57247bf29bd8c7f1b5 Image

https://pudge.explorer.nervos.org/xudt/0x37146d3967d7e9aae77bc16d7070d2e89a659b2d8fc1df57247bf29bd8c7f1b5 Image BTC data on Testnet shows abnormalities.

This may be because the previous data has not been refreshed, and there has been no recent udt transaction, so the data update will not be triggered. After the manual update, the data is consistent.