Aleo 🛠 Powering Private Applications with Zero-Knowledge Cryptography

[Music] all right so hey everyone um my let me just actually start some timers here all right [Music] um cool um so hey everyone uh my name is Prav it's good to meet yall and uh today I'm gonna introduce the Leo programming language and show you how we can use it to develop private applications on on the AL stack so over the past decade we've really seen how web 3 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 web 3 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 to endpoint this is insufficient now one way we can remedy remedy this problem is by leveraging cryptographic constructions like Zer 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 Alo stack uh we'll start first by building some intuition for uh cryptographic Primitives and the State model that Alo builds upon and then we'll go into a deep dive of the Leo language and learn how we can build private programs and then finally uh 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 highle Concepts and I think there there will also be people in the chat uh helping answer questions uh 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 uh Alice can encrypt a message to and send that message to Bob and be sure that the contents of her message hasn't been leaked and this is what we 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 uh 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 F and a publicly known output y a zero knowledge proof is a proof Pi that allows me to claim me theover to claim that I know some private input X such that FX is equal to Y without actually needing to reveal X to you and uh this is the core idea we'll build upon today uh in reality Zer knowledge proofs are way more complex and we're really uh glossing over some fancy math and um 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 nark 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 Zer 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 uh 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 uh a zero knowledge proof is non-interactive so what this means is that the prover um the party generating the proof 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 soundest means is that any statement that can be proven True by the proof system is actually in fact true so now now that we have some really high level understanding of zero knowledge proofs let's switch gears a bit and uh discuss decentralized ledgers so blockchains or more generally decentral 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 um decentralized ledgers work so the left here we have a Ledger um on each row you have uh an account or an application Associated code and data and this is over uh 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 uh an identifier for the application some in data and a signature authenticating that transaction each node on the network Rec uh 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 reexecute 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 um an eth one style uh Network and each block requires 5 Seconds of compute this amounts to 1500 15,000 seconds or about four hours of compute uh 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 reexecute and for them to do that they need to be able to see uh 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 uh there are a number of use cases where uh 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 this 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 bya Global state so on the left here we have uh a user and on the right um a user with its Associated address and on the right we have a simplified model of global state in it you see you have an account its address its code and storage and you can think of storage as persistent data here so when a user creates a transaction uh 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 a block every node on the network re-executes it and induces a transition on the account State from from its original state to a new one here in this transition we see that um 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 uh 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 uh compromises privacy so let's kind of walk through an exercise where we try 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 what 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 senders key and instead of providing a signature we'll provide proofs that that the transaction updates or uh produces a 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 and 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 count storage is ENC 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 uh because we are reasoning about uh 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 polinomial and by doing so we can reason about it in a proof system and uh start constructing some uh snarks out of it so let's put this all together so in this new model you have uh so 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 trans uh transaction it submits the address it's interacting with um it submits uh some encrypted data a fee and proofs and these transaction effectively prove that each state transition um is made on encrypted and committed State and if the network accepts uh verifies these proofs finds them to be correct then the account state is transitioned into the new one note that uh storage is always in 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 uh 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 prettyy 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 uh before uh you have that a user needs to take the entire program State prove something about it in a transaction and then upload uh update that to the network so if user one comes along submits a transaction and while um the network is verifying and updating it user two comes along and tries to submit a transaction or reads the network State and tries to submit a transaction if user one's transaction goes through users two 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 the transaction uploaded the network has to get verified and then only after that user two can come along read it uh 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 uh because you're still uh sending the address of 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 sort of review some of the properties it gives us so first of all we did solve uh Ledger re executions because we're Computing State transitions in a zero zero knowledge proof offchain uh the 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 uh data stale data effectively so how can we do better and really this is where we're kind we're going to kind of like Drop The Core intuition here so the problem is that for in this model in this our 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 another 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 ILO actually um is constructed is constructed on so in the record model a decentralized ledger tracks each record via Global State um 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 its code and a set of records and note that records are encrypted on chain so there's no data that's being leaked there when a user submits a transaction action 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 uh 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 uh 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 uh that we use today so what does this give us so like here we have concurrency um because application state is sharded uh by for each user's context a user only needs to op operate on their own context 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 record serial numbers um after you accept every transaction uh this construction is actually uh this is a high level overview of this construction and there's actually some more uh technical details uh one great resource for this is the zei paper and really recommend um if anyone's interested to check that out but uh let's let's let's round this out so what do we actually prove in 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 um record owners are not leaked so in this model you have effectively account privacy oop sorry that's not it uh you have 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 uh state of the application to make an update so updates are effectively charted and just localize 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 uh at the same time and both will be verified by the network and both will be consistent uh with with uh the semantics of the application cool so kind of putting this all together a bit um we talked a we talked about zero knowledge proofs we talked about the record model and together these are instantiated in Alo and what Alo 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 and the least programmable to its right is ethereum which improves upon Bitcoin by adding programmability and to the uh and above Bitcoin you have zcash which improves on bitcoin with privacy Alo 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 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 Pi that attests that F of uh that I know X such that Y is equal to F ofx now the Le now one question when you're actually using snarks is how do you encode F how do you um specify the program PR the program predicate and this is where the Leo language comes in Leo is effectively a highle program programming language that's compiled into Alo instructions before it serialized into AVM bite code and the compiled bite code is deployed on chain and visible to all participants in the network the AVM or the Alo virtual machine is a virtual machine that executes AVM bite code and produces a a ZK snar or proof and the Alo virtual machine is essentially executed offline or offchain a user when they're constructing or uh creating a a transaction they invoke the Alo virtual machine it produces a proof they package that into a transaction and send it to the network now the the details of ILO instructions AVM bite code Alo 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 uh like all programming languages provides some uh data types for users uh it has 16 primitive data types and also allows users uh to Define their own composite data types now some of these might be familiar uh coming from other programming languages you have booleans you have integers you have structs um you also have strings but uh the orange uh 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 Fields uh 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 the these are akin to theorum addresses the little thinking a little bit deeper a struct is a composite data type which um contains any a number of fields each of these fields could either be a prim PR 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 on line on from line one through nine you define a program scope and it's Associated name hello. alio and on line two we have a a function Fu and on 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 Fu takes in as input X and Y produces u64 as an output and Returns the difference between X and Y transition main quite simple invokes Fu and returns it directly now the distinction between a function and a transition is that a transition forms the external interface of your contract uh this is what uh are the transitions that are actually uh 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 is effectively like helper functions in your code but when interacting with your program from uh 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 of 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 uh 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 uh 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 uh in some cases you really want to say some inputs are public and you know really control visibility uh in A fine grain 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 honors 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 uh iterations they 10 periods um we take in as input uh capital a public rate and just calculate the interest via simple for loop I think this should be familiar to most uh program grammar is 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 con uh static integer literals and the reason for this is that when when you're actually describing your program predicate at in a snark it needs to be deterministic and finite um in or fin of a finite bound of a finite size so we can't have non-deterministic circuits or circuits that or programs that change in size uh 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 uh parameter iterations and iterations 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 uh you accumulate the interest acrw 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 uh circuit based languages so one thing to call out here is um this assert statement here um effectively what this does is um this gets compiled into Alo 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 aover 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 uh typescript uh for those that are coming from those uh languages and provide some of the uh 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 re Leo because Alo is 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 uh Records are very similar to structs except for the fact that they have two required Fields an owner which is the 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 um Alo credit uh associated with that record so you can think of um Gates is to Alo credits as gway is to eth as cents are to Dollars now with this model application state is encoded in records and users effectively own uh 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 our 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 Alo suppose we have some transition who 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 in reality here so um we're gon to in St sheet and look at this record model under the context of tokens so we're gonna in describe a a userdefined tokens in Alo and in Leo and we'll see how the record model enables uh this use case so quickly we have so some record token which has uh an owner and Gates as required and some balance for that token and now we have a function uh 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 um 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 uh calculate the difference between the center'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 uh 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 and let's take a look at with 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 Pi I also see here that I have a typo and um really in Bob's uh balance this should be a 3 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 a 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 uh 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 a we're going to sort of backtrack a little bit so earlier in the 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 onchain State onchain execution is actually sometimes a good thing sometimes a desirable thing um one example is like escro for uh so when you put something in escrow or you want to do it in a decentralized way onchain State can make this programming such a thing super super easy so is there a way we can combine the record model with onchain state an 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 um in Leo and in ILO um but these are essentially similar to mappings like you have in solidity um they're effectively maps from uh an uh type to a value type in this case that you have a mapping balances that maps from addresses to u4s so how do we actually interact with mappings here we have a modified version of the original transfer function trans transfer transition and yeah let's walk through it let's see what the what the differences are so first of all uh we added uh two public modifiers for receiver and amount um 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 an invoke some onchain execution that updates a mapping onchain with the receiver and its new balance and effectively what this is doing is it's taking a private token a private uh private number of tokens trans and transferring some to uh the receiver publicly so that everyone on chain can see um the receiver's New Balance so on line two we uh we uh calculate the difference uh we construct the record for the sender the remaining record and then on line eight uh 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 off after performing your offchain execution onchain 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 receiver's entry in that mapping with the new amount that uh 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 contains a mapping uh 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 her encrypted record note that only Alice can see uh 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 like to send the transition transfer produces a new record containing Alice's remaining balance and uh passes through the arguments to the finalize block and then the transition transa 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 a transaction no state is updated but if the proof verifies then the network stores the new record and then updates its mapping with uh Bob's new value and this is effectively how we can combine uh offchain execution and onchain execution and in the offchain world we really can leverage privacy scalability uh you can Define all kinds of computation offchain run it in a snark and prove it in a short time and with the onchain model we can you know have somewh complex interactions and now allow for some of the 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 the purposes so we're it looks like we got about like nine minutes of time so I think the best way we're going to do this is we're going to walk through an auction example uh we won't do a live coach but we'll at least walk through walk through the application get a feel for how it's designed and then we'll look at how to deploy you know an application like this hey Prav 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 would 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 just totally just wanted to let you know it's up completely up to you man all right sounds good appreciate it I 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 step through the design so we Define a a program auction. Alon um and with this application we're going to Define some records uh that are associated with this application the record we're going to call it a bid uh bid 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 bid so with these three pieces of application State uh 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 um guaranteeing privacy with respect to the biders 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 is 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 the 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 and amount as private input and produces a bid um 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 bid uh maliciously so this is how we can place a bid and now let's define how uh we can resolve a bid so this function resolve takes in uh 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 hardcoded an address for the auctioneer and we check 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 F the person who submitted first or gets is inputed first uh uh we'll take it in case of a tie and then finally we have a function called a trans position called finish which takes in a bid 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 uh 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 uh the Alo 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 the s the 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 there are a couple of uh commands that you can employ um Leo new essentially uh initializes a new directory with um essentially a new Leo project for you with some templating uh we won't 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 highle program into Alo instructions Alo instructions um essentially invokes the AVM which parses and synthesizes a circuit a mathematical representation of the program underneath and really this this uh the synthesis process is actually quite involved and um as you can see dominates um much of the execution time here but this you only do this 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 build a Alo program and what we have here is a directory build and in build we have some like provs verifiers so these relate to the mathematical representation of the program we also have an Alo instructions file and this is um this is Alo 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 REO just to kind of make things a little bit easier is a script uh ron. SSH 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 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 10 uh we compile um our program and execute aliot a place bit the output of this function is a record and as you can see this record is owned by uh 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 um 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 bidder uh B would bid a higher amount creates a new record with bidder B um being the owner here and our returns that is winner is true uh so all this this example well 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 uh I'm going to show you a prototype tool that we've been working on called slingshot and slingshot essentially allows you to uh 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 testnet and whatnot and effectively what we're kind of envisioning for this tool is something you know maybe something like a nosh so let's let's take a look so slingshot is publicly available it's a prototype um H and we'll also include a link for it in uh the workshop resources but yeah let's let's take a look so here on the left we have uh we're invoking the Alo SDK with uh some command Alo account new what this does is it generates you new private Key View key and address which you can use when you're uh 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 uh 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 we're what 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 100 uh 100 credits and uh on the left we see that you know the the transfer transaction is executing and Just for kicks we're going to 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 100 credits inside of it so one thing you want to be able to do is query for um the records that exist uh on chain so so here I'm going to attempt to uh 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 uh 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 uh read the program create a 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 ex the the synthesis process is uh very involved but once it's done let's see we're able to deploy the program oh then I guess I it gets a little cut off here that's too bad um so 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 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 place bid uses a different address actually the auctioneer's address and uh the node fails to run and this 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 uh improving the UI adding features that uh developers want to see when they're locally devel uh 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 ILO is written in Rust it's all open source it's all up on GitHub uh 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 uh be a part of the community and um thank you so much for for listening thank you thank you perov that was amazing uh you know as usual you guys crushed it so really appreciate it I'm sure everybody in the audience really got a you know a great great understanding about how to work with Alo uh this was definitely a great followup on you know Anthony's kind of just like highle breakdown on what Alo 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 rais 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 some questions back in the feed I I thought I saw uh you know we have a few here I don't want to let's just see yeah so seems like Josh Josh Josh if I'm mispronouncing your name I'm sorry Josh Meer um Meer or mayor has uh has some questions here um did you maybe want to raise your hand and come up Josh 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 just brought them up okay cool Josh what's up man how are you just unmute oh can you hear me yep you are audible 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 we're having our first meeting this week so hey 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 not and just interested in building on Alo connect with Josh through entra 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 inperson thing you can host it digitally here on entra and kind of do 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 Afterparty 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 walkthrough for the people that are in there get all the Kinks worked out and then we're going to 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 with that augmented account model we didn't really have that much throughput no 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 uh 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 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 rollup 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 is still it's still like natively or primitively supported by our 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 for the link that was post 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 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 in 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 same here Josh like we're we're all about learning community so you know and we love Alo so if there's anything we can do to support you please let us know okay great thanks guys absolutely and I don't see any other hands raised or any more questions in the room chat so yeah if you guys have any questions feel free to drop them or click that raise hand button but with that said uh board 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 I'm going to have to unmute bottom left hey guys could you hear me yep how are you hear yeah nice nice to be here and listening to all of the thing you just said this is really cool um so uh um yeah I'm just having a quick question actually I'm I'm not really a reler myself I'm kind of a community Builder so um I'm building you know community of developers uh in soueast Asia in Vietnam in Thailand Philippines and she was wondering if um you guys are interested in you know raising a community of uh you know Alo builders in uh s Asia for specific or Vietnam because if you are interested in that then yeah we could probably 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 Alo 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 mod our moderators on there and our community members and our head of community actually uh Viv is Super Active on there so um 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 whatsa there and yeah we'll see what we could do next yeah yeah that's that'd be great um one just Qui oh sorry uh just just just just saying yeah one one 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 going to 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 Rosboro dropped into the chat he said can you discuss a little more on the aerous nature of finalized 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 finaly since while you can like make a bunch of or make a bunch of modifications to um some onchain mappings via a number of finalized invocations uh the order is essentially uh sequenced by uh 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 on ethereum effectively does that answer your question Andrew um I think so 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 a little bit more of a back and forth but um if we're if by caveat you mean like gotas maybe yeah well 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 Val so there 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 um you know either you know like error out or um uh is you know runs too long and hals okay H brought front off 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 incrementing mapping and that would be the main function I think finalized does is let you issue increment statements on that basis um yeah it would it be out of order like would the order be preserved that the finalize statement was called you said it was up to the lock producer to choose when to execute the finalize 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 sent 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 increment and decrement or increment and decrement operations are um 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 this is an issue in the general case um when you have when you start getting loads in stores ordering does matter okay I was fous if you're incrementing a mapping and then returning a record with the current M 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 be come outdated with other uh transactions yeah that 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 were 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 uh we can go ahead and wrap things up I have uh one thing I'm going to share really quickly here uh just just as kind of like that I bought for my two-year-olds right and Prav check this out ready so he colored it a little bit but here we go I'm just going to get down to it Alice has the coin Bob has the Apple that's awesome so that definitely like touched you know touched me with Al Bob examples I appreciate it yeah uh we should we should get your uh kid you know learning the ilas stack get him started early huh I 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 we're definitely putting him on the path for sure yeah it's awesome cool well thank you so much guys uh Colin actually that's a great question I know you're Alo team I also just want to give a quick shout out to Colin chin 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 and repositories are really appreciate it man it's uh definitely like you know makes a dynamic experience so thank you definely 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 uh recorded files uh and then we also send it to uh Ellis haacker Earth so if you're on the uh hackathon page at hacker earth.

com which I will share really quickly right here uh there is a workshop recordings tab uh where that will be available once they put it up um but other than that if you're not in the hackathon and you want to reach out to like uh anybody on the Alo 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 Alo 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 sathon you know maybe submit a couple game changers built on Alo uh you know I definitely am uh am quickly becoming an Alo Fanboy you guys you guys are putting it together and putting it down and it's really cool what you guys are doing so I appreciate thank you everybody so much uh we'll see soon