Minokawa Community Call - 2026/09/16

Hey, Matty. How's it going? >> How are you? >> You're not bad. [laughter] >> No, I mean it. It's I'm not dead. It's uh >> I know it doesn't sound good. No, I I I really do understand. >> All right, I am closing this window. I'm increasing this nice and sharing screen. >> Hi guys. >> Hi Yuri. How's it going? >> I lost my >> but everything else is good. to Okay, I think that's the right one. Can you all see my screen? Okay, let's see. We are one minute in. I'm going to wait for probably a couple of minutes and see if people are going to join. I opened a new batch of tea. It's very good tea. Um, yeah, very fragrant. Which also was a gift from my aunt. They're very specific about their tea. I have lost my specificity since I moved to the US. Um, sadly, as I'm waiting, if anyone has anything for me to add to the agenda, please feel free to raise your hand or just speak up. We have Kevin. I know Jonathan's not going to join today. Um, I don't know about Joe. >> I may have to leave 15 minutes early. >> Oh, there's Joe. >> All right. Before I start, I have a couple of things on the agenda myself, but before I start, anything that anyone wants to discuss that I should add to the agenda so that we can time manage, going once, going twice. All right. So, hello everyone. Thank you for attending. The first thing on the agenda that I have is regarding the public event scope that um has been sitting there for quite a while. Uh that it has been implemented. So uh I think my plan for it is to edit it based on the changes of the implementation and then have TSC review it and just get it in so that there's some document that tracks the implementation. Any objections? >> Um, I think that's a fine way to to proceed here. Um, I think in the future we should try to get ourselves out of this situation, but uh but now it's like becoming anformational quite where it says it describes what we did implement, not a proposal of what we will implement, >> right? >> Yeah. And it's a it does reflect reality. And we also we may revisit this but uh that'll be a different quip. >> Oh, that sounds good. All right. The second thing I have on the agenda is regarding the multi-environment kip. Uh for folks that are not in the loop, um we are at the point of which uh that different networks of midnight are using different uh ledgers. Um but comp the compiler the compact compiler only supports a single ledger at a time which then that for us means that we either have to release and maintain multiple versions uh of the compiler or provide a mechanism that allows us to allows the compiler to switch between between different versions of the ledger. Um, so I'm working on a proposal that uh advocates for the ladder and um how that's going to work is that we're going to introduce a ledger flag uh that allows the user to choose the version of the ledger that they want. Uh in reality because we recommend users using uh the developer tool uh in the developer tool they will have a flag for the network. So the user theoretically does not need to know the version of the ledger that um they need to compile a contract with. Um that being said, it kind of bleeds true and I will get to that point. Um so um I did have a couple of open questions that I think uh are good to kind of uh take the temperature of the room and see what what people think. So the first one is whether we want to have a default ledger. So if a user does not and for the purpose of this I'm not going to talk about the the developer tool. So I'm not going to I'm going to use the ledger flag instead of the network flag. Um so if a user does not provide a ledger flag uh what should happen? Um on one hand I advocated for having the oldest version of the ledger being the uh the default version. uh my assumption is that mainet will probably be on the oldest version of the ledger and that's that's the main reason for that. Um on the other hand given that this um the ledger is the back end of the compiler um having a default ledger then means that every time that we deprecate a version of the ledger this becomes a breaking change for the compiler. Um so question is do we want a default ledger uh that every time we we deprecate a ledger that makes uh a breaking change in the compiler or if we want to require uh the ledger flag being provided. Uh Kevin I see your hand up. >> Yeah I would I would take a step back and say that we can't really ignore the dev tools. we should design this in conjunction with a user experience that we want to provide with dev tools. Um for for the for if if we intend that the the recommended way or the the official way of invoking the compiler is via the dev tools, I'm completely happy saying that you must specify a ledger version that the compiler will not. >> So then that that becomes that you must specify a network. Um, >> no, it could it could be that there's a default network. I mean, so the so dev the user experience that dev tools provides can be that if you just compile a contract, it compiles it for mainet for today's mainet. >> Right. Okay. So your proposal is we have uh a default network that is mainet. So then the default ledger becomes um >> becomes there's no default the compiler itself does not have a defa the compiler itself does not necessarily have a default ledger. The dev tools will invoke the compiler with the appropriate ledger flag and the compiler will not allow itself to be invoked without a ledger flag. That's that's one possible design. But I but I guess my point is that we should take a step back and we should design a user experience that we want. Um and then we should provide an implementation of of that. >> Uh that's fair. I do like I do like um I do like having the default network being mainet and having the developer tool invoke um the appropriate ledger for that which then results in the compiler itself. If I'm calling the compiler itself um I must provide a ledger uh flag. Um, other ideas, other um, or I guess if someone is is um, itching against this idea. >> All right. Um uh going to quickly capture this default uh network to be mainet require the compiler to have a major lag. Okay. Um all right. Uh the second thing that I have is that I think right now uh the standard library is ledger independent. Um >> it's not >> I see. >> Okay. >> All right. Then that answers that. So all right. Uh that's a resounding no. Um >> well it's this has to do with which version of ZKI or is supported by which ledger. Um it's really not that that that it's independent. It is in a sense independent of the ledger. It's just dependent on ZKR and by transitivity. >> Therefore the ledger is certain ledgers don't support certain versions of ZKR. Okay. So then that brings up my fourth question. Is ZKR a separate access of ledger? The design I have right now is that it allows it allows for the introduction not in well it allows for having multiple ZKs for each ledger back end because that's that's what we have on main at the moment and that's that's what I'm going off of. Um, so is that is that going to be the path forward? I'm just going to go from I don't know who raised their hand first, but I'm going to go off of what I see on my screen. Joe, you're first. >> Yeah. Well, I guess my this it's more of a question. I'm just kind of thinking out loud, but um in the previous question um we're requiring the compiler to have a ledger flag and some thoughts in this area are I wonder if a ledger flag is what we actually want because I'm not sure that the ledger flag itself represent our direct dependencies. One approach might be to have um like an onchain runtime version flag instead because the compact runtime actually directly depends on that. Um and then maybe a separate zkir flag. Um and then instead of I don't know like having the ledger flag directly in the compiler maybe we can have a tool like the compact tool that actually understands the um compatibility matrix. And so if I write mainet then it can read a compatibility matrix from somewhere and then just set the onchain runtime and ledger flag or onchain runtime and zkir flags itself. So maybe the flag should only be our direct dependencies and then we have some other tool understand mainet prepro stuff like that. Um, Kevin. >> Yeah. So, so first of all, I was going to say that the order that you see the hands raised are the order that we raise them in. So, so Joe was first. And then I think that I think what you just said, Joe, is an is an absolutely fabulous idea that the the compiler should actually be configured just based on our direct dependencies. Um, and I think that's a really great way to think about the how we want to implement this. >> Well, that's that's the design that I have. I think uh there's um >> the ledger is only indirectly telling us what onchain runtime and Z we can um >> support. My push back on that would be that I also even though we recommend people using developer tools um the compiler itself still should be um user friendly enough and I wonder if the unchained runtime and I could argue against my so let me finish one argument um and the average user probably does not know what unchain runtime is. On the other hand, if I'm arguing that um for a more sophisticated user to use the compiler, that user might actually know onchain runtime. Um okay. So then but then we're talking about now having either a ledger flag or an unchained runtime flag on the on the compiler side and then a zk flag is that >> yeah not but they're not completely independent >> right >> some combinations will not Down. All right. Then this makes this that STD is not is is unchanged on time independent but is not ZKR independent. Did I catch that right? Um >> so that also relies on on on what we're calling from compact runtime right so standard is onchain runtime depend dependent not independent [clears throat] um >> oh yeah oh >> I okay it is zkr dependent but it is also onchain runtime dependent >> I think it's zkir are independent and it's onchain runtime dependent. >> Um, no, I think it's dependent on both. I think it's dependent on both those. So, let's just say >> yeah, so let's just say that we add a new um native to the standard library. we need to have a JavaScript implementation of that native um in the compact runtime and that might require um uh onchain runtime support and we need to have a um support for a ZKIR implementation of that native and that might require changes to ZKIR so a new so a new a new native in the stand like just like let's talk about SEP 256R1 it needs to have or verify proof is a great example Verify proof needs to have ZKIR gates to support it and it needs to have some something exposed in potentially in the onchain onchain runtime to support it. So it's so it's not so it's not independent of either of those. And right now I know that we have a ZKRV3 library that's um and I did not look deep enough to see if that's pulled into the standard library but um >> no we have two we have two ZKIR components. One is the key generation binary um that is compiled from Rust and the other is the zkir wom that we're currently using for testing but will possibly soon be importing into the compact runtime. >> So there's so there's a key generation binary and there is and I and maybe Joe knows more about how we're where we're eventually going to land with this. There's also some potentially some WM code that we have to import into the compact runtime. So this zkirv3 library.com compact is what this is what I'm talking about and this is what is it's also pulled in god can I remember uh in the >> yeah this is a different this is a yeah this this is a different thing this is this is um there are some there are some standard library um circuits and types that are not available in the ZKIRB2 back end, >> right? And then so but then this is pulled in in probably like expand module one and types into the standard library when CB Okay, gotcha. Um um okay. Okay. Um All right. I think that's clear enough. >> So the note just above the note just above there is >> is not is not correct. It's it dep it depends on both. >> Right. is not independent, right? >> It is onchain runtime dependent and it is zkir dependent. >> Oh, it it has a not. Okay, thank you. All right. Uh then we have contract manifest.json which uh at the moment does not record ledger version. Um do we want it to record ledger version? I think we want it to record ZKIR and onchain runtime version. >> Oh yes, >> I I I think that's exactly the answer. I think what what Joe what Joe said is exactly the way we think of this. >> It's going to give me some time. It's also much easier to just say one word instead of three. God help it. Uh yes. Okay. Right. So um coming up to docs um so it would be unfortunate for the docs to reveal the unchained runtime and ZKR versions. Um what I mean by that is for example the ledger ADTS we are generating those um the docs for those in in the compiler. As far as the compiler knows, it doesn't know the network. Um, so it will only know the unchained runtime and zkir. Um, which then it either has to reveal that information in the docs or or possibly via the script that goes and um and grabs the network information from the compatibility metrics that the div tool holds and expose it that way. I just don't like the complexity. Um, I think I answered my question. >> I think there's and I I don't know what the scope is for u what we're trying to arrive at, Parisa. Um but I feel like some sort of series of diagrams would be helpful here um in [clears throat] understanding because I don't know like you can even if we could specify like it suppose we even just had flags in the compiler that said onchain runtime version this and zkir version this we still need to figure out like how the versioning system of the compiler should work of the language which should work and of how that interacts with the different networks that currently exist. And I feel like to understand that we need it. It would be ideal if we had some sort of set cadence for when these networks are updated or promoted or stuff like that. Like Rust itself, for example, as a language has three different trains. They have a nightly, a beta, and then a stable release. and they um update those like promote those every six weeks or something. And so I don't know [clears throat] there's also yeah like I say I guess just a lot of questions about how we even version the compiler here. So long story short um to answer this question I don't think that we could assume that you get like one set of docs for compact um as long as it includes a definition of the ADTS right so you might different docs for mainet for prepro for different compiler versions >> and I also think that anyone who is looking at our ADT definitions is necessarily looking at impact code I think um it actually I don't know if the instruction sequences are included but it seems it seems perfectly it's not okay >> it's okay [clears throat] then yeah >> that's what that's what makes them abstract I think they they they should admit multiple implementations and >> yeah yeah okay so maybe the onchain runtime version is yeah should not be included there >> yeah I mean the uh one one thing that we maybe should consider is should we version the standard library because right now we're not um I could see that if we were in a position where we were not making breaking changes like we're not removing things or changing signatures um in breaking ways we could always say um this of the this feature was introduced in zkir 3.2 to onchain runtime 4.7 or whatever. Um, and we could have just a single set of docs that had uh features that required at least some version of ZKIR and onchain runtime. Um, but if we're making breaking changes, that's a little harder to pull off. >> Yeah, >> I like the idea of versioning the standard library. Um I do not want to rely on I well I would like to know um you know a timeline for promotions and deprecating of um what goes into what network that's not something that I can't rely on um >> out of our control. I think the goal I think the goal is that we go get to this vision of uh something that works like Cardano where there is mainet there is prepro which gives you early access to mainet when a mainet upgrade is coming and there's preview which gives you early access to new features um and there's fairly regular promotion from preview to to through pre-prod to oh for a period of time to mainet um we're not there right now >> yeah So >> yeah and the the I have not talked much about the formatter and fix up tools. Um so the floor is open for people >> there should not >> oh I guess if the standard library is um >> there should not be different formats by the formatter but there might have to be different implementations of the formatter if we make breaking changes to the language Um >> right. And so then if the breaking changes of the language are are unchanged on time or ZK dependent. >> Well just like for instance we've changed the syntax of assert. So you if you have a contract that has the old assert syntax you have to use an old formatter. And if you have a contract that has the new assert syntax with the parenthesis you have to have a new formatter. So there's there are different versions of the formatter as long as we're making breaking language changes. Um when we stop making breaking language changes, you could always format old code with the current latest formatter, I believe. Um and then the fixup tool, the fixups are built into the tool. Um so when we add a fixup, you need you need a version of the tool that has the fixup in it. They're not it's not parameterized over the fixups in any way. it. Um, why wouldn't we just think of these um tools as like independent tools? Like if I work in the TypeScript universe, I I might have a fix up or a format tool and they would be maintained as separate packages with their own versioning scheme. They would in some sense like be dependent on language changes. But I don't see a reason why we would not think of them as like any other format or fix up tools in a different language ecosystem and version them accordingly. >> We could I don't have a strong >> opinion for or against. Um I do well I do think for this proposal I do want to consider this out of scope so that um life would be easier. Okay. And then I have uh a cautionary tale that right now uh I'm I'm uh going off of the assumption that max field is is going to stay the same across all ledgers. Um if if or when that changes uh that also becomes um um becomes um I'm going to wrap them all up in one ledger dependent. Uh so then the same goes for example for midnight inlines and midnight events. Um, so we could either be proactive about this and uh right off the bat in in the breakup of these backends that we have uh consider these uh consider anything that has the potential of becoming dependent on either onchain runtime or ZKR um and do do the same mechanism for them that that we're doing for uh for example midnight natives and um ledger ADTS or be open to when that happens um going back and fixing it. Does that make sense? >> I think you lost me a little bit. I mean I think we need like a >> So right now Yeah. Uh so right now Midnight uh Midnight Natives and Midnight Ledger is being duplicated per back end because they have the they very clearly have the potential or I guess even at this point because of the ZKR they are dependent on the ledgers on the onen runtime. So each backend could have a change in them. So we keep a separate uh midnight um ledger and midnight natives for each back end. For example, Ledger 9.1 and uh 8.0. >> Yeah, let's just let's just let's let's flip it around and talk about the user experience. So let's say that we released a Ledger 11 and it changed the underlying native field from B from BLS 12381 to some other field. Um would we would we want you to be able to invoke the compiler and and select ledger 10 or ledger 11 and would we want to support that user experience? I think we would. Now would how would we support it? How would we implement it? I don't know that. But I think that that would be like an experience that you would want to provide that I could invoke somehow a tool that said compile this contract for mainet ledger 10. compile this contract for preview which has a different native field. Yuri, go ahead. >> Uh it's a pretty interesting challenge that you are trying to figure out and I just wanted to propose to create a new flag like a target. You know there might be different targets and currently you need to figure out which kind of combination you're going to uh support. Is it the Ziki 2 or Ziki 3? Is it a ledger 8 or ledger 9 or ledger 9.8.1? I don't know. So if we can define a target like Z2 ledger 9 blah blah blah like tuple or triple or doesn't matter how many uh variations are going to support because this variations are kind of coupled with each other. I believe that there is combinations that just cannot be uh cannot work together like old version of ZK IR and ledger 9 and all the stuff. So if you can define the list of targets which are finite uh definitions of supported combinations and you can uh add this target flag as in any other compilers like you have you can compile C++ code for one target for another target and it just create different binaries and different packages uh for you. So having target can solve this question. Yeah, I'm done. And >> yeah, so I think Yuri's I think Yuri's right. I think um Kevin's right. Um essentially the saying the same thing. We need to decide what the user experience is. Um and how we go about doing that from there is that we have lots of choices and we should not tie ourselves to a particular choice. Um, so I actually think the compact updater is the is the tool that we should we should decide what that looks like first and everything kind of flows from there. Um, I think the onshine runtime is not the best thing to be talking about. It may be the only thing we can talk about right now, but I think this is more of a of a a shielded level decision um how they're going to version um things. I think that you know if you if if we talk about having uh mainet uh every time mainet uh gets upgraded uh to to something there's there's a version there. It may not be called anything now. Um, but it the end user wants to be able to say I I want I want uh something that will target the the mainet and um and the version of of the onchain runtime we choose as a consequence of that not not the primary choice. Um the version of ZKR is a is a secondary choice. I mean we can actually it's that there are going to be constraints on on which version of Zcar can can be used but but we do have more flexibility there. Um, I'll tell you my experience with um, SHA scheme uh, is that what worked, the only thing that ended up working that really worked in the end for the most part uh, is a um, is a machine type flag that was a combination of operating system and architecture. And that's kind of what we're talking about here. we're we're kind of talking about um because there aren't there is an arbitrary there is no arbitrary combination of these things at any given time. There wasn't always you know a Windows that ran on ARM for example. Um so you couldn't just arbitrarily say I want an ARM 64 running Windows that just didn't exist. Okay. I don't know if it exists now. Um so we had the machine types had sort of both involved Um, I don't really care how we get there, but I think that's that's kind of way we think should think about our backends. And it could be that instead of thinking about compact C taking as uh take there being one build of compact C that takes flags to direct it whether it's onchain runtime or whatever we may really end up with a single release packaging up you know six different builds of compact C each specialized to some combination of these flags that we're talking about um let's not tie ourselves into having compact. It's compact C itself have to be able to have multiple backends and target multiple things. Each build of compact C can target multiple backends um uh as opposed to having one build that targets multiple multiple things. Kevin. >> Yeah, I think that's exactly right. I think for some for some um for some up upgrades that we might be able to support, we might just be able to have some conditional code somewhere in the compiler that the same compiler can just take a flag and for sometimes sometimes you might just want to have a se completely separate binary. Um there was an idea um from from somebody um that uh on the node team that the compiler should just take a node RPC endpoint and say the deploy I want to compile for this network. Um and so we we should also consider is that supported do we provide that as well. I guess the question is, you know, people people can run their own uh copies of the Midnight Network. Um, and uh often do for future, you know, we do ourselves for future uh networks. Um, but you may he may be version locked in the past. I can imagine some consortium of banks running their own midnight network separately from from everybody else and they may be version locked on some some older version. So yeah, I don't know if being able to point to a particular node is the right solution, but um but it's interesting to be able to do uh you know something that's much more contextual than than in the top level tool which is contextual in how I'm going to use this than than on what combination of tools and the combination of tools should be something that falls out of it. For example, even ZKR, we might not want to say I want this version of ZKR. We might want to say I need support for such and such or or um you know, sometimes you do want to say what version of ZK. That's the that's the complicated thing. You might say version 3.2 broke my broke my contract. I want version 3.1. So yeah, I think it's going to be end up being a combination of like individual targets, you know, like a handful of targets that we support at any given time. Um, and then maybe some some flags that allow allow you a little finer control. And these these may be configuration time flags before you build compact C. And they may be they may be uh some of them might be actual flags to compact C. >> Yeah. Okay, that does not leave me better off. >> Yeah, I understand. >> I think that I think the takeaway here is let's let's not define what compacty looks like. Let's define what the tool looks like and then let's let's um lay out the options for how um I don't know how this is like a more of an improvement proposal I mean as opposed to implementation proposal. Um the idea is we want to have this top level functionality and and this should lay out the different options for getting there and we can decide on the actual um in in a later version of it later iteration of the is it quite implementation proposal or or improvement proposal. It's an implementation proposal right? Um it does have uh an implementation section but it is it also has a you know like you you start with defining the problem and the statement of the problem and uh the potential >> trying to remember what the I stands for in CO >> it is improvement I think. >> Okay. All right. All right. Well, then I think it's quite appropriate for us to lay out what we want the user experience to be as the first as first and foremost um from the compact updater tool and then and then try to follow that through to a a useful conclusion. I also think that we we don't want to pull our hair out trying to have one build of compact C that supports everything. So that's why I'm that's why I'm advocating to towards this >> multiple bills of compact C each specialized to a particular target. >> Um but it's all still part of the same release. If you if you invoke shape on on a Mac and you invoke Sha Scheme on a on a Linux machine, you ask for the version, you might very well have the same version, but then if you go ask for the machine type, you'll see it's a different machine type. But it's only >> so you you release the same compiler but then it goes and picks the the machine type based on the host machine. Is that >> Yes. But that happens that happens at configuration time >> and then you run make >> and it builds it builds a version of sha scheme that will target um >> Mac if you're on Mac and it'll build the same version of Sha Scheme but that targets Linux if you're on Linux you know and there's more to it you know it's Linux it's Linux on on this particular architecture it's Mac on this particular architecture and I think that's kind of the model we should go for here so that we don't have like any any one build of compact C having to connect to multiple versions of the runtime or even the ledger. Um so that we basically say here's you know here's the end you know we we we have two flags here we're talking about right now is the onchain runtime and and the ledger. I'm not sure that the onchain runtime is the right the right flag. is probably the right one now, but ultimately it's probably it's probably something more like you know what is the uh node version kind of um and then the onchain runtime is determined by node version but regardless we basically say um you know certain combinations of those two things work on chain runtime plus zkr certain of those work we have a build for each one that works and it's a different But the but the updator knows which one to run. >> Yeah. >> Well, the updator knows which one to run for the defined networks. So, it still does not solve the issue if I'm running my own network. >> Yeah. So you may have to explicitly run, you know, you may we there's always going to be a need for override flags. There's always going to need be need to reach under the covers. So um you may need to you may as as one of those users, you may need to learn which of those builds to run instead of going through the compact updator. Okay, this answers some questions. Opens up a new account of your room. All right. Um, we have 15 minutes. >> I just want to say one more thing. I think >> Yes. >> Yeah, that's fine. I I have to run also to run to an appointment, too. So I have to get off a few minutes, but um I think that this approach that I'm that I'm outlining with multiple builds actually addresses. So we we we need to address the users, you know, we need to give users a good user experience, >> but we also need not to give ourselves a torturous developer experience and our and anybody who wants to contribute to it. And I think this what I've outlined um gives us that that we we have the updater isn't picking a version um but it's picking a build of that version, >> right? And so I think we should we should we should proceed down that path. And what ones we build will be and and what the criteria for which ones we build um we should try to nail down as we finish up the quip. >> Okay. I'll start exploring that. That sounds like a better idea. All right. And with that, uh, if anyone has anything else, now's the time. All right. Uh, folks, you get 14 minutes back. Uh, thank you so much for the conversation and attending the meeting. Have a good rest of your day. Thank you. Bye bye >> bye guys. Hey