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
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions