Zcash Arborist Call 05-28-2026

Added: 2026-05-31

[00:00:02]Okay, so welcome everyone to today's Abra call on the 28th of May.

[00:00:07]Uh, the agenda for today's meeting, uh, as usual we will start off with updates from the teams working on the core Zcash stack. That's the Zcash Foundation, Sodal, and Single Labs.

[00:00:18]Uh, then we will also follow this up with some updates from teams working on research and implementation of new features, uh, such as Keddit, Shielded Labs, and Sodal. Uh, we will then open the floor to participants to make any announcements or, um, bring any discussion topics that may be of interest to the community.

[00:00:36]So, what is the Abra call? Uh, the Abra call is a bi-weekly call where Zcash protocol contributors meet up to discuss upgrade timelines and process, protocol research and development efforts, design and implementation of new protocol features, and identify blockers and then resolve issues. And the purpose of this call is to try to make Zcash protocol development accessible to interested parties and to provide more transparency for everyone.

[00:00:59]Uh, anyone can register to attend. Uh, you can go to zcashabracall.org.

[00:01:05]And if you want to become more involved and present during this call, you can email us at [email protected] and request a presentation slot.

[00:01:14]You can also get involved in the Zcash community in a number of ways. Uh, you can apply to one of the grant programs or you can take part in community discussions in the Zcash R&D Discord or the Zcash community forums. And there are clickable links for all of these at zcashabracall.org.

[00:01:31]And with all that said, we can start with some updates, uh, on Zebra from, uh, the Foundation's engineering team, which I will be representing today.

[00:01:40]Um, so the team is not here because, uh, a number of them are looking to reports of degraded sync performance and are trying to understand what's going on and, um, see if we can do anything about it.

[00:01:52]Uh, apart from that, the team has been very busy working on a number of security issues and we will publish a security release later on today.

[00:02:01]Uh that's all I have. Does anyone have any questions?

[00:02:23]Yeah, there's I see Sukru is asking about sync issues. Uh there's a number of reports on this board and the forum that uh some super nodes are stuck. So, we're looking into that.

[00:02:42]Okay, I don't see anyone from Sudo.

[00:02:47]Um but I'm going to move on for now. We can come back to them later if they join.

[00:02:52]And so, next up we have uh Singularity with Sayno and I see Hazel, but I'm not sure.

[00:03:02]Yeah, Hazel's going to give us for a moment um the panelist.

[00:03:07]Hi, Hazel.

[00:03:16]We're not We can't hear you. Okay.

[00:03:20]Hello, hello.

[00:03:23]I see you're unmuted, but I can't hear you.

[00:03:27]>> Or maybe I can't hear you. I >> Oh, I can hear you now. Yeah, go ahead.

[00:03:33]>> Uh hang on. Let me see if I can figure out what's going on with my audio.

[00:03:54]>> Hello, hello. Can you hear me, Hazel?

[00:04:00]Guess not.

[00:04:11]>> Mistake now, can I hear you?

[00:04:15]>> Well, we can We can hear you, but I see Darrel and Matt has joined, so if you don't mind, I'm going to go back to that and let's hear if you have dates. So, one second, bear with me.

[00:04:30]Hi, Darrel Matt. Are you able to give an update on Zettel?

[00:04:35]From Zettel rather.

[00:04:43]Darrel Matt?

[00:04:44]Can you hear me?

[00:04:47]>> Uh yes.

[00:04:48]>> Oh, good.

[00:04:51]Do you have any updates on from Zettel and CK Zale or the core libraries?

[00:04:58]>> Uh yes, bear with me.

[00:05:01]Uh sorry, Zettel and Zale. Uh Uh just a second.

[00:05:10]Zettel and Zale, okay. So, um Uh fixes for the rewind method and SDK releases, so there are some um some internal release that um uh will support the um coin holder voting for next poll in Zettel.

[00:05:30]Um So, uh collaboration with the various group team on that for uh the coin holder polling uh and multi-server broadcast.

[00:05:41]Um some security work uh can't tell you about. Um and getting back to some um salary offer for uh working work.

[00:05:52]Um So, for mobile um released uh Zodl 331 on iOS uh and then um 340 on both platforms. Um and we finally fixed the um uh keystone uh import. So, that's the um issue where you don't um uh certainly see all previous um uh funds that you've received.

[00:06:20]Um so, now you can I think you I think how it works is that you can enter a birthday height and um it will scale from that birthday.

[00:06:28]Um Let's see. Uh Current focus is on uh coin holder polling. Um please um help us uh test those and um in Zodl. Um uh server improvements. So, that's um um uh light wallet server um and sync issues on iOS. Um Uh Harry has joined um as our senior mobile QA on Monday.

[00:06:57]Um and uh Danny will join us uh principal cryptographic engineer um on the 27th, which I believe is today.

[00:07:05]Um Could be wrong.

[00:07:08]Um let's see.

[00:07:10]Is So, that's the core startup updates. Um Yeah, I think that's everything.

[00:07:20]Okay. On that slide.

[00:07:22]>> Thank you.

[00:07:23]Um >> We've got We've also got is um R&D updates are separate um >> Yes, they're separate.

[00:07:28]>> Okay.

[00:07:28]>> That's uh later on.

[00:07:30]Thank you Darrel Emma. Any questions for Darrel Emma?

[00:07:41]Oh.

[00:07:42]Okay, let's let's move on and let's try Hazel again. I think she had things working, but uh let's try it again.

[00:07:57]Uh Hazel, can you hear us?

[00:08:03]Oh, no.

[00:08:04]Uh let's see.

[00:08:06]>> [snorts] >> Let's promote.

[00:08:16]Hello, Hazel. You're on twice, but that's okay.

[00:08:30]>> All right. Well, I still cannot hear, but I will give my update and then uh see if I can get my audio working after the fact. So, >> [clears throat] >> Zano has just had a release of version 3.1, which is it cleans up some stuff. Like we've fixed uh return value of a version in the get block range.

[00:09:02]And the the big thing is updating to latest Zebra. We were trailing behind Zebra, and now we are not.

[00:09:09]Uh and we have a whole bunch of new code that did not make that release. Uh we're working on a release that will get us proper light wallet D parity again, because with the huge like wave of light wallet D vulnerabilities being reported, uh we're starting to think that getting light wallet D deprecated is a shorter shorter term priority now. So, we're really trying to get out that that out the door as fast as possible. That's our main next goal.

[00:09:52]Uh I'm looking at the change log for the release we're working on and there is so much in it, so I'm not going to try to overview all of it. Uh but that is hopefully coming out this week.

[00:10:08]Maybe next week, but hopefully this week.

[00:10:12]And yeah, that's where we're at finishing off light wallet D.

[00:10:20]Uh not compatibility.

[00:10:24]And yeah, I think that's about it. I am going to try refreshing my browser again to see if I can get sound back cuz it seems to be that turning my microphone on is turning my speakers off and I don't understand it.

[00:10:42]This has never happened to me before.

[00:10:46]>> Okay, thank you, Hazel. Even though you can't hear us.

[00:10:49]If you have any questions for Hazel, please type them in the chat, I guess.

[00:10:54]So, she can see them.

[00:10:56]Otherwise, I'll I can you can tell me and I can try to type out.

[00:11:02]Um I'll give a few minutes for that.

[00:11:14]Uh Yeah, so there Emma has a question about what's the schedule for retiring light wallet D. Um Hazel.

[00:11:33]Uh Hazel says I had thought that we had parity already.

[00:11:36]Um Uh but something got lost when we did a recent upgrade.

[00:11:46]>> Okay. Um I I know that a few weeks ago um um Strat was um so still saying that um uh there were bugs that were blocking um kind of the those LA um uh beetroot offer for or whatever it is.

[00:12:04]Um but maybe those have been fixed and >> Okay.

[00:12:10]Um I guess given the audio issues where Hazel can't hear it's probably best to sync on this offline for today.

[00:12:17]>> Yeah.

[00:12:18]>> Any other questions for Hazel?

[00:12:41]Okay, I'm going to move on.

[00:12:43]Uh C cache deprecation update uh from Pacu and anyone else wants to jump in.

[00:12:49]>> Hey. All right. Yeah, um many things have been said already but um basically um yeah, Zeno uh um reached uh a few milestones uh of the Zeno completion grant. So, over the last two weeks um the block explorer RPC um start phase is mostly completed. The only the um the only RPCs that were not implemented were were those uh flagged as low priority by our uh uh surveys and our uh like spreadsheet of uh RPC usage.

[00:13:29]So, those will be as we always said like implemented on demand if if there's demand and if it's reasonable to do it.

[00:13:40]Um, then um also um we finished implementing the uh part of the integration tests on the integration test repo that actually um test the parity between light wallet and Zcashd. Those changes Those tests originated some changes within Zcashd and um also surfaced some some um uh possible bugs on Zcashd that were reported and then the team will decide whether they will are they worth it to be addressed or not.

[00:14:20]Um so, good feedback there. The only part that we haven't tested yet is the mempool uh because it requires a little bit of more setup. But um so, we are trying to uh speaking with the Zcashd folks, we're trying to target um light wallet parity uh between the releases of version 0.4.0 and 0.5.0. That would be like the next two releases of Zcashd.

[00:14:50]Um Of course, there there has to be a lot of testing uh involved to actually be able to call like um one thing is being feature complete um which on the light wallet surface like that's that's [snorts] objectively complete.

[00:15:10]The thing is that one thing is being like code complete and but then we had to do a lot of testing to say, "Okay, we we can actually start um replacing um light wallet V infrastructure with Zano D infrastructure that is kind of a adjacent conversation we need to have later.

[00:15:31]But we're trying to bump up that priority so we can also sunset light wallet D possible.

[00:15:42]And yeah, that's that's kind of the update on on that question.

[00:15:48]What else? Then regarding Zano with the milestones completed, there's the only pending stuff that is on the Zano grants that are currently open with ZDG is is work that is mostly internal enhancements and maintenance that doesn't impact the public interface. So there are a lot of like functionality that is completed, but we are now working with between Zano and sort of folks to wrap up some work from Strad that actually had some like differences or bug reports on the Zale and Zano integration. And I believe that Chris is actually working on that among the other ton of things that Chris works on. So kudos to Chris to to pulling that off and we expect that from that work Zeno focus will have a bunch of input from Chris to actually do some enhancements and include those in the next releases.

[00:16:55]Yeah, that's that's pretty much it.

[00:16:59]>> Can I just say that that Chris is doing an immense amount of work at the moment and I really want to make sure he doesn't burn out.

[00:17:07]So yeah, if if you're thinking of whether to to ask Chris to do something else, the answer is no.

[00:17:15]>> No, [snorts] if you ask something if you need to ask something [clears throat] to Chris, ask him if he needs some help and whether you can actually help him out with something.

[00:17:23]>> [laughter] >> Um, yeah.

[00:17:25]>> Um, and yeah, and he's also onboarding a lot of like new engineers. So, like this is a lot of work. So, kudos to Chris again and thank you.

[00:17:37]>> Yep, definitely.

[00:17:39]Um, >> He needs some kind of lifetime award for for services to Zcash.

[00:17:46]>> Well, we'll see what we can do at Zcon.

[00:17:48]>> [laughter] >> Yeah. Also, um, we're um, Hazel and I are grooming the Dagny section of Zeno so we can provide a comprehensive comprehensive views of uh, >> Uh, you you dropped out you dropped out for an important part of that sentence.

[00:18:05]>> Oh, okay. I will start again. Hazel and I I are working on the Dagny section of Zay of the Zeno section inside of the Dagny uh, um, graph of the Zcash core.

[00:18:21]And that will be a uh, that will um, like enable us to produce some nice views of like the work that is spending and how it's is going to be um, worked on.

[00:18:35]And we will be able to provide like public links to that work so that everyone can see uh, how it progresses and and also open like collaboration and and visit make some dependencies visible. So, uh, kudos to Chris who actually created Dagny as well.

[00:18:55]Between all the things he did, um, pretty >> That's right.

[00:19:02]Um, any questions for Paco on uh, Zcash deprecation?

[00:19:21]>> Okay. I'm going to move on.

[00:19:24]Next up, research and implementation updates from Kadet on Zcash shielded assets.

[00:19:32]>> Hi. Hi, everyone.

[00:19:35]So, yeah, this is I think the first Iris call since we like we met a bunch of people in Rome. So, yeah, it was very nice to meet everyone there.

[00:19:46]Yeah, so in terms of the update since then, we have been working on a few things. There's been work on Orchard. We've We've looked at tightening some of the validation logic around the issuance of Zcash shielded assets.

[00:20:01]And like I think we've looked at some of the edge cases and improved some error handling and documentation and things like that.

[00:20:08]We also recently submitted a new upstream PR to Zebra. So, like we had a PR that was up for a while, but we closed that and we've opened a new one that's more updated and we will be discussing with the Zcash Foundation over the next few weeks to uh like I think see the approaches to how to do things and see that everything looks good for like a future like detailed code review.

[00:20:37]We also looked at the We've updated the transaction tool that we have to again like work with this new tip of Zebra.

[00:20:47]And we have that working as well.

[00:20:50]I think like yeah, the Orchard PR was under review. I think that's also like pretty like we've responded to most comments. I think it should be getting ready, I guess. It's It's pretty much ready. I don't think there should be too much more before we get that merged into the uh LTFS at the say uh branch.

[00:21:14]>> Yeah, I agree.

[00:21:16]>> Yeah, and yeah, we we also have a grant proposal that's open. And so we had like a discussion with the ZCG yesterday and so we'll be working on updating the proposal based on the discussion that we had.

[00:21:30]So I think that's that's the main stuff that I have to update this week.

[00:21:37]>> Thank you, Vivek. Any questions for Vivek?

[00:21:54]Okay, I guess no questions. So uh let's move on to Shingle Cloud and network sustainability medicine.

[00:22:04]Who is giving that? Speak about that.

[00:22:05]>> Oh, so I'll give that.

[00:22:07]Um yeah, so I'll keep it super brief. Just have a couple of pieces of the refactor PR. I just need to merge that into uh main. Uh there was a merge conflict that I'll get done today, as well as the PR for ZIP 234, which I'll also publish as well today. Um this is the split up PR from the original implementation and uh was needed to It needed to be re-implemented uh on a couple of pieces, essentially. And so that is finally coming out today. Um yeah, so that should be about it.

[00:22:44]>> Great. Thank you, Judah. Any questions for Judah?

[00:23:04]I guess not. Uh let's move on.

[00:23:08]Uh shielded labs and settle on cross linking on the trading finality layer.

[00:23:15]>> Hello.

[00:23:17]Is my audio working?

[00:23:19]>> Yep.

[00:23:20]>> Okay.

[00:23:22]So, um let's see. I think it was before um or at Rome. Anyway, about uh 6 weeks ago, we um launched what we call the cross link feature net. And so, the this is sort of a transition where previously, when we were prototyping, we would just uh basically set up a an ephemeral testnet for each workshop.

[00:23:48]Now, we uh have a persistent network. Um and we're going to keep using that and having people use that.

[00:23:57]Uh and uh our our plan is to reset it when necessary um through 2026 and keep improving it until we get cross link um ready to propose as a mainnet feature.

[00:24:15]Um So, in the first 6 weeks, uh uh oh, and a one big idea here is that we are handing out real ZEC rewards to people who participate. And those rewards are kind of mapped to um their usage of the consensus stuff. Um >> [clears throat] >> to try to get people motivated to um to hammer on that. So, um the story so far is that relatively um relatively early on, uh a lot of the stake went offline so that BFT stalled.

[00:24:58]Uh which is a known feature of BFT systems. They stall in order to protect safety.

[00:25:06]Um whereas proof of work systems make the other trade-off where they don't stall, but they allow rollbacks.

[00:25:16]>> [snorts] >> Um and uh in in the cross-link design, in the current design of our network, when that happens, proof of work just continues uh as normal indefinitely.

[00:25:31]Uh which is, by the way, different from uh what's specified in the TFL book.

[00:25:38]Um and so, once that happened, we also saw some compounding effects. So, the uh we have made a new transport layer. Um there were some performance issues and bugs there. Um there's a new block sealing algorithm.

[00:25:56]And then, we also are in this mode where everyone, by default, runs a CPU miner to get um CTAs.

[00:26:05]Uh and the combination of those led to really long proof of work forks. And that led to hitting the reorg limit in Zebra.

[00:26:17]And so, now we have uh people see sort of permafork behavior.

[00:26:24]Uh and so, when grappling with what we wanted to do here, we decided instead of doing what we initially planned, which was to reboot the network each 6 weeks and do a new iteration, it was more interesting for us, and I think more valuable to um uh decouple the network reboots. So, we're going to only reboot the network when we have um a compelling engineering motivation to do so.

[00:26:59]Uh and in the meantime, what we want to do is instead of resetting to sort of get out of this bad state, we want to improve the software and analyze the bugs and learn what it's like for users to deal with these situations and try to focus on that to make it the the end result more resilient for the real world. And so, that's um the state we're in.

[00:27:27]Um And so, catching you up to the present.

[00:27:32]So, um some things we've done uh in our recent releases, we we've released a new V6 on Monday um that has uh BFT peer discovery um and visualization of which finalizers you're connected to. So, that's helping people figure out some network topology stuff that has um interacted with the current network state. Um and then we uh have also been doing lots of like diagnosis and analysis.

[00:28:09]Uh we've also been getting a lot of support from the um collaborators and contributors. So, uh specifically, I wanted to call out ZK Validator and Ken Back because they've each set up their own um different block explorers uh with staking info, which is really cool.

[00:28:29]Uh and then a lot of the the there's uh several users who were like really proactive about diagnosing things, figuring out what's going on, helping each other. Dismad, Paku, Orchard Guardian, Tomsy.

[00:28:42]Um so, we really appreciate all of that.

[00:28:46]Um we've also been Uh, oh, I kind of glossed over this, but we're going to continue doing, um, uh, updates every 6 weeks and workshops. And we're we're switching the rewards distribution approach so that it's time-based. So, it happens every 6 weeks regardless of the state of the network.

[00:29:09]Um, and that's sort of how we're decoupling, um, the network version or the network restarts from the workshops and rewards cycle. So, the workshops and rewards cycle are just time-based.

[00:29:24]The network restarts are whenever we think we should.

[00:29:29]And, uh, by the way, one reason we all agree we should is when we want to make an improvement and we don't have backwards compatibility as a goal at all for now. And we would only add it as a goal like, um, once it's very mature, like, basically, uh, on a uh, staging network for mainnet.

[00:29:56]And we're doing cross-org collaboration, so we're working with, um, Zcash Foundation Zebra devs on how we're, um, developing and diagnosing the new transport protocol and the new block sync.

[00:30:11]>> [snorts] >> Uh, and, um, moving forward, I'm also cuz I just heard about, uh, some, uh, Zebra nodes halting on mainnet. And so, I'm wondering if, um, we can probably collaborate more on diagnosing, uh, networking issues and stalls and things like that. Diagnosing and testing and hunting down how to do those, um, fixes.

[00:30:41]Uh, and then we're also collaborating with Nym so that our new um transport protocol will uh, have Nym integration sooner or later.

[00:30:54]And then finally, there is uh, I've done an iteration on the ZIPs, but it is what I call partially refined AI slop.

[00:31:05]Um, so I don't I'm not super proud of it, but it is helping me get started on a structure. Uh, so right now there there's a PR um against the upstream ZIPs repo that I opened a while ago that just had a stub, and now I've replaced that with um some AI slop that's you know, I've done a couple iterations, so it's somewhat useful, but somewhat misleading. Uh, and it has two ZIPs. One ZIP is an overview, one ZIP is um about the cross-link construction, which is um roughly equivalent to the TFL book construction, but with with significant differences, but the scope is about the same.

[00:31:53]And then I've identified we're going to want many more ZIPs, so ZIPs around the BFT protocols, ZIPs around the staking rules on the ledger, uh ZIPs about new transport protocols, etc. etc. So, um I think there might end up being a big chunk of ZIPs, and uh we'll be iterating on that.

[00:32:16]Um, that's what I got.

[00:32:18]Okay.

[00:32:19]Ooh, any questions?

[00:32:21]>> I might have a question.

[00:32:23]Yep, go ahead.

[00:32:24]>> So, so three protocol points. So, to to motivate the um 2/3 schedule um threshold, that that this is why the BFT is stalling. And it turns out that to get the um security properties you need from um a BFT protocol that's that's resistant to partition, you need 2/3 of the registered stake. Not Not just 2/3 of the um uh stake that's online at a given time to vote for um uh for the right updates. So, um that's why it's um actually um kind of difficult to um completely avoid um the possibility of a BFT stall. Um and kind of I think so the incentives to um keep validators um online are going to be really important for the um the eventual network. Um Yeah, and that explanation of why it's 2/3 um is in my presentation on cross-link for I think uh was it Zcash 5-ish, maybe Zcash 6, I'm not sure.

[00:33:42]Um All right, another protocol point. Um so, um you said that um the Sharded Labs version of um cross-link um differed from the TFL one um in terms of what happened on a BFT stall. It In both of them, the the proof of work [clears throat] continues. It's just that in the the one in the TFL block, um uh you can only past a certain point um you can only do empty blocks.

[00:34:11]Um but in both, the the the proof of work has to continue because um uh it a a proof of work chain is like a shark. The The anecdote about a shark swimming, which does not apply to our sharks, um it it has to keep contin- uh continue swimming or um it can be attacked.

[00:34:32]>> Yeah.

[00:34:33]>> And third thing, I promise this is the last.

[00:34:37]Um, so Zebra and Zcashd differ um slightly in how they implement the rollback limit. Um, so I believe in Zebra's case, um, it just won't roll back more than 100 blocks.

[00:34:52]>> Yeah.

[00:34:53]>> But it stays on its own chain. It stays running.

[00:34:57]>> [clears throat] >> In Zcashd's case, if it sees that it would roll back um 100 blocks, then it shuts down.

[00:35:03]Um, so that those are obviously very different semantics. Um, >> Yeah.

[00:35:09]>> Um, and I I think we need to consider more carefully what we want. Um, I actually prefer well, I would prefer Zcashd semantics if the um the rollback limit was increased. So that there is actually a proposal by um uh is it Faraday Group? I I think it's Faraday Group to um increase the um uh rollback limit to 600 blocks. Um, and that's in combination with the um a reduction of the block time from 75 uh so target block facing from um 75 to 25 seconds. So that would restore the um the wall clock time of the uh the rollback limit back to what it was before Blossom, before we had the block time.

[00:36:02]Um, I think that's everything I have.

[00:36:06]>> Nice. Thanks.

[00:36:07]Yeah, um I'm especially interested in understanding more the rollback limit and what to do about it. Uh um and one thing I proposed to the team is that we actually lower it because and or maybe this is something a collaboration we could do with um ZF uh even against upstream zebra which is set up a network it's sort of like a um what do you call it?

[00:36:40]You know, it's like a red teaming network or like a stress testing network. We explicitly lower that. We turn on everyone is a CPU miner uh in order to trigger that condition and learn from it. That's what we're seeing right now on our testnet. Um Yeah, uh so I'd be interested to have a discussion about the reorg limit specifically.

[00:37:05]Um what to do about it both on mainnet and for the cross-chain version.

[00:37:12]>> Yeah, I I mean the the rationale behind it is that um if that ever happens, then you violated the security assumption of the proof of work. Um >> Mhm.

[00:37:25]>> So, yeah, we we should really be aiming for not to be able to happen. And part of that is just um kind of having the difficulty in having enough reliable mining power in our testnet.

[00:37:40]Um which is a just a question of incentives.

[00:37:44]Um but yeah, and and part of it is just it being a bit more difficult than it probably should be to run a node.

[00:37:56]Um and I I I think probably um nodes should not be mining by default because um mining is actually making a commitment to have a stable network connection.

[00:38:10]Um because if you don't, then you you will either get eclipsed or you'll um uh fall off the network and then it um you'll be on a fork. So, um I I don't think that nodes should be mining by default.

[00:38:24]Um I think that's a a commitment that you have to consent to.

[00:38:27]>> It It's the dream of initial Bitcoin, but um >> Yeah, yeah, the dream failed.

[00:38:34]>> But by the way, the reason we chose to do that is uh so that people could get C ties organically um because we didn't want to rely as much on a faucet um partially because there's these Zec rewards. Um I don't think there's enough Yeah, so uh I don't think our current user community there there's an issue, but uh if it grew larger, we didn't want to like reward uh airdrop farmers, like people who love rewards and just figure out how to game them.

[00:39:09]Um So, yeah.

[00:39:12]And also, it it is sort of measuring how the real world behaves if we imagined everyone had similar mining equipment to begin with. Um [snorts] which is not the real world, but um still interesting to me.

[00:39:29]>> Yeah. To To To quote the intro to Babylon 5, I have >> [clears throat] >> uh proof of work was a dream given form.

[00:39:37]Its goal to prevent uh to prevent centralization. It failed.

[00:39:42]>> [laughter] [snorts] >> Um >> There was a few things I need to unpack there for the super perspective, but um yeah, I think I like the idea of uh trying these things out on a on a feature test net, I guess, and I'll see how we can um look to prioritize and schedule that. Um >> Mhm.

[00:40:04]>> Yeah.

[00:40:04]>> Thanks.

[00:40:06]>> Cool. Any other questions on cross-link?

[00:40:12]>> Actually, just Sorry, to respond to that, I think that is more effort than needed for the first step. The first step might be just ensure that we um explain to some Zebra devs everything we've learned about the behavior on our network and ask them um to check out which pieces might apply to mainnet.

[00:40:35]>> Okay, let's set that up. I'll take that.

[00:40:38]Thank you, Nate.

[00:40:39]>> Thank you.

[00:40:40]>> Okay, let's uh let's move on for now. Uh shielded labs dynamic fees.

[00:40:46]>> Uh hello.

[00:40:48]I'd like to share my screen if that's okay.

[00:40:52]>> Uh yeah, one second.

[00:40:55]>> All right.

[00:40:58]>> I guess if I stop sharing, you might be able to share now.

[00:41:02]>> Yeah.

[00:41:03]All right, cool. So, this is the uh blog post and forum post that we made yesterday. There's a lot of really exciting stuff happening in dynamic fees land.

[00:41:12]Um our overarching goals have remained pretty consistent um this whole time here. We want to uh you [clears throat] know, mitigate sandblasting situations um while also reducing fees for normal users under normal circumstances and by way of paying uh dynamic fees supporting the sustainability of Zec and the Zcash network.

[00:41:39]I'm not going to read the whole post here, but there's other goals and things like that. And we sort of realized that we can do a lot of things under the current mainnet parameters right now with wallets to start moving things in this direction and getting useful data um on mainnet that we can study and uh perhaps use. So, we're working with I think six or seven wallets now have agreed to uh experiment with these features starting with unstoppable and um moving through a handful of others. And the ones that have not agree yet agreed, um we have feelers out to talk to the wallet teams about these things. Um one is a 4x priority delivery, which goes right up against the uh weight cap defined in ZIP 317.

[00:42:32]And that basically creates a quality of service that a user can choose to pay for, um and speed up semantics, which are lowering the expiry time in transactions to 2 minutes of wall clock time, so like two blocks under current parameters, and then it would be like five blocks if Dave's ZIP 218 goes through.

[00:42:57]And um this is a way to get the same semantics um in the UX without you without implementing like RBF or any other feature like that. It basically just waits for the transaction to expire and then resubmits it at the priority uh rate.

[00:43:16]Then from there, once we have some data, we can design, spec out, and ship a RPC endpoint called Z get standard fee that could be called from a wallet or relayed by an indexer, and then the wallets can use that fee uh with some sort of uh pseudo SLA, you know, in terms of I mean inclusion in blocks. Um our preference is to use mined blocks and mined transactions as opposed to mempool spying or anything like that. It's just more real that way.

[00:43:50]Um and then from this research, uh we want to change two parameters in ZIP 317, which would be lowering the marginal fee.

[00:44:02]Um we proposed 5,000 to 1,000 before, and then raising the weight cap um, from four to 10 to just sort of widen the the inclusion, uh, parameters for uh, for blocks.

[00:44:19]And that's kind of where we're at right now. So, we're just we're working with wallets, um, and I am specifying the fee estimator.

[00:44:28]Um, there's a librustzcash, uh, pull request that somebody from not a pull request, an issue that somebody from unstoppable opened about being able to configure the transaction expiry and the uh, fee in librustzcash's, uh, transaction builder.

[00:44:47]And uh, I'll also be talking about like I think 2000 level ZIPs for the parameter changes and just getting the conversation started there.

[00:45:01]>> Yeah, um, the historical reason why we've um, [clears throat] resisted um, these prioritization ideas is that, um, uh, so, we wanted to maximize the anonymity set and, uh, obviously if you choose, um, four times fees, um, then the adversary has that information.

[00:45:23][clears throat] It's difficult to tell, um, if how much, uh, that leaks about who you are, um, because some users may be, um, more likely to choose, um, prioritization. But, I mean, I I think, um, so so the reason for the four times cap was, um, basically, um, well, I'm a communist, so, um, I I um, I don't really believe in money at all.

[00:45:51]Um, don't ask me why I'm working on this project. Um, I just to understand money really. Um, and some fun crypto. Um, and, uh, prevent [clears throat] surveillance.

[00:46:03]But, um, the is that um Yeah, we we didn't want a situation where only rich people could send transactions.

[00:46:14]So, the four times was kind of a compromise um uh to that >> [clears throat] >> um in that direction.

[00:46:24]Um, and if all you're doing is splitting the anonymity set between uh prioritized and not prioritized, then in some sense that's the the minimum um amount of additional information you can reveal. So, uh >> That's considered >> Yeah, I guess I'm okay with that and I and I wrote the zip to allow it.

[00:46:45]>> Okay, um cool. And uh yeah, if you got to use money, you might as well understand it, right?

[00:46:52]I'm sympathetic to that.

[00:46:54]>> So, I and my co-authors, which I think is Stratton Chris, um wrote the zip to allow that.

[00:47:00]>> All right, cool. Um Yeah, that's our thinking, too. It's it's it's a meaningful discretion to give the user, and it's minimal in terms of what it reveals. Um And after the NSM ships, it's even more uh opaque as to why somebody would be doing that. Um if they just want to tip the network or whatever. So, um That's Oh, yeah, packet >> Oh, uh yeah, first I I wanted to apologize because I haven't been able to read the post yet.

[00:47:35]Um but I I wanted to um yeah, stress out um stress out what the Aramis said. I was actually going to make like kind of the same questions remarks.

[00:47:46]Um So, like are there like are there any like privacy implications in terms of like being able to pick up like expiry heights or um or fees and and how how can we avoid like users being advised to pinpoint their own transactions?

[00:48:11]>> Just so in order to like not make the their I am a was right t-shirt like even more popular. [laughter] >> No, I I I want >> We have a We have a thousand orders at the moment and we can't like >> Yeah.

[00:48:25]>> Yeah, we can do want to we can't scale that that that many.

[00:48:30]>> Right, right. No, I want to be reassuring but also as intellectually honest as possible about about that question. It's because it's a policy change because it's a wallet change, there's going to be a period of time when certain wallets are are using these features and certain wallets are not. And um I we you know, expect the usage to be minimal in that regard.

[00:48:54]Um you know, the main wallet Zcash is is somebody that we have a conversation booked with but has not committed to any of these features or anything like that.

[00:49:03]So um I think you'll end up with a with two anonymity buckets. One will start very small and hopefully over time get bigger and bigger until they're you know of sufficient uh equality and then that will be that will be that. Um but it would still be if everybody plays along which we're going to be pretty rigid about um how the wallets implement these. We're looking at We call it the 5,000 4x parameters right now and we're hoping to get to 1,000 10x.

[00:49:40]Um but with all that, we're hoping that the the stays to about, you know, one bit quote unquote of of uh leakage or whatever.

[00:49:52]>> Well, yeah, well I It seems like you have every >> well thought.

[00:49:56]Um awesome, yeah. Because these kind of changes are those kind of things that are are under the category of like uh road to hell is paved with good intentions. Like I remember having a conversation with one of the authors of the Zit 313, was it the um the previous Zip 3 that lowered the fee like to really low.

[00:50:21]And the idea was to lower them so like with with some parameters of how bandwidth costs uh were at the time in in developing countries. And then like this person was really kind of like re- regretful because like then we had the the sandblasting and also like I think that these these changes need like like a lot of like introspection and it appears that you have done it, so it's it's really awesome.

[00:50:51]>> Yeah, yeah. If if you think about um it it's weird because there's no price oracle, right? And and if we low you know, right now if we lower to 1,000, it's probably fine. Um but if Zec drops to maybe 200, 150 again or something like that, you don't know. So I I think but the good news is is that we kind of know from 30 on up 5,000 is like safe where it is. So we can be careful about changing that parameter um while still progressing this work forward um with the current the current setup.

[00:51:29]>> I I mean we also haven't seen um what I would consider a serious attack designed to make um uh Zcash unusable that is well funded. So the sandblasting did in fact make um uh a a lot of Zcash um wallets unusable, but it did that um partly because of our um own tardiness um uh um um people know my um position on this, I think, um by now um about implementing uh ZIP uh 317.

[00:52:09]Um so that that was kind of partly us shooting ourselves in the foot uh and not responding quickly enough. Um but on the other hand if someone um if uh it's a denial-of-service attacker with um 10 times or 100 times the budget of the Sunblast thing attacker um tried to attack us, then then they would succeed.

[00:52:35]So um yeah.

[00:52:40]I don't know how to fix that.

[00:52:43]>> Yeah, there's also a if you squint at ZIP 218, which is the 25-second blocks, there's also these action limits.

[00:52:50]And I start to wonder if there's interactions here that and I know it it it it helps with sandblasting to have these action limits in some regard.

[00:53:00]Um wondering if there's some something between the fees and that that might uh interact.

[00:53:07]>> Um well, they they do interact because they both um affect the um adversaries' um cost.

[00:53:15]Um but I mean so so in any network like this, if the adversary is prepared to pay more than the users in aggregate, then there's not much you can do.

[00:53:28]Um uh the the adversary can just flood the network, and if they're clever enough about it, then their transactions are uh pretty much indistinguishable from user transactions. And so, how do you tell how how do you end up fav- favoring the users over the other three is the hard problem.

[00:53:49]Um and no one has ever solved it as far as I'm aware for any any network [clears throat] protocol whatsoever.

[00:53:56]Um we we kind of rely on centralized services like um Cloudflare Flare to um and other CDNs to kind of partially mitigate this at the kind of HTTP internet level.

[00:54:14]But um and that that's dependent on paying people to um have detect um uh uh attack patterns and kind of block them in real time.

[00:54:29]>> [clears throat] >> Uh and maybe eventually that's what we'll have to do.

[00:54:35]>> Yeah, makes sense. [clears throat] >> Oh, I'll get an AI to do it because it hasn't turned out so good.

[00:54:41]>> We do the Yeah.

[00:54:42]>> Probably, yeah.

[00:54:43]>> All of us, yeah.

[00:54:44]>> of But vibe denial of service protection.

[00:54:50]>> Nate.

[00:54:55]>> Yes. Hello. Sorry, I was actually chatting with uh Dave from Valor Group saying they should be in the Arbor Assaults. Uh he wasn't aware of it uh until just now. But um and the reason is because I remembered he had a criticism of uh this dynamic fees approach. Um and I wanted to channel it because it's not it was new to me cuz it's not my awareness or bias, but >> multi-sig thing?

[00:55:27]>> Yeah, it's basically a short time scales. Like So, I'm I love the idea of short time scales. Uh you know, like the 2-minute expiry because um I think it's a good way to address the privacy issues but it's by imposing the certain constraint that that your wallet is online at recently when it generates the transaction.

[00:55:53]Um and so I'm skeptical I've I'm typically skeptical of use cases where you have a transaction that's old that hasn't been online recently and you want to submit that that seems strange to me but one use case that um sounded like it made a lot of sense is around multi sig or threshold signatures where you need time for everyone to agree.

[00:56:21]Um how do you think about that?

[00:56:24]>> So check this out.

[00:56:26]>> I have an opinion but I'll let Mike go first.

[00:56:29]>> well yeah I'll say my heavy uh blunt instrument approach here which is multi sig should just pay the priority fee at the time of the last signing and it will probably be fine.

[00:56:43]>> Oh.

[00:56:44]Okay.

[00:56:45]Great.

[00:56:46]>> That's kind >> Yeah, so actually part of the problem is I don't understand the um the use case specifically like there may be clunky multi sig people >> yeah I don't know about multi sig UI and UX I think that's kind of the wallet's job but um the the problem statement as I understand from Dave is that in the span of time it takes to coordinate the multi sig the the fee could change and then the transaction doesn't go through and you have to start the whole multi sig all over again.

[00:57:16]>> Yeah.

[00:57:17]>> Um which I think if you just pay the priority fee it will probably go through.

[00:57:22]If if our estimator is designed well.

[00:57:24]>> Oh well yeah I think the story might be like you know it's an institution and it's three of five and the one guy is away from the office on the weekend and so the transaction the transaction is specified and it's the the last um necessary signature doesn't arrive for like days or whatever. Uh I think that's the kind of use case that might happen in real life for other networks at least. Um And my I I also have an opinion which is just make the multi-sig system work better so it can handle that long time scale, but but the transaction is actually generated on demand after everyone agrees. I'm not sure how to do >> So so okay, so talk down to the rescue um because if you have um recursive proofs, as a so let me first explain um why the problem arises in the um current protocol. Um and this actually also a privacy problem because um you have to choose the anchor um in order to know the sig hash um so that you give the sig hash um and the transactions so that we know what we're signing um to all of the signers. They decide to sign it um and then they combine the sig partial signatures um to get the transaction, but in the meantime the the anchor can't be advancing. Um So that is what um you you end up using um an old anchor.

[00:59:10]Um and also and you could estimate when you're going to be able to um broadcast the transaction and set the expiry height um accordingly, but you don't necessarily know um when the multi-sig ceremony um uh will have finished and so you have to estimate conservatively and which is a pain. Um so Penumbra actually um took an approach to this which is to um allow the anchor to be updated.

[00:59:41]Um now I don't know whether we want to do that. Um uh we decided not to do that in um kind of strike something in Orchard um that to maximize privacy. Um but but there's [clears throat] a case for that and there's also um you might be able to use the features of um Tachyon to do a similar thing uh without um compromising privacy.

[01:00:14]Um so that yeah there there there there are two potential so avenues I think that there's that avenue and then there's also um when you get the authorization to spend from the um signers um they don't necessarily need to um sign uh the sig hash of a precise transaction. Um they could for example um uh authorize an intent which matches some set of um transactions.

[01:00:46]Um and that would be um kind of uh uh CK proof um that um Sorry, I'm confusing um two different things. Basically you you you just want the signers to um authorize only the um uh the um kind of weakest um condition necessary not a specific transaction. Um and then you combine that with um uh because of proofs which means that you can much be much more flexible.

[01:01:27]Um >> Mhm.

[01:01:28]>> So, and and that there's also some other problems because um if So, we we have some threshold post-quantum signature schemes um based on ML DSA, but they they all have some drawbacks and the the two main ones are one's patented and patented and the other doesn't work in a um dishonest majority model.

[01:01:54]Um And they're they're kind of inflexible and you would have to use ML DSA uh and they're likely uh produce distinct short signatures. So, there are other um reasons why you want might want to use um recursive proof aggregation instead of a dedicated um uh threshold signature scheme. Um and that kind of solves your problem.

[01:02:20]>> I'm glad this is recorded.

[01:02:22]It's a lot of information I need to go back and look at uh each piece of >> I was hand-waving a lot.

[01:02:28]>> Okay.

[01:02:29]>> [laughter] >> Circle up with you and we can just do a study group all that but >> [clears throat] >> Yeah.

[01:02:35]Nate, you still have your hand up? Are you good or you want to keep going?

[01:02:39]>> I do have my hand up and it's it's for even more hand-waving and it's like totally a tangent, but I just realized um I feel like the way I might want to solve this very abstractly is as an application of intents.

[01:02:58]Um so, maybe this is just a different Yeah, it's just a maybe we should have an intense geek out call someday that's not this. Uh but I just wanted to say the idea of intents how it might apply here is you could have an intent which says uh you know, I'm signing that I control this private signature key and I approve of any one single transaction that meets these criteria and those criteria include it has a significant sufficient threshold of signatures from the other participants and it pays this amount to that recipient and the fee is either this or that and then the actual transaction has to include proofs that it satisfied all of these intents. So, it's it's a pretty significantly different architecture, but I I'm very interested to explore it if anyone wants to do a geek out on that someday.

[01:04:04]>> I I do. If you squint at this sideways, it's basically a smart contract contract system. So, it's it's adding programmability.

[01:04:12]And you can So, with not much more effort you can support both programmability and this and I'm very keen to explore that once we have tachyon deployed for scaling that we try and extend the use of the um the recursive proofs as far as it will go.

[01:04:41]>> Okay.

[01:04:43]>> Sounds fun.

[01:04:44]Let's do it.

[01:04:45]>> It also Yeah, it also gives you privacy of the statement just like in Hawk for example.

[01:04:51]Hawk is an academic kind of private smart contract version.

[01:04:55]>> Yeah, envision there being these sort of NU6, NU7 dynamic fees version and then the post tachyon, you know, there's probably tons of discussions we can have around how all this changes and new cool stuff to do.

[01:05:10]>> The but, takeaway point is we have very powerful tools that we are deploying.

[01:05:16]And we can solve basically any cryptographic problem that you can state precisely can be solved. And the question is just the complexity budget and um yeah.

[01:05:27]Attack surface.

[01:05:28]>> [snorts] >> Well, thank you all. That's all for me.

[01:05:34]I'm going to stop sharing.

[01:05:36]>> Thank you, Mark. Let me share my screen again.

[01:05:43]We're almost at the end, anyway.

[01:05:45]Um Okay. So, uh any announcements from anyone?

[01:05:54]>> Oh, we we didn't have we didn't have R&D updates.

[01:05:58]>> Oh.

[01:05:59]>> From Zcash.

[01:06:01]>> Oh, I didn't know there were any.

[01:06:03]>> Oh, yeah. But there are.

[01:06:05]I'm sorry. Yes.

[01:06:07]Um Okay. Anyway, I'll I'll get there. Um I I realize I missed a few things in my other report. Um the most important one is um kind of I mentioned that Harry and Danny are joining us. Also, Paco is joining us as well.

[01:06:23]So, um Yeah. And as well as that, so we merged the final changes to Zcash 2005, which is the version quantum recoverability Zcash.

[01:06:35]So, that's now in proposed. Um Okay, we we were Um Chris and I and um I >> [clears throat] >> was uh I working on improving our security and triage policy at Zcash and um we'd like to work with other organizations to kind of have a um more of a common policy without kind of constraining [clears throat] everyone to to do the same thing as we discussed it at the summit. Um Uh the key signing of offers have merged. Um PR artist brought slip 1390 secret sharing.

[01:07:10]um, uh, and that'll be available in the future firmware update, um, and I have a project, um, called, um, Dara/Shannon, um, on GitHub, um, and it's, uh, kind of AR related, and what it does is improves Cloak's ability, um, to remember things, um, particularly across, uh, session boundaries and, uh, perfection boundaries, um, and it adds hooks so that, um, it actually gets to remind you of the right things at the right time. Um, uh, and it it does significantly improve, um, kind of uh, I I I find default Cloak quite forgetful, um, and it it's a problem with, um, doing complicated things with it, uh, in long context sessions.

[01:08:02]Um, okay, I think that is everything.

[01:08:07]>> Cool.

[01:08:07]>> Oh, and and >> Yeah, go on.

[01:08:09]>> And in in Rome, by the way, Rome was fantastic, um, I did four conferences, um, Zcash Summit, um, uh, the Zcash Summit, um, ZK Proof and Eurocrypt, um, and uh, the highlights for me were kind of the the very nuanced discussion of AI, um, discussing the potential harms, um, but also not kind of pretending that it doesn't work.

[01:08:35]Um, uh, and, uh, the discussion of the post-quantum timeline, um, which which we absolutely do not have time to discuss here.

[01:08:47]>> Cool. So, I was going to ask, we don't really have a subtle research, uh, updates, but maybe we should add a section for that for the next time, um, like a separate one.

[01:08:56]Um, >> Yeah, that'd be a good idea, I think.

[01:08:58]Cuz that that's kind of how we organize the updates, um, >> Yeah, so we'll we'll we'll do that for next time.

[01:09:04]Uh, and then, yeah, I want to I want to coordinate more on the security disclosure process. I just haven't had a chance to uh, update our own to to match yours a bit more closely. And I think Mark has a question or an announcement.

[01:09:19]>> Uh, yeah, I just wanted to invite everybody to our next office hours, which is going to be a continuation of the notes, commitments, and nullifiers protocol walk-through that we had to cut short last time. That's going to be June 2nd at 3:00 p.m. UTC.

[01:09:36]So, hope to see you there.

[01:09:40]That's all.

[01:09:41]>> Okay, thank you, Mark. Any other announcements?

[01:09:44]>> I'll try to be there.

[01:09:53]>> Okay, any I have to say I do have a very hard stop. So, if we have any more discussion, it might have to continue without me, but uh, any any other discussion topics?

[01:10:11]I think I'm not going to give much of a chance for another one to arise, so with all that, uh, thank you very much.

[01:10:18]Uh, the next office call will be on the 11th of June, uh, 21 UTC.

[01:10:24]Hope to see uh, a lot of you there.

[01:10:26]Thank you.