Minokawa Community Call - 2026/08/19

Hey Kent, how's it going? >> Hey, how about you? >> Not bad. It looks like we're not getting people today. >> Yeah, we're not getting Kevin for sure. Um, Joe is still joining. Um, I was just in a meeting with him, so he's definitely coming on. Um So, for the secp, Bob's asking where are we at in secp 256k1 verification and compact. And [clears throat] I believe the the run time is uh And Joe can correct me if I'm wrong. Hi, Joe. Um So, there's a the the secp 256 Bob's asking about secp 256k um verification. Um verification. I think he may also mean recovery. I know there's the verif- the recovery procedure in the run time. Is that Is that That's exported from the run time, right? And the in should be in the current release. >> muted. >> I don't know what you mean by recovery. Um >> There's a function called secp 256k1 something's recovery. ECDSA recovery or something like that. I forget what it's called. >> Yeah, okay, okay. Yeah. >> And it's in the TS. I I was looking for it earlier. >> Yeah, secp 256k1 ECDSA recover. >> And so so dapps can get at that if they have the latest run time? >> Yes. >> And do they import utils? >> See where it is. Yes, utils. >> Okay. All right. And then as far as the verification, I think we have support for that and circuit, right? >> You see that verify. We We should. I don't I don't think there was or we have jump jump snow verify. That's all that I see. Actually, snow verification. >> Okay. Unless that's where >> That's also in details. Yeah, that's also in details. >> Okay. I'm going to have to write this in the release notes anyway, so. All right. I didn't mean to hijack your agenda per se. >> Uh actually don't have much on the agenda. Uh anyone has anything to discuss. >> Yep. >> Let's go, David. >> Okay. I didn't have I have slides that I just very hurriedly wrote. Um oh, I can't screen share. No. I'll have to wait for whoever's sharing the slack to stop sharing. >> Wait, are you trying to share? Hold on. >> Yes. >> I see. Um look. How do I stop? I will stop share. Let's see. >> Um yeah, so uh it's very quick one. Um it only takes like Um so as you some of you guys know, um I made a horrible bytecode compiler that no one should ever use. Um it's called Minicomp as Have any of you guys heard of it yet? Excellent. Uh it's an eDSL. Um it's a rusty eDSL. I can show you quickly how it looks. Um it's broadly speaking um it's quite similar in terms of syntax, slightly more verbose like any good eDI eDI eDI eDSL. Um and what it does is it generates um code that can run on midnight. Uh it compiles down to ZK IR. Um and it's relatively good at it. Um it's but kind of start at top. Um It never gets built as ZK IR because that stuff's scary as hell. Um should you actually use it? Um absolutely not. I came up with the scariest possible error message. Uh with uh scariest possible warning which is this proper uh whole project is bytecode. Do not use it. Um because bad things will happen which is hopefully more scalable scary than this one which people continue to use regardless. Um and the reason that we we built it originally was we were interested at seeing um to what extent can we optimize our circuits beyond what Compact is currently doing. Um because we were running into we thought let's make a uh compiler which is really really unsafe. Um but very good at sort of guessing optimizations. Um and we found specifically in uh serialization deserialization code we can actually get a lot headroom out of it. Uh so some parts of our circuit we basically have to put data in, you have to kind of mash that data up a bit, and then you have to sort of put it out somewhere else. Um, in those circuits we found very, very big wins. So, um, on the respond contract um, we saw about a, I think, 25x improvement. Um, although, and the nice thing about that was we worked out why we had the 25x improvement was because, um, the reversed bytes um, system call didn't exist in the version of the compiler we were using, and we worked out if we actually just reversed the input we were giving the circuit, um, it would generate a proof, um, comparably quickly. So, that's a nice quick way of finding an uh, some answers. So, you know, very boring stuff like that is quite helpful. Um, it's also a very, very nice, um, testing suite. Uh, so you guys have the ability to generate ZKR that resembles what contracts generate quite a lot. Um, it has a native compiler as well as a ZKR runner. Uh, there's about 6 million property tests that check that the native native runtime system and the ZKR system are roughly the same. Um, yeah, it looks very similar, um, which means you can kind of write this stuff without having to run the compiler, without updating the compiler. Um, we have really, really strong benchmarking tools in there, which is how we did these kind of optimizations and working out how to get this thing running, uh, running better ZKR. Right now, we kind of basically it's built around the So, we have a corpus of about 320 compact files, uh, which we took off GitHub, um, generated uh, comparable systems, we checked equivalents, um, using sort of gate equivalents, and that's how we originally built it, and then we built the optimizations on top of that. And we wrote proofs showing those optimizations were somewhat valid. Again, all bytecode, very scary. Um, but it also gives you, um, standard Rust uh, to s- safety features, so you have the ability to use, um, for example, we encoded lots of sort of privacy stuff. Um, we did a lot of wrapping stuff in new types. Um, a lot of weird stuff with uh type families. Uh, basically as a way to just sort of see how type safe we could make these APIs. Um, cuz that was a source of problems on our end. Um, also um, we found uh couple of bugs in your compiler. Uh, we found a lot of ways to make your compiler crash with some pretty nasty error messages but which aren't particularly interesting. Um, we found one really nasty security vulnerability um which I'm going to submit at the end of this call uh through your security vulnerability system. Um, uh which I won't be able to go into into this call because it's public, but um it's it was a helpful exercise. Um, and it was only, you know, 40 dollars worth of LM credits, so I guess it's kind of worth it worth it in that regard. Um, and yeah, um we hope that we can try and feed back the findings we have about some sort of optimizations you guys could have. Um, feedback on the bugs. Hopefully this is useful for you guys as a testing and benchmarking tool. Um, and really ideally one day in the very distant future we'd like it to be have people actually write using the Rust IDDL rather than their own language because it makes things like porting really really easy. Uh, so for example, we um had issues with the FAB format, which is what we talked about last time we were here. Uh, we decided to use a subset of BOSH. Um, in uh as an encoding format, basically a fixed width subset of BOSH so you don't have the the branching issues with size. Um, and that means you can use a standard um BOSH encoder on the other end so you can directly use the Rust type on a standard um server. Um, and you can directly serialize that and output to a well-defined format. It's has lots of language implementations, so we found that all very helpful. Uh, do you guys have any questions? >> What was the Uh, thank you uh for presenting the state of first off. Um, I guess I would I'm I'm curious what again the motivation was for retargeting to Rust. Like I mean it's it's cool. Um, um, I I guess I I just wonder if like while you're spending API credits, it could also make sense to direct them towards the compiler itself that exists. Um, and try to include optimizations there. Um, so I guess I'm curious why retarget to Rust. >> The So first of all, it's it's fun. And as I was less than $40 worth of API credits. So I I'm sure your compiler would not you would not have liked to get an LLM generated PR from $40 of API credits that was 50,000 lines of code with dubious benefit. Um, you know, that's uh would be kind of simple answer. Um, broadly speaking, um, we're a Rust company. We use Rust products. Um, a Rust uh eDSL is nice. It works well with our tooling. Um, we have a Rust MPC server that needs to generate proofs. Um, so again having that being sort of directly linked is again quite nice. Um, there's no sort of I've generally found that when you when you have your own language, even a language which is syntactically similar to other languages, um, it can be quite a high barrier to get new developers in. Um, whereas if it's a common language, you can even if it's sort of an uncommon API, um, generally people can learn those things quicker. Um, so I've written a lot of these Rust eDSLs in my life before. I wrote one for what is now Canton. Um, I wrote one back when in 2018. Um, I wrote one for Dfinity which is now their major SDK and wrote something similar near. Um, I found we got much better developer traction off the back of it. And I found that uh um uh there's a lot of weird safety tools out there. Like weird test suites and all that kind of stuff. Um which are really really mature. Um and it's just a lot of work to build them. So, I I guess in let's say this was a useful thing. Um in a year or two's time, what I would see is that like if you are an entry-level programmer trying to make a compact program, you would probably use a compact compiler. But if you're like someone with many years of Rust experience and you really really care about sort of low-level, assembly-level optimizations, all that kind of stuff, you care about really sort of effective benchmarking, you care about testing, and you're largely interacting with a Rust code base, uh with sort of shared data structures, shared marshaling between those different things, I think you might consider using this uh as a sort of alternative SDK. Um and our APIs are exportable to compact. Um so you can relatively easily mix and match, which is quite nice. Sorry, uh we can import compact. We can't export. So, they they can be mixed and matched relatively well. >> Uh-huh. So, yeah, thanks. Um yeah, I I yeah, um yeah, I think there's some there's some interest anyway in in potentially retargeting compact to generate Rust. Um so that we can produce WASM code out of the back end. >> Yep. >> Um there are you know, there's there's no no firm plans to do that, but there there's been discussions about all kinds of of things, and that was one of them. Um so I'm I and I agree with your point about about DSLs. I mean, I've been doing DSLs uh for let's say more than 5 years. So, um yeah, it's it's they have their place for sure and and often it's often as a lower barrier barrier to enter like you said and better interaction um at least with the one language. Um what can we take from this for compact? Um obviously any of the bug fixes we're happy to to apply um eager to apply. Um what it how do you see us taking action on the optimizations that you've identified? Um is do we have uh you know, have you is it boiled down to something smaller than a 50,000 line PR that we can look at to to tell us here's an optimization here's an effective optimization and and then furthermore um how much of your tooling could be retargeted to to to to use for general ZKIR to see um you know, for us to do our own benchmarking on ZKIR independently of this tool and it independently of the of the DSL. >> So, independently of the DSL um provided you can mark regions um in your ZKIR which I see you can um then you can do use all of our benchmarking tools. Um I I think this is a really nice testing suite for you guys um because if you um it's it's just very nice for regression tests. You can make sure that there's some equivalents between um two conceptually similar versions of ZKIR um which is could be help quite helpful in some cases. Um and then yeah, beyond I so I think it's a very very fast testing suite that you can run very slowly and ensure that you have um equivalent outputs. Um but uh beyond that, yeah, I think it's just a sort of interesting So, I'd say that we can give you specific um like optimization. So, reverse bytes, very simple one. Um but um I think fundamentally in the future you may want to have a way for people to write very low-level operations within compact. I'm not sure if that's currently possible. Um uh basically just output your own CK R if you're really sure that that's what you want to do. Um because >> talked about We actually talked about that for at least the VM code. I don't know about the CK R, but yeah. >> Yeah, that's uh well, easy one. It's It's just very low-level stuff is fundamentally people are going to like the performance of some of these circuits is is very bad to the point where it's almost unusable um just cuz of the nature of ZK circuits and proofs. And sometimes if you can get it below um a K barrier, you can cut everything in half. And you can have four times as much machine, um which is sometimes you know, if that's 50 gates, you may want to go and write a couple of uh IR things down there. Um so, yeah. Um Happy to send you these things. Um we might keep working on this. We might use this for some My the majority of it right now is um a mature compiler. You can throw any program at it and it will output the right IR. Um we think we may be able to get this to a point where it's good enough to output the IR of one circuit if we look very carefully at that circuit and make sure it's doing the right thing. Um so, we may use that for a single method that we have to call from it uh approve from MPC. Um just the way to sort of specifically the serialization one. Like it's just the Yeah. Response singleton thing. This is This is enough of like if you if for each user we have to spend 5 seconds of compute time, that's going to burn down our MPC. If it's a tenth and this much memory, then we're at a pretty good spot. Um so, it's Uh yes, Yuri. >> Uh hello, guys. Thank you for letting me join this meeting. I'm for the first time. Let me introduce myself. I'm a part of the Lace team. And we are currently actively helping the Midnight and Chill the teams to deliver self-sovereign identity layer on top of Midnight network solution. And we will slightly experimenting with different tools. And as you know, the code base of the Midnight stack is mostly written in Rust language. And for our prototyping, it was um pretty inconvenient to use Wasm and TypeScript libraries to run particular circuits. And during our experiments, we forked Compact repository and tried to build to improve Compact compiler and emit the Rust code base based on a smart contract code. So, as a result, we have the fork of the Compact repository which can emit Rust code base when you provide minus minus Rust flag. We also tested that all circuits are all simple circuits are compatible between each other in TypeScript or in Rust. And we produced tiny crate in Rust Compact runtime to wire all this generated code with Midnight ledger libraries because majority of these types are already defined in Rust in Midnight ledger. And now I'm working on creating some Compact improvement proposal or I don't know what is the right way to go, but we uh have a pretty good uh test coverage and uh we have a midnight did smart contract that also was ported to Rust and is much easier to call and to deal with it if you use a Rust for channel for wallet or for any other back back um back end applications. So, my uh primary question, uh who is the contact person who can guide me how to properly land this in terms of uh PRs review, some security review, and other stuff. Or I can demonstrate some demo next week. How does it work? If you give me any smart contract, I will try to generate a uh create in Rust and demonstrate you support of a Rust language together with TypeScript. >> So, generally speaking, if you have a proposal of some sort of feature that you want to add, so for example, if you want to add a Rust back end, uh we would go about it by adding a COIP. So, you would write a COIP. Uh I can share a link of a very a template of a COIP and a couple of PRs of COIPs that we have that you can look into. Uh so, you can write a COIP and then uh once we get that COIP uh the TSC goes and reads it and then we'll discuss it. So, hopefully you'll come back to one of these meetings and then we'll have a discussion on it. Um we might pick it up, we might not pick it up, uh but then I'll I'll I'll point you to to the to our COIP process um so that you can take it from there. >> Excellent, person. Uh can I have your Discord um contact or any other way how I can communicate with you out of this chat. >> Yes, we are not very active. Yeah, we're not very active on Discord, but I'll try to keep an eye out on it. Um >> Um I have access to Linux Foundation decentralized trust servers. If you have particular spaces for Mina cover project, I can find you or whoever is responsible >> We do. >> for that. Yeah. >> Let me open Discord. I don't I don't keep Discord open often, [laughter] but I do because I have I have seen it and um I don't check on it often. Uh we should. Uh but I would say the best place to interact is on GitHub. We are pretty active on GitHub. So, once you open an issue, um we'll go over it and we read through our issues and we come across it. So, uh if it happens that you put something on Discord and no one from your team actually sees it, I would recommend interacting on GitHub and we'll sure come across it. >> Okay. Thank you, Professor. So, short summary. We do the prototype where we can emit a Rust code base for smart contract and use the crates in the same way as we do with TypeScript packages without any frictions. It's still prototype. It still need to be properly reviewed and tested, but it works in the majority of cases. >> But one of the things that um there's a a midnight improvement proposal um or at least a problem statement. >> Yes, I I saw it and there is a reference that it should be moved to compact improvement proposal or something like that. I already told this meeting. >> But but I mean it's an interesting question as to what are the right boundaries here for these different kinds of uh things. In some sense, the I I liked the way that MPS uh I guess was problem statement 22 um laid out the the need that we have these desires for different programming languages, different environments to interact with Midnight. Um and uh that what we need is something that says, "Look, if you write a compiler and it target and it produces this kind of stuff, then uh we don't care if you wrote it in whatever language or whatever the runtime is. As long as it does this, it will work on you can run it on Midnight and you have something that can execute that." Um if that I I think we're all sort of in in agreement we want to move in that direction. Um And so, our team internally has been looking uh in recent months and weeks at how to move that direction in a way that is conscious of where we're headed with cross contract calls and and better management of private state and some of that kind of stuff. Um So, I mean, this isn't a way anything where I'd say, "And here is the solution to it all." But, I it feels like I'm observing that there's a lot of different action in this space and it isn't just Rust, right? It's like you'd like to say you don't want it too tied to one language. It's like I mean, the compact says, "Look, we'd like to look a lot like TypeScript. That's familiar in a certain environment." Um but there's a different ways you can move towards kind of separating that. And so, we've been talking about things like, you know, some of the sort of stuff you do that is um uh that right now you have to go write witness functions for, um you You have to go write TypeScript for it. Something that you nearly could have said in compact anyway. Um other things could just be library calls where it says, "Look, we don't care if this thing is written in TypeScript or Rust or whatever it is as long as it satisfies this API." And I think if we can move in more of that direction, then you can say, "Hey, I'd like to run this one in Rust. I'd like to run this one in I don't know, Visual Basic." It doesn't matter in some sense, right? You'd like to be able to move it around. Um and compact and can kind of run forward with it's own DSL that it fits nicely with TypeScript while at the same time I think we need to move in this direction that gives us some well-defined boundaries that um let people agree on as long as I meet up at this boundary, I'm working on this side of it and someone else deals with that part. >> That makes a lot of sense. It's um >> One comment. Can I 2 minutes? Jonathan, I really like your statement about all stuff, but I also haven't been thinking about the right uh right architecture of the compact compiler to support any language. And uh Yeah, my solution is not perfect right now. That's why I want to present it and elaborate how to make it right. But uh in uh it it does what it needs to do for our uh use cases. Um moreover, I thought that it would be great to support a UDL. It's a universal description language. The language that is used for binding the Rust or any other uh native packages to Swift, Kotlin, and other languages. It's a UDL language and uni- unifier wrappers. If it's possible to emit a UDL language from a compact, it might be absolutely trivial to uh generate Kotlin, Swift, Python, TypeScript, whatever language based on UDL description. It's also a big piece of work, but it might add pretty cool capabilities to the compact compiler and the language unit. Yeah. Thank you, David. >> I'm just saying I I wouldn't stand by that approach. And C ABI is a great thing. Um but fixed with C ABI seems to be a sensible way of doing it. Am I not right in thinking that if I pin my ZK ZK I versions, then like I can always keep deploying my contracts, or do you just eventually block deployment of contracts which are from an old version of ZK I I R? >> The on-chain um in some sense doesn't know about ZK I R. >> Okay. >> Right? It knows about the proofs, it knows about this It knows that you you're going to um run this circuit uh and it has this identifier, and here is the the the verifier key for it. Um and as long as you can prove that your execution using that verifier key is a a legitimate execution of it, then the midnight nodes will will run it, right? They don't In some sense, ZK I R is uh really is an intermediate representation between this front end and what eventually becomes the back end stuff and the proofs, and we can all sort of move it around and change it over time. Now, that sounds great. That That said, there is interest in if in the latest version of ledger, not the stuff that's deployed yet, but in the latest ledger code, ledger 9, there is space in there to hold some kind of intermediate representation on chain. And the idea for some of that is if someone when they deployed contracts also put an intermediate representation on chain, um because the the verifier keys or in some sense derived from the intermediate representation, if there were some sort of upgrades that required, you know, some like new curves that required a whole new uh verifier key, and you had the intermediate representation on chain, then you could have some kind of automatic upgrade process that derived to new verifier keys. Right? And if that were there, then at some point old intermediate representations might no longer be understood. But that's really more about providing automatic upgrades. It's not about whether they could still be executed. It's if the chain made some major migration to new curves or something. >> So, this would be like you find a bug in a bunch of previous contracts, and you say, "If you have this instruction, we're going to replace it with these instructions." Um because that instruction was somehow compiled in an insecure way. >> Right, but it would be and it and we and we're automatically generate verifier keys or something. But I mean, that's very hand-waving in that direction cuz who who pays for all that compute time? Who pay I mean, there's the um it's just that we know that there is is no way to do that kind of up right grade if you don't put some kind of intermediate representation on chain. But there's always the fallback that says, you know, there was this major upgrade, everyone who wants your stuff to still work, go upgrade your contracts. >> Yeah, I mean, all you guys have to do is just make a a compiler that can turn out ZK proofs. It's It's so easy. It's >> [snorts] >> Yeah. >> Um okay, cool. >> Wait. Uh do we have anything I I stopped sharing, but do we have anything that people would like to discuss? Oh, what happened to my screen? Oh, there it goes. >> Uh yes, on my side and not sure if it is still in time. So, there is a pull request that is also related to what is being discussed here about the intermediate representation language. Uh let me put the link. So, there is a proposal and the last meeting we discussed two possible implementations. So, one uh which was provided by Kent was adding a hook that allows us external processors to process the hook on uh a given stage. In this case, for the analyzed uh language. For the analyzed program, I mean. And there is the other approach which is adding a a new pass that basically uh generates uh an intermediate representa- uh representation and that other um interpreters can use to to interact with contracts. So, my only question in this case is if uh you guys had time to have a look at it and um yeah, if we can proceed uh with next steps. >> I didn't see you on here, Rodrigo. That you were the one I was referring to who wrote that MPS on the um MPS 22 uh which I love, by the way. That's that's uh we have referred to that quite a lot as a kind of model for what a good uh intermediate representation could look like. Um and there is definite interest in moving that direction. >> So, I can speak for myself. I don't think many people have read the PRs. So, I'm going to put it in agenda and I'm going to ping the TSC to actually look at this PR and then it start having conversations around um around that. We have to let you know it's uh While I'm writing that, uh any other thing people wanted to discuss? >> I'll just say that it it may not have been obvious to Rodrigo. I haven't looked at this yet, but um the kind of thinking you've had about an uh and some intermediate representation that's not just for the proofs, but really represents the contract. Um it comes up a lot in conversations. We're doing all this work uh moving towards systems of contracts and cross-contract calls. Um and if you do that and you want to support private state and cross-contract calls in the destination contract, you end up needing some notion of calling across to something where you don't necessarily have TypeScript code or JavaScript to run it. Um and you want some kind of intermediate representation storage. And so, um there's a big intersection between some kind of uh language-agnostic intermediate representation and the full generality we need to achieve with cross-contract calls and multi-contract systems. And so, um we're trying to think a lot about co-design of all of that in the coming months. >> It makes I remember someone mentioning that the cross-chain uh the cross um call for for contracts is adding a lot of changes that will probably fix all those issues in the future supporting it in ZK uh but yeah it's probably a few months still to be ready. >> Okay. Uh all right. Uh any other topics? Why did I get this wrong? Oops. Oh it's the same. Okay. Going once, going twice, and going three times. There's none. Okay. Uh I'll try to get a TC to respond to to to start moving on this call you and um get some direction. Okay. Uh thank you everyone for attending and um I don't have any anecdotes and not no no fun facts today. Okay. Um and you will get about 24 minutes back. All right. Uh have a good day everyone. Thanks. >> All right then. >> Bye bye guys. >> Mhm.