Danksharding Workshop | Devcon Bogotá

foreign [Music] sharding design that proposed by dankara he's here today in 2021 and so in this new design that it unlocked so many scaling um I mean The Challenge and it's not that now the charted data we don't we shot it at the data blocks rather than having many EVN instructions but the dog shotting protocol is there are still some um technical challenge that we need to fix so right before we have to fall down cutting uh Proto is also here and uh many of us um they call elaborate it and figure out that we can have a more feasible Solutions like in the short term to address this cell links and it can greatly scale the ethereum with their two Roll-Ups in the very near future so that's the Proto and dankara and this is the Proto then [Music] okay so there are some and many common features in both eip4 and the default then sharding so today we will break down these topics and you can see that they both have the kcg commitment so um Democrat will introduce the cryptography part uh first and they also have the blobs transactions so we will also introduce like what is blob today and fee Market is also the shared common features here and um so the challenging part of dunk charting is the PBS and the DS so we will also talk about it later okay there's the agenda today we have a very rich agenda in the next two hours so yeah and that will I will hand it to duncra next to introduce the cryptography in Junction so if you can go through this you will know everything okay thank you thank you Sarah cool so um I will uh be giving an introduction um to kcg commitments um uh I'll be starting with giving you motivation to um to understand why why we need these Advanced polynomial commitments and why we can't do all this uh simply with uh Merkel routes which we're all quite familiar with um uh so I'll be going through the motivation uh I'll quickly go give an overview over the final fields that we that we use in order to commit to uh polynomials uh um I will kind of motivate ktg commitments as like hashes of polynomials um then go to the actual meet which is um how do kcg commitments work and finally because we also use these a lot in our construction now I will be going through the technique uh which I call random evaluation which is um a nice trick that you can often use to to work with polynomials and that uh that makes a lot of um things that you want to do with polynomials a lot more efficient um cool so let's talk about uh data available assembling and eraser coding so um so so what is data availability sampling so the idea is uh we somehow have a large blob of data and um and what we're working on are scalability so scalability means that somehow we have to make it so that a node has to to uh do less work to achieve the same thing that we do today so right now every node ensures that all ethereum blocks are available by downloading all the blocks um that's just an implicit part of it like it seems obvious because right now you also execute the full blocks but it's one of the things that don't scale in the current ethereum system so we need a way um to to reduce this this workload but we want to do it in such a way that we don't lose any of the security that this provides and that that's what makes us tricky and um so like the the basic idea is okay but if we take our um data blob and we just checked um uh that's random samples um of uh the data are available um so if we do this naively if we just take the data as it is then this this does not uh this does not really work um uh because uh even even missing a tiny amount of data um is catastrophic potentially for a blockchain um but but best by by doing random sampling you can never find out whether a tiny bit is missing you can only see whether major parts of the data are missing so what we'll need to do is in order for this technique to work um is we need to encode the data in such a way that um uh that even having some parts of the data say 50 is enough to guarantee that all the data is available um and so the way we do this is we extend the data using um a so-called resolomon code and um if you know a little bit about polynomials like um a real Solomon code is nothing else but but extending um the data using polynomials so what you do is let's say like in the simple example um we have four blocks of original data and what we'll do is we'll um we will take these four as evaluation as of a polynomial there will always be a polynomial of degree three that goes uh through these four points and then we can evaluate this polynomial for more points and what this means because Four Points always determine a polynomial of degree three that any of these four points are enough to reconstruct exactly the same polynomial it does not matter which four points you have and so this this is like this is the basis of Erasure coding and now because of this the data will be sampling idea that we had here and actually works because now I don't need to ensure that every single bit of the data is available now I only need to know that at least 50 of the data available and then I can always reconstruct everything yeah sure yes yeah we have double the data no so that's the trick so um we do random sampling so as an example we query 30 random blocks so if the data is not available that means the attacker needs to have withheld 50 because if they submitted more than 50 to the to the network it's all there okay so if it's not available then each of these samples because we used local Randomness to query them has only a 50 chance um of succeeding so that means in aggregate the probability that all of them succeed is now 2 to the minus 30 which is one in a billion so this is why it scales you don't need to ensure you don't need to query 50 of the data you only need to do like a tiny number of random samples and this number is constant so it does not depend on the amount of data foreign okay so what if we now we have this polynomials polynomial so we have these evaluations this was the original data d0 to D3 and then we have these extensions that we computed and we just compute an a normal Merkel Tree on top of that and use this root as our datability root so the problem with this is that mercury Roots do not tell you anything about the content of the data so like it could be anything so in this case let's say an attacker wants to trick our data availability system they could just not use this polynomial extension but they could just put random data so basically in coding terms they have provided an invalid code what that means is that any if you get four different chunks of this data you would always get a different polynomial so you would like so consensus is all about agreeing on like something like and and in this case we wouldn't actually have agreed on something because the data is different depending on which um on on which of these samples we've got so the only way to make this work is if we if we add fraud proofs to the system where you basically prove uh prove that um that someone has provided this invalid code um but that uh that isn't great so that that has some problems um they add a lot of complexity and particularly in this case because this is about the layer 1 itself it would make our system very very difficult to design because now validators um would need to basically wait for this fraud proof in order to know which block to even vote for so they would be kind of vary a fee to design this um so the interesting question is what if we could find some kind of commitment um that instead always commits to a polynomial so we always know that the encoding is valid cool and that is why we will introduce kcg commitments and we need to start a little bit earlier so I will start from by introducing finite Fields a little bit for those that who are not familiar with it okay so I can do it from you um okay so what's the finite field okay so to understand uh what a field is um it's basically think about um rational real or complex numbers which you've already learned about and um just remind yourself like we have basic operations that we can do in them we can add subtract multiply and divide and we can do that do all of these except division by zero so that you're always um you're always able to to do these operations and you have some uh you have some laws like their associative commutative distributive basic basically just think of like I mean I I could give like the formal laws here but I don't think that would be the best illustration because you're already very familiar with these rules when you work with um rational or real numbers and the big difference finite feels is that unlike um uh unlike these uh these fields that we're very familiar with they which all have an infinite number of elements they have a finite number of elements that's quite important because otherwise we can't encode them with a finite number of bits which is yeah kind of like something that we that we need to be able to do um so yeah so that means that each element can be represented using the same number of bits and um as an example uh on of showing how this works here's he has a very small finite field this is F5 and basically the way it works is you uh you take uh the five numbers zero one two three four and um and you you use your normal integer operations um to compute um like the addition subtraction and multiplication uh but whenever you've done that you take the result and do module um take the remainder after division by five so you take it modulo five and then um when you write it out um basically you'll find that for each element so we haven't yet defined like how do we do division um so if you write down the multiplication table you'll find that each element has actually an inverse so basically um if you take uh for example here like a 2 then you can see that 2 times 3 is 6 but modulo five that's one so it has an inverse okay that's nice and like then the other way around three the inverse is two and for four um if you take four times four it's 16 and it's uh um and that's that's again modular five that's one um and so we've just found like by just listing these these numbers that um every element has an inverse and the reason for that that is that 5 is a prime number so whenever we to take these modular operations modular prime number um then then we'll find that we actually have a finite field um and so that that's our final Fields [Music] um um except that the fields we're going to be working with in practice will have a lot more elements so the prime that we're going to be using will have 255 bits so it's like a very very big number because yeah we want to be able to represent a lot of numbers in this field cool okay let's think of um hashing polynomials okay so a quick reminder what's a polynomial um so a polynomial as an expression um of this form so it's like a sum over some coefficients f i and uh and uh and terms of the of times term of the form x to the power five so the property is that um uh this it has to be finite sum so it's a sum from zero to n and we is is the degree of the polynomial and um and basically the other important thing that you have to always remind yourself there can never be any negative terms so you cannot have x to the minus one it's only terms of the form x to the power of 0 1 2 3 and so on um yeah and um and each polynomial defines a polynomial function so it's important to distinguish between the two so polynomial is just an expression of this type so it's just you could think of it even as a list of coefficients um and like and then it defines a function but like for example in some Fields um like in finite Fields you you will have the property that the same polynomial function can have many polynomials corresponding to it because there's only a finite number of functions but there's an infinite number of unpolynomials um this this property you don't have in infinite fields um and so the the cool property that polynomials have is that for any K points there will always be a polynomial of degree K Min K minus one or lower that goes to all of these points and um and that's polynomial is unique um and the other um uh properties property is that a polynomial of degree um n that is not constant um has at most n zeros okay um so what what what would be cool if we could imagine a hash function for polynomials so let's imagine that we could have a hash function um that uh takes a polynomial um and hashes it okay that's easy but it should have a have an extra property which is that we can construct proofs of evaluation so basically what we want is that for any Z so any point um uh we want we can evaluate those polynomials comply compute y equals F of that and we want um some um some proof that this is correct so that that um that would be um an interesting hash of polynomials that gives us something new and um and this this hash and the proof um should be small in some sense so um here here's some idea okay um what if we just choose a random number for example let's say we choose the number three um if we want to Hash a polynomial we just evaluate it at this random number um three so we said we put x equals three um here's a couple of um examples how that works if we stay in our small field F5 for between that five and before with just those five numbers so if the opponium is x squared plus 2X plus 4 then the hash is like x squared 9 plus 2X 6 plus 4 modular 5 is 4. and then here's a second example so a bit of a bigger polynomial module 5 in this case it's zero okay um that that seems a bit stupid to just do it at one point but the interesting thing is if our modulus has 256 bits which is what we're going to work with in practice it's actually extremely unlikely that two randomly chosen polynomials have the same hash and quotation marks just like it is for a normal hash function right so uh that that that's an interesting property like I mean it seems like a very stupid and simple operation but in some ways in one way it already has like a property like a hash okay um okay so if we accept this for now then let's have a look at some of the things we could we could do with it um so for example we can actually add two hashes of polynomials um so like if we have uh if we have the hash of uh take oops that should we take up the hash of two functions uh hash of F and F hash of G then the hash will just be the sum like the hash of the some of the functions will just be the the hash of F and plus the hash of G um and that's because of this homomorphic property which is Trivial if you write it out in polynomials um and the same is true if you um uh if you multiply two of these polynomials and that's just because polynomial evaluation itself is a homomorphic property like if you you can either first add to polynomials then evaluate them or you can like do evaluate them and then add the result and the same for multiplication so it has some really cool properties if we could use this hash function uh but there's one problem um uh if if you use this um then if someone knows this random number right then they could easily create a collision of this polynomial function because um while for random polynomials it's very unlikely that they evaluate to the same point it is very easy to create like manually to polynomials that evaluate to the same value at this random number um so it doesn't quite work as a hash function as we know it um but what um it would be different if somehow instead we could put this random number into a black box so if we could uh if we could find a way of computing with these finite field elements um but instead of giving everyone who wants to evaluate this hash function giving them the actual number you give them a black box um so like we we said we assume we have a cryptographic way of putting a number into a black box and then we give them um our random number s and we give them also like the random number s squared and S to the power of three but all of them only in the Black Box um and we do it in such a way like this black box needs to have the property that you can multiply it with another number and you can add two of these but you cannot multiply two numbers in a black box foreign if you could do that um then this would actually work because now the attacker would not be able um to like create these two polynomials because they don't know they don't know this this number um and so they they cannot um they cannot craft handcraft the polynomials that so that they evaluate to the same uh number at that point and basically the cool thing is that elliptic curves actually um give you give you exactly that so um uh elliptic curves um are basically uh you you can think of them as a way of creating Black Box finite field elements and the finite field that you have to use is the curve order of that elliptic curve so if we have an elliptic curve um which we call G1 why we need this in xg1 we'll come to later but it's just elliptic curve that has a generator which means that that's a point so that the um if you if you add that point again and again um it will generate uh your whole curve and um the the order of the curve is p so that's the number of points um and then basically we have the property that uh that x times G where X is a finite field element x times G1 um it's basically this black box and the reason for that is that it is hard to compute so-called discrete logarithms so it's um it's difficult like when you when you have computed this x times G1 um it is uh it is difficult um to to compute X from that point um so that's that's a cryptographic assumption and so if we have that um then if we take uh two um if we took two elliptic graph elements um G and H um then we can multiply them with field elements like we can compute x times G we can add add the two G plus h and we can compute linear combinations like x times G Plus y times H but what we can't compute is we can't we can't without Computing the discrete logarithm with the chat we can't compute something like G times h and so um just like we uh we said before like we we want this black box so we will introduce the notation um like X and squared brackets one for saying that it's in this uh G1 which is the first elliptic curve we're going to use we need later we'll need another one um we Define that at x times G1 and so basically when you when you see these square brackets think of it as like this is a prime field uh element in this black box in this elliptic curve black box so we can put stuff inside and there's no easy way to take them back out but we can do some computations while they're in there cool and with us we are ready to introduce KCT commitments okay so what we're going to do is we're going to introduce a trusted setup so we're going to assume that um uh that that someone has um computed with has taken a random number as um and they've computed inside this block box and given to us and the powers of s s to the power of uh 0 1 2 3 and so on in our black box and actually forget this second one for now we'll come to that later um and um and so uh if we take a polynomial function so we've defined this previously so it looks like this it's like a sum of coefficients times powers of X and we Define the kcg commitments as um as this sum which we can evaluate so we take the coefficients and we replace x to the power of I by S to the power of I inside this black box and here on the left like so this is something we can obviously compute it's just a linear combination of these elements which we have been given as part of the trusted setup and uh and the cool thing is if you write this out in in effect if it is it is just an F to the power of s um evaluated inside this black box so effectively we've come back to what we said before um it's just this random evaluation but we've managed to now randomly evaluate this polynomial inside a black box at the secret point and um uh yes and this this we call the kcg commitment to the function f and um now in order to um uh to do interesting things with this um we'll need to introduce an elliptic curve pairing so this is where we where we get our second group so we actually need a total of two two groups and what we'll have is we we have a pairing is a function from two elliptic curve groups and a Target Group which is a different kind of group It's actually an elliptic curve but that's not too important here and it takes basically these two elliptic curve elements one in G1 and one G2 and it has the cool property that it is um what we call bilinear and so that what that means is that um you can you can compute this um uh this linear combination so for example if you have the pairing of a times x and z that's basically you can take this a out um the same in the second coefficient and in addition if you have the sum then um uh then basically um what it does uh it it splits into these two so it's like a distributive law here X Plus y times Z is e of x z and E of y z and the same goes again in the in the second parameter of this function and um and basically the cool thing is um that uh that this um what what we couldn't do before um inside yeah foreign yes um and so what we couldn't do previously between elliptic curve points which is multiply um multiply two elliptic curve points um is that we can do in a way between pairing so if we have one of our points in the in this first group and one in the second group then due to this bilinear property we can it actually in in the in the Target group it computes something like x times y right so it has this property we Define we Define this additional notation for the Target group and then we have this very clean and nice equation that the pairing of um X as a black box element y as a black box element is x times y so this is very important basically at this point when we have the pairings and that's why we really need them we can do one multiplication you can we can only do one because afterwards we get this target group element and that we can't really do anything with um but it turns out that this is actually um actually enough to do like a lot of very useful stuff in elliptic curves that we have two polynomials um f and g and we commit to those polynomials but we come commit to F in G1 and G in um in G2 in the different groups then um then basically this pairing actually lets us compute this like the product of these two commitments um in the Target group so basically um in this really cool polynomial hash that we have defined we can now um if we commit to them in the in the right groups we can now multiply two polynomials um that are committed in this way so we can multiply the the commitments without even knowing the polynomials themselves okay cool um okay so we will need uh to introduce one uh one last missing piece in order to fully come to how um how kcg commitments work and how we can construct proofs and that is uh quotient of polynomials okay so let's say we have foreign we have a polynomial f of x and we have two field elements y and z and then we can we can compute this quotient Q of x um this is a rational function right so like a polynomial divided by a polynomial is in general a rational function um so you can just see this as like a formal expression um but sometimes this quotient is exact so sometimes like this quotient will actually result in another polynomial and basically there's a theorem that's called the factor theorem um It's relatively elementary math you've probably learned that in school at some point without calling it that basically says that this is a polynomial disclosion um exactly if F of Z equals y EP and um I mean you can kind of see like that um in One Direction because f of x f of x equals y then um then at the if you set x equals y you get a zero here um f of z f of Z here and you get a zero here so like zero by zero that can that that that that that can only like that yeah so sorry if if the quotient is zero at Z that can only work if this is also zero at that Z So like um so it can only really work if this is this is correct but the other direction is a slightly um slightly more complicated so if you restate this basically we get the fact that we get the polynomial that fulfills the equation this equation so we just put the x minus C on the other side Q of x times x minus D equals f of x minus y if and only a f of Z equals y [Music] okay um and now we get to how the kcg proofs work so if approver wants to prove that um f of Z equals y the computer desk version Q of X which is f of x minus y divided by x minus Z and Center proof Pi which is Q of s so the commitment to the polynomial polynomial Q um and in order to verify this um uh what the verifier will do is um they'll take this quotient and they will multiply it by the commitment to S minus Z and check that this is the same as original polynomial the commitment to that minus y and sorry this is unfortunate very readable on this background um because if you write it out in this pairing group then you get um on the right hand side Q of s times s minus Z in the Target group equals F of s minus y and this is the same as the second equation so the cool thing is we can verify this equation because we are able to multiply two polynomial commitments inside using the pairing and this way we can verify that the portion was actually computed correctly cool yeah and that that is basically that that is the that is how kcg commitments work so like just to yeah so yeah um so so the idea is just um if you can compute this this quotient then you'll be able to find something that fulfills this equation and using the factor ethereum that we mentioned previously if F of Z is not y then you cannot compute this it doesn't exist it's not a polynomial and we can only commit to polynomials so yeah this is the recap on the kcg commitment we can commit to any polynomial using a single element in G1 and um it is and this is just the version valuation of the polynomial at the secret Point s um inside the black box we can open the commitment um at um any point so we can compute F of Z and by Computing the quotient Q of X we can um we can compute this proof which is Q of s in the black box and in order to verify that proof we use this pairing equation and um and that that shows a verifier that um this evaluation is correct sure cool so that is uh kcg our case G commitments work now there's uh I want to do something slightly more which is a technique that we use um quite a lot we have even using it in uh eip4844 and so I want to give a quick introduction into how it works which is uh with the random evaluation trick um okay um so basically let's recall that kcg commitments are nothing but evaluating a polynomial F at a second Point s inside this elliptic curve Black Box and um so in a way this is already like a random evaluation like but basically what we've done is we've we've identified this polynomial using random evaluation and we kind of we somehow found that this is good enough to like um to Hash a polynomial in a way that uh it's very difficult to create Collision and um more generally this random evasion trick can be used to verify polynomial identities and the reason for that is the amstrad's typical Lemma and I will just formulate as a more General one but let's say what it says in one dimension so let's have a degree a polynomial of degree less than n that is not identical to zero so there's one particular polynomial that is zero everywhere that's just like all zeros right that's a very special polynomial so let's say it's not that now let's take um a random uh Point Z in FP then the probability that F of that is zero is at most n over p and that's because it can have at most n zeros um and so this is a very useful thing because um our p is very very large and our degree is relatively small compared to it in our case so for example in for blast 1231 PES 255 bits say we commit to a polynomial of degree 2 to the 12th then as probability is something like 2 to the minus 240 so like it's a very very small probability okay um and so here here's the first way um in which uh in which we can use this so like we have this transaction blobs that um we'll Define for 4844 so it's like uh they are commitments to um polynomials with four thousand six ninety degree 4095 so a total for 1096 points and uh to committing such Computing such a commitment is not very expensive but it is expensive it's like for 50 milliseconds to do this but verify one kcg proof is um quite a lot cheaper it only costs about two milliseconds so we can use this to our advantage and so the idea is this we take our commitment to the polynomial see and we take the polynomial F itself so what we want to verify is that we have the polynomial that it's given to us in this case we have all the data and we have the commitment and the naive way we can just commitment to compute the commitment from the polynomial but that's expensive okay how can we do it cheaper um we do we compute a random point and one way to get a random point is actually a very cool technique it's called via chamir and we take all our inputs so we compute that as the hash of the commitment and the polynomial why is that kind of random because like if an attacker tries to craft something if they try to adversarially compute either C or F it will always change the point that so it's very hard for them to find some like uh to to craft them in a way that that breaks our construction so basically this is a common technique in and cryptography um to to get something random that the attacker cannot control and so um we evaluate this polynomial why at um at this random point that we've taken and then we compute a kcg proof that F of Z equals y and basically that then what we'll do is we just add this proof um to our transaction blob wrapper which is the way we're sending uh transactions and then like to verify this you compute he also compute F of Z which you can do because you have the data for that and you check the proof Pi the kcg proof and that's done and that's much much cheaper than Computing the commitment and so that's one way in which we can use random evaluations to like save us a lot of work and making things more efficient okay um so uh here's another way in which we can use those random evaluation technique and so ZK Roll-Ups um uh they use many different um proof schemes and so um only a handful I don't know if actually is there any right now um will use natively kcg commitments or over BLS 12 381. and so the question is like um how do all the other make efficient use of our blob commitments that we want to add with 4844 and then full charting um because like because Computing kcg commitments inside a proof or Computing pairings that is pretty expensive like that that um that's a very expensive operation in a zero knowledge proof and um so what we do in this case is basically you have to uh you you commit to the data in a different ways so we have uh we have three different inputs so we have our blob data which is this function f itself and um and we have two different type of commitments now we have C which is our blob commitment which is what we'll use um inside ethereum um uh for 4844 and we have another way of committing to this data which is using um the the ZK Roll-Ups native commitment so they will in some way um it will also have some way of committing to data that that works well for the as you know it's proof scheme and so in this case what we'll do is we'll take Z as a hash of C and R like these two different commitments and um we will compute y again as F of Z and we'll add um pi as a proof that F of Z equals y and we'll we'll add this pre-compile that allows us in the ethereum virtual machine to verify that the the kcg proof pi um so we will know that c c is a correct commitment to f um and what we'll need to add is uh to add the proof that R is also an um a correct commitment and uh and the ZK roll-up can do that inside the proof so they will inside the proof um they also have to somehow get C and R as an input and hash them and compute that and then they can um they can evaluate so they will also have F because the rollup wants to use the data so f is completely available to them and they just have to compute um y equals F of Z and use some technique to verify that the f is the same as they are but that's there are ways to make this easy and then they can verify that they have the same data as was committed through C so that will make it much easier to use these commitments in ZK rollups okay cool and um yeah I collected uh some resources if you want to um read further on this um so vitalik wrote a while ago a post on elliptical pairings um um I uh because there was a lot of interest in that I wrote some notes on how on this last part how to use kcg commitments in ZK roll-ups um for those who are like kind of uh skeptical and they're like wondering do we really need um this like Advanced cryptography and trusted setup and so on um vitalik recently wrote a summary on like what what the difficulties are with um alternatives to KCT commitments um and um here this is uh if if you uh want kind of it's it's very similar to this talk but I I wrote a blog post about kcg commitments and then of course if you want to dive deep there's the um case the original kcg paper and if you scan this QR code there will be all these links yep okay if you look at the I think Christians I don't understand why where do you want to open it multiple times right right if each time you could have your separation are you talking about s or like the the The Trusted setup yes yeah is today is eventually right but this is a cryptographic probability right we're talking about I mean that's why we're setting the security to 2 to the minus 128 so 2 20. yeah is not right there yes but so we are setting in cryptography we are setting our security parameter already in the assumption that an attacker will do a lot of computation to try to break it like 2 to the 50 to the 60 or more computation power this is much much more than however we ever use it in in the actual protocol so like this is all already covered by the um by the cryptographic construction um I mean you can do it but the random probabilities like the probability of randomly hitting that are extremely extremely low like if you like if you construct it so that the probability so yeah yeah like randomly they are less than two to the minus 200 or something like that it's like so low you cannot even like yeah think about it yeah x to the P minus X right yes yeah no you can't but that's fine uh okay so we are always because we're limiting the degree of our polynomials right so our trusted setup will only go to a certain power for example to the power of 12 and inside that space there's only the zero polynomial yes yeah yeah so like if you have no limits on the polynomial decrease then it doesn't work but we always have a limit thank you thank you excellent excellent thank you dankrade for the math so okay so now we're gonna go into the bit more like kind of kind of like we're on the sky of math and we're kind of like tone it down into like the protocol stuff so I'm gonna start with a small like um explanation of how all this math stuff going to our protocol and how like you know all the extra bandwidth of 4844 travels around and gets verified then Proto is gonna take it and tone it even down into more practical stuff like how the l2s are gonna use the data and then answer card is going to turn it even more down and basically explain how people pay for this data so okay so basically um this is a graph that shows how um like Optimum optimism and L2 uh what is its costs and you can see that like this blue stuff is the data fees like how much money they are paying for the like data they put on chain and the other like white stuff is some other stuff but you can see that the blue the data is dominating all the costs so basically what 4844 is it's like a mechanism that drastically increases the amount of data people can post on chain um and this is all it is right so okay so basically um what we want to do is we want to increase the amount of data so um on this very simple picture on the left side you can see uh our data which we call blob because it's a bunch of data that also corresponds to polynomial and on the right hand side you can see a small thing a commitment that represents that data commits to that data and the like graph idea is that you know commitment goes and chain forever whereas The Blob is kind of like you know there for a bit and then disappears so this is like the high level strategy of how we increase bandwidth we commit to data we keep the commitment forever but the data is ephemeral in a way okay so let's talk a bit about what this data is what these blobs are how do polynomials enter this picture uh so okay this is a polynomial I think by now you're very familiar with it based on the last talk uh the question is like how do we put data into this polynomial and like the basic idea is you know you have these coefficients the A1 a2a whatever and each if you you can basically put data into this coefficient so you know if you have some data uh one four one six you can put it in the coefficient so you make this little polynomial on the bottom and that's like a very straightforward way to put data into polynomial so right so let's now think of like what like in in our case um let's see about these numbers one four one six how they can resemble real data so in our case uh the numbers are going to be finite field so they're going to be parts of a finite field which is going to be like a number between zero and this insanely huge prime number um and so each coefficient is going to be a number between these two things and that's about 254 bits that's about 31 bytes so a coefficient with a polynomial with like 4096 coefficients can store about 128 kilobytes by putting the stuff into the coefficients so you know now we know of a way to store 128 kilobytes into polynomial and that's kind of interesting because like you know right now roll ups they don't even use close to that number like maybe they use one kilobyte so we're basically giving lots and lots of space maybe even uncomfortably lots of space to roll ups to put their stuff in but this is like the whole idea of 4844 of course in reality we don't put the data into the coefficient and we put them in the valuations and then we're doing interpolation but like whatever this is not so relevant for this case the idea is that like you know when code data into polynomial and we have polynomials that correspond to a big amount of data and that's a blob right and you know then we have kcg which is what dunkrat was explaining for the past 45 minutes which is basically like a black box where you give a polynomial to the black box and spits out a commitment and the commitment is Tiny and the data is Big so you end up with a situation where you know you end up posting on chain lots of data and then a small commitment and this is like the rough idea so just to talk a bit about like when this data travels what the network is supposed to do you know like when you see a commitment that corresponds to lots of data what the network needs to do is like they need to make sure that the data corresponds to that commitment and like the the basic thing to do there the basic strategy of the verifier to make sure that someone is not like you know fooling us and giving us a wrong commitment to other data which would be catastrophic is to you know like commit to P of X use this black box again commit to it and then check that the commitment that the verifier computed matches the commitment that the guy gave you so that that's basically a pretty straightforward way to to verify um that polynomial matches the commitment but you know then we have more data and more commitments you know in a transaction you can have lots of those in a blog you can have block you can have lots of those and and that starts being quite expensive so what we end up doing because you know like it's 50 milliseconds to do each of the commitments so and it scales linearly so that ends up being quite expensive especially you know for mempool and this kind of stuff so in the end what we're using we're using kcg proofs and this whole random evaluation trick that dankrad taught you before and basically for it like data and commitment we also put a proof of a random evaluation so basically the proof is a helper that helps you um do this small verification I don't have enough time to go into the details but like the idea is that you know like the proof tells you that the committed polynomial evaluates to Y at Z and then you can also evaluate the polynomial on the left side at Z and get some other number and if the y1 and Y two matches you're certain that it's the same that the polynomial matches the commitment and this is much faster than doing the commitment manually um it's not my intention to go very deep into this I'm just giving you some idea of how kcg is used in the protocol so um I think I'm gonna stop here and and stop with the cryptography and pass it over to um Proto who's gonna go a bit deeper into the actual system thank you foreign so let's talk about the blob usage so with ep44 we're introducing a transaction type to make to confirm these blobs in the evm10 however something to note is that it's A New Concept here where we are having a transaction type left data outside of the transaction that's now responsibility of the consensus layer so it's like a regular erpm159 transaction then the transaction contains some pointers or hashes ready let's then commits to the develop data this is the transaction in a little bit more detail something else to note is that it's not ROP but as you see that mercolizes nicely it's better for layer too and then note here that we have these data hashes committing or to hashing the case D commitments which then commits to the film block data these data hashes are available in the evm through an opcodes whereas The Blob data lives outside of the evm so the blob content is unlike call data not available in evm eventually we can prune this block diagram it's not a long-term commitment to store of this block data but rather we are introducing this blob data and just for the availability properties a layer 2 needs this data to help users sync the latest states permissionlessly without communicating directly with the sequencer or whichever operator exists on the roll up and then people can reconstruct the latest stats they can have a different solution for retrieving for your old stuff it's like a month ago or a week like two weeks ago so that's the separation of data and the transaction itself so this is what the life cycle looks like as a layer to user you submit the transaction then we have this bindling as a layer two we often combine the transactions so you can pack them compress them and so on this is task for develop operator and then as a rollup operator you publish your bundle to layer one with this new transaction type and then in the transaction pool we have both the transactional paste the fee as well as the wrapper data with the actual blob content and then the layer bomb Beacon proposer creates a block and the blobs make their way from the transaction pool in the execution layer to the consensus layer and his parents the blobs don't get into the exclusion layer back it's just the responsibility of the consensus layer um pairs on the beacon that and they think the blobs bundle together with blobs from other transactions as a sidecar and then the execution payload stays on layer one whereas the blobs stay available for a sufficient amount of time to secure there too but then can be pruned afterwards so blob data is bounded this is what it looks like on the network level we have the layer 2 sequencer communicating with the transaction tool the execution engine communicating as the beacon proposer then Beacon notes syncing the blobs with each other and then there's the splits of the data where the other big nodes they give the execution payload process the ECM and everything fees will be processed by everybody the Deep blobs they are they stay in the contents layer into a layer two node retrieve stem to reconstruct the layer two stains so how do Roll-Ups work with this already explained the proof of equivalence trick so I'll give you just a simplified overview how we do this in the evm we introduced two new things in evm and opcodes and a pre-compile the up codes simply retrieves the data hash which is this this hash that is part of the transaction just like the hashes in the access list from the Berlin transaction type it can be retrieved through an opcart pushed on the stack and address this pre-compile which you can provide with a proof to verify that a certain data at a certain position matches the deep Loop contents committed to by the data hash and in the case of zika rollup we do so we use this pre-compile to do a randomly Federation and prove that the data that the rollup is importing is equivalent equal to the data that develops this into the blob is introducing this pre-compile is versioned so we can change the commitment scheme and in the future I hope we can use it for other things perhaps frequently verification then this is part two yes [Music] right so going back deep proof all the inputs that pre-compiled they're passed in a skull data The Blob is completely separate it's not involved in any of this computation [Music] and so it's just the core data that we're passing in um with a proof the index of the pointer trying to fit about the commitment that hashes to the hash that we retrieve from the up cards and then the pre-compile will verify everything um similarly we have the zika state transition that needs to be verified this is obviously can roll up specific um up to you to design this but with the data that's verified and the secret proof that's verified we can then get some outputs that we can persist and then use to enable withdrawals and then this is the version of the interactive optimistic roll-ups interactive optimistic rollups use this concept called a pre-image Oracle where we do not access all the data at the same time but rather we loads pre-images one at a time and by bisecting an execution Trace we only really have to do a proof for a single step a single execution um of a single like VM instruction and this might be loading some data so for example the start with a layer 1 block header hash then we retrieve the fill block header as a pre-image then we retrieve the transactions by digging into the Mercury commitment in the transactions hash and then we can get the data hashes from the transaction and then from the data hash we can get the case D commitment and then it's not a regular hash commitment anymore but there's a different type of commitment with the same Oracle where we loads one point from The Blob that is committed to by the plot transaction and so this way we can load all the data into the fraud proof VM I'm going to talk a little bit about now that we hopefully in the future will have this functionality how how can you pay for it but also kind of conceptually basically um I mean the data unboxing is already you know kind of pushing into limits like where's the extra space and resource-wise for this basically where where does the efficiency gain here come from um and to understand that first we have to just look in general about like how do how does research resource pricing on ethereum work today so this is just um kind of my way of thinking about categorizing the different resources we have we have on ethereum so there's things like bandwidth computes data Access Memory State growth history growth right this is all the kind of things and this is a non-exhaustive list right but this is this basically the kind of things that actually cause effort for nodes while they're processing um a transaction and if you squinted this hard enough you you'll notice it and that that basically two different types um of resources here and um we call those um basically burst limits and sustained limits and the best limits I think things where basically they they they cause costs or it can cost right at the moment that the the block the block is propagated right the bandwidth to to to to propagate a block the compute to actually verify it all of this the the the the the critical point there is that basically it has to be bounded um in order for blocks to still be propagated in a timely manner um and in order for notes to be able to to verify them at all right they might run out of resources and the sustained limits they don't matter so much block to block those are more things that accumulate over time so that state growth history grows these kind of things right like a single block can't really make it like produce too much damage there but over time it just basically makes it more and more costly to to to to run a full node um as it turns out like if you if you look at this um there's some sort of of structure to this and you can you can actually reorder this a little bit and it turns out that usually there's a relatively good matching between like a specific burst Limit and a specific sustained limit so bandwidth and and history growth kind of they correspond right because the bigger block is the bigger like the more bandwidth you need to propagate but then also the more disk space you need to just you know keep it round forever for history purposes and similar with State access and state growth these kind of things um now specifically for 4844 right what we are introducing is this new type of data so uh kind of the the resources we're talking about here this this first kind of row so it's um it's on those burst limits it's the bandwidth how how big can box get and then on the sustained limit it's just like how much resource do you need to store kind of the history of ethereum and and if you um uh if you put an engine and if you basically look into the AP a little bit you already know that like there is this this this limit um in terms of History growth we basically we introduced this new new um uh basically uh a mechanism where blobs are only stored for a single month and so this is basically why on the history course side we basically it it will it does mean that there will be is some extra requirement for node operators um but it's quite bounded Because unless normal history that today is stored forever but even after this this nice erp444 basically even even after that it's still going to be stored for a year um blobs are only stored for a month so basically in terms of sustained limits it's it's not basically it it has like a very limited impact but the more interesting and also more tricky side of this picture is the the burst limit so so bandwidth um and to kind of understand like what what the situation is and how 44 fits in we have to first remember that today on ethereum basically we only have a single gas price right whenever you send a transaction you don't actually specify how much bandwidth am I do I want to use how much compute how much memory you just spend said like one gas one gas limit and then also like how basically how how what kind of Base fee are you willing to pay for this right and it's all basically mapped down into what you think about it as like a single dimension for pricing and and that comes with um uh basically very real trade-offs in terms of a kind of resource efficiency so if you if you look at this kind of stylized picture of just looking at two different dimensions here they could be I don't know data and compute or data and memory or whatever right two different two different dimensions and basically the way the uh the the kind of the ethereum Gas Works today and that's purely for Simplicity right because it's very simple to for users to deal with one dimension basically but the way it works is basically that it is um basically that those two resources and compete for for for for for usage in a block right so you could imagine um if you use if a block is very full of compute then there's very little room for to to put any data in it or the other way around and actually if you if you want to like open ether scan for example they fight for every block for the detail page they actually give you the size of the block and usually it's something like 50 kilobytes 100 kilobytes but like rarely more than that but if you look at what would a block look like if it was was like just full of call data which is where all the data comes from if we were all the way like say on the lower part of the diagram if recess B was was Data it could actually be up to one or two megabyte like well two megabytes basically um of of size right so so what that means is we basically determined in the past that two megabytes per block are kind of safe um and uh and the reasons would be there right it basically sitting there but an average block basically almost like you completely underutilizes data and that is again just just because it is simpler for us conceptually to price these things so most of the time we are like very far up up the slope there and where do we want to be like what would be like the most efficient way of handling resources well that would basically be be this picture so ideally you'd want to basically make these things be independently used consumable where you can basically consume the most amount of like the most the highest save amount of data that we think you should be like the chain can manage but then at the same time you should also be able to you know do we still do state access to the biggest the highest amount possible or memory or whatever right there should not be this this kind of a competitive nature to it um and this is basically where four eight four four on the burst Limit side um gets gets it in efficiency right because full charting uh full-time charting we'll hear about it a bit more um after this actually that's really clever things where people only sample the data so bandwidth constraints goes quite down but for eight for four there is no fancy trick right everyone still downloads all the data so it's very real bandwidth strain so the Innovation and the burst Limit side is purely trying to get to this upper right point trying to actually basically make it so that the existing resource we already have today is just more efficiently utilized and the way we do this is by going from as we're saying like right now today um pricing is one dimensional and so what we introduced with point for voice basically we go to D um and this is how that how that looks like um so this is this is an open PR right now it's not yet quite much but um you can have a look so like small details might still change but I think the general direction is is pretty sad and so the idea is we introduce what we call data gas and as you can kind of figure from the name it's not blobcast status the aspiration would be that like maybe in the future we can we can expand this to cover the entire data Dimension but for now it's it's only used for blobs and we we set it in a way where basically like one byte of of plop will cost one data gas um and this data gets importantly basically is completely independently priced from normal gas so it has its own 5059 style mechanism where and that's that's where basically where they use and I see Mario is not very happy about this because you know like he has to implement it and get it in of the day but this is really important for the EAP because other than that basically you wouldn't be able to get to this more efficient bandwidth usage so um what does it look like and how does how can you think about it well it's just you know similar to how 5059 already looks so the way to the this is the courtesy of Proto I stole the site and so every column here would be a separate slot so the first slot and in this case basically the the the target amount of blobs would be two the maximum allow it would be 400 block so the first block first block comes in it has exactly two so nothing happens the next one has three right the red one it's basically one one two two many so the price would go up and then the next two kind of like are stable again and then then one moves as a blob so the price goes back down so it's like a very you know like just like 1559 like you you you know and love it basically um it is a bit different or like basically it's it's under the hood it works a bit differently so here's kind of a bit more more look at the details here so first of all of course just we have the max data gas per block right just similar to 259 and the Target that that is half of that um transactions these block transactions they specify an additional Max fee per gate per data gas field so like how much are they willing maximally per data guess and to to to have their transaction included importantly you know that this introduce a little bit extra complexity for users but users in this case are not actually users those are like big Roll-Ups right so basically them having to specify one more value you know fine that shouldn't like if you can't do that maybe you shouldn't be in the world game basically and and so uh we just to to keep the complexity this year minimum though we did not uh opt for having a separate tip for this Dimension so we just reused the the existing existing tip um and then we one thing that we where we deviate from 559 a little bit in 1559 basically if the demand were to completely crash theoretically like one gas could could be could be I think valued as little as seven way which is just the minimum after which basically updates don't don't go lower anymore so the transactions would basically be free we don't quite want basically to make the the lowest demand case of transactions here completely free so we said a minimum data gas price that's a that's kind of at least somewhat meaningful so that's like 10 to the minus five eighth per plop um so of course it's priced in late I guess but it comes down if you if you compute the for the cost of a full block the Bob to to the value and and the last thing and again this is very technical so like if if you just want to understand and conceptually this works don't don't care about this but but if you ever pull up the IP and you might stumble across this and you might be confused so so actually the way we we track this um in 1559 right now we we usually check the base fee directly and then we update it every every block and actually turned out after we introduced it like looking at it it's slightly conceptually ugly because we always do these these kind of so basically there's some some properties in the upgrade updating we don't quite love it's it's a little path dependent and these kind of things so um so we move to to just a conceptually simpler way of tracking for this Dimension where we track the excess excess data guess that has been basically been used over the existence of the EIP right so basically we just um we have some sort of Target that we want to be used and then every every block if it basically uses more than that we just add to this to this counter and then every block wave is basically use less than that but we're still above zero in this counter we just reduce the counter uh yeah sure if you wanna foreign just like the base fee yeah so yeah yeah so this is one additional header field uh which good question actually also um uh I you can you can see that because I just wanted to give you like an impression of of what the kind of calculating the the the the the um cost looks like with this header field so um as you can see basically we have these kind of functions um if you want to to get the the feed that in transaction actually has to pay it depends on on on on the head of the previous box similar to 1559 and so you first get the total data guys that the transaction consumes which is just you know data gas per block times the number of blobs and then you calculate the basically the base fee but we don't call it basically because again there's no tip so it's kind of unnecessary to have the base fee tip distinction so we just call it data gas price um and so how you basically for each block you once basically calculated its state I guess price and you do that by um by basically taking in uh there's this excess um data guys and then we use this fake exponential function it's a little nice little tidbit I don't know maybe it's irrelevant but it's it's something time to talk about briefly So like um just because we want we want some so maybe I can already go to the next step to explain so basically this is kind of how the pricing develops it's it's like 1559 right so basically if you were to continue to just keep keep basically using up all the data space in a block not just the target it would basically be on an exponential curve and would be more and more and more expensive and you can see basically uh like a thousand a thousand excess plops that that's roughly I don't know something like 10 minutes or so so within 10 minutes you'd really like they have like super expensive blobs if it were to to keep to keeping being fully used uh yeah various again because um so this the nice thing about this is that it's basically a pure function in um um in excess data guess right so it doesn't really matter if it was simulated at the beginning or at the end um there will probably be a different like in the beginning it will probably be relatively cheap to to use data guess because robots are still kind of adopted in the process of adopting it so there's not that much that much demand so basically probably for the first first month or so we'd be like in the very zoomed in left part of this picture and then later on once once it's all basically fully adopted and people use it we'll be like a bit more towards the right in this picture but it's not like this is not a basically because it's so reactive it's it's similar to 559 so basically every block in it most they're doing 12.5 update so the difference here like basically you can come you can go from one of these paradigms to the other within five minutes of of uh of high usage or low usage blocks so it's not like it's not basically something where it matters immensely what and what what was done in the in the past basically a lot High consumption in the past only means that like basically you have like five five minutes of of reduced pop usage before you're back to your normal price level so it's not Yeah so basically there's no significant kind of accumulation effect or anything right right sure no no but the thing is because so so the way to think about it is like because the the the price is a pure function of the excess data guys so at any excess excess data I guess I mean of course I put down excess plops just to think about it more easily but it's tracked in excess data I guess but once you reach something like say I don't know a thousand excess excess blobs that would mean that sending one block already costs 30 each and that doesn't matter whether the excess blobs were accumulated over one day or if they were accumulated over a year so basically once they access the data gas field reaches that value it would cost 30 years per block to send block so we would expect of course that if robs are not willing to pay that much for blobs right so if for some weird reason there was some spike in demand and the excess would shoot up to that level it would quickly come back down and stay at some some kind of permanent level so the excess is not something that will continue to grow over time it'll just similar to the base fee the basically doesn't grow over time it just Finds Its equilibrium value and of course sometimes goes up and sometimes goes down temporarily but it hovers around some sort of you know 10 to 100 gray level an ish and similarly it takes us blobs because that can can go back down right if a block uses less than a Target the number goes back down so it will just find some sort of equilibrium value that corresponds to to to um some sort of equilibrium price um and it'll just have around that um yeah I'll just keep for continued questions so anyway so basically this is how we how we make uh flight for four work history growth not a big deal bandwidth we really need to put in work to make this work and this is kind of where the core innovation of the Erp for Now lies other than that it's forwards compatible for full length sharding but for now this 2D fee Market is really why why we can do this and why we basically just utilize existing ethereum resources more efficiently and with that I think we are done with the kind of the fourth for four part of today and we can move to fall down shutting okay I want to introduce um now to the two-dimensional kcg scheme which we will need for full charting sorry this is a big jump okay so when we do foreshadowing um why do we not take all the data that we want to encode and put it into one big kcd commitment and the reason for that is that that is going to require a super node like some powerful node that you probably can't easily run at home unless you like have a very good intent connection and want to invest some money into it um so you will need this both to construct blocks where we're probably like kind of okay with that um but we will also need it to reconstruct the data in case there is a failure and this is an assumption that we want to avoid for validity So like um it's kind of um more acceptable if a failure leads to just not being able to contact blocks or maybe we have to make smaller blocks so we have to um make blocks without chartered data but it would be really bad if the absence of the super node could lead to the to a network split where some people think data is available and some people think it's not available this is what we want to avoid so what we want is a construction where yes like there will be a lot of data in the network and maybe like someone needs to be there specialized into Distributing that data but once they've done their job the very decentralized network of maybe your Raspberry Pi is at home can guarantee that it will always converge it will always be safe and so on okay um so what what if we um what if we just use um many many different uh kcg commitments just a list of kcg commitments um so if we do this naively we just take many commitments and we sample from each then we'll need a lot of samples because we before I had this number of samples for example say 30 samples now we need 30 samples per commitment okay that's that would be a lot of samples um but there's another much cooler way of doing this where we use read Solomon codes again and we ex will extend M commitments for like M actual payload blobs uh and extend them to 2m commitments so here's how this is going to work so we have our original data commitments um in this case um three commitments and what we'll do is we'll Define another four commitments that are an extension of these commitments um so they will be completely determined um by the actual data commitments uh and yeah so here here's the math of how this works so what we'll do is we'll Define a two-dimensional polynomial um for the data and it works the same way as before so basically we will interpolate this polynomial we will Define it by this data region the original data that if that comes from many different transactions that include Charlotte data and what we'll say is for Simplicity I'll just take the row K will just be the evaluation of this polynomial where we set y equals to the number of this row y equals k so we evaluate the row the polynomial at K and then we get a one-dimensional polynomial right so we get F K of x equals to this and like you can pull up all of this together and what you get is again an expression just in the these powers of x and then we can combine commit to those polynomials in our normal kdg way okay so we have FK of s equals to this now we replace the X by S and some complicated sum in there but overall we'll have like one elliptic curve element this black box evaluation and we call this C of K okay now the cool thing is if you look at this expression as a function of K then this is also polynomial right it's just a sum of terms uh of powers of K okay so this is very cool and what this means is that our commitments themselves um will be on a polynomial so if we see the commitments which are now elliptic curve points as a function of K they are on a polynomial so what we have is before we started with having each row being a polynomial that we commit to we also have that each row I mean this is a property of just a two-dimensional polynomial each column will be a polynomial but also the commitments themselves are a polynomial in this case of degree three yeah because they're determined by these four commitments um so what we have is will the how the 2D commitment scheme will work as we'll have two uh 2m uh row commitments and um we can actually verify that this is the cool thing like a any anyone who validates these commitments can easily verify um uh that uh that they are on this polynomial using a random evaluation trigger again which I introduced earlier so what do you what we'll do is we'll take the first M commitments divide them at a random point and we'll do the same for the second M commitments and if these two result in the same uh Point actually the point will be in this case an elliptic curve point then they are actually on a polynomial of degree n minus one for those who are interested there's a way to do something very similar um using uh 2D commitment so you can do one commitment to the whole thing but I won't go into the details here but um there are basically some downsides but which is why we're not choosing that way cool and so what what's what why are we doing this okay so we have properties that we already know we can verify all samples directly against commitments um there are no fraud proofs acquired um but now we need a constant number of samples for all these commitments in order to get probabilistic data availability um and basically we get the property that if at least 75 percent of those samples are available then all the data is available and it can be reconstructed and that's the cool thing from validators or other and also only observe rows and columns so there's nobody nobody in the system will ever need or will be necessary I'm sure they will exist but it's not necessary that anyone watches the full square of samples in order to get these convergence properties um so what you'll notice is that this number is a bit higher than before so like if we only have one commitment um then we only need 50 of the samples to be available for the square we need 75 um so the number of samples you need to get this will be a bit higher cool and so um what we get with this um is that um I made a proposal I mean this is all still in discussions but like one of the ideas how how we could uh extend this to a full trading construction is that um basically the way validators um uh useless construction is that they will download rows and columns they will each choose to run randomly um of each and then what we get is um that if a block is unavailable it can't get more than 1 16 of it attestations so automatically the consensus will never vote to unavailable blocks um um and um and at the same time they can use these full rows and columns that they don't load um to reconstruct any incomplete rows or columns so if any samples are missing they can reconstruct this and because there will be some interactions like for each validator there will be if they do too like there will be these four intersections and they can see the orthogonal rows and columns with the samples that may be missing and so like as an example um I made a computation that basically was about 55 000 online validators you get the guaranteed reconstruction where basically every sample will always be reconstructed if like we initially had enough data available to do this um and the state in practice this number will be much smaller because most nodes don't run one valid data but uh tens and some even handles and data availability sampling yes basically just uh checking um like random uh samples on a square and what we want is again we want to get um that the probability that um unavailable block passes is less than 2 to the minus 30 and if you do the math you find that you need about 75 random samples to do that and so the bandwidth to do that in this example if we do is 512 um byte samples would be 2.

5 kilobytes per second which is really nice low number cool okay handing it to Denny [Applause] okay so there's a lot of math and there's an elegant construction assuming uh that we can do a constant time amount of work if we're a large amount of data to kind of layer it into it as similar to like a validity condition on our on our block tree we don't consider invalid blocks in our block tree we don't consider unavailable blocks in our block tree and so the math and the construction are very elegant but when the rubbery hits the road um datability sampling on the networking layer is actually non-trivial problem that's the wrong way oh the arrow that goes right is so worn it doesn't look like an arrow anymore um okay so kind of stepping back why is this why are we making this problem hard for ourselves um everyone's seen this these things are it's not fundamental that they um cannot come together scalability security and decentralization all in one system but it is hard um and it's hard primarily because we want home nodes to be able to run we want standard computers to be able to validate the system uh to kind of have uh security and aggregate even against a malicious majority of our consensus participants again kind of in that validity condition of if there's an invalid block and all the validators or miners are saying that's a that's that what is that's what the head is you say well that's not even literally real because it is invalid um and so users in power uh kind of Define what the network is similarly we want to do that with um our bandwidth consideration with respect to um data availability so thus we need to focus on the bandwidth here um a lot of this is a quick recap we've been talking about this all day but we need to scale execution we need to scale data availability essentially Roll-Ups give us some sort of like compression algorithm for the execution of transactions whether it be from fraud proofs or validity proofs data availability we use DS datability sampling or we want to um data availability we've been talking about all day means no network adjustment including excluding super majority of full nodes has the ability to withhold data again this this it kind of makes data availability of validity condition um it is already today as we noted you have to download full blocks but once it's a lot of data and we want those home nodes it becomes very hard um right so again we want the amount of work to not really scale as those blocks become very large to scale the network so data availability Insurance the data is not withheld also Assurance of data was published real quick shout out dockerd made most these slides of another talk and I'm just reusing them um important to note it's not data storage it's not continued availability there's a debate as to how long the network needs to have the data available so that people can check that it was made available some people say on the order of where are we at like 100 seconds some people say two weeks um you know it kind of depends on the use case and and it's a bit of a more of a ux debate it's kind of the online in this requirement of people to be able to get this security guarantee without trusting you know someone else so um is it important I don't think we need to get into this too much optimistic Roll-Ups and ZK Roll-Ups it's critically important and you know who knows the utility of uh solving this problem might extend beyond these two types of systems so networking the networking is hard and we probably are making it even harder on ourselves by some of our assumptions here so we could say okay we want we certainly want to make sure that block producer and consensus nodes we want to be able to um not be fooled by a malicious majority um but maybe we have a neutral PDP Network and we can just assume that the P2P network is like healthy and gives us what we want this is certainly attractive it ensures that each node really can see that they get the statistical security but if we're assuming that the validators can be malicious it's very high amount of them at least you know maybe about two-thirds some people like to say 99 depends on probably the construction on what the real one is um then the Assumption then that the network network is neutral is probably not a realistic assumption so well maybe it's realistic in most scenarios but if we want to really be able to harden against that majority adversary we need to be thinking about um an attacker controlled P2P Network by some threshold defining whatever that is um again this is a lot of um kind of exposition of the problem rather than total Solutions of the problem so you know if I'm thinking about designing data availability sampling um I'm probably it's probably interesting to think about what's a good neutral Network solution but then I think when the rubber meets the road we need to think about what thresholds uh can we actually Harden against a very attacker-controlled PDP Network um so in this model certainly some nodes can be fooled and so it ends up being a collective guarantee again depending on the thresholds and how the system is tuned but rather than no node can be fooled it's probably going to end up looking like no above certain threshold of node can be fooled maybe for a certain period of time maybe until the network kind of resolves itself um but so this is likely correct model but it does make that problem harder so the B2B problem what are we trying to do here we want this like P2P distributed data structure that can reliably served samples so that people can do their job of getting the samples we won low overhead on nodes from multiple perspectives one on nodes that are participating in pulling down samples but also potentially we want to leverage nodes that are not just validators not just builders in this distributed P2P structure so we want to also consider the the overhead of these nodes that are participating in the serving of the samples as well or in the dissemination of the samples other things I want to be robust against attacks I think one of the really really scary things here is liveness attacks um doses civil attacks Etc that happen on the network layer because if a majority of nodes are seeing data as unavailable either temporarily or permanently then they cannot follow the chain at all again we want this to be essentially a validity condition you know if there's an invalid transaction in this Branch I don't follow the branch if that branch is unavailable I don't follow the branch so that is a very important critical requirement but a very terrifying requirement meaning that like it is very important that this these PDP structures um are hardened and do we do understand kind of their failure modes we understand where they where they operate and if you don't understand how they um resolve maybe after an attack um and low latency on the order of seconds I have a um page of some deciderado I'm going to get into in a second um and there's some distinct challenges I think when you're kind of thinking about this problem dissemination into the P2P structure we have a lot of data how do you efficiently get it into this P2P structure without causing High load on the on the individual nodes of the P2P structures you know if every node only needs you know 1 100th of the data but they had to touch 50 of the data to get it disseminating the structure it's we're kind of missing something there um similarly we want to support queries with disseminated data sample for x amount of time which I can get into this centerata again um and validators certainly with their row and column kind of crypto economic Duty can identify and reconstruct missing data but we also probably want to consider should this PDP structure be able to identify and reconstruct missing data so there's two kinds of um potential reconstruction that we might want so validators are very incentivized out the gate you know if things are missing from the rows and columns to incentivize to to repair patch and make make things whole but if say the P2P structure is supposed to serve data availability sampling for one week then um are those validators the same people that will then identify and reconstruct missing data or is there some other more distributed and less timely required method to do so there's a handful of actors involved in data availability sampling Francesca is going to talk about Builders and where they fit into kind of the consensus protocol but they're kind of the original source of the data they're highly incentivized to get it out but they're probably not one that you'd want to rely on uh in perpetuity validators highly these are you know crypto economically incentivized actors that we can try to leverage in this construction they do have the rows and columns they do also perform data availability sampling like a user node and then we have users users perform data availability sampling hopefully they can be leveraged in serving and making the whole P2P also more resilient itself some quick deciderata right now um you know if I were thinking about building datability sampling if I'm researching and doing stuff I'm these are kind of some Target numbers but I would also be sweeping these numbers and understanding where they uh where they work and where they don't so data size 32 megabytes per block that's per 12 seconds um or if the slot time were adjusted it might be per some other amount of seconds call it 16 or 20. but with the 2D Erasure coding that ends up being 128 megabytes of data being inseminated into the network chunks I think we there's chunks and we sample the chunks or their samples and we sample the samples um but on the order of 250 000 you can make these larger but then you end up with you still need the same constant number of samples so you end up with more overhead samples he said 75 something on that order but essentially we want to drive that probability down um as we're doing the sampling latency validators really right now need to make decisions about what they see is the valid and available head on the order of four seconds that could be tuned depending on the construction available to us but they if they could not regularly be able to do data availability sampling um then on the order of four seconds we have a problem users you could have a potentially lack more LAX requirement on the order of 12 seconds on the order of a slot um or you could even consider maybe they needed to be doing it on the order of epochs and optimistically following the head as available and maybe there's some play in in the constructions there validator nodes 100K is pretty optimistic but uh we probably open the order of four thousand today so something on that order is kind of the the the Baseline and then user nodes on the order of 10 years especially we start adding light lighter weight nodes with statelessness and like clients that might want to participate in this datability sampling um you know 100K to a million user notes you know so it's really if the user nodes cannot participate in the serving of samples then the load on if we only relied on say incentivize actors like validators then the load would actually scale as the the to serve as the user nodes serves so it's probably very important um to tie them into the data structure itself bandwidth assumption I don't know it's probably worth discussing the eth.org website suggests a minimum of 10 megabytes per second to run a full node uh but but for good whatever 25 megabytes per second I don't know who came with that number maybe it's a good place to start the conversation and then persistence obviously like I said datability sampling is not for persistence it's to ensure that data was made available where how but you know data if data was made available for half a second like No One's Gonna necessarily be able to prove that to themselves that it was made available or a very small subset so is it two epochs is it two weeks um there's much debate here onsgar I think what was your recent number is he still here okay okay 10 minutes an hour whereas I think some are more like a week two weeks um and those that actually changes the requirements on nodes especially in terms of storage um my intuition here is that the online in this requirement for users that want to get their you know State transition changes from ZK Roll-Ups or policemen users that want to submit fraud proofs for ZK for optimistic Roll-Ups you know this dictates their online in this requirement and so I'm I feel like 10 min oh man I gotta get out of here um Okay cool so debate an hour seems short um P2P designs so uh one easy thing you could do is just say there's a bunch of super nodes in the network and if you connect to them you do the dis and if they give you the samples that you want then things are available um this is I believe Celestia's current design although that statement I could claim is true a few months ago I'm not sure today and you could potentially do something in similar ethereum whereas maybe instead of a uh each node meaning you have everything you could leverage uh ethereum validators uh the rows and columns that they custodied and it looks kind of similar um this is is nice um you know if you connect to one on a supernode uh then you get what you need um but this doesn't really fit well into the node model especially if validators you know a node that's running on the order one two maybe three validators should be able to run on the order of you know home resources which is definitely not the case foreign [Music] nice way to distribute data and attribute to data structure across the network it's a nice way to find data um and seems intuitively like a very good direction a very good start it fits really well in because each of these nodes can have very small amount of data and really nice scalability as you add more nodes to network you can depending on your redundancy Factor you can have um you know similar or less data per node uh prone to lightness attacks it's really easy to assemble this thing uh and naively uh you just make note IDs you fill the tables and if you're a malicious node you can just return uh entries from your table that are full of malicious nodes and one thing that's I think very promising is looking at secured dhgs docker's been digging to escadimlia and I believe there may be some others in this room that have looked at some other papers about hardened dhcs and we do have you know we as long as you have a simple resistance set then you all of a sudden can have certain guarantees in these constructions so you can Leverage The validator set or maybe other types of crypto economic sets uh to have hardened dhts um so you could use standard open DHD for average case performance and maybe a secondary or fallback DHT um leveraging the validator set for uh in case of attack you could also yeah there's some weirdness because then all of a sudden you're assuming that you have a certain amount of honest validators for this um so does that sufficient suffice under the malicious majority construction sure you can probably tune the numbers but you could also potentially layer other types of crypto economic sets um you know proof of humanity uh Spruce ID whatever the hell all sorts of stuff and could have layered dhts where they're ultimately just kind of fallbacks in the event that the the big main DHT starts failing um validator privacy and optionality and how they construct their node setups is probably very important I'm definitely over time okay cool great hi I'm Francesco and I'll cover the last bit of this very large topic that we've kind of gone over today it's proposed a bullish operation expect probably most people will be somewhat familiar with the concept but this will be kind of a light um introduction like it's not going to be um yeah it's not going to be too advanced it's going to be just for you to get a picture of how does it fit with dunk sharding and what does it have to do with it uh in general and also like uh kind of how does the road map of that fitting in the protocol look like um yeah so first of all what is PBS um it's oh sorry yeah so there's a let's start from the pieces uh we have DB and um NS so first of all uh block building the B uh is essentially this task of actually creating and distributing uh execution payloads mainly so we have Beacon blocks but then inside them there is execution payload which is the kind of the valuable part in some sense the part that actually changes the state uh in uh of the execution layer and this is the part that is kind of uh requires some specialization to deal with whereas the the beacon block part is more of a consensus part um and yeah so this is um the normally today we only think about the creating part like only basically putting together a new execution payload but uh the distribution part will also become critical uh especially in the well in the context of dunk charting um and yeah and also uh this uh distribute so the distribution will involve the data that is committed to uh which is going to be eventually very large so that's why it's it's kind of an important task eventually and so for these reasons and well later it will get a bit more into them it's a quite specialized activity that we don't really want normal validators to do because it would kind of increase their requirements too much for our for us to be comfortable with um and then there's proposing so this is just um you could think of today proposing includes both things both this kind of consensus part of making a beacon block and including all the consensus messages in it attestations and other things like slashing messages or anything that's kind of critical to the good function of the beacon chain um but then also the put in an execution payload in it so today it's still possible for anyone to do this by themselves and kind of have both the roles together but if we kind of ignore this execution payload part this is really not a particularly specialized role and we think that it's always going to be possible to or we really want this to always be possible with low requirements uh basically what we expect today validator to have um and yeah the separation is just that these two things are split up like we don't um the default it would not be any more that uh a validator does both things or the proposer which is a validator does both things but that uh the proposer does the beacon block relevant part the consensus messages uh part and uh some other kind of specialized actor comes in with the execution payload and the distribution of the data eventually um and yeah so why do you want to do this I've kind of already well hinted at it but yeah it's it's simply that if we Outsource the specialized stuff we can keep the simple stuff um basically decentralized we can keep the really consensus critical things um essentially done by a very decentralized validator set um which is a really important goal in ethereum in general so and I mean practically why you know what are these things that we want to Outsource um so that we've for all the whole day we've been talking about dunk sharding and um it's not there's nothing really I guess fundamental about starting that requires um this Outsourcing you could imagine other models I mean the I guess original starting model before the Dank part uh didn't require this Outsourcing um but it's really like a major simplification and um so I mean not just simplification also as I think like consequences for latency like um it just makes the it gives us this really tight coupling between uh the execution uh payload the blobs and kind of um yeah just reminds the whole process um and so we in we're done charting if we do want these simplifications we kind of have to uh we start having something to Outsource because the proposer has to compute these commitments really quickly which is uh not easy to do for uh like normal hardware and also like probably the most prohibitive part is the uh basically distribution of the data to the network so that would require like really uh kind of uh not uh acceptable uh Upstream requirements for for validators like more than uh you know probably multiple gigabits um you know and so yeah we don't want we don't want to require this it's like or there's a magnitude more than what uh someone would need today um because basically the most you might need to distribute is 128 gigabytes per block and yeah but again this is not a kind of fundamental reason if there was no other reason that we needed the separation for we might be a bit more skeptical about dunkshardi we might think well you know we don't need these other actors why are we introducing the system just to get the simplification that's not kind of the ethos of ethereum like we really want everything to be as decentralized as possible as like resilient as possible these actors probably you know do introduce some complexities in this Vision but the issue is down charting isn't the reason why we uh these actors the reason is med um and this is kind of fundamental reason there's I don't think anyone that has looked into me uh enough thinks that there there's any other uh way essentially to go um and the issues simply that as I said these execution payloads are really valuable and uh extracting value from them is a really sophisticated activity from many points of view algorithmic uh infrastructure like requires uh potentially very good Hardware a very a very good connection like latency is really important so there's like all kinds of reasons oh and also like uh access toward their flow so um you know today we can think that order flow is more or less so you know essentially access to mempool transactions is more or less available um to everyone publicly but that's it seems very naive to assume that that's going to be the case in the future and already it's not quite true that that's the case so maybe they're always going to be a public mempool for sensorship resistance reasons for I mean other reasons but it's really naive to think that everyone is gonna have access to the same kind of raw material to build blocks like the transactions and uh this access order flow is is a huge part of being able to create valuable payloads so there's like all kinds of reasons why it's just not realistic to think that validators will be able to uh profitably make their own blocks and so there's this really like strong centralization pressures if we essentially don't provide them a way to do it you just go and you know have someone else to do it well which is the whole point of Separation but there's different ways in which it could happen some ways in which it could happen are for example just everyone's taking with pools because that that's the only way that they can extract value um although that's actually kind of not already it seems like a scenario that in some sense maybe we can avoid uh we already have a PBS today like we usually say PBS and we mean um basically empirical PPS so where the protocol kind of knows about the separation like has a concept of a builder and in some sense like negotiates this um Outsourcing uh but today we basically have PBS is just not in protocol it's called a map boost uh maybe probably a lot of you know it um and essentially what it does is it introduces a trusted third party in between a builder and proposer which are these three layers um I don't think I have time to like go into the details of it but essentially you know we don't we want Builders to not trust proposers we want proposers to not trust Builders there's reasons for that um and yeah we just basically put like a trust to the third party in the middle which kind of negotiates the uh The Exchange um so you know the proposal wants something they're built from the Builder the Builder wants to get something to the proposer the third party makes sure that the exchange happens you know we where none of the two parties can cheat each other essentially and so this already exists today a lot of ethereum blocks are built in this way um so it's it's the reality that and it's not something that you know um the ethereum community um kind of made well it is something that deterior Community made happen but it's in some sense inevitable like anyone could always build some infrastructure of this kind and people could use it if it's more profitable for them um so yeah so you know we already have this why do we care about potentially putting uh this separation protocol um so as I said relays that trusted third parties we don't usually like to have these sort of entities in the protocol they're not critical in some sense well if things are set up properly um which I mean I think there's a lot of improvements to be done on the infrastructure that exists today it's very um you know young infrastructure um but either way there's always going to be some um kind of failure modes that we don't really like or some some requirements that we don't really like from having these these parties so one is that you have to basically white list them because they're trusted so everyone has to kind of go and configure some list of these entities that they they're fine with essentially the trust um and we don't care if Builders do that but we don't really like validators to do that um or well I don't know that's debatable but anyway um there's I think there's a future for relays to still exist and just have a full fallback in protocol that is not the default but that's a conversation from our time um but yeah another thing is that today we don't really have a kind of live monitoring for relays uh like locally people don't have a chance to uh observe interactions that really have had with other proposers and then disconnect from them if these interactions look suspicious essentially so that's something that we can include we can basically really improve the um you know the the resilience of this whole system because we can make it so that people don't need to you know go on Twitter and find out oh this relay is malicious and I'm going to disconnect from them but just maybe this can happen locally essentially so there's a lot of improvement there but still there's some kind of um I guess really fundamental uh catastrophic scenario that seems unavoidable to me if we keep having uh or rather if we only rely on these entities for this Outsourcing if we have kind of no fallback so especially we're done charting so today you can always have a fallback actually it's not so fundamental to this this state of things today you could always have this fallback which is uh essentially the characteristic scenario is like all relays that uh most people are connected to fail for some whatever reason they're malicious or they're attacked Anything Could Happen um they fail and now all of a sudden today it's fine you could you know once you manage to disconnect because you realize okay these people haven't given me blocks for you know however many times I've tried or if you have this monitoring system um that's fine you just fall back to you you building your own you know gather or whatever like other execution clients you're running building your own blogs so now we're likeness is not really threatened maybe it's like a temporary thing um but with dunk sharding and also statelessness in some sense uh if you know let's say all the validators are still list they cannot build their own blocks um or within charting like they cannot distribute data um then this becomes like a threat to know our liveness uh we dangsha did not exactly it's like you could make blocks you just cannot put a lot of data into them but you could argue well is that really liveness like if all the roll ups can stop because they don't have access to data anymore that is not really what we want um yeah so this is maybe what it would well this is like the one of the current ideas of what it could look like to put it in protocol um I think well yeah I think it probably can't really go into it uh I don't think we have time to go into it in much detail but basically it looks like you know as I said before what are the relays they're just these kind of actors that negotiate the The Exchange um you know what do we do we want to remove these actors we basically have the protocol negotiate exchange and the protocol in this case is basically other validators so there's a proposer there's a builder and we have the whole rest of the validator set or some committee um more well likely um that basically kind of makes sure with their well they observe the exchange and with their attestations they sort of make sure that if the proposal tries to shoot the Builder um they they fail and vice versa essentially so it essentially gives us the property for example that if the proposer accepts some block and or some some like a bid you could say from from a builder and we have good latency like things are fine from a fortress perspective from a network perspective then the proposal will get paid it doesn't matter what the Builder does if they reveal their block a good kind of this is a good case if they don't reveal their block they're really late you know tough luck for them they're going to repeat the validator and not even get their uh building opportunity and so this is one design there's this other design which is kind of interesting oh yeah also uh thanks to vitalik for all of the things that just took him from many of his uh research posts um but yeah like so this is basically you could say empirical map boost because it's really like um designed to look like map boost again we have basically this like party in the middle this time more clearly than before um which is in this case a committee it also was before but anyway and in this kind of um party again negotiates negotiates The Exchange we could think of the party as basically uh an availability Oracle so it's um basically its job is to ensure it's to give guarantees to the proposer that what the Builder sent is available so the proposal will accept um a header like a basically offer of you know I want to give you this blog pay you this much and the Builder will uh essentially erase your code so you know hopefully if you follow the discussion you know whether it is recruiting is by now um the um essentially the execution payload to the committee um like essentially encrypt well Azure code then encrypt and then basically split the parts to the committee so that if some threshold of the committee is honest and online uh they will be able to decrypt even if not all of the committee is um and basically the committee uh signs you know essentially the individual members of the committee will attest to the fact that they have their part so that if you see enough attestations and the committee is officially honest then you know that as a proposer that this thing will be able to be decrypted and uh you know the data will be there essentially um so it actually yeah this kind of fits in quite nicely with these data availability discussions like that is really the problem here that um the purpose is accepting a bit but the Builder doesn't want to say what the bid is because that's the are kind of private like secret information and we want basically some guarantee that even if you don't know what it is it is going to be there once the time comes essentially um like once you've accepted the bid and it's ready to go in the chain um so that's yeah that's what it looks like looks like um and uh just last quickly I want to comment on um basically well so there's like sensory resistance questions about PBS um and I think they're not you know they're like fairly well understood there's a there's clearly like a way that PBS in or out of protocol says it doesn't really depend this is like you know our questions also today um it does the great censorship resistance um but that we already know kind of how to deal with that there's this kind of inclusion list there's like slight tweaks of that there's I mean there's like basically really wide design space of very like roughly said ways for validators or proposers but you could just say validators to basically uh make sure that transaction that should go in the chain eventually get in the chain even if Builders don't want that and this also by the way like a really important reason why we want decentralization of the validator set because if you don't have that then you just don't have this option like if you have 100 validators and they don't want some video on the Chain that's it there's no way well I mean there's ways like soft working or you know other reasons other ways but there's no kind of automatic way to to do that whereas with a decentralized by leadership we can always do that um and yeah so inclusion lists are quite simple in some sense and there's like disagreements about how exactly they should work but they're super simple today so if we have like the property that it is easy for a validator to say this transaction is uh available and this transaction is valid um so the validity part becomes a bit harder with account abstraction so there's some questions there but won't go into that that's not really relevant here uh the availability part that becomes a bit harder with down charting because now all of a sudden you know there's all this like all these blobs floating around the network there's all this data that you're not supposed to uh no you're not supposed to essentially download all of um you're only supposed to sample what actually ends up uh um okay yeah well I've just finished this phrase and then I guess that's it uh but yeah basically um with uh yeah so we're done charting the terminal availability becomes a bit harder so we would like to have uh some kind of Chardon mempool construction so that you can even for things that have not been included in a block yet you can still in some way determine that they're available uh without everyone having to download everything essentially um and at the point at this point uh and this might not need to be the default route that all transaction goes through and probably won't um for kind of some of the reasons that I've already hinted at before like it's it's unreasonable to expect that everything will go through a public mempool but this is kind of the fallback for censorship resistance always and so we want to basically have some kind of construction like this um and I think that's it we're out of time hopefully maybe we still have time for some questions for everyone um but otherwise that's it okay so yeah obviously out of time but uh we can still use this room for another 20 minutes we have a special guest here of italics here to answer some questions around of it ah okay any questions okay there's a question everyone hello thank you how do you approach them the topic of multi-rely in this time sharing black ecosystem because there are many solutions and because I heard in PBS but that it weakens them the topic of censorship but how do you how do you approach then to improve the mempool with um multiple multiple relays so relays are a concept that exists in like Mev boost kind of out of protocol PBS right like it's not a concept that exists in in protocol PBS so the one right so the long-term solution is to effect to not need to rely on them hi the Erasure coding in show me a secret sharing scheme seemed very related because they are they're the exact same math okay is is Network persistent uh for the blob is going to be dependent on finality because I would have expected this to be the case and therefore rule out completely these Notions of having them for only five minutes what do you mean by dependent on finality like that if we're not finalizing then we need to keep the plots for longer no well oh I see it well so like if you're in the middle of an inactivity League that probably makes sense I mean I think like I personally favor blobs being around for long enough like you know among like at least a month or so so that uh you know any like it's longer than any realistic inactivity leak that would happen but there's different approaches okay uh just on the setup was there like a consideration or is it even possible or what's the problem with actually making that like a separate system it reminds me a bit to like swarm as it was integrated into ethereum notes like wouldn't it be possible with pre-compiles and like the right new evmob codes actually make that an independent system or so the problem the reason why we need like data availability sampling in consensus and why it's like so different from you know ipfs and everything out there is because we want to have like actually have consensus on the fact that the data is available right like the yeah like ipfs does not provide that right and there's ways to like upload files so that some people think it's available and other people think it's not available and for like regular file publishing that's fine because if it's ha if a file is half available you just publish it again but for Roll-Ups like it you need like exact like Global agreements on which data was published um on time in which data was not published on time because the roll-ups like in order to figure out the current state of our rollup you need to figure out like which uh data blobs to include and which ones to skip over yes and tightly coupled with the chain okay next question hi for the sort of data uh blob storing period are there any thoughts about like challenges for valid leaders that kind of keep that data or is that purely altruistic Behavior I mean there have been proof of class study designs that we've worked on over the years I think it's kind of it's on the sort of rhetorical back burner because we just like know that these techniques exist and like we know that when the time comes you know we can probably just stick them in to get extra security um yeah so I wanted to ask about the multi-dimensional fee Market quickly um we talked about this excess data gas field I was just wondering if uh the same would like in an Ideal World if we hadn't already done eip1559 with the same construction uh be wanted for the like original kind of gas yes yeah and but this can happen simply just could this happen yeah feeling 559 could be upgraded to that over time okay cool so I think they even already thoughts in their directions I think over long over the medium term we would want to and one of the nice side benefits it would give us that it also makes other improvements to to 5059 like mechanism easier like for example like a Time based instead of a block-based um kind of throughput targeting so yeah we would probably want to homogenize this over time yep so um I could be wrong in one of these assumptions but my understanding is that proposer Builder separation was motivated largely by the um centralizing effects of Mev and US wanting to keep the proposer set decentralized um but then kind of later with these designs like full sharding we realized that we could utilize the builders as kind of um with extra Hardware requirements because they'd be incentivized with the Mev that they're extracting to have these nodes but then there's also Research into completely mitigating Mev uh okay so maybe that's the wrong example okay there's multiple strands of research and some of them are definitely sort of covering for each other in case the other fails but and some of them are complementary right so there's a PBS which allows proposers and validators to be more decentralized but at the cost of kind of Shifting that centralization to builders there's a separate strand of research on the topic of trying to make build like Builders themselves a decentralized internally um so like a some kind of protocol would plug into the market and make bids instead of being a single actor and then there was also research on making applications that are Mev minimized so like all three of those exist okay I guess the question is just simply like if we mitigate or very minimize Med then goes away it just means we do as much as possible to reduce it but there's no actually again like I think anyone that's thought about maybe for some time will come to the conclusion that it's just not possible to assume that there's not going to be an incentive to be a specialized actor like there's even if all transactions are encrypted there's always going to be some reason to be the first to to touch uh this state like you know so the idea is they'll still be incentivized to run these nodes yes there's always going to be I think a lot of money to be made by uh controlling a block I don't think that if ethereum is a platform with value flowing essentially right and just to mention it's not just tank sharding where basically a PBS like architecture would help so once we move with worker trees to some through a world where it's uh easier to run stateless nodes and then also with what PBS would get us would be that like that normal validators would basically all of a sudden have like way way and lower um a storage requirements and we only we don't don't get that if they still have to create blocks because then they need the state but if you only actually validate but you don't create your own box you you get you you leave that to to a specialized entity then you can um as a validator turn stateless and that's kind of the one more of these benefits we would get out of this wouldn't it make sense to like uh charge for sampling or something like that to like motivate people to have the data and be able to collect the charges I mean I think that's definitely a possible construction you could like uh see a way like where you oops a specialized sample provider and you pay them um I think like the downside is that it makes it much harder to run a note because now you need to somehow set up this payment infrastructure so um I think it's not ideal but it's possible and next hello will there be ways to um foreign for somebody who wants to make data available to provide a proof through a smart contract as well uh which is independent of this call data layer twos and so on which is a smart contract specific like it's a generic infrastructure for proving that the data was available I mean that's that's what this construction does okay like this is part of like you there will be a type of transaction that uh is called with the kgt commitment and with the guarantee that this data is available and then also being um does there need to be like a special opportunity to to run the proof then to will uh to check that it was actually provided because the data was like if you get that commitment it was provided yes full stop but if there's no extra check necessary yeah that it was provided but then if uh let's say somebody wants to have a check inside solidity if the data was available but it's a parameter it's just like you get this commitment and you know it's there it's like extra data that the data is available behind a commitment you use a history of proof to prove the document with any transactions okay legal questions so one way to understand the data available exemplary Network can we fix it basically interpret it as kind of like a dedicated ipfs but with the samples that Distributing the network and the validator sample its and but definitely ipfs has ipfs is a very bad way to think about it because what we're doing is not storage it's proof that data was not withheld um yes but I just like um kind of like for the network perspective like um yeah and I know ipfs is one of those two simple attack yeah that's something that is going to adjust I mean I think yeah from from the kind of network perspective of how the thing should be yeah implemented like this thing has much higher requirements in terms of Byzantine and fault tolerance and in terms of real-time access and like real-time real-time being able to change what you're accessing yeah those are probably the biggest differences in requirements okay great next question there like if you don't mind uh have you enjoyed your stay in Colombia so far sorry no no I I have it's uh it's been very fun thank you thank you um something I was thinking about is that if so we um we assume that nav exists and that people want to um you know sandwich other people's transactions and stuff like this so we we have this proposed to build a separation which makes a lot of sense and then we once we have this we kind of start to utilize it to do heavier work like thanks sharding and things like this one of the things I'd be concerned about is that um presently we have the ability for users to just simply not run Mev and they just let the transactions come in as they will and they you know lose a bit of money but they're kind of genuine people I'd just be interested to make sure that um we don't rule out this person and we don't kind of glue together the role of like making really specialized fancy um sandwiching blocks and then also doing all of the tank shouting stuff I think it'd be nice if we can make sure that we keep a space for the home home user to continue to pack their own transactions and just be like you know a nice guy okay yeah yeah I know well no this is um actually one of those things that I yeah I think I wrote a new research post about last week right like basically yeah like can we uh push the autonomy in choosing a block contents uh back to the proposer and like that's a spectrum that potentially could go all the way up to the purpose of having an option to make everything and then one of the conclusions there was that if we want to have that kind of proposal autonomy property but also have the uh the property of like potential low proposal requirements we might need to have a third category of actor that does are kind of not and not MVP extraction that in basically the entire bundle of computationally expensive stuff so like uh witness Edition State Route calculation in the future ZK snarking and uh minimum um like figuring out polynomial commitments and proofs and broadcasting and so forth I mean I I just want to comment I think like people need to stop thinking of Mev only as a bad thing because you think of sandwiching and even without any front running any sandwiching we still have lots of Mev and it's actually a necessary part of the system like someone needs to do the Arbitrage on the exchanges someone needs to do the degradation someone need to submit the fraud proofs all of these are Maybe so don't think like this is a we're incentivizing a bad thing here so it's it's a part of the systems we're building and but I mean you so if we I would say for example you can eliminate um the bad Mev using transaction encryption for example but you'll still have loads of mab left like yeah um sorry I've I've thrown I was going to say I think uh well but basically I think we're relying on ethical Builders I think there's like all kinds of techniques that were layering on top to one or that Builders have to do like they get really nasty things a question on the PBS so uh here uh so we we like sort of apply some slashing mechanism once we have a separation between the builders and the proposers right sort of um different actions they probably have yeah so there are slashing mechanisms different slashing mechanisms that play right so like there's a swatching mechanism that slashes the proposer if they make two conflicting blocks in some of these partial block auction protocols and we use eigen layer and that's like basically exposes the proposal to kind of extra swatching if they yeah so if they violate the rules of the partial block auction protocol uh Builders can get slashed in some like some contacts and forget exactly yeah which ones but there's a definitely a few cases um so you know there's definitely like different uh forms of uh of swatching to make sure different the the different participants follow the rules of the protocol yeah thank you