StarkNet:Recursion

Transcript

[Music] okay no response from my friends let me text okay okay i received the

command yeah i should start okay uh yeah that starts uh uh gm engine no matter where you are now and welcome to today's english seminar hosted by the dev learning and stock wire yesterday uh we had a very good session uh from lucas talking about the career 1.0 i believe that all of the attendees i mean got the basic knowledge about the career 1.0 and it may spare their interest of learning the technology and knowledge about the

stock wire and uh yeah today's we invite hungry yeah another developer ambassador yeah and the topic is about recursion proof so uh before i start before we start i'd like to i mean give you uh some context about the stock wire and the dapp learning community the stockwear is an open programmable ethereum layer 2 scanning solution developed by the stockwear that uses stark validity proof to enable option complete computation and on-chain verification and stock validity proof is secure reliable and efficient ensuring

that stock night is an infrastructure built for future mass options and and for the depth learning um i mean i'm from the dark learning community yeah one of the members and we are designed for developers to stack into blockchain depth development including defy ft dao and iron crypto projects and we hope we could give junior developers a feasible and easy to use blockchain debt learning roadmap and present some advanced i mean developers with a platform for communication and cooperation and uh

please note that we are we are non-profit organizations and uh now we uh we launched our uh project in the bitcoin 15 waves feel free to uh donate okay uh thanks for watching hurry and uh it's your turn and uh would you like to introduce yourself and i mean yeah okay sure background so hello everyone and thanks for receiving me uh it's a privilege to be talking with all of you my name is henry leoto i work at starkware as a developer advocate for stark.net so stark net as you mentioned is a layer two

programmable layer two for ethereum it's stark net starkware is the company who is building is currently building stark net and so i explained to people what stark net is and how they can build cool stuff on top of it i just want to mention that if you're interested in building depths and you want to learn how to build a dap on starknet we have a bunch of tutorials a bunch of links that you can check online we have a very extensive github organization with a bunch of practices and a bunch of workshops you can follow and you'll be able to write your uh your app on the most scalable layer 2 of ethereum currently

in no time so and if and if you have any questions uh feel free to reach out send us a message um we have uh we now have the spanish uh sorry um chinese speaking dev advocate in the team so we'd be happy to help you out and um reach out don't be a stranger would be happy to help you um yeah should i share my screen uh yeah start interrupts uh one more sentence uh yeah if you have any questions i mean during this speaking or stage please send a message in the comment area or in our discord or wechat group okay yeah thanks your turn

very nice so i'm now presenting my screen today i'm going to talk to you about a relatively advanced topic which is recursion so what is recursion exactly oh just give me a sec and what are we going to talk about today so i'm going to give you a bit of background on what we are what we do and then i'm going to talk about what what is recursion what it is we call recursion um and then i'm going to explain how recursion will benefit from i'm sorry how the networks

we operate will benefit from recursion i say networks with an s because we currently have two software uh two networks on top of ethereum that are running um which is one is stark net the ovary stark x and i'm going to talk about both and how they can benefit from redux from recursion yeah so first as a background let me explain a bit what are proofs what are starks what is cairo what is sharp and what is stark net so in

um in a nutshell what we call stark proofs and what cairo is are the following a stark proof is a way for a person to run a specific computation on their machine and generate a proof for this run for this execution of a program the very cool particularity the property of this proof is that if this person gives the output of the program as well as the proof to somebody else this person can

verify the output of the program without having to run it themselves it sounds simple but it's actually a very novel property in computer science it's not something that we've known how to do for a very long time the first concepts of computational integrity are trustless are essentially you know starks and snarts so sum up again i run let's take an example right so i'm going to run a program where i do generative art right and this heart would take a hundred years to generate on your

computer because it's very complex right but i have a very big computer so i run it on my machine and it takes me one hour if i give you the output what's how can you be sure that i didn't give you a random output how can you be sure that i gave you the output of running the program in the usual world you have no way of doing that the only way you can verify the output of the program is by running the program yourself which would take you a hundred years so it's not feasible now the cool thing is that when i run the program i also ran the program and i generated a proof now i can give you the output so the art will generate it as well as the proof and you can verify in a few minutes that the art is

is authentic that it was generated with the computer the computer i used now what makes this powerful is this difference in time um so let's say specifically it's what's written on screen if a computation takes me time t you can verify it for log time log t time right so the scaling factor is exponential right it takes you exponentially less time to verify the proof than it took me to generate it and to execute the program now cairo

as a smart contract language is essentially a smart i mean it's not a smart contract language it's a general purpose language that lets you write a computer program right and generate a proof very easily for that program so the the proof system i described the stark proofs i described basically are essentially mathematical concepts that are that are that manipulate polynomial equations not everybody wants to design polynomial equations with

specific properties to prove a program so our team basically came up with a set of polynomials that satisfy a specific constraint that reproduce the characteristic of a cpu so some basic operations on polynomials are allowed and from these basics operation we're able to design a higher level language which is cairo this is also the reason by the way you can't generate a proof for an arbitrary smart contract language you need to write your smart contract you you need to write your program in chiral because it compiles down to a specific set of constraints for a specific polynomial but cairo basically

lets you do that you have approver running the cairo program on input x giving the output y and the verifier can verify the proof which is nice now how do we use this in the blockchain world well the cool thing with verifying the proof is the following it's that verifying the proof is something you can run on a computer program but in fact since it's basic mathematical operations it's also something you can do inside a smart contract so you can write a smart contract that will verify a stark proof

in fact we wrote this smart contract and we operate an architecture on top of ethereum that is called sharp and that basically aggregates cairo program right compiles them into a single proof through approver and then sends them to the verifier on chain why do we do that as i mentioned verifying a proof is log t time you're running your program for t meaning that if

you run your um if you run a program for t time it will take you log t time to verify the proof if you run twice that program right so 2t it will take you log 2t times to verify the proof and the fact is that log 2t times is much smaller than 2 log t times right so aggregating cairo jobs like this allows lowering the verification cost per jobs right so and i'll talk a bit about that later on about the challenges with recursion but

basically with proving it's not just a you generated a proof and verifying it on chain there's a big engineering aspect into how do we make this scalable and efficient and we came up with this system that is called sharp for shared prover because you can have various entities so here you have immutable x on starkex sorer on starkx you have starknet the network will basically send batches of execution of cairo programs whether they be for immutablex or soror nft trading transactions or for starting a general purpose smart contract executions

and these execution are bashed into a big proof that is then then sent to ethereum in the verifier and the verifier is able to verify that the proof is correct and he is able to manipulate each outputs of this program and then these outputs can have some kind of impact on chain right so this is the state of stark net i mean of sharp a few weeks ago now today i'm going to talk about recursion so what is recursion exactly it's actually fairly simple this is the state of what we do right now okay you have an original program

and then you generate a proof for it and you verify it well now what we do is the following we run the program we generate a proof for it and we gen and we run a verifier program and this verifier is written in a provable manner and we generate a proof that we generated that we verified the previous proof right sounds simple and it is it's not that difficult to understand right i mean verifying a proof is just a set of mathematical operations so there's nothing preventing you writing a cairo contract that will

verify a stark proof and you can generate a proof that you verify the proof and in a nutshell that is what uh recursion is right does that make sense up until now yeah yeah and the fact is you can go even deeper than that you can verify the proof of the proof you can go as many layers deep as you want the only thing that will uh that is you are not going to get the same return of efficiency every time but you can get as deep as you want so now what we do you know remember the sharp program uh the diagram i showed you

before instead of just concatenating cairo programs we're now and you know you have sharp and you have you know different cairo programs that we concatenate and execute sequentially and then we get a big proof for all of these you know we're able to generate a proof for each separately so this will take less time than generating a proof for all of them sequentially because we're able to parallelize these and then we just have a batch that aggregates the proof and generates another one so we can have various programs that we get that we generate in parallel right so in other

words you can apply recursion sequentially or you can also apply for parallelization of tasks now obviously why do we do that because doing this allows to reduce proving proving time for the verifier and as you know since the verifier in our case runs on the ethereum virtual machine it has a cost it has a gas cost and so having a leaner verification makes it more cost effective and makes it cheaper for the user in the end which is what we care about

right now what can you do with uh with recursion now so that's the the theory now let's see how we will apply it in real life and how we started applying it in real life well the first thing is that it allows us to reduce gas costs on the networks we operate the reason for that is that basically you know there's a gas block i mean there's a gas limit per block on ethereum and i think there's a gas limit per transaction and so even if running your program takes t time

log t if t grows log t still grows right and so there is a limit into the dimension of t when you generate a single proof for a cairo program if you want the ethereum to verify it so technically this meant that there was a scalability sealing into what we were able to do with uh with starcx and there was a gas cost we couldn't go lower um now and for example here in this scheme so for example you have t steps right so you're you have here in the verifier you are forced to run program a

go through t steps you're forced to prove it and then you have to run program b and then you first improved it so the cost of verification is spread over program a and then another verification is spread over program b now what we're able of what we're able to do is basically instead of doing that we're able to have program a and we generate a proof for program a and program b and we generate a proof of program b and if instead of verifying two times in ethereum we verify them two times in

a cairo program and we generate a proof for that verification and we send this to ethereum all of a sudden instead of having one cost of verification spread over program a and one cost of verification spread over program b we have only one cost of verification spread over both program so you basically are able to divide and amortize the cost of verification over over your programs which in the end translates to savings for uh for users and this is something you can verify like you can uh you can do much

much at a much higher level right because you're basically able to do this various time above you know you can have program a program b program c program d and as soon as you hit a specific size you just verify it get down to log t and then you can aggregate these and you're able to in a sense scale your proving costs and amortize it much much much faster on all your [Music] on all your entities it basically becomes a game of how far you are in the recursion chain and

and you can define the cost per users depending not necessarily on the actions you make in the chain but based on your distance to l1 if i may basically the more proofs between you and l1 and the higher the complexity you can get in your program then another thing we started using recursion for is latency so this is the program i showed you before for sharp and so basically what we had is we had this different programs right

these different projects were running payloads in parallel each of them were running their network in parallel and these proofs were then sent to the prover who would have to then generate a big proof and then send it on chain this meant that for example imagine that each proof is generated every eight hours generating a proof takes time and so every time a a job at say for example imu tablex was finished so say they had gone through 100 blocks then at that point the 100 blocks were sent to sharp and then sharp would wait for the same thing

from solar air from stark net and all of these were aggregated and then the proof was generated and this would take a long time because it takes um because it may take a few hours until it is published right now what we're able to do with recursion is the following every time a job is received or even intermediate jobs can be sent you know we run a recursion job and so instead of having to run the job before sending it to ethereum instead of having to concatenate it you can start parallelizing and take jobs and generate proof for these

now when the last job arrives you can even aggregate these into smaller proofs and when the last job arrives you can just generate a proof generate another proof for everyone and then send it so basically it allows instead of waiting for everyone to be here and then generating a proof it allows compacting stuff as they go so that once you say okay the train goes everything that needs to be compacted in this final proof is smaller and so you have a shorter time to main net right yeah and this is in a sense uh and this also saves crafts obviously because this final proof here is the very

fiction of virus super so it's even uh this even is uh is cheaper um all right so these are things that we're using right now in production this is something that went in production recently and uh and we're already using it to decrease latency and to uh and to save cost now the other concept that people get really into is the concept of l free um and and i'm gonna get into it in a second everything that i'm that i'm referring to so

recursion is the fact to generate a proof that you verify the proof right now what we call fractal scaling is the fact that this technique allows you to scale your network in a bunch of dimensions you can you can scale it in the time dimension you can scale it into complexity dimension you can scale it in the layers dimension and this is the last one the this point i want to talk about right now you have ethereum and on top of it you have a bunch of networks to their stock net and their stockx and there are various instances of stock net of starkex

maybe i mean one day we will have a cairo verifier operated on starknet so basically the architecture you have on top of ethereum you know sharp which i presented earlier you will have sharp on ethereum but you will also have a sharp entity on top of stark net and verifying a job on star on stark net on this on sharp on stark net will be cheaper than verifying a job on sharp on stark on ethereum because it's further away and you generate the proof after that before you send it to ethereum and once you have a sharp operated on stark net it allows you a bunch of stuff and it allows you to run networks on top of

starknet and if you operate a sharp operator on that network you can run a network on top of this one and so on and so on what is really interesting is that these networks that you'll be able to run on top of starknet there are a few things the first one is that they can be of any kind of architecture you want starknet is a l2 on top of ethereum and it is an l2 that is written in cairo but you could implement other kinds of vm in cairo you could have started of course but you could have starcx you could implement the zkvm

written in cairo you could write an orbit vm written in cairo and you could generate a proof for that and so basically you could have on top of starknet different sub networks with different characteristic the other thing that is really interesting with recursion is that proving that the network executed correctly basically allows operating a network without having to trust the operator because since you're generating a proof for the execution of that network there's no way the operator can cheat the operator either behaves honestly or he is not able to generate a proof

there's no way to for him to generate a proof where he cheats right and one big narrative in the blockchain space and in ethereum for the past few years has been enterprise chains you know let's set up a permission chain let's set up a chain for a consortium and stuff like that and this never really took off why because what you want in a blockchain network is for people to trust what happened in a smart contract when a chain is controlled by a set of validator if it wants to to trust something that was done by another set of validator it basically means that they need to trust this other set of

validator in other word it's the same as having the same set of validators and this does not work because if if if it will work you wouldn't need two sets of validators with proofs you actually don't have this issue because a set of validator can trust the output of another set of validator even if it doesn't see the data because there's no way they could cheat so once they generate a proof they can believe it and now they have a way to communicate with each other they have a way to trust each other based on math and not based on game theory so there is actually a feature where these chains this proprietary chain this permission chain however you want to

call them they communicate and they interact with each other and even better it lowers the barrier to entry to run such chains because to run a trusted uh to run a consortium chain or a nap chain today you need to be very mindful of your validator set you need to lobby so that people will run the validator you need to make sure they don't forget it with this kind of networks you can run it on a single machine and people will still trust you because there's no way you can cheat it's not that they will trust you they will trust the match that you cannot cheat and so the barrier to entry to run a network will lower dramatically so you will you will have a multi-chain future multi-network

emerging with this technology now another thing that is really cool with recursion is that we get to have a simpler solidity verifier [Music] so let me um let me take a step a step back on this one so a bit earlier i described cairo as a cpu that allows you to run generic programs right that get compiled to uh to polynomials um

you really have to if you think about the architecture of a computer today what is a cpu what is your computer at its core its transistors basically what they do is add stuff and make differences and they have a very simple set of constraints and capacity but on top of this we're able to build more complex structure and more complex structure until you get to a relatively high level language well so based on very simple basic arithmetics you're able to build complexity

polynomials are the same way in the sense that on top of polynomial during you're able to encode basic operations and then build complexity on top of that and the same way that modern informatics evolve by leap and bounds stark systems are evolving the same way meaning that the first computer circuits or the first circuits that evolved were really electronic circuits with a few transistors to do one specific operation right and the first iteration of stark proof system were the same thing we would write a program defined as a set of polynomials that was very specific for that program that

would allow us to generate a proof and it worked well but eventually this is not very flexible and it's very cumbersome to read just as a specific asic is not very flexible and hard to design so we came up with different of architecture to do some different operations and so we arrived with cairo which is a general purpose cpu that allows you to write arbitrary arbitrary operations but if you think about it in your computer there are other electronic circuits than just a cpu for example you could have a gpu that is

specialized on special types of operation and we have the same kind of concepts in in stark proofs in the sense that some operations will take time to execute on a general purpose cpu such as cairo but if you write a specific circuit for it if you write a specific polynomial for it then you get to execute it much faster yeah and this is what we call built-ins right so a built-in is basically a set of constraints on the lower level than cairo that allows you to execute specific mathematical operations for a cheaper cost than if you were to

run on the more general global purpose cpu now the thing is there's a trade-off with built-ins because we're able to generate a proof for the cpu we're able to generate a proof for the built-ins but this takes some space having more built-ins having more components will lead to a higher proof size in what we call the layout because the solidifier fire will need to be able to interpret the proof that comes from these buildings right so the more built-ins the more complex the solidity verifier gets

okay yeah now what we get to do though and and this puts an upper bound like it puts a limit on the number and the complexity of built-ins we can get in starknet and in cairo now having recursion means that we can write an intermediate verifier in cairo that will have a large layout right that will take outputs from many built-ins on layer 3 for example and on layer 3 you'll get to generate some operations much faster because you'll be able to use the special built-ins and these built-ins they will be verified by the by stock net but in order to verify these

built-ins you don't need the specific layout you can use cairo to verify these built-ins you can use the general purpose one and so this means that you can move the complexity of the layout to start net and remove it from solidity where things are expensive and so you can have a simpler verifier very thing verifying compact stuff it sounds almost like magic because you basically have complexity and you're able to boil down complexity to smaller and smaller operation until they're very cost effective on l1 um so for example you could have a keycheck built-ins and the so you could have the trigger built-ins on l3 and

then verify that the kel check built-in was executed correctly on l2 and you don't need to have the catch act layout on l1 to verify that it is executed correctly so it saves you money and time and in a nutshell that's what i wanted to discuss about the recursion how we're applying today applying it today how we're using it and what we think it can bring in the future so to sum up it's going to reduce gas costs for users of all the system using stock proof it's going to make proofs bigger and so it will allow to add way more computational capacity in a proof

and to a certain extent it will grow the computational capacity of ethereum second it will reduce lat latency it will allow the proof for a block to be generated much faster i mean it will generate allow the proof for a block to reach mainnet faster let's say that way right finally it's going to allow the the the emergence of l3 so layers on top of layers on top of layers which will basically allow apps to decide how much their app will cost based on their distance to l1 and finally it will even allow to have a simpler verifier on solidity which is

great both for cost purposes but also for editability because the simpler verifier solidity verifier makes it easier to um for people to audit yeah right now where are we with that exactly how much of it is fiction how much of it is reality this presentation was done um two months ago and it says production in less than a month and it is currently we updated the solidity verifier for sharp on ethereum and it is now able to interpret recursive proofs so we now are able to batch eight times more transaction that we used to in a

proof so it means that the cost is even further reduced for the operator um and it means that latency is also going down um now proves rich maintenance up to up to fourth time faster than they used to so it's a better user experience for users they're able to withdraw their fund much faster they're able to mean their nft for lower for a lower price and so on um now there are still a bunch of optimization we could take i'm not going to get too much into them but i'm not going to get into the flexible hash commitments but uh there are some optimization we

could take around state update which is still one of the bulk of the the bulk of the cost for uh starcnet uh smart contracts today um and yeah another thing we could do is just improve recursion do better excursion and then recursively that and improve recursion recurse better improve over that and recurse better so this is basically what we're we're going to do um i'm not going to get into that because i'm not sure i'm going to be able to explain it correctly now i'm going to explain what we could do with state updates and data compression so

the principle of a zk roll up compared to what we call the lydium is that when you do some operation on a zk roll up the computation is verified but if you want to have full security you still need to have the data to reconstruct the state of the network at a given point in time right in order to optimize this this means you would basically have to publish the state of the network every time you publish a proof but if your state grows it's not very efficient to publish it every time so what we do is we publish state differences basically every time proof is updated to mainnet we will publish hey here's the

difference with the former state so it allows us to have just the diff with the former state now when you think about it before what we had to do say you had we have we said we used to send like a few hundred blocks of of stock net we would have to stand the state diffs from block one to block two then from block two to block three three to four and so on and all of these state differences were sent to to the verifier and the verifier would verify all of these now if we're able to generate a proof for so that's basically what it is right

so for each block we would have to store the state div now if we were able to generate a proof for going from block 0 to block two instead of storing just instead of showing three state differences we would be able to store only one and if some actions are repetitive or if the same study is manipulated over and over again this leads to cost saving for the end user i'm sure if that makes sense let me know if you have any question um so yeah to this i'm reaching the end of my uh presentation so to conclude i'll just say that you know recursion is a great tool it's a

fascinating concept i think recursion really brings to the forefront why stark proofs are fascinating you know thinking oh i can prove a program and it takes me less time to verify it than to run it it's kind of fascinating complex a concept but once you add recursion on top of it it really drives the point home that there's some kind of magic there where you actually are able to prove you you can verify the work of somebody for a cost that gets slower and lower in time which is really interesting so it allows boosting the performance from uh from the networks it allows to have more complex behaviors on top of um of stark net

and it is something that is live today that will get better with time and then that's it i reached the end of my presentation um i hope this was clear let me know if you have any question yeah yes thanks does it make sense yeah yeah i think it's i mean uh easier than i thought before i joined to this session because i'm not good at mathematics i'm afraid that i have to to know some knowledge about polyphonium or some

some long uh calculations and but not yeah everything is clear and i think i can get the higher level about the recursion i can say too it will be powerful and especially helping us save guys with more proofs capacity but keeping the theme uh i mean the same capacity the t yeah and uh yeah one interesting concept i learned is they are three yeah and uh i mean i i think it's a quite i mean a big idea about this part uh i would regard it as a blockchain

vmware or virtualbox in the future maybe we will have such uh an infrastructure provided by the stockholder yeah that's um my feeling or what i have learned in from these sessions and i received uh some questions yeah from our audience uh maybe we can uh uh we have five questions and uh [Music] yeah nice looks like so we have many members interested in these parts how many people are on the stream more or less uh currently in google meeting we almost had 10

but they also do uh forwarding in another uh platform like i mean uh open to more chinese people yeah and uh yeah yeah nice elective so what is i mean one of members willing to know uh a specific mass so i mean what kind of algorithm is used to implement such uh recursion um i mean the same algorithm that we use to implement stark proofs that's the beauty of it it's just the same algorithm applied over itself so

if you want i can i can give a quick uh i let me try to make it very high level how stark proofs work the idea of behind the stark proof is that i have a polynomial with a million factors right and i want to prove to you that i know all the solutions to this polynomial all of them i know all the roots but i don't want you to have to calculate the million steps for this because it will take you a long time and it's not and i don't want you to do all of this work yeah so what i'm gonna do is i'm gonna run a computation trace where i'm going to specify all the inputs for my polynomial and all the

outputs right and i'm going to specify all the roots where i mean i'm going to specify all the roots so the output for every line should be 0 because if i know the roots then the polynomial should be canceled every time right so now i have a list of factors and a list of zeros now on this list on this data i'm going in on the list of zeros i'm going to apply an error correction code error correction code is a a kind of mathematical mechanism that allows you to transmit a bunch of data and make sure that if part of it is lost

you can retrieve the data the full data that was sent um and one way to do that is for example just to broadcast the same data five times and you know hopefully you'll get you'll get part of it now there are much much more complex error correction code and one of them is the reid solomon error correction code which basically makes it so that if you want to transfer n data you will emit more than n let's say you emit 16 times n but if you retrieve any n data in the data that was transmitted you're able to recover the full end that was transmitted in the beginning

yeah okay the way they do that means that every data that is present initially should be present somewhere in the 16 time outputs right now remember what am i transmitting just a bunch of zeros yes now so on the other side you should have the same thing just a bunch of zeros but if somewhere in my bunch of zeros there is something different say a one for example then this error correction code will make sure that this will be this one will be replicated in many places in the in the output of the error

correction code in fact if i change just one cell i have a five percent chance of picking it if i take one of these outputs randomly right given it so say it another way i have a bunch of zeros there if i put in one place something else than the zero and i pick a random value on the other side i have 95 percent chance of um i have i'm sorry i have 95 chance of some picking something else than a zero okay

so five percent is is not that much so now the trick becomes hey look you know you committed to a bunch of zeros and on the other side if there was something else then i should be able to see it so i'm gonna pick one value and if it's not a zero i know that you cheated right so i'm going to pick it once and if i find a zero i know that i i'm 95 sure that you did not cheat 95 is not that much though so i'm gonna pick another one and then i am 95 times 95 right uh so in other words the chance that you cheated becomes

five percent then five percent time zero uh zero point five forty five percent time time so and so if i do that a few times i'm literally sure that you did not cheat so basically what what i do is basically that i take this zero this bunch of zeros i generate a trace and i i commit i applied the error correction code on top of it i commit to all the values you pick a bunch randomly and then you're sure i didn't cheat and if you make this calculation like say 16 time you're fairly sure that you're very sure i didn't cheat and you only calculated the route 16 times instead of a millions now um

yeah in a nutshell that's how stock proofs work and this protocol can be re-implemented if you have a general-purpose programming language and cairo being a general general-purpose programming language you just implement this on top of it and that's how you recurse it does it make sense yes yes cool hopefully it makes sense and uh yeah thanks for explanations and uh yeah i think our participants have have answers about this part and next it's about the

building procedure so what's the biggest challenge during building such a recursive layer or such a method is it some kind of mathematical proof or or some some engineering issues i would i mean the theory is here so obviously writing the program to do so is a challenge but i think the engineering part you know figuring out how to set up the infrastructure to receive jobs and then condense them and optimizing them to make the most out of recursion this is a very non-trivial part and before you're able like the concept of recursion is interesting how you apply

it to derive savings and lower latency is a challenging part also oh okay okay i see yeah um it's it must be a very very complex system and yeah a lot of members supporting efforts on this part and let's see the next yeah and it's a question about the polygon how does the stark net uh recursion compared with the pocky tube blanket

yeah such a name so that's that's a good question i i don't have a lot of insight on this i'm not super sure so take take what i will say with the grain of salt but in a sense plonky two is one step of the whole process i've described which seems to be very efficient one way to achieve that is that they have a smaller field of calculation which is um so in a sense when you write code in cairo you can have a number from 0 to 2 to the power of 251 more or less by choosing a low a smaller field and having smaller integers um you get to have some kind of savings

i would say the biggest difference between plonkie 2 and and what we have is that what we have is in production and donkey 2 is a research project which is really interesting but so far it's still researched there's no way to really use it okay still in the paper i mean don't come to life for sure i mean they're bright folks i'm sure but for now it's um for now it's really hard to have proper benchmarks because there's no way to use it yeah okay yeah i think what we need is something in reality yeah that's the true thing we can use in our daily life okay

thanks explanation and the next yeah i think you may and i mean previously you mentioned i mean at the end of today's demo uh you mentioned the uh state data yeah yeah and the data compression uh did we do kind of recursion during this part i mean aside from what i described unfortunately data storage is not really something execution with effect so for now so we don't like this is one avenue of optimization we have but that's about it for now

okay okay i see gotcha cool and uh one last thing uh it's a little wired from my side what difference is recreation going to make on stock nets in the development of ecosystem i think that there are various like various ways you could have it i think it will first it will make the user experience better because it will lower cost and lower latency second it will make developers able to run arbitrary code in their smart contract right now if you ever wrote a solidity smart contract you can't really

run arbitrary code you're bounded by what the evm can do now the network can do with recursion you could imagine running a program on a supercomputer and use that output in a blockchain network which is crazy so i mean you could have weather forecasts on the blockchain how crazy is that you so forecast okay yeah i mean you could have ai on chain you could have provable ai executed of chain proofed on chain so you can really push the boundary of what what is down is doing yeah i'm sorry what is done on chain um there will be a whole new wave of app specific chains where people will just run their own chain because it's easier

for them to do so or they want to have privacy because they don't want to push the data on chain and all of this will be done in a trustless matter and finally i think there will be a big wave also of privacy tools because privacy on ethereum for example is relatively expensive because yeah execution executing complex math is mathematics is expensive now if we are able to have computation for cheap then you're able to implement complex privacy protocols and execute them on ethereum so i think we're going to see a whole new wave of product of privacy protocols emerge and be implemented at the depth level so i think it's going to be really

interesting okay okay yeah i'm excited about what you said before uh maybe in the future we may have lucky side chin and some big stuff and uh yes and uh just i think i shared this repo yeah uh if you are interested in building on stock net make sure to check it out it's here let me try to see if i can come up with a qr code right this one yeah so um check this uh you consider qr code but check this tutorial it will guide

you through what cairo is and how you can build on top of it and it's fun you collect points so go take a look and figure out if cairo is easy it is i mean step step by step yeah exactly okay uh and last um i i think i still have a i mean a personal question about the slides uh clue clue please uh return to the slider 22.

wait a sec okay yep yeah so in this slide do we have um any limitation to the i mean the number of i actually say so theoretically uh we can wrap or aggregate all of the very fair as many as we want right yeah okay

okay see so so currently uh do we have um kind of data like i mean i mean uh in in the buildings in the building progress i know we cannot reach that limit so do you know uh i mean the exact number uh during the implementation or unfortunately i don't i don't have an exact number i'm sorry okay okay it's okay yeah i just um driven by the curiosity yeah no sure and it's great questions but i don't have this information unfortunately okay okay okay thanks henry sure happy to have you yeah i mean happy

to be to be here um and yeah you guys know how to reach me feel free to ask any question and i hope to do this again soon yeah yeah thanks and i think yeah after two days of studies henry and lucas gave us a good presentation about the stockwear and yeah especially the cario and the recursion and i believe all of the patients must have a deeper understanding about this part and at last many thanks to henry and lucas for their patient explanations

if you have any questions or issues in the future you can reach out to them or ask questions in the stuck nights communities or deaf learning community to get i mean uh some helpers or ideas about that uh okay i think um uh it's done and uh thanks for all of the participants and as well as henry and thanks for start wearing and dive learning and giving such a great event to us and uh enjoyed the rest of your day yeah thank you have a good day thank you

[Music]