You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
Advantages
This approach is done in a way that allows:
Drawbacks
This approach as it's currently implemented works well enough, but it seems to have the following drawbacks:
Tx
structure for both inner and outer transactions means that some of the structure's fields are redundant in either the inner/outer contextdata
field) does not map nicely onto existing protocol message formats like protobufsAlternative 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:
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.
The text was updated successfully, but these errors were encountered: