Unfortunately it seems that this implementation won’t run properly due to the new number type used in GSR, we use an unsigned arbitrary length integer instead of the current signed 32bit int. The new stack limits and OP_MUL should also drastically reduce the number of transactions needed and probably also reduce their validation time.
We benchmark a large collection of possible scripts and extract the worst case as the slowest execution time, this does not mean that it will be the new average, the 15 opcodes were disabled due to paranoia of nodes being DDoSed, as in an attacker trying to construct a block that causes memory overflows or extremely slow execution times.
As seen in the benchmark, almost every script is much faster and only uses a small fraction of the varops budget. But we are interested in the worst cases and those worst cases are only reached when hashing (which you can do right now without any restrictions and produce blocks much slower than 100ms) and arithmetic on very large numbers.
I don’t think we can or should predict what the average block with GSR will look like, we only want to make sure there is a reasonable upper bound for script validation times, the purpose of the benchmark is to establish this upper bound.
If 80,000 sig ops is too slow, why was it preserved in Taproot/BIP340-342? Varops really just wants to generalize this limit to all operations, without introducing a new worst case script.