SIMD-0170

Reserve minimal CUs for builtins

Author: Tao Zhu (Anza) · Category: Core Protocol GitHub →

Feature Gate Status

Mainnet Active E758
Testnet Active E737
Devnet Active E842

C9oAhLxDBm3ssWtJx1yBGzPY55r2rArHmN1pbQn6HogH

TL;DR

When transactions do not request a specific compute unit limit, the Solana runtime conservatively allocates 200,000 compute units for each tx-level instruction (excluding compute budget instructions) in the transaction's compute budget. Since builtin program instructions consume far less than 200k compute units, the runtime will be modified to only allocate 3,000 compute units in the transaction compute budget for each of these instructions.

Summary

When transactions do not request a specific compute unit limit, the Solana runtime conservatively allocates 200,000 compute units for each tx-level instruction (excluding compute budget instructions) in the transaction's compute budget. Since builtin program instructions consume far less than 200k compute units, the runtime will be modified to only allocate 3,000 compute units in the transaction compute budget for each of these instructions.

Motivation

When allocating the transaction compute budget for transactions which don't specify a specific compute unit limit, the Solana runtime over-allocates the number of compute units needed for executing builtin programs which have a small (mostly) static execution compute unit cost. The runtime will only release the over-allocated compute units from the block cost tracker when transaction execution finishes and the actual consume compute units is known. Over-allocating CUs for builtin program instructions reduces block density, lowers network throughput, and can degrade block producer performance by causing repeated transaction retries (due to repeatedly over allocating cu's and then releasing them after execution). Avoiding excessive CU allocation is critical for maximizing block efficiency and minimizing network delays.

Key Changes

  • Stake11111111111111111111111111111111111111
  • Config1111111111111111111111111111111111111
  • Vote111111111111111111111111111111111111111
  • 11111111111111111111111111111111
  • ComputeBudget111111111111111111111111111111
  • AddressLookupTab1e1111111111111111111111111
  • BPFLoaderUpgradeab1e11111111111111111111111
  • BPFLoader1111111111111111111111111111111111
  • BPFLoader2111111111111111111111111111111111
  • LoaderV411111111111111111111111111111111111
  • KeccakSecp256k11111111111111111111111111111
  • Ed25519SigVerify111111111111111111111111111

Impact

Users who previously relied on including builtin instructions, instead of explicitly setting compute-unit limits, to allocate budget for their transactions may experience an increase in transaction failures. To avoid this, users are encouraged to use set_compute_unit_limit to explicitly request the necessary budget for their transactions. If those impacted users have issues fitting in the set compute unit limit instruction into their transactions due to tx data size limits, they can also migrate to using address lookup tables to fit in the compute budget instruction call.

Security Considerations

Both Agave and FD clients should implement this proposal to avoid breaking consensus.