Cap the number of transactions per block and the total size of operation and message bytes

[ma2bd]

Alternatively the maximum size of the argument of an operation or an outgoing message

Also relevant: the fuel per block

• [x] #2455
• [ ] #2456
• [ ] #2457

[afck]

As discussed the motivation for this is that there are several hard limits like gRPC message size, gRPC timeouts, memory, and database limitations.

All of these are covered if we:

• limit the size of executed blocks (including e.g. outgoing messages; not only the proposed block), and
• limit the time and memory required to execute a block. (Special case: oracles are only run on proposed but not on confirmed blocks; these could have different limits.)

The limits should be enforced as soon as possible: e.g. it's better if the client knows in advance how much can go into a block proposal so that it won't be too big, rather than first having to execute and serialize it to find that it exceeds the size limit. However, this is not always possible.

Objective measures are preferable, so either all or no validators accept a block. However, for oracles that's not possible in general, and for regular blocks that's okay. Even for fast blocks, a client just needs to be able to make a proposal where the chance of it exceeding any limits on any validator is negligible.

Execution: memory

Here we can have a single max_memory_for_execution, in bytes. This adds up:

• all simultaneously loaded contract instances (bytecode and memory), and
• all loaded parts of the chain state view.

(Loaded blobs probably don't need to be added, since they will either end up inside a contract instance's memory, or are bytecode themselves.)

Execution: time

Option 1: Fuel and constants

An objective measure that bounds execution time would be to generalize fuel and add up:

• The fuel consumed by Wasm execution,
• some constants for system operations and messages,
• some constants for the different kinds of oracles, and
• possibly constants for overhead, e.g. a fixed value for each transaction.

Option 2: Wall-clock time

Easier to implement would be to bound the wall-clock time required to execute a block. If the validators refuse to sign a block proposal if it takes longer than e.g. 20 seconds to execute, a client that executed its proposal in 1 second can still be confident that it will get accepted.

Block size

We will add a single max_executed_block_size in bytes. This is tracked during block execution by adding up bcs::serialized_size for all new outgoing messages, oracle responses etc.