Hasu gets STARK-pilled - with Eli Ben-Sasson (StarkWare)

16 Dec 2021 · 1:37:19

Hasu talks with Eli Ben-Sasson of StarkWare about how STARK proofs can scale blockchains while keeping what Ben-Sasson calls inclusive accountability, the ability of anyone with a laptop to verify the chain. Ben-Sasson explains computational integrity, why only the verifier needs to be trusted, and how error-correcting codes let a verifier check a huge batch by sampling a few points, likened to a kaleidoscope. Using dYdX on StarkEx as a case study, they trace a trade from order to proof on Ethereum, the escape hatch for withdrawals and the trade-offs against optimistic rollups. They then compare StarkEx with StarkNet and discuss the Cairo programming language, recursive proving and volition, where users choose where their data is stored.

Speakers

Topics

Transcript

welcome to uncommon core where we explore the big ideas in crypto from first principles this show is hosted by suzu the ceo and chief investment officer of three aeros capital and me hasu a crypto researcher and writer [Music] in this episode i had the opportunity to sit down with ellie bensasson of starkware if you listen to my last episode with sue where we talked about the scaling approaches of different layer 1 blockchains compared to ethereum i argued that layer 1 blockchains do not scale and that the only way to create true scalability is to perform all of the computation off chain and only post

the results of that computation on-chain so starks are a technology that allows huge amounts of computation to be compressed into very small proofs that anyone can easily verify what ali and i have tried to create here is nothing short of the most approachable and comprehensive audio resource on how stocks work and how they will scale blockchains in the future we start by explaining the inclusive accountability and the true meaning of scalability then we dive into starks how proof systems work in general and where these so-called validity proofs fit into the context of unbundling blockchains

next we use dydx as a comprehensive case study to learn about the starkx system before diving into starknet and its trade-offs to starkx finally we talk about starquest programming language cairo and how the different costs of proving verifying and storage are going to scale into the future if you're a developer you should also gain a very good idea of the trade-offs and trust assumptions between building on regular layer 1 blockchain versus the general purpose starknet blockchain and an application specific stockx blockchain enjoy hello hi hi hasou i've been wanting to talk to you for a very long time i'm a big fan of starkware

and full disclosure and investor i think you're doing one of the most interesting things that happening happened in the blockchain space today can you give us a bit of your background maybe up until the point where you founded starkware yeah so um i sort of came to blockchains by chance meaning um for a very long time um i was a theoretical computer scientist which means i was uh studying and proving theorems about computation in a very abstract way with no no you know no applications in in sight so very fundamental questions about uh the mathematics of computation

um things like you know p np co-np uh creatures like that um and one particular question i was interested in starting around 2000 when i was doing my post-doc at harvard and mit was the question of how to get certain proofs called probabilistically checkable proofs to be shorter and more efficient and after some work uh we had a few breakthroughs there with several collaborators most notably emodu sudan who's now a one of the scientific advisors of starcore and a professor at harvard and slowly

these breakthroughs started to get implemented first by students and then i received a grant and we started implementing them more seriously for general purpose computation and fast forward something like 12 years to 2013 i was giving a sequence of lectures at academic institutions about this theory to practice of those proof systems and i was looking for examples like why would one use them and at that point i started to look seriously at bitcoin for the first time after hearing about it previously and i incorporated one such example in my talks and i also

asked to present at the bitcoin san jose conference in may 2013 and this was a turning point moment for me because there it was a very electrifying conference and in hindsight that was the place where i swallowed the red pill and realized in hindsight that blockchains are a very good fit for proof systems proof systems are good for privacy and scalability the first application we did was zcash first as academic work and then as a as a system that's out there i was one of the founding scientists along with my collaborators and i was still interested in like

better technology that's older but also more complicated to achieve which we ended up calling starks and when that was uh mature enough to commercialize i basically left my academic position i was a professor at technion at the time and with my three co-founders alessandro chiazo michael we founded starkware one concept that always shows up in sort of star quest material and that seems to play a larger and larger role in the block blockchain space is the concept of computational integrity and as i understand it

this is sort of the main application of stocks can you explain what computational integrity is and how stocks have to improve it yes so integrity was beautifully defined by c s lewis the author behind you know narnia and that whole story and he defined it thus integrity means doing the right thing even when no one is watching so computational integrity by analogy means performing the right computation say with our data even if we're not watching and especially when no one is watching

and it's even more so when there are incentives to misreport or sort of change the computation so let me give an example um you know most of our finances today are basically just bits sitting on a computer in a bank in financial institutions now we would very much like to know that those bits are handled in the right way in a reliable way with integrity so if you formalize computational integrity it means something like this suppose we agreed on what the right computer program should be right we wrote it down we all looked at it we agree this is the program you want

for instance you know if it's a blockchain uh please do not move my funds unless the signature matches my public signature and then do whatever i instruct things like that so there's a program that checks a signature and then does what it is instructed good so what we would like is to live in a world where when if someone is in charge of processing transactions and running computation she is doing so exactly as the program specifies and not deviating from what program we agreed to specifies now this is sort of a a value or an ideal or a principle we would like to to have with our

funds in the bank with uh transactions we do on the blockchain and with any sort of computation you know if there's a database containing um forensic information or health information again we would like the same principle to apply so we would like to live in a world where we have computational integrity just like we'd like to live in a society that has integrity and what starks do they are one of several different methods that give you uh integrity that assure you that computations that you didn't see were done with integrity so computational integrity is a value or a principle and starks are one very good way to enforce

that desired principle for me there are sort of two takeaways almost first this computational integrity is actually everywhere right um yes i i think you you gave a great example in one of your first blog posts um with starkware where you gave the example of how do you know that your bank actually performs its own sort of ledger updates with computational integrity and once you you know about this problem you start to realize that they spend immense amounts of resources on sort of signaling that they are a trustworthy institution and

um that sort of they they employ like external accountants and so on just so a lot of resources go into proving this because otherwise society wouldn't work and a lot of things actually depend on computational integrity precisely it's asus so what you're referring to i like to call delegated accountability which means if you look at the banking world the state usually will write laws and appoint all kind of uh you know accountants and regulators and lawyers to enforce and check on behalf of the public the integrity of these very important institutions yeah exactly and the second thing that i thought is

blockchains actually sort of almost computation integrity machines right they are not very fast ledgers or a cheap ledgers the only thing that they really provide is a ledger where computational integrity is insured right for everyone i i wanted to say that the way they achieve this is by numbers meaning you know trust in large numbers which means so i like to call this inclusive accountability which means that anyone is invited to be sort of an accountant and a regulator of the blockchain and by doing so that person would take her computer and now go over all transactions in the blockchain and check

each and every one of them so this is the way computational integrity is achieved today on conventional blockchains right and in a conventional blockchain this is very hard to scale right um because it's not we are not actually bound by the cost of computation or not even the cost of really storing any of the data but um by verifying the data right so yeah so so there's a very uh here it goes back to very you know beautiful principles that satoshi started but all the decentralized blockchains are following and the reason the reason uh we can't sort of 10x the gas limit or the block size of

bitcoin and we can't repeat doing this is not because there do not there aren't large enough computers and bandwidth that can support this that's not the reason there are computers uh that are that cost more that can process 10x whatever it is that is currently done but the problem is that you will start having people dropping off you know the public the inclusive accountability will will dissipate and disappear because uh you and i uh won't go out and buy you know some 64 core machine and some big you know bandwidth connection just in order to verify all transactions in this 10x greater thing so people will start

dropping off yeah and you will basically fall back to the existing world uh conventional world of some big trusted institutions with individuals appointed to check them and you know that's the conventional world so we would like to find ways to scale the system while maintaining it inclusively accountable that everyone with their laptops and very minimal work check and verify the integrity of the system and that's sort of the paradox that various different technologies are trying to solve yeah i think this point can almost not be overstated um that it's only scalability if you keep

um the inclu if you if you keep the property of inclusive accountability if if account the cost of accountability goes up then it stops being inclusive and then it's not you did not actually scale the system right you made it accessible to fewer people i i recently tweeted that ever since ethereum came out no other blockchain has really made any fundamental advances in scalability even though they all claim that they do they only chose different points on on sort of the accountability spectrum right i think you're very right that as as you if you increase the throughput by basically saying everyone is invited to

just buy a bigger machine then what you're doing is i mean you will get larger scale but on this curve between you know how inclusive it is and how scalable it is you're just moving to a different point where the ultimate two points of it are let's say bitcoin ethereum style where you with your quad core laptop and whatever 16 gigabytes of ram and you can check everything and the other extreme is basically banks and alipay and visa where you buy huge data centers and process tens of thousands and you can pick any point in the spectrum but the more you go towards the um scalable by better hardware

the more you are excluding the public yes exactly so that's why i'm so excited about starkware and by extension sort of all forms of sharding um like the other rollups and so on can you explain how starks um specifically scale this property of inclusive accountability like what are stocks um and how does it work so so stark is an acronym that i won't go over all of it but it defines a certain class of uh proof systems and for a proof system to be called a stark to satisfy this definition it has i'll just focus on the

first two letters it has to be scalable which again not to get too mathematical means that the time needed to generate the proof scales nearly linearly with the amount of computation or with the number of transactions that you're processing and simultaneously the time needed to verify a proof scales exponentially smaller or logarithmically with the amount of computation so a system that satisfies these two properties is called scalable that's the s and the letter t stands for transparent which means that there's no toxic waste or setup or approving keys the only thing you need in order to set the system up and use it

is basically public random coins um which is very important for trusting the outputs even when when the prover is some you know government or some monopoly and you don't want to make any assumptions about it so that's what starks are and the way a stark works is so we agreed that true scalability for a blockchain means that you don't change anything in the amount of computation and resources that all the nodes need so what if you could have a way where someone would run a huge computer but you do not need to make any assumptions about that someone and you

can check with near certainty the correctness and integrity of her computations so this is exactly what starks give you they say someone anyone can run approver this could be darth vader or you know the worst government that you have the least trust in as long as you know what program they are using for processing and you get a proof you know that they operated with integrity and this way you can have all the nodes of the blockchain still verifying the integrity of the whole blockchain using laptops and very standard internet connections and yet scale the number of transactions running on that blockchain exponentially so what is a proving system and as a

user of ethereum how do i know that whoever made the proof used exactly that system and not some other variant of it okay so proof systems started off in amazing research breakthroughs in the mid 1980s there are many variants of proof systems the most uh publicly uh well-known by now are the zero knowledge-proof systems but there are many classes and they have different properties uh interactive proofs multi-prover interactive proofs probably checkable proofs and many others so there's a wide class of cryptographic proofs but what they all share in common is the property of basically

certifying integrity um of a computation that's what proof systems give you they give you the the uh you know the guarantee and assurance that a large computation was done correctly even if you don't see all steps of it and even if some of the inputs uh that went into that computation uh are shielded from you that's the property of zero knowledge so that's what proof systems um give you now your second question is how can we trust that you know a proof system was used correctly and was designed correctly so this is it's a very good question and this is um you know a special case of the more general question of how can you

trust hardware and software that is supposed to do something to be doing that thing so in general it's a it's a it's a tough problem you know how do you know that your computer is not logging your keystrokes and reading your keys it's a tough problem in the case of proof systems what what is really really nice is that you only have to trust the verifier part so if you audited checked understand and believe that the verifier is correct and the hardware running it is correct the math of proof systems tells you that you don't need to make any assumptions about

the proving side it can be running on faulty hardware it can be uh running any software it wants with bugs or without bugs the verifier is the only thing you need to check and trust and the verifier in our systems is run on l1 ethereum its code is open source uh it's audited and being audited and uh you know hopefully there are no bugs ah so i don't need to trust that the solver is running uh so software that is exactly what it says i just have to trust the verifier and the verifier runs in an environment that has very high computational integrity which is ethereum for example but it could in

theory be any other layer one blockchain and then i can just like any other smart contract i can if i trust ethereum and then i trust that the smart contract code is correct and does what it it i think it does then i can also trust the entire proof system precisely i see so how does it work and maybe not to go too in depth but just to give sort of myself and our listeners um a high level idea how do you generate this property that you have a proof system you input a huge amount of computational data or data that you want to perform some amount of computation on and then you generate this

very small proof that is very computationally cheap to verify that the computation was done correctly so this is a it's a terrific question and indeed when these results result of this nature of being able to check the correctness of a computation very cheaply when such results were first discovered they were mind-blowing they seemed impossible how can you know that a very long computation processing hundreds of thousands of transactions uh all of them happened with integrity without redoing all of them and and you could do this for a generic

program this sounds almost contradictory to all kinds of famous fundamental theorems in math and computer science right like it is still mind-blowing to me yes exactly like the you know the undecidability of the halting problem basically says that you cannot say anything about let's say the running time or the output of a computer program unless you uh run it from start to end you can't even save one step on that that's you know those are notions of common goal of complexity and the undecidability and and so there like these very famous theorems from a hundred years ago that say that you can't understand and trust any computation without re-running it and here all of a sudden starting in the

mid-80s along come these uh you know amazing brilliant uh researchers uh lassie baba a bunch of others and and come along with these amazing results that say that you can do an exponentially smaller amount of work and still know with near certainty that things are fine so how can this magic be okay so first of all it turns out that there's a huge difference between knowing things with 100 uh guarantee and knowing it with uh you know 100 minus 2 to the minus 128 which you know minus some negligible error so that's one thing that really helps you the

second thing is that these systems are somehow interactive there's a back and forth going on between prover and verifier so that's how this magic came about but with your permission i'd like to sort of you know explain a little bit how how they might work so what is our problem here you want to come to some um facility or you know and inspect it and this is a huge facility and you want to know that everything there is just perfect um okay the analog for us is you know there's a batch of a million transactions a million payments and you need to know that all of these one million transactions were done correctly so

the first attempt but you the okay what is you could easily do but will take you a lot of time is check all of them one by one yeah we don't work very well but it's not scalable so the second attempt is to say well let me do a randoms a random sample let me just uh pick a few and check if they're okay now this will save you a lot of effort but of course this by itself doesn't work because maybe there's just one transaction that is faulty and it will be very hard for you to find it or you know you won't stumble on it by chance so here here's the analogy that explains it uh you're familiar probably with a kaleidoscope or a hall of mirrors where all of these different mirrors are

refact refractoring and amplifying light and vision that comes you know so you see uh one thing uh repeated many many times from many different angles so what if you had some way of viewing these hundred thousand transactions through something like a kaleidoscope something that would refract and amplify any small speck of an error so that even if there's one bit that wasn't correct it will sort of be reflected from everywhere now if you had such a marvelous magical contraption you could use it for coming into this facility

looking at the books with this kaleidoscope and then immediately seeing if something's wrong so the mathematics of stark proofs and other proof systems what it does is the analog of this kaleidoscope it applies certain mathematical methods that will refract and amplify any error in the computation and then you come and just sample it at a small number of locations and check if they're fine so is this another way of saying sort of the data gets rearranged in a way that makes it easier to audit using a probabilistic method this is precisely what happens and the way the data is rearranged is using something called

error correcting codes with very special properties that so basically you ask the prover to rearrange the data and encode it using an error correcting code and then also to re-encode the computation using these error correcting codes and then you come and inspect it so like the way a stark proof works in the interactive mode is that the prover first of all does the processing then encodes it then commits to a merkle tree of the encoded data and now we sort of uh committed to something so either it's all perfect or there'll be problems everywhere and then after these

commitments are on chain the verifier comes and samples a very small number of locations and the prover opens them up and shows uh what's written there and then the verifier can see if there's a spec of dust or not ah okay so the second thing you said is um there's a big difference between proving something with a hundred percent certainty and ninety nine point nine nine nine percent certainty so and you gain like an irrationally large benefit from that almost um so that in turn does this mean that um the stock proving system sometimes

produces false positives so basically saying that a computation was correct even though it wasn't okay so all proof systems and all cryptography has a probability of failing okay and um this is true of starks it's true of digital signatures it's true of encryption hash collisions collisions yes yeah they all have they all have the probability of error for instance to give an analogy in an encryption scheme let's suppose that the key is 128 bits long right so someone can toss uh you know coins 128

of them and there is a chance that the coins tossed will give you the encryption key in that case uh you know your sort of your system has been broken your key has been compromised the same thing of course with bitcoin and so on so the reason we say that encryption schemes are probably okay is because we think that it's very very unlikely for this to occur for someone by chance to get it and our proof systems are exactly like that so there is a probability of error basically there is a probability that the verifier will ask to inspect locations that all of them look okay even though the the batch is not okay but the probability of this occurring is again something like 2 to the minus 128 and

we view that as uh you know if you're worried about such errors that then you don't want to use blockchains at all because they have such error probabilities and probably not even use computers yeah you don't want to use any incre you can't use any cryptography because all of cryptography has such probabilities of errors right your keys could be compromised with such probabilities and then you don't want to use cryptography at all makes sense so we just zoomed way in how um stocks work improving systems work so now i would like to zoom out a bit how would you say that these so we also call them validity proofs right because we

prove the validity of some computation how would you say these validity proofs fit into um blockchains in general so because right now we can look at something like ethereum and that's how i would most most people would still look at it as like actually doing a lot of things that it doesn't necessarily need to do and lately we are seeing a trend of unbundling these different um [Music] jobs almost over blockchain so how would you say that validity proves fit into that and how does that how would that sort of make the ethereum unbundle so if we look at the cost structure of

transactions on ethereum there are three things you pay for you pay for long-term storage you pay for transitional witnesses and call data so this is something that can be consumed on the fly but you don't need to keep it for instance you know signatures and the third thing you pay for is compute so where validity proofs really help with is in exponentially reducing the cost of compute so you can think of them nearly entirely removing compute another thing they do away with is the witness data most of the witness data is not needed um so for instance signatures you don't need them anymore because they are

basically just uh witnesses are used as to support a computation there's a bunch of choices that need to be made and the witnesses tell you which choices they are but if you have a proof system you don't need the witnesses and you don't need the computation you what you are left with is the storage and with respect to storage you can also uh save a lot you sort of there's a lot that you can do by paying more with computation to save on storage in several different ways for instance you can use storage more efficiently by applying compression algorithms so compression algorithms lossless ones will reduce the amount of accesses to storage by doing more computation when you access that storage so that's another trade-off

so even though validity proofs don't directly reduce storage they can be used very efficiently to also reduce it in practice another framing that i have seen is that um ethereum has different or like that the traditional blockchain consists of different layers um the consensus layer the execution layer and then the data storage layer and we can use validity proofs to unbundle these layers so that for example transactions get executed um by a proving system or by any party that can then use a proving system to

precisely prove that the computation was indeed done correctly and um so where does where does sort of the data storage element um fit into this why does the data need to be stored okay the data needs to be stored because um it's it's basically some variant of the i mean it's liveness or also it also has to do with the um with the double spend problem right with uh like consensus because um suppose there are two different ways for the system to evolve and both of them are legit legitimate so alice can pay bob and she can pay charlie each one of them is legitimate so we need to know uh what state the system is in did she pay bob or did she pay charlie and for that you

need to you need some storage right you need something that reflects the state of the system um users need to know what is the status of their accounts they need if they're not tracking the blockchain all the time they need to someone to hold this data for them so storage is still needed um as you said i really like the way you described it that the execution layer can be very much compressed using validity proofs and under the execution layer you can also put transmission of witness data that's also part of it and can be removed and then with respect to storage there's there's a little bit that you can improve using execution because again up to

compression algorithms what they do is they reduce storage up to some you know absolute value information theoretic one you know the amount of entropy in the data but that's a long way they can reduce things uh by paying with more computation so you can even help the storage layer um using computation or the execution layer but at the end of the day you need the state uh i mean think of a banking system we need to know what we have in our accounts we need someone to know that's the whole goal right i mean we are doing this in order to like have a shared state of accounts and update that in a way that is sort of has computational integrity got it okay so one

your first product um is darkware is called starkx and this is um effectively an off-chain system where people send their transactions to and then it gets executed and then a proof gets posted to to the main ethereum chain i think so um stockx is so fascinating to me um because i i use dydx and it feels just like so dydx is one of your four customers um in stockx and um so i'm using it and it feels just like using a centralized exchange but i know that it's non-custodial so i can always withdraw my funds and um it

can only sort of change my account balance in in ways that are sort of valid right um that sort of iteration integrity yes to their smart contract logic so um i would like to talk about dyjx as a case study so one number that i i have seen is that if you did the same if you did if you did a transaction on dydx if you if you did it all on layer one then it would consume in the range of like a couple hundred thousand gas because it's a very complex system um it has a lot of markets it has um cross-collateral

positions um which is computationally expensive however if you execute it off-chain um via stockx and then post it on chain and then you look at sort of the amortized cost of each of these individual transactions you end up with something like 300 to 400 gas this number is completely mind-blowing to me so please can you explain sort of how do we get from let's say 300 000 gas to 300 gas what happens in the meantime where do these savings come from so yeah yeah that's a that's a really terrific question and um so what is happening uh

and it's even more mind-boggling because um actually dydx works in roll-up mode which means that all of the changes um to storage on the l2 system are actually relayed as transmission on l1 so it means that even as you go grow the the they're like i mean some of our other systems are validium we'll touch upon that later but they have even a smaller footprint for their storage on chain so what happens is something like this if you look okay we said that with proofs the larger they become sorry the the the size of a stark proof and the time needed to verify it

is exponentially smaller than the size of the batch so it's like logarithm of that so just to you know without like writing down numbers let's assume i mean logarithm the logarithm of a number is roughly the number of digits you need to in order to write that number so let's work in base 10. so for instance the logarithm of of uh of a million is six it's the number of zeros the logarithm of the logarithm of a billion is um is nine right because it has nine zeros and a trillion write a thousand billion the logarithm of that is 12. so let's let's examine now we said that the size

of the proof scales roughly like uh like the number of digits okay i'm simplifying this so let's suppose that every digit you know you count the number of transactions in a batch that you're proving and let's for simplicity assume that the gas cost you're paying is the number of zeros in the in that thing times a million so for instance if you took a million transactions you have six zeros and it means that your cost is going to be six times a million because we said each zero costs you a million gas so you have one million transactions and you're paying a cost of six million gas

so what you end up is with amortized gas cost of six per transaction okay now let's look at a billion a billion transactions you're going to pay 9 million gas because we said that's the number of zeros but now the amortized gas cost has gone down because you take 9 million and divided by 1 billion so that's much less than one guess per per transaction so we went down from six gas per transaction if the batch was one million to less than one gas uh much less than one gas per transaction as we scale up so this is

this is the way uh this is why as you scale up with a system like stark the amortized gas cost goes down as the batch size grows okay yes now um another interesting thing is that i mean there's this on-chain data in a roll-up that you need to put so you would expect each time you touch a certain position um you're going to have to write something on l1 that says what happened but here another effect happens which is suppose a certain uh account was involved in many many trades among those one billion trades so the proof only needs to talk about the diff

at the end so here again you amortize storage accesses across many transactions so you're again saving on storage uh data by using more computation which is this effect that we discussed earlier on if you have computational integrity if you can compress the execution layer you can also save in a very substantial way on the storage layer i see so what made to illustrate this even further so i'm a user i send a transaction to dydx what is the entire lifecycle of that transaction where do i even send it to

us i don't send it to ethereum miners right so i'll probably send it somewhere else uh what happens to that transaction before the the actor the eventual state change gets recorded on the layer one excellent question so let's let's go through the workflow you have a position and this position is controlled by a private key i mean this position has a public key that everyone can see um it's part of the state of the dydx system only you control the private key so now you send an order you want to do something you want to sell one banana coin and buy one orange coin okay i'm simplifying it so you sign

this uh transaction with your private key and basically you send it to dydx which is an off chain system okay dydx will first do some internal checks just to make sure that they're not passing on to the start prover something that doesn't you know that can't be executed with integrity so let's suppose this is okay dydx will do two things first of all they were in their internal system that talks to your front end sorry to your let's say app they will note that hassu has now won is one less banana coin but one more orange coin and they will let you trade on on that information so you as the

user get a very immediate finality and uh and you're you know you can continue trading dydx know that this is fine because they saw your positions they know they can do the trade now and they know that this will also be recorded on l1 okay now this order is sent to starkware for it to be part of a stark batch proof and there it sort of accumulated till we reach a number of roughly 10 000 transactions and all of them now we want to prove that all of them have been done with integrity so now we execute them in sequence see that indeed you can so we sort of check them again and the

reason we check them again is just because we won't be able to generate a proof for something that is invalid so we need to see that the execution is valid for each one of these things so we we check that the signatures i mean we run the same program that we all know should be the right program the one that checks signatures and that the trade is valid and after we saw that all of these things can update the state of the system correctly we generate a proof for this update to the state of the system and then this proof is sent on chain with a new merkle root for the state of accounts the verifier on chain checks this proof if it passes it basically replaces the state of the dydx system the merkle root of it with uh the new state and this is

repeated time and again fascinating fascinating okay i think i have a much better um sense now of how it works so um so i have a few questions about this so you said um uidx they do their own internal checks they check the transaction but at this point the state change is not really yet recorded on layer one but they already give you they as the user they already tweet like it's fine treat it like it's final right so would you say this is sort of can they never go wrong with this like is this some sort of optimistic finality or is this sort what is happening is that they are assuming risk for a temporary period of time

so uh for instance if they were let's suppose that you don't have any banana coin to sell um but for some reason they said yeah this is fine so suppose you have zero banana coins in your uh in your account and you still gave an order i want to sell one banana coin and buy an orange coin and they said for some reason there was some bug on their side or something and they said yeah sure let's let that happen so let's see what happens in this case you now uh you know from your side you think that the trade occurred i don't know exactly what happens because you supposedly had zero banana coins maybe now you have minus one i don't know um but what's going to happen is that they send this on to to starquer stark where's prover is

going to try and prove this and there's going to be something that says no this can't be done right we cannot have uh you know uh negative balance for banana coin and basically you know we cannot prove this thing so there's going to be some issue now on on the dydx right even if we wanted starkware right we cannot you know a prover cannot prove something that falsifies integrity that doesn't have integrity and if the system says that you cannot sell something into negative territory i don't know by the way about the dydx the system maybe you can actually be there in in the red but but assuming that this is not allowed by the program we even if we wanted we won't be able to generate the proof so now there's going to be some process

by which you know in this case dydx are going to have to do something about it uh maybe talk to you maybe cover it from their own banana coin fund or something like that but at the end for the proof to reach l1 and be verified we're gonna need to have things that are uh basically um uh legitimate transactions that compute with integrity so that will have so that's why i say that dydx will be assuming the risk if anything goes wrong along the process then for the temporary period till it's finalized on l1 and accepted that's the risk that uidx are assuming that actually ties into my next question so how long usually until 10k transactions have been

collected in a batch and the new update is made on the layer one so there are two latencies here one is how long does it take for 10 000 transactions to accumulate and then how long once a train has sort of been closed and the batch has been closed how long does it take for that for the proof to be generated and then accepted on l1 so roughly you know at current uh rates um it's roughly the order of one hour for a batch to close of course this varies along with time though and by close you mean for it to accumulate or for it to be yes for ten thousand so the current uh the average tps we have right now for dydx is anywhere between let's say

three and ten so let's suppose it's five okay so five tps to reach ten thousand actually in a batch size is thirteen thousand so thirteen thousand you know that's uh in an hour there are thirty uh six hundred seconds so thirty six hundred times um five is roughly that's 18 000 right so 13 000 takes let's say 40 minutes or so so if it's at 5 tps right every 40 minutes or so you'll have a batch accumulated that can be sent and then it takes several hours on our approvers for such a proof to be generated so all in all it takes the order of several hours since the

trade was done and until you have finality on l1 got it okay um and then we said you generate the proof you send it to the chain it gets mined and this sort of um is very interesting to me because in an optimistic roll-up system you need another third party again basically the delegated um accountability right you have these verifiers that re-perform all of the computation and and check if there has been any fraud and they are economically incentivized to do do so but this is not the case in the validity proof right it is the ethereum blockchain itself that checks

if the if the computation is valid yeah so in in a fraud proof system in the optimistic roll-ups um there are two big different well there are several big differences one is that um you either you know you're a user so in order to trust the system you either need to run um a node of uh the fraud proof system which again if you want to increase the scale means you need to buy a bigger and bigger computer in the validity-proof world you don't need to do that because you don't need to trust the party generating the proofs in the optimistic roll-up world you either need to get yourself such a big computer or else you

will be trusting someone else who will you know you're trusting that someone else is watching uh the system on your behalf and indeed in the optimistic rollup world only when there is a suspected fraud does the system start to generate proofs by some binary search mechanism so they take as the name suggests a more optimistic view towards the behavior of actors with validity proofs you're taking a more stringent view and you're putting higher demands on the party processing the computations and saying

look we're not going to risk it that maybe the watchtowers are down or you colluded with you or anything and we're not going to be asking users to run these big computers every time you touch the system and you say that you updated it with integrity so please prove it and uh you know on the one hand this puts more demand on this big computer that is the prover on the other hand everyone can now sleep very peacefully at night because uh every change comes with a proof okay so um thank you for the explanation so are there any um trade-offs

with using stockx compared to layer one ethereum uh yes there there's uh there are there there are several trade-offs if you let's look at a transaction like uh you know a payment on layer one ethereum versus starkicks so on layer one ethereum you have immediate blockchain finality and you have the security of l1 immediately but you pay higher cost and frankly if you took all citizens of the let's say european union and each one of them wanted to use do a single transfer once a week so

there's no way that ethereum could process all of this period that so it just doesn't scale now if you do the same payments through starkx then first of all you can easily you know service all of the citizens of the european union doing more than even you know doing several transactions a day without changing anything in the um l1 of ethereum so you maintain inclusive accountability that's the main benefit um what you are sort of losing here is slightly higher

time to finality that's one thing and the second thing well depending on the depending on the data availability model you may be needing to trust um other parties to keep the data or at least do so temporarily this depends whether you're doing it in roll-up mode or in validium or volition mode but that's another potential trait of where is the data maintained so you have longer time to finality not instant but let's say you know minutes to hours and you have much much lower cost and much higher scale that's the trade-off got it um what would happen if starcraft stopped processing any

proofs for dydx so i'm trying to sort of explain where does the non-custodial aspect of it come from right so all of our starkex systems these standalone layer twos all of them have built into them escape hatch mechanisms so we can talk about uidx there is a mechanism in which a user can say to l1 hey i want to retrieve i you know all my funds please and in this case the l1 waits for this to happen by the l2

but if it doesn't happen within a certain time frame basically the system freezes in which in this case the only thing the system allows is basically everyone to retrieve their funds from l1 by saying here's uh here's a path to my vault in a merkle tree and remember that in dydx it's in roll up mode so basically l1 has all the information you need in order to construct where your account is and what is the path to the merkle route and then you can basically instruct l1 to say here's an authentication path to my node please give me all my funds and the l1 contract will do precisely that when we

say that we um prove our balance to the uh layer one smart contract this only refers to the last recorded layer one state right we cannot sort of anything that happened on dydx in the meantime so let's say we made any trades but they have not yet been proven to the layer one then this is sort of that the risk that we assume as the user yeah exactly this was the finality this was the risk that we said that dydx was assuming uh exactly suppose uh it allowed you to do some trade and now um this proof never arises because uh you know starkware blew up and dydx blew up and there is no this proof the proof of this very last batch never appears and now there's an

escape hatch so this very last epoch this very last batch never never appears and then i guess you as a user will have to somehow sort it out with uh dydx or something because you got an assurance on your app or something through the l2 that this should have been recorded but it never arrived on l1 and now people are retrieving their funds well i just as a user as i understand it i just need to trust either dydx or starkware right because if i if if um if starkware is honest but dydx is faulty then starkware could still process the final batch

right to the make the proof and send it to layer one well assuming dydx sends it over depending what kind of fault the ydx has so suppose dydx just tells you that it's okay but it doesn't tell star query right if we if starkware got that information then yes the this batch will be on chain and then your state will be updated yeah whereas if dydx is honest and starkware is 40 and doesn't make another batch then dydx can just internalize to risk from their treasury right and yes and find another prover to replace darkwall yes okay that makes sense okay so that's that to me i can only say that is an acceptable risk

for the all of the cost saving that i get um so we have talked about stockx um starcx is basically what in the context of multi-chain you know blockchains and so on we would call an application specific blockchain right this one one blockchain is it's not even really a blockchain but it's basically one system per application but now you are launching a second product um called starknet right so the the known problem with application chains there are many advantages but the known problem is sort of lack of composability um within the same shared state

so what is the difference between stock net and stockx it's like the difference between a company running a big computer and the cloud so starcx is like a big computer that allows specific businesses ones who have uh talked to us and asked for this to benefit from higher scale so think of that as like the big computer that lets you scale in a non-custodial way with computational integrity on the blockchain so it's like the analog would be it's as if duidx went and bought a you know massively big computer that allows it to process things very uh very well but it's

it's their computer right you can't use it um and same thing with diversify immutable each one of those has their own sort of computer and then stark net is a little bit like the cloud or the internet where or a blockchain maybe that's the best analogy like ethereum so if you're a developer and you have a brilliant uh smart contract that you would like people to use well you can just uh go write it up uh deploy it on starknet and um people can send transactions to it exactly like ethereum so that's that's the difference between starkx and starting it so on stackx it's basically a permissioned

blockchain in the sense that only one party can deploy their smart contract code others can still read it and audit it that it it does what it says it does start net is more like ethereum itself where anybody can build their own um applications right but it has more scale that's the big difference it has more scale than ethereum it sort of it takes the execution layer and it it has the ability to compress it from the point of view of layer one ethereum so you get much higher scale right so it retains this major benefit of stockx but it makes it available on a shared compo composable

uh execution layer pretty much yes okay will anything change with regards to the provers so right now in stockx um star starkware operates the prover for everyone are there any plans of changing that in the future definitely a very exciting stage of starknet and one that is uh on our plans you know the major um next stage i mean there will be a whole bunch of small updates but the big next change which we call universe um will be uh decentralizing the sequencer and the prover so that it's not stark we're running those it's

actually you know anyone may run them if i'm if i'm thinking about launching an application today um so i imagine i'm a developer is it now strictly better to build on stark net uh and does this make sort of stark x obsolete or what are the trade-offs between the two that's a really good question you know in the long run what will the difference be um so definitely if you're uh a developer okay starkx right now is catered towards very very specific highly you know ubiquitous cases but still very restrictive so it is very good for

massive payments massive trading massive nft minting and trading but for instance if you want to build a gaming application on using stark technology star kicks doesn't deliver that so if you want general purpose new applications or you want to have something that is generative art you know something that evolves some some crypto kitties style thing then definitely you can't do that on star kicks the more interesting question um in the long run is suppose you want basically the functionality of starkx today you could write it on starknet or you could uh you know talk to starquay and get a starkx instance and the question

is what will be the steady state let's say in two years we don't quite know our thought process on this is constantly evolving and and you know we we um actually inside our team we we have you know some folks have came up with some very interesting brilliant ideas on how they might live together in the future in ways that both star kicks lives and starknet lives and both of them thrive and and uh benefit from one another but taking a very high level view the big benefit of starkx is that because it focuses on very special use cases yeah it's very

likely that some customers will want that and get get a much higher scale and higher control for instance if you're a visa and you want to use stark pay which is part of star kicks you want the payment processing maybe you will want to use a star kick system and not write it as smart contracts over stark net so we don't know yet what will be the end game with stark x versus dark knit my guess is that they will both have a very long and successful life uh even a stark net increases in size that's my intuition as well i think you can always do better at making one specific application more efficient than having like a chat system right that

works for many applications maybe this is a good time to talk about um cairo so your um both of your systems require any application to be written in the cairo smart contracting language so it's not possible to take an application that runs on ethereum today and just deploy it either on on starcx um or stock.net and i as as i understand sort of your business model for stockx has been almost software as a service like where so dydx did not write their own um application in cairo but you did that for them uh sort of as a almost as also like doubling as sort of

a proof of concept right um and but this is different for stock network you don't offer this service anymore um for anyone who wants to deploy on stock net they have to write their own application right so um what happened with uh cairo in it the way it emerged is also a very interesting um story so initially like all um projects that that work with proof systems you know zcash and you know many many others you start writing by hand various circuits or in our case they're called airs algebraic intermediate

representations and uh this is a little bit scary from the point of view of developing code because it's the analog of uh putting down a circuit comprised of nand gates and wires to do some computation so beyond a certain scale it just gets very uh hard to do right yeah and then folks inside our our team came up with a much better idea so i mean the cairo uh white paper has uh three co-authors the co-creators of cairo leo goldberg shah papini and michael yapzev who's also my co-founder

they said that why don't we write a sort of small circuit that is the analog of cpu let's make it very very simple and first this was done for internal internal reasons so that we can just write more elaborate code uh for more elaborate systems and for instance dydx probably the logic there which is very complicated couldn't have been achieved in these sort of asic you know nand wires model just this would no one would sign off on it as being secure it was too complex but once you have a programming language you can write code and audit it and inspect it and that's how cairo came about and then we wrote all of our star kick systems in this way

and then what happened was this turned out to be so efficient and usable that we said wait why not open this to the whole world to use and that's how stark net came about so today we have startnet whose operating system is also written in cairo and people can use cairo for writing smart contracts that basically came you know that are using a programming language and they're using a programming language that is very battle tested you know with hundreds of billions of dollars of trades and several different systems on them and that's i think very comforting to know this approach is

quite different right from um the one that sort of other layer to take um because if we for example look at they have been struggling to get any traction um compared to the simple evm forks like let's say like polygon or binance smart chain or other chains that simply [ __ ] the evm and where you have what they call um evm equivalent so you can just take your your code and just deploy it there whereas in the original ovm you had to make even just minor changes to the code um in order to get it to work but that still sort of held them back substantially so i would i would be interested in so why do you have the confidence that you can

require users to rewrite everything from scratch in a completely new programming language um and still sort of compete um with those who offer evm equivalents right so um the bet we we made with this approach is something like this when there's huge need and demand for something i mean of course it would be really great if you could just press a button and have your code uh which let's say you wrote in solidity work on on some layer two yeah by analogy it would be really really great if you could just take your python code and press a button

and have it be a smart contract in in ethereum right or any other [Music] any other program that you wrote right but you know multi multiple teams of developers have gone through the effort substantial effort of learning solidity um or other languages yule and whatnot in order to program for this environment because they recognize that blockchains are something new they are a bit different they have a set of complexity parameters that operate differently and you know we're still too young to uh believe that this technology can just work out of the box with you know everything just perfectly fine

uh you know on your favorite earlier code base now we we believe this is the bet we're taking that with uh startnet the same thing is going to happen where people that need the scale and the you know compressed execution layer that is offered essentially only by starknet um if you really think about it with the security level of l1 and without any change to the assumptions there then we think that they will understand that it's in their interest to learn this new framework and work in it and we see some very encouraging steps you know a lot of very good teams are working on it now i just want to say that even

even if we had and of course there was a a very important project being executed right now by nethermine called warp that is exactly a transpiler from solidity to cairo so this will exist okay but i just want to say that if you take you you mentioned dydx earlier if they just took their previous set of l1 contracts and compiled them and even if everything would have worked well they wouldn't have achieved the functionality that they achieved now with our system and the reason is that most solidity code has been written to work within the constraints the execution layer constraints the limited gas of layer 1.

once you move to starknet you have nearly unlimited computation so even if you continue to work in solidity you would significantly rewrite your applications to benefit from that larger compute so if you're going to rewrite your computation and you want to maximize its utility we see good indication that the developers understand that you're going to want to rewrite it in the native language for that environment that maya that makes a lot of sense to me so it's not just it's a different paradigm but also you may want to change your business logic anyway right for example yes cross position margin just doesn't work on

layer one it's too expensive to compute but if you are if you want to have a derivatives exchange that competes with other derivatives exchanges in a computationally cheaper environment then you have to offer those things or you will get out competed so it's not just you could not not like you could port it and the same goes for something like unisop it's not like you can be successful reporting uniswap um to starknet right because much better like unisop only works because it's sort of the most efficient thing in a very computationally constrained environment but it doesn't mean that it could compete in a less computationally constrained environment and that's why

yes exactly i don't think you'll see uh on wall street amms and the reason you don't see them you know even though trading has been there for hundreds of years yeah the reason you don't see them is because they are much less efficient than you know standard order books and things like that and dark pools and whatnot the only reason they thrive uh and and by the way as a consequence i think they will thrive only temporarily because what's gonna happen is that starknet and maybe other l2s are gonna offer um a non-custodial experience that is much more standard trading and not amms and i think that's where the market will go completely agree

so what has the early feedback been from developers about cairo and if i'm a developer how do i best pick up cairo today what are the steps that you recommend here in the resources so like every new thing new technology there's a lot to improve so definitely we get a lot of tremendously valuable feedback on features that need to be added and you know i'm not gonna uh whitewash it this is uh these are the early stages of of the system so uh you know you're coming to the new world and uh you don't have as much facilities as you had um this was the same for solidity in the early days that's

perfectly fine um i think we are pleasantly surprised by how uh positive the reception for starknet and cairo is uh so argent yesterday uh already published their uh wallet that will allow you to interact on on uh starknet um it is of course uh major parts of it are written in cairo their experience was a very good one um you know many exchanges and amms are building i think they are very happy with the level of support that they're seeing um so so i think overall we're very

pleasantly surprised to see the reception then to learn it i will basically send you some links that you can just post and basically you know if you go to startnet.io or to cairoland.org you will basically have all the information and documentation you need to get started so the last topic of the day that i would like to discuss with you is scaling the verifier and the prover right so we discussed earlier it's only true scalability if um at least the verification cost can stay maybe not constant but at least like it

grows much slower than um because actually performing the computation right so in to you know get a better feeling of this and also how sort of the um the stark system is going to evolve in the future i would like to unpack the different costs that go um into it for the end user okay so let's unpack what happens as you scale up which in our in our case means that you increase the size of of a batch right the size of a batch being proof let's say from 1 000 transactions to 10 000 100 000 and so on so what what's going to happen to the costs the amortized proving time which means

the amount of time you're spending proving per transaction will grow slowly and it grows like n times logarithm of n so again to take the analogy we had earlier on for a million transactions taking logarithm to be base 10 is the number of digits for million transactions that means six steps per transaction whereas for a billion transactions it means nine steps per transaction amortized so the amortized proving cost per transaction has gone up as the scale increases on the other hand and this already

discussed the verification time the amortized verification time drops dramatically so it dropped from six per transaction in assuming one million gauss for every gas for every digit so we had like uh amortized gas in verification of six gas per transaction if it's a batch of size one million and as you go up to 1 billion that becomes a negligible fraction of a single gas per transaction because it is 9 million divided by [Music] 1 billion so that's roughly like 10 million

divided by 1 billion which is one over 100 so you went down from six gas per transaction to one percent of a gas to one over 100 gas so 100 transactions cost you one gas so this is very dramatic on the verification side and you have a very slow amortized increase in cost on the proving side wow actually i thought that the verification verification cost um grows very slowly but i thought that the proving cost would grow linearly with the number of transactions that you put in so i was wrong about that grows slightly slightly worse than linear it grows mathematically we call it quasi-linear

which means as n goes to infinity you're proving time scales like n times a polynomial in the logarithm of n so n poly log n so it means uh if we take uh you know poly log n to be just the number of digits to represent and that's how you get you know six times n for one million and nine times n for one billion so let's using for example like n of 100 transactions um if you scale that to a thousand the cost the the proving time does it increase also by a factor of ten or less or more slightly more than ten ah okay so what can be done um sort of in order to

um to lower the the cost of that what what is possible in the future of proving yeah yeah there are a number of things that can be done the the the first thing that is uh um most immediate and likely the first thing that stark oil will will be done and and work on this already has started is use of recursive proofing which basically allows you to take let's say instead of moving from a batch of size 100 to 1000 you could move from a batch of size 100 to 10 proofs of size 100 but then prove that you verified all 10 of them and this can allow you to have now 10

provers running in parallel each one of them for 100 and then some additional costs for verifying the 10 proofs and this will allow you to reduce latency and increase scale so that's one thing that you can do another thing that you can do is start changing some of the elements inside the proof for instance right now for security we're using as our cryptographic primitives for instance the hashes that we use to keep our data saver data and committed to it is a peterson hash which is very secure it's uh provably secure you can reduce it to the discrete logarithm problem but on the other hand it's not as

efficient as some newer constructions specifically poseidon and rescue and gmc and things like that so now all the other validity-proof systems are using these newer uh schemes uh you know aztecs the key sync maidan mir mina z cash they're all using versions of mimsi posadon or rescue so and those primitives are roughly 10x more efficient than peterson so we could replace that and get like 10x improvement on that part of using these cryptographic primitives we could change things like uh you know there are other parameters of the basic proof systems

uh that we haven't you know modified recently and we can play with those like decrease the size of the fields to get more efficient proving time and then of course down the line you have hardware like dedicated hardware for generating proofs once there's enough demand for proving machines right so we saw this with regular asics for bitcoin first there were cpus um then gpus fpgas and then eventually or not in that order but then eventually we got asics that are highly specialized machines that only do 256 basically and nothing else and so expect this to emerge um how how how big are the possible

savings from something like that because it's not it isn't very complex still right it's not as simple as just running shaft 256 over and over again yeah so well it's it's a bit complicated to estimate but i think that um like with recursion there's a very high potential for because you can now paralyze proof generation and then also uh reduce latency and increase proof batch size so you could easily get anywhere between a factor 10 to 100 improvement sorry maybe even a thousand down on the line just from that thing alone replacing the crypto primitives can give

you on that part it gives you like a 10x improvement but that's only part of the proofs being generated the cryptographic primitive so let's say i don't know you say between you know that gives you anywhere between 2 and 5x on top of whatever went into the uh these are all you know accumulative it's not one and not the other then if you change the field size you probably get another two to four x improvement in many aspects of the system and again all these can multiply and compound one another and then hardware it's really really hard to say because we haven't really started even thinking about that and the system you know the core system isn't yet stable enough for us to say

this is the way you're gonna use hardware but i would just guess another 10 to 100x just because hardware has that effect makes sense so does this mean you will re you use this recursive proving approach also to create one proof for a bunch of different x plus dark net and so on yes uh so some version of this already is in production today so the sharp uh service which means shared prover what does it do it takes several different programs let's say one for diversify one for dydx one for starknet and it generates one single proof that all of these different systems

advanced correctly this is the sharp capability so it already takes several different things and puts them together so this is already working and it's offering great savings to all of the different uh you know applications and it's especially important for small applications so in starting it will be sharp proofed with the other things already from the start recursion does goes one step beyond that because now one of those programs being proved as part of the sharp batch is that some proof has been verified so you can get this exponential savings sort of amplified and multiplied okay so i think that covers the proving

cost next we have the verification cost um and this is basically it's the cost of basically posting the the final proof to the layer one and then it gets um verified by um so in this case who verifies it is it is the the dydx smart contract right for example um there's a cairo verifier that verifies the that basically it gets basically a hash of a program which is the dydx program and it and then a proof in a state update and it basically says okay we check this program and this is the new state and everything's fine and this then goes to the dydx contract that

basically gets this as input and says okay so now we're fine with updating the state of our system uh so they're like two different contracts um and in terms of reducing the gas cost for verifying a proof so one thing that's going to be seems to that likely to happen even if we do nothing is eap 4488 which will reduce by roughly 5x the cost of the gas cost of transmission and of the several million gas that we're paying per proof let's say five million nominally roughly half of that is going uh well it depends and varies but let's say half of that or 70 of that is transmission

and if that part reduces by a factor of 5x then you'll see our gas cost going down by that by let's say you know factor two to three so from five million maybe to one or two million gas cost after eip 44.88 oh that's okay and then the final cost is um that of storing the data right now in this case i think we're not talking about the final state update right which is not big we are talking about the the different balance changes that led to this update right so why do we need it according to my understanding it is so somebody if if the current

sequencer leaves or the current approver then for that somebody else can um take the last date and sort of um and the the transactions or the the state changes and like continue um the work of this the approver right okay yeah so like uh for state updates um well i mean there are several answers one is that you save a little bit because you only need to update the final state diff and you already save there with things like in the dydx system um

in roll-up mode you can try and do compression and then the limit to that will be the information theoretic limit to how much entropy does a change have and another you know the next phase which will be also on startnet will be to have layer 2 data availability decentralized and incentivized by various uh crypto economic mechanisms so that users will have the option of trading you know security versus cost this is something we call volition so either you keep your data on l1 in roll up mode and then you pay slightly more or you keep it on layer two and then you

pay slightly less but uh you take the risk of this uh security of layer two so if you keep it on layer one then you know it's definitely gonna be available unless the layer one breaks whereas if you decide to i mean you could even say i want eli to store it on his phone right in theory you can choose any anyone who would be willing to store your data and sort of make a bet that they will provide it to you when you need it and the time so the time when you need it is only if you wanna withdraw from the layer one contract right if the if this sort of in the unhappy case where the sequencer leaves that's the only time where it really matters right where your data is stored well it also matters like if you picked

an untrust you know a a faulty or malicious data availability provider then the longer you keep your data with him then the more you are at risk is there any risk for me sort of in the happy case like let's say dydx progresses normally and starkware is honest as well but i i use a data ability provider who sort of becomes faulty does this have any risk for me without dydx or starkware becoming 40 themselves well i think in the dydx and starquer system first of all it's roll-up mode but let's say you know on diversifier

immutable x which is um validium there basically starker and the white and diversifies or immutable are already relying on the data availability committee so as long as we and they are not faulty you will have your data but i thought that like on starting it you were envisioning some very interesting system where like just like you could decide on which cloud you want to keep your photographs maybe you some contracts will say look you just pick your data availability provider and when you need it on our layer two just tell us you know what is the path to your state and uh we'll take it from there um i could envision i i could see such a thing

happening in the market for that and then uh if this uh you know if this amazon cloud analog is is faulty then you'll have problems okay so it puts me in problems even if i don't want to withdraw from the layer one because even like you will need you as the user you will need to provide the some of these smart contracts with information about the location of you know your part of the storage so maybe and maybe those smart contracts don't want to know like you picked your you know you picked your cloud you decided where to put it so my smart contract doesn't need to know that each time you interact with it you go and tell me where where you know that you

have yay many funds here and then it will be your problem so in a volition every user even though they're in the same state they can choose where they want their data stored i think that's one of the coolest things that i've heard in the last year in crypto um because then every user only needs to pay for the security that they actually need right if they want to make a large transaction for example they might want to prefer more security how does it work if um two users are in the same state and one user has a faulty index say data availability committee um so what hap so the other transactions of

the other users who have a good provider they will continue to get process right what what happens to those of um of a user whose data is no longer available well at the very least there's that user's data problem i i just want to stress that that um the layer 2 will likely have its sort of layer 2 volidium which will probably have higher security than and maybe cost a little bit more than the various validiums that would be offered by um by you know various entities um and that's probably going to be safer because we'll crypto incentivize it uh properly i hope so yeah so now like if you have a smart contract that is willing to allow you to work in

you know full free-ranging volition which says you say where your data is kept and it's your business to bring the latest state update then i would imagine that the dapp developers for those smart contracts would probably want to have some separation where if your data availability provider did something really bad then it won't it will be sort of in your compartment and won't so maybe you can't trade anymore until you sort it out but it won't stall the system that would be a good design so like maybe yeah all the other um all the other participants who have their data can continue using the system and only those whose data has been

compromised by that faulty provider are at risk oh yeah okay that would make sense got it um so yeah okay to summarize we have basically the the end cost of using the system depends on the proving cost the verification cost on the layer one and then the cost of storing your data and there you have many different options for what you want to choose um so we earlier talked about sort of the the cost of using the udx we said it would be let's say 300 000 gas on layer one per transaction but using stockwear or stockx it's only in the range of 300 to 400 gas but this did not include um the proving cost right

this this only end end well it's in rollup mode right so it did include the data storage cost but not the um the proving costs so how big is the proving cost right now if we were to factor that in and can you share if sort of after you know the fees generated from dydx and if the system is already profitable to run because this seems kind of relevant if we were to decentralize this soon um then it must be profitable for um for the other provers to run it right so um without going too much into you know particular contemporary business details that are very much going to change by the time we

decentralize and open proverbs and sequencers for everyone um suffice it to say that the you know amazon or cloud cost that we're paying for running the proving servers are negligible you know much less than five percent of the l1 cost that we are paying uh significantly less so the gas cost that proofs are costing you know the each time you submit a proof uh you pay a certain let's say if it's five million gas right so you pay i don't know how many thousands of dollars that costs you if you look at how much did you pay you know to amazon or google for the proving that went you know several hours of proving uh for

generating this it is negligible compared to those uh negligible compared to those thousands of dollars of gas fees oh interesting i i would have thought that the proving costs are sort of the big one but it's actually the verification cost today well gas is a gas yes yes since the start the price the cost of uh of running the prover machines has always been completely negligible compared to the cost of uh putting the proofs on layer one the gas cost in what way is this or if at all is this sort of relayed to users today um [Music] you said there's two smart contracts

involved right with eventually like getting the proof on layer one so startware smart contract i i so i assume that you are currently subsidizing this but then for dydx's part they are subsidizing it right so our customers who are using star kick systems they basically pay the gas cost the l1 gas cost we incur the you know the amazon compute costs um and the way i think all of them work is they don't charge their users for gas but because they have various kinds of fees you know uh transaction fees and whatnot um they cover it from there or they subsidize it in some cases so i think that for instance trading of nfts

on immutablex currently is is free so it means that whatever incremental cost for gas you have and there is some cost there subsidizing that part right i think that actually that like intuitively that makes much more sense that it will eventually on ethereum layer one it will only be applications paying to prove sort of their computation and it won't ever be like regular users right you will only have proof like some maybe some settlements but mostly just you know verifying different proofs of off-chain computation that's certainly the case on all of our uh layer two uh systems right now the star kick systems now in start

net currently there are no fees uh later on there will be fees and these fees will be designed to cover the cost of gas on l1 got it thank you um eli this has been a fascinating conversation i learned so much about starkware and starkx and starknet and i must say this to me it's one of the most interesting um pieces of technology being built right now and as far as i can see it's sort of the only what happens sort of in the roll-up space to me is the only thing that looks like real scalability to me in crypto thank you jesus both for having me on this and also for you know carrying out what is probably the

deepest most profound uh techno technological uh podcast on blockchains thank you so much have a good day thank you [Music]