Add MaxVerificationGas

[erikzhang]

No description provided.

[shargon]

ConsensusPayload has 0_02000000 maybe we should unify these values.

[erikzhang]

ConsensusPayload doesn't pay, and it only do the simple signature verification.

[roman-khimov]

I think this value should be a part of the policy contract. We may see something on the mainnet that would suggest raising or lowering it, execution cost and GAS price could also change, so we're better be adaptive. And this value is a policy in its essence.

[erikzhang]

I don't think it will be changed often.

[shargon]

It's not a bad idea

[vncoelho]

I think so as well,better to be in Policy.

[erikzhang]

I don't think so. Even this value can be different for each node, it will not have much impact. Because it only effects verifications.

[vncoelho]

I see,Erik.
But are there bad aspects in moving it to Policy? In summary,I imagine that it has been good to have been moving parameters to the Native Policy.

[erikzhang]

We can't put everything into policy.

[vncoelho]

If we can run large scale applications perhaps we can include many things on the Blockchain Governance Smart Contract, Erik.
I understand that everything may be too much...aheuaheuaea But I still think it is a good practice to move parameters towards there.

[igormcoelho]

Does this small change already limits? Does it apply to all scripts or just verification?

[erikzhang]

Just verification.

[igormcoelho]

I mean, I don't see how this prevents execution... perhaps this PR is just to add this Max variable, and then it is used in near future to halt executions, right?

[igormcoelho]

Time and Space are two faces of the same creature. It's not just Einstein speaking for physics, but it also applies to computing.
GAS is an abstraction of time, in fact, computing time. By limiting execution by GAS, you limit time, and as computing power evolves, this value will need adjustments in time to remain "consistent".
By limiting execution via a turing-incomplete no-jump policy, you don't care about time, as scripts will mostly occupy space. Then you care more about space, which doesn't improve too much in time. In fact, space is typically the most significant problem of a blockchain, from a long-lasting perspective.

That said, this solution will fix the problem, from a time perspective, but we will still require other fixes for the space perspective (limiting transaction size), that is why I strongly prefer a beautiful turing-incomplete safe execution mode.

[igormcoelho]

If intention is to limit execution by gas, then this is the path to go. A MaxVerificationGas variable is desirable and necessary.
Although this value may change in the future, I agree that it doesn't affect much things, as persisted blocks will be kept persisted, and all verifications are assumed to be correct on the blockchain (no need to verify gas of accepted tx (IVerifiable entities).