Feature Proposal: Adding Buttons for Cell Data Decoding

[Keith-CY]

Discussed in https://github.com/Magickbase/ckb-explorer-public-issues/discussions/324

^{Originally posted by **Flouse** May 16, 2023} Recently, I created [a simple tutorial showing how to inscribe "Hello Common Knowledge Base!"](https://ckb-tthw.vercel.app/) or any message to CKB Testnet. @quake suggested a new feature for CKB Explorer. And I think it is worth discussing here. ## Problem The data stored in CKB cells usually is not human-readable formats. It can be difficult for users to interpret this data.  The [above cell data](https://pudge.explorer.nervos.org/transaction/0x39d6d7b6129b7e418c9ea6a353a5d85eb69f9ee5b4c7c43223fe0fad2b0e6200) is the hexadecimal format of "Hello Common Knowledge Base!". #### Related issue - https://github.com/Flouse/ckb-tthw/issues/1 ## Proposed Feature We propose some addition of buttons for decoding cell data in the CKB Explorer, similar to Etherscan  These buttons would allow users to easily decode cell data to decimal or UTF-8 string formats. This feature would be particularly useful for some on-chain scripts such as SUDT and DAO, as their cell data could be easily decoded and interpreted by users. ### Functionality When a user clicks one of the decoding buttons, the corresponding decoder function would be applied to the cell data and the result would be displayed in a new modal or overlay. The decoded data could be displayed in plain text to make it easily accessible to users.

[ShiningRay]

We can use pegjs to parse the .mol format description file, and use it to parse these data.

[homura]

Personally, I have doubts about the necessity of this feature.

Unlike Ethereum, where it is an uncommon and SUPER expensive practice to store textual content in data in UTF-8 encoding on CKB. Ethereum is able to do this because when we transfer Ether to an EOA account, the data field is ignored by the transaction execution, and usually the additional data does not raise the transaction fee too much.

However, writing a byte to data costs an extra 1 CKB, we can look at this famous Ethereum transaction, which wrote a total of 8501 byte of data in data, if it is on CKB, it costs an additional 8501 CKB, although this 8501 CKB can be retrieved at anytime, most of the SDKs cannot manipulate such a cell with data, because the SDK will consider the cell is not a free one, and will not spend it.

So I think "decode data in UTF-8" is just a corner case, and maybe we should think more about this feature

[Keith-CY]

Personally, I have doubts about the necessity of this feature.

Unlike Ethereum, where it is an uncommon and SUPER expensive practice to store textual content in data in UTF-8 encoding on CKB. Ethereum is able to do this because when we transfer Ether to an EOA account, the data field is ignored by the transaction execution, and usually the additional data does not raise the transaction fee too much.

However, writing a byte to data costs an extra 1 CKB, we can look at this famous Ethereum transaction, which wrote a total of 8501 byte of data in data, if it is on CKB, it costs an additional 8501 CKB, although this 8501 CKB can be retrieved at anytime, most of the SDKs cannot manipulate such a cell with data, because the SDK will consider the cell is not a free one, and will not spend it.

So I think "decode data in UTF-8" is just a corner case, and maybe we should think more about this feature

It's not limited to UTF-8 encoding, but depends on the business logic of the cell.

As I briefly mentioned in the discord channel, I suggest running a node.js service to go through cells and translate their raw data into business data with the help of dapps' SDKs.

The data should be explained by the dapp providers.

Furthermore, we can expose an API to accept decoded data of a transaction and authenticates dapp providers to decode the data. Once the decoding service can be deployed standalone, we can run it ourselves.

[Keith-CY]

This feature can be adopted on witness, too(I got this feature request recently)

---

I'm inspired by the translation feature on selection.

What if the data can be parsed partially by selection?

1. Users select a segment of the data
2. A tooltip shows with some pre-defined decoding algorithms
3. An algorithm is selected, and the selection will be decoded accordingly.

Complex strings containing multiple encoded data can be parsed separately.

Expected algorithms

1. UTF-8
2. Number
3. Address

4. Big-Endian

IMO, this feature can be enabled on address, args, too

[Sven-TBD]

We can move this issue to #469 , it's also related to the way we display transaction information.

[Sven-TBD]

@Keith-CY @Kirl70 here's the UX plan, please check this translation-like user interaction design.

[Sven-TBD]

@Keith-CY @Kirl70 here's the UX plan, please check this translation-like user interaction design.

About whether this new feature needs a prompt/tips. I think it's unnecessary. The reason is: currently, the user's typical action is to click here if they want to copy the data for decoding. With the changes, when they click, the corresponding decoding pop up will display. So, the transition is quite natural, and there's no need for an additional prompt in the design.

关于此新功能是否需要提示。 我觉得不需要。理由是：现在目前的操作是，如果用户想要复制Data进行decode，他会点一下这里，然后复制。改动之后，他点击时，就会有相应的decode算法，所以过渡其实比较自然，就没有另起设计提示。

[Kirl70]

Design Draft: https://www.figma.com/file/6XNoimRDbFTTNm016rbIdU/Magickbase?type=design&node-id=29085%3A17636&mode=design&t=TRJHXdueGMbI8zsc-1

[Keith-CY]

Design Draft: figma.com/file/6XNoimRDbFTTNm016rbIdU/Magickbase?type=design&node-id=29085%3A17636&mode=design&t=TRJHXdueGMbI8zsc-1

LGTM, it's better to have a Copy button next to the decoded content

[Kirl70]

LGTM, it's better to have a Copy button next to the decoded content

Copy button has been added.

[Sven-TBD]

Related issue #498 , I will mark this as Hold On, and we can only track #498

[Keith-CY]

Partially done by https://github.com/nervosnetwork/ckb-explorer-frontend/commit/4710e4c52ae446b212084755845662503f1ac5f4

Available in transaction parameters.witnesses, Cell Info E.g. https://pudge.explorer.nervos.org/transaction/0x5709cdc5cab0cfe17749d0118b4cf9b23fd1e06e64b8a4164b50972945dbc7b0#1

And https://pudge.explorer.nervos.org/transaction/0x6df4dc73413a50318dace027a70725fb137184beb8802306daa4a0283860c8a8

[FrederLu]

The decoder positioning will shift when used on the page, sometimes thinking that the current information cannot be decoded.

https://github.com/Magickbase/ckb-explorer-public-issues/assets/25676576/fbbef769-4dc9-407f-8903-a106cd1cb7f5

[Keith-CY]

The decoder positioning will shift when used on the page, sometimes thinking that the current information cannot be decoded.

2024-04-03.13.59.19.mov

It should have been optimized

[FrederLu]

The decoder positioning will shift when used on the page, sometimes thinking that the current information cannot be decoded. 2024-04-03.13.59.19.mov

It should have been optimized

On which PR was the optimization performed? You can post a link. I still see this problem on Testnet.

[FrederLu]

The decoder positioning will shift when used on the page, sometimes thinking that the current information cannot be decoded. 2024-04-03.13.59.19.mov

It should have been optimized

https://pudge.explorer.nervos.org/transaction/0x5dc3868ae53725530b6bd74965d9576880f2858a34b2f9ede6a6d0e4ac310f22 This is an arbitrary data link on Testnet.

The decoder positioning will shift when used on the page, sometimes thinking that the current information cannot be decoded.

2024-04-03.13.59.19.mov

The position of the encoding pop-up window after clicking is as shown in the video.