Why Privacy Has A Time Problem

SPEAKER_00 0:13

Today I am joined by Arthur Breitman, co-founder of Tezos. We're here to talk about Zell, an experimental project exploring private post-quantum payments on Tezos Testnet. The question behind it is simple. If public blockchain data can remain available indefinitely, what would it take for private transactions to stay private years from now? Arthur, thanks for joining us.

SPEAKER_01 0:41

Thank you for having me.

SPEAKER_00 0:43

It's our pleasure. Most people think about blockchain privacy as a present-day question. Can someone see this transaction right now? But public blockchain data can stick around indefinitely. Is the right starting point here that blockchain privacy has a time problem?

Zero Knowledge Proofs Versus Memos

SPEAKER_01 1:04

Uh so the the answer is partially yes. And I used to think that it didn't. And let me explain a little bit. So most of the systems which have been used to provide privacy on blockchains have relied on zero knowledge proofs. And a zero knowledge proof, the zero knowledge part that you get, it comes from information theory. So the information is just not there. It's not encrypted in a way that you can't find it, it's just not there. And so it doesn't matter if you have quantum computers or whatever you have, the laws of physics tell or not even mathematics tells you like you can't access it. So I thought, okay, this is all safe. You might be able to forge fake proofs in the future, but you won't be able to see the data. And the picture is a little more complex than this. Because when you make those transactions on most systems today, I don't just go and tell you, hey, by the way, uh I've made a transaction and you know you should check your your your balance. You have a transaction for convenience. Um, an encrypted memo is added to the blockchain. And it's way more convenient like this because I don't have to like, you know, if I receive a payment from you, I don't have to give you my email address, I don't have to give you a way to reach me with information, I can just receive it. That's important. But it means you have an encrypted memo that sticks around. And that memo is encrypted with a key that can itself be cracked by quantum computers. So if you look at a system like um the sapling circuit on Tezos today, and of course, sapling came from Zcash, so it applies to Zcash as well. Um it's not as bad as, oh my god, everything is going to be decryptable. The scenario is the following. If you know someone's public key and you have a quantum computer, you'll be able to decrypt the memos, which is why usually it's recommended to like not reuse your public key, give every single person a different public key. It's not always practical. People don't always do this. And so, unless you have really, really good hygiene today in using the systems, um, there's a risk that if you use someone with your public key and access to quantum computers, maybe not you know, not next month, maybe in 10 years, maybe in three years, um, can decrypt those messages.

SPEAKER_00 3:30

Permanence is the part worth staying with for a moment. If encrypted private transaction data remains part of the public record, privacy has to be judged across time, not only at the moment the transaction happens. So, what does it mean for a private transaction to have a long memory?

Harvest Now Decrypt Later Risk

SPEAKER_01 3:49

Well, that that that's the thing is uh every transaction on a blockchain is essentially like broadcast publicly, and and and and a trick to to to you know it it's it's an it's an abnormal type of affair, right? That before blockchains, there are no system in which all the transactions are public. It's kind of it's it's kind of weird. Uh and privacy preserving solutions on blockchain restore some normalcy, right? What they do is say, look, we're going, you know, if we're not going to like broadcast it for everyone, we're going to encrypt it. And then because it's encrypted and we still need to check it that it's valid, we'll have a proof that it's valid. So you'll have an encrypted transaction with a proof that it's valid. Uh and and that can restore a little bit like the status quo. What would you expect out of like a normal payment system? Uh it's not a radical thing, it's it's fairly normal thing to do, uh, although it's it's been framed a bit differently. Uh now on a block, you know, on a blockchain, typically, if your information is public, the fact that it sticks around forever doesn't really make a difference because I would say like as long as your information is public once, we should assume it's going to stick around forever. Like you should not, like your privacy should not rely on the fact that someone is going to kindly delete the data. Uh and it gets a bit different once you start talking about data that is encrypted. Um, there's a concept that people talk about for quantum computers called harvest now, decrypt later, where an adversary could you know get a bunch of encrypted messages and they can't decrypt them now, but later on with quantum computers they have access to it and they can uh decrypt it uh retroactively. And usually it's not really a problem that blockchains have, because in general, there is nothing to decrypt, right? The problem that blockchains have is at some point in the future you can forge transactions, but as long as you migrate before that, the old transactions are what they are, they're not going to change, they're in past blocks, they're not they're not. So as long as you migrate to your keys, you'll be fine. It's a bit different once you start having encryption come into play, and that's where you know like the privacy-preserving systems do involve some encryption, and so to some extent, they are subject to this harvest now decrypt later problem.

SPEAKER_00 6:04

Well, this turns a general cryptocurrency concern into a specific engineering problem: private payments, long-term data exposure, post-quantum assumptions, and a roll-up-based implementation. What made this problem interesting enough for you to work on personally?

SPEAKER_01 6:24

Oh, I mean, it's it's it's super interesting to begin with. I think it's like it's it's it's a really interesting uh engineering challenge to be in with. It hasn't really been done. I think like I don't want to make a blanket statement because a lot of people are doing a lot of crypto projects. I haven't heard of any crypto projects having um quantum resistance uh privacy. There may be some tests out there, and and you know, Tell itself is only uh a test net right now, so it's not it's not in production. Um but I wanted to challenge myself a little bit. Uh and I also thought that you know, part of the problem with the systems is that the proofs from uh post-quantum systems are a bit heavier than what you can get with a lot of like the elliptic curve family of you know of constructions will give you more efficient proofs. So because they're a bit heavy, people have considered that this was not very practical. But then I remembered that Tizzos has a DAL, a datability layer that actually lets us put a lot of like, you know, is the data you don't really need to know what to do on the blockchain, but to check that it's valid. And that's exactly what a proof is. And so I figured, wait a second, we can actually put those proofs on the DAO, the data ability layer, and because we have this, it makes it like a really interesting fit. Um, I also wanted to um, you know, I I've been doing more uh more agent coding uh uh as of late, um, it's given me an opportunity to to go back and to like uh and and find the time to actually do direct uh direct contribution. And it was quite interesting. I think there's a misconception that uh if you use agency coding somehow you're going to like make a lot of bugs and have all these problems, and it's certainly possible uh to fall into that trap. Um, I don't think it works like this. I think I think what it does is that it makes it a lot easier um to develop. And uh there was actually uh this is inspired by by something like Vidalek Butterin was actually saying this morning, but it's I think it's completely true. It's like it made like programming with bugs went from like normal to extremely easy, and programming with like a high level of security came from extremely hard to now like just moderate. And I think if you you know if you use the right approaches, uh in particular if you use you know you can use tools for informal verification, um, you can uh do multiple uh implement separate implementations, uh, you can rely on very, very strong unit tests. So if you have all of this like knowledge of good security practices for writing robust code, you can actually elicit really, really strong uh systems out of it. Uh, I also wanted to be more familiar with uh some of the post-quantum uh you know proving uh tools that exist out there. You know, and part of this also stemmed from a general push um that or drives that I've had to really try to figure out the post-quantum situation for Tezos. So I would think I don't think you know that there's today there's not a lot of like people using um the sampling tools that are available on Tezos. So this is not a burning need. Uh more pressing is uh converting Baker signatures into post-quantum signatures and having like aggregation around it. Uh the DAO itself, you know, it's it's the DAO itself also needs to be moved to a post-quantum system. We have some pretty good ideas on how to do this. I wanted to become more familiar with it. Um and so I've I've been making experiments. So Zale now is like available as a as a as a test net, it's something that can be used, but uh actually I've spent quite a bit of time on data availability layers uh and and and proof aggregation for uh for bakers as well, which is you know less visible, uh less fun, but probably a bigger priority as well.

Why Zell Exists On Tezos

SPEAKER_00 10:16

The less visible updates we I we find ourselves often going, what's going on? We only feel the work, we never see the results, but we do appreciate them. So thank you. Post-quantum cryptography makes long-term protocol design very concrete. The assumptions underneath the system can change. Does post-quantum cryptography make the need for long-term protocol adaptability more concrete?

SPEAKER_01 10:43

Uh it does. I mean, I I think that that need has always been present, and to a large extent, I would say a lot of protocol designs have converged. I think there's like a consensus. Well, among a small group of people, there's a consensus as to what constitutes a good design for a blockchain. Um that consensus is not reached like Solana, for example. I but uh there's a group, you know, among like I would say, like, you know, blockchain researchers, uh, I think there's a general idea on how to scale. So to some extent, uh when I started working on Tezos, there was a lot to be discovered, a lot to be done. It wasn't even clear how to do proof of stake. It wasn't even clear what form smart contracts should have. A lot of these questions have been answered. Um, and but for the longest time, you know, post-quantum was a big one. Uh, and it's one that everyone will eventually have to face. Uh once you have like systems that completely scale and are post-quantum, will there be problems that you need to uh yes, probably they're harder to foresee. I think you always needed adaptability. Uh the difference is that at one point uh the problems you were gonna have were kind of foreseeable. And then you know, once you have systems that like completely scale, are private, are secure, uh, and are you know quantum resistant, it's we don't know what the uh what the what the what the topics will be.

SPEAKER_00 12:11

The oh you're fine. The claims around Zell need a careful boundary. People can hear post-quantum or private payments and run too far with the claim. What should people be careful not to claim about Zell?

SPEAKER_01 12:25

Oh boy, oh well, first of all, that is you know production ready. Uh, I think it needs like, I mean, there's been quite a bit of work actually going on into like ensuring the the the security of it, but it's still proper audits, uh, it still needs proper integration into wallets before it could be uh before it can be used uh on chain. Um there's also the fact that um whilst you know the entire system is is post-quantum, one solution to the um decrypt now and harvest later problem would have been to not make the entire system post-quantum, but just the encryption part. So like just the part where you encrypt it.

SPEAKER_00 13:03

Oh no.

SPEAKER_01 13:04

Oops, sorry, I dropped. Uh can you still see me?

SPEAKER_00 13:08

Yes.

What Not To Claim About Zell

SPEAKER_01 13:09

Yeah, so I was saying uh one possibility would have been to just do the encryption part in a post-quantum way and not the you know the whole rest. It was interesting, right? As a as a bit of a proof of concept to say, like, can we do the whole stack post-quantum? With that said, it runs as a rollup on Tezos and which itself has a not a post-quantum you know architecture, it still has like elliptic curve or maker signatures. The DAO itself relies on on the KCG proof. So whilst like by itself is fully you know like quantum resistant, it runs on a non-quantum resistant system, right? So that that that that's something to bear in mind. Uh, so it's it's definitely uh about starting to get familiar with this technology and you know demonstrating it, getting used to it. Uh, it was also a way to experiment with like um different technologies around um like what is a good circuit uh for uh uh for uh for um sorry for shielded transactions. So there's a lot of good ideas in sapling, like uh um you know viewing keys, like inbound viewing keys, outbound viewing keys, delegated proving. There were others that came from other circuits. So Penombra had this concept of um detection key where you can scan the blockchain and see if a transaction is probably yours or like probably of interest to you, but you don't know anything of the content. And that's very useful if you have like a wallet service. You can just give it this key and say, like, hey, you might be interested in this, and then and then you can take it and look at it, as opposed to giving them a fuel, a full viewing key. Um, and yeah, at some point, like you can you can start building all this like Legos, and uh it's it's really interesting to be able to like construct the circuits and have all the properties you uh uh you want.

SPEAKER_00 14:58

A working prototype can be valuable without being a finished product, it can show a design path is real while still leaving review, testing, and hardening ahead. What does this prototype prove and what does it still leave unproven?

SPEAKER_01 15:12

Uh well, one, it proves we can do it. Uh two, it proves uh intent and interest in doing it. I think a lot of people are not going to bother uh doing this, and this is you know, I think something that at some point uh should be a part of uh Tezos X in the same way that you know if you wanted to create um chiclet transaction as part of a smart contract on Tezos, you've been you know able to do that for a few years. Uh, you know, that should remain possible uh on you know on a post-quantum system. When we've discussed transaction to post-quantum, we identified the list of let's say with some you know different core teams working on uh on a on a Tezos protocol, uh have identified the parts that you need replacing, and you know, there were signatures for transactions, uh aggregation of signatures for bakers, the databability layer, the randomness generation from uh the VDF, and then certain vehicles and primitives like sapling. So that's a drop-in replacement for that, and uh uh some um uh some time lock puzzles, which are are really used. So I don't think this one is like a big uh a big priority. So this is like one one brick uh out of uh out of what comes.

SPEAKER_00 16:25

So what had to be built for this to become sort of an end-to-end system rather than just a paper design?

SPEAKER_01 16:32

Tasles have to be built. That's the thing. It's like it's um we had to have uh database layer, we had to have uh a L1 blockchain, we had to have a rollup stack. But it is interesting, it is uh you know exciting that it is actually like now quite pragmatic to go out and like build a rollup kernel. I just you know that that just works, and there's extremely good documentation for doing it. It's a lot of good code examples, so you can build your rollup kernel now and uh and try a lot of things, and you have you know you have the infrastructure in place to do it. But internally, um the you know the the parts about it are essentially they are there there's there are the circuit the circuit parts, which are about like making the proofs that you want to make, a bit of wiring uh around uh around the proofs and around encryption of notes, a bit of infrastructure around like how to send transactions, how to have like remote provers, uh and uh uh and a bit of uh uh smart contract code to do bridging of assets between uh uh L1 and uh uh and the roll-up.

SPEAKER_00 17:43

Now, once something becomes a running system, the clean design meets friction. Some parts get harder, some parts get clearer, some assumptions get tested in ways a spec can't fully show. What did you only learn once this became a working prototype?

SPEAKER_01 18:10

I mean they were there were learnings around uh around the way. Like I made some mistakes and I fixed them and realized like I had like thought of thought of it like you know, you know, so sort of things in the right way, sort of other things in the wrong way. Um but I don't think at the end there was like a particularly like salient lesson. You know, it's like the small lessons, but you know, the lessons are the fact of like, ah yes, you really need a two-phase commit for bridging, otherwise, you know, your your your tokens can get stuck on a bridge, like this type of like bug that are easy, you know, like that you can make easily with uh with a roll-up. So like very, very lessons very, very specific to roll-up construction and not like particularly of general interest.

SPEAKER_00 18:53

Perfect. Well, proof size is one of the hardest constraints here. Post-quantum friendly privacy can bring heavier proof data and larger proof data changes when the system needs it underneath. Why does proof size matter so much on a blockchain?

From Prototype To Real System

SPEAKER_01 19:08

Well, on a typical blockchain, if you don't have a tabability layer, everyone needs to download all the data. And so, you know, the the proofs are about 300 kilobytes per transaction. And so if you only have like 10 transactions per second in a system like this, that would already be three megabytes per second that everyone has to download. If you have 100 transactions per second, that's like 300 megabytes. So it's it's too much to push on a on a layer one. It's far more appropriate to do this on uh a data ability layer because what the data availability layer does is that it shards this responsibility so that many people download small pieces of the data and can reconstruct it together. It still requires a rollup operator to download all the data, but or any rollup operator, it's not a single operator, but anyone running in a rollup node needs to download all of the data. However, that's fewer people and they may have more performant hardware, more performant bandwidth in order to do that.

SPEAKER_00 20:12

What does the Tesos Dow change about the design space?

SPEAKER_01 20:16

I think it opens it up to uh uh to systems which need more data to run, like more witness data, bigger proofs, these type of things. And and what people have contemplated in the past is doing proof aggregation. So where you'd have like a roll-up upper, you know, a roll-up sequencer which does more than sequencing, which also takes the proofs, aggregates them, and then puts an aggregated proof. Um, but that gives a lot of like power, uh, not so much power, but it it gives a lot of importance to that to that sequencer. There's no sequencer right now in this uh in Zell. And I think like people can be shy to be a sequencer for a system that does shield the, you know, that that purely does shield the transactions.

SPEAKER_00 21:05

Yeah, that's fair. Uh this also raises the question. Zell puts heavier cryptographic work in a roll-up rather than forcing every detail onto layer one. Is this the broader pattern? Heavier cryptographic systems run in roll-ups while the Tezos protocol provides settlement and data availability?

SPEAKER_01 21:24

So the load isn't that much. Like verifying some verifying a proof is fairly fast. Uh, it's not as fast as verifying a signature, but it's not messy. Like the computational cost is really on the side of the prover. Like building the proof takes a lot of RAM, takes a lot of CPU. Verifying the proof is fairly, fairly fast and fairly easy. Um, but in general, I would say it's it's it's it's it's all com you know, all computation, all of that can go on uh is much more efficient to put that into uh um it's in into construct it at at a layer two system rather than at the layer one system. So, you know, like uh A clean separation is that your layer one focuses on consensus uh and stacking. So that that gives you a platform where you can like basically timestamp your and decide that and and have a data ability. So you can say, like at this point, you know, like this blob of data was available, and then behind that, you have systems figure out like where is the data, download the data, execute the data, do all of this. But the point is, like you need a single honest participant to do this. Whereas on a rollup, you would need like sorry, not on the L1, you need an honest majority. So, like for the L1, you want to be more conservative, you want people to do, you know, you want the validators to do less to really focus on like data line security of the system, less so on the performance. So it's kind of like a you know, you separate your security in your performance, and that's a really elegant way to scale.

Proof Size And The DAL

SPEAKER_00 22:53

Private payments still need practical controls. Users need ways to detect payments, recover information, and reveal specific details when needed. How should people think about viewing keys, detector keys, and selective disclosure in a private payment system?

Viewing Keys And Selective Disclosure

SPEAKER_01 23:11

Yeah, so you know, there's there's the version of all these protocols where you don't have viewing keys, you don't have any of this. Everyone just runs a node that always listens to the uh to the blockchain and that all that happens. And that's not very practical if you're not always online, if you want to use a wallet on your phone, if you do different things. And I think that was one of the like one of one bit of um of Zcash early on that was really inspired was thinking through all these different keys and all these different delegations that you might need. And you have this idea of like a master key that gives you that lets you do everything, and then you can derive and devolve like small powers to different parties. So the idea of the viewing keys, for instance, is like look, you don't want to listen to every single block on the on the chain. So you could give someone your viewing key or give a wallet your viewing key without your spending key. Maybe your spending key stays on the hardware and like your computer only has your viewing key, but then it can download all this transaction and tell user yours. If you have a detection key, you can even do something a bit better. You have a service you give the detection key to, and with some error rates, we say, like, oh, maybe that transaction is yours, right? So you get a subset of the transactions. Then maybe you have another service which has a little more, which has your viewing key and say, like, oh yeah, that's that's what's happening here. And then you can spend and you can do all the things. So it really lets you use external services, but only give like a minimal amount of power to these services. Likewise, there's a possibility to use an external prover. I think that's important because the prover does take a lot of CPUs. Like on a beefy machine, you can do prof the proofs in seconds, but it will still they will still still take like loads and loads of RAM, more RAM than people might have even on their laptop, for example. So you want to, if you want to use an external prover, um that maybe you're going to disclose some stuff to the prover. The prover might know what the transaction is, but you don't want a prover to be able to spend your funds. So you only trust the prover not to go around and like tell everyone a statement that they proved, uh, but not to not spend your money. So, like again, that's a proving key. Uh in terms of the selective disclosure, I think it's also uh, and this is again something that was introduced by by Zcash culturally, this idea of thinking about privacy not as hiding, but as selective disclosure. And that's a default. You know, when you when you when you have documents, you know, in in your home, when you have emails, all of that, you know, they're not like hidden, it's just that it's disclosure. You choose who you're going to disclose to. And legal systems are completely already well equipped with dealing with this type of information. You know, it's called a subpoena, or it's called discovery. You know, if uh if the if the police seems, you know, like thinks you've done something wrong, and you know, they can go uh to your uh they can go to your email provider and try to subpoena the emails, for example. Uh or they can, you know, they can they they they can so in the US, for example, uh it's the legal system most people are familiar with because of the because of movies and and and and TV shows. If they're not being familiar with their own legal systems, because they may not have faced it. But like you'll have this thing where you say, like, well, you know, you might not have to testify against you, but like if you want to defend yourself, you better be able to like actually like show up evidence, and so you have to disclose these things. Um, that's a concept of selective disclosure. You choose who you disclose to. And from uh even from a regulatory perspective, you can think of regulation this way. You can tell people, like, look, maybe you know, you get audited. For example, you get a tax audit, and they might come in and say, like, well, you know, you have to show us those words, sir. Never well, you know, it's very, it's it's it's it's a very uh it's like it's very high-stake paperwork, it's very annoying. I've I've had tax audits, it's uh it's not it's not pleasant, just takes a long time. Um, I do have a note on this, but I'll I'm gonna I'm gonna put a pin on it. Um, but let's say you know this happened. Yeah, they can they can make you disclose it when we see your transaction, you show your key. And on a blockchain, it's weird because on a blockchain by default you disclose it to everyone. And so I think this notion of selective disclosure is important to get people to understand that there's nothing weird about the privacy, you're not hiding it. You're not hiding it. You're saying, like, no, I'm just like not giving it to everyone. And you know, if you want to know what a transaction is, uh, you know, like and you have a legal right to know, then you can go and assert the legal right, and then you can compel me, you know, and and and then you know, like you can either like put me in contempt of court for not showing my key, you do whatever you want, but like by default, you're not just going to like force me to like broadcast it to the entire world to see. And I think that's like a very reasonable way to look at the uh uh to look at the question. I'm actually saying assuming we have the you know, as assuming, you know, first of all, it's it's it's very silly to to cheat on your taxes. Don't don't don't don't don't do it, it's just it's it's it's not it's not worth it, it's not worth it. Uh, but with that said, even if you don't, even if you've done everything right and you get audited, it's still a massive pain in the eyes. Um the thing that's really useful though is like age, you know, coding agents really, really good at chasing paperwork throughout your inbox and through your documents. And a thing that used to be extremely proof painful in terms of like chasing everything, chasing you know, like finding all the receipt, finding all of this. Um, you can now do it for a fraction of the cost and a fraction of the time. And so I think that reduces the pain immensely if it, you know, if you know, if God forbid it happens to anyone. Uh are you using cloud code? Are you using OpenClaw, Hermes agent? No, I use mostly cloud code and uh and and codecs uh quite a bit. And with some frameworks that I have around them.

SPEAKER_00 28:48

Okay, interesting. Yeah, I'm just curious what you sorry, aside.

SPEAKER_01 28:53

No, I mean it's it's it that's the thing. It's like people think of them as coding agents. They're actually quite good at um admin tax task, admin task and chasing paperwork.

SPEAKER_00 29:02

Right, yeah. I'm seeing like I think Anthrooptic just dropped a legal seal for Claude recently.

SPEAKER_01 29:07

So there's uh yeah, but we know without even without even this, it's like you know, a simple question is like I don't know how many, like how many, how many days have you spent in this country? If you travel a lot, then again, it can actually be a tricky question. Um, you know, here's my calendar, here's my email. Figure it out.

SPEAKER_00 29:30

Well, Zell shows one side of what can be built on Tezos, other use cases bring out different parts of the infrastructure. Outside of Zell, is there anything being built right now that's got your attention as well?

SPEAKER_01 29:44

Uh, I mean, I I I I took a particular interest in like the post-quantum stuff. So, like um, there's really interesting uh techniques for doing data availability in a post-quantum way, which are actually quite uh quite efficient. Uh so I'm looking uh I'm looking at that. Uh it's really fun because it's really like you know like deep core engineering. Uh, but there's also you know uh activity happening on the app stuff. I'm also like I really like the developments with metals.io uh which like are are pushing more metals and more more products out there. That's quite interesting. It's very, very different type of uh of work from like the deep, nerdy core engineering work.

SPEAKER_00 30:24

Well, Zell may change over time. Later versions may look different from this prototype, but research implementations they they help show what part of the problems are real. If later versions look different years from now, what would still make this prototype an important experiment? Sorry, if if what I can guess if if later versions were to look different than the current iteration right now, what would that look like in the future?

What Changes In Future Versions

SPEAKER_01 30:54

Um I think it would look pretty similar. I think maybe different proving systems. So um Zale uses um work done by Starkware, uh, so Cairo uh S2. Uh and there's a new type of proving systems which are very similar to Stark, which are using multivariate polynomial um as opposed to univariate polynomial and different techniques which are maybe a bit more efficient. Um and they are part of a project called um lean VM, which is developed uh in the Ethereum community. So I've been playing with lean vm, it's very efficient, uh, it works very well. So it's I think it's a it's it's quite a um it's it's really good um replacement for the the stockware libraries. However, um it really focuses on proving it doesn't do zero knowledge yet. Uh it's it's it's doable, it's not a it's not a massive like endeavor to to to turn this like Lin VM into something that does zero knowledge, but it's not been their priority because it's mostly used for for scaling. However, I would say if and when uh lean vm becomes useful for uh zero knowledge uh proofs, it can be a drop-in replacement. What's interesting is that you're not you know you're not tied to a proof system. At the end of the day, what you're what a an encrypted ledger looks like is essentially a Merkle tree of hidden commitments to like to little nodes. That's what it looks like. Any in and you can use any proving system on top of this. That's the thing. You're not you're not necessarily tied to one. As long as you can prove some statement about like, hey, I know you know, like a pre-image of this hash that has this and this and this property, you can accept that. So you don't have to like you don't you're not stuck with one.

SPEAKER_00 32:43

Well, Arthur, I really do appreciate you taking the time out today to share with us and explain this. Uh it it's a lot to go over and it's a lot for the average person. And I think you really did make this a lot clearer for a lot of us. Thank you so much for your time today.

SPEAKER_01 32:58

Well, thank you. And you know, I I I I know uh we haven't like put out a uh a post yet, but you know, look look look out for it. You'll be able to uh you know give uh uh give Zell a try and uh and uh uh and and launch it and uh and play with the code is already out there, uh, but there will be a bit of a bit of infrastructure for everyone who wants to play with it to play with it.

SPEAKER_00 33:19

Well, thanks again, Arthur and uh I look forward to the opportunity to do this again. Thank you very much.