Scaling rollups with Eigen DA - Mariano Cortesi

said I'm Mariano I'm the head of engineering of cabs and I'm going to be talking today about like how you uh can scale rollups using igda um so first things first guess something about me I'm from Argentina uh I'm not really part of igen or a DA so I'm not going to be speaking here uh from like okay it's my company I'm going to try to Shield it actually I'm more of a customer uh I'm part of I'm part of cell um cell it's a L1 uh chain it's a chain that it's basically in its own journey to become an L2 uh it's basically an evm chain uh that I guess one of the most interesting properties to me is that uh we kind of modify we introduce uh new types of uh transactions so you can actually pay gas using um R c20s so for example you can use some page gas using tar usdc or uh sell Mentos families of um uh stable con which is like um CD Euro or even like um local curses in different countries uh as I said one big thing that basically is relevant for solo today is like we are in our journey to become an AER to uh we started talking this around a year ago um it's been quite a journey because we wanted to basically assess all the different technology that was available AEL and see uh what was the best um stock options uh for that for for that for us and and that's why I think I can really go and speak about you like different option different traits um and how you make that decision no um just recently we introduced our first test net uh for the2 it's called Dango um something interesting um it's like I guess it's not that easy to it's not like we are launching a new chain we are migrating an existing chain so imagine from the user perspective the user won't really notice it's like one day they be connecting to nodes that are running an L1 and next day will be an L2 and for them it will be exactly the same so same state same everything and so doing that particular migration is actually particularly tricky and that's part of what we need to do and Dango is our first experiment of doing that actually uh later this year like later on September we'll be migrating actually our first uh test net that it's live that's a testet has like many years of um of history and we expect I have some people here that probably are not going to agree too much with me but we expect that maybe sometime next end of the year we'll be able to um get to Main okay so that's enough about cell uh let me talk about igen in particular I'm going to be talking about igen and op uh so you know optimism optimism has its own uh stack it's called op stack and that's actually what we're using we're using op stack and we're using NDA and I'm going to try to talk you about how you can use those two and how they work together so first first things um what is IG da so first thing is like you need to understand what is igen no I know how many of you know igen layer uh but I layer it's a it's a raking solution so the idea here is that um you can use the um the stake at eth for um etherum uh proof of stake to run other services now you know that most of these Services have this idea of Economic Security that um some nodes are doing some job and if they fail or do something uh bad you they get slash no and so the idea is like by reusing the steak by reusing all that uh e that it's steak uh for ethereum they can start running other service and they get they can get slash for running those service in a in a in a bad way no one of those service is egda so igda is guess they call this service a s uh and IG da it's actually also igen solution for data availability no and why do we care no why do we care about data availability um I don't know how many of you work on infrastructure but or um you've seen that uh we have rollups rollups used to be I guess cheaper but not as cheap as they could and one of the main blockers was the data like the data requirements uh a rollup basically uh takes execution outside of ethereum but the data still goes to ethereum and that's why ethereum was becoming this huge bottleneck uh ethereum has own plans to solve this problem no so you care about produ sharding which is already live and you probably hear about D sharding which is something that's going to come later and the whole idea is etherum is becoming this kind of huge settlement layer or data availability layer where all these rollups or layer shs are going to send their data um now that's maybe interesting future but we don't know when or how it's going to arrive or if it will arrive and it will actually be able to uh cope with all the demand for space so having offchain data availability Solutions is actually an interesting idea and for that you can mention Celestia for example that you probably also know and I da would be another one now uh I'm going to do a step back and try to explain so we have a a common framework how does a roll app work um so how does it work no so uh we have ethereum no you have like blocks on ethereum um you have the sequencer uh you have a sequencer you have a validator these are like roll up um um Pro rollup rols know that are like basically have a job within running a rollup no and you have the layer two these are like the blocks of l two so what's going to happen is like you going have this this person the sequencer that is going to start creating blocks no it's going to go Define okay I'm going to get these transactions I'm going to put them into a block and I'm going to say okay this is a new block no now uh it's not only going to do that it's going to get the data for those transactions is going to send those to ethereum no that thing called the RTX data uh why do you need to do that uh the whole idea is like I guess with with chains in general you know that uh whenever you are I know any know of a change and you want to sync and you want to learn what's the canonical chain uh you need to go and get all the blocks and how do you know it's canonical in proof of take because it's sign in a rollup it's because it's there no and it's there sign by the sequence and has some kind of maybe other other authentication properties so full noes will go and basically read the TX data from there and that's how they will be able to sync to your url app now there's uh I said that it's only sending the TX data so uh again if you go back to analyze an ethereum block what you'll find I block has the transactions and it also has what they call like the state route the state route it's the result of applying all those transactions and so um in a rollup basically that that has been divided into two jobs now one job is to get the transactions out there okay these are the transactions that we need to execute in this order so that's one job that the sequencer job and then there's another uh which is the validator that's going to say okay and this is the result of executing those transactions now You could argue that this is uh not entirely needed all the time uh I guess if you're running your own node and you know the transaction that you need to execute you can execute them yourself and you get the result no uh but this is actually become quite important if you want the layer two to communicate with the layer one in this case is you because uh the validator is going to compute that s Ro is going to send it to ethereum and then ethereum is going to I guess ethereum contracts are going to be able to say oh because the state rout the the result of the layer two is this I can do this other thing on the layer one that's basically bridging no or what they call in uh in this um lingo it's like a validating Bridge because um it's in the time of of brides basically we are validating the whole state transition now how does this change when you go and try to do offchain da so when you try to do offchain da well you need to introduce another actor here which is the da provider and so now this thing that I would say that you have like free jobs is now divided in fre uh free jobs so the sequencer is going to um be responsible to sending the data commitment uh but it's going to send the data to the VA provider what does that mean it means that basically uh guys uh basically um the ethereum is going to still be responsible of uh giving you the order in which you need to uh process all the data no imagine this is not like just one time you are doing this H for every block or for every batch of blocks and so ethereum is what they call like consensus layer because it's basically giving you the order of all the the pointers to data but then you need to go get a pointer to a data and ask the da provider to okay what's what's the data that I need to process okay so Celestia of chain sorry is Celestia VA of chain that's what you mean by off chain uh Celestia is also offchain yeah I'm I'm here talking more of a general like offchain da uh I'm going to be talking about I da but celesia will be the same so this General process will be the same every time you see an offchain da no uh you are going to send the data elsewhere but then you're going and you're going to get like a commitment of that data from the da provider and you're going to send that commitment to ethereum you can imagine that that commitment is like a pointer to the data okay um before getting into igda another thing I want to mention from the op stack is what they call op plasma or I guess they used to call op plasma they are now calling like op Alda and the idea is that this is a a protocol for offchain optimistic da what what do I mean by this no so um I guess this is more or less the same that I just show no the sequencer at some point is going to go and post a blove so this transaction data to the DA provider in this case going to be call like the plasma server and the full node when it wants to sync when it wants to basically get all the transactions is going to go to the same plasma server and going to say hey uh give me the block for that key no and by key I say it's like this da commitment I was talking before no so the sequencer post a blob to the VA provider plasma server no this is something like this uh and it's actually an htb protocol so the idea is like you're going to go basically do like a post and you're going to send okay this is the blob and as a response you're going to have like this kind of X and code and commitments or you're going to basically get okay this is the commitment of my of The Blob you can use this commitment to later go fetch it which is what the the full node will do no so it's very basic it's not really telling much what is the optimistic or what's the interesting part here it's uh what they call like challenges no so uh there's an attack that you can do to these systems now imagine uh we know that I know it's very hard to attack ethereum has like a a ton of Economic Security uh so would be impossible to gu quite hard to go and change those commitments to do like a reorg or to do like a um like I guess yeah a reor like a dou you call people call like double spend attack but in this Cas is just trying to change the history of a them but what if the da provider uh at some point decides not to serve the data no so you have a commitment and say hey give me the blob for this commitment and the da server says okay to you I'm not giving that or to you yes or or or I don't give it that to anyone no what happens then and and that's actually what what what they call like a data withholding attack no and actually in um optimistic uh rollups that could be quite serious because you know that optimistic rollups have this uh okay I haven't explained that but basically when you send the state commitment there's a challenge period of uh s days in which um in which um anyone or some parties can go and say okay that state rout that you said it's actually incorrect now what happens if the da provider decides to withhold data for seven days so no one is actually able to get the data executed and challenge the results and so that way would be basically a way to generate a hard fork or do a double span attack on the on the layer two so what op people thought was okay we're going to create something that's called a challenge no and the idea is like when you are syncing when you are a full node you start getting and you start quering the da no uh provider the plasma server and if the plasma server uh is not giving the data you're going to send a challenge to a Smart contract on ethereum and you're going to say hey uh I I can get the data so put it here put it on the L1 no uh again the whole idea is like I'm going to be paying for the cost of that as a node um so uh you can you can do the this kind of dis griefing task uh but what will that generate is like the da server will need to either post data there or um or it could choose not to but if it choose not to the L2 itself will reorg no it basically would say okay there's a challenge and this challenge was uncontested and and so we're going to rewind the the story of the of the of the L2 to the point where basically that data was not available no and so this requires a smart contract and this requires a very subtle but important um when you create this kind of challenge contract you need to be able to say hey I I ask for this key uh for this um da commitment and um you show me the data no and how do I know that the data you show actually belongs to that commitment to actually do that you need to be able to let's say uh the simple version would be like the commitment should be like the hash of the block so I could have a smart contract that basically hash the whole data and say okay it's the same cont cool so uh let me talk about igen first no so again uh the idea is a DA solution it's an offchain da solution has this kind of fre steps no it's going to be something that's called encoding then it's going to be doing thisp person attestation and finally it has something that they call bridging um the idea is like uh this is designed to be horizontally scalable and so the idea is like um you're going to talk and maybe I'm going to show it here first you're going to talk with what they call like a disperser so dispers is a service that they run and then these etherum validators that are part of I da can run what they call like this da nodes and so the dispersor is going to get your blob is going to do aure encoding into that it's going to put all of that into a kcg commitment into a pol commitment and it's going to send chunks no this uh part of this um of this blob to the different da nodes and so why does this scale is because you can actually have as many da noes as you want and that's going to give you a lot more bandwidth that you can basically use no so this scales with that and so the first part that I was mentioning like this encoding and a it's the a show encoding and then getting all of that into a polinomial commitment and I guess generate all the chunks and send all of those uh to the to the to the DA nodes now the da nodes are going to get uh get get the get a chunk and it's going to return a signature saying hey I I I I I I saw that chunk I'm I'm holding it I'm I'm going to store that and that's going to be part of a BLS signature and and so the disperser then is going to got all those D BLS signals is going to aggregate that and that's part of what they're going to give to you I guess the client I say hey here's a BL signature here's the proof that your blob has been stored on on I now if you are like talking to a disperser using HTTP or um um any well hgp that's okay for you you will have that data uh but what if you are a rollup or what if you are a smart contract that you want to kind of know that actually that happened so they do another thing for that uh what that's what they call bridging no so when you go and call the um when you go and call the disperser the disperser is going to get your blob is going to store it using this process I explained and the second thing is going to do is going to add that into a batch no it's going to basically have as many blobs uh it's going to have like I know let's say I think it's for 10 minutes more or less it's going to accumulate all those blobs it's going to put all there into a Merle tree uh and it's going to call all of that a batch and it's going to send that batch uh or the batch header with like the batch root uh to etherum and thanks to that you can basically go and prove that you your blob has been a tested it's basically part of a batch no on a them and by doing you can basically use uh that Knowledge from Smart contracts on ethereum okay um that's again um not necessarily what you will use but it's actually what it's going to give you uh certainty that is has been attested has been stored is going to be available okay um final thing that I guess I wanted to go and talk is how you mix all those things together now I talk about op LDA I talk about I da how all these things work so this is basically what I describe about op LDA or plasma and this is what I be describing about um about igen no uh the way it works is like again you still have the sequence or the sequence is going to talk what with this plasma server uh there's actually one that exist is called igen proxy that Implement that standard the igen proxy is going to be talking to the disperser which is part ofda andda is going to be doing the da nodes uh going to be talking to the DA noes the same thing as a full node you will uh be able to go reach the I proxy and going to get a blove no and you're going to get all the data now for da commitment it's not going to be the hash as I explained uh as the simple case it's going to be more of like a serialized data structure that contains like the blob the batch where this was stor the batch header and and some miracle proof to show you that you can actually verify that actually exist um and again if it at some point it fail you could always go and do the challenge now and say okay um show me the data now show me the data that uh you you you said you had but you are not willing to give to me and you can create a challenge again for that you will need a specific kind of contract that is able to understand like the da commitment of of igen which is um I guess in construction right now now uh I say this is very simple but it's actually not that simple right now um when you actually the disperser I guess as I said puts everything into a batch and it's also going to consider that your blob it's like fully fully like confirmed only when that batch has gone to ethereum that actually takes some time time and so the way they work is basically you post a blob they give you a request ID and then you can actually go and query the disperser as many times you want to see if like your your request is done or what's the set of your request no and so uh you can imagine that first phase is going to be Aur encoding and then send that to uh the da noes that's probably good enough for some use cases um then it's going to tell you okay uh I already include into a batch and the batch is closed no and finally um it's going to send that batch to ethereum and it's going to tell you okay it's done in ethereum here's a transaction or even more it's on a transaction on a block on ethereum that it's already finalized no so that actually takes some time um so a few things that I wanted to mention here that I guess are kind of missing pieces that we are working on uh either byself or with IND da or with OP um so as I said the challenge mechanism uh the op plasma initial version relies on the idea that da commitments are hash of blobs here is quite different and so there's a need to actually create this kind of challenge mechanism for this to work um the second is like as I said this um this um the disperser takes actually some time to to do the rights um several minutes and so uh we are working actually in like making many or concurrent rights because you don't need to actually wait for that um and they also working on like actually having all of that in a in a in a faster fashion uh another thing that I didn't explain too much but if you see this um this this uh diagram you see that the from a from a system perspective like the disperser seems to be like the central point of failure right like they run the disperser and the disperser is down well everything is down uh again it's a server it's a service that you can I know have all your like technology and Ops to uh make it for tolerance replicas and everything but it's still going to probably be run by one a single organization and so the idea the they're also part of I is to go and and decentralize this and so you could potentially run your own disperser this is not something you can do now but would be important for the future if you want this to really really work um and finally this is more of our own uh addition which call like a backup service and I'm probably going to be discussing Now with uh when I talk about like failure scenarios um so when we I guess as I mentioned beginning we are working on um we are working on integrating op we T in da and run cell on top of that and so one of the things we start doing was try to understand how this could fail what would be our response what would be the response of our system in those scenarios no so I guess you have like two typical like buckets no you can talk about right failures so imagine uh you are the sequencer you uh create your own transaction B you want to talk to the service you want to write that and let's say the disperser is down and so uh you are not able to communicate with that or the dispersa respond but what doesn't respond doesn't really verify no so they give you a DA commitment but the da commitment uh doesn't um doesn't match what you expected those are for us maybe the similar thing for us is the same thing like right fail and there's two type of solutions uh you can have or guess free um so you know like chains have like I guess two options right when when it comes to to failure they could say to um prefer liveness and so they say okay I'm going to continue working even if I can guarantee this is going to be final and it's I'm okay with reorg no so that's for example like how ethum uh tends to they prefers uh liveness over safety or you can prefer safety and say okay I'm not able to progress because the conditions are not met and so I'm going to stop no and depends on what kind of of system you want to build you can say okay what with my preference so in this scenario okay you can write so you have you can stall you can say okay I'm going to stop um you can uh you can uh you can you can choose livess too you can say I'm okay with reorg uh when this happens with this change or uh you could also have like a secondary um secondary server or mechanism to write for example you can go and talk to um send the data to directly to ethereum as C data or as blobs or you could have a secondary uh da service for these kind of things now that's that's that's okay uh this actually is more challenging um so what happens if a read fails what happens if the if the dispersor goes down or the dispersor send something that doesn't verify so the first thing is like well you know that you have the challenge mechanism so with a challenge mechanism if read failures it's going to generate a reor no so that's actually solve there uh but maybe that's not what you want I guess in our case we prefer to have H safety over liveness so we want to have like what call one block finality or reor resistance and so we don't want to reorg at any cost so in our case what we are thinking is actually have like a m of a backup service whenever you write I guess we will probably write that uh ourselves at Le as a training wheel for this system so you know that you you'll still be able to read whenever you want and I guess I'm on time and this is all that I wanted to show uh yeah thank you so much we have time for just one question if anyone's got a question please feel free to give it now yes um so I'm curious to why you chose to use a data data availability service now that uh you know on L1 we are in a blob World ands use 444 blobs which are quite cheap and you know there's a separate Market from the call data um is there is there still benefit to like using the data availability service over blobs this cost yeah so I think uh it's probably a cost and the problem uh we see how we see is like I think uh right now with prod sharding the costs are pretty low um and it's not being the B anymore at the same time we are seeing all these l2s posting and starting to be coming coming on ethereum and so it's very hard to uh Gamble or know is like okay are the cost going to is like the supply of blow up space is going to be as it is now or because the demand is going to grow so much the ca are going to increase again so when you are trying to make this kind of long-term decision you are saying okay uh always a bit of a gble you say okay well maybe the demand is going to increase but then it's going to arrive D Shard full D Shard and we're going to be okay again but uh still a bit of a of a bet no so I guess it would be more of like a conservative approach where we say okay we know that we can have actually much cheaper da uh in a way that is going to always work um without taking that Gumball um the whole thing is like again uh on these systems you could eventually change if you want it uh the nice thing about I haven't really describe that on on from this Alda or plasma solution is like whenever you say a DA commitment you basically um you send like a DA commitment of Type X no and so you could basically uh when you are reading those da commitments no you imagine it's basically uh a full note reading from a queue and reading messages and so you say okay this is a blob da commitment I'm going to read it this way this is an i da da commit I'm going to read it this way and you can do all of that and So eventually you could basically have a multi da system or with FW as I said or you could switch so I think that's interesting too from a syst perspective awesome thank you very much another round of apprise [Applause]