From e40c5aa0e2a408f692a2b8e91f3b5862390e0399 Mon Sep 17 00:00:00 2001 From: Jeff Bencin Date: Thu, 5 Dec 2024 17:34:05 -0500 Subject: [PATCH 1/2] First draft of SIP to correct `burn-block-height` keyword --- ...p-03x-fix-burn-block-height-in-at-block.md | 118 ++++++++++++++++++ 1 file changed, 118 insertions(+) create mode 100644 sips/sip-03x/sip-03x-fix-burn-block-height-in-at-block.md diff --git a/sips/sip-03x/sip-03x-fix-burn-block-height-in-at-block.md b/sips/sip-03x/sip-03x-fix-burn-block-height-in-at-block.md new file mode 100644 index 00000000..ae6cb3d3 --- /dev/null +++ b/sips/sip-03x/sip-03x-fix-burn-block-height-in-at-block.md @@ -0,0 +1,118 @@ +# Preamble + +SIP Number: 03x + +Title: Fix `bburn-block-height` in `at-block` + +Authors: Jeff Bencin + +Consideration: Technical + +Type: Consensus + +Status: Draft + +Created: 2024-12-05 + +License: BSD 2-Clause + +Sign-off: + +Discussions-To: https://github.com/stacksgov/sips + +# Abstract + +This SIP corrects the behavior of the Clarity keyword `burn-block-height` inside of an `at-block` statement. + +# Introduction + +Currently, `burn-block-height` does not take into account the context set by `at-block`, and will always return the burn block height at the latest Stacks block. +This behavior was reported in first reported in issue #1615 on the hirosystems/clarinet repository ([link](https://github.com/hirosystems/clarinet/issues/1615)) +The correct behavior would be to return the burn block height **at the height of the Stacks block passed to `at-block`**. + +This behavior only occurs in Stacks Epoch 3.0 and above, and is due to a change in how the burn block is calculated for Nakamoto blocks. +`burn-block-height` returns the expected result inside of `at-block` in Stacks Epoch 2.x and below. + +The proposed fix is to correct the behavior for `burn-block-height` for Stacks Epoch 3.1 and above, and leave the incorrect behavior in Stacks Epoch 3.0, to avoid breaking consensus. + +## Examples + +If we open a session in `clarinet console`, and enter the following commands: + +1. ``` + ::set_epoch 3.0 + ``` + +2. ```clarity + (define-read-only (get-burn (height uint)) + (let + ( + (id (unwrap! (get-stacks-block-info? id-header-hash height) (err 1))) + ) + (at-block id + (ok { burn-block-height: burn-block-height, stacks-block-height: stacks-block-height }) + ) + ) + ) + ``` + +3. ``` + ::advance_burn_chain_tip 100 + ``` + +4. ```clarity + (contract-call? .contract-0 get-burn u3) + ``` + +It will return: + +```clarity +(ok { burn-block-height: u101, stacks-block-height: u3 }) +``` + +Where we would expect it to return: + +```clarity +(ok { burn-block-height: u3, stacks-block-height: u3 }) +``` + +# Specification + +TODO + +# Related Work + +- [hirosystems/clarinet#1615](https://github.com/hirosystems/clarinet/issues/1615): The issue that reports this behavior +- [stacks-network/stacks-core#5524](https://github.com/stacks-network/stacks-core/pull/5524): The PR to introduce the correct behavior described in this SIP + +# Layer + +Consensus (hard fork) + +# Requires + +N/A + +# Backwards Compatibility + +The behavior for contracts deployed prior to Stacks Epoch 3.1 will not change + +# Activation + +Since this SIP requires a change to the stacks consensus rules a community vote is additionally required. + +## Process of Activation + +Users can vote to approve this SIP with either their locked/stacked STX or with unlocked/liquid STX, or both. The criteria for the stacker and non-stacker voting is as follows. + +## For Stackers: + +TODO + +# Activation Status + +TODO + +# Reference Implementations + +To be implemented in Rust. See https://github.com/stacks-network/stacks-core/pull/5524. From 08392eac685cb5fff4123089fd3251b182407c26 Mon Sep 17 00:00:00 2001 From: Jeff Bencin Date: Fri, 6 Dec 2024 11:21:49 -0500 Subject: [PATCH 2/2] Fill in "Specification" --- .../sip-03x-fix-burn-block-height-in-at-block.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/sips/sip-03x/sip-03x-fix-burn-block-height-in-at-block.md b/sips/sip-03x/sip-03x-fix-burn-block-height-in-at-block.md index ae6cb3d3..cb3b5d12 100644 --- a/sips/sip-03x/sip-03x-fix-burn-block-height-in-at-block.md +++ b/sips/sip-03x/sip-03x-fix-burn-block-height-in-at-block.md @@ -2,7 +2,7 @@ SIP Number: 03x -Title: Fix `bburn-block-height` in `at-block` +Title: Fix `burn-block-height` in `at-block` Authors: Jeff Bencin @@ -33,7 +33,7 @@ The correct behavior would be to return the burn block height **at the height of This behavior only occurs in Stacks Epoch 3.0 and above, and is due to a change in how the burn block is calculated for Nakamoto blocks. `burn-block-height` returns the expected result inside of `at-block` in Stacks Epoch 2.x and below. -The proposed fix is to correct the behavior for `burn-block-height` for Stacks Epoch 3.1 and above, and leave the incorrect behavior in Stacks Epoch 3.0, to avoid breaking consensus. +The proposed fix is to correct the behavior for `burn-block-height` in Stacks Epoch 3.1 and above, and leave the incorrect behavior in Stacks Epoch 3.0, to avoid breaking consensus. ## Examples @@ -78,7 +78,13 @@ Where we would expect it to return: # Specification -TODO +When called in the context of `at-block `, `burn-block-height` will return the following result based on the current Stacks Epoch: + +| Epoch | `burn-block-height` returns | +| ------: | ---------------------------------------------------------------- | +| < 3.0 | Height of burn block associated with parent of `stacks-block-id` | +| 3.0 | Height of burn block associated with latest Stacks block | +| > 3.0 | Height of burn block associated with `stacks-block-id` | # Related Work @@ -95,7 +101,7 @@ N/A # Backwards Compatibility -The behavior for contracts deployed prior to Stacks Epoch 3.1 will not change +To avoid breaking consensus, the behavior of `burn-block-height` in blocks prior to Stacks Epoch 3.1 will not change # Activation