Provable count trees enable efficient querying of aggregated data in decentralized databases by maintaining count information at insertion time rather than query time, allowing operations like counting items by value, range counts, and histograms with logarithmic complexity (log n) while providing cryptographic proofs without exposing all underlying data.
深度探索
先修知识
- 暂无数据。
后续步骤
- 暂无数据。
深度探索
DCG Development Update - 2026 May 12本站添加:
Hello and welcome. This is the VCG development update. We are here with the platform, the core and mobile teams to give you an update of what happened over the past two weeks.
And I'm I'm sure if it is streaming, but I think it is. Uh so we will we plan to have a dedicated Q&A session. So if you have any questions, please put it put put them in the live chat below using a Q or a question prefix.
And uh without further ado, let's write jump right in. Let's start with Sam and overview.
>> Yep.
Hello everybody.
>> Hello there.
So, we the big focus is getting 3.1 out and there's going to be a little bit of a there's a big update there. Um, - SPV and iOS. It's pretty much the same thing. Uh, but uh I I'll I'll explain what's going on and how we are shifting gears a little bit. Uh so dash evo tool luc continued on that rust-core same I mean pretty much very close to the same thing uh 3.1 shipping was me and yon so let us go right into it and I will kind of well no I mean okay so for me um last two weeks big thing was well for the first week or so I worked on iOS getting iOS out getting shielded balances on iOS, getting, you know, a lot of things like that, right? And I started being able to send shielded balances on iOS. Uh I don't have a demo for that today because it's kind of out of my mind. It's been uh it's been a week, but uh we you know, a lot of progress was made there. Then um I you know once we were at a spot where iOS was you know at a stage where well it's closer right it's not done but it's closer. Uh the big thing was we need to ship uh 3.1. So I shifted gears to basically ship 3.1 out. Um and let's we can go to the next slide.
Next. Press next.
>> Yeah. Yeah.
>> Okay. Yeah. So, um there we go. Uh so, there was a lot of work needed to get 3.0 out. We need So, um Abnik's team reported two uh issues that we needed to fix and uh Evan fixed them.
Um, we had uh count trees for Yapper that were uh started to be written, not finished in a pretty uh unstable state that needed to to come out. Uh we had three shielded balances issues and um we had a lot of other things that needed to just kind of be uh finished um all around the board. Right. So that was that's been my main focus for the last week. Uh we fixed the issues um from platform for platform explorer. Uh we finished the country stuff and we finished two out of three of the shielded balance issues. There's still one left that I know of. Um so we're getting very close to having that done.
Now the amount of difference between 3.0 0 and 3.1 is very big now. Um, and it no longer makes sense that 3.1 is a minor release.
It's so we're going to rename it into 4.0. Um, because it's just it's it's just uh we have all of shielded balances in there. Like if there was just at the very beginning shielded balances that could have been like a 3.1 kind of in the 3.0 family, you know, 3.0 I know was platform addresses could kind of understand but the amount of uh new features around countries um it just it's not minor anymore. So uh we're we're going to release it as 4.0.
Okay, let's go on.
Yeah. So this is kind of the summary.
It's very close to the previous summary.
Um I'm going to talk a lot about Yeah.
So this is kind of my work but I feel like countries was you know let's just say a lot of time uh getting getting all of that done. Uh PR count is definitely not effort. Yes. Uh but um yeah let's talk about uh countries and verifiable accounts.
So yeah, so now uh that the thing has merged uh what can you do differently uh you need to tell your well we're going to kind of explain how you can set up your contract to have these features but uh things that are now possible and I'm sure pasta you're going to be very happy with these. So uh the first one is get uh like count how many types of a document you have total with no filter. It's just one read in the system now, right? So before that didn't exist. Um you can also count filtered by inequality. So you could say um if you had I don't know cars for example, you could say give me the count of cars that are red. Or you can say something even more filtered like uh get me Mazda's uh get me Mazdas in this parking lot that are red, right? And how many are there? Um and then you can get a count and it's actually just one read and it's one proof in the system. You don't get back all the elements to prove it. You just get one count uh proof. So it's very efficient and uh so once again I do not know if any system like this exists ever has been built. So all of this stuff is completely new. I don't think I didn't use any research that had previously existed. Um so yeah I mean it exists obviously in SQL and many databases but it doesn't exist in a desend uh in a provable merkelized uh tree structure.
Okay. So then we have split count by in values. Um so that's um yeah you you can split it by in values one number. We also have stuff with a range count and that's much more interesting right? So you could say um give me people where the age is where whose age is over 30 between between 20 and 40. That makes no sense. Okay. This was a bad um a bad example but uh you can get uh range counts uh and a count and the size of that is actually um uh the the the the query complexity is log n. So it's very efficient. Uh and I'll kind of explain how that's done um later. Again, it's with our provable count sum uh provable count trees and um yeah, it's very very cool. Um you can also get histograms across a range.
Uh I'll kind of explain that later. Um yeah, so this is a big big upgrade in the system. Um while we were kind of in a in a weird state and you know we could have pushed this out to the next version and you know shipped faster but um it was some of it was already written in some was not and just uh it was better to just take the take a week to push it all through uh instead of uh leaving it in the state that it was in.
or we're trying to remove it because I know pasta really needs it for Yapper and a lot of people need it for the data contracts that they want to do and it's like it's a really important feature for queryability. Okay, next.
So, how do you uh do this? How do you get in? So if you want uh to query on your primary uh key you can put in uh documents countable to true. Uh the primary uh tree then becomes a count tree. Um you can also put range countable true and then the primary tree becomes approval country.
If you do range countable you can also um get your items through blast sync.
uh eventually we haven't coded up that feature but provable account trees allow like uh blast sync on the tree. So just you know another um just an interesting part of that. Um yeah. So if you want to instead count by indexes, you put countable true on the index or you can put range countable true.
Um they don't it you know while it says like countable gives a country and range countable gives approval country that's not actually how it works exactly. The range countable actually puts gives a provable country um on a different level. And I'm going to try to show this with diagrams afterwards.
Uh let's go on.
Oh yeah, show me the JSON.
So um if you just want the totals, you put countable true. If you want like filtered counts by a certain value, you put uh on the index countable true.
Um and if you want it uh like range counts on an age, like you can do range countable. And then the range countable could allow you to say like how many people in this like how many people have registered over the age of 45. you can do that query right and it will give you back that response with a very small proof right because it's all aggregating at insertion time and not at query time that's the that's the power of the system um these these are slightly more expensive uh so the default is not putting them on u you know in a distributed system you have to pay for everything but you know it's just very marginally more expensive it's not like twice the price uh for an insertion. It might be um well, let's actually think about it.
So 90 uh it's about 8% more expensive um when you have something countable and maybe 12% more expensive when you have something range countable. Not exactly sure. That's like uh just uh the math that I just did in my head knowing that uh the sizes uh will increase. But yeah. Okay, let's go.
Let's go on.
Yeah. So, picking the rights uh flags.
Um yeah, this is I mean you can you can read this a little bit more in depth.
Um, but I don't think we need to to present this right now. I think the diagrams coming up are a little bit better. Yeah. How you want to call it from your app.
There we go.
How does a range count stay login?
Yes. So, for example, if we say um, no, don't do next. This is the thing I wonder.
I see you.
>> Um, so for example, let's imagine you have like a very big tree here and you want to say get me thing, give me the count of things over C. Uh, sorry C equals 2. Well, basically this is a very bad example. Um, sorry. Uh, I had it better.
I anyways so if you know what I'm going to actually uh present it in the documentation that I wrote. So I'll go over that right after this.
So let's let's let's go on at the end.
I'll just present the documentation where the it's a lot better explained.
Yes. So another thing that I worked on was the count index tree.
because why stop at something really complicated when you can do something even more complicated?
Um, so in normal SQL databases, there's something called a having. Um, right if anybody's ever uh used SQL before and having is more like uh what what can it actually give you? It can give you like give me the five people using the system the most, right?
That's kind that that would use a having tree. Um >> and there's a lot of there's a lot of value in that you can for example you can do trending topics on Yapper would be something that could be possible once we have having trees. And you know I started um while I was working on the previous stuff I started thinking how can we do it and I actually figured out how we can do it. So I wrote the pull request for it in Grove DB. It is now 18,000 lines of code there and um you know it will take another week to ship.
So I don't want to actually delay 4.0 uh for this feature. We're gonna actually move it to the next version. Uh, but it will be really I mean it's doable and I figured out how to do it and um yeah, so we'll have that uh in 4.1. I'll I'll make sure it's a fast follower because I do want it. I just, you know, we we we need to to get the next release out.
Uh just so people know kind of how it works. Uh there's basically a secondary tree that just aggregates your counts or or counts or sums or averages or anything that's aggregable. And you we have uh we can choose you can choose sum, you can choose average, you can choose uh count so far. Those those are the three that will ship. So it'll allow you to do things like um if you have all the grades in your system of people right let's say people got you know 75% 80% you can say you can query the system and say uh give me all people ordered by that by the best students only give me ones that pass the class, you can do some like really advanced uh cool stuff there.
So, you know, again, this has never really been done in a decentralized network. So, you know, we're trying, you know, it's going to be I mean, I think it's it will allow a lot of new features. Uh it's a very uh maybe geeky talk right now, but uh it'll be very cool what this actually brings out when it's released. Okay, next is Yeah. So I worked on the shielded credit pool integrity hardening. Uh let's talk about that. So, uh, yeah, we had, um, we had two sources of truth for the most recent anchor. I removed one of them. You had all the you had all the anchors and you could just like actually, um, get the latest. And we also had we were also storing the most recent anchor and it didn't make sense to have them twice in the tree.
So, I removed one of them. That's not really a bug that we I just I just noticed it as I was, you know, as we're getting ready to ship this and I'm doing a final review. I was like, "Wait, why did I do that?" Um, then the big issue was the the 3624, which was a fixed credit not balance regression.
Yeah. So um I I thought I had a diagram for that but basically what happened is it was also having to do with count trees. Uh actually no not even countries sum trees. So um we were using a count sum tree internal to a uh count uh to a sum tree that was uh dealing with balances.
And the the basic thing is is that uh the trees uh the sum trees take the values and they migrate up to the parent. And in this specific case it we didn't want it to migrate. So I created a new fe uh a new system where they don't migrate and then that's been fixed and it also was uh you know work in growb to to to build out that system. So now that we don't have the credits not balanced uh issue.
So we're getting very close for shielded balances. Um yeah, I had uh I did the first shielded balances a week ago. uh transfers um on iOS because basically I want them on iOS before we ship just so you know there's no um like you know there's not a lot of work to bring out it to iOS.
Okay, next. Swift SDK and example app. Yeah, a lot of work here.
Yeah, lot of work. That was like my first week. Key wallet refactor. Yeah.
Yeah.
Let's go on.
Oh, why we're renaming to 4.0.
Um, yeah, we have six new types of elements.
Uh, I mean this is actually the most This is on par with the token release, if not bigger. Version 2.0. Uh, I would say, yeah, 2.0. They're all very big.
2.0, 3.0, and now 4.0. So, it doesn't really um make sense to have this as just 3.1.
Let's go on.
Uh, I don't know why it's putting the test coverage here. I We're We're done with test coverage. I haven't really worked on that because I'm working like non-stop. I don't spend as much time that I should on this. I re review it really quickly and then I'm like, "Yeah, looks good."
Um, okay. I'm going to quickly share my screen and show uh the new documentation because it's pretty nice.
Okay.
Where is it? Where is it? Where is it?
Oh, here we go.
>> You guys see my screen?
>> Yes.
>> Excellent.
Uh so, uh yeah. uh basically indexes and uh we have a lot more information on how indexes work um in um in in the in the book, but I Oh no, it's not showing the flowcharts.
Oh, it was working. We I don't understand why it's not working.
Anyways, we had beautiful flowcharts here. Um well, I don't have them anymore anyways, but it it explained like uh how how the different indexes work.
Uh well, that's you know what? I'm going to get it working and then u you'll come back to me at the end. Okay.
Okay.
>> All right.
Um, do you want your slides back?
>> No, no, we're we're Well, yeah, sure.
Why not?
I think there might be some more stuff in there.
>> Okay.
>> So, here we were documentation and daybyday timeline. Oh, doesn't matter.
Doesn't matter.
>> Summary.
>> Oh, it doesn't matter. Just let's move on.
>> All right.
Um, wash.
>> Yeah. Hi.
So, basically in this uh sprint in this last two weeks, I was uh focused on two things. First one is platform wallet that uh the team had developed and I s a QA for that and I was also doing some maintenance level tool work not not so much but but just a bit uh so the high level uh view is that we are planning to integrate the new platform work into dash evo tool hopefully in the next two weeks. It should happen. But right now, I'm just checking how it works, doing some tests, stuff like that. Yeah, let's go forward.
Yeah, in terms of platform wallet, I did some improvements.
Uh the first one is that yeah there was some bug uh in input selection that caused some issues.
Uh basically that was just a bug fix.
uh there were collisions in so basically the main effort is single credit in terms of development but the tests were running uh stuff in a highly multi- threading environment with sending multiple transactions from the same wallets and stuff like that. So there was a race uh where uh parallel sends from the same wallet had a chance to try to double spend some funds. Basically it caused errors and issues but it uh we have improved this behavior a bit uh in this PR.
Yeah. And there were some minor fixes like uh uh the when you have add username and our uh DPNS usernames have the dash suffix by convention but if you put like uh capital letters in the username on the dash suffix we didn't like drop it.
So it it's right now fixed and normalized so that we accept both. So the these issues were more related to dash evol and testing of dash evol and and to to learn in the platform wers and on the next slide uh uh yeah so my main focus was on testing uh platform wallet. I got a big test specification. I don't know 50 tests or so or even more.
Uh there and right now I'm slowly going forward with the tests. On the chart here you can see uh how many of the tests are passing, how many are failing.
These failures can be bugs in platform world can be bugs in the test still in progress basically and just uh a few other uh other tests still to be written and processed. So once the tests are more or less stable, I need to go through all these failing uh failing tests and either fix them if these are triggers or file a bug and discuss with the team how to fix this if they are more complex.
That's basically the status like looks like from the chart looks like I'm in the middle of work here and but I think it's much more done than still left because it also introduce a test framework that is running all these tests and also some uh some new features in terms of platform wallet. So first one is that we want to have a separate we call it persist persisttors in in platform wallet. So we we will have a separate trade for managing where we store data from platform wallet. It's modular so we can store it anywhere and I'm doing SQL SQL light pistor that will just just be shared and developers will be able to use and it might it will be used in dash evo tool so it's all done in the direction of dash evo tool yeah yeah small improvements to SDK there is new test net and new mainet function that was not implemented previously right Now it should correctly determine a list of uh of uh DPY endpoints that these networks should use. So basically if you initialize the builder with a new test net or new mainet this this SDK should just start working out of box. That's the idea right you don't have to know anything any end points anything. Internally, it will use a hardcoded list of endpoints that is distributed with the the product. There are a few other approaches possible, but I don't want to get into details here. Our goal is to have that decentralized and to not really on any centralized service. So, we just hardcode a set of IP addresses that can be used uh in the default configuration. Of course, you can always override at least. It's just a con convenience method to make it easier for developers to to use.
Yeah. And some some documentation improvements. It's nothing interesting. So, so much in terms of dash evo tool. It's uh in a mode of small maintenance uh in terms of uh we don't want to do too many changes because we want to integrate the the platform world there soon and it will just conflict. So it will be double work. So we need to finish that the the wallet first and then hopefully in the in this spring that we just start we will go through integration into the platform into D evo tool and and work on it in normal mean normal mode from now on.
So basically three uh main things here.
First one is that there was some uh uh some bug and that not all information was displayed. So it's fixed and two in progress. First one is quite a big update of Egi library that is the primary library we use and uh and basically it's it has some breaking changes. So this PR is meant to fix these breaking changes and uh yeah so yeah that's the the last one is is basically the same topic. So it's just fixing some deprecated uh so so outdated uh methods we use uh in the code to just have a clean baseline software.
Yeah. And I think that's it on this slide. I think we are done. So not so many PRs because the biggest effort I'm working on right now is uh in in the in one big PR with the tests for platform one basically and that's pretty much it on my side.
>> Thank you very much.
>> I have the I have it. I have it. I have it.
Can I share >> please?
>> Uh, replace current share.
>> There we go.
I thought this was actually quite cool because um it kind of explains how platform actually works under the head under the hood and I think you know I I don't think many people know it right how how we're able to prove all the data with secondary indexes uh but this also shows uh like what's a country what's not a country so in black we have the normal trees and in Um, uh, I don't know what color this is.
Yellowish pasta. What color is this?
>> Yeah, it's a yellowish a beigy yellow.
>> Yeah, there we go. So, um, yeah. So, if you wanted like widget is just the document type. I don't know why I called it widget, but um, it has a color and it has a shape, right? So if you want to find how many widgets are red, it goes color red and then there's a count tree and the count's two.
How many widgets are blue? One, right?
How many widgets are red and a and a circle? You have one down here. I mean, there could be more than one, right? But it's just so the diagram shows on the in the area, right? Um so yeah, basically this is how you can count specific things. Um this is actually not the most complicated part.
The more complicated part um is when we now have this right this is this was uh the first naive approach this is what we have today uh after a few days of work for me. So um you can say let's say you had red, blue and green. Uh actually blue would be on the left side then it would be red then it would wait B g yeah it would be blue G because blue starts with a B right it's before red they're actually in order. Uh, so normally blue would be on the left side here and red would be on the right side, but it doesn't really matter. Um, if you said get me all colors greater than red, um, you'd use the provable country in the color and then it would go down to blue, which would be a country of one.
There'd also be green, which is would be a country of one, and there would be basically an aggregate there. Um, I will show how that works a little bit later.
But as you can see, we also have these new things called non-counted because otherwise the um the uh the the uh the countries could migrate north. So if you want to do a composite aggregation, you might have a an aggregate, you might have shape be a provable country in which circle in which case circle or square become um countries as well down here. In that case, shape uh if it's a country then would migrate its count up until red and we'd have a bug, right? It would not it would not match. So we now have this non-counted that basically can encapsulate any element and it makes it so it doesn't translate the count number to the parent. It's a new feature of grow DB.
Um I want oh why do I not have why we can do aggregation?
Is it not here? Is it not here? Maybe in document countries.
Uh maybe here.
Why internal node count make range counts o log n? Yes.
Uh we actually had a really good diagram but I think it got destroyed somehow. Yeah. I don't see it anymore. But um yeah, it doesn't it's no longer there.
Uh this is what happens when you I don't know. It must be on a pull request somewhere.
I Oh, it's in the Grove DB documentation.
Okay, please continue, guys. Eventually, we'll find it.
I'm really like it's really very cool what I built. So I I do want to show it but not right now.
Please um >> please continue with >> Can we continue with Ivon's work?
>> Oh yes.
Um yeah. So Yvon's working on identity funding with asset lock in the platform wallet app.
um fix paid unpaid classification. We already merged that in. I don't know why he said in review. Uh and he's been working a lot on unify JSON value conversion traits in um JavaScript.
>> All right.
>> He's been working on other things. I don't think he's very good at saying what he does. Um okay.
Let's continue. Um, Borha.
>> Yeah. Hello. Uh, well, today Kevin isn't with us, so I will be doing his section again as usual at this point. And, uh, the most important points he was working on the past two weeks uh was disconnect resilience sync. So if you remember the last uh presentation, the last yeah the last presentation where we show the example app, it was hard to sync with bad connection. So he was working on making improvements in that area. This is one of them. Then filter sync correctness uh where filter sync mean flight code could freeze.
He also work on wallet runtime improvements. Uh here he is adding the chain locks to the SPV client. SPV client is not right now aware of chain locks. So we are working on that. That will help me also implement the asset locks.
And so eventually we could we could see uh the example app being able to send from core to platform. That would be nice. Uh uh he made some improvements in the login and really important continue to work on integration tests uh master know stuff avoiding future uh regressions in our in our code.
a thing that I really love because I hate to work on things I already pick to be honest. So that would be and now if we go to the next slide I could talk I can talk about what I've been doing and okay there you go. Basically my work right now is uh all kind of transactions I would say from core to platform and core to core. Uh previously core to core transactions were were working but after some internal changes uh they just stopped working in some cases. I've been working on that and I will continue to work the this this week I think I think I will have it done for this week. So I will continue to work on that. Uh after that I will go into acid locks something that that I would love to have and then I finish well I'm talking about swift SDK though but it also applies to Ras dash core in some way. Uh what what else? Yeah, I also finished some re refactorings in the FFI side that allows to have better code and something easy to work with.
Then I also b RA version to latest uh commit we have uh with this I introduced a fix I did in RAS dash core previously and confirm balance and change balance was not being used uh when creating new transactions now they are being used which is cool and something that we really need to to Then what else? What else was um yeah also fix some balance and transactions issues after the internal change I already mentioned and I don't think I have anything else important to share. I mean I al I've been also refactoring some rascore things especially the transaction builder track we have to build transactions uh why basically we have some logic here and there I made everything uh more consistent and easy to work with since I want to get all the kind of transactions working I needed that to get I need the log logic to get centralized somewhere so it's easier to spot issues and fix them. And yeah, I think that would be all main focus transactions to be honest and cleanups.
>> Thank you very much.
>> All right, one second.
I need one second to share. I think we can continue with mobile.
Oh, sure. Uh, usually I go a little bit later, but that's all right. Um, okay.
So yeah, I mean as previously this kind of combined mobile wallets and the Dash website tool or Dash website really as a whole. Uh there's really two pieces to that, the tool and and the actual website itself. Um so those are the kind of just the tallies of the different areas of work. Um you can scroll past that to the next slide.
>> I did uh also the executive summary.
Should I?
>> Yeah, you can scroll past that. I don't know. It's just tech. It's just text. Um I mean, not to discount, you know, what was done on the mobile for sure. Um still, you know, a small team and >> and the website is uh there's a lot of work going on just just from a migration standpoint bringing things over from from the current website um contentwise and then obviously the uh related improvements and fixes to the tool itself. Um but good progress on on both fronts. Uh you can move on. Yep. On Dash Wallet, I guess one noting mention here is we do have a new part-time uh iOS developer which has been great. uh been able to help out with kind of general maintenance and other you know continuation of our feature features and uh and other integration work so we can keep parody between you know Android as much as possible as we continue on with our iOS- pay related work uh in parallel. So um we had a few things relating to translations that needed to be addressed. Um, I'll show a couple designs relating to a new feature on Piggy Cards, which is, you know, one of our gift card providers for Dash Spend.
They had um a need from a regulatory perspective. There were a lot of people that were buying multiple gift cards basically in multiple transactions. Uh, and that was flagging issues from a a risk perspective. So, um there is limits as to how many gift cards people can can actually purchase, but being able to allow them to purchase multiple cards at the same time is actually a it's a better workflow for them as well as um it's it's not unnecessarily flagged as a as risky transactions. So, um I'll show a few designs on that and then um the just some refactoring relating to the gift card, you know, screens.
Uh started back into some Maya work uh that I was doing and I had to pause for uh you know, so I could get into some other things, but um that has resumed as well on Dashwallet for iOS. So, you can move on to the next slide covering Android. Um, I mean, we're always going to be making improvements to our sync process and, you know, shutdown restart was kind of one one area there. Uh, the same, uh, multiple purchase feature on piggy cards is is also going on Android.
Um, we had an issue with how we were receiving the exchange rates u for or prices for um, uh, for the Maya implementation. Uh, so that's why we weren't able to to release that. that needed to be fixed. Um, we found the solution. Now, we're in another final stage of of testing for that. So, that hopefully should get out soon for a beta, a public beta for people to start using. Uh, and then a small crash fix uh relating to our dashben explorer explorer map feature.
Okay. And then the next page gets into platform website which uh so a lot of things happen here. Uh it was on a repo outside of the D-pay or so. So one thing we I did was move everything into our org. Um that was kind of this initial move to start getting more people contributing. Um so there's other people on the team. Uh the fez uh Jeremy aka is is helping out there as well. um already adding value, having more than one person working on this, being able to add tests and whatnot. So, that's been great. Um, as the migration happened, I mean, so this got into a whole another can of worms, which I knew we were going to face, which was multi-user use of the tool.
Um, and that's something that pertains not only to the tool itself, but just the sharing of of website content across users. So there's there's different timing aspects to that that needed to be dealt with. Um and that's still ongoing and that that will continue to be ongoing as we get especially as we get more people using the tool uh in house here. Um but but this is exactly kind of how I expected things to pan out. It's it's great being able to see how everybody interacts with the tool uh at the same time independently. Um and and we're all kind of calling out different things that need improvement and and whatnot. Um but overall it's been it's been a good move there. Uh the next phase is getting another individual to help out with really the operational side. So to move away from WordPress, we need to make sure we have a good stable, you know, operational flow of making sure we can update the the content on the website, you know, as needed in the same timely manner. Hopefully quicker really is the goal than how we're doing it with WordPress now. uh and being able to again just continue making improvements to the functionality of the tool um not only for our benefit here to maintain the Dash website but you know once it goes public to the community um for other people that might want to use it um and one of the next feature big feature changes will be uh that I'm working on anyways will be migration to mainet so technically there's very little activity involved moving to mainet Uh technically it's just really putting you know the metadata on mainet versus testn net um because we're not currently storing a whole lot on platform. So it's not a huge technical move but operationally and being able to have the controls in place in the tool to do that uh is a little bit more um sophisticated. So that is taking a little time just to get the right design in place. uh as part of that having a better alignment with GitHub. So better GitHub integration is kind of key to that as well. Um so those two go hand inand but are both kind of major kind of elements or changes that are coming to um but the next month essentially will be a combination of people reviewing content both English and translated pages that are currently running on testn net and our our current um lighthouse storage solution. Um making sure we get take care of any any issues with content. um those that are using the tool, you know, making improvements and and fixing any bugs that may come up, particularly with multi-user use um and and production migration. That's all going to happen really over the next month or so. Um and then once we're happy, you know, um looking at everything, then we can, you know, formalize a plan to migrate away from WordPress, decommission WordPress and and and go from there. All this is being done on a separate parallel um domain for our own testing purposes. So um but yeah, lots of work on those PRs in in a lot of different areas. Um uh I already mentioned, you know, Fez joined up helping out on Dashplatform website. Uh Roman is the new iOS developer. Uh and they're both, you know, uh already immediately productive in both their their own regard. So, that's been great.
Uh, I think that's Yeah, that's pretty much it. I don't think uh you can read that real quick if you want, but nothing uh more to add.
>> Thank you.
>> Oh, sorry. I didn't uh show some design.
I was going to show a few designs. Uh let me do that real quick.
All right. Should be able to see my screen. Yeah.
>> Yes.
>> Okay. Uh, so one thing I didn't mention, design work often kind of doesn't get a lot of visibility because it's it's one of the first stages, you know, uh, to to any of all of the development aside from writing kind of the requirements. Um, but there is a lot of back and forth that goes there. One of the things um we've landed on is at least for now an MVP version which we're still kind of playing with a little bit uh for shielded balances. Um I couldn't find them immediately before this. I thought I had a few more minutes. But we this all starts I mean you can start it with an actual move or transfer to a shielded balance obviously before you create a username. But, you know, people that maybe aren't as familiar with privacy and shielded balances, their first, you know, intro to this would basically be when they're creating a username, they will just like now they have the opportunity on Android anyways to um they're kind of warned if they're not already mixing uh to first mix their balance, i.e. create some privacy um before they create their username. So, that that same flow will happen. it'll just refer to shielded balances instead of a mixed balance um by by use of coin join. Uh so if they're in the username process, they'll you know they can be directed here or they could come right here um via the same send receive screen that we already have that's triggered at the very bottom. Uh so we are working on this screen a little bit more. we we had it um a little bit different um but it does still show the general theme that not only sending and receiving with outside parties you know now it's a more formalized internal transfer process and it starts with shielded pools but the reality is we have a lot of different types of balances that people will be able to transfer you know between their Dash wallet um funds. So, this is just the start uh and to make sure we've got a good um area of of functionality for people to create their usernames when Dash Pay comes out. Uh you know, a simple process just to show all the different values. We are still thinking through how we want to display the large credit values. So, that could change over time. We might truncate or give the option to truncate, but for now, it'll just it'll show the true values. Um but again the key thing is is breaking this up to to differentiate that this is an internal transfer. Um you know for now it's just going from the Dash wallet to shielded pool. Ultimately you know there will be um features both ways. Um they go through a confirmation process with another little tip just about the privacy. again um they should wait a little bit of time before they actually consider it to be in its best state. Um >> and for now we're trying to this is another area we're we're still kind of thinking through on how we want to show different types of balances especially as we do introduce a lot more different types of credit balances. Um but for now given we're only dealing with two uh we're going to show them um on the more screen for now. uh and and and the way and the format this is shown likely will change over time, but this is just kind of the initial view that they'll have so they can you can make sure they can see see where their balances are. Um >> I would like yeah I would like to say one thing though that might be confusing.
When you send from your wallet to the shielded pool, you're you're not sending from your wallet to the shielded pool.
you're sending from your wallet to your wallet, right? You just have a shielded balance. You don't send I mean, it's a conceptual send, right? But uh >> yeah, I mean, this is where we get into I mean, in the in in the Dash wallets, we've always tried to keep terminology as layman as possible. Um we did originally have just kind of send receive, but I I wanted to make sure it was clear. this is not going outside of that person's control, let's just say. And and that's why I'm I'm classifying it. It's just it's a transfer between chains essentially. Um but yeah, I mean there's always going to be terminology. I've I've hesitated forever. I I would say literally forever since since credits even came into the picture on on having visibility in them in the wallet because it it gets complicated for the ad for for a person that's not familiar with all the technical bits that's going on behind the scenes. It introduces a whole lot of complexity and and that's the opposite of what we've always tried to achieve with mobile wallets is we want it to be as simple and straightforward as possible. But yes, I mean it's they're not sending it outside of their control. I guess you can say is is >> maybe we could just put shielded balance instead of shielded pool.
>> We have also Yeah, I don't actually have a super strong opinion here. I I kind of like balance better, but I have been seeing shielded pool being mentioned more than balances. So yeah, >> I'm open to >> being balanced instead of pool as well.
>> Yeah. Yeah. And for like a platform um balance and like uh like core balance, it's just loop grouped together in your Dash wallet invisible to users, right?
>> Well, we I mean for MVP for Dash Pay, we're just talking about shielded balances, but yes, I mean when we get into all of the other types of balances you can have, I mean the the the transfer process is expected to be the same. We just don't have a complete view of what all the balances look like yet.
There's a different a few different ways we can show the balances there. But but again that that that will be later once we um after MVP most likely.
>> Got it. Okay. And that also again I mean that brings again not only a level of internal transfers that we're going to be dealing with but external transfers when we're able to actually send to other users as well which whether it's available technically right away or at the same time you know isn't my point.
It's more there are two different aspects to that too that we'll have to be talking about. So yeah this is just the very very first step. Well, yeah, there are eight different types of uh transfers now available in the system, right? Or even more. Core to platform, platform to core, core to identity, identity to core, platform to identity, identity to platform, core to shielded, shielded to core, platform to shielded, shielded to platform.
Yeah, and that's what these little arrows kind of indicate that ultimately again we'll be able to do all of those combinations. Um, but yeah, that's for another another phase.
>> All right, real quick. Yeah, real quick on on the piggy cards one. So, this actually it was a little bit more complicated than planned, but there are two different types of gift cards. One is flexible cards where you can enter an exact amount. Usually you do that at the point of sale once they tell you what you owe. You can punch the exact amount in and and that's not changing. Um it's you know that design is just simply it's a single card you're buying for the exact amount. So that doesn't change.
We're just adding a tab here so that if you wanted to buy multiple gift cards, um, we are restricting it not to like a decimal or a fractional amount of of a dollar, but we're having predefined amounts based on that merchants's minimum and maximum limits.
So, you know, these values are dependent on on the merchant, but it's just an example to let you show you can buy a whole bunch of different kinds of denominations for a flexible card merchant. Um, and for fixed cards, it's the same principle. The difference with fixed card merchants, uh, and those who are familiar with gift cards will will understand this terminology. Those who aren't, it's a little bit new, but there are two different types. Um and for a fixed card merchant um you know they can choose to buy really just one one denomination type uh in multiple quantities. So if uh if a merchant happens to have let's say two different denominations that they offer for gift cards, you know, we'll let them buy three $50 cards or three $100 cards, but they can't buy kind of a mixed combination. And that's a restriction or a limitation to on the provider side, not ours. Um, so it gets, you know, these things are a little bit more complicated behind the scenes, but this is what it looks like. Um, it's same similar flow as before, just having, you know, a quantity check basically. Uh, and then, you know, the redemption part.
You can see a whole bunch of different line items for each card that was purchased, but each card will show the same details that it showed before for redemption. So, it's just kind of that middle stage that changes a little bit.
Okay, I'll stop now. Uh, that's my demo.
>> Thank you.
Let's continue with core. I don't know how to stop actually sharing.
>> There you go.
>> Great. Sounds good. Thank you, Bash. So, um, see is okay. Cool. So, uh, a good chunk of things were done this week on the core side of things or the last uh, two weeks. Um, Kitty Whiskers has remained relatively focused on hyphen. Um I think a little bit of core work happened from from them but not not so much. Um on the hyphen side the main cool development is that test net is now uh fully supported.
Um and there is a version of the uh of the hyphen explorer that is um on testn net. Um so that should be working nicely. Um, please let us know if you find any issues or have any problems with hyphen stuff. Um, one of the, uh, next, there are still, um, some known bugs and known issues to improve um, on a hyphen, but one of the next things is getting it moved over to a dash domain so that it uh, feels a little more official and um, is a little easier to find for people.
On the core side specifically um mostly refactorings and uh some test fixes and improvements were done this period or were merged in this period. Um early support for batch 32 type support was worked on. Uh primarily that was for the platform address style of bench 32 addresses to be able to support using a or creating a asset lock which will send directly to a platform address. Um a lot of stuff is in progress or in review. Uh there are a ton of um backport PRs that are actively in progress. Um, and then as well a good chunk of backports that are now just in review. Um, as well as some uh other PRs that are in review and close to close to being able to get merged in. Um, I think actually a couple of these that are in progress uh got merged in since I uh made this slide, but overall pretty solid um progress mostly around refactoring and uh codebase cleanup and fixes.
All right. So the next slide here you can see the um backport progress. Um some some decent progress was made towards V25 stuff in the last last period. Nothing crazy to report here. Um and I believe that is all that I have for core stuff this week.
So >> all right.
So um question from Bonai any ETA on Maya swaps live live in Dashbay.
>> Yes I was just reading the questions. Um so that to my earlier update um we are very close to having that on Android.
Um, I think the question was just in general, but on Android, hopefully within the next week or so. Uh, we fixed the price issue that we had. Um, so I'm hoping to get a beta out within the next week on Android. It'll be public beta.
No need to sign up. We'll just, um, it'll be available, you know, in in the buyell area of the app. Uh, and so far testing has gone well. So, that should be good. Um we are also just as a follow on to that the next kind of I won't say fast follower necessarily but we are um looking to also integrate uh swap kit which gets us access to the near intense um network as well. So um that is the plan for both Android and iOS to have both near and and swap kit um really all or sorry Maya and Near on on the wallet.
That's that.
>> Thank you very much.
One thought for credits display because such an big number. What if it was displayed as quote rough estimate of number of actions or state transitions.
Uh we do actually have so when we we had previously actually we already have something in the Android wallet uh for topup which top up is is kind of buried a little bit intentionally but it does actually already do a little bit of a of a conversion to contact number of contacts and number of state transitions. Um yeah, I mean it it we have thought about that. Again, it a lot of it will um it gets technical and there's not really any way to get around that. I mean obviously mentioning state transitions to the average person isn't really ideal. So we're probably going to end up having, you know, more advanced views versus standard views that will show different things. Um, but it it the idea also comes down to other DAPs, right? So, there's going to be other well obviously already are other DAPs out there, but it's not just, you know, the Dash Pay wallet that we're talking about where you have a certain number of contacts that you can maintain based on your credits or a certain amount of contact requests, you know, that you can um that you can do. But there will be other DAPs out there where you might want to purchase, you know, shields or swords or guns, right? All of those will have different a different translation of credits. So, ideally, there'll be some kind of directory of some kind that we can refer to or that anyone could refer to really >> that could show.
>> What's with all the weapons though, Brian?
>> Okay. Cooking utensils. May maybe it's mixing bowls and ovens that you might might want to purchase. Okay. Uh, but it could be anything, right? If you talk about it gamewise, that that was my example. But yeah, ideally there'd be some kind of, like I said, um, some kind of registry of some kind of um, publicly available list that shows what those values are. So that any any DAP could could do that translation and you could see what it is that you're how many credits you actually you know would want to purchase to do whatever you want to do whether it's on the Dash Pay wallet or or some other some other D.
All right I do not see other questions. So, thanks for being here, for being with us, for your questions and feedbacks, and see you in two weeks.
相关推荐
She Lost Her Car... But We Still Helped Her!
RecoveryBoyz
129 views•2026-05-30
Deadly Got Talent Auditions You Should NEVER Try at Home!
gottalentglobal
5K views•2026-05-29
Cozy Cottage Jazz | Warm Morning Cafe Ambience 🌸
villagejazzhouse
846 views•2026-05-29
DeBoer Wants Alabama Tougher, Texas Tech Calls out the Texas Longhorns | TNR 5/29/26
NextRoundLive
2K views•2026-05-29
Smart Working Techniques for Faster and Safer Jobs Part 54✅ #construction #adamrose #workers
worksmart-98
2K views•2026-05-29
LIVE: Move Into Friday with Special Guest Ed O'Brien | Morning Becomes Eclectic
kcrw
778 views•2026-05-29
On Bended Knees - Jekalyn Carr (Official Live Worship)
halalafrika
7K views•2026-05-29
Black Hills To Badlands In A Nova Bought SIGHT UNSEEN-Going To Towns Tour with HUNDREDS of CLASSICS!
ViceGripGarage
52K views•2026-05-29











