Benchmarking Bitcoin Script Evaluation for the Varops Budget (Great Script Restoration)

The exploration of the capabilities enabled by new opcodes in Bitcoin's scripting language, particularly through the implementation of zero-knowledge proofs (ZKPs) as illustrated by the OP_CAT based ZKP verifier, presents a significant shift in what is computationally feasible on the blockchain. A detailed analysis reveals that implementing such ZKPs could involve around 223,000 operations per script, with a diverse breakdown including 30,000 additions or duplications, 20,000 conditional statements, and a small number of more complex operations like concatenation and hash functions. This complexity raises questions about the practicality of these scripts given the current computational models and the introduction of new data types and stack limits.

The transition to using unsigned arbitrary-length integers from signed 32-bit integers, while expanding the potential for more complex and varied transactions, introduces compatibility issues with existing implementations. Furthermore, enhancements such as OP_MUL and revised stack limits could streamline transaction processing and validation times significantly. However, the emphasis on benchmarking against worst-case scenarios rather than average use cases might not accurately reflect real-world usage patterns. Such an approach suggests a cautious stance towards network security concerns, particularly the risk of Distributed Denial of Service (DDoS) attacks via crafted transactions that lead to memory overflow or excessively slow execution times.

Despite these advancements, there remains uncertainty regarding the average computational load that future blocks will carry, especially with the generalized operation limits introduced by varops aiming to mitigate the risk of introducing new bottlenecks. The goal of establishing benchmarks, therefore, is not to predict regular transaction times but to ensure a reasonable upper limit on script validation times, safeguarding against the potential for abuse while accommodating a wide range of transaction types. This consideration reflects a broader strategy within Bitcoin development to balance innovation with network integrity and user safety.