Panel: State of 4844 | Optimism Summit 🔴✨ The Future of Ethereum
ETHGlobal·Sun, Oct 9, 2022, 12:00 AM
Join Tim Beiko, Terence Tsao, Mofi and Roberto Bayardo for a panel talk titled "State of 4844 " - Part of our Optimism Summit 🔴✨ The Future of Ethereum. ETHOnline is our biggest event of the year! Collaborate with thousands of developers and creatives from around the world and win over $300k+ in prizes! We're bringing in 30+ of the biggest teams in web3 to give you access like never before. Learn from ecosystem leaders and build your biggest ideas as the merge nears reality. The future of Ethereum is being written right now, and it's time to make your mark. --------------------------------------------------- Follow us: https://twitter.com/ETHGlobal​ Check us out: https://ethglobal.co​m Email us at: hello@ethglobal.com #ethereum #web3 #blockchain
Transcript
foreign [Applause] [Music] hey everyone welcome back um so up next we have a panel on uh the Theta 4884 and we have a really awesome uh Team of experts here to talk to you guys about it so we've got the legendary timbako Taryn Sal Mophie and Robert bayardo welcome guys thanks so much for being here thanks for having us cool I guess um yeah to kick this off uh maybe we could just take a couple minutes uh doing quick intros especially because uh 444 has been interesting in that it's mostly been spearheaded not by kind team so far um obviously you have parents here uh who who's on on a clan theme but yeah um do you all want to think just a minute or two and kind of share who you are and how you got working on 4844 um absolutely I'm happy to go first so my name is Roberto bayardo and I work at coinbase I've been there for about a year now um and I'm not on a client team therefore I was not as overwhelmed by the merge I think as everyone else and we have deep interest in scaling ethereum and I was given the opportunity to participate in this for a bit um and so uh jumped at the opportunity um and you know hope to keep getting more involved as as things go on you wanna go yeah we go next hey um I'm milfi taiwo um I work for op labs um which uh is building the um optimism roll-up and um I started working at eip44 sort of like out of necessity um way back like early summer um because it was critical for optimism to have something like this to keep a roll-up costs uh pretty low and uh yeah pretty excited the opportunity to um get this out the door and uh get it done cool parents hello hello yeah so hi I'm Terence from prison Matthew Labs I am mainly a core Deaf from the consensus layer so I've been working around this space since 2018 I started working on proofre stage now it's known as The Beacon chain and um last year I've been working on the merge and also a little bit of MVB stuff here and there and I've been interested in 4844 actually since if Denver this year February and um I hacked a little something with Proto Lambda so that was fun but yeah I've been mostly watching from the side for the last few months because of like the merge will slightly more important but yeah I'm actually really excited to start picking this up again and uh uh hopefully we can get this into Shanghai nice yeah I think I think it's worth adding then I think when we say we're interested in the ip4844 I mean we're interested in each scaling right and this is kind of the natural first step to getting where we want to go yeah yeah absolutely and um yeah parents you mentioned you know this first got prototyped around eat Denver and um maybe do you want to actually take a minute or two and walk through like how this relates to bank sharding for people who have like no context um because you know we have this this plan to scale ethereum massively uh like Roberto was saying um and Ford for four is kind of one of the first steps towards there um so do you maybe want to just take a minute or two and tell us like what 4844 is and how it relates to like full full scaling on ethereum sure yeah happy too so um so how do we scale right so right now what we're doing with Bitcoin and e3m is just every no download every single data and to verify every data and that's obviously not going to scale right and um with how this drops into roadmap essentially with the our official romance it sounds more like that we will essentially um put the data on chain and then run the execution option basically but in the event of fraud the execution needs some sort of data to basically prove that where the fraud exists right so um so um so the notebooks so usually how it works is that we we will have sharding basically means that not every node has to download every single data but with sharding it comes data availability sampling which may take a few years to resolve and 44 is essentially the stepping stone basically say hey we will essentially Black Box the the data will be sampling aspect and just put all the just make every note download the data as well but it's a nice future stepping stone for the future yeah right so it's almost like today all the nodes download and execute everything with roll ups you can have the nodes only download the data but not execute every single transaction that happens on the rollups eventually you would like to get to a spot where like not the nodes don't even have to download all of the data that's concept on the network they can only kind of sub-sample part of it and know that uh that that it was correct um and 444 is saying like we're gonna we're gonna add more data capacity for these Roll-Ups but still get everyone to download everything the roughly right um and uh and like you're saying you know this kind of came about earlier this year and and got like hacked on at Denver um and after that uh Mophie you were like one of the people that actually like started working on okay what does a proper prototype look for this um what do we need to do to get this and get in prison first and get all the Kinks armed out um so can you kind of walk through like you know what you've been up to over the past few months uh what the implementations were like uh and yeah like where things are at now yeah yeah certainly um yeah it's been a wild ride um last couple months uh getting into like EAB 444 was like something I was even aware of it until around like April even though like it was worked on the East Denver um but my first thinking was okay we really need this for optimism like gas costs are out of control right and um and the rate of user group that we're going um we really need this soon as well So like um basically roll up my sleeves and uh start working on an implementation at first it was uh basically looked at already existing work like what Terence and uh mentioned he and Proto already had like um a proof of I guess like a proto-proof of concept of eip4844 um there are some things that are missing uh First Step was basically to take a look at that existing um code and extend it basically um so what I did first was uh complete the implementation in the execution client um the one that um already existed was gef so all I had to do was continue working on gef and have that done and the next thing was uh to have a consensus client that also incorporates CIP 444 um even though it's not quite evident if you look at the spec there are a lot of like consensus uh level changes to AP 444 and so um I basically looked at prism because it's written in go and um I'm pretty familiar with a girl lately so um that was like my client of choice for this but really could have been any client um so I looked at a prism basically started implementing um what's needed to um get eip44 working and um yeah that's pretty much mostly what I've been doing for the past couple months and then there was a point where once both the deaf and prison implementations were good enough and implemented most of the spec it made sense to like start integrating things and um that's what gave birth to um the first devnet um so the devnet is basically a small like Network that's running um the eip44 hard Fort um it it contains implements both the consensus and execution level changes to the spec and uh it's kind of like our like playground we're using to like test out you know how would the spec behave in certain conditions and uh what sort of transactions can we like send to it and uh testing like the threshold of like the spec itself sweet yeah that was a great overview uh Roberto Terence said you think you guys want to add on that I just want to give a shout out to like Mophie and Roberto and team it's a heavier death net now it's a prettier mesh it's a pretty amazing like accomplishment right just because like we even had a death net before the merge and we had this death net before withdrawed everything and it's just like remarkable and I always find it like impressive and possible that people go into other people's code base and then able to make like advancements such that so so all the props and other all the all the props go to them yeah I was going to give props to Mophie specifically as well I mean he's really pushed this along consistently been been an amazing help in providing guidance to those of us jumping in you completely cold and being able to get reasonably productive anyway I also wanted a shout out to Michael dehoug who um did some work on this from the coinbase side before I did um so I'm a relative newcomer here um I did some work uh predominantly in the consensus layers side um implemented the um the the new style uh um blob verification for so long um for example um and continuing building from there hope hopefully we're gonna get the the next version of the devnet up soon where we have the latest spec changes for the most part implemented um at least you know Still Remains a little bit of a moving Target but a Target but it's starting to settle down nice and yeah it is I believe the first time that like coinbase like gets involved in working on a protocol change um I think that I recall um I'm curious you know why does coinbase want to do this like what is the rationale to put Engineers on this uh instead of like the Thousand other things I suspect we all have to do um yeah it's that's that's a it's a great question and as you know Tim I've been talking with Tim since I've started at coinbase trying to figure out how we can contribute and it's um there are a lot of competing um um efforts for for time for a coinbase employee um but ultimately I mean I think we realize that um you know we want to we want to raise raise all boats we want to build out the ecosystem and and you know that's not just purely purely charitable um we we view coinbase it's not you know just trying to be kind of the most easy to use and secure exchange and custodian for crypto out there but we we view it as a you know a broader um uh onboarding mechanism to to crypto as well as all of web three um so if you think about it that way um and look at the kind of number of users we're we're dealing with if we took all you know roughly you know 100 million-ish users of coinbase and tried to dump them on chain um you know it wouldn't work out so well right now um so and we want to do that right we we want to start blending coinbase's centralized experiences with more decentralized experiences again provide this um you know very straightforward easily usable onboarding mechanism and so on um and so in order to get there we need to scale the ecosystem right and the best scaling roadmap out there you know we believe is the ethereum scaling roadmap so that's the natural place to contribute and um yeah and and so you know Mike got involved at first um I've joined in we've got a couple other people we're trying to ramp up um yeah just really delighted to be a part of this yeah I I can't like emphasize enough like how much effort like Tony bases um putting into this um we have like a very good relationship with coinbase uh because we're all both like in the same boat here we really want ethereum to scale and we also anticipate like um the huge influx of users as we come in the next couple years so it just makes sense for for the collaboration effort that we have going on yeah and maybe uh you know that they're bringing back to like how we actually get this done um parents you know you're you're on the client team obviously uh and all the time teams have been deep down and emerged for the past year um but some people have started to like looked over to the edge and think about what comes next what's your general read of like how client teams perceive 4844 now like what did they see in terms of like the complexity here the risks um you know what yeah if if people have had time to even look into it but yeah what's your general read on that front right so I can give my perspective from the consensus of the client so my first impressions I really like it I think it's elegant and I think it's a good stepping stone and it's funny because if you look at ethereum history right we don't usually just dive into something we make incremental progress I think a good example of that is just like we should prove a state we can try it first we didn't just merge right we ship this day we can share we let it run in the wild for like one year and then we hop forward to a tear but we did a merge there right because we want to try to understand how to hard work in this type of environment so we take our time right and another example is just hybrid PBS right we didn't fully ensure on PBS first we have this hybrid PBS we use like Med boost just because we don't want to commit into something and I think this is a very similar concept basically we are exploring ish right I think I think my perception is that I think some of the teams also think that I think important to get it done but we want to get it done as safely as possible we don't want to trade off between quality and speed for example I think majority of my time will be spent on testing and then in terms of just implementation complexity right I do think it's a little comp I do think it's a little complicated just because there is this new cryptography primitive such as kcg and most of the client teams unfortunately don't have like ads per cryptography we have to work with someone else and unfortunately when you work with other dependencies it takes longer it introduces more complexity but the good thing is that we are using IPOs like in the current on previous day so we do have some experience working with like um the teams as well and I think the consensus and the network changes are fairly easy just because we've done that before many times for The Hartford and then I think majority of the fun part is just like client implementation detail right for example like we have this concept of optimistic thinking about what can a client do when the data is not available right I think like using the merge as an example right there's probably like in prison there's like 20 000 lines of div but there's many there's only a 2 000 lines of Beats that that's actually important right and then we spent the longest time just looking at those 2000 number div to make sure hey this is good this is good this is good this is good so I will say definitely um lots of time on testing and stuff and I also know like Mario's from Jeff has hacked like eip44 Branch for Lighthouse at ipadine is super awesome and Enrique from take Tech who has also been asking questions on that front so definitely seeing a lot more progress right now but overall I am very bullish and do you think introducing because we're basically introducing a new layer into ethereum right with this EIP we have like now we like to call it the consensus layer execution layer you can almost think of these lots of like a data layer that we're introducing um how does that like change you know the client architecture or the testing infrastructure like is this as big as the merge where you know the merge we had no way to test the combination of execution and consensus player clients and we had to spend you know months and months building all that infrastructure is adding a data layer similar or is it actually a bit simpler because you know it's still handled by validators on the beacon chain and and we have a bunch of infrastructure there so yeah that's a good question if you asked me that like a year ago I probably wallpaper or like pessimistic like you ask me now I think like we are like used to this concept of layering right for example we have translations layer we have an execution layer and with like all the MDB stuff we have this Builder there so like everything is become more layerish and then so it like every software implementation is very complicated but they are as complicated as basically the API between them right so we have this concept of engine API where it consists this layer and an Institutional layer basically uh it posts certain things to each other and that's all they have to understand and similar with this like data layer whatever we're calling right we will essentially it's post this API such as getting blob such as and stuff like that so yeah I would say the complexity is pretty like encapsulated so that's nice and we have also so done this for the merge so we're quite experienced at this already and then it's just testing and which we have been testing for the last eight months right there's like great people like pairing and everything we know we know how to test this with different client combos yeah I I just like to jump jump in and I think this is way simpler than the merge um the prototank charting in particular it's it's pretty strongly coupled with a consensus layer at this point it's not like it's adding a completely new independent layer so I think it's I think it really hits a really great balance of you know getting us taking a step towards that independent data layer um without having to go all the way there so I I actually view this as a relatively low risk change again being somewhat young muted this project and probably naive but um compared to what I saw going on with emerge this to me seems like almost a piece of cake nice um and you know like we keep saying how this is uh what we'll use to scale ethereum and how Roll-Ups will use it uh Mophie you want to take maybe like a couple minutes to walk through why is this actually better for Roll-Ups like how does a roll-up use proto-day charting to provide lower fees to their users yeah certainly um so right now um roll-ups basically have to have to like do extending transactions and doing everything in L2 we need to post that data back to L1 it makes it easy for um a new node that's joining the network to derive the chain right once that data is available but posting that data is actually expensive right now today ethereum um the main way we do it well the only way I think most Roll-Ups I know does it is by using call data um when we create a transaction on L1 all the transactions and state routes and commitments that we roll that up hence roll up um into a transaction on L1 and that's posted via the call data but the call data is quite expensive um over like the past couple of months a couple Roll-Ups including optimism have like implemented like a couple techniques to cut reduce the size of that call data like um compression but overall it's it's still not sufficient especially with the rate of growth we've seen at like L2 Zone it will like eventually be more and more expensive so what blobs transactions do what which is what the AP 4544 brings is provide like an alternative source of that um roll-up data that we need um and also provide like a an alternative but also cheap way to post that data and the way we're doing it with eip44 is rather than just post it back to L1 as call data um we would use like a special transaction type called the Blobfish action and this is kind of goes back to like the data layer that Tim mentioned so the the data that we're posting back to L1 um kind of like gets posted to the data layer not L1 in particular directly and the economics of this makes it much more cheaper for Roll-Ups to do because um blob space data space is cheaper than just using the L1 block space um so that's kind of like an enough that's part okay that's like one part of like how l2s would be using relapse the second part is also like um in false Crews right as I roll up well for optimistic Roll-Ups in particular um we need to be able to um easily dispute any invalid like uh State Route that's been posted on L1 and with eip44 this also makes it easy all we need to do is just change where we're um getting the data used for that fraud dispute to use blobs instead um what I like about this design is like it's very easy for optimistic Roll-Ups to just plug in what that data source you're using for this it's either from the data layer or from L1 call data doesn't matter oh so yeah that's kind of how it works in a nutshell nice and I guess oh sorry go ahead oh no please revert though I was just gonna add it in and right so then when you can start um extending the data later to implementing the sophisticated um you know Erasure encoding and um rather than keeping it with every single consensus layer but I think one of the things to add um if for the for the viewers that aren't intimately familiar with the spec is um The Blob data doesn't need to be kept around indefinitely by by the consensus layer it can be it can be thrown out I think you know the the discussions I've heard so far is you know probably after a month or so right because I think the main need for that data is for these fraud proofs or availability proofs and so you know after the uh dispute period is elapsed there's no reason for a standard node keep that data which is one of the reasons it can be price cheaper for example exactly nice and um you know so okay so we have all this l2s are going to use it it's going to be great it's going to lower their fees um what's left with you to ship this like uh you know first of all we this hasn't been accepted by client teams as part of the next uh the next Network upgrade yet uh because we frankly haven't had time to to discuss it in much detail because of the Verge um but from like a purely technical perspective right to bring this to a spot where like it would be safe to deploy a mainnet what are like the big things that are missing um and and that you're all kind of looking into uh I I can go first then maybe like people can fill in from my perspective I do want to like um start merging the changes into prison which means like currently the code is more for like devnet but it's not so much for like a production Readiness quality so um it will be hard to merge it so I would definitely want to clean up whatever we have today to merge it with upstream and at the same time I do want to like sync with the devnet a little bit play with the death net try to break it just to make sure it's robust it's it is resilient and I do think it's very important to write more right just right now I look at I type eip44 on Google and nothing really show up so I do think we need more like nice resource material such so that to bring more attention to the community and I think that's like a great way to like push forward foreign I think the other thing is just more client implementations right so we've we've um you know we've got prism and they're it they're preliminary and um Terence is absolutely right there's a lot more than needs to be done to productionize that code to test that code to um you know prove to everyone out there that if we launch this on the main event um things won't explode right so the other thing I think we really need to do is we need to set up an official test net that I think has the IDE 484 for active um where you know the developers of l2s can actually start creating their next version that takes advantage of it and seeing what what benefits it provides yeah and and so after that um it would also be I think we also need like a proof of concept use case of uh the ib-44 for like a roll up um because again maybe I'm a little bit salty about access lists but we don't want to end up in a case where um we deploy AIP and people start using it and realize that oh the gains are not that much that we expected you know we wanted to like show that this thing actually works it's a valid use case we we would like use it once it's available and it'll be a huge Boon for the roll-up um teams so I think demonstrating this um by like by in particular rather good Bedrock we're actually working with coinbase to um integrate fedrock with the Bedrock is like the optimism upgrade that's currently important development and we want to like integrate it with Eid 444 and then tell like the client teams that hey this thing actually works um it's you know you can see how it works it's not just vaporware or something that'll be really I think a good way to like convince client teams to like accept it absolutely yeah I mean the the back of the envelope math looks great we expect it to scale it'll help scaling dramatically but uh you know prove is in the pudding once we have code a usable um usable system I think it'll be a lot more convincing right yeah yeah and uh I'll put us on Mophie to your point where it's like we've we've had features in the past that we've deployed on ethereum more like the um yeah the usage didn't end up being what we expected so uh accesses were once there was once another pre-compile for interop with Z cash um that uh I think Z cash changed a curve a few months after so didn't end up working great um so seeing something like a you know Cutting Edge roll up implementation that's that's working on a prototype of 4844 that would be that'd be really valuable um and one thing uh that 444 also introduces uh that's kind of new to ethereum is uh basically this idea of case and G commitments which require a trusted setup um so it's like a new cryptography primitive that we're adding to the network um Mophie do you want to kind of walk us through what that is at a high level like why do we need to add new cryptography to make this work um yeah and and just your general view there yeah um so the data that we're posting um to the is where we've already dubbed the data layer that relatively using we we need a way to be able to like um prove that you know a particular piece of that data um we need to prove What that particular piece of the data means and this is like really useful for example in frog proofs where rather than sending the entire data set to your fraud proof you would just send little bits of it right and you can like convince the fraud prover that hey this data like matches the little piece that you've posted so what kcg lets us do is um it's basically it's like a commitment similar to um worker proofs but it's different from like um marker proofs in the sense that um it's easier for you to like um prove a particular Point um with the same like proof size and also it's very easy for you to like extend it um this goes back to what Roberto was saying about like um full data availability and Erasure codes so with kcg it's very like um you can like extend like a kcg um your data with the kcg and then easily like and make it available for data availability um so that's kind of like gets over like the overview of like why we need a kcp about 4844 but it's like new cryptography like what team says um that we're introduced into the consensus uh client and um it's uh it's there's like some unknown unknowns a little bit that we're still trying to figure out in particular like what's the most efficient way of like um verifying these kcgs and um it's still like an open research question there but um I think as more and more people are like getting into like um the yeah the spec and taking a look at it we'll be able to like get develop better Solutions there yeah I think it's also worth adding that while it is Cutting Edge crypto it's not quite as Cutting Edge as some of the stuff that's going on and the like zke EDM world right um it's a fairly contained um a dare I it's I wouldn't dare say well understood but it's I I don't think it's like we're you know really inventing brand new stuff here um so and some I'm not a crypto expert uh by the way um but I was able to follow us back fairly um easily and and go and implement it with with the benefit of you know the Proto Lambda work and the kcg libraries and so on um so yeah I I just I guess I don't want people to be too frightened by that work that's going in there because I I haven't found it terribly intimidating again as a non-crypto expert yeah true like the math like kcg is based on is pretty old math like 80s math it's just like it's just recently we're starting to like actually implement it uh production-ish system and that's where like we're trying to like figure things out yeah in in Mophie in particular has been doing lots of work and optimizations and benchmarking and things like that so that that's another part of uh the project and work remains to be done there making it go faster I guess the fun question is like um do you foresee that we just have one crypto library for kcg that all the clients can use or do you foresee there that they're like they're like there will be multiple efforts that every client team will build their own kcg Library I think there will be one or two um in particular with go where we're thinking of using like one particular library that has like written in C but there are some like particular things with go and interop with like C code that might prevent us from eventually using that but I could definitely see like other client teams that perhaps using rust uh would probably use that as well and yeah it's pretty much mostly two implementations um at the most I think yeah Q feels like it would be a sweet spot um one has been a contentious Topic in the past for implementing stuff on ethereum because we do have this multi-client architecture and the whole purpose is that if there's a bug then um not all the clients are affected but then if you have the central point where everybody's using the same library in the background um you know for for the purposes of those operations you're back to like a single neutral inpatient so um hopefully we get to see two high quality ones emerge over time um yeah yeah it's been interesting we've been trying to sort of figure out where to set that bar where the appropriate abstraction layer is where we start sharing code right you want to set that as low as possible but without requiring people to like Implement their own very low level bid to a link to get the crypto right um so yeah correct yeah yeah yeah um and I guess that the kind of go back up a little bit um you know we we've talked a lot about 4844 itself and and where we're at there um Terence do you want to like walk us through what you know if you look at like the whole world map towards full Chardonnay what like percentage of it is done with 4844 like what are like the the boxes that we check off and then what's the stuff that we would need to to do over the coming years uh to get kind of better scale on ethereum right I I can this a few points so what 444 includes right what 4844 increase essentially this new transaction type it's going to be exactly the same format that we'll be using in full sharding and the most of the execution layer largely required for free sharding is also going to be there and most of the execution and consensus there are cross verification checking logic will also be there right so those three are essentially getting piggyback by 4844 and like you guys said like the layer of separation between like this data layer and the consensus layer is also there as well the concept of sampling blob right now essentially you have one you can know that samples everything but with with full charity you have this Committee of of of validators that we can note simple portions of it and that's the power of shorting right and uh I think that guest pricing is going to be highly similar as well so that's very nice right so maybe we can talk about what food sharding um has that 444 doesn't have right full sharding please have this low degree extension for the blob basically allowed 2D sampling and then it has the actual implementation of the data value sampling it has a builder and proposal separation because I don't want proposal to essentially sample 32 megabytes of blob that's just a lot right and hopefully some proof of custody stuff as well to ensure there's no laser no lazy validator that just they just pretend to vote on everything so yeah feel free to add on guys if I miss anything yeah I mean I think at the to dumb it down a little bit because um it's pretty complicated stuff for someone who's just coming to this um but basically 4844 every every um node is still downloading every blob still storing every blob um with the exception of that what I mentioned earlier where they can delete it um the full sharding roadmap you know once we start doing this Erasure coding each you know you have these committees that can be consulted to reconstruct the data and so no longer does every node have to store every single thing so so that's why it's called full sharding well rather than than produce prototing charting yes right that I guess if you think of it in terms of costs right right now when you use call data you're storing data that is stored Forever by every node and so that's really expensive 444 gives us data that's stored temporarily by every node so it's like cheaper and then full Bank charging gives us data that's stored temporarily by only the substantive nodes and they can be even cheaper does that roughly make sense um also like a little thing that's like a bit different with the um I guess the security of uh assumptions of uh um the data layer with uh Proto dank sharding is like you only need like one node um that's available serving having the data available to be able to like sync up um whereas with um with like call data right in each like all your peers to have that data available so you can be able to sync up the tip right yeah yeah so you don't need this one that additional like that relaxed assumption makes things is also somewhat contributes uh to why like blobs are cheaper in some sense uh like indirectly yeah right that makes sense um and I guess one one final thing I wanted to touch on is um there's been tons of like Community enthusiasm for 4844 uh there's been like random people popping out wanting to help um and I'll give a quick shout out to Kane here from uh synthetics who's funded a lot of those uh that just come and help out with various things um what if if someone's like listening to this and they want to get involved in 4844 what are like the things that are most needed right now in order to the places that they should go or follow to to kind of be informed of the latest developments most of you want to take that you've got the best landing page I think well yeah there's of course eip44.com um it contains like links to several other resources that I think um should help anyone like get wrapped up to speed with uh the spec um we also have like a definite and yeah that's also another good way to contribute um basically just running a node in the devnet um building running a node you know participating creating contracts sending transactions there's a faucet available in the devnet that makes it easy for you to you know fund yourself and do things with it so that's where I think I'll I'll start it makes you like get familiar with the network before taking a deep dive into the spec yeah I was referring to um mophie's hack MD page where as instructions for getting up and running with the devnet is a great resource points shout out to Gabby and The Ether ID Discord for um setting up the faucet oh yeah absolutely and and a bunch of us hang out in the sharded data Channel and the Discord that's another good place to to interact with us I guess another one is just to write like learning material guide and stuff just a lot of people like don't know what 444 is and they're not probably not going to read EIP or because this is layers back a bunch of python code right they probably want to read something that's more like humanly readable I guess so yeah I guess I'm more education material and more resources those will be lovely yes and if people will do those please tweet at me or Mophie or Terence and we'll add them or link them on the 4844 website for sure yeah and if any testing experts out there we have we have a lot of work to do there um for example I think that's one area where there's um uh it's an easy way to easier way to get started right you have to understand the entire spec you can pick a little piece of it and you know take a look at the code we've written and how poorly tested it is so far and dive in from there yeah so testing is a big one um cool um and so if you have testing experience uh please give us a shout on Twitter emails on the website and we'll we'll uh we'll find something for you to do yeah in optimism optimization and benchmarking critically important here I mean this is this uh you know we've mentioned it a few times already um this this new crypto is pretty expensive um you know if you don't do it right you introduced denial of service factors um we want to make sure that doesn't happen so that's why that area of work is also important and plenty more to do there foreign I think this is a good place to wrap up so we've covered what the EIP is why it's valuable where we're at what you can do if you want to get involved um do any of you have any kind of closing thoughts you wanted to share with folks um yes uh to close um we really need our lives to be achieved if you want here to send your nfts and Vincent really cheaply uh this is the way to go foreign I think my only closing thoughts is that this is something we really love to Target for the Shanghai release um I personally believe it's um not too ambitious of a change to to to to you know slip beyond that um but we'll we'll do our best to to make our case through you know stuff that works um hopefully we'll get there my thoughts is um I think besides withdrawal scaling is probably the most important thing to welcome post merge because like Danny said we have sustained we have now we're sustainable and we have security so scalability is next and it's funny when I first started working on this space back in 2018 I wanted to work on shorting for the longest time and then finally now this is the time to work on sharding so yeah foreign I think that's a great place to wrap up uh thanks a lot guys for coming out I appreciate you all taking the time and thanks again to eat Global for for hosting us yeah thanks for having us thank you thank you thank you guys so much yeah thanks for all of the information and it was a really awesome panel appreciate you guys all being here thanks bye
Automatic transcript — names and jargon may be misspelled.