Skip to content

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

@tdelabro

Description

@tdelabro

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions