SIP-034: Dimension-Specific Tenure Extend Variants #236

jcnelson · 2025-10-16T01:44:49Z

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.

The purpose of this SIP is to make it so that cost-heavy transactions which otherwise execute quickly can be mined, regardless of how pessimistic the current cost model is.

This PR supersedes #234 since I can't push to #234's remote.

obycode · 2025-10-16T13:46:03Z

sips/sip-034/sip-034.md

+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.


Why this order? Could we swap runtime and read-count or was there a specific reason for this order?

No reason. I can swap them.

The database fields on a stacks api node are ordered in this way (alphabetic):

execution_cost_read_count
execution_cost_read_length
execution_cost_runtime
execution_cost_write_count
execution_cost_write_length

Sure, that's fine

Fixed in 97719e1

Could there be a scenario where it may be preferable to reset the count on more than 1 field?
i.e. reset on both of write-count and read-count?

from this table, it's apparent only that either all fields are reset, or one is reset only.

friedger · 2025-10-16T15:15:48Z

sips/sip-034/sip-034.md

+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.


The database fields on a stacks api node are ordered in this way (alphabetic):

execution_cost_read_count
execution_cost_read_length
execution_cost_runtime
execution_cost_write_count
execution_cost_write_length

friedger · 2025-10-16T15:19:51Z

sips/sip-034/sip-034.md

+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


How does this SIP affect the effectiveness of the coordination between signers and miners? Before there were only two options which are less likely to be disputed.

The SIP should address what happens if coordination fails, or why it is likely to improve the situation.

I'll add this to the SIP. The coordination would basically be the same as it is now -- right now, the signers signal to miners (and to each other) when they will accept a TenureExtend via the BlockResponseMetadata::tenure_extend_timestamp included within a BlockAcceptance message. Once enough signers have posted a timestamp that is in the past, the miner will create a TenureExtend transaction in their next block.

Signers internally decide what this timestamp will be based on how much "idle time" they have observed (i.e. time not processing block proposals). This ensures that the rate of block appends is low enough that a crashed signer (or new follower) can quickly catch up to the chain tip.

After this SIP is ratified, signers would similarly track notions of "idle time" for each of these cost dimensions, and share them amongst themselves and the miners. For example, they may require that the average rate of read I/O operations be beneath a certain threshold before they'll allow a miner to issue a read-count extension. This computation and sharing does not need to ship with the hard-fork since it is not consensus-breaking, but would be added shortly afterwards.

Added in 97719e1

sips/sip-034/sip-034.md

jcnelson · 2025-10-17T04:44:41Z

The reference implementation is being developed in this PR.

Technical CAB approval for SIP-034

add gov cab signoff for sip-034

314159265359879

I would say this is nearly ready for sign-off from the editors.

Correct some minor spelling/grammer issues
Add the "Reference implementation" section and References section
I think the Activation section could explain a bit better what it means to be a rider to the 033 (clarity 4) SIP.

314159265359879 · 2025-10-23T21:36:33Z

sips/sip-034/sip-034.md

+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_.


considers instead of consideres

spanish : )

Fixed in 8821768

314159265359879 · 2025-10-23T21:41:56Z

sips/sip-034/sip-034.md

+
+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.


Clearer: ...which dimension of the block budget is reset.

instead of "...a specific dimension of the block budget to reset.".

Fixed in 8821768

314159265359879 · 2025-10-23T21:49:29Z

sips/sip-034/sip-034.md

+
+# Introduction
+
+The Stacks network controls total runtime and I/O expenditure during Nakamoto tenures


...Nakamoto tenures, I think it makes sense to reference SIP021 here [1]: https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md#nakamoto-terminology

Fixed in 8821768

314159265359879 · 2025-10-23T22:02:43Z

sips/sip-034/sip-034.md

+# Activation
+
+This is intended as a rider SIP to SIP-033. If SIP-033 is ratified, then this
+SIP will also be ratified.


Let's add these two sections and references.

Reference implementation

stacks-network/stacks-core#6609

References

[1] SIP021 Nakamoto, Tenure definition: https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md#block-structure
[2] SIP021 Nakamoto, Block header wire format: https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md#block-structure
[3] SIP033 Clarity 4

Fixed in 8821768

314159265359879 · 2025-10-23T22:05:29Z

sips/sip-034/sip-034.md

+has been added are new values to represent the kind of tenure extension
+requested.
+
+# Activation


If activation criteria are redundant because this is a rider to SIP-033, that should be explicitly stated with some criteria or process for clarity.

Fixed in 8821768

314159265359879 · 2025-10-23T22:12:30Z

sips/sip-034/sip-034.md

+## Wire Formats
+
+The serialization of the `TenureChangePayload` will be a backwards-compatible extension of
+the existing SIP-021 serialization:


lets add a reference here [2] https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md#block-structure

Fixed in 8821768

aaronb-stacks and others added 2 commits October 15, 2025 20:18

initial sip-033 rider

bc34dc0

chore: add Related Work and some formatting

88656f1

jcnelson mentioned this pull request Oct 16, 2025

SIP-033 Rider: Dimension specific tenure extend variants #234

Closed

jcnelson added 2 commits October 15, 2025 21:45

chore: formatting

dd5997d

chore: add governance consideration

4177324

obycode reviewed Oct 16, 2025

View reviewed changes

friedger reviewed Oct 16, 2025

View reviewed changes

Hero-Gamer reviewed Oct 16, 2025

View reviewed changes

sips/sip-034/sip-034.md Show resolved Hide resolved

jcnelson mentioned this pull request Oct 17, 2025

Feat/sip034 stacks-network/stacks-core#6609

Merged

5 tasks

jcnelson and others added 7 commits October 17, 2025 01:09

chore: address SIP feedback

97719e1

Technical CAB approval for SIP-034

cb1b7aa

Merge pull request #239 from obycode/sip-034-tech-cab

a807a68

Technical CAB approval for SIP-034

docs: add gov cab sign-off to sip-034

991ef2a

Merge pull request #240 from stacksgov/docs/add-gov-cab-signoff

2629a15

add gov cab signoff for sip-034

chore: add sign-offs and advance to actiation-in-progress

6ae99ba

Merge remote-tracking branch 'origin/feat/sip034' into feat/sip034

80b224a

314159265359879 reviewed Oct 23, 2025

View reviewed changes

chore: address SIP editor feedback

8821768


		# Introduction

		The Stacks network controls total runtime and I/O expenditure during Nakamoto tenures

Uh oh!

SIP-034: Dimension-Specific Tenure Extend Variants #236

Are you sure you want to change the base?

SIP-034: Dimension-Specific Tenure Extend Variants #236

Uh oh!

Conversation

jcnelson commented Oct 16, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jcnelson commented Oct 17, 2025

Uh oh!

314159265359879 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Reference implementation

References

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants