Support batched transactions

[murisi]

Currently the Ledger app is only able to display batch Txs containing only one transaction. This is currently enforced here:

ledger-namada/app/src/parser_impl_txn.c

Line 983 in acb1d29

// Only singleton batches are supported currently

where the app asserts that it will only read exactly one TxCommitments object. A TxCommitments object contains a code_hash, data_hash, and a memo_hash, and these fields are subsequently read at

ledger-namada/app/src/parser_impl_txn.c

Lines 988 to 998 in acb1d29

	// Code hash
	v->transaction.header.codeHash.len = HASH_LEN;
	CHECK_ERROR(readBytes(ctx, &v->transaction.header.codeHash.ptr, v->transaction.header.codeHash.len))
	// Data hash
	v->transaction.header.dataHash.len = HASH_LEN;
	CHECK_ERROR(readBytes(ctx, &v->transaction.header.dataHash.ptr, v->transaction.header.dataHash.len))
	// Memo hash
	v->transaction.header.memoHash.len = HASH_LEN;
	CHECK_ERROR(readBytes(ctx, &v->transaction.header.memoHash.ptr, v->transaction.header.memoHash.len))

.

Would it be possible to generalize the Namada Ledger app to support printing and signing batch Txs containing more than one transaction? Supporting this would be useful because our CLI batches many transaction types with a Reveal Public Key transaction (since the latter is often a prerequisite for them). This feature would also be useful in the context of staking commands where Namada hardware wallet users are currently having to sequentially sign 10 transactions instead of just 1 batched Tx containing 10 inner transactions.

At a high level we want the parser to now parse a variable number of inner transactions instead of 1. Concretely, this means the parser should support reading a variable number (as specified by

ledger-namada/app/src/parser_impl_txn.c

Line 981 in acb1d29

// Batch length

) of TxCommitments objects.

Secondly, the Tx printer should support batched transactions by printing out each inner transaction in sequence. I.e. if the header contains a batch/vector of TxCommitments [a, b, c, d, e], then the future batch printer should print what the current printer would print had the batch just been the singleton [a], followed by what would have been printed for just [b], and so on until [e]. And then end this all with a single APPROVE and a single REJECT button. (So for the case of a batched Tx containing exactly 1 inner transaction, the Tx printer should yield exactly the same outputs as it currently does.)

Thirdly, the hardware wallet should sign/cover over all the inner transactions simultaneously. So more concretely, the inner signature for a batch should be over a set of hashes that is the union of the set of hashes currently signed over by the inner signature for [a], [b], ..., [e] separately. And the wrapper signature for a batch should analogously cover over the union of hashes the wrapper signatures for [a], [b], ..., [e] would have covered separately. I.e. we should always get one inner signature and one wrapper signature for a batched Tx regardless of how many inner transactions it has. (So for the case of a batched Tx containing exactly 1 inner transaction, the inner and wrapper and signatures should essentially be the same as what is currently produced.)

Please find attached some test vectors for this functionality: batched_debugs.txt.gz and batched_testvectors.json . Please let me know whether further information is required. Thanks.