[FR] Merge iCKB Utils UDTHandler features into CCC's Udt

[phroi]

Hello CKB DevRel folks!!
I was wondering, have you considered merging iCKB Utils' UDTHandler Features into the CCC library's Udt?

Summary

We currently maintain three parallel UDT implementations:

1. CCC's Udt class (metadata, transfer, mint, basic completeBy)
2. iCKB Utils' UdtHandler/UdtManager (SmartTransaction-aware balance tracking, input aggregation, change-cell via completeUdt)
3. iCKB Core's IckbUdtManager (overrides input balance for iCKB UDT cells, receipt and deposit transformation logic)

This duplication leads to inconsistent behaviors, extra maintenance, and diverging sUDT data-length checks.

CCC Feature Request

In the CCC library's Udt class, add methods/properties from iCKB Utils' UdtManager:

• getInputsUdtBalance(client, tx) (open to change the name)
• getOutputsUdtBalance(tx) (we can find a better name)
• completeBy(tx, signer, options?), support shouldAddInputs?: boolean and compressState?: boolean as options
• cellDeps: ccc.CellDep[];

Note: I'm open to change any of the previous names if necessary.

ICKB side of things

Deprecate iCKB Utils' standalone UdtHandler/UdtManager. Instead, let IckbUdtManager extend the enhanced CCC Udt class, overriding only:

• The xUDT data-length check (≥16 bytes on-chain)
• Custom input-balance logic for:
  • iCKB receipt cells
  • DAO deposit/withdrawal cells
• Accept both ccc.Transaction and SmartTransaction as completeBy inputs, detect type, use smartTransaction.copy(tx) when needed in SmartTransaction completeFee, and return the same transaction type.

Keep up the Great Work, Phroi %28

[Hanssen0]

Thank you for your suggestions! It's a reasonable feature to implement in CCC for better code reuse.

Before starting, I wonder what the compressState option is?

For the cellDeps property, if we add an onTransactionCreated hook for manipulating Transaction, how do you think?

[phroi]

I wonder what the compressState option is?

If shouldAddInputs is evaluated to true and at least one additional UDT cell is required, add all UDT cells to compress state rent. Feel free to change the name!

For the cellDeps property, if we add an onTransactionCreated hook for manipulating Transaction, how do you think?

At the beginning I wanted to fight back ("just give me back my cellDeps!!"🤣), but thinking more about it, it is reasonable to assume that any Transaction which uses UDT should also call completeBy as last step to even out the UDT balance between input and output.

Say a transaction exists that fails to call completeBy, it may very well be an error and we can passively prevent it the error by not adding said cellDeps beforehand.

At this point, I'd say that adding the specific cellDeps as last step inside completeBy seems reasonable. Even more we can make the specific behavior overridable with a hook.

Async-ness of getOutputsUdtBalance

Conversely, I'm worried that you'll make all these methods async for compatibility with SSRI, which is okayish until you notice that Transaction.getOutputsUdtBalance is not async.

This may prove to be quite a pickle for SmartTransaction migration to UDT, since SmartTransaction delegates to the UDT handler.

Any suggestion on this?

[Hanssen0]

If shouldAddInputs is evaluated to true and at least one additional UDT cell is required, add all UDT cells to compress state rent.

We added a feature similar to this last week with a suggestion from @rink1969 #216
And I improved the algorithm in #228. Now Udt.complete will try to fill the capacity gap by collecting more UDT cells, avoiding an extra UDT occupation fee while making the performance cost acceptable (since we have to collect cells for capacity anyway).

If we want to collect all UDT cells, I personally think Transaction.completeInputsAll will be better (of course, we can create a wrapper for it in the Udt class).

Say a transaction exists that fails to call completeBy, it may very well be an error and we can passively prevent it the error by not adding said cellDeps beforehand.

Yes. What's more, it's possible that some Udt in the future needs more than adding cellDeps, maybe add some headerDeps or witnesses.

Conversely, I'm worried that you'll make all these methods async for compatibility with SSRI, which is okayish until you notice that Transaction.getOutputsUdtBalance is not async.

We'll make it async.

[phroi]

For anyone following this issue, @Hanssen0 and I agreed to the following plan in 4 phases:

1. Let's focus on the complete* methods first. On this stage, only ordinary UDT cells will be considered. We should be able to move every UDT-related method out of Transaction after this.
2. Try to add more querying methods, like calculating info of a Signer. Meanwhile, we should have methods for parsing a single UDT cell. On this stage, we should consider if these new methods can be overridden to accommodate some unconventional UDT cell requirements.
3. Allow more than one cell deps, and also dep groups.
4. Decouple SSRI with UDT.

Current status:

• Phase 1: worked on feat(udt): balance related util methods #228, merged ✅
• Phase 2 : worked on feat(udt): add udt info querying methods #261, canary available for feedback
• Phase 3: TODO
• Phase 4: TODO

Phroi