Benchmarking Bitcoin Script Evaluation for the Varops Budget (GSR)

This has led to the suggestion of adopting a generalized sigops budget, now termed as the varops budget. This new approach is encapsulated within a novel Tapscript leaf version, designed to preemptively set a budget for all operations before any enhancements are made to computationally intensive operations or other script limitations are adjusted. The varops budget is directly tied to the transaction weight, establishing a mechanism where 5,200 compute units are allocated for each weight unit of the transaction. This allocation takes into account various factors including the length of arguments and the nature of operations such as copying, comparing, moving, hashing, or arithmetic functions executed by each opcode.

Further elaboration on this proposal can be accessed through the Bitcoin Improvement Proposal (BIP) available on GitHub, which offers an in-depth view of the varops budget (view the BIP). Additionally, the communication underscores the critical need for benchmarking the execution times for signature validations against the proposed varops budget. This is to ensure that the script execution time remains within acceptable limits compared to the worst-case scenarios of signature validation times. To facilitate this, a prototype implementation has been shared with the community for testing and feedback (check out the GSR prototype), encouraging contributions towards refining and validating the proposed budgetary model.

The dialogue also touches upon concerns related to the complexity of block assembly, specifically highlighting the potential issues arising from managing both the new varops constraint alongside the original sigops constraint within the tarscript V2 code. This dual-constraint system could complicate the block assembly process, making it akin to solving an NP-hard packing problem due to the simultaneous necessity to adhere to two separate dimensions of constraint solving. In contrast, the Simplicity framework is mentioned as reutilizing the budget mechanism introduced in the initial version of tapscript, albeit with costs computed statically rather than dynamically, presenting a different approach to managing computational constraints within the blockchain's operational framework.