Anna (00:07): Welcome to zero 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, Frederik. Anna (00:28): This week, we catch up with Howard Wu and learn about his new project Aleo, which is built around the ZEXE ZK construction. But before we start in, I want to say thank you to this week's sponsor Least Authority. Least authority it's 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 2.0 specification protocol labs, gossip, sub protocol, Z caches, sapling upgrade,Teslas foundations, TZ, BTC, block stacks, investor wallet, Metta masks, lava moat, and more. Anna (01:17): 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 least authority.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. Anna: We have today on the call, Howard, how are you doing Howard? Howard (02:03): I'm good. And thank you for having me on. Anna (02:06): 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 Aleo. And actually just as a side note, I've actually been freelancing with Aleo. I've been working on a very specific thing and I don't know that much about all of the other parts of Aleo. So this is a chance for me to also explore this project a little bit deeper. Howard (02:49): Yeah. I'm pretty excited to talk about this. And I'm also really glad that we're finally public. It's been about a year of work that we've been working on in stealth and you know, in the past 48 hours, since coming public, I've been getting a number of, of emails and also messages from people, there's now a developer preview that we've put online and people have started filing bugs and also joining our discord to give us messages there. And it's been, it's just been a very exciting time. Fredrik (03:21): Cool. Maybe to set the background a little bit, I know very little about this project other than the public announcement. 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 inspiration that made you kick this off? Howard (03:40): 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 that the model on the web is very much about providing free services in exchange for personal data. And, you know, one of the things that I really want is just to be able to use my apps and piece 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, and actually enforced that. And so, you know, in building Aleo, my goal has really been to build web services that can, that can become truly personal living in places more than just your browser and also provide an experience that is really tailored for you, where you still have control over your information. Anna (04:27): In the previous episode we had you on, I think we would have done 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? Howard (04:58): I think the number of experiences 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 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 wanted over the past few years is this ability to have a private and programmable applications, which hasn't been possible thus far. And that was also why, you know, we worked on ZEXE. We looked at the ecosystem and realized, you know, there's kind of two axes. You can really evaluate a crypto on and it's one is on programmability and the other is on privacy. And you know, Bitcoin is rather low on both. Ethereum goes one direction to offer high programmability and Z cash goes the other direction, offer high privacy. Howard (05:43): But 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? You know, I've wanted to see applications like this you know, for many now. And, and that was ZEXE was born. We ended up publishing that as a paper about well, actually it was, it just debuted this year. And, and we published the code last year for people to start trying it and using it. You know, since then the reception has been quite strong and positive. People have been really interested in, you know, applications like using decentralized dark pools or mixers for it. And this is an area that I think, you know, Ethereum has a lot going for it, but it doesn't have the foundation to actually support these types of applications. And it's something that for me, you know, I've wanted to see out there and it's something that we've been, then tinkering with and trying to make possible. Anna (06:41): 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 my, Howard (07:00): I definitely did not plan on doing this. Certainly my role as a VC, we tried finding teams to commercialize ZEXE. And 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 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 we found was really difficult and after, you know, a year or so of, of this swell, Matt and Ian were the ones who actually really were asking me about commercializing it myself. And you know, after much thought and discussion, I said, why don't we see if we can assemble a team? Howard (07:48): And somewhere around middle of last year, towards the end of the year we realized that we could, and we said, why don't we give it a shot? And you know, that was how Aleo was born. Frederik: Cool. So, like Anna mentioned earlier, we had a, an episode with Patricia about ZEXE in particular, and we'll link that I'm curious in part also like what your involvement on ZEXE has been, but also again, do a recap of what ZEXE is, as you mentioned, it's in this cross between private and programmable, but how does it actually achieve that? Howard: Yeah, so at its core ZEXE which stands for zero knowledge executions. Is a decentralized private computation protocol. The idea is that we're using a zero knowledge proofs to enable private applications in a recursive manner. The high level of ZEXE is that there's really two things that we really wanted to achieve with it. Howard (08:51): The first one was to offer full privacy for applications. And what we mean by that is that, we delineate in the paper, two levels of privacy. One is a data privacy, and the second is functional privacy and 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 ERC 20 transfer, we don't even know the fact that you were using this specific ERC 20 token or even, and the ERC 20 contract at all. And so that's the, that's the conceptual idea on functional privacy here. Howard (09:40): 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 applications. So on Ethereum, because there is roughly ten 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 proofs on chain. 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. Anna (10:44): 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 Z cash 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? Howard (11:12): Yeah. So when, I mean, recursion, actually there's different types. So in terms of recursion the approach that we took in ZEXE was to have a recursion of depth too. And so it was a fixed step recursion. There's also a lineage of recursion 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. And in our case, the motivation for having this recursion is specifically for privacy for every transaction. So 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 in order for that to be published. And so that the application data itself isn't visible, this approach lets us achieve that level of functional privacy because the application proofs themselves are actually checked within an outer proof. Anna (12:11): But is that recursion? You say it's only level two, this, like, is that how you described it? I've heard that just said a few different ways, like curse a depth to that too. Yeah. Layer two. Okay. But 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? Fredrik (12:32): Yeah, that's definitely another added benefit is that by checking multiple proofs here within one single invocation, you actually compress the transaction so that you can bundle it in our case. In the example in ZEXE is a two and two out that you can actually compress those four proofs into just one proof. And because of that, you actually save space you know, as an added benefit. Fredrik: But the main purpose is functional privacy, right? It's not like you're not doing it because of compression. Howard: Yeah. It comes as a side effect for free. And it's certainly nicer to be more efficient also in space. Fredrik: And I would encourage anyone who really wants to dig in deep on how Z works to just listen to the episode with British wary explains the birth scripts and death scripts and how all this works. Fredrik (13:23): Something that we touched on in that episode though, is the ergonomics of programming in ZEXE, 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 set up for each new type of application. Like the programming model is very different from a thorium. So you need to rejigger how you think about smart contract is 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 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 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? Howard (14:17): Yeah. So in terms of the developer experience for writing applications in the ZEXE model, it's something that I think can certainly be improved upon the way that we architected ZEXE was to allow for any type of music here to be used for applications. And you know, this could be anything from like graft 16, like SNARKs up to a universal SNARKs but also you can use, you know, like bulletproofs or Starks. And this model is meant to be general for different types of primitives. In our case, you know, the proof System that we are actually using for Leo is Marlin. And the rationale for that was to design A system for applications where developers don't have to run a trusted setup for every app. It would be a huge barrier to entry in my opinion. And it also just be a huge pain for developers to have to reason about. And so from 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 provided three examples for. So the first one was a, you know, private custom assets. The second was a private stable coins, which are things that allow you to attach policies to them. And then the third was a private decks and we gave two different variants in the paper for that. And you know, these are applications that we think, you know, in crypto are already kind of widely adopted or widely accepted. And we wanted to show what the privacy preserving variant of those could be. 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 performance. And you know, that's an area that we think is also very exciting. Anna(16:06): So I think at this stage, you know, we've refreshed a little bit, this, the story of ZEXE 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 Aleo and actually introduce Aleo maybe a little bit more now. So what is Aleo? What is this company? What is it doing? Howard (16:30): So the idea for Aleo 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 past few years, one of the things that I've grown to care deeply about is this ability to own your data and for information to be private. I think one of the really cool things that zero knowledge proofs enables is disability 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 ideas, specially with respect to the web on, you know, how you can provide user experiences that are truly private 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 this is a model that I think is really underexplored, especially in the context of the web today. You know, the web itself has a model that requires users to kind of exchange their personal data for free services. And I think that this model, not only this is antiquated, but it's also really incentive incompatible for the user and for the provider. I think that there are far more clever models that people are starting to realize and also reason about. And you know, for me, it's something that I find very interesting and fascinating to explore. Anna (17:54): What was your experience at, like at decrypt you worked at, as 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. Howard (18:14): 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 Aleo to address a lot of the shortcomings in crypto. 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 you know, one of the areas that I really wanted to hit with Aleo was just solving for the web. Like the web is a phenomenal place. It's a place that really connects us and allows us, especially during a time of COVID to actually stay in touch with each other. Howard (18:58): But at the same time, we know that freedom on the web is going down, that censorship is going up. And just the quality of experience of the web itself is degrading. You know, there's this fake news, there's all these different advertising platforms that are taking over this. There's a lot of spam that's being pushed to users. And we see it on our devices every day. It's a fundamental user experience that I think could be far better. And I think that the business model of the web itself could even be completely changed. And, I think we have a real shot at making the web a better place. And, Aleo is designed to actually provide a type of experience and, zero knowledge itself is a phenomenal technology for enabling that. We don't have this notion of private web data today. Howard (19:40): And everything is starting to become a public commodity. If you look at your household, there's just devices everywhere now, 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, it's not something that we want, or it's not something that we intended to build for. And, I think that being able to separate public web data from private web data is an important thing, specially for this next decade. The internet is going to become pervasive. It's going to become incredibly personal. And I think that if we don't actually go for building the platform that allows private applications 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, a technology that actually can enable this in the right way. Howard (20:33): I think that you know, it's a value proposition that should be open source. It should be permission, listen, and we should allow, allow anyone to, 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. Anna: When you talk about this, like, so, 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? Howard: Well, first off I think the web is a really cool place and it doesn't make sense to try to replace it. 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. Howard (21:13): 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. So the purpose here is really to provide an experience for users where, these types of services really live on the client side. And instead of having to send your data over to the server, you actually can just get transparent algorithms from the server and run it on the client side, for both sides, there there's certainly benefits, from the, from the user's perspective, there are no longer forced to give up their data in exchange for services that they want at the cost of their personal privacy, but also fo the provider, 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 one that really allows the users and providers to be incentive aligned because they're no longer in this game where reputationally, the providers taking on all the risks for the user and the user is forced to give up all of their information in exchange for that service. Fredrik (22:20): It is obviously common complaints, specially in the blockchain world of, you know, 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. While 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 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 provider. Howard: So in terms of, business models, I personally think that, first off that model remains cohesive in this new architecture. But at the same time, I think what this provides is more choice for users, 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 micropayments and having the ability to actually charge from a resource perspective is quite difficult right now. And as we explore the different types of assets that now exist with encrypto, I think it's starting to show that there is more forms of payments than merely just money on its own, that services and assets themselves more broadly can be used it in exchange for other things. Howard (24:43): And 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 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 user data, I have no issues with that. What I really find issue with is, is when they don't tell, tell that to you upfront, or an end transparently, I think thus far today, we don't really have good technologies to go in and force that they're using your data responsibly. And once your data is in their hands, there's no take backs. So it's very hard for us to control it. And because of that, we don't really have the power here. Howard (25:27): And so what this model really is trying to do is to open up the, the types of options or opportunities that both users and providers 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 and have 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 have. Anna (26:00): I wonder, like the thing is sound like some of these topics, this idea of like privacy and, 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 Aleo lineup, when you think of projects like Aztec or Matter, or Findora or Coda, these are sort of varied, zero knowledge focused projects, where do you position Aleo when you compare it to them? Howard (26:25): 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 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 Ethereum, without privacy, applications like smart contract mixers or dark pools can't fully protect user activity. It just doesn't work. And for companies who actually want that and want the skill associated with off chain computations, there is no good combination for that today. That's where, we've certainly thought about building this 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 Aleo on a layer one that isn't private by default. Anna (27:25): Hm. So I think we've defined philosophically what Aleo is and what it aims to do, but what is Aleo? What is it like, what are the pieces of this project? Howard (27:37): So, Aleo is a platform that is decentralized. It has a blockchain, and it uses blockchain to verify and store proofs. These proofs are effectively ZEXE transactions. And the architecture that we went for was something that was Bitcoin, like, so, in ZEXE, we talk about a ledger and we adhere to what looks like a UTX. So model here and for consensus, we've been developing something that is very much a SNARK friendly. So one of my personal goals, which is less about the web, is this ability to have a zero knowledge proofs in kind of mainstream audiences. And one of the biggest barriers to getting there today is this ability to perform in the compute zero knowledge proofs. I don't have a hardware background myself and neither do the people on our team. But what we do have is the ability to design incentives and incentive mechanisms. Howard (28:31): And, you know, what we decided was to build a consensus algorithm that adhere to the same type of cryptographic stack as the applications that would live on ALeo and use that to basically incentivize miners, to develop hardware acceleration for SNARKs. I think that the ability to have really performance SNARKs is really cool, but it's also one that we've seen even from the traditional computing industry from many decades ago. If you look at many of the cryptographic algorithms that are commonplace today, for example, for HTTPS, those types of operations under the hood are really slow in software, relatively speaking. And it wasn't until, companies like Intel started adding these cryptographic units into every CPU that's shipped that these algorithms actually became performing. And because of that, if we almost take HTTPS for granted today, but these types of technologies, required real hardware to be baked into every chip for every device in the world in order to be practical for use. And I think that we're in a very similar story here. And the hope is that we can bring verifiable computations and, and the goal is, to bring verifiable computations to mainstream audiences. Anna (29:48): And this idea where the consensus of 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 an earn from it, that process is actually useful throughout the rest of the system. Howard (30:06): Yeah. I guess the best way to talk about it is, so the consensus algorithm that we've been working on is called proof of a succinct work, and it's based on proof of necessary work with hockey's. Anna (30:20): We've had on the show a few weeks ago and I'll add to that as well. Howard (30:24): So the idea for us has been, instead of going down the path of a succinct blockchain we've been more interested in using Aleo for interoperability and also for, for building efficient light clients. And 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 it 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 very convenient way for, a smart contract on another system to verify that a transaction was actually included in block 58 on Aleo by just verifying a proof. So this model is very nice for interrupt, but 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 check very quickly that these transactions really were included in a specific block without having to process them individually from Genesis again. Fredrik: That's interesting. So it's sort of, it's proof of work where the work is generating proves that the transactions are in the block. Yeah. Howard: 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 two, five, six, 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 by doing that and creating that incentive you know, application developers on Aleo can actually run their applications on ideally various service providers who happen to now have the choice of saying if market demand says that, 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, 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 be useful for companies like mater or for Aztec, where they are building validators for roll-ups. And these role of validators themselves are designed to be very performant for computing's. You're gonna watch proofs. 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 Aleo. And this gives an ability for validators there to actually have some constant, or more stable type of revenue. Anna (33:08): 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? Howard (33:28): So the circuit itself is effectively a small Merkle tree, and this Merkle tree is meant to represent, the state of this block. So by performing this type of work well, for one, 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, 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. Fredrik (34:10): Is there also a proof that I'm on the correct chain? talking about light clients. Howard (34:16): 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. And it's also one that's, more fundamentally just a question on consensus on what is the most common or what is the right state? Fredrik (34:36): Yeah. So back to Anna's question, I guess, to keep talking about like clients, you know, normally I like clients syncs the whole header chain to know that they're in the right place. And then they go, I want to know either some States 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 while 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 Merkel proof that it is here. So what you're doing is because you have this proof of work 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 apply with the snark, with the smart proof saying, here's the proof that it is. Howard (35:38): Yeah. It ends up being a proof of inclusion for that transaction. And it's something that is even composable. So for example, if you really wanted to give a proof that not only was this transaction included in this blog, but it was included in this block that now has six confirmations. What you could do is actually take six of those proofs in those blocks. And actually then recursively come up with one new proof 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 and say to a smart contract to go and check there. Just one proof that instead of six and by doing it this way it, it's far more efficient for actually doing interoperability. But it's also a really nice way for light planes to just quickly validate, Oh, like if I really want this transaction and know and want to know that this thing really was included on this ledger at this, at this block, they can. Fredrik (36:35): A question for me immediately is do light clients still just sync the header chain or, I mean, it feels like it would make sense for them to sink the header chain and all of the proofs, like depending on how large the proofs are, but like the difference between a light 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 sync all of the proofs, then you still don't have to re execute the transactions. So you can just verify the proof. Howard (37:07): Yeah. I mean, in this model, because the VM doesn't live on chain there, there is actually never even execution for the full nodes themselves. Everyone on Aleo just has to verify proofs and these proofs will ensure that the transactions themselves are valid state transitions. Fredrik (37:27): Yeah. So you're, you're almost collapsing the roles like an client and a full note is basically the same thing. I mean, you could construct a lighter light client that doesn't have all of the data or something, that is selective and amount of downloads, but it's more or less the same thing. Howard (37:44): Yeah. The idea really is to make it crypto economically well incentivized to, the idea being that on a theory come today for a minor, they, they have to reason over whether to spend their cycles checking a transaction or trying to mind 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. I think that from that perspective, it's also a, far more efficient, you know, quote unquote gas wise because everyone gets an only needs the same amount of time per transaction to be rezoned on in order for that transaction to be included in a block. In this case, we're talking constant times of, you know, somewhere around three milliseconds then, and because of that, no one needs any more time than that. So it's a really nice benefit to have in this architecture. Anna: Is like, I know that there's, I know the ZEXE, The ZEXE curve, the ZEXE concept has also been implemented in PLUMO this a light client on the Celo construction. Is there any relationship to that? Is it, is it similar? Howard (38:46): Yeah. So the Celo folks are using those ZEXE curves. They aren't using the ZEXE transaction model and more so the curves 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 state of, of every round for their blocks. And so in that model, they are using BLS 12, three 77. And, and to my knowledge, they are exploring using BW six for then doing a block compression like techniques. Anna (39:16): But I guess in yours, it's different because this light client could almost be this main may notice at the same time, like we're Frederick saying that they're kind of merging of roles in their case. They have a more traditional blockchain where they're using this ZEXE curve for purely the light guy. Howard (39:32): Like the difference I would say is that for transactions here on the other, they are actual is ZEXE transactions. And so because of that, every execution is private and every execution comes with zero knowledge proof in the Celo model to my understanding it's effectively a fork of death where transactions adhere to the smart contract and Ethereum model. And rather for validators, they are now, 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, your block history is correct, and that you're actually sinked to the right block as the latest block. Fredrik: Yeah. That is the point of this yellow profess 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 of tax and basically say, this is the chain that it's supposed to be. And then you have these intermittent proves that you just sink those proofs rather than sinking the whole header chain. So it's just a faster way to sync a like lines rather than providing any privacy or any like other thing it's just faster sinking. Yeah. Anna (40:52): 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 ZEXE curve itself, did it have a variety of different Snarks in it acting at the same time? Howard (41:06): Yeah. So in ZEXE, we have a few circuits and these circuits are used to make attestations of validity for different statements. For example, there's the inner snark here where the inner snark is responsible. One with checking that a transaction is actually based on correct ledger state. So the way that a ZEXE transaction works at 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 the ledger digest and checking that when we're spending a record, that its corresponding commitment actually lies in that Merkle tree with the outer snark it does something a little bit different. Howard (42:01): So the outer snark is the circuit here that is actually one checking the inner circuits proof. But then two, it's also checking the input at the, the death programs and the birth programs, the proofs. So for every transaction, you're reasoning over, spending some records and birthing some new records. And with each of those, it's basically an application runtime where you are composing a new proof for each of those. In this model the outer snark can check for example, for proofs are two into out and 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. And at the end, all you have is this outer smart proof, which is what you actually bundle in your transaction and publish on chain for people. Anna (42:52): And does, is it that, that ends up in the proof of succinct work? Howard (42:56): Exactly. So that's the actual... Anna (42:59): That's the connection then? So this is the connection between ZEXE and the proof of succinct work. This has remained a complete mystery to me until now. This is awesome. Cool. Howard (43:08): So those transactions actually form the leaf of the Merkle tree that is then passed in for the actual proof of succinct work, to check and base itself on. Anna (43:18): Okay. It's basically like all of these Snarks 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, but this becomes, this is part of the leaf of the Merkle tree. That's then proven by the snark in the consensus mechanism itself. Howard: Right? So… Anna: that's the useful work Howard (43:49): Effectively. 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 performance. So to actually come up with a performance system for prove as the sync work, it doesn't really make sense, frankly, to actually build a succinct 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 multiple sub trees and the sub trees themselves. I include for example, the transactions in them. And so because of that, we actually have a way to then check point state with this. And this checkpointing is what serves as a proof of inclusion. We've been a few other designs that are effectively recursive to allow us to then extend this even further and also to bake in additional hardness on it. We think that there's a lot of interesting work that's happening right now within like the plunk and the plookup space. And it's something that we've also been evaluating specifically for consensus here to, to add that into this model. Anna: I think I've never heard that pronounced out loud. You just call it the plookup. Fredrik (44:57): Yeah. That's how they say Howard (44:59): Yeah, I´ve called it Plookup. Is that right? Fredrik (45:02): Well, I mean, that's a new type of Gates and yeah, I, they do say look up as well. So we've covered that you're building a new layer one. I'm curious to hear how is this a fork of Bitcoin like Zcash has been doing or is it, you know, everything new from scratch, networking, the whole shebang? 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. Howard (45:40): Yeah. When we first got started, we really wanted to use something off the shelf that already existed. And we started looking at different blockchain implementations. One of the things that we really had to account for was the fact that 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 ZEXE itself is assuming a UTX, so ledger you know, there's also no compatibility with smart contract based platforms. And so we had to throw those out. And at the end of the day, there was basically, 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 Cassius implementation, Z cash foundation has been working on an implementation of Z cash called Zebra. Howard (46:29): And you know, that, that was one that we thought actually had a lot of potential. Unfortunately just given our timing, it was very early on in Zebras 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 snarkOS, and it's on get hub. You can find it under a github.com/AleoHQ/snarkOS and it's written in rust. There's a lot of modules in it. It includes SEXE in it and also proof of succinct work and, and it's not battle tested yet. You know, we've been running and we just started up test net one. And, as part of that, it's a trusted test net. That's designed to one actually battle test the actual system income in conjunction with audits. But secondly is also just let people actually try using it and try building on it deploying things to it and seeing how it works. Fredrik (47:25): How many engineers you have on that, because it's still quite a feat to be able to build that in a year. Howard (47:30): Yeah. So there's four folks on the team, myself included. Who've been working on the implementation of snarkOS for the past a year, but we've also gotten some really good extra help from Georgios Konstantopoulos and also Kobi Gurken 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 with Akis, who's been architecting it from, from the theory side. Right now we're in an implementation that we think is good enough for getting ourselves to tests net, but we think we still have a really long road ahead to get to actual maintenance. And so, the course of, of testing one is effectively to start battle testing it, to start stress testing, to start actually poking at it and seeing what breaks and also just letting users try it. Fredrik (48:18): So let's, let's keep going into, you know, outside of just the blockchain to make this system work, to build something that's actually usable here, you obviously need a ton of different things. I mean, when we talked to others in the space, they have programming languages or IDs or various tooling to be able to prove and browsers or whatnot. Like what other things outside of just the blockchain are you building? Howard (48:45): Yeah. Well, first off, I'd say the application programming model is something that we've spent a lot of time fleshing out. When we first wrote ZEXE, one of the things that we alluded to was this idea of being able to do private smart contracts, and we gave three examples in there. But as you can imagine that was myself and Patricia and the others hand wiring these circuits in code 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. So it requires a lot of cryptography knowledge. It requires also a lot of careful handholding and and just a lot of hope. And it's something that doesn't scale. So you know, as part of that, we've spent a lot of time thinking about how to design these types of private programs correctly. Howard (49:33): And when we first got started, we started evaluating the different DSLs that are out there today and everything from Zocrates to snarky, recently the zinc. And one of the things 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 compiling that circuit. So if you want it to see you at what stage you were at, or 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 standing up to the, to what we expected them to be. Howard (50:24): 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 liked the design on how they constructed ASTs here and more so how the compiler actually reasoned about every step. It was well designed for doing, you know, optimizations. And one of the things that, with any engineer they'll have opinions on this syntax. And so we ended up changing the syntax of it. But other than that, the foundations really did extend off of Socrates. And since then, I think we've evolved it to a point where it's almost unrecognizable from its original starting point. Howard (51:12): 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 the goal here was really for, the normal web developer to be able to write private applications without having to reason about low-level cryptography, under the hood, Leo 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 even then like, you know, for something like JavaScript, we found that, that the design space for, for it was actually quite well suited for four circuits here. The reasoning is that JavaScript itself is actually designed in one environment and ran in another. Howard (52:05): And what I mean is that you write Java script with the intention of seeing its output in a console, but in reality, it's 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 program. And we found that that was quite analogous to the model that we have here with circuits, where users are actually writing circuits to be generated and an output and run within a proof system. But in reality, when they're interacting with it to write tests and also to even just debug it, you know, they're really looking at a console here. And so because of that, we realized that this type of syntax that JavaScript already came with was one that was actually quite adaptable to the model that we were looking at. Anna (52:51): Aren’t you worried though, like solidity also is really easy, but has a lot of kind of issues because of its 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 deeply you learned that lesson from seeing it happen? Howard (53:12): I am incredibly worried about this. And 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 on developer preview one actually is to get the language out there is to get the technologies we've been working on out there so that we can get feedback. I'm a huge believer in getting open feedback and iterating quickly in part, because you want good ideas to persist and you want that ideas to die quickly. So for us the objective has been to get feedback from people 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 maintenance. Anna: You just mentioned developer preview one. What is that? Howard: Developer preview One is the first release that we've made since coming out of stealth. So for Aleo, a developer preview one is meant to be an opportunity for people to one, see what we've been working on, but then to also try this type of experience that 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 surrogates to actually propagate across an ecosystem. For example, if you're the implementers of open SSL you should be able to write an implementation of 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 reimplement, for example, you know, shot two, five, six from scratch whenever they want to write a program. And they also shouldn't have to go to github search for a file that has an implementation of it and copy paste it into their Rebo in order for that to happen. You know, I think that's a very common notion within traditional programming languages is to have package managers, but within the blockchain ecosystem, specifically with Ethereum and solidity it's not so common. Howard (55:35): And because of that, we have, you know, 20,000 copies of safe math on Shane. And I think that in general, it's not a great design and it's also something that we think should be standardized. Anna: Cool. Howard: The last piece that we've released is a product called Aleo Studio. And the idea here was to jumpstart the development cycle for four developers in DP. The goal of Aleo Studio itself is to be an IDE to make writings your knowledge applications easy and at its core, either studio itself 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 a code. But the second thing is also that it's, it's integrated with the package manager. So by doing that, it makes it really easy for you to import and also to publish new packages. Howard (56:24): 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 cross-device with other people, whether it be friends or colleagues on applications. Fredrik: So unfortunately it's about time to wrap up, but as a ending note suppose I usually like to ask and talk about what's coming up next. So you're at this point of developer preview one and your, your first testnet 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? Howard: So in terms of the horizon, we're currently preparing for running a trusted set up ceremony for Marlin. Marlin is a universal snark and updatable snark that we're using for programs on Aleo, but also for the proof of succinct work circuit as well. And over the coming months, we are going to be building out to the infrastructure and tooling to actually run our set up here. We'll be building out the tooling and infrastructure for it and keep an eye on our channels. Anna (57:34): Yes, Indeed. That's a good plan for everyone. So, Howard, thank you so much for coming back on the show. Howard: Thank you for having me on and really look forward to coming back. Fredrik: Yeah. Thank you very much. And to our listeners. Thanks for listening. Anna: Thanks for listening.