Benchmarking Bitcoin Script Evaluation for the Varops Budget (GSR)

In the realm of blockchain development, particularly within Bitcoin's scripting enhancements, there is an ongoing discussion regarding the complexity introduced by new versions of script. The conversation centers on the challenges posed by adding multiple dimensions of constraint to block assembly, which risks transforming it into an NP-hard packing problem. This issue is highlighted in the context of the transition from tapscript (V1) to tarscript (V2), where the latter introduces a novel varops constraint alongside the pre-existing sigops constraint. Such dual constraints complicate the process, diverging from the simplicity sought in cryptographic scripting languages.

The dialogue references Simplicity, another scripting language for blockchain, as a counterpoint to the approach taken in tarscript V2. Simplicity adheres to a single dimension of constraint solving by employing a unified budget mechanism for its cost calculations. This method, inherited from tapscript V1, contrasts with tarscript V2 by opting for static rather than dynamic computation of costs. The preference for static computation is underscored by its potential for simplification and predictability in contrast to the complexities introduced by dynamic runtime evaluation.

This ongoing debate underscores a critical crossroads in blockchain development, emphasizing the trade-offs between advancing functionality through additional constraints and maintaining computational simplicity to avoid NP-hard scenarios in block assembly. The discourse not only highlights the technical nuances of developing scripting languages like tarscript and Simplicity but also reflects broader considerations in the optimization of blockchain protocols for efficiency and scalability.