`block-height` in Nakamoto

[obycode]

This question arose on Discord:

What happens to BNS name renewals with the Nakamoto upgrade? Will the dramatic increase in block time mean that BNS renewals will be due much sooner?

To clarify that a bit more, in Nakamoto, the block height will be incrementing on the order of seconds, rather than 10 minutes. This would cause BNS, and potentially other software that uses the block-height to have unexpected behavior (e.g. much sooner expiration than expected).

One proposal is to make block-height in Clarity 1 or Clarity 2 contracts continue to increment at a similar pace by incrementing on tenure changes, instead of at each new block. In Nakamoto, the tenure changes once per Bitcoin block, so it would be similar to the current block-height pace. In Clarity 3, block-heightwould still indicate the height.

Two problems with this proposal are:

1. It could be confusing for block-height to have different meanings in different versions of Clarity
2. Functions that take in a block height, such as at-block or get-block-info? would not work as expected if passed a tenure height instead of a block height.

[jcnelson]

It could be confusing for block-height to have different meanings in different versions of Clarity

We could create a different variable in Clarity 3 called tenure-height, which captures the same data that block-height does today.

Functions that take in a block height, such as at-block or get-block-info? would not work as expected if passed a tenure height instead of a block height.

at-block takes a block hash, so I don't think that's affected. get-block-info? would still need to take a Nakamoto block height, because it queries information about that specific block (not the tenure). Perhaps there ought to be a separate get-tenure-info? function that indicates tenure-specific information?

Specific to BNS, what probably ought to happen is we should create a "wrapper" contract around BNS for Nakamoto. The new BNS can use tenure-height to track name expirations and timeouts for newly-registered names in the Nakamoto epoch, and would return old name information written in the Stacks 2.x epoch via at-block for everything else.

This would require a PM to coordinate work on the contract and all BNS-aware wallets, though, so they'd know to migrate over to the new BNS contract right at the epoch boundary. Moreover, we'd want to do some testing on the Atlas system to verify that it can track both the old and new BNS contracts' transactions' attachments (I'm pretty sure it can, but we haven't done this in prod yet).

[jcnelson]

Regarding BNS migration, perhaps we could create a "BNS directory" smart contract that simply contains a read-only function which returns the address of the old BNS contract or new BNS contract, depending on whether or not the chain is in the Stacks 2.x epoch or the Nakamoto epoch. Then, wallets would just call this function via the read-only function call API to determine which BNS contract to interact with. We'd publish this BNS directory contract in a SIP or some such, so there's broad awareness and buy-in to what's going on here.

[hstove]

Thanks for the input @jcnelson ! There are definitely a few options in the case that block-height is fundamentally changed, including what you've mentioned. I'm part of the BNS WG and would be one of the devs who'd contribute to any efforts. At this point we just need to be notified ASAP whether or not this change will come into effect, and then we can coordinate on how to handle it.

[jcnelson]

Hey @hstove, the current plan is that block-height always, always, always refers to the Stacks block height, even though it will grow at a much faster rate in Nakamoto.

[kantai]

Yep -- a related point is that I think miner reward maturation also should follow tenure-height rather than block-height

[obycode]

a related point is that I think miner reward maturation also should follow tenure-height rather than block-height

Is there any advantage to adding a new tenure-height, versus just using burn-block-height?

[jcnelson]

I think (- burn-block-height NAKAMOTO-START-HEIGHT) might be sufficient to deduce the value of tenure-height.

[hstove]

I ran a basic query to lookup contracts that use block-height and sorted them by (roughly, non-exact) number of transactions. My goal was to see what other contracts this change might effect. At the very least, this can help us make sure other developers are aware of the change and get prepared.

Lots of contracts use block-height in a way that isn't effected by this change - like using it for an activation height. Others are more effected, such as:

• Alex reserve pool
  • Staking rewards
• Arkadiko
  • Stacking
  • Staking, liquidity, and stability pool rewards
• NYC & MiamiCoin
  • Stacking and mining

Mainly, these are apps that use block-height for an "inflation schedule" or other time-based mechanisms. I think some contracts will have the ability to work without a new contract, like if they can update a "rewards per block" variable.

The raw data (again, non-exact but directionally correct):

584091,SP000000000000000000002Q6VF78.bns
89014,SP32AEEF6WW5Y0NMJ1S8SBSZDAY8R5J32NBZFPKKZ.free-punks-v0
84493,SP2C2YFP12AJZB4MABJBAJ55XECVS7E4PMMZ89YZR.arkadiko-oracle-v1-1
66410,SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.amm-swap-pool-v1-1
66284,SP466FNC0P7JWTNM2R9T199QRZN1MYEDTAR0KP27.miamicoin-core-v1
51402,SP2C2YFP12AJZB4MABJBAJ55XECVS7E4PMMZ89YZR.arkadiko-swap-v2-1
49732,SPSCWDV3RKV5ZRN1FQD84YE1NQFEDJ9R1F4DYQ11.newyorkcitycoin-core-v2
48425,SP1Z92MPDQEWZXW36VX71Q25HKF5K2EPCJ304F275.stackwap-oracle-v1c
47315,SP1H1733V5MZ3SZ9XRW9FKYGEZT0JDGEB8Y634C7R.miamicoin-core-v2
45246,SP2H8PY27SEZ03MWRKS5XABZYQN17ETGQS3527SA5.newyorkcitycoin-core-v1
41528,SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.alex-reserve-pool
38259,SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.alex-launchpad
28821,SP2KAF9RF86PVX3NEE27DFV1CQX0T4WGR41X3S45C.wasteland-apes-nft
24752,SP2C2YFP12AJZB4MABJBAJ55XECVS7E4PMMZ89YZR.arkadiko-freddie-v1-1
20389,SPNWZ5V2TPWGQGVDR6T7B6RQ4XMGZ4PXTEE0VQ0S.marketplace-bid-v5
19973,SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.auto-alex
17306,SP238ZDHMX8SW2KXD8X164XGY39KBGGKSD3XYQ6F2.artic-monkeys-nft-v3
16998,SP2C2YFP12AJZB4MABJBAJ55XECVS7E4PMMZ89YZR.arkadiko-oracle-v2-1
15482,SP125J1ADVYWGWB9NQRCVGKYAG73R17ZNMV17XEJ7.mutant-monkeys-staking
14395,SP8A9HZ3PKST0S42VM9523Z9NV42SZ026V4K39WH.ccd006-citycoin-mining
14376,SP1CSHTKVHMMQJ7PRQRFYW6SB4QAW6SR3XY2F81PA.stxnft-auctions-v1
14354,SP2KAF9RF86PVX3NEE27DFV1CQX0T4WGR41X3S45C.steady-lads
11993,SP2KAF9RF86PVX3NEE27DFV1CQX0T4WGR41X3S45C.btc-monkeys-staking
10263,SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.collateral-rebalancing-pool-v1
10194,SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.stxdx-wallet-zero
9801,SP2C2YFP12AJZB4MABJBAJ55XECVS7E4PMMZ89YZR.arkadiko-oracle-v2-2
8068,SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.amm-swap-pool
7326,SP2A665S3H6FVMZSY4VJ17ESXX21CGS0A32984B1H.staker-v2
7156,SP2C2YFP12AJZB4MABJBAJ55XECVS7E4PMMZ89YZR.arkadiko-vault-rewards-v1-1
5906,SPZ0RAC1EFTH949T4W2SYY6YBHJRMAF4ECT5A7DD.oracle-v1
5770,SPXG42Y7WDTMZF5MPV02C3AWY1VNP9FH9C23PRXH.Marbling
5578,SPNWZ5V2TPWGQGVDR6T7B6RQ4XMGZ4PXTEE0VQ0S.marketplace-bid-v6
5379,SP343J7DNE122AVCSC4HEK4MF871PW470ZSXJ5K66.miamipool-v1
4923,SP6P4EJF0VG8V0RB3TQQKJBHDQKEF6NVRD1KZE3C.monster-satoshibles
4922,SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.alex-reserve-pool-sft
4330,SPNWZ5V2TPWGQGVDR6T7B6RQ4XMGZ4PXTEE0VQ0S.bm-stake-v1
4126,SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.auto-alex-v2
4120,SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.event-claim-helper-v1-01
3314,SP3C0TCQS0C0YY8E0V3EJ7V4X9571885D44M8EFWF.arkadiko-job-registry-v1-1
3294,SP2507VNQZC9VBXM7X7KB4SF4QJDJRSWHG4V39WPY.stxswap_v10
3249,SP3QSAJQ4EA8WXEDSRRKMZZ29NH91VZ6C5X88FGZQ.crashpunks-v1
3197,SP1Z92MPDQEWZXW36VX71Q25HKF5K2EPCJ304F275.stackswap-farming-v2c5
3121,SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.alex-lottery
2925,SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.simple-weight-pool-alex
2848,SP2KAF9RF86PVX3NEE27DFV1CQX0T4WGR41X3S45C.bitcoin-monkeys
2787,SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.fwp-wstx-alex-tranched-64
2699,SPNWZ5V2TPWGQGVDR6T7B6RQ4XMGZ4PXTEE0VQ0S.mktc-staking-v2
2641,SP3QSAJQ4EA8WXEDSRRKMZZ29NH91VZ6C5X88FGZQ.thisisnumberone-v2
2581,SP238ZDHMX8SW2KXD8X164XGY39KBGGKSD3XYQ6F2.artic-monkeys-nft-v2
2564,SP1Z92MPDQEWZXW36VX71Q25HKF5K2EPCJ304F275.stackswap-farming-v1l

[kantai]

One option here could be to either:

1. Always return tenure height for block-height -- so block-height basically still works the same. Introduce new Clarity3 keywords chain-length and tenure-height, and forbid the keyword block-height in Clarity3
2. Clarity1 and Clarity2 get tenure height returned for block-height, but in Clarity3 it returns the nakamoto chain length.

I think (2) might be way too confusing.

[obycode]

I agree, (2) is not a good solution. (1) seems like a viable option to me.

[obycode]

I'd argue that the correct solution is to leave block-height as-is, returning the chain length, and then require any contracts to adapt to the new timing of blocks, but practically, that is likely to cause some problems and slow down timelines.

[fiftyeightandeight]

I'd argue that the correct solution is to leave block-height as-is, returning the chain length, and then require any contracts to adapt to the new timing of blocks, but practically, that is likely to cause some problems and slow down timelines.

I would second @obycode 's argument, but failing that (1) may be a good alternative. Also agree that (2) is messy and not good.

For ALEX, as @hstove mentioned, our staking/farming is based on the number of blocks, but this can be easily updated to reflect the faster confirmation time (though there might be some minor unexpected behaviour right before and after such update).

[hstove]

Hey all, I just wanted to check in and see what the status is for this issue. It seems like there's agreement on keeping block-height equal to tenure-height, but I'm also seeing content like in the ultimate stacks nakamoto guide on changes to block-height.

[jcnelson]

As far as I know no-one is working on this

[hstove]

Does "working on this" mean there is work to not make the change, or the work would be to make the change? I'm sure there is some work on either side, I'm just curious what you meant. I should dive into the core codebase to see how instances like this are handled.

[jcnelson]

I meant, block-height is not tenure height; it's the Stacks block height. No one is working on adding a separate tenure height at the moment, as far as I know. A PR that adds would be welcome🙏

On Fri, Dec 8, 2023, 5:06 PM Hank Stoever @.***> wrote:

Does "working on this" mean there is work to not make the change, or the work would be to make the change? I'm sure there is some work on either side, I'm just curious what you meant. I should dive into the core codebase to see how instances like this are handled.

— Reply to this email directly, view it on GitHub https://github.com/stacks-network/stacks-core/issues/3943#issuecomment-1847901210, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADQJK6UU5RJCPEHZNUY2IDYIOFM5AVCNFSM6AAAAAA45CJ7WOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBXHEYDCMRRGA . You are receiving this because you were mentioned.Message ID: @.***>

[obycode]

The decision in the SIP is:

The protocol described in this document would have Stacks blocks occur at a much greater frequency than in the past. Many contracts rely on the block-height primitive to approximate a time assuming that a block takes, on average, 10 minutes. To release faster blocks while preserving the functionality of existing contracts that make this block frequency assumption, this proposal calls for a new version of Clarity, version 3, which includes the following changes.

A new Clarity global variable stacks-block-height will be introduced, which evaluates to the Stacks block height. A new Clarity global variable tenure-height will be introduced, which evaluates to the number of tenures that have passed. When the Nakamoto block-processing starts, this will be equal to the chain length. The Clarity global variable block-height will continue to be supported in existing Clarity 1 and Clarity 2 contracts by returning the same value as tenure-height. Usage of block-height in a Clarity 3+ contract will trigger an analysis error.

I will begin implementing this change in the interpreter. We will also add this support in the Clarity-Wasm runtime.