RFC: BNS Fixes for Stacks 2.1

Hello Stackers,

During our last BNS Working Group meeting we decided to put forward a Proposed SIP to fix bugs and make improvements in the current BNS naming contract and make what we think will be non-controversial improvements to BNS for the Stacks 2.1 hard fork.

We will post future Proposed SIPs for what we believe are more controversial improvements that some of us believe should also be included in the Stacks 2.1.

Many of us also have a vision for BNS of something much more than it is today. We also hope that this Proposed SIP will be a starting point to discuss what we want to see from the future of BNS and who is interested in working on it.

BNS Bugs to Fix

Names can be renewed for free

When BNS names are registered, STX tokens are burned to pay the registration fee for the name.

When names are renewed, it is intended for registration fee to be burned again. This is currently not happening because the name-renewal function is missing a call to thestx-burn function. Currently names can be renewed for “free” by only paying the transaction fee for the contract call.

As it exists today, the name-renewal function takes an argument for the number of STX to burn and checks to make sure that the tokens to be burned are adequate. After doing that check, it does nothing further with the tokens. We proposed fixing the name-renewal function by adding a call to stx-burn to burn the tokens.

Name renewal new owner argument does not work

The name-renewal function takes an optional new-owner argument to allow the name to be transferred to a new owner upon renewal. Currently, this argument does not function as described. It currently checks if the new-owner can receive a name but then fails to call the update-name-ownership function.

Remove incorrect info in comment on line 728

The comment on the name-renewal function provides the following example:

; Depending in the namespace rules, a name can expire. For example, names in the .id namespace expire after 2 years.

This examples says that names in the .id namespace expire every 2 years when in fact they expire approximately every 1 year. This comment has caused a large amount of confusion as name owners thought that they had an extra year before needing to remove this name. Propose removing this example from the comment.

Improvements

Make BNS conform to SIP-0009 NFT standard

Names are the original NFTs. Conformation to the SIP-0009 NFT standard would make BNS names behave the same as other NFTs in our ecosystem, simplifying wallet, tool and application development.

Implementation & Deployment

Given that many users of the ecosystem have hardcoded the BNS contract’s address and the challenges behind migrating state from one contract to another, we propose that these changes be made by hard forking the existing BNS contract at the existing address in a way similar to the way updates to the POX contract → consensus algorithm were deployed and that this occur with the network upgrade to Stacks 2.1.

5 Likes

Hi Larry, was wondering some more clarity on above.
Would you say this is post is “Request For Comments” (RFC) from the wider community, or it’s a “formal SIP proposal”? (please see Muneeb’s comment on “Scaling up the SIP process” post, where he mentioned the idea of RFC).
:slight_smile:

2 Likes

Hi BNS Working Group, thank you all for your submission! I agree with @HeroGamer that this should be an RFC at this point until it’s a fully-formed SIP according to SIP-000. I took the liberty of changing the topic title.

Without commenting on the rest of the text just yet (I’ll let the BNS stakeholders take the lead here), I just wanted to correct a few misconceptions in this paragraph:

First, there have been no upgrades to .pox yet, so I’m not sure what you mean here. In general, it is currently impossible to retroactively change contract code.

Second, for Stacks 2.1, the .pox contract is not being changed. Instead, a new .pox-2 contract is being instantiated, and users will be expected to manually re-stack their STX into the new .pox-2 contract. All the state in .pox is remaining in place, and all of its functions will remain accessible to Clarity contracts, but future calls to stack-stx and delegate-stack-stx after an epoch-designated block height (e.g. one reward cycle after 2.1 activates) will invalidate the calling transaction.

  • (Aside: Something similar happened in SIP-012 for the .costs contract. .costs is still there; it was not modified, and you can still call its methods. However, the Clarity VM uses the new .costs-2 instead to determine the cost of each built-in function. This is consistent with the spirit of SIP-006; SIP-012 executed a one-off “fast path” mass-reassignment of all current cost functions through an on-chain vote.)

Third, I think that changing the BNS implementation out from under existing code sounds like breaking a promise to those downstream contracts. I think a SIP that proposes this needs to have a very compelling argument as to why the proposers believe that the vast majority of the downstream contract authors and users want this to happen. After all, people go through the hassle of writing smart contracts because the blockchain guarantees that (a) their code won’t change and (b) none of the contracts they call into will change. I would think very hard about why breaking this rule here is acceptable over all possible alternatives (and if it’s a change that is specific to just BNS, why does BNS get this special power while others do not).

Speaking of alternatives, have you considered the following?

  • Implement a new BNS as a new contract, and use (at-block ..) to resolve historic BNS names in order to “port” them into the new contract. This new BNS contract would need to declare a particular block for when it starts using (at-block ..), but that would be part of the SIP. Downstream resolvers and wallets would need to get on the same page with this block, but if the new BNS contract proves popular, that shouldn’t be a problem.

  • In addition to the above, propose a soft fork SIP at which point new contract-calls to the existing BNS contract’s name/namespace mutation functions (i.e. register, update, transfer, delete) will be ignored. This effectively freezes BNS at block X and after. Then, new BNS contracts could import its state via (at-block ..) per the above with the confidence that there will never be any name resolution conflicts between the old and new contracts.

  • To make it so that we only have to do this once, implement the new BNS contract so it can be subsequently upgraded later via a governance token or the like.

The above would require substantially fewer person-hours working on the blockchain, since implementing the soft-fork rule is a much narrower change than making it possible for smart contract code to change at a later date. Also, steps (1) and (3) of this plan could be done without touching the blockchain at all, and thus provide ample time for the BNS stakeholders to get on-board with the desired BNS implementation and upgrade mechanism.

What do you think?

4 Likes

Thanks. This makes perfect sense to me in that our goal is to request comments from the community and get a sense of what people want.

Thank you Jude!

Thanks for clarifying this. To be clear, the comment was referring to the POX consensus algorithm. I updated the original post (but left the change visible) to make that more clear.

Your clear and concise explanations of how some of the contracts that serve as part of the consensus mechanism were or are planned to be changed are very helpful.

Changing costs in SIP-012 as you mentioned, from the perspective of someone using a node is changing POX irrespective of how that change was done via directly changing a .costs contract or creating a .costs-2 contract and making it so that everyone uses that costs-2 contract by default by changing the clarity VM.

Similarly, the clarity VM could intercept calls to the current BNS contract after a certain block and direct them to the new contract. That said, I agree with you and think doing this sets a bad precedent.

I really like your suggested approach. I’ll refrain from commenting directly on it until more people have time to comment.

I think this really gets to the crux of the issue.

Is BNS part of the core Stacks blockchain?

If the answer is “Yes,” then it gets the special powers that are used to correct bugs or problems in the core blockchain

If the answer is “No,” then it doesn’t.

I think the answer up to and including the Stacks 2.0 launch was “Yes, BNS is part of the core blockchain.” Prior to Stacks 2.0 BNS was the main functionality of the core blockchain and prior to the Stacks 1.0 token sale, BNS was the entirety of the core blockchain. The current BNS contract (including some of the bugs we propose fixing) was written by the core blockchain team and shipped as part of the Stacks 2.0 genesis block.

That said, I am increasingly of the opinion that the answer to the question “Is BNS part of the core Stacks blockchain?” should be “No” going forward. Our ecosystem has evolved, grown and decentralized in such a way that it will be healthier for both BNS and the Stacks core blockchain for BNS to grow into a separate project built on Stacks (and bitcoin).

1 Like

Don’t you think, that blocking mutating function calls on a protocol/node level creates a precedence?
Downstream resolvers should be able to ignore all data changes made in old BNS contract storage after block X, therefore I don’t understand why would anyone want to block or invalidate 100% correct mutations.
And this should apply to all contracts, including .bns and .pox.

2 Likes

Thanks! But to be clear, we never upgraded the PoX consensus algorithm either. It’s been working the same way since the system launched. There are some upgrades coming in 2.1, though.

I think I agree with this. BNS isn’t “special” anymore because unlike Stacks 1.0, Stacks 2.0 has a full smart contract system. The only reason the current BNS implementation is instantiated in the boot code address is because it had to be pre-loaded with all of the name state that got migrated over from Stacks 1.0 (meaning, it had to be instantiated before the first block was mined). However, there is no special-case handling for it in the Clarity VM, unlike .costs, .pox, and .cost-voting. As you point out, these contracts are better thought of as part of the Clarity VM itself that just happen to be written in Clarity in order to simplify the implementation.

I think this is a great question for the BNS working group. Is it imperative that the old BNS contract cease operation, when downstream resolvers could instead supply a tip= query parameter in order to query historic name state? A SIP for a new BNS contract could mandate that all new resolver implementations use a particular tip in their RPC queries, in addition to using it within (at-block ..) in the contract code.

The difference between .pox and .bns is that .pox is technically part of the Clarity VM, while .bns is not. The Clarity VM implementation is tightly coupled to the .pox implementation, and the act of getting the Clarity VM to use a different contract besides .pox for implementing stacking will necessarily require a hard fork. By contrast, the Clarity VM does not depend on .bns for anything.

(Aside: it should be possible for a future version of .pox to offer stackers the ability to vote to change which contract is the PoX contract in-band, which would obviate the need for a hard fork each time there was a new PoX contract proposed. The system does something similar in SIP-006 with cost functions; it could also do something like this with .pox).

2 Likes

I agree that BNS is not part of the core blockchain layer. It can be treated separately and upgraded through RFCs/SIPs.

Thanks @larry for starting this RFC!

2 Likes