zadao.aiDimension-Specific Tenure Extend Variants
By Aaron Blankstein, Jude Nelson
- Idea
- Draft
- Accepted
- CAB vote
- Recommended
- Activation
- Ratified
Abstract
This SIP details a rider to SIP-033, including a new variant of the tenure change control transaction. This variant allows the tenure change to specify which dimension of the block budget to reset.
Introduction
The Stacks network controls total runtime and I/O expenditure during Nakamoto tenures
via a total tenure budget [1]. Costs are tracked using worst-case estimates of the actual
runtime or I/O expended to evaluate a given Clarity operation. In Nakamoto rules,
signers and miners may coordinate to include a TenureChange transaction in the miner's
next block which extends the current tenure by resetting the counters for its ongoing
runtime and I/O costs.
This mechanism allows the tenure's overall budget to grow, for example, there has been a long delay between Bitcoin blocks. However, if the assessed Clarity costs are much higher than the actual runtime or I/O characteristics of the executed blocks (i.e., the actual block runtime is much faster than the worst-case scenario around which costs are modeled), signers and miners have limited ability to address this. This is because a mismatch in one dimension (e.g., read-count) should not result in another dimension being reset (e.g., write-count). Resetting all dimensions of the block budget when only one was misaligned would open the network up to denial of service (unintentional or otherwise).
To address these concerns, this SIP proposes to add a new variant to TenureChange transactions
which allows them to specify which cost dimension should be reset (or all of them).
Specification
Wire Formats
The serialization of the TenureChangePayload will be a backwards-compatible extension of
the existing SIP-021 serialization [2]:
tenure consensus hash: 20 bytes
previous tenure consensus hash: 20 bytes
burn view consensus hash: 20 bytes
previous tenure end: 32 bytes
previous tenure blocks: 4 bytes, big-endian
cause: 1 byte
pubkey hash 20 bytes
The cause field serializes the new variant in a backwards compatible scheme:
0x00 indicates NewBlockFound whole budget is reset.
0x01 indicates Extend whole budget is reset.
0x02 indicates Extend read-count budget is reset.
0x03 indicates Extend read-length budget is reset.
0x04 indicates Extend runtime budget is reset.
0x05 indicates Extend write-count budget is reset.
0x06 indicates Extend write-length budget is reset.
Values 0x00 and 0x01 are used today to indicate whether or not the
TenureChangePayload represents a change to a new tenure or the extension
of the ongoing tenure. No other values are accepted today.
This SIP proposes accepting values 0x02 through 0x06 for cause, and taking
the above actions to reset a specific cost dimension's budget.
Coordination Between Miners and Signers
This SIP only requires Stacks nodes to accept dimension-specific tenure budget
resets via these new TenureChangePayload transaction payloads. It does
not mandate a strategy for coordinating with miners to determine when
dimension-specific resets might be granted. However, a brief description of how
this might be achieved is provided here, for informational purposes.
In the reference implementation today, signers determine how often a miner can submit a tenure-extension transaction based on how much "idle time" each signer has observed in its node. This is the amount of time the node spends doing work besides processing block proposals. Signers individually choose an amount of idle time that must pass on their node before they will approve a tenure extension. By choosing larger idle times, signers ensure that the chain does not grow so quickly that it prevents miners and signers from catching up to and staying at the chain tip. Signers advertize the earliest UNIX epoch time at which they will accept a tenure extension as part of their block proposal acknowledgements to the miner.
This behavior is not consensus-critical, and is outside the scope of this SIP, but is worth mentioning because it informs how future coordination between miners and signers could work. Signers may adopt similar notions of idle time for each budget dimension in order to determine when they will accept a dimension-specific tenure budget reset. For example, a signer may measure the amount of time the node spends not performing read I/O on the chainstate database ("read I/O idle time") to determine when they will issue a read-count reset.
This SIP does not require a coordination strategy to be implemented before its activation.
Related Work
The Stacks blockchain measures a transaction's resource expenditures along five dimensions: the number or indexed reads ("read count"), the number of bytes read ("read length"), the number of indexed writes ("write count"), the number of bytes written ("write length"), and the amount of CPU used ("runtime"). Each miner is granted a budget of each measured resource to consume over the duration of their tenure. Each Clarity operation consumes one or more of these resources. A Nakamoto block is only valid if the additional resources its transactions consume do not exceed the tenure's limits on each of these resources.
The cost measurements for each Clarity operation were chosen to ensure that a Stacks node would be able to reprocess the tenure much more quickly than it is produced. If this were not the case, then Stacks nodes would be unable to catch up to the chain tip. This is particularly dangerous for Stacks signers, which may go offline for mundane reasons; signers must be able to quickly catch up to the rest of the signer network.
An alternative approach considered to this SIP was to produce a more accurate measurement of how much of each resource each Clarity operation consumes. The current model is pessimistic, and assumes a worst-case resource consumption. It also does not consider the size of the value of the data being processed; it instead considers the worst-case size allowed by the data's type. We believe that the approach in this SIP is superior building a more accurate model (but does not negate a new model's usefulness) because it allows signers to determine whether or not to allocate more resources to an ongoing tenure based on their real-world observation of resource consumption when evaluating block proposals. As long as the signers observe that resource consumption in each dimension is below an acceptable threshold, such that a crashed signer could quickly catch back up, then the signers can safely extend individual resource budgets regardless of the current model's pessimism This in turn allows signers to grow the chain's tenure budgets in response to acquiring better harder, or running upgraded nodes with better block-processing algorithms.
A future SIP may increase the granularity of tenure extensions. For example, the signers may be able to choose the amount of each resource to extend. This SIP does not call for this in order to speed its implementation. Furthermore, signers have the option to enforce a more granular resource consumption rate without a hard fork -- they announce to miners their target resource consumption rates, and reject miner blocks that consume resources at higher rate than their target rate.
Backwards Compatibility
Per the Specification section above, the wire formats for TenureChange
transactions are backwards compatible with the existing wire format. All that
has been added are new values to represent the kind of tenure extension
requested.
Activation
This is intended as a rider SIP to SIP-033 [3]. If SIP-033 is ratified, then this SIP will also be ratified. Similarly, if SIP-033 is not ratified, then this SIP will not be ratified. No further criteria are needed for this SIP.