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

TransactionHelper -> generateBasicTransaction #435

Open
PatrickAlphaC opened this issue May 2, 2024 · 0 comments
Open

TransactionHelper -> generateBasicTransaction #435

PatrickAlphaC opened this issue May 2, 2024 · 0 comments

Comments

@PatrickAlphaC
Copy link

I'd like to make this issue on the npm zksync-contracts repo but I'm unsure as to where that is.

Problem

As of token, if I want to make a Transaction object (which I often do... Although I'm not sold on the name yet, but it's growing on me) I have to fill in this behemoth:

/// @notice Structure used to represent zkSync transaction.
struct Transaction {
    // The type of the transaction.
    uint256 txType;
    // The caller.
    uint256 from;
    // The callee.
    uint256 to;
    // The gasLimit to pass with the transaction.
    // It has the same meaning as Ethereum's gasLimit.
    uint256 gasLimit;
    // The maximum amount of gas the user is willing to pay for a byte of pubdata.
    uint256 gasPerPubdataByteLimit;
    // The maximum fee per gas that the user is willing to pay.
    // It is akin to EIP1559's maxFeePerGas.
    uint256 maxFeePerGas;
    // The maximum priority fee per gas that the user is willing to pay.
    // It is akin to EIP1559's maxPriorityFeePerGas.
    uint256 maxPriorityFeePerGas;
    // The transaction's paymaster. If there is no paymaster, it is equal to 0.
    uint256 paymaster;
    // The nonce of the transaction.
    uint256 nonce;
    // The value to pass with the transaction.
    uint256 value;
    // In the future, we might want to add some
    // new fields to the struct. The `txData` struct
    // is to be passed to account and any changes to its structure
    // would mean a breaking change to these accounts. In order to prevent this,
    // we should keep some fields as "reserved".
    // It is also recommended that their length is fixed, since
    // it would allow easier proof integration (in case we will need
    // some special circuit for preprocessing transactions).
    uint256[4] reserved;
    // The transaction's calldata.
    bytes data;
    // The signature of the transaction.
    bytes signature;
    // The properly formatted hashes of bytecodes that must be published on L1
    // with the inclusion of this transaction. Note, that a bytecode has been published
    // before, the user won't pay fees for its republishing.
    bytes32[] factoryDeps;
    // The input to the paymaster.
    bytes paymasterInput;
    // Reserved dynamic type for the future use-case. Using it should be avoided,
    // But it is still here, just in case we want to enable some additional functionality.
    bytes reservedDynamic;
}

It would be great if the TransactionHelper library came packed with a generateDefaultTransaction API for one to generate default transactions.

Potential Solution

The function could look as such:

/*
 * @param txType: 0x0, 0x1, 0x2, 0x3, 0x71, or 0xff
 */ 
function generateDefaultTransaction(uint8 txType) public returns(Transaction memory) {
  // proceed to populate the transaction with some good defaults..
}

This way, my API could be:

Transaction typeTwoTx = generateDefaultTransaction(2);
typeTwoTx.to = address(5);

Instead of having to populate everything myself.

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

No branches or pull requests

1 participant