#243 Izaak Meckler & Evan Shapiro: Coda – A Succinct Blockchain

12 Jul 2018 · 53:36

O(1) Labs CEO Evan Shapiro and CTO Izaak Meckler join Epicenter to explain Coda, a blockchain built on zkSNARK technology that keeps its chain size constant regardless of transaction history. They discuss why growing blockchain size threatens full-node decentralization on chains like Bitcoin and Ethereum, and how Coda lets new nodes verify the entire chain's validity through a single cryptographic proof.

Speakers

Topics

Transcript

[Music] this episode of epicenter is brought to you by shape-shift yo the easiest fastest and most secure way to swap your digital assets don't run a risk of leaving your funds on centralized exchange visits shapeshifter 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 here oi and i'm sonia agarwal

and today we have with us evan Shapiro and is Ahmed Meckler who are the CEO and CTO of a1 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 a1 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 Qatar fee for from ZK snarks to improve resource efficiency of blockchains um 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 notes back in the day like 2010 2011 in like Bitcoin and random el coins last year though is he and I really started getting into the space and thinking what we could actually do to improve it because we saw a lot of heightened potential for crypto currencies but we like it feel like the technology wasn't really matching up to that so yeah so we started looking into like scaling for crypto currencies and we started thinking about Byzantine consensus and we had a solution that you know got crypto currencies up to a few thousand transactions per second but you know once you've done that you have a whole nother problem on your hands because you just dumped a lot of transactions on to a blockchain and now you have this fuse box and everyone kind of has to share

and handle somehow so that 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 you were doing a PhD in cryptography and how did that lead you into getting involved the blockchain space yeah sure so um I'm Isaac you know some of my friends call me Izzy I guess Evan does right so so I had I 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 Piazza who was one of kind of the pine really a pioneer of making snarks practical and Evan and I haven't mentioned had been have been discussing cryptocurrency scalability and the idea of using snarks to to basically compress the blockchain seemed like a really clear and powerful application and so we started thinking about this and ultimately kind of the the project was getting so exciting that I decided to take a leave of absence from my PhD to work on it full-time so Alessandra chiesa of courses is one of the authors of I guess like the

stocks for sea paper and the and and easy cash paper boat right so it's like it's like many many of these our viewers would have heard of le bins are sown who is a professor at the hebrew university of jerusalem but then LS and rukia's has always been one of his co-authors in all of these groundbreaking start papers so easy you've also worked at a Jane Street as an as an intern and Jane Street is known for the usage of Oh camel and functional programming in its it is quantitative trading systems and I see that you're also using functional programming quite a lot in in in you know in over labs so like could you give

us a sense of sort of your background with functional programming and what you see as its advantages that led you to use this paradigm in in your work yeah sure so I work as you mentioned I changed it as an undergrad as an intern and also after graduating full time and you know I worked at daintree because I was interested in functional programming I had always been kind of functional programming person I guess as an undergrad I first got into it and I would say I would say you know AB well before working at Raintree time mostly program in Haskell and I guess Elm I did some work on the Elm compiler once working at once I worked at

gingered I was sort of fully converted to the okay well the okay my way of doing things and I think our reasons for working with though camel are very similar to James traits so there's this idea that well software should be correct especially when a lot of when a lot when a lot is on the line be that money or people's time or safety or anything like that and I think one of the best tools that we have for writing correct software are ethically 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 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 a camel or maybe rust those all have sort of different trade-offs you know rust is a bit low level and is a good choice for cases where where things are really performance sensitive but otherwise you know Haskell and no camel are a bit higher level a bit easier to sort of work with quickly and as for why oh camel you know what Haskell I think people who are familiar with no camel what you know these arguments will sound very boring to them because they've probably heard them a thousand times and I think they're well internalized by every Oh camel programmer but okay well has an amazing module system which is

like a great tool for making making structuring organizing code and making working with a large code base and with a lot of people a lot easier Oh camel is also strict which makes performance easier to reason about those I think the main things that sort of make it in some ways a more practical choice than Haskell for large projects at least in my opinion I see awesome well and yeah so you know you guys didn't mention it a little bit on your introductions about like you guys saw like some of the scalability problems in the blocks in space and wanted to help solve them can you tell us a little bit more though about the

genesis story of oh one labs like you know how did the two of you meet and like what's the vision here what are some of the problems are working on like your main product so if I know about coda and snarky is there anything else you guys are working on oh yeah definitely I just feel like the origin of the company is so is he and I knew each other from high school we both grew up in same town I went to the same high school together you know I was living out in San Francisco after college and is he 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 visiting consensus which led into resource efficiency issues which led them to ZK snarks

I guess it's kind of how it all got started and then we decided to really you know dive into the idea I make the company out of it and really build it yeah so so this is this really cool idea of like it's sort of hard to communicate this this is this sort of vision but the idea is that you have a bunch of a bunch of programs which are all all proving things about their behavior to each other and 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 they're 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/thebalancingactfans all the time that we we kind of have no

oversight over or any-any they're very opaque to us I guess would be a way to say it and and the primitive of verifiable computation makes it possible for to sort of rebalance the power asymmetry that exists between users and the programs that they interact with and make it possible for your users to get some kinds of guarantees about them 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 zzk snark set 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 Snorks are great for compressing proofs but there is still inherit limitations on the size of computation that can be proven using a single snarf so you guys jump in to let this whole concept of recursive snarks so could one of you like 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 where 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 Bataan Ski chiesa and then there's this

paper BC TV you know that a leave-in Sassoon Alessandra ki is a around tremors are severe 2014 working on this idea of rehearsal composition for sort of scaleable sparks but as far as how it kind of fits into the to the cryptocurrency space there we mentioned that 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 of behind cryptocurrency or 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 with 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 in the entire 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 and into

into one little proof so that that each computation 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 there at the IC 3 boot camp last summer I was I was working on sort of like a little hackathon project with I'm ed Costa he's like the creator of J snart 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 recreate a snark over

the entire like header verification only and so you know I that was the first time we 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 imagine sort of 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 hot nice but yeah so now all this like research and work you guys have done into like exploring the use cases of the cursive 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 oh one laughs I understand the idea is like you know constant sighs right oh one what does coda mean and why this project sure maybe I can say something about the name and then Evan can talk more about Dakota so okay well let me say the first the first thing is if you're watching this I really recommend that you check out our talk at Z Khan if you google Z kotas econ 0 in our name then you can find it I just try it I think it gives a pretty good explanation Evan will we'll 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 coda I think it was it's kind of a cute name and 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 and all that yeah I mean we want something that was like minimalist and sleek and like sounded kind of cool and also like hey you know there's this idea music of course as you was saying that like the end of like a measure and you know and art so this really gets into what our Couture currency is doing um the main thing in coda is you really only keep around like the most recent

state of the world and a full proof of that state but the proof is very small um like an 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 at in the cryptocurrency so in these other crypto currencies 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 Koda really does is it's the first cryptocurrency that's actually resource efficient these other crypto currencies are you know as you add more and more transactions everyone else has to download all those transactions the I guess concretely like

you know much these crypto currencies are you know well over a hundred gigabytes in size and to actually use the crypto currency you have to download that huge piece of data whereas in Koda that's replaced for just like this tiny little snark that stands in for that whole range of transactions right so what Koda does is is instead of having you know every every new participant in the network run this computation of downloading the transactions in bear planet themselves you can sort of use this technique of verifiable computation using snarks to provide people with sort of a freeze-dried computation that's the metaphor that I use a Zeke on zero and

maybe some people found it helpful you can somehow give them this computation a little sort of freeze-dried version of this whole computation that someone already performed of verifying the blockchain and and they can just check it really quickly themselves without having to rerun it so let me see maybe I can put this in with 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 but made up right now but like let's say I can for for analogy purpose let say can verify any snort in one millisecond but not only 10 but yeah sure sure right and you

know this is 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 let maybe let me just say kind of like what the kind of high-level take away is just so it's very clear for the listener Kota 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 analyst geo free strain computation right so I was thinking like Bitcoin also frees tries some part of the computation so in in Bitcoin you have this thing which is a the Merkel tree and so you have let's say you're a particular block block three 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 right 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 joined the coder Network I get something that I can verify in ten milliseconds but that the initial verification that's not 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 may be a bit different from from from that so the 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 miners 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 got 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 thing to do if you trust the miners but you don't actually know that that transaction was valid you know that that that the sender actually had that money or anything like that you just not 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 miner is and that could be a miner that's attacking the network well your truck you're not trusting the specific miner you're

trusting the entire group of miners right because you know you're you're saying that not the my other miners are not gonna build on that unless you're in a situation where the chain is being attacked which I which is kind of what happens often speaking of the maybe this is a little bit of a tangent but uh in your Zeke on video I remember you talked about how you you know have a one you do they snark for bringing yourself up to the current state and then the full node will also transmit you a merkel proof give showing you your account balance a question I have is why is that Merkel proof uh you know that in the way that you put in those econ video made it sound like the Merkel proof is like you

know a magnitude bigger than the stark proof up now why not also create those 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 your snarking in a reusable way so you know in coda there's this one snark which sort of which sort of certifies the entire state by certifying the the merkel group 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 group 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 it's it's a it's the managers are involved are so rather small so the you're only downloading a few kilobytes at the end of the day so essentially the future is that if if I'm or Saturday 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 I know the Genesis block from someplace else right right

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 have caught up to the to the main chain I am what is a full 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 the final state of the blockchain is now in this coder 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 I can do this verification in ten milliseconds and then I can I can look up my account balance I can have somebody else look up my account balance and if when they reply to me I won't be fooled by their reply right their reply has to be will always be genuine from from from my 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 am a Raspberry Pi it makes or frankly even you know a laptop or desktop computer that doesn't

want to store many gigabytes true so so it's it's like coda this system is it's 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 all of that data and verify verify they verify the blockchain from start to finish like kiss 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 either scan or something like that or maybe historically you have been sort of sort of okay for it seems but I think from what we're kind of seeing now is we're moving we're moving into a new world we're 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 you know I'm referring I guess are alluding

right now to kind of the recent attacks on all these groups proof-of-work cryptocurrencies which which four people had thought about theoretically and sort of knew were theoretically possible but it took it took a little while for for someone to actually do it and that's the same essentially the same thinking with trying to provide people with sort of a full cryptocurrency level of security for interaction with the collection 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 of the latest attacks right in prefer web block chains were traditionally uh you know on verge and stuff were like double spend attacks

Dakotah 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 if you're doing some kind of state commitment or some kind of you know trick commitment to transactions or whatever you can just stick whatever you can change the state however you like change put what per transactions you like in there and SPV type nodes aren't actually checking anything so you can lie basically in arbitrary ways about about what the status I may be I should also the other advantage I think with this style of

system is that you know if we want crypto currencies 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 gonna happen if that seems like if downloading the cryptocurrency to that app is lightweight and easy and quick to do um 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 I think it's sort of a key thing for 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 call miners or stickers on boarded to the system and because 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 first sort of a full node or a minor qira'at processor kind of gets worse with with time because that node has to redo all the computations that ever happened so for example you know thinking of sort of syncing from Genesis and the theorem takes I think on the order of a few weeks I 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 them so this episode is brought to you by shape-shift the world's leading trustless digital assets change quickly swap between dozens of leading cryptocurrencies including Bitcoin ethers e cash gnosis manera golem or cur and so many more when you go to shape-shift dot IO you simply select your currency give me receiving address sent the coins and boom shape-shift is not your traditional cryptocurrency changed 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 other malicious actor shape-shift has competitive rates and is even integrated in some of your favorite wallet apps like Jax 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 shape-shift is so to get started visit shape-shift I Oh and start trading and we'd like to thank shape-shift for their support of epicenter 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 subtly different ways right so for example if you think of scalability generally when you look at scan across all of these scalability projects in this space you will find them narrowly focusing on the problem of increasing number of transactions per second that that they're doing that the blockchain is able to process whereas coda is focused on how to get devices on board it quickly into the network and trustless ly onto onto the network right so one of the one of my questions is does the problem of increasing

throughput through the blockchain in in transactions per second become easier once you solve the problem of onboarding are these two problems related in any way and of course my second question would be even right when I look at coda you are using the technology of zero knowledge proves in order in order to increase in order to attack some of the challenges of scalability whereas Z cache is using that same technology in order to attack the problems of of privacy it would be interesting to compare and contrast how these two approaches differ yeah I mean they're they're super super related like um I 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 um but really really the question is what do you do once you dealt with that what do you do once the block size is huge and you're adding a bunch of stuff to the blockchain um 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 such 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 everyone was saying you know once you increase the throughput the this question arises if like okay great you've increased the the 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 that data faster and faster right it's like okay we had this problem that that the blockchain kept getting bigger and bigger now we have the same problem but actually it's it's a thousand times worse because the but 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 turbines 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 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 transaction 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 syncing and stuff uh what about for like active nodes like who are like 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 well you know obviously miners still have to like propagate those two with each other but like what about two propagating it to other full nodes could can we essentially my question is can we also use the same stuff to reduce bandwidth overhead cuz 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 on III for these like 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 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 get the diff to the state along

with the new proof which you know if depending on how how big you make that delay be at a hundred or thousand you would be able to see sort of perform network usage improvements over just downloading the entire history so is they in your Zeke on presentation you talked about how like you know how you would do this where you have like state 0 state 1 state 2 and you wanted to create the snort from state 0 to state 2 and so you talked about having like the intermediate state 1 and so you have a start from 0 to 100 stems one two 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 dip of state 0 and state 2 good enough but just the beginning and end States yeah all you have to give me is the deck so that's what makes this technique very cool you're sort of you know zero knowledge away the intermediate state and and the intermediate transitions and and you can just sort of send me just the dip and and and 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 polka dot and stuff are working they're using a very almost like true bit like game kind of thing but like you know shows if you have a snark proving the validity of a shard uh 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 oh I wouldn't say like looking into like 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 us a sync 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 it's one of the main benefits I wonder what kind of consensus algorithm with the cryptocurrency system end up having ah yeah so I mean so the succinct box chains are basically independent from the consensus algorithm you know we can swap out whatever we want with the work through the stake whatever and that'll be great the planet launches to basically have a variant of Ouroboros Genesis which is a proof of stake based system and he thought son like can you explain why you chose or both Genesis as opposed to you know maybe more BFT based uh

proof of snake protocol uh yeah I mean I think I think the main benefit of using prio snake as the base consensus layer is because it gives you really good security guarantees especially the or Boris Genesis people were using this is by the Iowa a team behind Cardno and you know it's they have like you know real security proofs and the real explanations for like you know why everything they did matters and why they chose it it just feels very theoretically sound to me in a way that um all will see the way the gripstic protocols another question I have now regarding the you know the technology that the the recursive snarks is what are the limitations here well you know

is this more of a theoretical hurdle if we have to overcome or is it mostly now just an implementation problem um yeah I guess I would say you know in terms of the theory that that's something that's 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 there's a big gap to overcome between theory and practice there are some kind of interesting theoretical things that we've been working on in particular thinking about how to how to make these proof systems more efficient both both sort of the fundamental cryptographic primitives underlying them and also and also in the

in how they implement the algorithms for implementing them work but yeah I I guess I would say a lot of the work has it is is really into kind of well sort of the the practical engineering work of sort of snork engineering which is kind of a whole new thing that has to be invented from whole cloth and then 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 so I mean I guess I think that's a great segue into your guys's 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 that the overview of what's the snarky project is yeah sure so snarky is our okay ml DSL for writing writing sort of verifiable computations or sort of writing as some people talk about it snork circuits so this is like if you have a property that you want to certify with the 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 Jason mark and XJ snork as you mentioned earlier but the the basic idea is the the main one of the

main tools that we have for sort of reporting with snarks right now is lip sir Lu snark is an amazing piece of work but I think as even its creators would admit is is not it it's sort of not the best programming tool so working sort of writing Snorks and lip snark is is very low level it's it's I would say very error-prone there are a lot of sharp edges and Gaucho's and as a result you're sort of writing a computation of any substantial complexity like we have in coda you know verifying a blockchain you really want to have a programming language for for doing that it's kind of

like if you want to write a complicated program you want C or o camel instead of assembly language so snarky is kind of a way of writing your computation so this at a someone higher level so that you can have things like making abstractions and types and making writing the snark a lot easier to reason about and actually do so maybe I should say like good you know we we were we wrote this this language snarky which is a DSL and oh camel for the purposes of working on coda so the idea here would be that let's say I I have a particular computation right like so I am 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 right so like I think 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 these statements of these hundred voters then I could use snarky for that purpose yeah right so like any application that you had in mind where you want to use zero knowledge proof or verifiable computation I think snarky is is a a good language to use for for writing your application so any kind of application that uses snarks let's say for example for example doing something like you know often the kinds of places where you want to use your own talent approve start 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 well sort of maintaining their their

privacy over that data right and so you know like I said I I tried playing with lips narcs before and you know when I was lip snark it was more like you know we were given these pre-designed hand-done circuits and we kind of 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 gonna build an entire you know this is why we built CPUs we wanted general-purpose things and you know basically you're 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 it's very analogous this is a normal situation in computing which is like we haven't we have some idea in our heads that we want the computer to do but the computer only sends it 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 kind of a some kind of higher-level way that 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 everything well some of us do again understand arithmetic

circuits so anyway you you want some kind of higher-level language for specifying that so one interesting thing though that I liked about what your guys's design was for snarky was um 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 noticed you guys kind of do something similar with this concept of helpers so let's say I wanted do a shot 256 in like in snarky but you you guys offer me a way to like

outsource this to lib snark for example oh yeah I understand that might be that you might be thinking of t-bolts Socrates talked because he talks about this it's actually very similar a construction that they use there but the idea somehow is um some okay so sometimes there are cases where verifying a computation it's a lot easier than than performing yourself so for example okay so it's narcs let's say you want to you know divide one number by another number one way of doing that is well you can use for Maas little theorem I guess and okay what this is maybe maybe two in the weeds for this show or whatever but okay so there is a

way of computing you know then 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 mozilla theorem 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 1 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 that 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 you can sort of use that as your computation you can sort of non-deterministically you 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 in programming language theory world which is these algebraic effect systems and so snarky has like an algebraic effect system where you have sort of these requests for some computation be performed and then handlers which are these sort of programs that sit on top and sort of love merit very much like exception handlers answer requests for data for modeling the non determinism that you sort of inherently have with this with the snark backend I guess there also is a facility though for wrapping lib start gadgets so for example you know let's say you want to

use shot to v6 and you don't have to implement that yourself you can sort of use the lip snort gadget for doing that and just for a rabbit but anyway cool so I'm curious about ver coda is that currently in its development cycle III I guess some a lot of the core ideas of it are you know we're you know they're ready to be launched with you know theoretically it's all done and we've built a prototype of it that actually uses a sync blockchain so we have a blockchain running that folds in transactions and it stays the same size you know we're still doing like some of the work to like kind of make it ready for like um you know everyone to kind of download

and use I guess mainly that's in the proof of stake yeah so you can go into that if you want oh yeah oh yeah oh yeah I was just gonna 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 an in addition switching over to use approved sake consents consensus mechanism where's the prototype this implemented right now uses proof report and in this test net right or you know not sound public test not yet but like what is the general a computational requirements like you know for the nodes that want to be part of the protocol following nodes like you know to create the snarks what are the copied requirements there

so I can find your transaction um on a CPU let's say with one thread take 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 in light of the fact that you can you can do multiple in parallel so if if you you can use this sort of recursive composition up a tree construction so that the sort of total time for compressing you know and transactions is log over they make an end so for example if we wanted to do you know a thousand 24 transactions that would take proportional to ten sort of steps of recursive composition rather than 1024

um that said we're also right now exploring more efficient implementations of the server and we're hopeful that there will be substantial performance improvements over that on certain certain hardware anyway mm-hmm are you also hoping to get like performance improvements like I know the Z cache team is doing a lot of like with their new sapling curve it's supposed to add a lot of efficiency stuff is that something that you guys are playing on like 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 coda but some of the work that they've done is sort of sapling specific job job specific or BLS 3:81 specific and because you know our sort of crypto set up is a bit different we can't build on all that another quick 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 tezo's and he talks a lot about this recursive snarks and you know as you know tezo's is also like an oh camel shop so it seems like you guys are like you know

very similar in a lot of ways is it are you guys working with anyway or so we chatted with with Arthur and Kathleen a little bit but we're not working together anyway it's just I guess uh in my mind a happy coincidence that there's two people who are using oh camel Thank You Evan and easy for 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 this show so we had epicenter in these episodes every every Tuesday you can follow us at youtube.com slash epicenter Bitcoin epicenter PTC

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 [Music] [Music]