Proposing to update the tx_transfer wasm on-chain.
There is a known issue previously reported by a community member in which a large enough batch transfer submitted on-chain will consume and cost lots of gas but slow down block processing of a node. This proposal limits the number of sources + targets in such a batch transaction to 20 in order to prevent such transactions from being processed on-chain.
The new WASM has been deployed and tested on Housefire testnet as Proposal #35.
The code used to generate the WASM for the proposal that was placed on Housefire testnet and that will be used for mainnet can be found here. The new tx_transfer wasm file included in the proposal and to be written to the Namada storage was generated from namada#4659 and can be specifically found in the CI artifacts from here. This is the same transfer logic that is present in the new namada release v101.1.1.
In the opinion of Heliax, it is important to update this wasm and vote this proposal through before beginning Phase 5.
Building update_tx_transfer.wasm from commit 390cf67 using earthly +build: d915550a5fae3dba36feb204f03799d9690a0512b0cdf2a7b833a7829e18758d
Result: hashes match
New tx_transfer code
New transaction hash in proposal code: 9a950b45d233c8f6fabfa5c473800c182f7666fe0c35c1a612f66a5f094758fe
CI Artifact contains: tx_transfer.9a950b45d233c8f6fabfa5c473800c182f7666fe0c35c1a612f66a5f094758fe.wasm
Result: hashes match
@brentstone how can I easily see what the old tx hash is for the current tx_transfer? To verify whether the correct old code is getting replaced? Then I could also add that to this ‘tiny verification process’.
@Rigorous, you’d likely want a more thorough audit, huh . Automating this all (excluding actual code auditing) should be possible though.
@Rigorous, you’d likely want a more thorough audit, huh . Automating this all (excluding actual code auditing) should be possible though.
Automation will make it less cumbersome to verify that the embedded WASM is equivalent to the one generated by Github CI, but yes, it does not actually tell us the code itself is safe. But at least we can trust that the code has been written and reviewed by repository contributors (Heliax), and they are of course unlikely to blow up the protocol intentionally.
@hjg888 The effective real limit of such a transactions is like ~250 targets so such a single tx as you suggest is already wildly unrealistic. There are plenty of ways around this though in case such a situation arose in the future. We are also working on a more proper solution in the meantime to limit the gas cost of such large transfers in the protocol, which currently suffers from some inefficient operations. This current solution is moreso temporary in the short-term and can be changed later.
@zenodeapp the current (old) tx hash is hard-coded into the Rust proposal code here.
For visibility, the hash to be overwritten is ef687f96ec919f5da2e90f125a2800f198a06bcd609a37e5a9ec90d442e32239.
A couple ways you can see that this is the hash that is currently on-chain:
Query a node with namadac query-protocol-parameters. If you look at the Transactions allowlist, then the hash will be included in that list.
Dump the DB from your node by stopping it and running namadan ledger dump-db, which will give you a file db_dump_<block-height>.toml. Then grep for tx_transfer and you will see a storage key with a value that equals the current hash that will be overwritten by the proposal.
happy we have such community members! TuDudes support this 
. Automating this all (excluding actual code auditing) should be possible though.