ZKPodcast: Aleo with Howard Wu

Transcript

[Music] welcome to xero knowledge a podcast where we talk about the latest in zero knowledge research and the decentralized web the show is hosted by me anna and me frederick [Music] this week we catch up with howard wu and learn about his new project elio which is built around the sexy zk construction but before we start in i want to say thank you to this week's sponsor leased authority leased authority is a security consulting company known for

their dedication to privacy respecting solutions and boundary pushing technology they are a team of security researchers open source developers privacy advocates and cryptographers specialized in security audits design specification reviews and security by design you may know them as the team behind the security audits and reviews of the eth 2.0 specification protocol labs gossip sub protocol z cash's sapling upgrade tesla's foundations tzbtc block stacks investor wallet metamasks lava mote and more beyond auditing they also have extensive experience in building distributed systems helping to improve privacy enhancing tools and making regular contributions to open source software projects if you are looking to

improve the security of your protocol or verify your use of cryptography including zero-knowledge proofs anytime from design to implementation you can schedule a no obligation call to find out how least authority can help on your project visit their website leasedauthority.com and hit the schedule a call button to book one of these calls i've added the link in the show notes so thank you again least authority and now here's our interview with howard we have today on the call howard how you doing howard i'm good and uh thank you for having me on so howard has already been on the show

we actually did this episode on zk snarks it was one of the most popular episodes i think we've had on the zero knowledge podcast and in that we actually did introduce howard quite extensively and so you might want to listen to that episode i'll add the link in the show notes but just briefly howard is a researcher at berkeley he co-founded the decrypt capital vc and is also the co-founder of a new enterprise called elio and actually just as a side note i've actually been freelancing with alio i've been working on a very specific thing and i don't know that much about all of the other parts of elio so this is a chance for me to also explore this project a little bit deeper i i'm pretty excited to talk about this and

i'm also really glad that we're finally public um it's been about a a year of work that we've been working on um in stealth and um you know in the past 48 hours since since coming public i've been getting a number of of emails and also messages from people there's there's now a developer preview that we've put online and people have have started filing bugs and also joining our discord to give us messages there and um it's been it's just been a very exciting time cool maybe to set the background a little bit i know very little about this project other than the the public announcements what was the spawn of this why did you start working on this like what was it that

made you go like what was the problem or what was the the inspiration that made you kick this off okay sure yeah so i guess like over the past year you know i've been thinking about ways to for applications to become more personal and more private today the the model on the web is very much about providing free services in exchange for personal data and uh you know one of the things that i i really want is just to be able to use my apps in peace you know i want to be able to use personal apps without needing to hand over my personal data and i want applications that can also let me decide when and how my data is being used and actually enforce that and so you know in building a leo my goal has really been to to build web services that can

that can become truly personal um living in places more than just your browser and also provide an experience that is really tailored for you and where you still have control over your information in the previous episode we had you on i think we would have done your your background from you know start to then and so anyone who's curious about maybe that background i'll put a link in the show notes to that episode if you hadn't heard it already but i i'd be curious to hear a little bit like since then you've i mean you were working in academia and you were working in vc and i'm curious like what did you learn in that time that sort of made this idea pop into your mind

i think the number of experiences that i had that i've had over the past few years have taught me a lot of things like first i've seen a lot of projects uh within crypto build out ecosystems and communities and and i've also seen a number of applications enabled on blockchains one of the things that i've i've wanted over the past few years is this is this ability to have a private and programmable applications which hasn't been been possible thus far and that was also why you know we worked on zxe um we looked at the ecosystem and realized you know there's kind of two axes you can really evaluate to uh crypto on and it's one is on on programmability and the other is on privacy and uh you know bitcoin is rather low on both ethereum goes one direction to offer high programmability

and zcash goes the other direction offer high privacy but there's there's this upper right hand quadrant of high programmability and high privacy that's really missing and you know it's an area that that we said why don't we take a stab at it um you know i've i've wanted to see applications like this uh you know for many years now and and that was how sexy was was born we ended up publishing that as a paper about it you know actually it was it just debuted this year um and we published the code last year um for people to start trying and using it um you know since then the reception has been quite strong and positive um people have been really interested in you know applications like uh like using decentralized dark pools or mixers for it

and this is an area that i think you know ethereum has uh has a lot going for it but it doesn't have the the foundation to actually support these types of applications and it's something that that for me you know i've i've wanted to to see out there and it's something that that we've been we've been then tinkering with and trying to make possible did you ever try when you were doing more of the vc stuff did you ever kind of like try to find a team to do it were you ever like hey there's this great technology that we came up with the system that we came up with do you want to build it or were you always in the back of your mind thinking like i'm gonna this is mine i i i definitely did not plan on doing this

uh when i certainly my role as a vc we tried finding teams to commercialize xc and uh one of the challenges that we found was just finding good pairs of people is really hard for this particular problem you have a very complex technology with with a a market where people not only have to understand the technology but they have to be able to explain it well to other people and combining you know the business and the development side well uh we found was really difficult and after you know a year or so of of this well matt and you were the ones who actually really were asking me about about uh commercializing it myself and um you know after after much thought uh

and discussion i said why don't we see if we can assemble a team and uh and somewhere around middle of last year towards the end of the year um we realized that we could and we said why don't we give it a shot and uh you know that was that was how helio was born cool so like anna mentioned earlier we had an episode with pratush about sexy in particular and we'll link that um i'm curious in part also like what your involvement on sexy has been but also again do a recap of what sexy is as you mentioned it's it's in this cross between private and programmable but how does it actually achieve that

yeah so at its core sexy which stands for zero knowledge executions is a decentralized private computation protocol the idea is that we're using zero knowledge proofs to enable private applications in a recursive manner the high level of sexy is that there's really two things that we really wanted to achieve with it the first one was to offer full privacy for applications and what we mean by that is that we we delineate in the paper the two levels of privacy one is a data privacy and the second is functional privacy and the you know data privacy is quite intuitive the idea is that if you and i are communicating or you and i are interacting

only you and i should see this information and what functional privacy means here is that in addition to just our data being private the application that we're using here also is not known to the public so from an ethereum perspective you could think about it like you know not only do we not know the amounts within an erc20 transfer we don't even know the fact that you are using this specific year c20 token or even an erc20 contract at all and so that's the that's the conceptual idea on privacy here um and the second is really around providing a more scalable solution and by scalable you know people like to talk about tps from our perspective we've been looking at scalability in terms of the size of

of applications so on ethereum because there is roughly 10 second blocks and you have a block gas limit that you have to abide by applications can only run for so long and so the way that we get around this is effectively performing those types of application runtimes off-chain and merely verifying the proof's on-chain um and so by doing that you can as a miner just check the output along with the proof and know for a fact that this state transition is correct and by doing it this way it's far more scalable because it allows the miners to spend less time checking every execution but also that every execution can be you know the same amount of time to check and because of that you know

that you can fit far more transactions into a block and this is also a way for applications to run for much longer than that little time slice that they're actually being given you just mentioned this like recursive feature of the sexy protocol like is it i don't know if it's easy to do this but i was kind of trying to picture how that compared to something that we are more familiar with like the zcash transaction where there's a snark prepared for each transaction when you say recursive like is it each transaction then does a snark of the entire blockchain rather than it just being like a snark attached to a transaction yeah so uh when i mean recursion actually there there's different there's different types

so um in terms of recursion uh the approach that we took in in zaxi was to have a recursion of depth too and so it was a fixed step recursion okay um there's also you know a lineage of recursion that that is more common which is to have cycles of pairing friendly elliptic curves be used and by doing it this way you can kind of have quote-unquote infinite recursion in our case the motivation for having this recursion is specifically for privacy for every transaction so in instead of having transactions themselves publish proofs about the runtime we are actually verifying the proofs about those application runtimes and then bundling those into a transaction proof um in order for that to be published and

and so that the application data itself isn't visible this approach lets us you know achieve that level of functional privacy because um the application proofs themselves are actually checked within a an outer proof but is that recursion you say it's only level two it's like is that how you described it i've heard that just said a few different ways like we're curse uh depth two two yeah layer two but i i guess are you doing that for compression in any way like is it to make it smaller as well are you combining lots of them under one of these recursive snarks and then making it smaller yeah that that's definitely a another added benefit is that by checking multiple proofs here within one single invocation you actually

compress the transaction so that you can bundle in our case uh in the example in zaxy is two and two out that you can actually compress those four proofs into just one proof um and because of that you actually save space uh you know as a as an added benefit but the main purpose is functional privacy right it's not like you're not doing it because of compression yeah it comes as a as a side effect for free and uh it's certainly nicer to be more efficient uh also in space yeah and i i would encourage anyone who really wants to dig in deep on how sexy works to just listen to the episode with british where he explains the birth scripts and death scripts and how all this works something that we touched on in that

episode though is the ergonomics of programming in sexy which is a huge problem or you know it's something that we discussed back then and the problem being that you need a trusted setup for each new type of application like the programming model is very different from ethereum so you need to like rejigger how you think about smart contract it's not one contract that just lives in a place but created and destroyed when you move coins around or move you take those around i mean i i suppose this is to some degree what you try to address when you build a product around

it but before we get too deep into like the company the product side of it maybe what are your thoughts on those are these problems that are fundamental or can they be solved yeah so in terms of the developer experience for for for writing applications in the sexy model it's it's something that i think can certainly be improved upon the way that we architected sexy was to allow for any type of music here to be used for um applications and um you know this could be anything from like grot 16 like snarks up to universal snarks but also you can use you know like bulletproofs or starks and um this model is meant to be be general um for

different types of primitives um in our case you know the proof system that that that we're actually using for elio um is marlin and the rationale for that was to to design a system for applications where developers don't have to run a trusted setup for every app it would be of a huge uh barrier to entry in my opinion and it also just be a huge pain for for developers to have to reason about and so from our our perspective it was something that we thought was very important and it's updatable which is a really nice property to have here in terms of the actual programming model you know it's something that in the paper we we provided three examples for um so the first one was uh you know

private custom assets the second was a private stable coins which are things that that allow you to attach policies to them and then the third was a private decks and we we gave two different variants in in the paper for that um and uh you know these are these are applications that we think you know in crypto are already um kind of widely adopted or widely accepted and we wanted to show what the privacy preserving variant of those could be um and you know even since then we've been evolving the original designs of that in the paper so that it's more encompassing it's more secure it's also more performant and uh you know that's that's an area that that we think is is also very exciting so i think at this stage you know we've refreshed a little bit

this the story of sexy and the story of how it works and some of the challenges and now you've started to explain you know how it's been how these challenges have been taken on but we should actually describe elio and actually introduce elio maybe a little bit more now so what is alia what is this company what is it doing so the idea for elio is to build a platform that is fully private and to support applications that can be both truly personal and truly private you know over the the past few years one of the things that i've i've grown to care deeply about is this ability to own your data and for information to be you know private i think one of the really cool things that zero knowledge proofs enables is

this ability for you to run your computations on private information without revealing it to other parties and as part of that i've been exploring these these ideas especially with respect to the web on you know how you can provide user experiences that are truly private for for the end user while providing you know the service providers themselves with the correct information the correct state to continue serving them correctly and um this is a model that i think is really underexplored especially in the context of the web today um you know the web itself has a model that requires users to kind of exchange their personal data for free services and and i think that there that this model not only is

antiquated but it's also really uh incentive incompatible for for the user and for the provider i think that there are you know far more clever models that people are starting to to really realize and also reason about and you know for for me it's something that i find very interesting and fascinating to explore what was your experience at like at decrypt you worked in academia and vc so you had access to so many different projects but like in that process something dawned on you that made you feel like you needed to build this company what was that like what was the spark that really like made you go no like there's something still missing and one of my frustrations with the blockchain industry as a whole

is just this general trend towards building solutions in search of problems i personally think that it's important to work backwards by starting at the user experience and trying to find the technologies you need to actually go build those solutions i think we have a real shot at positioning helio um to address a lot of the shortcomings in crypto um you know for one i think deeply about user problems in general like it's something that i spend a lot of time on every day and uh you know one of one of the areas that i really wanted to hit with alia was just solving for the web like the web is a phenomenal place it's a place that that really connects us and allows us especially during you know time of covid to actually stay stay in touch with each other but at the same time we know that

freedom on the web is going down that censorship is going up and just the quality the experience of the web itself is degrading you know there's there's fake news there's all these different uh you know advertising platforms that are taking over there's there's a lot of spam that that's being pushed to users and and we see it on our devices every day it's it's a fundamental user experience that i think could be far better and and i think that the business model of the web itself could even be completely changed and you know i think we have a real shot at at making the web a better place and you know elio is is designed to actually provide that type of experience and you know zero knowledge itself is a phenomenal technology for enabling that um you know we don't have this notion of of private web data today

um and and everything is starting to become a public commodity if you look at your household there's just devices everywhere now and and we've come more web connected physically in our personal space than ever before you know in the wrong hands this type of technology is very clearly able to become a type of big brother experience where you know it's not something that we want or it's not something that we intended to build for and and i think that being able to separate public web data from private web data is an important thing especially for this next decade the internet's going to become pervasive it's going to become incredibly personal and i think that if we don't actually go for building the the platform that allows private applications um we might not get it and so for me it's

about building a web experience that actually addresses this this shortcoming and provide with zero knowledge you know a technology that actually can enable this um in the right way i think that uh you know it's it's a value proposition that should be open source it should be permissionless and and we should allow allow anyone to you know contribute and participate towards because it's something that affects every one of us as we become more web connected it will only become more apparent to people when you when you talk about this like so you know we have critique of the web but i guess how do you undo this model that exists like do you still have to keep a foot in the web in order to do that well i first off i think the web is a really cool place and um you know it

doesn't make sense to try to replace it um you know we've grown used to it we've grown accustomed to it and more so it's become a real part of our daily lives i think what makes sense really is to build an experience that is integrated with the web it's cohesive with it and it actually helps to unlock new value on the web um so the purpose here is really to provide an experience for users where you know these types of services really live on the client side and uh instead of having to send your data over to the server you know you you actually can just get transparent algorithms from the server and run it on the client side you know for both sides there's certainly benefits you know from the from the user's perspective they're no longer forced to give up their data

in exchange for services that they want at the cost of their personal privacy but also for for the provider they they don't have to bear the risk of managing user data to provide their service so that means that they don't have to face the implications of storing processing and reporting it in this model i think it's it's one that that really allows the users and providers to be incentive aligned because they're no longer in this game where reputationally you know the provider is taking on all the risk for the user and the user is forced to give up all of their information in exchange for for that service it is obviously a common complaint especially in in the blockchain world of yeah the web is broken and we need to fix it

and it's always interesting to see how people argue do we integrate do we provide something new i think both paths are fine but you kind of have to keep in mind the user right if you're providing something new you need to get over that inertia of the web and like get someone to download a new kind of thing and get them to understand why they should do that i think that's a massive task well if you can integrate with the existing web and just provide some more value or some clearer like you actually own your data on this website and then i think that's a lot easier path to go as well because ultimately

we're only interested in solving problems for people and like doing what they find valuable so i think if you can meet them where they are it's it's a lot easier but it for me this brings up a huge question i mean with what you just described we are in this world where we give data to companies to for a free service but this is spawned from the advertising industry and it's spawned from a place where people decided at some point they don't want to pay for things anymore right they'd rather get it for free and give up their privacy how do you reverse that trend and tell someone

you now have to pay or if they don't then what's the business model for the for the provider so in terms of you know business models i i personally think that you know first off that model remains cohesive in this in this new architecture but at the same time i think what what this provides is more choice for users you know on the web today there is no simple way for them to pay for things there is no simple way for them to bill for things and having micro payments and having the ability to actually charge from a resource perspective is quite difficult right now and as we explore that the different types of assets that now exist within crypto i think it's starting to show that there is

more forms of payments than merely just money on its own that that services and assets themselves more broadly um can be used in exchange for other things and this this is almost like going to this concept around bartering but with a model that is far more scalable now and from this perspective i think these types of transactions allow you to actually pay for services fairly without having to to give up your data in exchange for it but i would also emphasize and stress that you know for services that want to collect your data and use your data you know i have no issues with that what what i really find issue with is is when they don't uh tell tell that to you up front or and transparently um i think thus far today we don't really have good technologies to go and enforce that they're using your data

responsibly and and once your data is in in their hands you know there's no take backs so it's very hard for us to control it and because of that you know we don't really have the power here and so what this model really is trying to do is to open up the the types of options or opportunities that that both users and providers can can explore and find the one that meets their needs i think that when it comes to user payments it's certainly one model where on the web today it's virtually impossible to do that at scale for every small item that you want to receive or for every small bit of of streaming that you want to do and in this model it's something that you actually could give people the option to um

to have um i wonder like the thing is some like some of these topics this idea of like privacy and then you know putting more power into the hands of people like this this does come up often with the projects that we interview and so i'm kind of wondering like how does elio line up when you think of projects like aztec or mata or fendora or coda these are sort of very zero-knowledge focused projects where do you position elio when you compare it to them you know my personal belief is that in terms of what we're building the technology needs to sit on a new stack to allow for privacy um for applications you really need to build a system from the ground up that is private by default and we see this today already on on

ethereum you know without without privacy you know applications like smart contract mixers or dark pools can't fully protect user activity it just doesn't work and um for companies who actually want that and want the skill associated um with off chain computations there is no good combination for that today um that's where you know we've we've certainly thought about building this uh as a solution on ethereum we've certainly considered other architectures as well and at the end of the day one of the things that continues to come back to us is the complexity and challenges of building a system like like a leo on a layer one that isn't private by

default so i think we've defined philosophically what elio is and what it aims to do but what is a leo what is it like what are the pieces of this project so it is a platform that is decentralized um it has a blockchain and it uses this blockchain to verify and store proofs these proofs are effectively sexy transactions and um the the architecture that we went for was something that was bitcoin like so you know in zexi we talk about um a ledger and we adhere to what looks like a utxo model here um and for consensus we've been developing something that is very much snark friendly so um you know

one of the my personal goals which is less about the web is this ability to have zero knowledge proofs in kind of mainstream audiences and one of the biggest barriers to getting there today is this ability to performantly compute zero knowledge proofs i don't have a hardware background myself and neither do people on our team but what we do have is the ability to design incentives and incentive mechanisms and you know what we decided was to build a consensus algorithm that adhered to the same type of of cryptographic stack as the applications that would uh live on on a leo and use that to basically incentivize miners to develop hardware acceleration for snarks um i think that the ability

to have really performance snarks is is really cool but it's also one that we've seen um even from the traditional computing industry from for many decades ago if you look at many of the cryptographic algorithms that are commonplace today and for example for https those types of operations under the hood are really slow in software relatively speaking and it wasn't until you know companies like until started adding these cryptographic units into every cpu that that's shipped that these algorithms actually became performant and because of that you know if we almost take https for granted today but these types of technologies you know required real hardware to be baked into every chip

for every device in the world in order to be practical for use and uh i think that we're in a very similar a very similar story here and the hope is that we can bring verifiable computations and and the goal is is to bring verifiable computations to mainstream audiences and this is this idea where the consensus so the mining of this blockchain also like whatever that action is under the hood the thing that people are going to spend money buying hardware to potentially do and earn from it that process is actually useful throughout the rest of the system yeah um i guess the best way to talk about it is um so the consensus algorithm that that

we've been working on is called proof of succinct work and uh it's based on proof of necessary work um with akis um so we had on the show a few weeks ago and i'll admit to that as well so the idea for us has been you know instead of going down the path of a succinct blockchain um we've been more interested in uh using elio for interoperability and also for for building efficient like clients and um one of the things that we wanted to do was to have this consensus algorithm be useful work and instead of actually checking the entire history of a blockchain we wanted to confirm that a transaction is actually included in a block and so in our architecture this circuit

is effectively checking a merkle tree about transactions that are included in that block and it's a it's a very convenient way for you know a smart contract on another system to verify that a transaction was actually included in block you know 58 on elio by just verifying a proof so this model is very nice for interop but it's also it's also great for light clients because it's a very simple way to say if i'm downloading a blocks data i can i can check very quickly that these transactions really were included in a specific block without having to process them individually from genesis again that's interesting so it's sort of it's proof of work where the work is generating proofs that the transactions are in the block

yeah so the best way to think about it is similar to bitcoin it's a proof of work consensus algorithm but instead of grinding shot 256 we're grinding snarks here and by doing that the goal is to incentivize miners to develop hardware acceleration for snarks so that we can make these types of computations a commodity and commonplace um by doing that and creating that incentive um you know application developers on a leo can actually run their their applications uh you know on ideally various service providers who happen to now have the choice of saying if market demand says that you know there's a lot of programs and people want to pay a lot of transaction fees to run their programs great i will target my hardware for those types of programs

but if if suddenly there's a drop in activity you know it's not that these chips are useless there is still a blockchain here where i can actually mine new blocks on and get a block reward for and they can then target it for that instead i think that that's also something that will be useful for companies like mata or for aztec where you know they are building validators for rollups and these these rollup validators themselves are you know designed to be very performant for computing zero launch proofs um and in the case that there is low traffic for roll-up transactions they could also use their hardware to actually target mining blocks on a leo and this gives an ability for you know validators there to actually have some constant or or

more stable type of revenue but is like when you're saying grinding the snarks like when you're actually like proving them or going like you're using that the work is the snark generation is it useful snarks or is it useless snarks is it just the act of proving a snark or do you actually are you actually attaching that to something else so the circuit itself is um effectively a small merkle tree and this merkle tree is meant to represent you know the state of this block so by performing this type of work well for one you know we're basically asking the miner to now check that the transactions are included in this block

but then for the rest of time every node no longer has to perform that inclusion check themselves because they can simply verify this proof to ensure that that they actually have the right block data and this is a really nice feature to have because it saves on all future participants for the rest of history from having to do extra cycles of computations for themselves and it saves on a lot of work then is there also a proof that i'm on the correct chain talking about like clients so so consensus about which chain you're on or which network you're on is a really hard problem and it kind of gets back to just what is the source of truth so in this case it doesn't do that um and it's also one that's you know more fundamentally just a question on

consensus on what is the the most common or or what is the on what is the right state yeah so back to anna's question i guess to to keep talking about like clients you know normally a li client sinks the whole header chain to know that they're in the right place and then they go i want to know either some state or or like in bitcoin i want to know whether this transaction is included or not and then they go ask a full node is this transaction included and the full node replies well i'm at this block with this hash and this is the merkle tree here and this is the transaction so you can now

you know here's a merkle proof that it is here so what you're doing is because you have this proof of work that that proves the inclusion the full node doesn't have to reply perhaps with anything that's a question but even if they did have to reply with anything they just play with the snark with the snark proof saying here's a proof that it is yeah it ends up being a proof of inclusion um for that transaction and it's something that is even composable so for example if you really wanted to give a proof that uh not only was this transaction included in this block but it was included in this block that now has six confirmations what you could do is

actually take six of those proofs in in those blocks and actually then recursively come up with one new proof i'm on top that actually checks that those six block proofs are indeed valid and that this transaction then was included in the most recent of that and then you can send that over say to a smart contract to go and check there um just one proof instead of six um and and by doing it this way uh it it's far more efficient for actually uh doing interoperability but it's also a really nice way for like clients to just quickly validate oh like if i really want this transaction and note and want to know that this thing really was included on this ledger at this at this block

they can i mean a question for me immediately is do like clients still just sync the header chain or i mean it feels like it would make sense for them to sync the header chain and all of the proofs like depending on how large the proofs are like the difference between a like client and a full node is not necessarily that it's cheaper on data but that you don't re-execute the transactions but if you synced all of the proofs then you still don't have to re-execute the transactions you can just verify the proof yeah i mean in this model because the vm doesn't live on chain um there there is actually never even execution for for the full nodes themselves

um everyone on elio just has to verify proofs and these proofs will ensure uh you know that the transactions themselves are valid state transitions yeah so you're you're almost collapsing the the roles like a like client and a full node is basically the same thing i mean you could construct a lighter like client that doesn't have all of the data or something that that is selective in what it downloads but it's more or less the same thing yeah the idea really is to make it crypto economically and well incentivized to you know the idea being that on ethereum today for a minor they they have to reason over whether to spend their cycles checking a transaction or trying to mine

the next block effectively and it's far more efficient to say you don't have to re-execute these transactions from genesis forever in order to verify this block and instead you can just spend your cycles mining um i think that from that perspective it's also you know far more efficient you know quote-unquote gas-wise because everyone gets and only needs the same amount of time per transaction to be reasoned on in order for that transaction to be included in a block um in this case you know we're talking constant times of you know some around three milliseconds and and because of that you know no one needs any more time than that um so it's a really nice benefit to have in this architecture is like i know that there's i know sexy the sexy curve the sexy concept has also been

implemented in plumo this uh light client on the cello construction is there any relationship to that is it is it similar yeah so the the seller folks are using the zaxy curves um they aren't using the xc transaction model more so the curves uh provide recursion which is really useful in their case if i understand correctly for proof of stake in leader election and also then composing the the state of of every round um for their blocks and so in that model they are using vls 12 377 and and to my knowledge uh they are exploring using bw6 uh for then doing uh block compression like techniques but i guess in yours it's it's different because this leg client could almost be this main

main node at the same time like where frederick's saying that they're kind of merging of roles in their case they have a more traditional blockchain where they're using this sexy curve for purely the like yeah like the difference what i would say is that um for transactions here on the other they are actual as xe transactions and so because of that every um every execution is private and every execution comes with a zero-knowledge proof um in the cello model uh to my understanding um it's effectively a fork of geth where uh transactions adhere to the smart contract and ethereum model and rather for validators they are now you know constructing signatures for the next block

and by having a proof about these signatures it's a very easy way to make sure that since genesis that you know your your block history is correct and that you're actually synced to the to the right block as the latest block yeah that is the point of the cello proof is is like what i said to prove that you are on the correct chain basically as far as i know they bake in some origin hash to prevent long range attacks and basically say this is the chain that it's supposed to be and then you have these intermittent proofs that you just sync those proofs rather than syncing the whole header chain um so it's just a faster way to sync alike lines rather than providing any privacy or any

like other thing it's just faster syncing yeah one of the things that i wanted to sort of dig into was a little bit like the different snarks in the system like the sexy curve itself did it have a variety of different snarks in it acting at the same time yeah so in zaxi we have a few circuits and these circuits are used to to make attestations a validity for different statements for example there's there's the inner snark here where the inner snark is responsible uh one with checking that uh a transaction is actually based on correct ledger state so the way that that a zaxy transaction works

deep down is that we have serial numbers and commitments the commitments are generated when you create a new transaction and the serial numbers are revealed when you spend a record and so in this model the commitments themselves are composed into one giant merkle tree to represent the state of the ledger and with the inner snark we're actually taking the root of that tree um the ledger digest and checking that when we're spending a record that that it's corresponding to women actually lies in that in that merkle tree with the outer snark it does something a little bit different so the outer snark is the uh circuit here that is actually one checking the inner circuit's proof but then

um two it's also checking the input the death programs and the birth programs proofs so for every transaction your reasoning over you know spending some records and birthing some new records and with each of those it's basically an application run time where you are composing a new proof for each of those in this model the outer snark can check for example four proofs so two into out um and uh compress those as part of that but also hide the application that you're running because the proofs themselves of those of those state transitions are no longer public here um and at the end all you have is this outer snark proof which is what you actually bundle in your transaction and publish on chain

for people and does is it that that ends up in the proof of succinct work exactly so that's the actual okay that's the connection then so this is the connection between sexy and the proof of succinct work this has remained a complete mystery to me until now this is awesome cool so those transactions actually form the leaf of the merkle tree um that is then passed in for the actual proof of succinct work to check and base base itself on okay it's basically like all of these snarks and and with different purposes happening in parallel i guess and then those are in a way compressed but also made private through this outer snark and i know you just said it but i can't

remember exactly how you just said it it's like the leaf of this wait this becomes this is part of the leaf of the merkle tree that's then proven by the snark in the consensus mechanism itself right so that's the useful work effectively we've been we've been reasoning over a number of different design constraints for proof of succinct work and it's in part because we need it to be really performant so to actually come up with a performant uh system for previous succinct work it doesn't really make sense frankly to actually build a sustained blockchain there and one of the design approaches we have right now is to construct a small merkle tree that actually checks the state of of multiple sub-trees

and these sub-trees themselves include for example the transactions in them and so because of that we actually have a way to then checkpoint state with this and this checkpointing is what serves as a proof of inclusion we've been evaluating a few other designs that are effectively recursive to allow us to then extend this even further and also to bake an additional hardness on it we think that there's there's you know we think that there's a lot of interesting work that's happening right now within like the plonk and the pluck-up space and it's something that we've also been evaluating specifically for consensus here um to add that into this this model i think i've never heard that pronounced out loud did you just call it the plookup space yeah that's how they yeah i call it flick up is that right

is that right they do say pluck up as well so we've we've covered that you're building a new layer one i'm curious to hear how uh is this a fork of bitcoin like zcash has been doing or is it you know everything new from scratch networking the whole shebang um so in part i'm curious to hear how how are you actually building this blockchain but i also want to dig into everything else that's needed to actually make this work and what are you building there but let's start on the blocks blockchain side yeah um you know when we first got started we

really wanted to use something off the shelf that already existed and we started looking at different different uh blockchain implementations one of the things that we really had to to account for was the fact that this this layer one was going to be private by default and so because of that many of the architectures immediately were thrown out of the window but then the second thing was that because zexi itself is assuming a utxo ledger um you know there's also no compatibility with um you know smart contract-based platforms and so we had to throw those out and at the at the end of the day there was basically you know one or two implementations that we could actually try basing ourselves off of and and the main one that we were looking at was z cash's implementation zcash foundation has been working on an

implementation of zcash called zebra and um you know that that was one that we thought actually had had a lot of potential um unfortunately just given our timing it was a it was very early on uh in in zebra's development and so because of that we ended up just going for our own model and we ended up building this thing from scratch the repo now is called snark os and it's on github you can find it under github.com heliohq snarkos and um it's written in rust um there's a lot of modules in it it includes zaxy in it and also proof of succinct work and and it's it's not battle tested yet um you know we've been we've been running uh and we just started up test net one and

and as part of that it's a trusted test net that's designed to one actually battle test the actual system um income in conjunction with audits um but secondly is also just to let people actually try using it and try building on it deploying things to it um and seeing how it works how many uh engineers do you have on that because it's still quite a feat to be able to build that in a year yeah so there's four folks on the team myself included who've been working on the implementation of snark os for the past year but we've also gotten some really good extra help from georgios constantopolos and also kobe girkin who have been contractors working with us on that initiative and you know they've been helping instrument proof of succinct work as well as uh uh with with aki's who's

been architecting it from from the theory side um you know right now we're in an implementation that we think is good enough for getting ourselves to test net but we think we still have a really long road ahead to get to actual main net and so um you know the course of of test net one is effectively to start battle testing it starts stress testing to start actually uh poking at it and seeing what breaks and also just letting users try it so let's let's keep going into you know outside of just the blockchain to you know make this system work to build something that's actually usable here you obviously need a ton of different things i mean when we talk to others in the space they have programming languages or ides

or various tooling to be able to prove in browsers or or whatnot like what other things outside of just the blockchain are you building yeah well first off i would say the application programming model is something that we've spent a lot of time fleshing out um when we first wrote xe one of the things that we alluded to was this idea of being able to do private smart contracts and we gave three examples uh in there um but you know as you as you can imagine uh that was myself and patricia and the others hand wiring these circuits uh in code uh to actually come up with that model and it's certainly one that i wouldn't expect you know average developers to actually do themselves uh

it requires a lot of cryptography knowledge it requires also a lot of careful hand-holding and and and just a lot of hope um and it's something that that doesn't scale so um you know as part of that we've spent a lot of time thinking about how to design you know these types of private programs correctly and uh when we first got started we we started evaluating the different dsls that are that are out there today you know everything from socrates to xj snark to snarky you know recently there's zinc and one of the things that that we found in in evaluating these was that there wasn't a really good kind of developer tooling built with it and what i mean by that was it wasn't

possible to write unit tests or integration tests and more so there wasn't really convenient functions to be able to actually get out the type of information you want when you're when you're compiling that circuit so if you wanted to see at what stage you were at or or you know what the actual representation of the circuit looked like there wasn't good serialization tools for us to actually evaluate and make sure that these circuits themselves were were standing up to the to to what we expected them to be um and so and and so as we were doing that what we decided to do was actually to just fork one of these dsls and build leo on top of that and so we ended up choosing socrates in part because of its maturity it's been around for a very long time but also just because of its

architecture we particularly like the design on how they constructed asts here and uh more so how the compiler actually reasoned about every step um it was well designed for doing you know optimizations and um one of the the things that you know with any with any engineer they'll have opinions on his syntax and so we ended up changing the syntax a bit um but uh other than that the foundations really did extend off of socrates and um you know since then i think we've evolved it to a point where it's it's almost unrecognizable from its from its original starting point um you know with leo the objective has been to build a programming language that is intuitive and simple to write we really wanted leo to look and feel just like a traditional programming

language and and the goal here was really for you know the the normal web developer to be able to write private applications without having to reason about low-level cryptography you know under the hood leo is is quite complex and that it's abstracting low-level concepts and making it really easy to integrate private applications into higher level stacks so the language ended up becoming something that looked far closer to javascript than it did to something like assembly and um even then like you know for something like javascript we found that that the design space for it for it was actually quite well suited for for circuits here um the reasoning is that javascript itself is actually designed in one environment and ran in

another and what i mean is that you write javascript with the intention of seeing its output in a console but in reality its code actually is running to manipulate a dom that is being shown on your interface and from that perspective the coder is actually thinking about two different models when they're writing one one program and we found that that was quite analogous to the model that we have here with circuits where you know users are actually writing circuits to be generated and output and run within a proof system but in reality when they're interacting with it to write tests and also and also to even just debug it you know they're really looking at a console here and and so because of that we realized that this type of syntax that javascript already

came with was was one that was actually quite uh quite adaptable to the model that we were looking at are you at all worried though like solidity also is really easy but has a lot of kind of issues because of ease of use there's also chance for a lot of kind of misinterpretations are you at all worried about that with leo or i guess you know that like i'm curious if you how how deeply you learned that lesson from seeing it happen i am incredibly worried about this and okay all i can say is that we think very hard about this before before committing to a design and leo is still not in a final stage the whole point on developer preview one actually is to

get the language out there is to get the the technologies been working on out there so that we can get feedback i'm a huge believer in in getting open feedback and iterating quickly in part because you want good ideas to persist and you want bad ideas to die quickly so for us the objective has been to get feedback from people and to hear their input and also to see like what works what doesn't what sticks and what doesn't it's far easier to get that now than after you've baked the cake and we've certainly seen you know with a lot of blockchains that it's really hard to change it and it's really hard to go back once you actually have it on mainnet you just mentioned developer preview one what is that developer preview one is the first release that we've made

since coming out of stealth so for elio developer preview one is meant to be an opportunity for people to one see what we've been working on but then two to also try this type of experience that we've been we've been thinking about the goal here is to provide an intuitive experience for writing private applications and we've been building out a few different pieces of technology the first is leo which i've just talked about but also you know secondly we've been working on a package manager for leo so the idea is that in order for leo to really kind of take off in our opinion we think that it's really important for the right people to be writing circuits and for those those implementations of circuits

to actually propagate across an ecosystem for example if you're the implementers of openssl you should be able to write an implementation of that that you can then then put out there for other people to import into a package when they're writing their applications it shouldn't be that every user has to go and re-implement for example you know shot 256 from scratch whenever they want to write a program and they also shouldn't have to go to github search for for a file that that has an implementation of it and copy paste it into their repo in order for that to happen um you know i think that's a very common notion within traditional programming languages to have package managers but within the blockchain ecosystem specifically with with ethereum and solidity um it's not so common and because of that we have

you know 20 000 copies of safe math on chain and um i think that in general it's it's it's not not a great design and it's also something that we think you know should be standardized cool the last piece that we've released is is a product called aliastudio and the idea here was to jumpstart the development cycle for for developers in dp1 the goal of ali studio itself is to be an ide to make writing zero knowledge applications easy um and at its core alias studio itself um has leo baked in so that you don't have to go and install some separate thing you just have to download the software open it up and start writing your code but the second thing is also that it's it's integrated with um the package manager so by doing that

it makes it really easy for you to import and also the publishing packages um but it's also really easy for you to then collaborate with others so one of the features that we're currently fleshing out is this ability to support teams and organizations so that you can actually work across device with other with other people whether it be friends or colleagues on applications so unfortunately it's about time to wrap up but as a ending i suppose um i usually like to ask and talk about what's coming up next uh so you're at this point of developer preview one and your your first test net started working on some language some of the tooling what's up next like where are you going from here and what are you looking

forward to so in terms of the horizon we're currently preparing for running a trusted setup ceremony for marlin marlin is a universal snark and updatable snark that we're using for programs on elio but also for the proof of succinct work circuit as well and uh over the coming months uh you know we are going to be building out the infrastructure and tooling to actually run our setup here so we'll be we'll be building out the tooling and infrastructure for it and uh keep an eye out on our channels yes indeed that's a good plan for everyone so howard thank you so much for coming back on the show thank you for having me on and uh really look forward to coming back yeah thank you very much

and to our listeners thanks for listening thanks for listening you