Megathread: BNS upgrade discussion

BNS
11

Hey everybody,

I wanted to provide an update and some next steps here. Earlier this year, I joined Trust Machines, and since then my main focus has been to contribute to the Nakamoto and sBTC launches, which I believe are crucial for the entire Stacks ecosystem. I’ve always been invested in BNS, including the work we did to build BNSx and Dots at Mechanism. Even though my focus has since shifted away from BNS development, I’m as excited as ever about the potential for BNS. While I’m not working on BNS directly, I have been advising the Orange Domains team regarding ways to help BNS move forward. Orange Domains has been allocating a ton of resources to both BNS core upgrades and app development.

To that end, I’m excited to share that we have collaborated on next steps for nearly all of the technical upgrades discussed by the community over the past ~1 year with strong support. Below is an updated proposal for the work.

The following features have been determined doable:

  1. SIP9 Compatibility - make BNS more composable and market-friendly
  2. Multiple names per address - allow Stacks addresses to own more than one name
  3. Managed namespace improvements - extended functionality for fully-customizable managed use-cases such as token-gating mints or paying with sip10 fungible tokens
  4. Registration flow - improve both the UX and security of registrations
  5. Require payment for renewals - a bug in the current version of BNS doesn’t actually charge users for renewals, even though that was the intended (and previous) functionality

There were a few items originally suggested for an upgrade, but were determined to either lack broad support or add too much complexity:

  1. String Data Structure: the proposal was to change the underlying storage types for name and namespace to string-ascii, instead of the current buff. This was always considered a “nice to have,” but after looking more into the complexity of implementing this, it was determined that it wouldn’t be worth it.
  2. Supporting sBTC for payment; managed namespaces support native name registration via any SIP010 token, including sBTC down the line. Additionally, wrapper contracts can provide functionality to pay for name registrations with sBTC and other tokens.
  3. .btc pricing changes - overriding pricing and expirations for .btc names violates the original parameters of the namespace
  4. Zonefile resolution changes - updates to how zonefiles are resolved and updated don’t need to be part of the v2 upgrade, as those changes can be implemented separately.

The development work on the BNS V2 smart contract is set to be completed by the end of May, 2024, to be followed by a transition and upgrade period for apps and protocols.

We’ve been gathering early feedback on the best path to provide users the option to use this upgraded BNS protocol. It’s not technically possible to automatically update the BNS contract from BNS V1 to BNS V2. The other paths worth considering are 1) forking BNS and providing everyone with their same name on V2, or 2) having users individually upgrade and migrate their names to BNS V2. Both options have pros and cons with complexities, costs, and considerations to be further explored. It’s important to note that any upgrade path will not allow names to be registered on BNS V2 that are already registered on V1.

We’d love to hear your thoughts and feedback. Cheers to further progress of the original Bitcoin Naming System

Thanks,

Hank

10 Likes