RFC: BNS Fixes for Stacks 2.1

[larry]

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.

[HeroGamer]

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

[jude]

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:

@larry

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 were deployed and that this occur with the network upgrade to Stacks 2.1.

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?

[larry]

@HeroGamer

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

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.

@jude

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.

Thank you Jude!

@jude

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.

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.

@jude

What do you think?

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

@jude

(and if it’s a change that is specific to just BNS, why does BNS get this special power while others do not).

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

[LNow]

@jude

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.

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.

[jude]

@larry

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.

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.

@larry

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

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.

@LNow

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.

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.

@LNow

And this should apply to all contracts, including .bns and .pox.

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

[muneeb]

@jude

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.

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!

[rainer]

transferring token via web3 domain is really weak demand, most people used to transfer ETH via their address for safety though ENS registration quantity has reached nearly 3 million.

web3 domain development rely on decentralized social media development.

the biggest vision of web3 domain is used as web3 social ID, it is much bigger than web2 domain coz in web2 not everyone need a web2 domain to build website, but in web3 everyone needs 1 web3 domain as web3 social media ID. it has the potential of billions of users.

Only when the decentralized social media became popular, web3 domain will achieve mass adoption

The only way for BNS growing bigger is that some big projects create their namespace on BNS and integrate BNS , 1 name 1 address is in the crucial importance to attract those big projects/companies coz they can earn registration fees from BNS.

We have seen that many projects in Stacks ecosystem has created their namespace such as .frien .citycoins, .app and so on.

We have 10+ namespace on BNS, That is the big advantage than ENS, no projects want to create their namespace on ENS.

Because in multiple names, their namespace is inferior to .btc name, the one stx address and btc address be occupied by .btc name, no one would like to mint names on new namespace.
But in 1: 1 name, their namespace has the same priority rating to .btc name, match with 1 stx address and 1 btc address just like .btc names does.

most efficentive way to reduce dormant addresses is to raise the register price , but not allowing 1 more names

With the open space, security,anonymity and low tx fee, BNS holds the potential to become the web3 ICANN to attract all the big projects creating their namespace on BNS and integrating BNS. But If 1 name 1 address be changed, BNS will lose its biggest competitive advantages.

[3.id]

Hi Larry - thanks for this thread. I just got directed to it.

To comment on the change to free renewals - it’s worth considering the implication on different namespaces depending on their pricing models.

I BELIEVE only .id and .btc are currently the only namespaces requiring renewal (at 1 and 5 years respectively), but the pricing models are very different.

.btc is 2 stx per registration/renewal which is largely unaffected by the addition/removal of renewal cost even if stx does very well as we all hope and becomes a top 10 coin.

There are some shorted addresses in .id however that this doesn not apply to (single digit: 110 stx, single letter: 440 stx, many shorter (2 and 3 char depending on make-up) domains: 27 stx). In the event of stx being very successful these would start to cost crazy amounts at renewal.

If the fees are intended to be burned, and the intention of renewal is to stop addresses lying lost in forgotten wallets, then why not just keep registration as a requirement, but only costing gas - as it does now?

[3.id]

Just seen this thread is very old - has anything happened since? Any updates I can follow? Thanks again

[larry]

We just discussed this on tonight’s BNS Working Group call.

We’ve generated a list of possible features for BNS 2.0 which will we share soon. The next step is to share them with the community for discussion followed by writing a draft of a new contract to propose to the community as a hard fork.

[3.id]

Looking forward to it - thanks Larry

[Stijnnys.btc]

In the pace there are also a lot of question about ordinals and BNS names , … there are sites where you can inscribe and I guess register your bns name. and if it will have functions in the future . I don’t know if here on stacks we work on this.