Aleo 🛠 Powering Private Applications with Zero-Knowledge Cryptography

foreign [Music] so hey everyone uh my let me just actually start some timers here all right um cool um so everyone uh my name is pranav it's good to meet y'all and uh today I'm going to introduce the Leo programming language and show you how we can use it to develop private applications on on the Ilia stack so over the past decade we've really seen how web3 has pushed the envelope of decentralization really providing users with more control over their data in the web 2 model your data was owned and managed by a centralized party and in the web3 model your data is no longer managed by a centralized party but it is effectively owned by the network and what I mean by this is that many platforms fail to provide data privacy and from a user experience from a ux standpoint this is insufficient now one way we can remedy remedy this problem is by leveraging the cryptographic constructions like zero knowledge proofs and building friendly abstractions on top of them so today in in today's talk we're going to walk through how developers can build private applications using the Leo language on top of the Alias stack uh we'll start first by building some intuition for cryptographic Primitives and the state model that Alia builds upon and then we'll go into a deep dive of the lia language and learn how we can build private programs and then finally we'll build our own private auction and Survey some of the tools we have to test and deploy applications so quickly before we get started um in the chat uh we'll link some developer resources they have some instructions on how to get your Dev environment set up and you know this may take some time so feel free to run it while we go over some high-level Concepts and I think there are there will also be people in the chat uh helping answer questions as things go on and yeah let's get into it so for decades cryptography has really served as a powerful tool for building secure systems and much of the cryptography we use today provides security guarantees about data for example Alice can encrypt a message and send that message to Bob and be sure that the contents of a message hasn't been leaked and this is will be called confidentiality she can also sign a message which Bob can later verify and this gives authenticity for the message and these techniques are really incredibly powerful and we see them used in a number of systems but they don't provide guarantees about computation you know the Integrity of computation they don't provide guarantees about the privacy of computation and this is really where zero knowledge proofs come in now formally zero knowledge proofs are privacy preserving cryptographic proofs of computational integrity and that's a mouthful but simply stated with zero knowledge proofs I can prove to you that I know some Secret that without actually telling you that secret and let's make this a little bit more clear so suppose we have a publicly known function or predicate s and um a publicly known output y a zero knowledge proof is a proof pie that allows me to claim meat approver to claim that I know some private input X such that f of x is equal to Y without actually needing to reveal X to you and uh this is the core idea we'll build upon today in reality zero knowledge proofs are way more complex and we're really glossing over some fancy math and some really deep technical details but if you're interested in learning more uh we'll have some resources for that as well now there's a special type of zero knowledge proof called a ZK snark and a ZK snark is a zero knowledge succinct non-interactive argument of knowledge and let's break let's break that down a bit so a ZK snark is a proof that is zero knowledge which means that the proof does not reveal anything about the private inputs that were used to construct that proof uh zero knowledge proof is succinct which means that the proof is small in size and verifying the proof is fast this is super powerful because it ensures that the cost of verification is independent of the cost of computing that proof and in other words your proof could be over a very complex calculation but can always be verified in a short amount of time and this really helps with scalability as we'll see later a zero knowledge proof is non-interactive so what this means is that the prover the party generating the proof and the verifier the party verifying the proof do not need to talk back and forth for the verifier to be convinced that the proof is true the verifier can independently verify without the need for communication and a zero knowledge proof is sound um this is a technical requirement but at a high level what soundness means is that any statement that can be proven True by the proof system is actually in fact true so now that we have some really high level understanding of zero knowledge proofs let's switch gears a bit and discuss decentralized ledgers so blockchains are more generally decentral at decentralized ledgers have spawned a wide variety of applications that really weren't possible before um but these constructions have some significant limitations now to understand uh where these limitations come from let's kind of walk through how a decentralized ledgers work so the left here we have a ledger on each row you have an account or an application Associated code and data and this is over a network a distributed Network so fundamentally decentralized ledgers enforce correctness and guarantee security by re-executing computations on the network and how does this work so when a user submits a transaction uh containing some an identifier for the application some input data and a signature authenticating that transaction each node on the network re-executes the computation inside the transaction if the computation is correct the nodes agree and the signature is valid the state is updated now the problem with this model is that it hurts scalability since every party needs to re-execute the transaction the network is essentially performing a massive amount of redundant work so let's put this into perspective suppose you have 3 000 nodes on an ethereum an eth1 Style Network and each block requires five seconds of compute this amounts to fifteen hundred fifteen thousand seconds or about four hours of compute redundant compute performed by the network and this is extremely wasteful another fundamental problem is that ledger re-execution hurts privacy so the core strength of decentralized ledgers really is also its weakness for to provide correctness and security every node needs to re-execute and for them to do that they need to be able to see user data program data inputs and outputs and while this leakage might be okay in certain applications tolerable and maybe even desired in some applications there are a number of use cases where that break under this model now one like natural example uh for us is uh Banking and payments So In traditional banking uh when you uh providing someone with your bank account number doesn't reveal information about your balance who you transact with what you buy when you spend and so on but in ethereum when you give someone your ethereum address they can see all this information and what's more is that they can track you till the end of time so clearly we need to improve on some of these existing constructions but first we also need to see what's the fundamental cause of this problem and when we take a step back and really look at the system or existing systems we see that these problems are really a byproduct of the account model so uh what is the account model the account model is a model for organizing account and application State on a decentralized ledger in this model a ledger tracks each account by a global state so on the left here we have a user and on the right a user with its Associated address and on the right we have a simplified model of global state and that you see you have an account its address its code and Storage and you can think of storages persistent data here so when a user creates a transaction a transaction itself contains the address of the account it's interacting with some data a fee and a signature authenticating the transaction when this transaction is included in the block every node on the network re-executes it and induces a transition on the account state from its original state to a new one here in this transition we see that most of the stuff Remains the Same but the account storage persistent storage gets updated now this model is actually really nice to work with um it's really easy for developers to understand and write programs that coordinate with each other manage State and so on it's a very simple model and it's the one it's one that we see today um all over the place but the issue like we discussed before is that it's not scalable if you suddenly get a spike in traffic and a bunch of people are submitting transactions you end up with bottlenecks which result in fee spikes and so on and like we also discussed um for these for the for this network to be able to execute these transactions they need to know full State and that compromises privacy so let's kind of walk through an exercise where we take this account model and see if we can improve on it add some more privacy and see if we can get something desirable and really what the we're trying to work towards is uh private smart contracts so um what we're going to do is maybe make some modifications to the original design here we have the original specification of the transaction and let's try to get some more privacy here so first what we'll do is we'll encrypt the data under the sender's key and instead of providing a signature we'll provide proofs that that the transaction updates or produces uh correct uh let's say updates the account State correctly and this will be a zero knowledge proof and the remaining stuff Remains the Same mainly because you need to know which account that you're going to access or which account you're going to call application you're going to call and your fee Still Remains the Same and then um on the network side you have an account originally you have an account it's code in storage so what we'll do is we'll encrypt the storage um separating each encrypted Portion by um index by user effectively so each portion of the account storage is Inc that is related to a user is encrypted under that user and um instead of storing code we're going to store a predicate and a predicate is essentially a mathematical representation of the original code and we need to do use this mathematical representation because we are reasoning about the correctness of the transaction or the correctness of the execution within a cryptographic proof so when we take the we take the original code turn it into a predicate it's actually a polynomial and by doing so we can reason about it in a proof system and start constructing some snarks out of it so let's put this all together so in this new model you have a global State each account has its address and for each address it's um each address is indexed by user and for each one of those is an entry you see here some code and some encrypted storage of the Old State of the current state now when the user submits Trend uh transaction it submits the address it's interacting with um it submits uh some encrypted data fee and proofs and these transactions effectively prove that each state transition is made on encrypted and committed State and if the network accepts verifies these proofs finds them to be correct then the account state is transitioned into the new one note that storage is always encrypted so we still have privacy here now the the key component of this construction is or really the key question is what is actually being verified in these proofs so you have a transaction here and in the proofs uh we're going to take as input uh the code predicate and the Old State so it's the old encrypted state and produce new encrypted State and what the proof will do is check that the program predicate the mathematical representation of the code that um represent the state transition is actually satisfied is actually executed correctly and with this when this if this proof is verified a verifier can be sure that account state was updated correctly but also a verifier doesn't know learn anything about what the account state was because it still stays encrypted through and through so this seems like a pretty cool model um it actually doesn't work so so why so why doesn't it actually work here um first of all the first problem is that you don't have concurrent access to program state in this model that we have before you have that a user needs to take the entire program State prove something about it in a transaction and then upload update that to the network so if a user one comes along submits a transaction and while the network is verifying and updating it user 2 comes along and tries to submit a transaction or reads the network State and tries to submit a transaction if user ones transaction goes through users too will fail because it has read Old State effectively in this model in order you in order for you to get any sort of multi-tenancy user one needs to read state construct a transaction uploaded the network has to get verified and then only after that user 2 can come along read it produce a transaction and upload that to the network furthermore State updates in this model because you have to kind of pull the entire account State it's extremely inefficient so and then another problem here is that we don't have privacy because you're still sending the address of the accounts that you're indexing in the clear you still have to um everyone can still see your access pattern so even though I don't know what your data is even though I don't know what your data is I know when you interact with this program and I can infer things about your behavior so this model doesn't work um and but let's just sort of review some of the properties it gives us so first of all we did solve larger re-executions because we're Computing State transitions in a zero zero knowledge proof off chain uh the the network only needs to verify the correctness of the zero knowledge proof which is very quick uh we have data privacy we're encrypting our data we're encrypting data on uh on on the Chain itself we don't have account privacy because in this account model the uh Ledger requires the address that you are accessing or updating to um uh effectively update Global State over each transaction so addresses cannot be encrypted under this model and because of that you leak uh some information and like we discussed earlier uh we don't have efficient State updates because you need to take the entire account State reason about it and produce a proof and you don't have concurrency because because like we discussed before um you would users could be would be reading old data stale data effectively so how can we do better and really this is where we're kind of we're going to kind of like Drop The Core intuition here so the problem is that for in this model and this are augmented account model every transaction requires the entire account state to um to require must read the entire account State create a proof and produces a new one so that's inefficient there's no concurrency there um and the other problem is that addresses are public so the idea that we've come up with is that can we Shard application states such that each user owns their own piece and really if you build upon this idea you arrive at the record model so this is uh the model upon which ilio actually is constructed is constructed on so the record model a decentralized ledger tracks each record by a global state here you have a user here you have some um Global State for the for the for the Ledger in here what we are what we store is the program it's code and a set of records and note that records are encrypted on chains so there's no data that's being leaked there when a user submits a transaction a transaction actually consists of a number of State transitions each transition containing an ID of the program it called the old records that were consumed the new records that were produced a fee and then a zero knowledge proof stating that given the input records given the output and given the output records and the program predicate everything was executed correctly so if you know a transaction submitted It's contained in a block and the network verifies this the network only needs to effectively throw out the old records and put in the new ones and uh in doing so it's it's actually a quite simple update model and it's the one that we use today so what does this give us so like here we have concurrency um because application state is sharded by for each user's context a user only needs to operate on their own contacts the the records that are only associated with their component of the application state for program execution you also don't have double spends and this is because the Ledger can enforce that no record can be consumed twice and the way you can do this is by revealing consumed records serial numbers um after you accept every transaction this construction is actually uh this is a high level overview of this construction and there's actually some more technical details uh one great resource for this is the zaxi paper and really recommend if anyone's interested to check that out but uh let's let's round this out so what are we actually proven a transaction uh you prove that given some code predicate and some old records and uh some new records as output the program predicate is satisfied for all uh Records um that are taken in and produced and with this uh we have uh we now achieve account privacy uh there's no notion of addresses or Global State and within a record is uh effectively each user owns their own record and on record owners are not leaked so in this model you have effectively account privacy oops sorry that's not it uh you have efficient State updates uh predicates only consume records that are actually being updated um in their context they don't need to reason the about the entire state of the application to make an update so St updates are effectively sharded and just localized to the to the set of records that are being written and you have concurrency because uh the application state is split apart uh two users if they're operating on Independent application State can submit transactions and run them at the same time and both will be verified by the network and both will be consistent uh with with the semantics of the application cool so kind of putting this all together a bit um we talked a little we talked about zero knowledge proofs we talked about the record model and together these are instantiated in ilio and what Elio is is a new L1 that builds upon existing constructions to offer more privacy and programmability so in this uh in this diagrams here we have Bitcoin being the least private in the least programmable to its right is ethereum which improves upon Bitcoin by adding programmability and to the and above Bitcoin you have zcash which improves on bitcoin with privacy ilio effectively takes the top right uh quadrant here where we have privacy and programmability and we get this with our construction with our usage of zero knowledge proofs and how it's used with our record model oh yeah so um with that let's now that we have an intuition for the record model let's take a look at Leo and see how we can use it to develop private applications so first let's recall our original definition of a snark um a ZK snark or let's say a zero knowledge proof it's a proof pie that attests that uh that I know X such that Y is equal to f of x now delete now one question when you're actually using snarks is how do you encode F how do you specify the program the program predicate and this is where the Leo language comes in Leo is effectively a high level program programming language that's compiled into a Leo instructions before it serialized into AVM byte code and the compiled byte code is deployed on chain and visible to all participants in the network the AVM or the Alia virtual machine is a virtual machine that executes AVM byte code and produces a ZK snark or proof and the Alia virtual machine is essentially executed offline or off chain a user when they're constructing or creating a transaction they invoke the Elio virtual machine it produces a proof they package that into a transaction and send it to the network now the the details of alien instructions ADM byte code Alia virtual machines are actually really cool we have some developer resources for that but for the purposes of this Workshop we're only going to focus on Leo code and with that let's dive a little bit into the language so Leo like all programming languages provides some data types for users it has 16 primitive data types and also allows users to Define their own composite data types now some of these might be familiar coming from other programming languages you have booleans you have integers you have structs um you also have strings but uh the orange shading here indicates that you know strings have a limited uh set of functionality we're building upon this but uh there's actually some subtle details in making sure strings work safely uh in snark constructions you also have algebraic data types called field either fields scalers or groups and these relate to some of the cryptographic Primitives that Leo offers underneath um or Leo offers to users to use um Fields also relate to the snark construction underneath and they're the they're the fundamental uh representation of data in in a snark and then you also have addresses and these are akin to ethereum addresses the little digging a little bit deeper a struct is a composite beta type which contains any a number of fields each of these fields could either be a primitive primitive data type or another composite data type another struct itself so now let's look at some Leo code and actually see some of the familiar paradigms that Leo provides to users so here's our hello world Leo program um online on from line one through nine you define a program scope and its Associated name hello.aleo and on line two we have a function Foo and then line five we have a function main before going into the distinctions between uh a function and a transition let's just walk through the logic a bit so a function Foo takes in as input X and Y produces uh u64 as an output and Returns the difference between X and Y transition main quite simple invokes Foo and returns it directly now the distinction between a function and a transition is that a transition forms the external interface of your contract this is what uh are the transitions that are actually created in the record model transitions have the ability to take in records as input and provide records as output and transitions also have the ability to to declare visibility on its inputs as well you can think of functions as effectively like helper functions in your code but when interacting with your program from as a user you're invoking transitions so one thing to call out here is that Leo is a strictly type language every variable declared needs to have its type and this is mainly to enforce safety uh during programming we're also investigating some techniques uh we're also investigating implementing type inference to make this a little bit more ergonomic but more to come down the line another thing to call out is that Leo provides some primitive uh you know standard operations over primitive data types um you know right here like one thing it you know obviously it uh provides is uh integer subtraction integer um some integer arithmetic now Leo's arithmetic is safe by default so all these primitive operations actually check for overflow so here uh you don't need any notion of safe math safe math is you know done by default and if a user really would like to use a wrapped version or a wrapping version of integer arithmetic that is also available to them they just have to explicitly call it uh within our standard Library and then the final thing to call out here is that like I said before transitions have visibility modifiers on its inputs and outputs and this is especially useful because really in some cases you don't want everything to be private or in some cases you don't want any in some cases you really want to say some inputs are public and you know really control visibility uh in a fine-grained manner and this is what transitions let you do you can Define modifiers on each of your visibility modifiers on each of your variables and the compiler utters these modifiers when it actually produces uh the circuit the compiled circuit underneath so let's look at a little bit more complex example um here we have an interest calculation that uh compounds for 10 iterations or 10 periods we take in as input capital a public rate and just calculate the interest via simple for Loop I think this should be familiar to most uh programmers coming from you know any any language here one thing to call out is that Loops in Leo and loops and Leo must be static integer static integer literals and the reason for this is that when when you're actually describing your program predicate in a snark it needs to be deterministic and finite in or find a finite bound of a finite size so we can't have non-deterministic circuits or circuits that or programs that change in size depending on input so all of these like constructions here like Loops uh need to be effectively unrolled into a sequence of instructions before being able to synthesize a circuit or a mathematical representation of that program but you know this is not super desirable in all cases right like some cases we're going to want to you know change the behavior of our program based on input and one way you know you can get around this is by defining your circuit such that it accepts computation up to a certain size so bounding the size of your computation and we'll see how you can do that right here so this is the same interest program but in it you actually pass in another parameter iterations and iteration specifies the number of times you want to compound your interest as you can see in the body of the for Loop the modification is that if the loop index is less than the number of desired iterations you accumulate the sum you accumulate the interest accrue interest but if it's greater you don't do greater than or equal to you don't do anything and what this does is that it lets you define a larger circuit which describes possibly a larger set of you know computations you want to run and then you control with input what you're actually running and this is some ways you can get around the limitations of circuit based languages so one thing to call out here is um this assert statement here effectively what this does is this gets compiled into a Leo instructions and when the AVM executes the corresponding program if this assertion is triggered the prover will fail to will halt actually will fail to create a proof so it's a way this is a construct in Leo that lets developers really you know add in safety checks and ensure that approver can't create a proof for something that violates certain invariants cool so we went through some familiar programming paradigms uh you know Leo looks a little a lot like rust and typescript for those that are coming from those languages and provide some of the some constructs that you know are sort of expected in all programming languages now Leo also provides some more powerful Concepts and we use these Concepts to create private applications and we can do some fancy stuff with them and the first thing is uh Records like we described before Leo because alios built on top of the record model Leo needs to have a way of interfacing with this model and you can do so by declaring records so recall that we were able to declare composite data types called structs our records are very similar to structs except for the fact that they have two required fields an owner which is that the owner the address that owns that record and it is the address uh to which that record is encrypted and Gates and Gates is a native denomination of iliocredits uh associated with that record so you can think of um Gates is to Elio credits as G way is to eat as cents are to dollars now with this model application state is encoded in records and users effectively exclusively own their records because records are encrypted under a user's address they are the only ones able to see the information inside a record and with this you have concurrency and privacy so let's let's take a little bit uh you know just look at what we can kind of do with records what we can Define so records can contain any sort of other data type in Leo inside of them so they can either contain um in this case we see that a record contains a field message which is a struct and you know that struck payload here contains primitive data types but could also contain more composite data types and so on the only thing you can't have is a record inside of a record so that is where uh the nest that that's the only level of nesting that isn't allowed a record can also Define uh more Fields if they'd like so in this case we only Define one but you could imagine a record that has you know any number of fields after that for any other application data that you want to encode so how do we use records on Elio suppose we have some transition Foo a transition can take in any number of records as input and produce any number of records as output now how does this work uh in principle in reality here so um we're gonna instantiate and look at this record model under the context of tokens so we're gonna describe a user-defined tokens in Elio and in Leo and we'll see how the record model enables this use case so quickly we have some record token which has uh an owner and Gates as required and some balance for that token and now we have a function a transition sorry transfer which takes in as input um a token so the sender's token the receiver's address and the amount that the sender would like to send what transfer does is that it consumes the sender's token and produces two new tokens one with the remaining balance and one with the new balance for uh the receiver so in line two we calculate the difference between the sender's amount and the uh amount that we want to send recall that you know Leo is safe math by default so if this operation would overflow uh this uh the this the execution layer would be unable to produce a proof for it and then on line see on line three we actually construct a record for um the the remaining balance for the sender and then we on line eight we construct a record for the remaining balance for the or the set the the amount for the receiver and then on line 13 we uh send these um we send these out and let's take a look at with a better diagram of how this actually looks like so here uh let's suppose Alice wants to send some amount of money to Bob and and she's going to invoke the transition transfer to do it so she has a ledger where she has some record uh with some gates and some balance and what Alice does is that she invokes uh the transition transfer with Bob's address and um the amount she wants to send the transition transfer produces um two new records one for Alice one for Bob and a proof pie I also see here that I have a typo and um really in Bob's balance this should be a three u64. so if this proof is uh verified and is accepted then the two records are appended to The Ledger uh note that the Alice's original record n is actually grayed out and what this indicates is that this record has been consumed so technically even though this record will always be stored on The Ledger um it is updated with the flag or actually it's updated with its serial number which indicates that this record uh cannot be consumed again and this prevents double spending of application state or records so that is the record model um this is a powerful Paradigm we can make we can create private tokens and really can create a lot of a lot of applications that um you know uh in a different model that uh create privacy effectively but um we're going to take it we're going to sort of backtrack a little bit so earlier in the presentation we we talked about how the account model um was bad and why uh why you know leaks privacy why it's bad for concurrency but actually you know in certain applications having public or Global State uh this account you know this account based model can actually be useful so on-chain State on-chain execution is actually sometimes a good thing sometimes a desirable thing um one example is like escrow for uh so when you put something in escrow or you want to do it in a decentralized way on chain State can make this programming such a thing super super easy so is there a way we can combine the record model with on-chain State and execution so that we have this hybrid model that lets users kind of choose a sliding skill of privacy and also you know get you know the power uh The Best of Both Worlds here really and turns out we can so mappings are an experimental feature on on Leo and in ilio but these are essentially similar to mappings like you have in solidity um they're effectively maps from a key type to Value type in this case that you have a mapping balances that maps from addresses to u64s so how do we actually interact with mappings here we have a modified version of the original transfer function a trans transfer transition and yeah let's walk through it let's see what the what the differences are so first of all we added two public modifiers for receiver and amount in this case the way this transfer function is going to work is that it's going to take in a sender's record uh return the sender a new record with the remaining balance but then invoke uh and invoke some on-chain execution that updates a mapping on chain with the receiver and its new balance and effectively what this is doing is it's taking a private token a private a private number of tokens Trends and transferring some to the receiver publicly so that everyone on chain can see um the receiver's New Balance so on line two we we calculate the difference we construct the record for the sender the remaining record and then on line eight we return the record back to the sender and we we use a then finalize invocation to indicate that after uh creating this record or doing your all after performing your off chain execution on chain you would like to invoke a finalized block with these with the receiver and amount as arguments and a finalized block is a block of code this block of code here um and it it is uh each each transition function can have a finalized block associated with it so you see how uh you have a transition transfer you can have a finalized transfer here the inputs to a finalized block must be public and uh in this finalized block what we're doing is we're taking balances incrementing receivers entry in that mapping with the new amount that we'd like to send so how does this work on chain so here we have a network there's some validators the network contains a ledger with Alice's record and it also contains a mapping balances with keys and values Keys being addresses and values being uh the amounts uh allocated to each um address so first Alice will query the network for an encrypted record note that only Alice can see the data of this record then she will execute the transition transfer locally so what that does is she she to do that she provides Bob's addresses input the amount she'd like to send the transition transfer produces a new record containing Alice's remaining balance and passes through the arguments to the finalize block and then the transition transaction transition also produces a proof so note that this is all done locally and this is all done within the body of the transition so if we're looking at the original code here everything that was just executed is from lines two to eight so now now that Alice has kind of executed a transition locally she now produces a transaction and sends it to the network so in this transaction we have all the outputs of our transition and what the network first does is that it verifies the proof If the proof doesn't verify the network drops the transaction no state is updated but if the proof verifies then the network stores the new record and then updates its mapping with Bob's new value and this is effectively how we can combine uh off-cheat execution and on-chain execution and in the off chain world we really can leverage privacy scalability you can Define all kinds of computation off chain run it in a snark and prove it in a short time and with the on-chain model we can you know have some more complex interactions and now allow for some of their stuff that are originally possible in the account model um at the expense of in this case still sacrificing some privacy but getting you some more expressivity uh with it all right um so that concludes the the Deep dive of the language so for the for this purposes so it looks like we got about like nine minutes of time so I think the best way we're going to do this up is we're going to walk through uh an auction example uh we won't do a live coding but we'll at least walk through walk through the application get a feel for uh how it's designed and then we'll look at how to deploy you know an application like hey pranav also it's Joe just so you know there's not like a particular hard stop so if you want to keep going you can and I think many of the people in the audience are to hang around it's not just going to stop at 11 uh but if you want it you know if you want a hard stop at 11 we can do that too it's just totally just wanted to let you know it's a completely up to you man all right sounds good appreciate it I'll be um we'll go with we'll just walk through the example um it should be pretty illustrative I think and um I'll Stick Around for questions after uh because I'm sure there might be some uh lingering all right let's see let me just switch this out cool um sweet okay everyone can see this um so this is the auction example in the workshop repo and this should be included in uh the developer resources um so let's let's just walk through it um just step through the code a bit and stop through the design so we defined a program auction.alia um and with this application we're going to Define some records that are associated with this application the record we're going to call it a bid a bit it takes uh the first two fields of a bid are owner and Gates required fields and in a bid the data that's important here is uh who the bidder is the amount that was bid and whether or not this is a winning bit so with these three pieces of application State we're going to be able to implement private auctions now to clarify a little bit here in this auction model we are we are guaranteeing privacy with respect to the bidders uh the auctioneer or the party running the auction is able to see all the bits and we're assuming that the auctioneer is semi uh semi-trusted here or is a trusted party there's no collusion between an Auctioneer and a bidder so so you know there's no there's no cheating in in that in that form um this construction could be improved to actually provide privacy against Auctioneer as well but uh that's a little bit more complex and we're going to um just keep it simple for now so first we're going to define a transition which allows someone to place a bid uh the the transition Place bid takes in a bidder an amount is private input and produces a bid a record the only check is this is actually a very simple function all it's doing is minting a record and the only thing it checks is that the the party who called the function is in fact the bidder and why we have this check is to ensure that you know another person can't come along you know let's say Alice bids um some amount Bob can't come along and just you know up her bid uh maliciously so this is how we can place a bit and now let's define how we can resolve a bit so this function resolve takes in two bids as input both are private and produces a new bid as output this function we wanted to we want to design this application such that it can only be called by the auctioneer so here we've hard-coded an address for the auctioneer and we checked that the caller of this function can only be uh the auctioneer and to resolve the bid it's very simple very straightforward um you check that the amount you check the amounts in each of the bid records and uh select the greatest one and ties are broken by order so for the person who submitted first or gets is inputted first uh uh we'll take it in case of a tie and then finally we have a function called a transition called finish which takes it a bit and updates its state to indicate that it's a winning bid and this function we also want to restrict that it's called only by an Auctioneer so we check that only an Auctioneer can call it and we just essentially return the same data that was in the original bid except flip the flag is winner to be true and in doing this we actually kind of arrive at a pretty cool construction for private auctions that's very simple um it's doesn't require any sophisticated code but really relies on the fundamental properties of the ilio stack and the you know some nice cosmetic stuff from the Leo language to make it you know really really simple logic and let's kind of like go through a little bit of like how we can like build these build these applications um or use the Leo language or the Leo compiler um so I'll just I hope this is the font size is the the font size okay yeah I think it could maybe use a little Zoom especially for the people on mobile but yeah that's perfect all right cool so uh Leo provides a CLI um are there a couple of uh commands that you can employ um Leo knew essentially uh initializes a new directory with um essentially a new Leo project for you with some templating uh we all need to use that for now so what we're first going to do is do Leo clean so I'm going to clean my old build uh I'm going to do Leo build so what this does is in that process that I described earlier the Leo language translates this uh high-level program into a Leo instructions ilio instructions um essentially invokes the AVM which parses and synthesizes a circuit a mathematical representation of the program underneath and really this uh the synthesis process is actually quite involved and um as you can see dominates uh much of the execution time here but this you only do the synthesis when you're actually trying to submit a proof during development you don't need to do this um but for this case we will so we build some um we built a a Leo program and what we have here is a directory build and in build we have some like provers verifiers so these relate to the mathematical representation of the program we also have an Elio instructions file and this is um this is alien instructions there's some more resources out there but um this is effectively what the intermediate representation looks like so we also have um in our repo just to kind of make things a little bit easier is a script run.sh which effectively invokes um invokes Leo to you know just make make running this program a little easier so what I'm going to do is I'm going to uh let's see Max out this and then on the auction so we have some like you know commands to make this pretty um but in step one uh the first bidder places a bit of ten uh we compile um our program and execute uh aliod.

place bit the output of this function is a record and as you can see this record is owned by the auctioneer so only the auctioneer can see what this record is if let's see if I can yeah and then the second bidder places a bid of 90. and again this record is only owned by an auctioneer and then finally the auctioneer takes the two bids calls resolve and uh since bitter B was a bit a higher amount creates a new record with bitter B being the owner here and our returns that is winner is true uh so all this this example we had to do a little quick one here but it's all there in the workshop repo you can step through it we also have included a guide um so a step-by-step like you know developer guide where you can actually walk through you know we kind of give you a walk through of how to build this application what the logic is and how like the interactions work but hopefully you got a taste for what um you know using Leo uh looks like one quick thing I want to do is show how we can deploy applications so for those of you have a little bit more time I'm going to show you a prototype tool that we've been working on called slingshot and slingshot essentially allows you to uh spin up a local development node and um essentially run your programs locally test them without having to you know do the heavyweight deployment of you know going to test net and whatnot and effectively what we're kind of envisioning for this tool is something you know maybe something like ganache so let's let's take a look so slingshot is publicly available it's a prototype um and we'll also include a link for it in the workshop resources but yeah let's let's take a look so here on the left we have uh we're invoking the Elio SDK with uh some command ilio account new what this does is it generates you a new private Key View key and address which you can use when you're developing on the two left screens we just looked at uh the program.json which is a file that exists in each Leo project and that file contains some important data about you know for that program what some development private keys are for each of them so the important thing to note is that you know we have two addresses here two private keys that are unique and what we're going to do on the left is spin up a slingshot node with um a private key that we created earlier so slingshot will take some time to spin up and then it's going to start a server to which you can like initiate requests so slingshot has a faucet which you know kind of helps spin up uh being able to deploy or deploy and run applications so we're going to send to the account on the top right um a hundred uh a hundred credits and uh on the left we see that you know the the transfer transaction is executing and Just for kicks we're gonna also pour uh one more uh support another 200 credits and what this will do on the right is create another new record with 200 credits inside of it so one thing you want to be able to do is query for um the records that exist on chain so so here I'm going to attempt to query slingshot but I'm going to mess up the command as you'll see and and I figure it out so essentially um with slingshot you have a couple commands available to you to um get to get tokens to your accounts and then also see the records that have been created across the execution of this development node and you can use these records when you're also now executing new programs and whatnot so what we'll do here is uh for so right now what we did was for the auctioneer which is the top right we have poured some amount of records for the auctioneer we're also now going to pour some uh Records or sorry pour some credits for Alice who is going to try to make a bid so on the auctioneer side we'll first deploy the program and this is done by invoking slingshot deploy and as you can see once we've invoked that deploy transaction a bunch of stuff starts to go on inside the local node it starts to read the program create a a mathematical representation of it and uh store that to the on chain or in this case on the single node this process actually takes a bit of time um as we as you already saw earlier when compiling when compiling Leo programs we need to the X the the synthesis process is very involved but once it's done let's see we're able to deploy the program oh and I guess uh it gets a little cut off here that's too bad um so and I don't know if you can see the bottom uh left or bottom right but essentially we call slingshot execute yeah uh auction Place bid the first execution is a valid bid we use it with Alice's address and you see that um you see up on the left you know we execute Place bid the second invocation to placebid uses a different address actually the auctioneer's address and the node fails to run and this is the check that we had earlier to make sure that only uh the caller is the person um uh creating the bid and yeah this is still a prototype tool there's a bunch of stuff we can Workshop here um what we're really interested in is improving the UI adding features that developers want to see when they're locally developed when they're you know testing their local developments and we also want to really like kind of see just kind of get feedback and explore how we can make this tool into something useful in the ecosystem and with that thank you for listening Elio is written in Rust it's all open source it's all up on GitHub there's also a workshop repo like I said um that contains a bunch of stuff on how to get started on development and we have a Discord and Twitter so please join please be a part of the community and um thank you so much for for listening thank you thank you pronov that was amazing uh you know as usual you guys crushed it so really appreciate it I'm sure everybody in the audience really gotta you know a great understanding about how to work with Elio uh this was definitely a great follow-up on you know Anthony's kind of just like high level breakdown on what Elio is and what you guys are doing um you know thank you everybody in the audience who attended this is generally the time where we just make room for questions uh I do see actually let me double check uh earlier on there was somebody in the audience who had a hand raised so what we do uh for anyone who hasn't been here before is you can actually raise your hand in the controls on the bottom of your screen or your phone uh if you raise your hand we can pull you up on stage to ask your question uh to engage with the panel and if you would rather just drop your questions in the room chat a little more shy and just want to drop a question please do I do think Sean did we have have some questions back in the feed I I thought I saw uh you know we have a few here I don't want to see yeah so it seems like Josh Josh if I'm mispronouncing your name I'm sorry Josh Meyer um Meyer mayor has uh has some questions here um did you maybe want to raise your hand and come up Josh or or if you don't raise your hand in the next 30 seconds I'll just ask your questions from chat um where are you there should I Sprout them up okay cool Josh what's up man how are you just unmute oh can you hear me nope you are honorable uh thanks for joining us thanks for you know asking questions and being engaged uh you know let's let's uh what do you have for us yeah that was a great uh presentation um I'm setting up a Leo learner group and we're going to be doing some lower level basic uh starting for anybody who had trouble following along with that we'll take this we'll break it down uh we'll get your feet wet you don't have to be a programmer to learn uh Leo can be your first language that you learn on and that's okay so um we'll be coming out with that in the next few weeks we're having our first meeting this week so hey Josh just before you continue I would say you know uh for everybody in the audience anybody who was like you know new to this trying to follow along interested in the engineering side is a builder or is in the hackathon or or not I'm just interested in building on Elio connect with Josh through antra and Josh I would suggest you know like engaging the people in the room make some connections and actually you can host that meeting digitally as well if it's an in-person thing you can host it digitally here on ontra and kind of do like a follow-on I know sometimes people have a tendency to do like event After parties so you know if anybody wants to host like an after party and get in and kind of discuss the content uh that's another thing people do just if you're interested in doing that you know start a room and then drop the link here in the chat but go ahead Josh okay yeah sure yeah so what we're doing we're setting it up on Discord we're going to make recordings we're going to be posting them on YouTube we're going to do a walk through for the people that are in there get all the Kinks worked out and then we're gonna set up a uh series of videos that you can watch in a weekend so you can go from zero to writing your first uh smart contract in a weekend and then also we're going to teach mob programming which is where you get a group of people together and you all know programming so you can all be productive in making that happen um and I'm on Discord I'm at Josh on Discord I'm a moderator on the Discord so you can reach out to me also there um but yeah so my my question I had you said about the transactions and you can't have two transactions happening at once so what's the throughput on transactions um how long would it take for one to clear and is that something that's going to scale or is it going to start out kind of at the limit yeah um so I guess uh sort of like kind of clarify clarify a couple things there so with the uh account you know I did with that augmented account model we didn't really have that much throughput no concurrency I think so with this new record model you now do have this concurrency and I don't have the numbers off the top of my head I think um Colin has some um has some rough numbers here in the chat uh but effectively uh I believe like so even though like you have like a certain number of transactions per second you could actually like really like increase up the throughput by encoding more of your computation inside uh that that's done offline uh in the snark so suppose that you can only do one transaction but you actually make it a really big one maybe it's uh a roll-up actually of a bunch of other uh you know State transitions this is something that's possible and um that's how you can actually like boost up throughput um that being said I'm going to say that that's a sort of an exploratory construct uh no one's kind of instantiated yet but it's still it's still like natively or primitively supported by architecture okay awesome and then the other question I had was um okay so I'm kind of uh fuzzy I read the definition that then for the link that was posed for transition it's still a little hazy is there something that's uh similar in Rust programming that transition would be or is this just a blockchain it's just a blockchain thing um really like if you if you think about it both Transitions and functions are functions in the traditional programming sense transitions just have this extra notion of uh doing something on the blockchain okay all right that's clear okay thanks a lot that was great I really like that yeah thanks Josh also really appreciate uh kind of the interest and like you know actually creating a Leo learning group we love it when people like take initiative and you know start learning stuff so there's any stuff we can do to help support that uh let us know uh super exciting same here Josh like we're we're all about learning community so you know and we love Alia so if there's anything we can do to support you please let us know okay great thanks guys foreign chat so now if you guys have any questions feel free to drop them or click that raise hand button but with that said uh more than happy to kind of wrap things up here oh we got we got one more we got I think we got time for one more I'm gonna pull up Andy over here hey Andy how are you gonna have to unmute bottom left hey guys can you hear me yep yeah nice nice to be here and listening to all the things you just said this is really cool um so uh um yeah I'm just having a quick question Ashley I'm I'm not really a helper myself I'm not I had a community Builder so um I'm building you know communities of developers uh in Southeast Asia in Vietnam in Thailand Philippines and just wondering if you guys are interested in you know raising a community of uh you know ideal builders in Southeast Asia for specific or Vietnam because if you are interested in that then yeah we could probably uh discuss more about that yeah this is something we're definitely interested in and actually um in in our so uh right here we have a link for the ilio Discord and in the Discord we have some um we have some I think we have some channels already or some channels through which you can go through to uh start spinning up communities if they don't exist already and uh the modern our moderators on there and our community members and our head of community actually uh Viv is Super Active on there so um I that's probably the best way to go through and uh get the ball rolling on these discussions all right cool cool I would uh drop a um what's up there and uh yeah we'll see what we could do next yeah yeah that's that'd be great um oh sorry uh yeah just just saying yeah what what general plug um on the Discord uh a lot of us are actually pretty active especially the engineering team for like answering questions that's probably the the best channel to reach us if you need support help um so yeah just kind of just throwing that out there I'm gonna I'm gonna keep this one quick uh because I think we're you know we're running up on on kind of a sensible time here uh Andrew rossborough dropped into the chat he said can you discuss a little more on the asynchronous nature of finalize statements yes so uh that's a great question um so finalized statements essentially execute in um in the same way as uh ethereum transactions execute or in a similar model so while you can make a bunch of finalized since while you can like make a bunch of or make a bunch of modifications to um some on-chain mappings via a number of finalized invocations uh the order is essentially uh sequenced by the block producer and you know they can all go through but uh it sort of just kind of Falls prey to some of the similar limitations I think consistency limitations that exist um uh on ethereum effectively does that answer your question Andrew um yeah I think so well I think I was curious oh uh he said I think I was curious if there were any caveats to it like in situ I guess uh maybe this might be a little bit more of a back and forth but um if we're if by caveat you mean like gotchas maybe will the data always be committed on chain to the mapping yes it will always it will always make it it'll always be committed as long as the proof um the proof is about so it'll uh there are a couple caveats it'll make it as long as the proof is valid uh associated with the finalized transaction and then as long as the finalized transaction itself uh does not uh you know either you know like error out or um uh is you know runs too long and halts okay now uh Andrew good to meet you actually yeah we've been talking a little bit um so so I guess what I'm curious about asynchronous and if you're income rating mappings and that would be uh the the main function I think finalize does is let you issue increment statements and that makes um yeah would it be out of order like with the order be served that the final I statement was called you said it was up to the Rock producer to choose when to execute the online statement yeah so what's going to happen here is like uh essentially like let's say you have um two transactions in a block that both increment the same um entry in a finalized in a mapping on chain okay um let's say both of these transactions are set to the network uh their proofs verify uh you know some some person verifies both of their proofs and puts it all in a block the order in which those mappings are incremented are dependent on the order in which that block producer included the transactions because that's how that's the order in which the finalized blocks are going to execute now one thing that's nice here is that um an increment and decrement or increment and decrement operations are or at least let's let's say this increment.operations are monotonic so uh order ordering doesn't matter okay for right but it does this is an issue in the general case um when you have when you are getting loads in stores ordering does matter okay I was curious if you're incrementing a mapping and then we're turning a record with the current now or something like that I guess you wouldn't want to access the mapping directly rather than copying it to a record because that record could become updated with other transactions yeah that's exactly right yeah okay yeah a great question love it well with that I think we'll go ahead and wrap things up as always you guys had an amazing presentation I uh I'm surprised there are any questions you guys literally answered all of mine it was it was honestly a great presentation really appreciate you guys coming on um if there's any final words best way to reach you guys any of that stuff feel free to drop that now and then we can go ahead and wrap things up I have uh one thing I'm gonna share really quickly here uh just just as kind of like that I bought for my two-year-olds right and pranav check this out ready so he colored it a little bit but here we go I'm just gonna get down to it Alice has the coin Bob has the Apple [Laughter] that's awesome so that definitely like touched you know touched me with the Alice and Bob examples I appreciate it yeah uh we should we should get your uh kid you know learning the Alias stack uh get him started earlier I'm I mean this is this is the intent right I have I mean he's got blockchain for babies uh you know electrical engineering for babies all that stuff so yeah we're definitely putting them on the path for sure yeah that's awesome cool well thank you so much guys uh Colin actually that's a great question I know you're a Leo team I also just want to give a quick shout out to Colin Chen thank you for like sharing all the resources staying on top of it managing the chat making sure everybody has access to all the docs and stuff uh and repositories I really appreciate it man it's uh definitely like you know makes a dynamic experience so thank you definitely on top of it it was awesome and uh the the talk will be posted so we process the recordings once the recording is processed this is a little bit of a longer talk it'll probably take a few hours to you know maybe potentially overnight depending on what's in the queue uh but once it's processed we'll shoot it over to uh Anthony via our recorded files uh and then we also send it to uh Alice at hacker Earth so if you're on the uh hackathon page at hackerearth.com which I will share really quickly right here uh there is a workshop recordings tab where that that will be available once they put it up but other than that if you're not in the hackathon and you want to reach out to like anybody on the Elio team they'll have a copy of that within the next day or so and can probably share if they want to so thank you so much everybody we really appreciate it hope everybody has an awesome day uh you know thanks again Elio for sharing and thanks for everybody for coming and as I always say this is the start of the conversation so connect continue and let's keep the dialogue going and you know let's uh let's all hopefully build some really cool things for the sackathon you know maybe submit a couple game changers built on Elio uh you know I definitely am uh and quickly becoming an Elio Fanboy you guys you guys are putting it together and putting it down and uh it's really cool what you guys do it so I appreciate you thank you everybody so much uh we'll see you soon