|
| 1 | +--- |
| 2 | +simd: 'XXXX' |
| 3 | +title: Percisely budget builtin instruction units |
| 4 | +authors: |
| 5 | + - Tao Zhu (Anza) |
| 6 | +category: Standard/Meta |
| 7 | +type: Core |
| 8 | +status: Draft |
| 9 | +created: 2024-08-26 |
| 10 | +feature: |
| 11 | +supersedes: |
| 12 | +superseded-by: |
| 13 | +extends: |
| 14 | +--- |
| 15 | + |
| 16 | +## Summary |
| 17 | +oBuiltin instructions in the SVM consume their static DEFAULT_COMPUTE_UNITS from the compute budget during execution. These DEFAULT_COMPUTE_UNITS are also counted against block limits during the banking stage. However, historically, builtin instructions have been allocated DEFAULT_INSTRUCTION_COMPUTE_UNIT_LIMIT units of compute budget. This discrepancy between the allowed consumption and the actual usage tracked for block limits creates several issues, which are outlined below and need to be addressed. |
| 18 | + |
| 19 | + |
| 20 | +## Motivation |
| 21 | + |
| 22 | +Allocating DEFAULT_INSTRUCTION_COMPUTE_UNIT_LIMIT instead of the actual DEFAULT_COMPUTE_UNITS for builtin instructions distorts the tracking of transaction compute budgets. This can result in more expensive instructions being executed when they should fail due to exceeding the budget. As a consequence, the cost tracker may need to account for additional compute units towards block limits after transaction execution, potentially producing blocks that exceed those limits. |
| 23 | + |
| 24 | +Moreover, maintaining consistency in transaction costs between the banking stage and SVM would greatly simplify the code logic and make reasoning more straightforward. |
| 25 | + |
| 26 | +## Alternatives Considered |
| 27 | + |
| 28 | +One possible alternative approach would be to maintain the current allocation of compute budget for builtin instructions but add logic to the cost tracker to account for the discrepancy during tracking. However, this would add complexity and could introduce additional corner cases, potentially leading to more issues. |
| 29 | + |
| 30 | +## New Terminology |
| 31 | + |
| 32 | +None |
| 33 | + |
| 34 | +## Detailed Design |
| 35 | + |
| 36 | +1. compute budget allocates actual DEFAULT_COMPUTE_UNITS for builtin instructions, including for compute-budget-instructions. |
| 37 | + |
| 38 | +Currently if not explicitly requested, each instruction is allocated DEFAULT_INSTRUCTION_COMPUTE_UNIT_LIMIT, capped by transaction's MAX_COMPUTE_UNIT_LIMIT; except for compute-budget instructions - no units are allocated for them, historically. There are few scenarios this could lead to over pack blocks. |
| 39 | + |
| 40 | +[Example 1](https://github.com/anza-xyz/agave/pull/2746/files#diff-c6c8658338536afbf59d65e9f66b71460e7403119ca76e51dc9125e1719f4f52R13403-R13429): |
| 41 | +A transaction consist of a `Transfer` and a expensive non-builtin instruction; by expensive, let's say its actual execution take more than DEFAULT_INSTRUCTION_COMPUTE_UNIT_LIMIT. Because it over budgeted for `Transfer`, allows expensive ix to execute to completion, force adjust up |
| 42 | + |
| 43 | +[Example 2](https://github.com/anza-xyz/agave/pull/2746/files#diff-c6c8658338536afbf59d65e9f66b71460e7403119ca76e51dc9125e1719f4f52R13431-R13455): |
| 44 | +A builtin instruction that might CPIs into other instructions, it'd fail without explicitly request more CU. But it is not atm. |
| 45 | + |
| 46 | +2. cost model honors set_compute_unit_limits, even there is no user space instructions |
| 47 | + |
| 48 | +[Example 3](https://github.com/anza-xyz/agave/pull/2746/files#diff-c6c8658338536afbf59d65e9f66b71460e7403119ca76e51dc9125e1719f4f52R13457-R13484) |
| 49 | +cost model ignores explicitly requested CU due to all builtin instructions, it ended up to have adjust up, instead of normal adjust down. |
| 50 | + |
| 51 | +3. fail transaction before send sending for execution if set_compute_unit_limit sets an invalid value. |
| 52 | + |
| 53 | +[Example 4](https://github.com/anza-xyz/agave/pull/2746/files#diff-c6c8658338536afbf59d65e9f66b71460e7403119ca76e51dc9125e1719f4f52R13344-R13373): |
| 54 | +if explicitly request cu limit is invalid, eg. below all builtins on top level would require, or above MAX_COMPUTE_UNIT_LIMIT, tx can be failed during sanitization, save from sending to SVM for execution all together. |
| 55 | + |
| 56 | +## Impact |
| 57 | + |
| 58 | +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_limits to explicitly request the necessary budget for their transactions. |
| 59 | + |
| 60 | +## Security Considerations |
| 61 | + |
| 62 | +All clients should implement this proposal simultaneously to avoid breaking consensus. |
| 63 | + |
0 commit comments