HAL-01: Missing Maximum Size Validation

[fmiguelgarcia]

Description

This includes an E2E test to ensure that failed_send_message transactions is bounded. It reaches the maximum number of failed vector::send_message transactions per block, so we can determine the maximum number of integers used by MemeoryTemporaryStorage. We use the minimum size send_message transaction possible as an ArbitraryMessage and FungibleToken. In order to get that minimum size, and produce a maximum number of failed TXs, the parameters of the call are:

• message: an ArbitraryMessage with empty data.,
• to: Bob's address,
• domain: It is just 0 (invalid domain), forcing the TX fail.

Having that, the maximum number of TXs per block is just 136, filling the 86% of the block weight. That generates a post inherent TX failed_send_message of 136 items (Compact<u32>) with an encoded size of `432 bytes``, and an extra block weight of 12M (around 0.62 % of total block).

In Summary,

The worst case means, *`136 size_of ~= 544 bytesextra memory requirements per block**. The impact of this post inherent TX **could be up to0.62%` of the total block weight**. Keep in mind that transactions from regular users could fill up to 85% of the block.

Checklist

• [x] I have performed a self-review of my own code.
• [X] The tests pass successfully with cargo test.
• [X] The code was formatted with cargo fmt.
• [X] The code compiles with no new warnings with cargo build --release and cargo build --release --features runtime-benchmarks.
• [X] The code has no new warnings when using cargo clippy.

[ToufeeqP]

maximum number of TXs per block is just 136

Fyi, currently we've reduced the block capacity from 5 seconds to 2 seconds when we switch back to 5 seconds this will increase