SIP-034: Dimension-Specific Tenure Extend Variants

considerations/minutes/technical-cab/2025-10-17-sip-034.md

@@ -0,0 +1,57 @@
+# Technical CAB Minutes
+
+## Meeting Information
+
+**Location:** Discord (async)
+
+**Recorded:** No
+
+**Date:**
+
+- Oct 17th, 2025
+
+**Time:** n/a
+
+**Attendees:**
+
+- Aaron Blankstein
+- Brice Dobry
+- j2p2
+- Friedger
+- Radu
+- Setzeus
+
+**Topic(s):**
+
+- [SIP-034: Dimension-Specific Tenure Extend Variants](https://github.com/stacksgov/sips/pull/236)
+
+**Materials**:
+
+- [SIP-034: Dimension-Specific Tenure Extend Variants](https://github.com/stacksgov/sips/pull/236)
+- [Reference implementation](https://github.com/stacks-network/stacks-core/pull/6609)
+
+## 2025-10-15 Meeting Notes
+
+Note: This vote was urgently needed to ensure it can proceed together with
+SIP-033. The current chair, Jesse Wiley, is unavailable for this vote, so Brice
+Dobry is acting chair for this vote.
+
+The Technical CAB reviewed SIP-034 and the supporting materials, and concluded
+that this change is necessary to support the ecosystem.
+
+## Vote Outcome(s)
+
+| Name             | Vote    |
+| ---------------- | ------- |
+| Aaron Blankstein | abstain |
+| Brice Dobry      | yes     |
+| Friedger         | yes     |
+| j2p2             | yes     |
+| Setzeus          | yes     |
+| Radu             | yes     |
+
+_Note_ Aaron Blankstein is the author of SIP-034, as such he abstained from
+voting.
+
+The Technical CAB approves SIP-034 with 5 yes votes and 1 abstention by the
+author.

sips/sip-034/sip-034.md

@@ -0,0 +1,184 @@
+# 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
+
+Sign-off:
+- Brice Dobry <[email protected]>, Acting Chair, Technical CAB
+- Jason Schrader <[email protected]>, Chairperson, Governance CAB
+
+Discussions-To: 
+* SIP pull request: https://github.com/stacksgov/sips/pull/236
+* SIP reference implementation: https://github.com/stacks-network/stacks-core/pull/6609
+
+# 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
+
+## Wire Formats
+
+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           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 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.