get_cell to reoslve OutPoint

[homura]

Feature Request

In some dApp scenarios, it's necessary to resolve a cell even if the cell has already been consumed. This is needed for tasks such as analyzing the purpose of a transaction and rendering transaction records that include both the sender and recipient.

Developers currently have to resolve an OutPoint by fetching an entire transaction and then extracting the corresponding cell from its outputs. This becomes challenging when the pointed transaction is large

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Add a new RPC similar to get_live_cell without the status of the cell

Request

{
  "id": 42,
  "jsonrpc": "2.0",
  "method": "get_cell",
  "params": [
    // out point
    {
      "index": "0x0",
      "tx_hash": "0xa4037a893eb48e18ed4ef61034ce26eba9c585f15c9cee102ae58505565eccc3"
    },
    // with data
    true
  ]
}

Response

{
  "id": 42,
  "jsonrpc": "2.0",
  "result": {
    "data": {
      "content": "0x...",
      "hash": "0x28e83a1277d48add8e72fadaa9248559e1b632bab2bd60b27955ebc4c03800a5"
    },
    "output": {
      "capacity": "0x802665800",
      "lock": {
        "code_hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "hash_type": "data",
        "args": "0x"
      },
      "type": null
    }
  }
}

Describe alternatives you've considered

[eval-exec]

ckb/store/src/cell.rs

Lines 75 to 79 in 44afc93

	let deads = transactions
	.iter()
	.skip(1)
	.flat_map(|tx| tx.input_pts_iter());
	txn.delete_cells(deads)?;

Is it impossible to resolve this issue with dead cells because dead cells in RocksDB always be deleted from COLUMN_CELL? @quake

Or we can query deadcell from COLUMN_BLOCK_BODY?

[homura]

we can query deadcell from COLUMN_BLOCK_BODY?

To achieve the feature, I'm extracting the cell from the corresponding transaction using the following code:

tx_hash = []
for input in inputs:
  tx_hash.append(input.previous_output.tx_hash)

txs = batch_and_chunk('get_transaction', tx_hash, chunk_size)

zip_with(inputs, txs, zip_func)

However, there are some challenges with this approach:

1. The inputs may contain hundreds or thousands of input items
2. The resolved transaction could be 100x larger than the target output, leading to wasted netowkr io

[eval-exec]

@homura Hello. Could you describe the "use case" in which you need to query DeadCell?

[homura]

@homura Hello. Could you describe the "use case" in which you need to query DeadCell?

We are developing a data aggregation layer to retrieve historical data from the blockchain, including CKB. A component of this project, called sync, extracts data from the blockchain block by block and converts the transactions into human-readable actions. These actions include native and derived asset minting, transfers, burns, DeFi swaps, liquidity operations, and more. We use the get_block RPC to request blocks. Currently, we decode the blocks using the mentioned approach to ensure that the cells in both the inputs and outputs are accessible and determine the purpose of the transaction.

Another project from a long time ago was an asset bridge, which had no backend and used CKB RPC directly, and in the transaction history we also needed to render from and to information, which was also a user story

[quake]

To provide functionality such as querying “which transaction spent a cell”, the ckb node would need to keep track of the referential relationship of each dead cell, this will significantly increase storage requirements and IO overhead.

CKB's rpc design is same as Bitcoin, focus on maintaining the UTXO set only, as this helps to speed up the transaction verification process, complex queries are often considered to be within the scope of functionality of third-party services such as block browsers and analytics platforms.

[homura]

To provide functionality such as querying “which transaction spent a cell”,

I want to clarify that the feature request is to resolve (dead) cells by OutPoints instead of querying "which transaction spent a cell". The purpose is to prune unnecessary data while resolving inputs' OutPoints. The CKB node can store all transactions and retrieve the specific transaction by a hash.