Benchmarking Bitcoin Script Evaluation for the Varops Budget (GSR)

In an effort to address the concerns regarding denial-of-service attacks through excessive computational time and memory usage in Bitcoin script execution, a new proposal has been put forward. This involves the introduction of a generalized sigops budget, now referred to as the varops budget, within a new Tapscript leaf version. The goal here is to apply this budget across all operations before any computationally expensive operations are restored or other script limits are lifted. The varops budget is intricately linked to the transaction weight, allowing for a proportional allocation of compute units based on the size of the transaction. Specifically, the budget allocates 5,200 units per weight unit of the transaction.

The computation of the varops cost for each opcode varies, taking into account the length of its arguments and its specific action on the data, such as copying, comparing, moving, performing hashing, or executing arithmetic operations. Further details and insights into this proposal can be found in the Bitcoin Improvement Proposal (BIP) documented on GitHub (view the BIP).

To ensure the feasibility and efficiency of these proposed changes, a benchmark methodology was outlined. This methodology focuses on evaluating the script of block-sized scripts to identify the slowest possible script for validation. The benchmarks consider two primary limitations: size, capped at 4M weight units, and the varops budget, set at 20.8 billion compute units. The evaluation includes testing various scripts, including loops of simple operations and more complex arithmetic or hashing operations, to determine their performance relative to the constraints of size and varops budget.

Furthermore, the email highlights the current theoretical limit for signature operations within a block and the necessity to measure execution times for signature validation against the proposed varops budget. This comparison aims to ensure that script execution time under the varops budget does not exceed the worst-case scenario for signature validation time. To support this initiative, the community is encouraged to participate in running benchmarks using a prototype implementation available on GitHub (check out the GSR prototype). By compiling with benchmarks enabled and running the specified benchmark command, contributors can generate valuable data to help refine and validate the varops budget approach.