Restructure Namada Transactions

[murisi]

Namada transactions are similar to executable files in that they contain executable code (the WASM) and initialized data (Transfer, Bond, Unbond, ...). Continuing the analogy, execution of Namada transactions consists of running the WASM code on the Namada VM with the initialized data being accessible. Therefore the techniques used to organize and design executable file formats may be applicable to Namada's transactions.

Current Approach

Before considering other executable file formats, it makes sense to describe the current approach we take:

• Outer transaction:
  • Signed data:
    • Unsigned data: Wrapper transaction:
      • Gas payment info
      • Fee payer info
      • Inner transaction hash over:
        • Hash(inner tx wasm_code)
        • Hash(inner_tx extra_data)
        • Inner_tx signed data
    • Sig: Wrapper transaction signature over:
      • Unsigned data
  • Inner tx: Encrypted inner transaction:
    • WASM code
    • Extra data
    • Signed data:
      • Unsigned data
      • Signature over:
        • Hash(wasm_code)
        • Hash(extra_data)
        • Unsigned data

Advantages

This approach is done in a way that allows:

• hardware constrained wallets to sign over only WASM code hashes and extra data hashes
• inner transactions to be fully encrypted after all wallet signing operations are concluded
• all signing operations to be done by a hardware wallet with one communication round
• inner and outer transactions to be signed by potentially different parties

Drawbacks

This approach as it's currently implemented works well enough, but it seems to have the following drawbacks:

• The nested treatment of transactions by the protocol means that VPs cannot access gas payment info due to wrapper and outer layers having been stripped
• The reuse of the Tx structure for both inner and outer transactions means that some of the structure's fields are redundant in either the inner/outer context
• The nested (de)serialization of transactions (into the data field) does not map nicely onto existing protocol message formats like protobufs
• The nested (de)serialization of transactions subverts the Rust type system by replacing structures witth byte vectors
• Full decryption and decoding of an entire is rather cumbersome as it necessarily involves deserializations of its byte vector subcomponents
• Conceptual overloading of the transaction concept (inner, outer, wrapper) makes discussions and reasoning about them slightly harder
• Removal of subsections of a transaction for consumption by certain consumers (like hardware constrained wallets) is cumbersome

Alternative Approach

In summary the above approach hits many goals but it comes at the cost of maintainability. Are there any ways of achieving the above objectives, but with reduced complexity? Adopting the approach of the COFF and ELF formats, a transaction could be reshaped to be a transaction header followed sequence of sections as follows:

• Transaction
  • Header:
    • Transaction format version info
    • Gas payment info
    • Fee payer info
    • Extra data section (pre-encryption) hash
    • WASM code section (pre-encryption) hash
  • Vector of sections, each section is one of the following:
    • Data section
      • Contains program defined information
      • Always sent to hardware wallets
    • Extra data section
      • Contains program defined information
      • Sending to hardware wallets optional
    • WASM code section
      • Contains executable instructions of a program
      • Sending to hardware wallets optional
    • Signature section
      • Target section (pre-encryption) hash
      • Signature over target section hash
      • Typically produced by hardware wallets
    • Proof of work section
      • Proof of work solution
      • Only for testnets
    • Encrypted section
      • The encryption of any of the above sections
      • Typically constructed after signing is complete
      • Everything other than header and its signatures can be encrypted

Proposed Process

The intented use would be for clients to construct an unsigned transaction, strip it down to a header followed by data sections only, send this stripped transaction to the wallet for signing, append the signature sections produced by the wallet to the unsigned transaction, then encrypt all sections that are not needed before DKG secret reconstruction, then send the result off to the protocol. It is understood that nodes will first decrypt all encrypted sections and replace them with their underlying plaintext section before continuing processing.

[tzemanovic]

I wholeheartedly welcome this change!

A note on eng. side - we have couple PRs that are likely to conflict with this, but I think they're all ready (release pending devnet):

• Replay protection #1017
• Tx ChainId #1106
• Tx expiration #1123

[Fraccaman]

@tzemanovic maybe multisig will also conflict with this