Open Keith-CY opened 1 year ago
In my imagination, it may look like this
At the present, there doesn't seem to be a way to fetch which transaction consumed a particular OutPoint
via RPC directly
A close idea is to use the get_transactions
to probe which transactions have consumed the Script
of the OutPoint
, but there are some problems with this way
OutPoint
must not be popular on the chain, otherwise the probing process will become very longIn my imagination, it may look like this
At the present, there doesn't seem to be a way to fetch which transaction consumed a particular
OutPoint
via RPC directlyA close idea is to use the
get_transactions
to probe which transactions have consumed theScript
of theOutPoint
, but there are some problems with this way
- the scripts of the
OutPoint
must not be popular on the chain, otherwise the probing process will become very long
Please have a look at this proposal @Danie0918 @Sven-TBD
In my imagination, it may look like this At the present, there doesn't seem to be a way to fetch which transaction consumed a particular
OutPoint
via RPC directly A close idea is to use theget_transactions
to probe which transactions have consumed theScript
of theOutPoint
, but there are some problems with this way
- the scripts of the
OutPoint
must not be popular on the chain, otherwise the probing process will become very longPlease have a look at this proposal @Danie0918 @Sven-TBD
This is a useful and interesting feature and we will start moving forward with its implementation.
vs0cjf.axshare.com/?id=j6zrfc&p=_354_an_independent_service_of_transaction_graph&g=1 @Keith-CY
cc @homura
The diagram is cool and inspiring, but I guess it might be affected by the above one. It is based on the view of a single cell. However, it's not easy to define an entry cell, and it's difficult, maybe impossible, to define a one-to-one relationship between cells. Therefore, I propose changing the view from single-cell-based to timeline-based
Next, I'll talk about what each of these elements represents.
A cellbase transaction example
This is a chained transaction exam. The dashed lines linked to the transactions are clickable and link to the corresponding block area.
This is an example of the spent cellbase transaction. Also, the dashed line is clickable and links to the corresponding block area.
The diagram is cool and inspiring, but I guess it might be affected by the above one. It is based on the view of a single cell. However, it's not easy to define an entry cell, and it's difficult, maybe impossible, to define a one-to-one relationship between cells. Therefore, I propose changing the view from single-cell-based to timeline-based
Next, I'll talk about what each of these elements represents.
A cellbase transaction example
This is a chained transaction exam. The dashed lines linked to the transactions are clickable and link to the corresponding block area.
This is an example of the spent cellbase transaction. Also, the dashed line is clickable and links to the corresponding block area.
Is it necessary to order the transactions by block [n]
? Transactions are ordered by their nature(linked list). The graph may be hard to read if a transaction is linked to several transactions that are far from each other from the block number dimension because they may not be linear. For instance
Block Block + N Block + N + 1000 Block + N + 10000000
Transaction ---------> Transaction
├-----------------------------------------> Transaction
└-----------------------------------------------------------------------> Transaction
Is it necessary to order the transactions by block [n]?
Block Block + N Block + N + 1000 >Block + N + 10000000 Transaction ---------> Transaction ├-----------------------------------------> Transaction └--------------------------------------------------------->--------------> Transaction
No, but it isn't easy to design how to
Block + N
and Block + N + 1000
The new one I proposed is not a fix, but another new way that will make the design more intuitive
The graph may be hard to read if a transaction is linked to several transactions that are far from each other from the block number dimension because they may not be linear
Exactly, this is the reason to keep an OutPoint
with a dashed line in the Tx3
, and users can click the OutPoint
with a left-slide animation to locate the corresponding block area
A PoC can be previewed here https://ckb-tx-illustration.vercel.app/
log10(capacity)
instead of capacity
because the amount of capacity varies greatly from cell to cellI have already implemented a demo using Cytoscape. Cytoscape is convenient for constructing tree diagrams. I will continue to research how to add nodes dynamically.
It was found that the fifth data in UTXO graph
was incomplete. @yanguoyu
It was found that the fifth data in
UTXO graph
was incomplete. @yanguoyu
I checked with Guoyu like last week, and I told him 4 cells should be displayed here by default, though he said it could be 5, never mind, let's make it 4, so we could mark this bug as fixed @FrederLu
https://pudge.explorer.nervos.org/transaction/0x8ab56f4f70cac7c23aac75bc81abb403f799befc16490528f342b3837fc82824 https://pudge.explorer.nervos.org/transaction/0xbf824fe159e97d65af0776c7ad9261fc98f5b648f411edf9a4bab20bf63a43e2 It was found that the fifth data in
UTXO graph
was incomplete. @yanguoyuI checked with Guoyu like last week, and I told him 4 cells should be displayed here by default, though he said it could be 5, never mind, let's make it 4, so we could mark this bug as fixed @FrederLu
OK, I got it then.
All cells on-chain are linked by
input -> output
in transactions, so they construct a graph that shows the history of the whole chain/live cells.It would be very intuitive and impressive for data analysis.
The service can be designed standalone and provides data to CKB explorer UI