fix: ensure ExecutionStack cannot exceed MAX_STACK_SIZE

[sdbondi]

• Check that ExecutionStack does not exceed MAX_STACK_SIZE (255) when decoding from bytes
• Add size() to tari script required to limit the maximum number of script elements in transaction and block validation

[CjS77]

LGTM except for the off-by-one

[sdbondi]

@CjS77 What are your thoughts on limiting the number of ops per script in tari crypto?
Looking at bitcoin, there is a 10000 byte limit on the script byte size, a limit of 520 items on the input stack, 1000 limit on items pushed by a script on the stack (script.h). Perhaps we should introduce similar limits? Alternatively we can add these limits to the base node validators.

[CjS77]

We have an implicit limit on ops since we limit the script size, don't we?

Edit: It seems we don't 😱 though I could have sworn I put a limit on the serialised script size in the consensus validation code. Either I forgot, or it's been removed; I don't feel like digging right now.

So we absolutely must put a limit on the script size. I would do it in the consensus code since we may want different rules for different chains. Testnet and Mainnet should match up; but experimental chains like Igor may need a different limit.

I would put the limit on the serialized length rather than straight opcode count because it's the serialized script that takes up precious space in the block pre-pruning.

Another reason not use a naiive opcode count is that opcodes are far from equal. An OP_PUSH_ZERO and a OP_CHECK_MULTI_SIG have vastly different CPU cycle costs.

So: serialized limit mitigates "block stuffing spam attacks", and mitigates expensive opcode attacks to some degree.

I don't know what the script limit should be, but it should be large enough to allow reasonable complicated smart contracts, but small enough to prevent block stuffing.

2048 bytes might be a good starting point and see whether this is too restrictive.

Next thing to look at is, What kind of expensive scripts can I write that fit in this limit? Hashes and sig checks are the most expensive operations, so we could run some benchmarks to test where performance starts to affect consensus.

Multisigs have a self-brake on them because we require the pubkeys to be part of the script, and not just pop them off the stack. So you can't just slap up 2000 multisig opcodes. The maximum would be m of 7 with a 2048 byte limit.

[sdbondi]

We currently don't impose a byte limit on the script in consensus, but makes sense to do it in validation rather than a hard coded limit in tari_crypto. 👍

[CjS77]

We currently don't impose a byte limit on the script in consensus, but makes sense to do it in validation rather than a hard coded limit in tari_crypto. 👍

Agree. I was editing my last comment when you posted this.