zkSummit6: Programmable Zero Knowledge: Introducing Aleo – Howard Wu – Aleo

Transcript

[Music] okay so next up we have howard wu speaking all about elio hi everyone my name is howard wu i'm a co-founder of elio a platform for fully private applications i wanted to start by thanking anna for hosting the xero knowledge summit and the sponsors for making this event possible in this talk i'm i'd like to explain the concept of alio where the technology stands today what it enables and how to get involved as a developer and or cryptographer

so to get started i thought i could share a bit about my background in blockchains and and the zk ecosystem and frame the notable accomplishments and shortcomings of the space my journey began like so many in bitcoin for myself i was into computers as a at an early age and during my high school years i came across bitcoin just as it was getting started and while i had little experience with the technology at the time i did have a fascination for the mission the incentives and the value propositions of the cryptocurrency and like so many i began mining bitcoin

in order to support the effort fast forwarded 2014 and the concept of a decentralized world computer began picking up steam and i found myself shifting my interest from pursuing endeavors like bitcoin scripting to programming on blockchains like ethereum unlike bitcoin ethereum offered a far better developer experience and allowed programmers to write financial logic to dictate how cryptocurrencies were transferred and it was around this time that i was in university now and began pursuing research in cryptography under two professors one was professor alessandra chiesa who himself is a co-founder of zcash

and also don song who is the co-founder of oasis labs along with several others many in alessandra's lab we saw the work of zero knowledge proofs uh mature into the genesis of zcash a fully private cryptocurrency and unlike bitcoin zcash offered privacy for payments and spurred the awareness of on-chain privacy as a concept you know unbeknownst to most of us at the time the implications of this work um continues to have long-standing implications for how and where cryptocurrencies can be adopted and used so about three years ago a few of us

began evaluating the blockchain landscape along two dimensions notably programmability and privacy we realized that bitcoin offered low programmability and low privacy um ethereum extended bitcoin in one direction to offer high programmability and zcash went the other direction to offer high privacy however there was an upper right hand quadrant of high programmability and high privacy that remained missing in the landscape and we decided to tackle that with a protocol that we developed called sexy we designed and published sexy which stands for zero knowledge

executions um as a protocol for decentralized private computations and it's a cryptographic protocol that enables both privacy like zcash and programmability like ethereum sexy is a ledger based system that allows users to execute offline computations and produce publicly verifiable transactions on chain which attest to the validity of those offline executions zexi's two-part architecture um introduces the split between off chain and on-chain verification and every application using zaxy goes through both on and off chain

phases you know in the case of a of an application that's being submitted on chain uh miners on chain act as verifiers that serve to um validate the actions of the application um and to ensure that they are truthful by having the verifier on chain we allow the network to process a large number of transactions quickly without hitting bottlenecks not only does this allow for high throughput with lots of applications running simultaneously but it also enables applications of unbounded size to be supported and run on such a network and the verification with each

transaction takes just milliseconds on chain no matter the size of the application so with zexi we not only provide data privacy and functional privacy but also leverage this to increase the scaling throughput and support unbounded computation size since publishing this work a number of us who worked on zexi received a lot of inbound requests from dapps token wallets and d5 protocols asking us to productionize the system and i'm excited to say that in the past year along with colleagues who worked on xc we decided to take this work into production as a leo

aleo is a platform for fully private applications and elio is architected as a blockchain that is private by default open source and built for the web unlike existing solutions that seek to replace the web alio is designed to integrate with it for users ailu introduces new services that are both personal and private and for developers ali introduces an a programming model that can easily integrate with existing decentralized applications and so i'd like to walk you through you know how this model works with this programming model we really

can break it down into effectively this this diagram that you see here the idea is for developers to write their applications in leo to then run it on provers and those provers publish the results um as transactions on a blockchain and to break it down more concretely you know in the first step users can write their applications in this programming language that we have developed called leo developers will write and define user actions in the language which then gets compiled as an application and can be packaged and in a

collaborative environment for you and and your team second on provers uh developers can host their their applications as a package um as a web application and with every one of these applications they can process and execute and facilitate interactions with other users across the web lastly as it's open and it's part of a global network this is also something that can be easily controlled or managed but also accessible to others around the world and because there is a blockchain that

is checkpointing and storing the state of everything we also have finality and the nice the nice thing about this architecture of finalizing it on avio is that the transactions themselves can be submitted anonymously but in addition um because we use the zexy architecture to process transactions every transaction itself can be verified very succinctly and lastly we can store your records on there permanently and on elio every transaction encompasses records themselves that are fully private they're encrypted under the receiving addresses uh public key

and this ensures that no matter how you store your data on chain it will always be private by default if an application wishes to make that public they can publish the view key either for the record or for the entire account as part of the memo field in the transaction and that that gets broadcast and and becomes visible by everybody on the network what we're really talking about when we talk about a leo however is this idea of programmable zero knowledge programmable zero knowledge combines both the development opportunities of a programmable protocol with the privacy and security of a zero

knowledge protocol powered by zexc in this case the result is a solution that both developers and end users want and can use dark pools and mixers have been the primary applications leveraged by users of tornado cache and zcash providing that degree of transaction privacy has driven extraordinary success people recognize the need for more natively private ways to transfer value and have migrated funds to platforms that can support that value proposition so i believe that the appetite for privacy is obvious but core to that value proposition is privacy as native most prominent layer 1

blockchains are addressing privacy concerns to some degree but they are doing so mostly through layer 2 solutions though these layer 2 innovations will result in degrees of privacy being added to these protocols privacy at the end of the day will remain a feature and not a core component with programmable zero knowledge helio gives developers the ability to build with privacy already baked in and gives end users the confidence that privacy is not a voluntary add-on by the developer but is rather an architectural bedrock of the underlying platform our first step towards opening up elio

to the community has been as part of our mission in building out the developer preview one developer preview one is the first step towards launching the alia platform and it is composed of four main components snark os which is a decentralized operating system for private applications test net one which is a trusted test that launched on snark os to allow developers to begin writing and deploying applications aliexplorer which is a block explorer for the test net and exposes rpc apis and breast api endpoints and lastly of course is the leo programming language a functional statically typed programming language

for writing private applications i want to spend a bit of time talking about snark os and leo as their components that make ailer's solution particularly unique snark os is a decentralized operating system for private web applications and it forms the backbone of a leo and enables developers to checkpoint and finalize application state in a publicly verifiable manner it runs a blockchain and supports all sorts of applications so it's very similar to ones that people know and love on ethereum the idea for us is to use snarkos as the foundation

or the backbone of this entire system so snarkos is meant to checkpoint verify and store data in state leo is the programming language developers use to build on alio and it looks and feels just like a traditional programming language yet under the hood it is far more complex leo abstracts low-level cryptographic concepts and makes it easy to integrate private applications into your stack leo mimics javascript's approach since it's a good paradigm for thinking about circuits and javascript developers expect all code to either render or print to the console likewise circuits will either render or compile to a circuit and there is a clear divide between

whether something should be asserted at proving time or compile time current languages for writing snark circuits don't have a clear distinction and it leads to a lot of confusion instead alio introduces a new syntax in order to elucidate this snark circuit logic and to make it simple to bundle and share your work we have built a package manager for leo called alio package manager alia package manager is the first package manager for xero knowledge circuits and it includes collaborative features like teams and organizations to make it easy to work with others on private applications our team's decision to incorporate a

package manager frankly is just another key benefit to using leo and so we're asking for two things from the community today the first we're looking for open source developers to contribute to the development of smart os and leo but second we're also looking for feedback from the community on our design decisions especially as we ready ourselves for production launch and if you'd like to get involved i'd ask that you head to edu.org to start programming or exploring alia packages okay and now here we are with howard uh and we get to talk a little bit more about this presentation if you do have

questions please leave them in the chat but i do have i have a question that i thought could actually start this off um in this presentation you didn't really talk exactly about like the cryptography like behind an actual transaction maybe you can walk us through what that would look like on elio sure i'd be happy to um basically there's um there's a few circuits that we've been architecting um which are an evolution from zexi effectively in this xc architecture there is what we call an inner and outer circuit um the inner circuit itself in our case checks value conservation but then also checks the validity of every record in the transaction that is being spent and also being produced so for example um if you have um a

record that you're spending you want to make sure that the serial number um hasn't been spent before um and and on the other side with a new record you want to make sure that the commitments that you're now committing this record for um also have not appeared on on the merkle tree the the global state of the ledger before um and so that's one circuit here that that is used for for value conservation and for validity checks um there is another circuit called the outer circuit here which is um it's more like a compression but it's it's it's a little bit into that recursive proof composition that i was mentioning um just previously and um the idea there is that not only can we compress state about the programs that are being run under the hood but uh we can also um ensure that this

this transaction itself is valid um within a shielded pool that is not fragmented and i think that that's a very nice concept here that is quite um is quite new um in the fact that uh we haven't seen a production system do that today um and you know the the third area uh is is a circuit that we call the proof of uh proof of succinct work circuit and it's a it's a circuit for consensus and in this case it allows us to effectively one grind snarks similar to doing proof of work in bitcoin um we're now grinding snarks and um by doing this uh one the push has been really to drive um a huge incentive for miners to actually invest resources

and technology um towards advancing you know proving capabilities in hardware for snarks and so by having a hardware accelerated snark you know in minding this that it actually gives you a really nice incentive for um you know earning rewards but then on in our case designing it this way also allows us um to incentivize and speed up the programs that people would run and build and by doing it this way like i guess i should also mention that the proof system and the curves in the posw circuit are the same as the curve and the proof system in programs and that was an intentional design that we did to make sure that if you get a hardware acceleration here you also get a hardware acceleration there

but those are the three main circuits that we have architected i will actually want to i want to come back to proof of succinct work in a bit but we actually have a bunch of questions that i think we should dive into so uh mccara asked how does alio compare with other solutions like secret network on cosmos so i'd say like you know what what elio tries to achieve is is a is a quite broad scope but in practice the goal here is really to um target um well frankly usage from other l1s into one shielded pool i think one of the ways to think about it really is that there's a there's a lot of people who who understand privacy now are interested in it but obviously like

it's there's a network effect to privacy as you know fragmenting the anonymity set is a huge uh issue if you want to preserve someone's privacy and so in our case you know we've architected zexxi as a stand-alone system that allows us to immediately have all of these applications from different networks whether they be blockchains servers databases you name it basically tie into one system and and the goal for that is so that we all can grow one anonymity set together and grow this shielded pool to be as large as possible um together so uh ciao was asking for some typical use cases for elio and i know it's still pretty early days but i'm curious to hear too

what the ideas are so i alluded to some earlier and i'd say like you know for for for crypto natives um the two most interesting and the two most common requests that i've i've gotten and the team has gotten really has been around dark pools and mixers um to be frank you know a lot of people are starting to realize that their assets you know on ethereum aren't really shielded that every time that you know if i were to pay you anna and and you received some eat from me you also receive uh my address as part of that and you can just go on to either scan and look up my address and see how much balances i have um how frequently i'm transacting what apps i like to use and also potentially other people that i'm transacting with that you recognize and this is something that people are

starting to recognize in their own accounts and you know in the normal notion of a bank account it's almost kind of unheard of to just have that be open and so this is one area that we found to be quite quite impactful i mean on the other front certainly has been with dark pools that with a lot of dexes and d5 applications um you know the nice thing about being public is that everything is public um and so you can see it and validate it but you know the downside is also as we've seen recently with these uh minor extractable value concerns and discussions that it also leads to front-running attacks and risks there um because you can now reorder transactions you can you can forego transactions you can you can effectively nullify transactions um in the sense that a miner who sees an opportunity can

stick their own transaction in and game the system and this is something that zexi's uniquely poised to prevent um because the system is fully private um and so for i think for crypto natives the concepts are quite clear that these are two areas that i think are very promising for the technology i think generally this idea of defined privacy that's one of the poll questions that i actually put in originally on this in the event i think that's such a important conversation that i i hope to actually explore more with you know subsequent events and stuff like that hopefully you can join all right um silly man asked is it possible to use elio and snark os is part of an mpm module logic in browser thank you for asking this yes uh well

not yet but yes [Laughter] we're working on it actually if you're interested uh feel free to ping me uh howard eliot.org i'd love to i'd love to discuss it with you like it's something that we've been actively exploring right now um because we do want to make it easy to just um on the web frankly and we have some simple applications we've been piloting internally to try to just see this uh into something that's mature enough to open source um and uh would love to would love to um you know brainstorm with you on that oh asked why must testnet be trusted ah this is a great question um so you know without without giving away

too much we we will have a setup event coming down the line it's something that we've spent a lot of time working on and um the reason that the testnet currently is trusted is that we're very early and so you know we want to be kind of transparent or frank with the community that this network was spun up by us you shouldn't use it um to put real money in it but if you would like to build applications try building applications and testing it on an open network it is available for you to use it there and in the future we will have a trustless test net that will be live for you robert was asking how scalable is the

blockchain and then his subsequent question is how does the blockchain work maybe you can so yeah no these are great questions i would say you know the the framing uh is very similar to bitcoin and ethereum in the sense that um you have a mempool and you have a ledger um frankly you know in snark os we've architected it to be quite modular um so that we can support multiple ledgers if your client would like to and on the other side the client can also run programs if you'd like to um the goal right now has been to stress test and to benchmark and and you know because of that i don't have numbers that i can you know say right now but at least in our initial tests it was easily you know a hundred transactions to a thousand transactions per block

without issues um verification on that is under 20 milliseconds currently per per transaction and it's a constant time operation so we feel pretty comfortable that you know this this will scale quite easily to large numbers of users sean asked uh zexi proposed delegated computation using blind signatures allowing for mobile processing does leo actually support that so i guess you meant sexy in the original paper yeah so one of the things that we've been very careful about adhering to is the zexi model of delegated compute and also non-delegated compute we want to make sure that people who are on low end devices like mobile devices have the ability to call out to either their own hardware or to

third-party hardware to run their their computations and frankly with the inner and the outer circuit there's also two different levels of running that so what i mean by that is on a program level and on the inner circuit level you may want to run that on your own hardware but on the outer circuit because it's effectively like a compression circuit um you can offload that to a third party if you're okay with losing functional privacy but not data privacy what that means is that that third party would learn um you know what application you used because they see the ids for for the verification keys but um they wouldn't know um precisely you know what information you you use the application for

so if it's a payment or if it was a an exchange or if it was you know a message or um it doesn't know semantically on that level and so there's different levels with with which you may be interested to offload this and that delegation model for mobile i think will be very important to seeing it kind of happen full-fledged in a mobile app then uh kev kevkev asked does the leo abstraction apply any overhead to circuit size in any case yeah that's that's also a great question so yes there is and currently what we're doing in leo is to not toggle that on unless you put in the the flag to load state as well um the idea is that there is one small layer of abstraction which is

effectively like two merkle proof checks and those abstractions allow you to ensure that this transaction actually lives on chain for the inner circuit and the outer circuit process when you construct a transaction outside of just that one state abstraction um there is no additional overhead and frankly um you know the goal with the compiler has been to build a system that is quite um like quite optimized um while also being provably correct and there there's a lot more that i can talk about that once we kind of push that push that work along the way dara asked which proof system is it i know that sexy originally used graph 16.

yeah um thanks for the question dara so so the um the current architecture has two different proof systems there is both kraut 16 and also marlin and uh in the case of the inner and the outer circuit we use grot16 for performance reasons for these transactions and we've actually been evaluating a fallback plan to marlin so that in case there is a vulnerability in the grad 16 circuits that our network can also support switching over to marlin as needed but for all programs like leo programs and also for consensus this these will be using marlin and the goal with that is to have a universal and updatable system that um allows us to ensure that things you know can con continue to maintain

correctness but also to make it convenient for the developer experience that um there does not need to be you know gigabytes of keys stored across the board in order to use different applications that you could in theory store just one index into the respective keys that you need per application ronald was asking when you say apps run offline off chain where do you foresee the end user approvers to run on their own device or in their wallet or on an alio provided aws instance so uh tentatively we're we're building one we wanna make it public for everybody um so you can run it anywhere you want um you know you could run it on a on a laptop you can run it on aws you could also find a host

and we're also working with a few different teams to try to get um get people who are interested to actually run this as a service and if you're interested to run it as a service like please reach out like we'd love to work with you on that front um the goal for us has been to and personally you know one of my personal goals is to just see this technology become commonplace or really commodities so that um you can use it wherever you need to and where you would like to um i think that just access and infrastructure has been such a barrier and also tooling and tooling is also another aspect that has been such a barrier that you know i think not prior not prioritizing this would be a disservice and so the goal is to make this all out there for everybody to use and

the hope is that you know people will go and build different uh different endpoints to actually call into it kev asked he mentioned that you so you mentioned that leo it was or javascript inspired javascript inspired leo does this mean that some constraints will be implicitly applied ah this is a great question so um everything in leo except for um uh console functions currently today are uh native circuits and the reason for using the javascript model is that in javascript develop web developers look at um two contexts implicitly actually there

is uh you know as a react programmer you might think about um writing code that will render in in a dom and then you might think about code that will print out in a console um you know when you're debugging um and writing a web app you'll think about it from these two frames almost implicitly because you're just checking does it show up you know on the page itself or does it show up on the console on the side and right now we don't have a have a very clear model for that within the zk space and part of barring this notion was that it's quite intuitive that if you replace the word dom which is just a tree effectively with circuit and it's just the dag effectively that you know you can think about it from that model and separately have your console on the side as well

but also for the use case that you know we're looking at which are web applications um it already comes with this this two-tone model anyways that you know we would want to adhere to that and so in leo effectively um uh console functions like asserts console.assert console.log these types of methods uh would only be at compile time and uh in the case of the actual rendered circuits um everything else will be baked into the circuit itself there's a related question here are you concerned about leo uptake because most devs work in imperative languages and don't understand functional languages that's always an uphill battle um and uh also like the definition of

functional uh at least for my pl friends uh who are much eloquent much more eloquent speakers about this than i am um say that it continues to evolve um and uh frankly i i think that there is an uphill battle there is also um generally a much better abstraction model which is part of what draws people to the functional languages and i personally subscribe to that model that i think it's a it's a good one for this context because snarks themselves are very modular in terms of gadgets and gadgets behave like functional units within a programming language francois asked what are the trust assumptions i need to adopt when using elio so for one

the goal with putting out the package manager has been to provide a way to publicly see and to publicly check what what circuits are being used in an application that you are you're interacting with and you know on the other side of things i'd say there is also going to be a setup event down this down the line um to make the actual cryptography under the hood um effectively trustless for um for all intents and purposes so that you know in terms of what you really have to look out for are these two two um two dimensions but um outside of that um none really come up to off top my head but i believe that these are the two main ones um there's a lot of great questions

there's some really long ones coming up so uh howard i think people are very interested michaela i don't know maybe we should be doing a q a session just just on its own so michaela asked are there any limitations to the code being developed assuming it uses snark for computation this means the code cannot be turing complete this is actually a question that i had as well about um whether it's sort of cons sexy and snarks are considered kind of you know connected somehow is is that always the case so it's it's a great question and also like to your point about turn completeness this is also a great question you know there's two dimensions you can

look at it on on the leo sense of just writing application itself yeah currently it's not turning complete we we did have a lot of discussions about whether we wanted to do it and frankly we realized you know from our perspective it's best to allow people to write small gadgets if they want small gadgets and then for people who want turn completeness in an application to support basically a vm circuit so that you can just like in the tiny ram model right turn complete code as you may have seen from other other teams that are in this field you know there has been a lot of explorations on that front and frankly our work is uh is quite um it's quite complimentary to theirs in the sense that uh we could also adopt the very similar approaches or even work with them to integrate that

into leo currently the approach we've taken has been one for efficiency reasons to keep things small and keep things lightweight and also i think that down the line if there is demand for having it be a turing complete system we certainly will bake in a vm then that that you know has that that functionality in it so daryl was asking kind of the continuation have you thought about other proof systems such as plonk or halo yeah um i think that that's one that uh i would i would say it's such it's such an evolving field it's very exciting um and i think one of the one of the reasons for well for

one of the reasons why we picked marlin um to start was that it's the one that we from our team are most familiar with and comfortable with for universality here um but it doesn't preclude other options and i think for one for privacy um it has been a concern that that different types of programs may have different verification times or sizes because of the proof systems kind of trade-off for transparency on the other front i'd also say that this space is fast moving and i'm always looking for a better zkp to use so if there is a better primitive that comes along the way i'm very much open to swapping out marlin for something else and i think that meant most on the team would also echo the same thing that

it's just uh it's been a huge priority for efficiency's sake because as you know with web applications the demand for instance interactions is is quite high um and uh and zero knowledge proofs historically have had a lot of barriers to getting to that performance at that performance level mccara had a follow-up question to that first question which was since alias meant for other l1s to use it are there possibly going to be bridges to ileo or would it possibly compile say evm by code or to snark os by code yeah no it's a it's a great question and frankly like i know that there's a lot of teams that have looked at interoperability um i think that with a lot of approaches there has been a top-down approach of

running light clients and i would say for us it likely won't be much different um right now it's a bit early for us to really engage on l1 discussions and so you know in terms of bridges yes um but also very curious to see where the where the approach evolves like uh you know with with teams like coda doing succinct blockchains i think it's very interesting or intriguing um to have a to have a simple proof that could check and attest to the to the validity of a transaction in a block um without having to run a full light client to verify that this exists and effectively use consensus in that mechanism

ar are you muted there anna yeah there we go i just corrected you because you said coda but it's minna now you know my bad sorry zach zach williams asked a big long question that i'm going to try to do justice to so does alia architecture have a concept of call semantics for example if one creates a circuit that creates shielded tokens is it possible for a third party to create a decentralized exchange that instructs the former circuit to update records on behalf of the user i'm going to leave it there you guys can read the rest of the question the answer is um out of the box no but if architected yes and it's a package that we've been working on

um to to do this uh like effectively hyper threading model um you can you can call one into the other and and we have something called program registers um that that's an addition to the originals xc model that allows you to pass state between these records within a transaction so that you can execute without without having to make a trust assumption about like the model that you're operating in and so you can keep that boundary between a third-party token and your application um it's something that i'm also happy to walk you through um in detail as well just a one-on-one um kev asked can you go more into the detail of the compiler architecture is it fairly stable i would say there is a there's a there's

a diagram that we've been working on that we're going to put in the in the repo very soon um so stay tuned but there's multi passes and we've been doing a a pretty large compiler architecture upgrade as of the past 30 days um there is a pull request you can track that has that and it also has the diagram in there actually i think we did put it up uh maybe i can just link it in here right now to save time but the effective model has been to parse everything into an ast then do type resolution on it then do optimizations on that so for example constant folding and these types of functions where you know that you know the kind of semantic or state about an application and you can then parse through that and finally circuit synthesis

but let me paste the architecture into the chat here because i believe it is up here i'll need to find it apologies oh um anna i can't hear you i'm using my mute too well um okay i wanted to ask uh kev had a follow-up question to this where he he said i asked because proof creation times with the programming

language would become compilation time plus prover time this is going into the compiler like following up on the compiler question i believe um so in terms of the times um it would be the comp the proof time and um the compiler itself is quite quick like for most applications that we've been playing with it's usually seconds i think the longest i've gone was something that was close to gosh like maybe two to the 19 or two to the 25 member right and like it was um on the order of like three or four minutes this was also on a very beefy macbook pro and so um you know depending on your hardware and your laptop or desktop setting um you know the compiler performance

will vary as well we've tried our best to keep things as paralyzed as we can but there's also a lot of work we can do to you know use async to prioritize certain things so that the compilation path itself is faster um always looking for devs to work on that so if you're interested would love to debrief with you on that awesome so there's a couple i think there's a couple more questions actually people are answering the questions in the chat so that's awesome but i would put if you do have any sort of last questions maybe put them in the chat now because we only have 15 minutes left on this block um and yeah there's one more from kev which was do you envision a situation where the package manager becomes an attack vector yes yes are you worried i need to write

like a like a post somewhere so that there's an open discussion about this um basically in its current form it can be an attack vector leo itself also assumes the package manager to be this one package manager in reality the goal is to modularize that to be whichever manager you'd like to use and as part of that we've been exploring an on-chain circuit registry so that you can publish this directly to a ledger itself in this case snark os and this way there is a more resilient repository for everybody to host their circuits on but in practice right now we do rely on the package manager and exploring a a compact and a succinct representation

for storing those circuits on chain and i think there's one last one that i can see here which is can you elaborate on the leo compiler performance when the circuit size is above 2 to the power of 20. um you know uh i actually don't have a lot of data points beyond to the 20 right now but uh if you're interested to to write one that is that big like i'd love to work with you on it or or feel free to publish it and uh and to ping me because i i would love to see the results myself very cool so i guess as a last question if there aren't any more in the group where should people meet you find out more what should they do

to get involved yeah i'd say first off you know there's a qr code on the screen for for the developer docs um i would i would highly recommend you check it out um it gives a lot of the basic concepts that that i talked about today um here in in depth um on the other fronts if you're interested for um you know the leo compiler if you go to leo.lang.org it's a redirect to the github repo for for the leo compiler and also if you go to snarkos.org it's a redirect to the github repo for snark os feel free to check those out and also star them if you if you're if you like it on the other front i'd say like if you're interested to try writing an application if you go to elio.studio as the url you can download alias studio today

it has leo built-in batteries included and you can start writing an application right from the ide that we've been working on very cool so thanks so much howard for the talk for the q a almost like a fireside chat thanks for hosting me and thanks for having me i really appreciate it anna cool so we're going to sign off from this stage oh i'm supposed to look up here we're going to sign off from this stage for about 10 minutes and then we should be back with pratush talking about arc works exciting cool see you soon