ZKPodcast: Light clients & ZKPs with Celo

Transcript

[Music] welcome to zero knowledge a podcast where we explore the latest in blockchain technology and the decentralized web the show is hosted by me Anna and me Fredrik [Music] in this episode we'll sit down with Marik and Coby from CeeLo to talk about their blockchain and how you can use zero knowledge proves to construct ultralight clients before we start we want to say thank you to this week's

sponsor Aragon won Aragon one is working to make decentralized autonomous organizations or dows easy and accessible to create and manage if you love working with talented designers building smart user interfaces or if you're simply excited about dows then you should check out Aragon ones available jobs the company is currently hiring a front-end engineer to help build the platform for modern organizations for more about the front-end engineering role or other available jobs in general check out aragon dot 1 slash jobs that's ARA gon dot o ne slash jobs so thank you again Aragon one and now here's our interview with Marik and Kobi from Sela so today we're sitting down with American Kobe

from sello and we're gonna be talking about light clients how zero knowledge could potentially be used to make light clients lighter and why this would be desirable welcome to the show guys thanks it's great to be here thanks so maybe to kick off what is sell oh so sell o is a permissionless platform that makes financial tools accessible to anyone with a mobile phone and I think what makes us maybe a little unique is our product focused approach and so we're very focused on end user usability and we're very focused on Financial Inclusion and so that means that we go out we've done a lot of user research

we've done over 150 user research studies in the field and around 10 countries or so and we've used that to guide our work oftentimes synthesizing that research and taking it back to the team and then using that to guide the development of the protocol and I think what's interesting with this approach is that we learned really early on that we had to develop in a full-stack manner we knew that people to reach market area customers we needed to build for mobile and to deliver a great mobile experience we had to build in a manner where we were building both the platform and a mobile app on top of that where does the light client come in to this exactly yeah and so to deliver a great mobile

experience in a fully permissionless censorship resistant manner it's important to have a very good like line protocol and so I think there's been a lot of work that you know the Bitcoin community that etherium has done to really bring us to a point where like clients are I think feasible but they still require too much data to be actually practical in data they use and so one of the innovations that that sello has done is to create a like client protocol that requires only just a trickle of data while remaining fully sent resistant I really want to dig in more into sort of how you've built a lot of these things because I think that's

an interesting and somewhat unique story and ties into the like client stuff as well but maybe before we go in there what about you guys where are you coming from and how did you get to this space I'm I guess I'm an entrepreneur I have a background in computer science did my undergrad at the University of Toronto and then later went to MIT for my PhD and at MIT I'm a trainee who's one of the cofounders of sello and back then in a class taught by Tim berners-lee we we created our first company called locu which was in the semantic web link data space so some of you might recognize that that

was actually original web 3 Tim berners-lee was looking to do today that what he did to documents namely make them interconnected and accessible to everyone and and so we ended up actually starting a company around link data as is I think common with startups we kind of pivoted towards becoming a machine learning company that was helping small businesses better compete against and of the Amazons and the McDonald's of the world through data and and that company did well it got acquired a couple years later and it was actually I think the weekend after we got acquired that I was at outside lands and Brian Armstrong actually showed me the the coinbase app

on his phone and actually sent me my first Bitcoin so that was pretty excited yeah that's how you got into it what about you Kobe yes so I got into Bitcoin I think around 2013 I was doing my masters at the time applied math and I just had to give a seminar about any subject that has meth in it so I heard about Bitcoin awhile before and it fascinated me so I just gave a seminar about that and since then I couldn't leave it so that's I think how urgent I got into it I got involved in material later on thinking early to that 2015 and a bit before Olympic I think yeah later

on we think in 2016 I heard about your knowledge about what Z cash was doing and they started experimenting with it working with it and also tried out like Rufus of replication that has been designed by that point and that's how I got into letting a team of Ziggy snark developers for a few years and he headed and yeah after that I met Marek we actually met at ZK at the seek a proof workshop yeah just a good place yeah we might take a pool what so what role do you guys take in their company and sell oh yes I'm the

CTO and one of the co-founders of C labs which is one of the connect companies working on seven I'm in Philips letting that photography afore that nice copy would you say are you like on the research side are you also doing some engineering actually I'm doing a lot of engineering a some research cool so you're talking about Salo and sort of being mobile first being focused on usability you know it's kind of obvious that yeah obviously usability is good but why did you decide that these things should be your goals like how did you come to that point where you know mobile first is a requirement for us yeah I think it comes down to our mission so Stella's mission is to create a

monetary system that creates the conditions for prosperity for all and everything that we do is kind of in service of that mission and just in service of advancing financial inclusion and so for us even though we're very very excited by connect crypto and blockchain technology it's really a means to an end and not an end in and of itself and so when you take this in a viewpoint you could have naturally ended up really focusing on the end users and I think that ties in to what I was talking about with how you've built things so this is not something that we've talked about yet but you actually forked the gift codebase and started modifying that so you didn't start

building everything from scratch why did you make that choice so I think we initially started by trying to build on aetherium to create a great mobile experience that I could kind of meet the needs of our target users and throughout that effort we we struggled to get through an experience this was around two years ago I think before people were doing a lot with meta transactions and generally I think also maybe when crypto kitties was really driving the price of gas up and so it was really hard for us to build that experience that we wanted to and so we knew that we needed to build our own later one platform at that point and we

had a choice to start from scratch or to invest more effort on usability on the mobile wallet on the like line protocol and I'm not built from scratch and you know I think at the time the decision to start with aetherium was was obvious two years ago it was definitely the best starting point for us why do you choose to for death and not parody yeah that was a really hard one actually we we were looking at both very closely and I think the big reason was just at the time parody was not compiling to the mobile platform yet and didn't have a

version that we could link into a mobile application I think that's changed obviously since then but as we made changes to our consensus protocol as we made changes to the like client protocol it meant that bringing parody up to the place that we were with guests just took more currently just takes more effort than we have time for but it is a hope of mine that we can actually do that I think having two clients running on a network I think it's just there's a lot of goodness that comes from that and so I think it's definitely near to our hearts and does that mean that is your is the majority of your stack built didn't go some event so actually a lot of our protocol we ended up building in

what we're calling system smart contracts so sella was a proof of stake protocol it has a lightweight identity system that makes it easy for users to find each other by phone number it has a stability protocol that allows you to send stable value easily to people and it has full-on chain governance for all of these systems more contracts and all of these are written in upgradeable smart contracts that in effect can be upgraded through governance and only through governance but are these like is it then is it also kind of using a solidity like language to write the smart contracts on a guest like client exactly hey so much of the protocol is written in

solidity and and then we do have changes obviously at the gas layer as well we have for the proof of stake protocol we run a protocol that's somewhat similar to cosmos where we threw people staking the native coin on the platform which is seller gold for us I can elect a hundred or possibly more at the time a network launch validators and then perform pbft consensus and this is really nice because it allows for very short block periods it allows for one block finality and it allows for this really interesting and you like client protocol that we've created so the changes you've made on if you just

talk about the client itself if there's obviously a new consensus algorithm that you were talking about but then you've done a bunch of other things in solidity so that doesn't require you know layer one changes it is there anything else notable aside from the light clients which will I think we should talk more about that you've made like changes you've made on layer one one thing that's actually not in the layer one but I think we're really excited about it solo is the addition of a lightweight identity protocol that map's hashes of phone numbers to public keys and so this is a in effect a decentralized PKI that allows people to find each other

more easily and communicate securely and transact securely just by knowing each other's phone numbers and so I think for the mobile first use case the usefulness of this might be pretty obvious when you're sending a transaction using celos mobile wallet you can send that transaction simply by looking at people in your contact list looking up them by phone number and I think perhaps even more interestingly and this allows users to send transactions to people before they even sign up and so if you have a friend who isn't yet on cell oh and you have ten maybe cell oh dollars with cell Oh shillings that you want to send their

way because we have this decentralized phone verification protocol you can send that payment to an escrow account which is locked such that the user can only withdraw from that account after they've verified their phone number and so this allows for a flow that looks very similar to what you've seen on centralized services like event MO or PayPal but it's fully decentralized and trustless we've made a number of changes that are again maybe not surprisingly really focused on usability and so early on in our research we learned that the the complexities of owning multiple assets to to pay for gas was a big

hurdle for for our target audience and so I guess what you mean by that is like using one token or transferring one token but having to pay gas in another exactly okay especially if that gas currency is a volatile currency and the price of gas changes you know frequently over time you know this presented a pretty big hurdle for usability and this is a pain in the ass for most people I mean if anyone has gotten out a bounty from like a gate coin bounty or something that's paid and died and then you have dies in an account that you can't move anywhere because you don't own eat yeah exactly and so one of the changes we made fairly early on is to support paying for gas in

multiple currencies including in ER c20 like tokens and so this means that if you want to send one of our stable coins like sello dollars you can pay for that transaction fee in several dollars and so when it's displayed to you as something for you to confirm it's in the same currency you can kind of calculate the percentage in your head if it makes sense for you and it's just much much more intuitive but this is still what you're talking about here are like ERC 20 like tokens living on the seller network exactly there's no there's no real connection between like the existing aetherium main chain and sell oh right now is there there is not but we are working hard to add a bridge and

so one way to think about cell OH is potentially as an extension to the etherium ecosystem mostly because we plan to have eath in the reserve that backs the stable coins okay Oh interesting so it'd be like a cross chain stable coin that's right and early on some of that youth might be off chain managed but the planet is longer term to have it be fully automatic with cross chain rebalancing so this already sounds like quite a it's a very ambitious project already you have your own protocol your own sort of tokens and you RC 20 like

tokens sitting on that protocol a stable coin a POS system and then these dislike claim construction and maybe if something else - I don't know governance helpful note incentives which is another thing that we modified get fours so undersell offal nodes can be incentivized to serve traffic to light clients I think this is a common problem on on aetherium and other networks where it's there's no incentive for you to sort of like clients by default if you fire up a full node you won't be serving them you have to explicitly turn that on and and as a result it's sometimes hard

as a lie client to connect to a network and so with Zelo we take this coffeehouse model we're serving the information that you need to to fetch your balance and to access the protocol is free but when you want to transact then you have to pay so similar to being able to kind of sit at a table maybe work with your laptop but if you want a coffee you have to pay for it and and we do that by modifying the transaction object to include a an account that part of the transaction fees need to be shared with and a full node can choose not to forward those transactions if

they don't have their own account listed in that transaction that's interesting so and this is something I've asked people to build for like two years is an incentive model for my clients but is does this mean that if someone wanted to they could modify the like line to basically just remove that extra fee they can but then pull notes were likely enough or were their transactions and so they wouldn't really be able to get around it so when I'm sending a transaction I'm doing it to a full node and then they for the transaction only if a fee to them is included in that transaction exactly how do you prevent just gossiping the transaction generally on the network I

mean it I guess it's sort of the same same same answer that no one would like the gossip would stop at the first stop regardless of where you send it because it's not in their interest to forward it yeah I think if a liked line pretended to be a full node right now it's communicating using a different protocol and so I think it's easy to for a full node to know that it's talking to the Lifeline but it could possibly try to fake being a full node we're still exploring ways to mitigate that and then in the worst case maybe someone would be a full node would be duped and I'll get paid but that's a pretty I think the worst case is just a status quo today

and so that's not the end of the world yeah let's let's go like let's really talk about this light client because I feel like there's some interesting features about it so I think we've spoken about light clients in the past on the show but I think given that we're going to be talking quite a bit about life light clients it might be good to define kind of what light clients are what they tend to be used for how we've seen them in the past like clients are clients that are typically more resource constrained typically both in terms of storage and bandwidth so much so that they can't participate in a decentralized protocol acting as full

nodes where they have the entire state of the chain and every transaction gossip to them so that they can verify every state transition the chain and so to make it possible for these lighter weight clients to participate a lot of research has been done around using Merkel tree commitments that allow full nodes to maintain the state of the blockchain in a sort of Merkel tree and as long as these like clients have an efficient way to download and to get the latest Merkel tree commitment they can query other nodes on the network for data and use

that Merkel tree commitment to validate any data that they receive from these phone nodes in the case of a light client is it like I've always understood like clients is kind of kind of proving that a block has happened but also sort of showing the state if that's at that moment is that is that the case or delight' clients not show the state of a blockchain so the light clamp knows what is let's say the latest Heather did the blockchain had if we're talking up for example about a serum like and they know all the headers that exist in the Kitty room chain and they verified at least those so the headers themselves contain for example roots of the state and that

allows that clients to request to do some queries about this state when they can ask for nodes or other nodes in the network not actually hold this state so light clients don't have to hold all the state but so they have to have enough cryptographic roots in order to be able to query for elements in the state such that they will still be certain that this is exactly what exists in the network and that they are not being full how would you describe this light client like what what are the features of this light client that you think could be highlighted so I think the main thing that like Marik said we are very focused on light client so this light client

sync we call it ultra light client saying it's focused on life clients being able to sync really fast to the network and to do that and serve like clients anywhere you want to reduce the data that clients have to get as much as possible so one of the main features of this ultralight client protocol is that you have to download a really small amount of data to get synced to the latest state in the network and to be able to efficiently making light client queries to for not and be certain that you're actually getting what you should be getting and how do you do that there are a few steps to this let's start from

the end actually all you have to do is download a few Zeke is not groups and you will know what is the current state of the blockchain and what do you care is a live client what do you care what is the state you care about as a life plan and that would be what is the current validator set in the network so in Istanbul or in PV 50 in general you have a set of elevators that are developers that are approved to sign blocks and initially in the Genesis block you have a set of validators that's been chosen and in several each day at least now it's each day and the

validator set changes there are votes of what next validator said should be that's in the governance system and today this validator set changes so a light client would at most need to download this last block in each day which we call an epoch and after they do that they would be able to know what is the current validator set for that block so we started a zero we have a letter set to the Genesis block and then after they won we need to download just the last block in this epoch and we know the values are said then in this by the way

gives you a 17,000 times reduction in how many headers you have to download so this alone is already pretty substantial oh yeah blocks are really fast so currently they're around five seconds for each block so you would have to download a lot of blocks to sync then yeah so this is this would be a naive light client naive like client would download the last block in each epoch and they would have to sing but this is still a lot of data to download especially after a year passes you have to download quite a bit of data so we aim to reduce that even further so the way we we approach that he is first of

all and we started out with signatures with these ECDSA signatures on blocks and that means that whenever a block is authored a majority of the validators have to sign this block in order for it to be accepted by the network so a majority in the case of a hundred evaluators would be more than 66 and that means that each block contains 66 ECDSA signatures so that's something that was really fast and we wanted to reduce that so the first thing we did is replace those signatures with BLS

signatures and the nice thing about the other signatures is that there are forgettable not interactively so that means that instead of 66 or 67 signatures we can have one huh grenaded small signature for each block and especially for each last block in an epoch is that like a did you like put it on Merkle tree like how did you make it from 66 to one yeah so that's something that's really nice and native in BLS signatures themselves there is a nice protocol that you can do you basically add up all the signatures and you are able to verify as long as you also add up the public keys that would verify

these individual signatures and if you run this let's say the sum of the signatures in the normal BLS verification equation it would still pass and you would know that this set of public is signed this aggregated single signature I think like anyone who's familiar with the youth to protocol knows they're also trying to use BLS signatures for the signature or aggregation of validators but you're using a different curve if I understand correctly you're using the 12 377 curve which is newer why did you pick that one that's because we still were unsatisfied with the amount of data you have to

download so we further went ahead and design this snark based protocol where instead of having to download the last block in each epoch you just have to download the snort proof and it shows the following let's say we're at block 0 and we have the Genesis validator set and we collect on the side let's say 100 100 epic blocks and what we do we they then take them as provers we can then take this hundred epoch blocks the validator set the changed or the difference in the valid or set the change in each epoch and run this

transition inside snort proof now it would get you from knowing as inputs the evaluator set at the Genesis block to develop it or set at block 100 without having to see all the epoch blocks in the middle you just need like the beginning and the end and you're good you can be certain this is developer set lock 100 now the reason that we had to not use maybe the curve that is popular right now which is be less twelve three eight one is that we want to run the verification of the other signatures inside a snark and that means that this

curve has to satisfy some properties it's about the to a deity of the base field of the curve but it's not really important but we we just we can just say that three eight one does not satisfy that it wasn't a design goal for three eight one and actually three eight one has bit better performance for square roots for example because of that because they don't satisfy this property that's yeah that's an interesting approach so to recap I mean that the main problem of a like client is to figure out what the correct chain is and in aetherium as it is today it does this by downloading all the headers actually in reality it checks hard-coded header and sings from

there mmm but that's undesirable for other reasons so you imagine you have to download every header you already make this better by introducing proof of stake because you you really only need to download the headers for where validator transitions happen to be able to verify that those are done correctly right so now you need to download one per day instead and then you introduce that or reduce that even further by saying you don't have to download each state rent or like each validator transition header you can just download this zero knowledge proof that proves that all of the validator transitions

have happened correctly is that an accurate summary exactly perfectly so in effect you are proving the light client protocol that you would have if you didn't have these snarks yeah so you've some of your listeners probably are familiar with coda which is also using snarks to prove not just headers but entire blocks and entire transactions inside those blocks and so one way to think about the difference between these two approaches is in Coda's case you're again proving every transaction every you're proving the whole consensus protocol and then you're recursively composing that with previous proofs whereas with the sello approach you're

just doing that for the light client protocol and so you still trust other full nodes to correctly validate the chain and to make sure that no illegal state transitions could happen but again this is what most protocols do today and and it's interesting I think place to be on the on the kind of trade-off spectrum for kind of trust and data utilization and just usability I'm curious when you say that you wanted to reduce data even further what what was your goal did you have sort of I need to be able to sync the chain with a 2g connection or

something in mind but like where does your requirements come from yeah so we're targeting 3G connections and the a lot of the users that we interviewed frequently just turn off their data entirely so they are so data sensitive that they frequently just keep data off and so in a world like that there's really no number that you're trying to hit you're really just trying to make it be as lightweight as possible because any and all data is too much people are turning it off in this model the goal is to have one zero knowledge proof that you download and can verify that you're on the correct chain but how do you

actually get to one proof if you're proving that the validator transitions doesn't that still mean you you need to have one proof for each epoch okay that's a great question so this is okay it works like this so what you have to do in order to verify an epoch block you have to do a few things so the first thing you have to do is verify the aggregated VLS signature of this epoch block and in order to do that you have to know the current validator set or the public keys of this validator set so that's one thing you have to do this is one step that you need to prove another thing is actually in BLS signatures you have to do something called hash to

group you have to transform your message from a sequence of bytes to a group element and that's something that's usually done with hash functions that are cryptographic hash functions like Lake to shatter physics and this becomes pretty expensive when you need to do it on large messages and want to do this in a snore so what what we did there he is we too we built a construction that's a composition of pettersen hashes to compress a big message where the message would be the validate or diff of the tip of block or developer difference so what validators were added in this

block which were removed and this would be the message that we verify the signature for so we compress this message using Patterson hashes which are collision resistant for fixed size messages at least and then we run more traditional cryptographic hash function like to and we get a group element okay so this is the second thing you have to do so we can do both of these things many times in a single snort proof let's say n times and then we get a state transition from block I to block I plus n so you have a snort proof that verify these ten state transitions may be something that would be interesting to

note here is that we do use here one level of recursion which these pair of curves that we use allows and this is because the 377 curve that we do the Miller signatures on can actually run snark proofs inside it as well so we use that curve to prove the result of the Patterson hashes and the Blake to hashes which allows us to stuff more blocks in the outer curve in the outer snark and that's how you get too many VLS state transitions in one start proof we maybe I should add that it doesn't have to be

one block or one sorry one snart proof that light client downloads because this thing has finite space and maybe creating a snort proof that has all of the blocks is too big so you might have to download two or three I see do you already know what practical limitations are how many blocks you can fit in so this is something that we're still benchmarking this is emitting flux but it seems to be in the range of tens to hundreds cool yeah so that would be potentially hundreds of epochs in one proof then so your aren't like going back to like how you're reducing it you're going from every

header to one header per day to one hundredth of a header per day could be one proof per year for example yeah yeah so these are not proofs we've already mentioned snarks and a couple things but what what's there are knowledge proofs are they proof that we use our second snarks and we actually used pair of curves that this is XE paper introduced we use the same curves but in a very different construction than what the sexy paper used them for and the proof system that we use are some of the known ones so

it's gonna be either bogus on 18 which is it's a variant of growth 16 which is simulation extractable and we're still seeing if we can reduce that to something that has less guarantees and a bit more efficient but if not we good with that are you are you experimenting at all with like a universal set up are you doing a more traditional trusted set up so this is something that we're definitely exploring we expected for future works universal set ups or Universal proof systems will improve the let's say the user experience and the trust plot so this is something that we would really want to use in the future

and we're exploring to use that but for now you haven't actually done a trusted set up for anything this is just sort of a theoretical thing you're gonna do in the future when you deploy this right so the plan is to port the powers of tau ceremony that has been done for the cache sapling that has to two steps in it so one step is about something that is not circuit dependent something that everyone that uses the same Cavs can enjoy and just want to make snacks about in those cares and the second phase in that setup is making that creating the proving and verification key is for the specific circuit you want to run so what we we

hope to do is to collaborate with the community to do part of Tao ceremony for these curves so if anyone is interested in in waiting or doing a setup for these pair of curves and is interested in using these sexy curves and this is definitely something that we would be happy to talk about that whole new phrase sexy curves we talked to them about the naming and it was slightly constructed an interesting aspect of the trust that setup here is the the danger and like why people dislike trusted

setup so much is obviously it threatens to break the system rights like in Z cash if the trusted setup is broken then people can mint coins it's all sorts of disasters on the horizon if someone breaks the trusted setup of your system what can they do it's a really great question for a good reason there's a lot of I think angst around these ceremonies being done correctly especially for projects where if it wasn't done honestly then someone might be able to mint coins in a fully fully secret manner luckily for us there is always a way to verify the chain without a snark

and so if one were to ever find a proof that claims that a particular header is part of the chain that can be shown is not really part of the chain by performing a an actual full node sync then you will instantly know that the trusted setup was compromised and so there's some work that around tremor one of our advisors has been doing around sharks and he's really interested in kind of having these proof systems that have the same behavior where you have a very fast way of verifying a proof and then potentially a slower way of verifying that proof that doesn't rely on a trusted setup so in

his research he was using bullet proofs for that slower way but for us we don't actually even have to use bullet proofs you can just look at the chain itself and just verify the headers as you would if you were on any other protocol and so I think that is a very I think nice benefit of the way that the protocol is being designed again this is one of these cases where as your knowledge proofs aren't being used necessarily for privacy or transaction of tokens where if something is corrupted it gets really dangerous or expensive here it's it's proof of data the fact that it's there or the fact that it's correct and the

data itself makes its public still exam and so if a potential attack scenario I guess is someone manages to produce a false proof includes that then tells someone hey I paid you a bunch of money they like client sync look say yes it looks like I've gotten a bunch of money I'm gonna give you this product that you bought and then you know it's a falsified block so they didn't actually get paid and they're out of products so it's sort of you could execute a sort of double spend at AK on one like a particular targeted user I guess but then what you're saying is if there is

at least one full node who are is sinking then as soon as they see that block and try to verify the proof and say that you know that this thing is wrong they could sound the alarm and basically tell the community in some way that hey this thing is false if I don't trust this so so only if it was like payment for a real-world acid where the asset had been transferred over the payment had seemingly been made at that moment they can get screwed over but it will immediately be like flagged and only if the trusted setup was compromised and so the best way to avoid that is if you are interested in transacting on solo in the future participate in our trusted set up

and act honestly I wonder could you make this is just a side but like given this idea of the universal set up where you have constantly the ability to join a ceremony after it's already kind of launched meaning like if I want to know for sure that that is safe I myself could join at any time I haven't seen this yet but it would be interesting to see where like a zero knowledge proof is being used or as snarks being used and at the same time there's like an option to opt in to this Universal trusted setup somehow yeah I think that's a big selling point for sonics and for anything that builds on that is the ability to say hey if you want to use this system opt into the security participates and you can be safe but

it's I mean the whole trusted setup thing in Saren large groups in general I suppose is an interesting one because there has not been a ceremony that was compromised so the problem with Z cache for instance the bug there was not in the trusted set up it was in in the construction of the thing itself so it wasn't like the secrets leaked out and they were able to recurrence reconstruct things it was that the thing was wrong to begin with kind of so it seemed like no one really has any reason to distrust powers of tau setup that's true last week was blockchain week in Berlin and at the web 3 summit I did a session a bunch of workshops one of the

workshops was about interoperability and zero knowledge and all the ways that zero knowledge proof could be used for interoperability and that's actually where the sallow light client came up to kit was brought to my attention because by creating these zero knowledge very light light clients this could potentially help when you're talking about cross train communication have you guys is that part of your thinking is this sort of part of your goals with building this absolutely I think that's a very great side benefit of inefficient to verify and like line protocol is that you can more efficiently verify it on chain of annex separate platform and so I think and correct me if I'm wrong Kobe BLS 12 377

there's a pre-compile that's potentially slated to land in the next aetherium hard fork and so should that be included it would be possible to verify our like client protocol on aetherium on chain and so that yeah so that opens up a lot of opportunities to to build a permissionless bridge between the two genes not actually I mean this this also helped me to better understand so I had always thought of bridging more in this I don't know we'd always learned when we talked to Igor I remember thinking of it like it's locked on one side minted on another I for some reason I maybe we

mentioned it but I had not realized the importance of light clients in that original conversation but and that may be correct me if I'm wrong but like for a lot of interoperability you don't necessarily you're not using this light client model some of them I believe polka dot and stuff are using an overarching model but our light clients still important in those like in the cosmos network or the polka dot system are are the light clients still very very important on the separate chains in order to actually do anything yes it depends on how trustless you want to go if you so in cosmos I think if you want to have a quote-unquote trusted trustless pretty I mean you sort of still sort of there's

still some trust assumptions in there for all bridges but I think they need like clients in polka dot we are not as a resource-constrained so technically you could like boot up a full like a full node that is a pair of chain and sync using full nodes but that would be extremely costly way to do it and so if you have like clients that are easily sinkable then you can embed multiple like clients in one parent chain slot and so bridge like 100 Cheng's in one parent chain salon using like clients so it's still very important and the size of them in this interoperability case like I understood it very much in the case of like celos specific where like you want to get it

down to that mobile ready like client size but what about in the interoperability way like does it if a light client is very very small does that actually make the system more efficient like where where do the improvements actually happen yeah it makes it more efficient okay it makes it so you have to pay less gas to verify the other chain on your chain okay so speaking about you know the going back a little bit to the proof system so you're using and talking about death where's the code for all of this what code are you using for the snarks is it like a lip snark thing or the latest d'caché code for it or have you built your own thing to like as approver verifier so what we use is the sexy code base that has been developed by the skipper lab

and this is so most of the cryptography related development happens in rust so we built we built our system or our photography related part of the system and on top of sexy we have our own rust crate that implements needs BLS signatures and some of the snark work that we've talked about that's public publicly available online and this is integrated into get as a static library and yet think cool and all of it is open source and you can find it at github.com slash silo - org ok so what's next for the cellar project well actually where

are you guys at like is it is it all live we have a public test net that's been out for awhile it's called the alfajores test net it's named after a delicious cookie from South America introduced to us by one of our early community members in Argentina and will actually be naming our next network through soliciting other delicious foods from around the world so if you know of a great be food let us know and I think bibimbap is a contender right now so you got to do better than that and so right now we're auditing a lot of the work we have five different audit firms that are looking at

everything from the security system to the economics and game theory behind our proof of stake protocol and the stability protocol and then we're also actually actively formally verifying every one of our system smart contracts and hope to do that by lunch as well when is lunch yeah and so next up is to release our release candidate Network and on that we're gonna do game mistakes and so if you're a validator or if you're interested in keeping your toe in that space then definitely keep an ear out I think starting in October or November we're gonna have more news on

that front and then depending on how things go on there we'll be launching at some point soon after cool well listen thank you guys so much for coming on the show talking to us about sello about like clients about zero knowledge and like clients about about how a small like client can be awesome and what it can do yeah and good luck with the project and everything thank you it's awesome being here thanks for having us thanks for having us and to our listeners thanks for listening thanks for listening you [Music]