SIP-034: Dimension-Specific Tenure Extend Variants

sips/sip-034/sip-034.md

@@ -0,0 +1,138 @@
+# Preamble
+
+SIP Number: 034
+
+Title: Dimension-Specific Tenure Extend Variants 
+
+Author(s):
+
+- Aaron Blankstein <[email protected]>
+- Jude Nelson <[email protected]>
+
+Status: Draft
+
+Consideration: Technical, Governance
+
+Type: Consensus
+
+Layer: Consensus (hard fork)
+
+Created: 2025-10-15
+
+License: CC0-1.0
+
+# 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 a specific 
+dimension of the block budget to reset.
+
+# Copyright
+
+This SIP is made available under the terms of the CC0 (Creative Commons Zero)
+license, available at https://opensource.org/licenses/CC0-1.0. This SIP’s
+copyright is held by the Stacks Open Internet Foundation.
+
+# Introduction
+
+The Stacks network controls total runtime and I/O expenditure during Nakamoto tenures
+via a total tenure budget. 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
+
+The serialization of the `TenureChangePayload` will be a backwards-compatible extension of
+the existing SIP-021 serialization:
+
+```
+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           runtime budget is reset.
+0x04 indicates Extend           read-length budget is reset.
+0x05 indicates Extend           write-count budget is reset.
+0x06 indicates Extend           write-length budget is reset.
+```
+
+# 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 consideres 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. If SIP-033 is ratified, then this
+SIP will also be ratified.