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

(small breaking change) Merge v13's "TransactionNext" into the existing "Transaction" class #396

Merged
merged 19 commits into from
Mar 14, 2024

Conversation

andreibancioiu
Copy link
Contributor

@andreibancioiu andreibancioiu commented Mar 11, 2024

The existing Transaction class has been adjusted to match the specs.

TransactionNext of v13 has been incorporated into Transaction.

Breaking (but small) change on tx.version and tx.options

Before (v12):

// @deprecated
version: TransactionVersion;

// @deprecated
options: TransactionOptions;

Now (v13):

version: number;
options: number;

However, in practice, dApps should not be affected by this. The fields version and options were marked as deprecated for a long time. This change does NOT affect the following (since they rely on the not-changed setVersion and setOptions):

  • mx-sdk-js-hw-provider
  • sdk-dapp

There, version & options are mutated like this (example):

transaction.setVersion(TransactionVersion.withTxOptions());
transaction.setVersion(TRANSACTION_VERSION_WITH_OPTIONS);
transaction.setOptions(options | TRANSACTION_OPTIONS_TX_HASH_SIGN);
transaction.setOptions(TransactionOptions.withOptions({ guarded: true }));
transaction.setOptions(TransactionOptions.withOptions({
    guarded: true,
    ...(isLedger ? { hashSign: true } : {})
}));

These functions, setVersion and setOptions, remain available (legacy).

@andreibancioiu andreibancioiu marked this pull request as ready for review March 11, 2024 10:05
@andreibancioiu andreibancioiu self-assigned this Mar 11, 2024
Comment on lines +87 to +92
public version: number;

/**
* The options field, useful for describing different settings available for transactions.
*/
public options: number;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Breaking change.

return feeForMove;
}
computeBytesForSigning(transaction: ITransaction): Uint8Array {
// TODO: do some checks for the transaction e.g. sender, chain ID etc.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

We should not forget about this.

Comment on lines 44 to 52
/**
* The address of the sender.
*/
public sender: string;

/**
* The address of the receiver.
*/
public receiver: string;
Copy link
Contributor

Choose a reason for hiding this comment

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

Now that i think about, maybe in the js doc should be mentioned that the bech32 representation of an address should be provided. (optional)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed.

/**
* The address of the guardian.
*/
public guardian: string;
Copy link
Contributor

Choose a reason for hiding this comment

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

same comment as above.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed.

Comment on lines 117 to 149
public constructor({
nonce,
value,
sender,
receiver,
senderUsername,
receiverUsername,
gasPrice,
gasLimit,
data,
chainID,
version,
options,
guardian,
signature,
guardianSignature,
}: {
nonce?: INonce | bigint;
value?: ITransactionValue | bigint;
sender?: IAddress | string;
receiver?: IAddress | string;
senderUsername?: string;
receiverUsername?: string;
gasPrice?: IGasPrice | bigint;
gasLimit?: IGasLimit | bigint;
data?: ITransactionPayload | Uint8Array;
chainID?: IChainID | string;
version?: ITransactionVersion | number;
options?: ITransactionOptions | number;
guardian?: IAddress | string;
signature?: Uint8Array;
guardianSignature?: Uint8Array;
}) {
Copy link
Contributor

Choose a reason for hiding this comment

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

perhaps change the constructor as bellow? to be aligned with the transaction factories.

constructor(options: {...})

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed.

Comment on lines 136 to 137
sender?: IAddress | string;
receiver?: IAddress | string;
Copy link
Contributor

Choose a reason for hiding this comment

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

shouldn't we have mandatory fields on the constructor? Like sender, receiver, gas limit and chain?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Indeed, fixed. Reverted, and now we have the same required fields as in PY (as in JS v12, as well): sender, receiver, chain ID and gas limit.

@@ -127,7 +127,7 @@ export class SmartContract implements ISmartContract {
const bytecode = Buffer.from(code.toString(), 'hex');
const metadataAsJson = this.getMetadataPropertiesAsObject(codeMetadata);

const nextTx = scNextTransactionFactory.createTransactionForDeploy({
const transaction = scNextTransactionFactory.createTransactionForDeploy({
Copy link
Contributor

Choose a reason for hiding this comment

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

also rename scNextTransactionFactory

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed.

@andreibancioiu andreibancioiu changed the title Merge "TransactionNext" into the existing "Transaction" class (small breaking change) Merge "TransactionNext" into the existing "Transaction" class Mar 13, 2024
@andreibancioiu andreibancioiu changed the title (small breaking change) Merge "TransactionNext" into the existing "Transaction" class (small breaking change) Merge v13's "TransactionNext" into the existing "Transaction" class Mar 13, 2024
danielailie
danielailie previously approved these changes Mar 14, 2024
danielailie
danielailie previously approved these changes Mar 14, 2024
radumojic
radumojic previously approved these changes Mar 14, 2024

public plainObjectToTransaction(object: IPlainTransactionObject): Transaction {
const transaction = new Transaction({
nonce: Number(object.nonce),
Copy link
Contributor

Choose a reason for hiding this comment

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

this can be BigInt

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Indeed. Fixed.

}
}
private addressAsBech32(address: IAddress | string): string {
return typeof address === "string" ? address : address.bech32();
Copy link
Contributor

Choose a reason for hiding this comment

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

I hope people pass the correct string representation of the address. If people pass the address as a hex string this will not work as expected.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Indeed. In the specs, we have transaction.sender, transaction.receiver as strings.

@andreibancioiu andreibancioiu merged commit ea1499a into feat/next Mar 14, 2024
1 check passed
@andreibancioiu andreibancioiu deleted the same-tx branch March 14, 2024 13:49
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.

4 participants