What I can suggest at this point is that we can implement some sort of backoff mechanism to reduce the amount of transactions in a block in such cases.

This might not help because even single transaction in theory can block consensus.

From discussion we had with @mversic before:

As i see problem right now we have two groups of parameters which are fighting with each other.
Like f(tx_in_block, max_isi_in_tx, wasm_limit) = derived_commit_time_limit and when this derived_commit_time_limit is higher than commit_time_limit in config we are in trouble.

Another idea was to have backoff mechanism for commit_time_limit so it increase with every view change index.
Eventually it going to be height enough to commit block.

But this might have some other concerns:

• like if at some high view change any node in validation set going to crash peers have to wait for significant amount of time before next view change index

What I can suggest at this point is that we can implement some sort of backoff mechanism to reduce the amount of transactions in a block in such cases.

This might not help because even single transaction in theory can block consensus.

yes, but you can also define max_instructions or fuel limits to reject those

yes, but you can also define max_instructions or fuel limits to reject those

i see, we just need to make sure that consensus commit_time_limit is large enough to produce block with this single transaction given limits on fuel and max_instructions.

A final important note is that blocks themselves are bounded in size. Each block has a target size of 15 million gas but the size of blocks will increase or decrease in accordance with network demands, up until the block limit of 30 million gas (2x target block size). The total amount of gas expended by all transactions in the block must be less than the block gas limit. This is important because it ensures that blocks can’t be arbitrarily large. If blocks could be arbitrarily large, then less performant full nodes would gradually stop being able to keep up with the network due to space and speed requirements. The larger the block, the greater the computing power required to process them in time for the next slot. This is a centralizing force, which is resisted by capping block sizes.

Looking at etherium: they add per block gas limit (link).

Our blocks have kinda have such limit as well, but it may be harder to derive because it's based on limit of transactions per block and limits per transaction.

I believe we should just introduce TooComplex transaction reject reason for cases where it takes more time to produce a block (with even such the only one included) than it's configured. I'm not sure how transactions are getting selected for the block proposal but in this case it seems those should be picked one by one from the queue. Again, not sure about performance implications. Alternatively there might be a 'prepick' batch with as many as possible to be included for a potential block. The rest from which are going to be returned to the queue if not included to the block.

Though in that case we must get rid of the cases where permission validation takes enormously much time (like in the scenario I referred to previously trying to unregister an entity) first so that even a couple of little instructions get processed for a long time.

I believe we should just introduce TooComplex transaction reject reason for cases where it takes more time to produce a block (with even such the only one included) than it's configured.

This may be problematic because different peers might have different processing power and if someone claims that transaction is TooComplex, but other nodes execute it without a problem or vice versa.

I believe we should just introduce TooComplex transaction reject reason for cases where it takes more time to produce a block (with even such the only one included) than it's configured.

This may be problematic because different peers might have different processing power and if someone claims that transaction is TooComplex, but other nodes execute it without a problem or vice versa.

In that case the complexity is to become tied to fuel and not the time limit/max instructions then (for both blocks and transactions)? Should that be enough to resolve the prolem?

In that case the complexity is to become tied to fuel and not the time limit/max instructions then

Tying to fuel might be tricky because for transactions/triggers we have wasm and isi execution mode, so we would need some way to measure amount of fuel each isi cost.
And since iroha isi is not very simple there cost may very a lot: e.g. unregistering domain delete all acounts within this domain. So the cost depends on amount of accounts.

Additionally it's not clear how to measure cost of smart-contract because they consume wasm fuel and as well execute instructions.
Should they be charged for burning wasm fuel and executing of instructions?

On it's own there is nothing wrong with limiting transaction by amount of instructions because despite time this limit does not depend on processing power of node.

But we can't use it to limit smart-contracts because user can loop forever inside transaction never calling any iroha isi.

Should that be enough to resolve the prolem?

I'm still not sure, additional research is required.
Because we still need to ensure that given block limit commit time is high enough that block is committed within given deadline.

way to measure amount of fuel each isi cost

I guess that's what we will inevitably do for the public mode anyway. Some references on Ethereum and Substrate:
https://github.com/crytic/evm-opcodes (Ethereum basic operations gas cost)
https://github.com/paritytech/substrate/blob/master/frame/transaction-payment/src/lib.rs (actual fuel calculation)
https://github.com/paritytech/substrate/blob/master/frame/identity/src/weights.rs (Substrate weights initialization example)

Should they be charged for burning wasm fuel and executing of instructions?

definitely both, right