SIP-012: Burn height selection for network-upgrade to introduce new cost-limits

[diwakergupta]

The current Clarity cost limits were set very conservatively in Stacks 2.0: transactions with contract-calls frequently exceed these limits, which negatively affects transaction throughput. This SIP proposes an update to these cost-limits via a network upgrade and further, that the network upgrade be executed at a block height chosen by an off-chain process described in this SIP.

[diwakergupta]

Tagging some folks to get the ball rolling here: @jcnelson @friedger @kantai @lgalabru @hstove @jasonklau @0xAsteria

[diwakergupta]

Also cc/ @xanbots

[Zk2u]

Looking awesome. Do we reckon we can get it from 3 weeks down to 2 weeks?

[LNow]

@diwakergupta is there any particular reason to increase cost of contract-of over 13x ? We can't pass to it anything but valid trait, which by default consists proper contract address, therefore I don't understand why do we have to increase its cost.

[hstove]

Big fan of this SIP!

Question about static vs. dynamic costs. map-get? is mentioned in the draft, but does this apply to basically anything that has a dynamic size? For example, functions like mine-many in MiamiCoin. The function arg has a (list 200 uint). Does this mean that, after this change, the cost will be based on the size of the argument, instead of the max length? If this change applies all around, that would be huge. I have found that this pattern is highly necessary in many different contexts, so only calculating costs based off of dynamic size would be a huge benefit.

[LNow]

One general remark - Title of this SIP suggests that it is about introducing new costs limits, but at the same time it also describe update of functions costs. Although changing costs limits is a consensus-braking change as it needs to be applied in stacks-blockchain code and describing whole process in SIP is a good thing, I thought updating functions costs can be done on-chain using SP000000000000000000002Q6VF78.cost-voting contract.

If updating functions costs can be performed on-chain we should describe the process in a separate SIP (if it has not been done already) and not mix it with changing limits.

[jcnelson]

@LNow Yeah, I agree -- the framing of this SIP could be better. The SIP is really about making a couple of one-off breaking changes, and it just happens to opportunistically change the runtime costs. I've detailed what I think the intro should say here: https://github.com/stacksgov/sips/pull/41#discussion_r729218799

[Zk2u]

hey @diwakergupta, so we don't overlap work, i'm making @jcnelson's recommended changes as I see them here

[diwakergupta]

hey @diwakergupta, so we don't overlap work, i'm making @jcnelson's recommended changes as I see them here

welp, sorry just saw this. I pushed 2 commits to address some nits, will circle back on some of the meatier feedback in a bit.

[Zk2u]

hey @diwakergupta, so we don't overlap work, i'm making @jcnelson's recommended changes as I see them here

welp, sorry just saw this. I pushed 2 commits to address some nits, will circle back on some of the meatier feedback in a bit.

All good. Here's a graph for the runtime cost stuff.

[jcnelson]

@hstove The function arg has a (list 200 uint). Does this mean that, after this change, the cost will be based on the size of the argument, instead of the max length?

Yes, that's the idea. For example, if the list has only 5 items, then only those items should be considered in the cost-tracker (instead of the total number of items).

[jcnelson]

Just spoke with some of the SIP authors to get some further clarity on some of the points here. We came up with the following action items:

• Changes to block-commit wire format. Nodes that run 2.05 must put 0x05 in the memo field. Block-commit transactions that do not have 0x05 will be considered invalid. The purpose of this change is to ensure that in the unlikely event some miners didn't know about this SIP, they will quickly find out because their blocks will never be confirmed.

• Invite more co-authors. This SIP affects the whole ecosystem. We should invite exchanges, developers, stacks.vc members, prominent community members, and so on to be co-authors. Basically, anyone in the ecosystem who supports the 2.05 upgrade should be able to stand by this SIP.

• Pick a pre-determined Bitcoin block height for activation now, and then see if there's support. Instead of building out an elaborate smart contract or on-chain voting scheme for choosing when 2.05 will activate, the SIP should pick a target Bitcoin block and then measure support for it between now and then. If there is support, then the SIP activates. Tentatively, this deadline is November 22, since that would give the engineers working on this enough time to build out and test the new features in this SIP (including the upgrade procedure).

• Vote by sending BTC. There will be two Bitcoin addresses whose UTXOs will be used to tally the vote: a "yes" address, and a "no" address. The addresses are TBD, but will likely be the addresses of a charity or a Bitcoin core developer's donation address or something. To vote, a Stacker would send a small amount of BTC to either one of these addresses.

  • The transaction's scriptSig must be signed by either the Stacker's PoX reward address's public key(s), or the public key(s) of their Stacks address (the option is provided here because not all Stackers have access to their PoX addresses). In either case, the vote commits the Stacker's most-recently-locked STX to "yes" or "no" if the Stacker had some STX locked in the past two reward cycles at the time of the vote.
  • The vote to activate 2.05 passes if the following two criteria are met:
    • 2/3 of all votes passed are "yes", weighted by the STX they represent
    • At least 60 million STX are represented by the "yes" votes. This is 2x the largest Stacker right now.
  • The vote can start once this SIP text is updated with the addresses. It will finish one week prior to the 2.05 activation block. If there is not enough support by then, then this SIP does not activate.
  • This SIP would come with scripts and instructions to use for independently auditing the vote.

  The rationale for this voting procedure is that it simultaneously gives the community a way to veto the SIP while also accommodating a low-ish turnout. The problem with any blockchain-based voting systems in the past is that unless there's a financial incentive to vote (e.g. mining, staking), turnout is low. By introducing a distinct "no" choice and giving it 2x the power of a "yes" vote, this protocol ensures that if there are real problems discovered with this SIP that would warrant a "no" response, it will take far less effort to stop its ratification than to advance it.

• Release the 2.05 binary upon ratification. If there is sufficient support for the 2.05 upgrade by November 22, then a 2.05 Stacks blockchain release will be announced. Miners will have 1 week to upgrade. The network upgrade would go live on November 29 or 30.

Please let me know if there's anything I missed.

[jasonklau]

This is fantastic. We (at Okcoin) would love to see these limits raised and block capacity increased.

Most of the deposit and withdrawal issues we've seen recently relate to congestion from a surge in activity. Given how the ecosystem is growing, we don't see that activity quieting down soon.

[Zk2u]

Regarding the Bitcoin block for 2.05's activation, how does #711,750 sound? That's estimated to be on Nov 29th.

Just give this comment a 👍 or 👎

[diwakergupta]

Just spoke with some of the SIP authors to get some further clarity on some of the points here. We came up with the following action items:

Thanks for the summary @jcnelson ! I'm working on incorporating the changes.

• Vote by sending BTC. There will be two Bitcoin addresses whose UTXOs will be used to tally the vote: a "yes" address, and a "no" address. The addresses are TBD, but will likely be the addresses of a charity or a Bitcoin core developer's donation address or something. To vote, a Stacker would send a small amount of BTC to either one of these addresses.

  • The transaction's scriptSig must be signed by either the Stacker's PoX reward address's public key(s), or the public key(s) of their Stacks address (the option is provided here because not all Stackers have access to their PoX addresses). In either case, the vote commits the Stacker's most-recently-locked STX to "yes" or "no" if the Stacker had some STX locked in the past two reward cycles at the time of the vote.

  • The vote to activate 2.05 passes if the following two criteria are met:

  • 2/3 of all votes passed are "yes", weighted by the STX they represent

  • At least 60 million STX are represented by the "yes" votes. This is 2x the largest Stacker right now.

  • The vote can start once this SIP text is updated with the addresses. It will finish one week prior to the 2.05 activation block. If there is not enough support by then, then this SIP does not activate.

  • This SIP would come with scripts and instructions to use for independently auditing the vote.

@hstove is above something you / OBY can help with? Basically selecting the two Bitcoin addresses to be used, ideally some sort of (open source) web UI to show the results as the votes come in, which can double as the scripts / instructions for anyone to independently audit the vote?

[owenstrevor]

Hi all, I'm of the opinion that this upgrade is super important to get done quickly, considering we have multiple high profile NFT launches, Arkadiko Mainnet, ALEX Mainnet, Stackswap Mainnet, etc. all coming imminently.

[Zk2u]

@diwakergupta and others -- what can I help do here? Don't want to overlap your work.

[hstove]

Hey all, I'm happy to help with the changes Diwaker mentioned in https://github.com/stacksgov/sips/pull/41#issuecomment-945165952 .

Here are suggestions for the 'yes' and 'no' votes addresses:

Yes:

• Public key hash = 00000000000000000000000000000000000000ee
• Address = 111111111111111111112czxoHN

No:

• Public key hash = 00000000000000000000000000000000000000ff
• Address = 111111111111111111112kmzDG2

Using a similar pattern as the PoX burn address, but the last byte of the hash is different. I've checked that each address has never been used.

[hstove]

@0xAsteria wanna collab on a front-end that shows current voting info? I could write some JS code that pulls in and aggregates everything, and you could work on the front-end, using mock data. Then we can combine them. Thoughts?

[owenstrevor]

We're having a vote and debate about the mint date for Crash Punks in the discord right now. Surprisingly, a lot of people hesitant about even minting before this upgrade.

Can read the debate and see how people are voting here: https://discord.gg/NgAEeEHCDK

[dantrevino]

@0xAsteria wanna collab on a front-end that shows current voting info? I could write some JS code that pulls in and aggregates everything, and you could work on the front-end, using mock data. Then we can combine them. Thoughts?

@hstove I'd be interested in a library/package that allows multiple frontends to be used

[hstove]

@dantrevino, definitely, it would be totally doable to ship as an NPM package

[Zk2u]

@0xAsteria wanna collab on a front-end that shows current voting info? I could write some JS code that pulls in and a

this sounds cool, though i'm not a frontend dev. can help on backend. dm me on discord.

cc @syvita @syinvidia @diopitis for frontend stuff

gonna see if i can get some frontend devs from syvita

[aulneau]

@0xAsteria wanna collab on a front-end that shows current voting info? I could write some JS code that pulls in and a

this sounds cool, though i'm not a frontend dev. can help on backend. dm me on discord.

cc @syvita @SyInvidia @diopitis for frontend stuff

gonna see if i can get some frontend devs from syvita

I'm happy to help build out a UI, I've messaged in discord. Here is a public repo for the UI https://github.com/fungible-systems/sip012.xyz

[jcnelson]

Okay, so this is obnoxious. I can't replace the remote on this PR to this repository, which should contain a branch with the SIP text being edited. This is necessary because the only people who can commit to this PR are Hiro engineers. I've opened https://github.com/stacksgov/sips/pull/43 which contains everything here so far, but is based on a branch in this repository. If we can't figure out a way to switch this remote, then let's move over to that PR to continue the discussion.

[diwakergupta]

Okay, so this is obnoxious. I can't replace the remote on this PR to this repository, which should contain a branch with the SIP text being edited. This is necessary because the only people who can commit to this PR are Hiro engineers. I've opened #43 which contains everything here so far, but is based on a branch in this repository. If we can't figure out a way to switch this remote, then let's move over to that PR to continue the discussion.

One easy fix is to add all SIP authors to the hirosystems/sips repo as external collaborators. Given the amount of comments and context in this PR, I'd prefer to continue using it if possible.

Meanwhile, how does using a branch in stacksgovs/sips solve this problem? For instance, I'm unable to push any updates to the PR you just opened.

[jcnelson]

One easy fix is to add all SIP authors to the hirosystems/sips repo as external collaborators. Given the amount of comments and context in this PR, I'd prefer to continue using it if possible.

I'm fine with that.

Meanwhile, how does using a branch in stacksgovs/sips solve this problem? For instance, I'm unable to push any updates to the PR you just opened.

Similarly, I can't push any updates to the SIP without making a branch within this repository. That's why I said it's obnoxious of Github to not make this possible -- as a repo admin, I should have the power to "import" a remote branch as a branch of this repository while keeping the comments.

[diwakergupta]

One easy fix is to add all SIP authors to the hirosystems/sips repo as external collaborators. Given the amount of comments and context in this PR, I'd prefer to continue using it if possible.

I'm fine with that.

Added you and happy to add others as needed. Can you re-push your changes to the draft/sip-012 branch in hirosystems/sips and close #43 ? Thanks!

[cryptopanter]

We're having a vote and debate about the mint date for Crash Punks in the discord right now. Surprisingly, a lot of people hesitant about even minting before this upgrade.

Can read the debate and see how people are voting here: https://discord.gg/NgAEeEHCDK

I think this SIP should have atm the highest priority for the Stacks community... All efforts and projects seem useless unless the slow network and congestion issue is resolved 🎩

[jasonklau]

Are we comfortable moving forward to determine the block heights for activation and vote deadline?

[diwakergupta]

@hstove @0xAsteria @aulneau any update on the frontend for tallying votes?

@jcnelson just wanted to confirm if we're OK to ask folks to start sending in their BTC transactions for voting?

@jasonklau I believe the plan is that once 50% of the work on this board is done (we're close), then the block numbers can be picked.

[jcnelson]

@jcnelson just wanted to confirm if we're OK to ask folks to start sending in their BTC transactions for voting?

Yes -- we're within the first of the two whole reward cycles that precede the target vote counting block height.

[jcnelson]

@kantai @pavitthrap when either of you get a moment, can you please answer @FriendsFerdinand's comments?

[Zk2u]

@hstove @0xAsteria @aulneau any update on the frontend for tallying votes?

Hey @diwakergupta 👋

JS library is done. API using said JS lib is now up (PR reintegrating it back into JS lib is waiting for merge) and available at sip12.halo.ms.

Last bit is on @aulneau for the actual UI.

@jcnelson just wanted to confirm if we're OK to ask folks to start sending in their BTC transactions for voting?

We sure can. Tutorials should go out and so should alerts for all the community. Need to get this voted through ASAP.

@jasonklau I believe the plan is that once 50% of the work on this board is done (we're close), then the block numbers can be picked.

Waiting on this.

[kantai]

@kantai @pavitthrap when either of you get a moment, can you please answer @FriendsFerdinand's comments?

What comments are those, I don't think I see them on the PR.

[aulneau]

@diwakergupta yep as @0xAsteria said I am now able to build out the UI which I will do today and tomorrow. it will be live at https://sip012.xyz.

Tutorials should go out and so should alerts for all the community.

Outside of this SIP, is there any documentation / tutorials for how best to vote? Sorry if I missed it and it's somewhere in this thread. Any pointers towards how-tos that can go on the frontend would be great.

Will update when there is something online.

[jcnelson]

To vote, you'll need to send a Bitcoin transaction using either the key(s) you used to Stack your STX, or the key(s) to your PoX reward address. To vote "yes," send a dust amount of BTC to 111111111111111111112czxoHN. To vote "no," send a dust amount of BTC to 111111111111111111112kmzDG2. The vote-tallying software will take it from there.

[Zk2u]

PR reintegrating it back into JS lib is waiting for merge

Update on this - v0.2.0 of sip12.js was released with integration for Halo's API. S/o @hstove! Great job 👏

[aulneau]

okay! site is live and someone has already voted! https://sip012.xyz/

[jasonklau]

Site looks awesome!

On Wed, Oct 27, 2021 at 8:07 PM Thomas Osmonson @.***> wrote:

okay! site is live and someone has already voted! https://sip012.xyz/

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stacksgov/sips/pull/41#issuecomment-953397193, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUXGBFFX3YNNKQ4OIRXUXDUJCH5BANCNFSM5F73MMJQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Sent from my iPhone

[314159265359879]

@aulneau yesterday the title had a regular size, now it looks different. Did you intend it this way (firefox and chrome on windows):

[aulneau]

@aulneau yesterday the title had a regular size, now it looks different. Did you intend it this way (firefox and chrome on windows)

Yep, intentional :)

[jasonklau]

@aulneau Is there any way we can add in the voting "win conditions" - amount needed, deadline, etc? Would be more informative for potential voters.

On Fri, Oct 29, 2021 at 10:38 AM Thomas Osmonson @.***> wrote:

@aulneau https://github.com/aulneau yesterday the title had a regular size, now it looks different. Did you intend it this way (firefox and chrome on windows)

Yep, intentional :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stacksgov/sips/pull/41#issuecomment-954797836, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUXGBFMMPJEPQKM5TBYTPTUJKWW7ANCNFSM5F73MMJQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[aulneau]

@jasonklau yes, we were just thinking about that! Here is a screenshot of a progress bar we'll be adding:

@diwakergupta @jcnelson what are the exact conditions that need to be met for either yes or no to pass?

[diwakergupta]

@diwakergupta @jcnelson what are the exact conditions that need to be met for either yes or no to pass?

It's in the SIP, under the Activation Criteria section:

The SIP will be considered Ratified if the vote to activate Stacks 2.05 passes. This requires:

• 2/3 of all votes passed are "yes", weighted by the STX they represent, at a Bitcoin block height at or before the vote deadline block.
• At least 60 million STX are represented by the "yes" votes. This is 2x the largest Stacker at the time of this writing.

[jcnelson]

As a means of cross-validating the vote tabulation, I've added a vote-tallying script here that was independently implemented from the SIP text. I'll be using it alongside https://sip012.xyz to verify whether or not the activation threshold has been met. The script needs some testing; feel free to post bug reports in this comment thread.

[aulneau]

nice, @jcnelson would be great if you could double check these numbers

[jcnelson]

Hey @whoabuddy @joberding, and @HaroldDavis3, this is a governance-track SIP. We're gonna need the governance CAB's sign-off (or rejection) on this at your earliest convenience. It's sufficient to just reply here with a comment (or even an emoji vote); I can add the sign-off text to the SIP. Thanks!

@whoabuddy You'll want to record that the decision happened. It could be as simple as adding a markdown file to the governance CAB folder in this repo with the date, signatories, and SIP number.

[kantai]

Here are some initial numbers from measuring the proposed changes to cost tabulations over ~3500 recent blocks. This table contains the total assessed cost in each dimension of the transactions in those blocks, assessed by proposed 2.05 rules and by the active 2.0 rules.

	2.00 Cost	2.05 Cost
Runtime Cost	7.85 * 10^12	3.75 * 10^10
Write Length	1.71 * 10^9	3.37 * 10^8
Write Count	4.52 * 10^5	4.52 * 10^5
Read Length	3.52 * 10^9	2.03 * 10^9
Read Count	1.16 * 10^7	1.16 * 10^7

Far and away the most significant improvement is in the runtime costs -- the total assessed runtime cost is over 100x smaller with the proposed 2.05 changes. The biggest factor in this change is the cost application of database operations-- in 2.0, database operations are assessed using the maximum size of the data schema (e.g., a (list 500 uint) is always charged as if it is 500 elements long even if the actual list stored is only 5 elements long), while in 2.05, the database operations are assessed using the actual size of the data.

The expected increase in throughput is more modest, however. The total read count is unchanged between the two consensus rules, and once the runtime assessment is reduced, this becomes the limiting dimension for blocks. The 2.05 proposed changes do increase this limit 2x, though. Given this data, an optimistic block packing of these transactions would require 746 blocks in 2.05 as opposed to 1,571 in 2.00, which is roughly a 2x increase in throughput.

[lgalabru]

Interesting. Do we have the distribution of contract-call / stx-transfer, on this last 3500 blocks? Would a pre-dominant number of stx-transfer (non impacted by the new costs) be dilluting the estimated gains?