Skip to content

Latest commit

 

History

History
161 lines (81 loc) · 14.5 KB

2023-09-14.md

File metadata and controls

161 lines (81 loc) · 14.5 KB

BNS Working Group public meeting (2023-09-14 22:34 GMT+8) - Transcript

Video

https://youtu.be/nxNQv1Opkqg

Attendees

Don Ruiz, Gina Abrams, Hank Stoever, Larry Salibra

Transcript

This editable transcript was computer generated and might contain errors. People can also change the text after it was created.

Hank Stoever: Just quickly just wanted to share that I posted an update on the Forum post for Bns on L1. The TLDR is that but I would say, 95% of the development work is done and actually merged on get every code, the actual Inscriptions flow is like It's not live. It's behind a feature branch. I'm working with Gamma to Get a proper collection page. because I think that's just really critical otherwise, It's just kind of a random assortment of inscriptions as well as dialing in the inscription, service to make it easy, especially to do an HTML inscription, which is what this is to sort of save a lot of data or fees.

Hank Stoever: But otherwise there's a couple new feature features on dots that I build kind of in support of this. But are helpful regardless, one of which is the Feature as well as name pages. And I think the main use case other than something like Gamma where you can already search Bns names is just kind of really lays out all the metadata including zone files. So go ahead and check that out, open for feedback, etc.

Hank Stoever: Yeah, so I think the main topic that I wanted to bring up today is related to the Nakamoto upgrade for stacks. And it covers a lot of different things including Svtc but also faster blocks.

Hank Stoever: so, instead of having one stax block per bitcoin block, there will be many stacks blocks in between every bitcoin block. So as a consequence of this, The. Stacks Core team is figuring out what to do about the keyword in Clarity block height. It's just like a variable and it just equals the current stacks height. there's a number of contracts, most importantly for this conversation Bns, which use this block height keyword to do any sort of time-based things. one of them is for expirations in the Bns contract.

Hank Stoever: Expirations aren't in years, they're set in blocks with an assumption that in the long run. Each block will average out to about. 10 minutes. So for Dot PTC, it's five year renewal, but in the contract, it's specified as Five years worth of blocks roughly, I forget the exact math right now. It's hundred forty four blocks per day times 365 times 5.

Hank Stoever: In Nakamoto again, with faster blocks, there's a discussion happening around what to do about this. Block height keyword and one of the possible outcomes is that. The blockhead keyword Still reflect exactly what stacks height it is but these blocks will happen much potentially like 120 times faster. So expirations which were again measured in block height will happen about, a hundred times faster potentially. So you'll have to renew instead of every five years. about every

Hank Stoever: What's the mat there? Every not Finn five minutes…

Larry Salibra: Every five minutes very frequently.

Hank Stoever: but three. No. Whatever, 0.6 months potentially.

Hank Stoever: For BTC anyways, it doesn't really matter. The point is that it's significantly changed another Part of the Bns contract where blockhead is used is There's a minimum expiration between when you order a name and you register name and similarly for namespaces which will now happen. It'll go from I forget. What it currently is, but I think two days. But down to about 12 minutes so, Fortunately, with faster blocks. Maybe this isn't nearly as big of an issue with renewals, but It's still, a different factor to consider. So I'm personally really advocating for

00:05:00

Hank Stoever: Part of this upgrade to basically treat any clarity contracts that are in clarity version one or two, which is all current contracts. To have the block height keyword, I mean return a different value, which would basically be equal to, how it exists today. The word for that is called tenure height in the Nakamoto, upgrade, but basically have backwards compatibility, I'm not on the core team. It sounds like That's, a good possibility. I think it's Pretty important decision to make, especially, because it's not just Bns, but various other apps that are doing similar, time-based the logic in their contracts, some of them also use block height so, for Bns

Hank Stoever: number one, we just need to be, really aware of that I think, without the core team's not gonna make this decision lately and so being respectful of them, making the decision that they feel is best. It may be helpful to advocate for this sort of backwards compatibility type of feature. But otherwise, we just need to really be aware. And so let's talk about the things we need to think about if that backwards compatibility feature is not included and thus expirations are significantly faster. In the short term, there are definitely some options. That are not great, but, some sort of a stopgap, I guess you could say.

Hank Stoever: with Bns X, for example, because there's this rapper contract, that's kind of holding the name itself. They're already is a name renewal feet function, that's exposed through the wrapper contract. So obviously you can renew your name even if it's in bnsx. and we can modify that or even just use, not bnsx, but something, similar just for this purpose where anyone can actually renew a name.

Hank Stoever: Just like this exposed public function and anyone can call it and it'll just call the underlying renewal function, especially, because renewals don't actually costs anything. At this moment, you could imagine some sort of public good or just utilities or whatever that make these bulk transactions, that renew a hundred names at a time. And, every day, it's just like, bumping out a bunch of transactions to renew any name, that's set up this way.

Hank Stoever: That's in my mind, sort of a short-term solution. More medium term or just certainly more critical for the long run would be to make an upgrade to Bns. Yeah, we've talked about this at length, there's a bunch of posts that I made on the forum, kind of proposing, various different feature sets. Myself, I've been working on this L1 project after getting something back that. it may be more useful in the immediate term especially considering sort of like the scope of work required for Bns upgrade.

Hank Stoever: But with this change, especially Again if it's not backwards compatibility it's almost like okay mandatory we need to figure this out ASAP and obviously priority one would be Okay. We fix this expiration bug to use different logic for time operations. but no matter what, whatever kind of upgraded is just, Important. I mean, I think there's a lot of things that we could do, even for example,

Hank Stoever: the Nakamoto upgrade happens, Bns is not upgraded yet. The upgrade contract could have some sort of logic to say, the name that you can claim in this new contract is we're gonna check before the Nakamoto upgrade because, then, even if it did expire because you just weren't paying attention and a month went by You'd be able to Get your name as kind of would be fair. Anyways, I'll stop there. I know I talked for kind of a while but yeah, I'd love to get thoughts and just discuss this.

00:10:00

Larry Salibra: Ask a question. …

Hank Stoever: Course.

Larry Salibra: is there any information about the status of Atlas and the Nakamoto release and Zone files? And if it's been a remain as they're going to be a six to fix the bug where only the current Bns contract can use that functionality.

Hank Stoever: No idea. I just kind of see scattered things, the occasional I don't know. document there but Especially with this stuff I should really, start to pay a lot more attention. So in discord as well, this tax core devs channel started to check that much more often. I don't know. Yeah, but that's a good thing to call out.

Hank Stoever: My suspicion is that.

Hank Stoever: I doubt that it's currently the plan to open up Atlas to not just the Bns contract, because You kind of opens up like a DDoS is not the right word but sort of a details. Vector, because

Hank Stoever: Then every Stax node holds every single zone file. And there's a lot of prison comes to that but obviously the con can't just be an open creeper all storage network. So these restrictions they certainly have downsides even just for Bns

Hank Stoever: I can understand why, they've done it that way so I don't know.

Larry Salibra:

Larry Salibra: Okay, it doesn't really sound. I mean you could accomplish anything through the Bns contract that you could do by opening up to other contracts. Slightly more complicated. it's the argument of Anyway,…

Hank Stoever: Yeah.

Larry Salibra: I want to print a topic but it's the argument of instead of setting a price, you're just making it complicated.

Hank Stoever: you're right, I mean you could just called name update and just put whatever you want and it doesn't cost anything other than the transaction fee.

Larry Salibra:

Larry Salibra: so it sounds like an action item with pizza look through the upcoming release and…

Don Ruiz: but,

Larry Salibra: make a list of things that The community to do for the penis contract and so that's one of them. just like that, look at, all of the things that are changing and then how it affects Bns and every way

Hank Stoever: And to work with. Some of the core team members who at least try and see if there can be a decision made. As soon as possible. This is the kind of thing where it's not just Bns but other apps where if this kind of breaking change happens, work needs to start ASAP. So certainly by the next time this group meets I think I would really hope that, we can have a court decision made

Larry Salibra: Yeah, no, I agree. I think one of the problems we saw I don't know Between his current version of Jackson. Previous one, was that Bns became basically non-functional for a period of time because the new tax launch but there was not really clear. what was being done? And I think it's really bad for the whole layer if you just break a whole bunch of smart contracts just because you're trying to get spdz out or whatever reason.

Hank Stoever: yeah, I mean Yeah, I assume it's all, certainly in good faith but yeah, I understand that.

Don Ruiz: I have a question that Hank, it sounds like the Bns at some point. We need to be in this upgrade and whether or not if there's no backwards compatibility it's kind of pushes us in that direction. But there is some backwards compatibility, we can kind of kick that can down the road a little bit. Is that accurate?

Hank Stoever: yeah. Mainly because it's extremely time critical. Yeah.

Don Ruiz: So what? You touched on this and I know that you have some information in the form. What would that be? In this upgrade entail in your mind at this point. And we'll even required for resources.

Hank Stoever:

00:15:00

Don Ruiz: And As well.

Hank Stoever: yeah.

Hank Stoever: I can if you search in the forum and I'll just post the link now. it's this sort of of threads, it's like a link to a bunch of different discussions, one which, There's contention, but I think consensus around more than one name per wallet. That's a big one. Some issue like actually making renewals cost money because they did originally and they were sort of supposed to, but it's just kind of a bug in the current contract that it didn't get included.

Hank Stoever: A couple other different making it a sip nine NFT so that it's just default compatible and in every, that's sort of a simple and just because this sit9 didn't exist at the time. so a couple things like that so that's what it entails and then in terms of the work required, Step one is sort of getting to consensus around what is actually included.

Hank Stoever: We've discussed this in some of these working group calls. A couple months ago, I suppose. I don't think we ever came to a clear decision that means if X then why in terms of consensus or not, it's kind of the messy thing in terms of what's it? It's just messy but we need to figure that and then it's development work. So That's just a lot of writing clarity and And lots of testing. Lots of sort of feedback from, auditors probably and just community in general and then going live and really just trying to work to get as many apps adopting it as quickly as possible. I think it should be said that.

Hank Stoever: Almost certainly an upgrade would entail a new contract instead of, sort of replacing the current contract for a number of reasons. But It does mean that, there's some sort of migration process that happens so potentially some tooling slash apps or whatever to help that.

Don Ruiz: Okay, thanks. That's helpful.

Hank Stoever: I think there's that we should definitely spend more time figuring out exactly what those resources are. I mean, I've personally committed to work on this so I could think just kind of off the top of my head. it might be helpful to have help here or help there. But it's exactly what help and exactly Do we need designers doing, community members etc is uncertain.

Don Ruiz: Certainly can't all fall back on you. And this seems like Would be a pretty major project and some significant changes. That. We really need to think through.

Larry Salibra:

Larry Salibra: Okay, do you think for super next in two weeks we should have before that which is get together a list of changes And the next version of drama released and how it's going to affect DNS. And then try to have that together a few days before and…

Hank Stoever: Yeah.

Larry Salibra: then discuss it then.

Hank Stoever: I'll reach out to, I don't…

Larry Salibra: Yeah, but

Hank Stoever: maybe to Walker or someone I could look through whatever's available but I think it's probably just better and more fishing to have someone who understands the whole scope of Nakamoto and can kind of think through this this might be relevant that might be relevant.

Larry Salibra: That sounds great. I'll also spend some time reading up and github issues and Keep it. I can figure out from code.

Hank Stoever: Awesome. Thank you.

Don Ruiz: That we'll look at things on their side as well, Hank, and try to collaborate with you.

00:20:00

Larry Salibra: I unfortunately need to run. you guys are welcome to continue but I'll get the recording when I arrive and make sure I upload it in a couple days.

Hank Stoever: Sounds good.

Don Ruiz: Great safe travel.

Hank Stoever: I'll hop up as well.

Larry Salibra: Thank you.

Hank Stoever: This was the main thing I wanted to cover sounds like we did. So, yeah, have a great day, everyone.

Larry Salibra: Thank you. Of.

Don Ruiz: Thanks Larry.

Gina Abrams: City.

Meeting ended after 00:20:41 👋