Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor(ckb): encapsulate transaction fee supplementation methods #302

Merged
merged 3 commits into from
Feb 11, 2025

Conversation

fghdotio
Copy link
Contributor

@fghdotio fghdotio commented Feb 9, 2025

Extract the logic for supplementing transaction fees into separate methods to facilitate users handling the signing logic for the final CKB transaction on their own.

xUDT testing transactions on Testnet3 in offline mode:

  1. Issuance preparation
  2. Issuance:
  3. Distribution:
  4. Jumping from BTC to CKB:
  5. Unlock BTC time lock cell:

xUDT testing transactions on Testnet3 in default mode:

Spore Creation:

@duanyytop duanyytop requested review from duanyytop, ShookLyngs and Flouse and removed request for duanyytop February 9, 2025 10:39
skipMissingKeys?: boolean,
): CKBComponents.RawTransaction;

export function signCkbTransaction(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are there three functions with the same name signCkbTransaction?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first overload handles the case where the key is a single string and inputCells is optional. The second overload is for when key is a Map<string, string>, in which case inputCells is required. The third definition is the actual implementation. I believe these overloads improve type checking and IDE support by explicitly defining valid parameter combinations, even though they do add some complexity.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you verify if it works if there is only one function signature?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the third function, which is the actual implementation, is sufficient on its own. The following are the related transactions I just sent for xUDT testing on Testnet3 in offline mode:

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So can we remove the above two functions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I'll make the change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in 740612b, along with this suggested change #302 (comment).

*/
export const appendIssuerCellToBtcBatchTransfer = async ({
secp256k1PrivateKey,
export const appendOwnerCellToRgbppTx = async ({
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: appendOwnerCellToRgbppTx -> appendIssuerCellToBtcBatchTransferToSign

*/
export const signBtcTimeCellSpentTx = async ({
secp256k1PrivateKey,
export const completeBtcTimeCellSpentTx = async ({
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: completeBtcTimeCellSpentTx -> buildBtcTimeCellSpentTx

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if this change is a good idea since the suggested function name is very similar to buildBtcTimeCellsSpentTx, which might cause confusion.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you are right. Maybe prepareBtcTimeCellSpentUnsignedTx is better?

*/
export const appendIssuerCellToSporesCreate = async ({
secp256k1PrivateKey,
export const completeAppendingIssuerCellToSporesCreateTx = async ({
Copy link
Collaborator

@duanyytop duanyytop Feb 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: completeAppendingIssuerCellToSporesCreateTx -> appendIssuerCellToSporesCreateUnsignTx

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: appendIssuerCellToSporesCreateUnsignTx -> appendIssuerCellToSporesCreateUnsignedTx

};

// Normalizes a CKB transaction to be signed by ensuring all witnesses are in serialized string format.
export const normalizeCkbTxToSign = (ckbTx: CKBComponents.RawTransactionToSign): CKBComponents.RawTransactionToSign => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any function calling function normalizeCkbTxToSign?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not in the current codebase. This function was implemented to ensure that RawTransactionToSign.witness is consistently represented as a string, simplifying deserialization in other strongly typed languages.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I don't understand.

Why do we keep this function if no other functions call the normalizeCkbTxToSign? And the signCkbTransaction already has the same code.

If you want a reference for other programming languages ​​on how to do it, adding more comments in the signCkbTransaction function can work too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed! Adding comments in signCkbTransaction would be a better approach.

@duanyytop duanyytop added this pull request to the merge queue Feb 11, 2025
Merged via the queue into utxostack:develop with commit 74b593a Feb 11, 2025
0 of 4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants