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

Should the signature field really be part of the Transaction types? #223

Open
tdelabro opened this issue Apr 3, 2024 · 0 comments
Open

Comments

@tdelabro
Copy link
Contributor

tdelabro commented Apr 3, 2024

If I want to create a transaction right now here is the flow:

    let mut tx = DeclareTransactionV0V1 {
        max_fee,
        signature: Default::default(),
        nonce,
        class_hash,
        sender_address,
    };
    let tx_hash = tx.compute_hash();
    tx.signature = sign_tx_hash(tx_hash);

This flow feels really bad because I start by building a tx with a dummy value for signature, use it, and then later replace this dummy value with the actual one.
I also have to create my tx as mutable.

Overall this introduces a lot of room for errors because the same type is actually used to represent two different types: Signed and NonSigned transactions. And for one of those, it adds a non-used field.
A good way to solve this would be the introduction of a SignedTransaction type:

struct SignedTransaction<T: StarknetTransaction> {
  tx: T,
  signature: TransactionSignature,
}

and maybe a trait

trait TransactionSigner<T: StarknetTransaction> {
  fn sign_transaction(transaction: T) -> SignedTransaction<T>;
}

It would then become really easy for the user to implement some signature scheme, key management, etc in a way that is not error-proof and feels good to use.

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