Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Evan Shapiro & Izaak Meckler: Coda – A Succinct Blockchain

Episode Date: July 12, 2018

One of the key scalability challenges with public cryptocurrency blockchains is that their size grows linearly with the number of transactions. Mature blockchains such as Bitcoin and Ethereum contain >170GB and >1 TB of historical data respectively. New nodes joining these chains need to download this data and verify it in order to become a “full node”. The number of full nodes is a key measure of decentralization, and difficulty becoming a full node translates into future centralization. In this episode, we are joined by the duo of Evan Shapiro and Izaak Meckler, CEO and CTO at O(1) Labs respectively. O(1) Labs is a pioneering company that uses zkSNARK technology in order to construct a cryptocurrency blockchain, called Coda, that solves the blockchain size scalability bottleneck. New nodes joining the Coda network will be able to trustlessly boot up in under a minute by verifying cryptographic proofs that attest to the validity of the current chain. This technology has great potential to enable decentralization, and for one blockchain to be a light client of another blockchain. Topics covered in this episode: Scalability challenges of current cryptocurrencies Background on O(1) Labs and their mission statement How Coda uses succinct computational integrity technology (zkSNARKs) to enable further decentralization of blockchains Snarky – a domain specific language for zkSNARK computations Current state of Coda and roadmap Episode links: Coda protocol website Coda Whitepaper Presentation on Snarkly by Izzak Meckler zkSNARKs in a nutshell by Christian Reitweissner zkSNARKs in a nutshell by Vitalik Buterin Coda presentation at hack.summit("blockchain") 2018 This episode is hosted by Meher Roy and Sunny Aggarwal. Show notes and listening options: epicenter.tv/243

This episode of Epicenter is brought you by Shapeshift.io, the easiest, fastest, and most secure way to swap your digital assets. Don't run a risk of leading your funds on a centralized exchange. Visit Shapeshift.io to get started. Hi, welcome to Epicenter, a cryptocurrency podcast that interviews academics, entrepreneurs, and leading personalities of the cryptocurrency and blockchain technology spaces. I'm Mihir Roy. And I'm Sunny Agarwal. And today we have with us Evan Shapiro and Izak Meckler, who are the CEO and CTO of

01 Labs. Pleasure to have you guys on the show. Evan, could you mind introducing yourself? Yeah, thanks. Yeah, likewise. I'm happy to be here. Yeah, so I'm Evan. I'm the CEO of O1 Labs.

So, yeah, Izzy and I founded this company last year to kind of take some of take some of the recent things coming out of cryptography from ZK Snarks to improve resource efficiency of blockchains. I guess what's my background? Yeah, so let's see, so yeah, I guess I've been like interested in cryptocurrency for a while now. I remember running some nodes back in the day, like 2010, 2011, and like Bitcoin and Random Alcoins.

Last year though, Izzy and I really started getting into the space and thinking what we could actually do to improve it because we saw a lot of hype and potential for cryptocurrencies, but we, like, it felt like the technology wasn't really matching up to that. So, yeah, so we started looking into, like, scaling for cryptocurrencies, and we started thinking about Bizzing and consensus. And we had a solution that, you know, got cryptocurrencies up to a few thousand transactions per second, but, you know, once you've done that, you have a whole other problem on your hands

because you just dumped a lot of transactions onto a blockchain. And now you have this huge blockchain, everyone kind of has to share and handle somehow. So that's when we started thinking back into Izzy's research and into ZK Snarks and resource efficiency. Cool. And Isaac, do you mind introducing yourself and what was your background?

You were doing a PhD in cryptography and how did that lead you into getting involved with the blockchain space? Yeah, sure. So I'm Isaac. Some of my friends call me Izzy. I guess Evan does. Right, so I had, I was until January of this year doing my PhD at Berkeley studying

cryptography, and I was doing kind of theoretical multi-party computation stuff, but I had taken a class with Alessandro Kieza, who was one of kind of the pioneer, really a pioneer of making Snarks practical. And Evan and I, as Evan mentioned, have been discussing cryptocurrency scalability and the idea of using SNARKS to basically compress the blockchain seemed like a really clear and powerful application. And so we started thinking about this,

and ultimately the project was getting so exciting that I decided to take a leave of absence for my PhD to work on it full-time. So, Alessandro Kiesa, of course, is one of the authors of, I guess, like the Snarks for C paper and the Zcash paper both. So it's like many of the our viewers would have heard of Ellie Ben Sasson, who is a professor at the Hebrew University of Jerusalem. But then Alessandro Kiesa has always been one of his co-authors in all of these groundbreaking snark papers. So, you see, you've also worked at Jane Street as an intern, and Jane Street is known for the usage of OCamill and functional programming in its quantitative trading systems. And I see that you're also using functional programming quite a lot in in in O1 Labs.

So could you give us a sense of sort of your background with functional programming and what you see as it's advantages that led you to use this paradigm in your work? Yeah, sure. So I worked, as you mentioned, at Chainsreat as an undergrad as an intern and also after graduating full-time. And, you know, I worked at Chainsree because I was interested in functional programming. I had always been kind of a functional programming person, I guess as an undergrad. I first got into it.

And I would say, you know, well, before working at J-Street, I mostly programmed it Haskell and I guess Elm I did some work on the Elm compiler. Once I worked at Jane Trude, I was sort of fully converted to the OCamill way of doing things. And I think our reasons for working with OCamill are very similar to Jane Strait. So there's this idea that well, software should be correct, especially when a lot of when a lot is on the line, be that money or people's time or safety or anything like that. And I think that, I think that I think one of the best tools that we have for writing correct software are statically typed functional programming languages. Well, really languages with good static type systems, but it happens to be the case that most of those are functional programming languages.

And I think, you know, if you're thinking of starting a new project where correctness matters, kind of the natural sort of choices are maybe something like Haskell or O'Caml or maybe Rust. those all have sort of different tradeoffs, you know, Rust is a bit low level and is a good choice for cases where things are really performance sensitive. But otherwise, you know, Haskell and Okamel are a bit higher level, a bit easier to sort of work with quickly. And as for why O'Camel, you know, on Haskell, I think people who are familiar with O'Camel, you know, these arguments will sound very boring to them because they've probably heard them a thousand times. I think they're well internalized by every OCamill programmer, but OCamill has an amazing module system, which is a great tool for making structuring, organizing code, and working with a large code base and with a lot of people a lot easier. Okay, ML is also strict, which makes performance easier to reason about. Those are, I think, the main things that sort of make it in some ways a more practical choice than Haskell for large.

project, at least in my opinion. I see. Awesome. Cool. And yeah, so, you know, you guys didn't mention it a little bit in your introductions about like you guys saw like some of the scalability problems in the blockchain space and wanted to help solve them. Can you tell us a little bit more, though, about the Genesis story of O1 Labs? Like, you know, how did the two of you meet and like, what's the vision here? What are some of the problems you're working on, like your main product Soda, if I know about Koda and Snarky, is there anything else you guys are working on? Yeah, definitely.

I guess for like the origin of the company, so Izzy and I knew each other from high school. We both grew up in the same town and went to the same high school together. You know, I was living out in San Francisco after college and Izzy came out here for his PhD and we just, you know, started hacking on projects together, sort of when we had free time. I think I mentioned before, the whole thing we tried Byzantine Consensus, which led into resource efficiency issues which led into ZK Snarks. I guess that's kind of how it all got started. And then we decided to really dive into the idea and make a company out of it and really build it.

Yeah. So this is this really cool idea of like, it's sort of hard to communicate this sort of vision. But the idea is that you have a bunch of programs, which are all all proving things about their behavior to each other. And the net effect is that you can have sort of mutually distressing programs, which are able to sort of verify that the programs that they're interacting with are actually behaving correctly without having to sort of redo the computations that those other people are doing. You know, to give a simple example, you could imagine, well, okay, so right now, you know, when you log on to Facebook.com, okay, or let's say to any website, let's just say any website, you get served to ads. And you know really nothing about how those ads are generated or what kind of information is going into those ads that are being shown to you. But it would be nice, for example, if when you were served an ad, you somehow got some

kind of guarantee that that ad was generated without using any of your personal data. So without using your socioeconomic status or your race or gender or anything that you might not want advertisers to use when kind of targeting things toward you. And the primitive of verifiable computation makes that possible. It makes it possible to send someone a piece of data and then a proof explaining some computational fact about that data. For example, this was generated without using any of your personal information. And so I think this was kind of like the idea, this idea to me was very compelling, especially

you know, existing as we do in kind of a world where we understand. We interact with computer systems all the time that we kind of have no oversight over or any, they're very opaque to us, I guess would be a way to say it. And the primitive of verifiable computation makes it possible to sort of rebalance the power asymmetry that exists between users and the programs that they interact with and make it possible for users to get some kinds of guarantees about the, until now, relatively opaque programs that they're interacting with. Right. And so, yeah, so, you know, this is actually a use case of like ZK. Snarks that, like, you know, most people think of them as primarily a privacy solution. But you guys are thinking of them more from the scalability aspect. And then what's interesting is then you guys take it a step further and you say, yes, snarks are great for compressing proofs, but there is still inherent limitations on the size of computation.

that can be proven using a single snark. So you guys jump into this whole concept of recursive snarks. So could one of you tell us a little bit about how you make this, made this jump into exploring recursive snarks? Yeah, sure. So I guess, you know, first of all, just so credit or credit is due, there's a very long line of works, maybe going back. I'm not sure really how far it goes back, but I know at least to this paper, Valiant in 2008, and then papers of Batansky

Kieza and then there's this paper BCTV you know Ali Ben Sassouin Alessandra Kieza Iran Chairman Madar Svirza from 2014 working on this idea of

recursive composition for sort of scalable snarks but as far as how it kind of fits into the the cryptic urgency space we mentioned or we just talked about kind of this idea of using snarks to

to sort of prove correct execution of computations to other people. But I think somehow the interesting idea behind cryptocurrency, one part of what makes cryptocurrency or sort of crypto-distributed computing systems interesting, is this idea that programs don't really exist in isolation. They interact with each other, and they have some kind of shared state, and they want to communicate with each other. And that's kind of the functionality that a cryptocurrency system provides you, in addition to some notion, I guess, of money.

And so if you're existing in a world where there's this kind of evolving state that programs are working on and all kind of working together on, naively, the way that existing cryptocurrencies work, the way that you sort of prove to someone that the current state is what it is, is you show them the entire history of that state and the higher history of all the computation that went into that state. But what the recursive composition construction gives you is a way to sort of bottle the whole state up into one little proof. So that each competition can kind of carry the whole state with it as it extends the history.

That kind of makes sense. Yeah, I mean, so I actually was first introduced to recursive snarks. At the IC3 boot camp last summer, I was working on sort of like a little hackathon project with Ahmed Kospa, he's like the creative J-snark. And what we were trying to do was almost like a somewhat limited subset of what you guys are trying to do where we saw that look, the Bitcoin blockchain, the headers take a very long time to verify from Genesis, like just doing that many Shah hashes. Can we create a snark over the entire like header verification only?

And so, you know, that was the first time I ever started playing with like Lib Snarks and stuff. And, you know, we realized that just, like, making this entire verification won't work. And so we would, IMAG started researching into, like, how to do a recursive snark over this. Myself, being my first time playing with the stuff, I got it to, like, manage, like, verify a chain of, like, six in a row. And I'm like, I was happy. Nice. But, yeah. So now all this, like, research and work you guys have done into, like, exploring the use cases of recursive snarks have sort of gone.

into what this project now is called Coda Protocol. So maybe one of you could explain to us what is Coda. One question I have is why the name Coda? So, you know, O1 Lab. I understand the idea is like, you know, constant size, right, 01. What does Cota mean and why the project? Sure. Maybe I can say something about the name and then Evan can talk more about Cota.

So, okay, well, let me say the first thing is, if you're watching this, I really recommend that you check out our talk at ZCon. If you Google Cota Zcon Zero in our name, then you can find it. I just tried. I think it gives a pretty good explanation. Evan will say more. But in terms of the name, well, you know, we've kind of struggled for a long time thinking of a name. But Cota, I think it's kind of a cute name.

It's Italian for tail, I think. I'm not an Italian speaker. And so the idea is that you only sort of have this little tail. of the whole chain. Instead of having to have the whole chain itself, you just have this little tail, which sort of has the current state in it and all that. Yeah, I mean, we wanted something that was, like,

minimalist and sleek and, like, sounded kind of cool, and also, like, you know, there's this idea of music, of course, as you were saying, that, like, the end of, like, a measure, and, you know, in our... So this really gets into what our cryptocurrency is doing. The main thing in Koda is you really only keep around, like, the most recent state of the world

into full proof of that state, but the proof is very small. Like in every other cryptocurrency so far, the way that you prove that the current state of the world is really the current state of the world is by verifying it by downloading everything that's ever happened in the cryptocurrency. So in these other cryptocurrencies, everyone is downloading this huge piece of data and verifying it the same way because they have to make sure it's actually correct. In Coda, you just download this tiny little proof that shows that it's correct. What Cota really does is it's the first cryptocurrency that's actually resource efficient. These other cryptocurrencies, you know, as you add more and more transactions, everyone else has to download all those transactions. I guess concretely, like, you know, much of these cryptocurrencies are, you know, well over 100 gigabytes in size.

And to actually use the cryptocurrency, you have to download that huge piece of data. Whereas in Kota, that's replaced for just like this tiny little snark that stands in for that whole range of transactions. Right. So what Coda does is instead of having, you know, every new participant in the network run this computation of downloading the transactions and verifying themselves, you can sort of use this technique of verifiable computation using SNARCs to provide people with sort of a freeze-dried computation. That's the metaphor that I use at ZCon Zero and maybe some people found it helpful. you can somehow give them this computation a little sort of pre-strived version of this whole computation that someone already performed of verifying the blockchain. And they can just check it really quickly themselves without having to rerun it. So let me see.

Maybe I can put this in a little bit of an analogy so it helps some of the listeners understand. So could you think of it? Let's say we have snarks and we can take any computation and let's say we can, You know, these numbers are a bit made up right now, but like, let's say I can, for analogy purpose, let's say I can verify any snark in one millisecond. But now... It's probably 10, but yeah, sure. Sure, right.

And, you know, there's like a small period of time. But now, let's say I had a thousand snarks I wanted to verify. That small piece of time actually turned into a large piece of time, which is now 10 seconds. And so the idea now is we can now create a single snark over the verification of those a thousand starts and now we turned that 10 second verification back into 10 milliseconds again. Is that like a right way of thinking about it? Yeah, yeah, that's right. I mean, in terms of how the recursive composition construction actually works.

But maybe let me just say kind of like what the kind of high level takeaway is just for so it's very clear for the listener. Coda is a new cryptocurrency protocol which makes it possible for anyone to sync with the network, get full node level security. while only downloading a few kilobytes of data and doing a few milliseconds of computation compared to, you know, gigabytes and gigabytes for sort of traditional cryptocurrencies.

So you had this analogy of freeze-drying computation, right? So I was thinking like Bitcoin also freeze-dry some part of the computation. So in Bitcoin you have this thing, which is the Merkel tree. And so let's say you have a particular block, block 3 million, as long as you just know the header of the block, and you don't know any of the transactions, somebody could prove to you that a particular transaction

was part of that block. So knowing a small amount of data, you could check that some other transactions furnished by some other person is a part of that block. And like Coda in a sense is an even bigger generalization of it, which is that I as a new user join the Coda network. I get something that I can verify in 10 milliseconds. But that initial verification, that snark verification I do, allows me to be sure that any particular claimed block was part of the blockchain. and then any claimed transaction in that block

was also part of the blockchain. Yeah, I mean, well, okay, so it's maybe a bit different from that. So the kind of mechanism that you described, this kind of SPV state commitment kind of thing, in some sense, essentially what that gives you is it lets you sort of delegate trust over what the current state of the world is to minors.

So if you're an end user, you can say, oh, you know, I just want to know that my transaction was in. I just get this header or whatever. And the miner tells me such and such transaction was included. So you don't actually, you don't sort of fully know. That's sort of a sound thing to do if you trust the miners. But you don't actually know that that transaction was valid, you know, that the sender actually had that money or anything like that.

You just know that the miner sort of included that in claim to include that in this block. The reason why that's dangerous is because you're trusting that at no point in time will there be an attack being run on like the chain. Because if there ever is, you're just kind of blindly trusting whoever

the current minor is and that could be a minor that's attacking the network. Well, you're not trusting the specific minor. You're trusting the entire group of miners, right? Because you know, you're saying that other miners are not going to build on that. Unless you're in a situation where the chain is being attacked, which is kind of what I've been talking about.

Speaking of the, maybe this is a little bit of a tangent, but in your ZCon video, I remember you talked about how you, you know, have a one, you do the snark for bringing yourself up to the current state. And then the full node will also transmit you a Merkel proof showing you your account balance. A question I have is why is that Merkel proof, you know, that in the way that you put it in the ZCon video, made it sound like the Merkel proof is like, you know, a magnitude bigger than the Snark proof up now. Why not also create the Merkel proof using a snark as well? I haven't thought through if there's any way to do that, but let me put it like this. Creating Snarks is, it's not so expensive, but it's not the cheapest thing in the world. you'd rather sort of do all of your snarking in a reusable way.

So, you know, in Kota, there's this one snark which sort of certifies the entire state by certifying the Merkel route. And what that means is that when you want to prove things to people about particular parts of the state, you don't actually have to create a new snark. You just have to sort of show that that part of the state is part of that Merkel route. So it's really about avoiding having to sort of make a custom snark every time someone wants to know about their own account, you can just send them a miracle proof.

You know, it is an order of magnitude bigger, but the magnitude involved are still rather small. So you're only downloading a few kilobytes at the end of the day. So essentially the future is that if I want, so today, when I want to do a blockchain node, what do I need to do? I need to connect to the network and I need to download all of the blocks. one by one. And I know the Genesis block from someplace else, right?

And knowing the Genesis block, I download all of the blocks one by one. And then I need to verify all of the accounting. And once I've caught up to the main chain, I am what is a full node. And I have the highest security as a full node, because I have done all of the accounting check, and I know what the final state of the blockchain is. is now in this Coda world what would happen is that if I want to be a full node I could have something much shorter so I connect to one of the nodes in the network I first of all I get this proof the proof gives me a snapshot of the current state like a hash

of the current state of some kind and it also assures me that this is exactly the hash of the current state and it is backed up by this much proof of work or this much proof of state exactly And then I can do this verification in 10 milliseconds, and then I can look up my account balance. I can have somebody else look up my account balance. And when they reply to me, I won't be fooled by their reply. Their reply has to be, will always be genuine from my perspective. So essentially, like, the main advantage of a system like that is when I am a resource-constrained device,

like I'm a mobile phone or I'm a Raspberry Pi. Or frankly even a laptop or desktop computer that doesn't want to store many gigabytes. True. So it's like Coda the system is making like the integrity of the blockchain higher for any of these devices that are either power constraint or are just lazy. that they don't want to download all of that data and verify, verify the, verify the blockchain from start to finish.

Like, your sense of why this is an important problem. Like, as a user, I'm used to just checking my balance on ether scan. And most of the users are just fine trusting ether scan for it, or blockchain. Dot info for it. Why did you focus on this particular aspect?

in developing a cryptocurrency. Mechanisms like just checking ether scan or something like that are maybe historically have been sort of okay for it seems. But I think from

what we're kind of seeing now is we're moving into a new world where all of these sort of attacks that maybe once we thought of as being theoretical or something like that are really not when there's a lot of money on the line. Somehow these systems

can only be as valuable as like the best mechanisms for attacking them. And I'm referring, I guess, or alluding right now to kind of the recent attacks on all these proof of work cryptocurrencies, which sort of people had thought about theoretically and sort of knew where theoretically possible, but it took a little while for someone to actually do it. And that's essentially the same thinking with trying to provide people with sort of a full cryptocurrency level of security for interacting with the blockchain is basically as we move into a world where these kinds of attacks become sort of realistic, we want to be able to have mitigation against

them. Some of the, but a lot of the attacks, the latest attacks, right, in the proof of work blockchains were traditionally, you know, on verge and stuff, were like double spend attacks. Does CODA help solve that problem or is it more, it really only solves a problem of like, you know, invalid blocks, but not double spent blocks, right? Well, well, actually, actually the kinds of attacks that you can run against sort of SPV nodes are even worse than double spends. So you can actually just like, you know, make money out of nothing.

If you're doing some kind of state commitment or some kind of, you know, commitment to transactions or whatever, you can just stick whatever, you can change the state however you like, put whatever transactions you like in there. and SPV type nodes aren't actually checking anything. So you can lie basically in arbitrary ways about what the state is. Maybe I shot also the other advantage, I think, with this style of system is that, you know, if we want cryptocurrencies to be running for end users, they're going to have to be as part of other applications,

as part of websites, you know. And that's not going to happen if your app asks you to download, you know, 200 gigabytes before you can start using it. It's going to happen if that seems like if downloading the cryptocurrency to that app is lightweight and easy and quick to do. So I think that's another advantage of these really lightweight synchronizations. Yeah. I should say also one thing that occurs to me is I think it's sort of a key thing for maintaining decentralization, especially as throughput increases. You want it to be very quick and easy to kind of get new processors, traditionally, you know, what people would call miners or stakers. onboarded to the system.

And because existing cryptocurrency verification is sort of anti-scalable in the sense that it gets harder as it gets used more, the actual onboarding process for

sort of a full node or a minor processor kind of gets worse with time because that node has to redo all of the computation that ever happened. So for example, you know, sinking from Genesis, and Ethereum takes, I think, on the order of a few weeks. That's what someone mentioned to me once.

I actually haven't tried it myself. It's kind of a silly thing to do to sort of say, you know, oh, it's been five years. Well, we did all this computation. You want to start doing computation now. You should start from five years ago, and, you know, we'll see you in five years. We can talk to that.

This episode is brought to you by ShapeShift, the world's leading trustless digital asset exchange, quickly swap between dozens of leading cryptocurrencies, including Bitcoin, Ether, Zcash, Gnosis, Monero, Golem, Auger, and so many more. When you go to Shapeshift.com, you simply select your currency pair, give them your receiving address, sent the coins, and boom. Shapeshift is not your traditional cryptocurrency exchange. You don't need to create an account. You don't need to give them your personal information and they don't hold your coins. So you are never at risk from a hacker, malicious actor.

Shapeshift has competitive rates and has even integrated in some of your favorite wallet apps like Jacks. So you can swap your digital assets directly within your wallet just as easily as putting on your slippers. Whenever you see that good looking fox, you know that's where Shapeshift is. So to get started, visit Shapeshift.io and start trading. And we'd like to thank Shapeshift for their supportive app center. So of course, like what's really interesting about Coda is it uses some of the same technologies that other projects use and it's also attacking the problem of scalability that other projects want to solve but it's both using the technology and attacking the problem in certainly different ways right so for example if

you think of scalability generally when you look at scan across all of the scalability projects in this space you'll find them narrowly focusing on the problem of increasing number of transactions per second that they're doing that the blockchain is able to process. Whereas Coda is focused on how to get devices onboard date quickly into the network and trustlessly onto the network. So one of my questions is, does the problem of increasing throughput through the blockchain in transactions per second become easier once you solve the problem of onboard Are these two problems related in any way? And of course, my second question would be, when I look at Coda,

you are using the technology of zero knowledge proofs in order to increase, in order to attack some of the challenges of scalability, whereas Zcash is using that same technology in order to attack the problems of privacy. It would be interesting to compare and contrast how these two approaches differ. Yeah, I mean, they're super, super related.

Like, I think increasing the throughput of these systems is something that, you know, can be done. You can do things like increasing the block size, using alternative consensus, like Byzantine consensus, or, you know, a bunch of methods. But really, really the question is, what do you do once you've dealt with that? What do you do once the block size is huge and you're adding a bunch of stuff to the blockchain? So I think focusing on that first, and then we can just do things like making. the block size like, you know, 10 times as big, and then you get 10 times the throughput without any of the added costs of making the block size bigger. So, yeah, we're thinking this also helps us solve the scalability issue. I guess I'd say, like, a lot of people for some,

you know, think about scalability. They just think about increasing throughput. And that's, that's really just changing the consensus mechanism somehow to achieve consensus on more data faster. But as Evan was saying, you know, once you increase the throughput, this question arises of like, okay, great, you've increased the, the, you increase the, the, you've the speed at which we can come to consensus about things, but somehow where do you put that data once you're sort of accumulating that data faster and faster, right? It's like, okay, we had this problem that the blockchain kept getting bigger and bigger. Now we have the same problem, but actually it's a thousand times worse

because the consensus is happening a thousand times faster. So I think increasing the throughput to me sounds when you don't have a mechanism in place for making it possible for the typical person who doesn't have, you know, whatever, gigabit internet and terabytes and terabytes of hard drive space to spare. It doesn't seem like the best idea in the world to do that to me. So I think having a kind of solution in place for making it possible for people to actually still have oversight over this now, you know, worrying turbine of transactions. speed is sort of necessary.

So we talked a lot about like, you know, using it to over minimize the requirements on storage for like sinking and stuff. What about for like active nodes, like who are like, who are, you know, caught up with the network and they're, you know, they're keeping up with blocks. And let's say now we have like, you know, I've heard crazy things like, oh, gigabyte blocks and whatnot, right? obviously miners still have to like propagate those with each other but like what about propagating it to other full nodes can we essentially my question is can we also use the same stuff to reduce bandwidth overhead because to me I personally feel that like you know there's three main constraints storage bandwidth and computational power and from my experiences bandwidth tends to be the most restrictive of the three definitely like um

For these nodes that are running consensus and keeping track of the entire ledger, yeah, I think they do have to see the whole block, which limits you to a few thousand transactions per second for like a few megabytes per second internet connection. But I think most nodes don't need to see like every single part of the ledger. Most nodes only need to see like, you know, a few paths from the Merkel route, like relating to what they're doing. So yeah, that does, you know, very minimal bandwidth to like transfer that over. Yeah, and you could imagine also nodes who are sort of in an intermediate position

between these two kinds of users who, for whatever reason, are interested in holding the whole state, but maybe don't need to know how the state changes at every block, but maybe at every hundred blocks. So, you know, every hundred blocks, they can just sort of get the diff to the state along with the new proof, which, you know, if, depending on how big you make that delay, be it 100 or 1,000, you would be able to see sort of network usage improvements over just downloading the entire history. So, is it in your ZCon presentation, you talked about how, like, you know, how you would do this, where you have, like, state zero, state one, state two, and you wanted to create the snark from state zero to state two. And so you talked about having, like, the intermediate state one. And so you have a snark from zero to one, a snark from one to two, and then, like, some proof that one and one is equal.

when I'm transmitting this to you, do I have to transmit to you all the intermediate states or is a diff of state zero and state two good enough, like just the beginning and end states? Yeah, all you have to give me is the dip. So that's what makes this technique very cool. You sort of zero knowledge away, the intermediate state and the intermediate transitions, and you can just sort of send me just the diff and the proof that, that there was a sequence of transitions sort of backing that dip. Cool.

Another thing when it comes to the scalability, another big use case I've read a lot about for snarks is for sharding, right? With sharding, you do need some sort of fraud-proof mechanism, usually. And, like, you know, people, the projects like Pocodot and stuff are working. They're using a very almost like Trubit-like game kind of thing. but like you know if you have a snark proving the validity of a shard

you can just provide that snark to the main chain rather than provide like the entire history and need this like challenge game with fishermen is this something you guys are looking into as well I wouldn't say like looking into actively just finishing the main protocol

is the highest priority but like yeah I mean I think that's totally one of the benefits of having a succinct blockchain enabled by snarks like you're able to have these chains that are instantly verifiable, like, and not just because of some like economic game that's being played, it's because it actually is, like, has a real security proof behind it that, it is valid. So yeah, I think that's one of the main benefits. I wonder what kind of consensus algorithm will the cryptocurrency system end up having?

Yeah, so I mean, so the succinct blockchains are basically independent from the consensus algorithm. You know, we can swap out whatever we want, proof of work, proof of stake, whatever, and that'll be great. The planet launch is to basically have a variant of Oroboros Genesis, which is a proof-of-stake-based system. Any thoughts on, like, can you explain why you chose Oroboros Genesis as opposed to, you know, maybe more BFT-based proof-of-stake protocols? Yeah, I mean, I think the main benefit of using proof-of-stake as a base consensus layer

is because it gives you really good security guarantees, especially the Oroboros Genesis paper we're using. This is by the IOHK team behind Cardano, and they have real security proofs and they have real explanations for why everything they did matters and why they chose it. It just feels very theoretically sound to me in a way that we'll see whether they'll prove-stake protocols.

Another question I have now regarding the technology, the recursive snarks, is what are the limitations here? Well, is this more of a theoretical hurdle if we have to overcome, or is it mostly now just an implementation problem? Yeah, I guess I would say, you know, in terms of the theory, that's something that's very sound and, you know, has been worked out by kind of all these papers that I mentioned. But kind of as always, there's a big gap to overcome between theories.

and practice. There are some kind of interesting theoretical things that we've been working on, in particular, thinking about how to make these proof systems more efficient, both sort of the fundamental cryptographic primitives underlying them and also in how the algorithms for implementing them work. But yeah, I guess I would say a lot of the work is really into kind of of, well, sort of the practical engineering work of sort of snark engineering, which is kind of a whole new thing that has to be invented from whole cloth, and then figuring out how to sort of make cryptocurrency work in sort of a constant size situation, which there are a lot of challenges there as well. So, I mean, I guess I think that's a great segue into your guys' second primary project almost, which is snarky, which is, you know, sort of making that snark engineering.

more feasible and possible. So would you like to explain a little bit of the overview of what the Snarky project is? Yeah, sure. So Snarky is our O-KML DSL for writing sort of verifiable computations or sort of writing, as some people talk about it, snark circuits. So this is like if you have a property that you want to certify with a snark, this is a language for doing so. there are a bunch of other really cool projects for doing this kind of thing. There's Bellman, there's Socrates, there's J-Snark and XJ-Snark, as you mentioned earlier.

But the basic idea is one of the main tools that we have for sort of working with Snarks right now is Lipsnark. Lusnark is an amazing piece of work, but I think as even its creators would admit, is not the best programming tool. So working, sort of writing snarks in Lib snark is very low level. It's, I would say, very error prone. There are a lot of sharp edges and gotchas. And as a result, when you're sort of writing a computation of any substantial complexity, like we have in Koda, you know, verifying a blockchain,

you really want to have a programming language for doing that. It's kind of like if you want to write a complicated program, you want C or okamil instead of assembly language. So snarky is kind of a way of writing your computations at a somewhat higher level so that you can have things like making abstractions and types and making writing the snark a lot easier to reason about it and actually do. So maybe I should say, like, you know, we wrote this language snarky, which is a DSL and O'Cam,

for the purposes of working on Kodak. So the idea here would be that, let's say I have a particular computation, right? So I'm taking a bunch of votes and I'm computing who the winner is. And if I'm the programmer, that's... And essentially as a programmer, I want to write sort of a program that accepts as data all of the different votes and it produces a result but it also produces sort of a proof that there were certain votes that create this particular election result.

So I guess the system is if there are 100 voters and each of them have a vote so they have a statement and I as a programmer want to write a program that takes all of these statements from these 100 voters, and it produces a proof that a particular candidate won the election without revealing the statements of these 100 voters, then I could use Snarky for that purpose. Yeah, right. So like any application that you had in mind

where you wanna use zero knowledge proofs or verifiable computation, I think Snarky is a good language to use for writing your application. So any kind of application that uses Snarks, let's say. For example, doing something like, you know, often the kinds of places where you want to use the journal to proofs are in situations where maybe one party has some secret data and they want to prove to someone else something about that data without revealing that data itself while sort of maintaining their privacy over that data. Right. And so, you know, like I said, I tried playing with lip snarks before. And, you know, when I was, lip snark, it was more like, you know, we were given these pre-designed.

hand done circuit and we kind of just have to like plug them into each other. It felt more like I was building a circuit than writing a program. And, you know, for me, I used to do a lot of like electrical engineering stuff. So, you know, that was a little bit fun. But I definitely saw like, okay, how am I going to build an entire, you know, this is why we built CPU is we wanted general purpose things. And, you know, basically you guys are building a system that makes it a higher level language that can allow you to express more complex logic, basically, right?

Yeah, that's right. It's very analogous to the normal situation in computing, which is like we have some idea in our heads that we want the computer to do, but the computer only understands assembly language, so we don't really, well, some of us understand assembly language, but we'd rather write our thoughts down in some kind of higher-level way that, that's the it then can be translated into words that the computer can understand. It's very similar with snarks. Snarks only sort of understand arithmetic circuits,

but we don't understand, well, some of us do, again, understand arithmetic circuits. So, anyway, you want some kind of higher-level language for specifying that. So one interesting thing, though, that I liked about what your guys' design was for Snarky was, you know, similar to when we're building computers, We have most of our computations happening in the CPU, but sometimes we have like specialized things, like, you know, maybe for cryptographic operations that are just very expensive, and you need to outsource this. And so I notice you guys kind of do something similar with this concept of helpers. So let's say I wanted to do a shot to 56 in, like, in snarky, but you guys offer me a way to, like, outsource this to LibSnark, for example. Oh, yeah.

Am I understanding that right? You might be thinking of Tibolt's Zoccrates talk because he talks about this. It's actually a very similar construction that they use there. But the idea somehow is some, okay, so sometimes there are cases where verifying a computation is a lot easier than performing yourself. So, for example, okay, so in Snarks, let's say you want to divide one number by another number. one way of doing that is well you can use for a mazal little theorem I guess and okay what this is maybe

maybe two in the weeds for for this show or whatever but okay so there is a way of computing you know the in say the multiplicative inverse of a number X using only multiplication if you're in a finite field you can do that you can use for mazlithorem you can do that but what's a lot sort of more efficient is to sort of ask okay what is 1 over x and then check that actually x times this proposed inverse is equal to one.

That's a lot faster than sort of doing the multiplication that you'd have to do. So that's what's kind of cool about Snarks is you have this sort of programming model where you can sort of, as long as you can check something, then you can sort of use that as your computation. You can sort of non-deterministically get the answer and then just check the answer. They're sort of very natural, I think, formalism

for describing non-determinism, which is popular in functional programming and programming language theory world, which is these algebraic effect systems. And so Snarki has like an algebraic effect system where you have sort of these requests for some computation to be performed, and then handlers, which are these sort of programs that sit on top

and sort of very much like exception handlers, answer requests for data for modeling the nondeterminism that you sort of inherently have with the, snark backend, I guess. There also is a facility, though, for wrapping lip snark gadgets.

So, for example, let's say you want to use Shot 2506, you don't have to re-impleat that yourself. You can sort of use the lip-snark gadget for doing that and just sort of wrap it. But anyway. Cool. So I'm curious about where Koda is at currently in its development cycle.

I guess a lot of the core ideas of it are, you know, they're ready to be launched. You know, theoretically, it's all done. And we've built a prototype of it that actually uses a succinct blockchain. So we have a blockchain running that folds in transactions and stays the same size. You know, we're still doing like some of the work to like kind of make it ready for like, you know, everyone to kind of download and use. I guess mainly that's in the proof of stake. You can go into that if you want. Oh yeah.

Oh yeah. I was just going to say, so right. So right, so there's all the kind of work that goes into making a system robust for lots of people using it. And in addition, switching over to use a proofs say consensus mechanism. Whereas the prototype that's implement right now uses for it. And in this test net, right, or you know, not public test not yet, but like what is the general like computational requirements like, you know, for the nodes that want to be part of the. the protocol following nodes, like, you know, to create the SNARCs.

What are the compute requirements there? Snarkifying a transaction on a CPU, let's say with one thread, takes something on the order of 30 seconds to a minute, which sort of sounds sort of terrifying, I guess, but it is kind of not in the light of the fact that you can do multiple in parallel. So if you can use this sort of recursive composition up a tree construction, so that the sort of total time for compressing, you know, end transactions is logarithmic in n.

So for example, if you wanted to do, you know, 1,024 transactions, that would take proportional to 10 sort of steps of recursive composition rather than 1,024. That said, we're also right now exploring more efficient implementations of the Snerk Prover, and we're hopeful that there will be substantial performance improvements over that on certain hardware, anyway. Are you also hoping to get performance improvements? I know the Zcash team is doing a lot of, like, with the new sapling curve, it's supposed

to add a lot of efficiency stuff. Is that something that you guys are planning on inheriting some of that work as well? Yeah, so we can definitely, we definitely can build on some of that work. So for example, they have like this really optimized implementation of doing Peterson Hashing, which we're using in Kota. But some of the work that they've done is sort of Saffling specific, or JubJub specific, or BLS 381 specific. And because, you know, our sort of crypto setup is a bit different, we can't build on all of that.

Another thing was, you know, I think a lot of people got first introduced to the concept of recursive snarks because of a blog post that Arthur Brightman made like about a year ago, I think, last summer on like talking about how they plan on scaling Tezos and he talks a lot about this recursive snarks. And, you know, as you know, Tezos is also like an O'Camel shop. So it seems like you guys are like, you know, very similar in a lot of ways. Are you guys working with them in any way? So we chatted with Arthur and Kathleen a little bit, but we're not working together anyway. It's just, I guess, in my mind, a happy coincidence

that there's two people who are using O'Camel. Thank you, Evan and Izzy for joining us today and walking us through your project Coda. It was a very interesting episode indeed. That brings us to the end of the show. So we had Epicenter release episodes every Tuesday. You can follow us at YouTube.com slash epicenter Bitcoin, Epicenter BTC for our videos. And we also release our episodes on SoundCloud and iTunes.

We always love to hear from our listeners and see reviews. So please write us a review and let us know what we do well and what we don't. And we shall catch you again. next week. Thank you.