Show bytes and cycles on block and transaction page

[Keith-CY]

Block page:
cycles: // TODO
max cycles: returned by get_consensus(https://github.com/nervosnetwork/ckb/tree/develop/rpc#method-get_consensus)
bytes: calculated from the block
max bytes: returned by get_consensus(https://github.com/nervosnetwork/ckb/tree/develop/rpc#method-get_consensus)

Transaction page:
cycles: returned by dry_run_transaction(https://github.com/nervosnetwork/ckb/tree/develop/rpc#method-dry_run_transaction)
bytes: calculated from the transaction
max bytes: // TODO

Sidenote: shown in progress bar

Ref:
Consensus: https://github.com/nervosnetwork/ckb/tree/develop/rpc#type-consensus

[Keith-CY]

With this feature, we're going to show cycles of a transaction and a block. I've found max cycles of a block in Consensus and cycles of a transaction by dry run transaction

But I was blocked in getting cycles of a block. AFAIK, we have to get cycles of every transaction in it so we have to dry run them all, which may be unreasonable. I wonder if there is a way to fetch cycles of a transaction without run it locally? @quake

[quake]

All transaction cycles of a block are stored in the ckb full node, but this is an internal data, not exposed through rpc, suggest to create an issue under ckb repo to provide relevant rpc

[Keith-CY]

Returning cycles within RPCs of get_transaction and get_block will be supported later so we can start with bytes first.

There're 6 bytes expected to have

1. bytes of a specific block
2. bytes of the largest block in the current epoch
3. bytes of the largest block from the genesis block(exclude the genesis block, because the genesis block is used to deploy initial scripts so its size is quite large)
4. bytes of a specific transaction
5. bytes of the largest transaction in the current epoch
6. bytes of the largest transaction from the genesis block(exclude transactions in the genesis block)

@ShiningRay @iamyates can we make a schedule?

[Keith-CY]

fee rate could be calculated if size is present.

[Keith-CY]

Update:

The cycles is not stored in the node of the current version. With the next version of ckb node, cycles will be stored but historical data of cycles should be complemented by resynchronization.

So we should run a new node to sync the cycles while keeping the current one running for online service.

[Keith-CY]

fee rate could be calculated if size is present.

UI of fee rate: Magickbase/visual-style-guide#12

[Keith-CY]

Could we return max cycles/bytes with its location, e.g. transaction hash and block number. With these infos, users can find out the tx/block easily.

[ShiningRay]

• Add bytes size to block and transaction datas #103
• Add largest block/transaction query to API #104 Add largest block/transaction query to API

[Keith-CY]

UI design: Magickbase/visual-style-guide#11 (comment)

[Keith-CY]

cycles will be accessible along with nervosnetwork/ckb#3684, but re-sync is required to store cycles of on-chain transactions, so we need another ckb node running from scratch

[Keith-CY]

CKB@v0.106.0 supports to return cycles within a block by RPC https://github.com/nervosnetwork/ckb/tree/develop/rpc#method-get_block @ShiningRay

[Keith-CY]

PR: nervosnetwork/ckb-explorer#1078

[Keith-CY]

CKB V0.106.0 has been released on 2022/12/23, we should start the work of displaying cycles on block page and transaction page

Ref: https://github.com/nervosnetwork/ckb/releases/tag/v0.106.0

[ShiningRay]

nervosnetwork/ckb-explorer#1122

[Keith-CY]

Basic cycles info was added by nervosnetwork/ckb-explorer-frontend#1181 in the front-end, max cycles in current epoch and max cycles on the chain will be implemented later

[Keith-CY]

Have historical data of bytes and cycles been updated? @ShiningRay

[Keith-CY]

As mentioned in the top message, size/cycles will be expressed in 3 dimensions

value: the value of the current block/transaction
compared to max value in current epoch: percentage of value / max_value_in_current_epoch
compared to max value on the chain: percentage of value / max_value_on_chain

I've got some feedback about the description that block 12%, max {value} in epoch 25%, and max {value} on chain 100% are confusing, do you have any idea? @Danie0918

Ref:
epoch: https://github.com/nervosnetwork/rfcs/blob/0a5825608be3a0f8805505c79fcd5203a8deef97/rfcs/0020-ckb-consensus-protocol/0020-ckb-consensus-protocol.md#dynamic-difficulty-adjustment-mechanism

[Danie0918]

As mentioned in the top message, size/cycles will be expressed in 3 dimensions

value: the value of the current block/transaction compared to max value in current epoch: percentage of value / max_value_in_current_epoch compared to max value on the chain: percentage of value / max_value_on_chain

I've got some feedback about the description that block 12%, max {value} in epoch 25%, and max {value} on chain 100% are confusing, do you have any idea? @Danie0918

Ref: epoch: https://github.com/nervosnetwork/rfcs/blob/0a5825608be3a0f8805505c79fcd5203a8deef97/rfcs/0020-ckb-consensus-protocol/0020-ckb-consensus-protocol.md#dynamic-difficulty-adjustment-mechanism

1.Using the progress bar with more than 2 dimensions will indeed cause confusion,it is recommended to display the value instead.
2 in addition, I understand that the value is the current block parameter, and the epoch/chain is a reference value, so it is recommended to put the value outside the floating layer, and in the floating layer Only contrast values are displayed in the layer, as shown in the following image:

[Keith-CY]

As mentioned in the top message, size/cycles will be expressed in 3 dimensions
value: the value of the current block/transaction compared to max value in current epoch: percentage of value / max_value_in_current_epoch compared to max value on the chain: percentage of value / max_value_on_chain

I've got some feedback about the description that block 12%, max {value} in epoch 25%, and max {value} on chain 100% are confusing, do you have any idea? @Danie0918
Ref: epoch: nervosnetwork/rfcs@0a58256/rfcs/0020-ckb-consensus-protocol/0020-ckb-consensus-protocol.md#dynamic-difficulty-adjustment-mechanism

1.Using the progress bar with more than 2 dimensions will indeed cause confusion,it is recommended to display the value instead. 2 in addition, I understand that the value is the current block parameter, and the epoch/chain is a reference value, so it is recommended to put the value outside the floating layer, and in the floating layer Only contrast values are displayed in the layer, as shown in the following image:

With the second solution, 12%, 30%, 70% are still obscure without an explanation.

The percentage/progress bar is used to visually show how consuming/large/costing the block/transaction is. And the value we can get are concrete numbers, percentages are calculated on the page.

If you're going to design the feature from scratch, how would you do

[Danie0918]

As mentioned in the top message, size/cycles will be expressed in 3 dimensions
value: the value of the current block/transaction compared to max value in current epoch: percentage of value / max_value_in_current_epoch compared to max value on the chain: percentage of value / max_value_on_chain

I've got some feedback about the description that block 12%, max {value} in epoch 25%, and max {value} on chain 100% are confusing, do you have any idea? @Danie0918
Ref: epoch: nervosnetwork/rfcs@0a58256/rfcs/0020-ckb-consensus-protocol/0020-ckb-consensus-protocol.md#dynamic-difficulty-adjustment-mechanism

1.Using the progress bar with more than 2 dimensions will indeed cause confusion,it is recommended to display the value instead. 2 in addition, I understand that the value is the current block parameter, and the epoch/chain is a reference value, so it is recommended to put the value outside the floating layer, and in the floating layer Only contrast values are displayed in the layer, as shown in the following image:

With the second solution, 12%, 30%, 70% are still obscure without an explanation.

The percentage/progress bar is used to visually show how consuming/large/costing the block/transaction is. And the value we can get are concrete numbers, percentages are calculated on the page.

If you're going to design the feature from scratch, how would you do

With the second solution, the data on the page is commonly used and easy to understand, the problem is how the reference value makes it easy for users to understand the relationship between them.

We can unify their format, which is easy for users to understand.

Of course, the percentage progress bar and the percentage value have the same function, and the UI can optimize their display.

[Keith-CY]

As mentioned in the top message, size/cycles will be expressed in 3 dimensions
value: the value of the current block/transaction compared to max value in current epoch: percentage of value / max_value_in_current_epoch compared to max value on the chain: percentage of value / max_value_on_chain

I've got some feedback about the description that block 12%, max {value} in epoch 25%, and max {value} on chain 100% are confusing, do you have any idea? @Danie0918
Ref: epoch: nervosnetwork/rfcs@0a58256/rfcs/0020-ckb-consensus-protocol/0020-ckb-consensus-protocol.md#dynamic-difficulty-adjustment-mechanism

1.Using the progress bar with more than 2 dimensions will indeed cause confusion,it is recommended to display the value instead. 2 in addition, I understand that the value is the current block parameter, and the epoch/chain is a reference value, so it is recommended to put the value outside the floating layer, and in the floating layer Only contrast values are displayed in the layer, as shown in the following image:

With the second solution, 12%, 30%, 70% are still obscure without an explanation.
The percentage/progress bar is used to visually show how consuming/large/costing the block/transaction is. And the value we can get are concrete numbers, percentages are calculated on the page.
If you're going to design the feature from scratch, how would you do

With the second solution, the data on the page is commonly used and easy to understand, the problem is how the reference value makes it easy for users to understand the relationship between them.

We can unify their format, which is easy for users to understand.

Of course, the percentage progress bar and the percentage value have the same function, and the UI can optimize their display.

Sure, the target is to show the relations between value and max value in/on epoch/chain clearly.

Say the block is of size 10,000 bytes, and the max block size in the epoch is 30,000 bytes, and the max block size on the chain is 100,000 bytes. The following messages are expected to deliver:

1. size of this block is 10,000 bytes
2. compared to the max block in this epoch, this block is small, approx. 1/3 of the max block in this epoch
3. compared to the max block on the chain, this block is small, approx. 1/10 of the max block on the chain

But the sketch above is still confusing

[Danie0918]

As mentioned in the top message, size/cycles will be expressed in 3 dimensions
value: the value of the current block/transaction compared to max value in current epoch: percentage of value / max_value_in_current_epoch compared to max value on the chain: percentage of value / max_value_on_chain

I've got some feedback about the description that block 12%, max {value} in epoch 25%, and max {value} on chain 100% are confusing, do you have any idea? @Danie0918
Ref: epoch: nervosnetwork/rfcs@0a58256/rfcs/0020-ckb-consensus-protocol/0020-ckb-consensus-protocol.md#dynamic-difficulty-adjustment-mechanism

1.Using the progress bar with more than 2 dimensions will indeed cause confusion,it is recommended to display the value instead. 2 in addition, I understand that the value is the current block parameter, and the epoch/chain is a reference value, so it is recommended to put the value outside the floating layer, and in the floating layer Only contrast values are displayed in the layer, as shown in the following image:

With the second solution, 12%, 30%, 70% are still obscure without an explanation.
The percentage/progress bar is used to visually show how consuming/large/costing the block/transaction is. And the value we can get are concrete numbers, percentages are calculated on the page.
If you're going to design the feature from scratch, how would you do

With the second solution, the data on the page is commonly used and easy to understand, the problem is how the reference value makes it easy for users to understand the relationship between them.
We can unify their format, which is easy for users to understand.
Of course, the percentage progress bar and the percentage value have the same function, and the UI can optimize their display.

Sure, the target is to show the relations between value and max value in/on epoch/chain clearly.

Say the block is of size 10,000 bytes, and the max block size in the epoch is 30,000 bytes, and the max block size on the chain is 100,000 bytes. The following messages are expected to deliver:

1. size of this block is 10,000 bytes
2. compared to the max block in this epoch, this block is small, approx. 1/3 of the max block in this epoch
3. compared to the max block on the chain, this block is small, approx. 1/10 of the max block on the chain

But the sketch above is still confusing

Suspended layer can hold more text，we can adjust descriptions to reduce confusion:

Max size in epoch ->Compared to the max size in epoch
Max size in chain ->Compared to the max size in chain

[Keith-CY]

As mentioned in the top message, size/cycles will be expressed in 3 dimensions
value: the value of the current block/transaction compared to max value in current epoch: percentage of value / max_value_in_current_epoch compared to max value on the chain: percentage of value / max_value_on_chain

I've got some feedback about the description that block 12%, max {value} in epoch 25%, and max {value} on chain 100% are confusing, do you have any idea? @Danie0918
Ref: epoch: nervosnetwork/rfcs@0a58256/rfcs/0020-ckb-consensus-protocol/0020-ckb-consensus-protocol.md#dynamic-difficulty-adjustment-mechanism

1.Using the progress bar with more than 2 dimensions will indeed cause confusion,it is recommended to display the value instead. 2 in addition, I understand that the value is the current block parameter, and the epoch/chain is a reference value, so it is recommended to put the value outside the floating layer, and in the floating layer Only contrast values are displayed in the layer, as shown in the following image:

With the second solution, 12%, 30%, 70% are still obscure without an explanation.
The percentage/progress bar is used to visually show how consuming/large/costing the block/transaction is. And the value we can get are concrete numbers, percentages are calculated on the page.
If you're going to design the feature from scratch, how would you do

With the second solution, the data on the page is commonly used and easy to understand, the problem is how the reference value makes it easy for users to understand the relationship between them.
We can unify their format, which is easy for users to understand.
Of course, the percentage progress bar and the percentage value have the same function, and the UI can optimize their display.

Sure, the target is to show the relations between value and max value in/on epoch/chain clearly.
Say the block is of size 10,000 bytes, and the max block size in the epoch is 30,000 bytes, and the max block size on the chain is 100,000 bytes. The following messages are expected to deliver:

1. size of this block is 10,000 bytes
2. compared to the max block in this epoch, this block is small, approx. 1/3 of the max block in this epoch
3. compared to the max block on the chain, this block is small, approx. 1/10 of the max block on the chain

But the sketch above is still confusing

Suspended layer can hold more text，we can adjust descriptions to reduce confusion:

Max size in epoch ->Compared to the max size in epoch Max size in chain ->Compared to the max size in chain

It's much clearer.

[Keith-CY]

@pygman could you add the tooltip of more info of size and cycles, UI draft has been updated in Magickbase/visual-style-guide#11

[pygman]

@pygman could you add the tooltip of more info of size and cycles, UI draft has been updated in Magickbase/visual-style-guide#11

Ok, I will.

[pygman]

Frontend PR: nervosnetwork/ckb-explorer-frontend#1200

[Keith-CY]

Some data are missing, waiting for a fix of backend