All Core Devs - Execution #172

Transcript

[Music] [Applause] h for

Tim Beiko: oh I was muted okay uh we should actually be live now um welcome everyone to acde 172 um not a pent on the agenda today but we'll obviously cover uh Dan so updates around Dev Nets around client implementations and any issues that that are coming up um and then after that uh we have an update on the eof work so uh there's been eof breakout calls happening for the past several months um so yeah the folks working on that will let us know what's been happening there um but maybe to kick it off I don't know if someone from the devops team wants to give a devet update and we can start

from there

sure

Barnabas Busa: I can begin so D 9 is still running we have about 93% participation rate right now we have uh gas and te submitting bed blocks so that's about 100 valat of the uh 1300 that we have around so that's another 7% so if you would bring uh get back online then we would be very close to the 100% participation rate we have a few few pairs that are not working though I think prism and Aragon is one of them and uh etherum JS is struggling to keep off with the rest of the chain because

we've been submitting transactions and blobs uh pretty much Non-Stop and certain uh certain blocks have have over 200 transactions and ejs is just unable to keep up with that uh so de 10 is supposed to Launch this week but I don't think we're going to be able to manage that so we postpone it to next week and hopefully uh next week we can launch it we would uh want to have the kg Library available in the consensus P report so each of the clients can include the uh proper kg uh files in their next release uh another note M boost is

working progress uh we have uh working relay uh powered by flash bot team and they also have a working Builder and we have quite some uh blocks that were proposed by them proposed by their Builder so things are looking good but uh I haven't been able to replicate their relay infra just yet but we have the relay running right here I just L the link for that and uh currently we have have 265 vators registered for this relay all of those are load star I haven't had time to mess around with other clients just yet nice uh are all the CLS ready to

test the Builder flow

I guess is NCL not ready okay yes for Te yes for prism

Barnabas Busa: yeah that's a better way to ask it

seems like I think

Parithosh Jayanthi: only open question was if uh Nimble muched the required PRS cuz earlier I think all the other clients we were able to test among kosis but we weren't able to do n yet don't is anyone from okay we can ping them later on yeah

yeah I don't see on the screen but

one screen

Barnabas Busa: so there's a good question regarding blobs going through me and we have not been able to confirm any blob transaction the uh so is anyone from from flgb here or any

Alex Stokes: I think they have an offsite this week but uh yeah that's just something we should pay attention to in the next couple weeks

Barnabas Busa: yeah it would be very good good if if we could have blob transactions going through M also because right now it feels like all the blobs are getting dropped even when there's some blobs in the pool

Alex Stokes: so like the Builder's ignoring

them or there's some error yeah okay

Barnabas Busa: but this is this is like not confirmed Behavior just yet it's just uh a few examples that I taken a look

uh were yeah

Parithosh Jayanthi: the main issues that we're spamming so many blobs that were almost always hitting the limit and that just increases the base fee and we're not necessarily sure yet if the missing blobs are due to the base fee being too high and there's no valid blobs that could be included or if um the builders in fact actually not including blobs that would have been otherwise included but we'll try and get an answer for that over back the next year

cool

Barnabas Busa: and I don't know if there's any other Builder other than the flashbox one uh it would be very good if we would have at least one more that we could test out

Alex Stokes: yeah I'm working on one and they should be ready soon TM but yeah I can uh circle around with you guys we can work on that

Barnabas Busa: yeah sure uh as soon as you have any kind of prototype we are happy to give you the test also so just and regarding de 10 so uh we would like to iron out all these M questions before we proceed to De because there's not much point of uh running with 300,000

validators uh if we still have open questions regarding M building so we can now hold off with that uh till we have all of this confirmed

Parithosh Jayanthi: and the other thing is because devet 10 will be bigger we want to make sure we have enough of the visible ility tools to understand how BL propagation looks um zat's added support for the event monitoring the event stream for um for blob related events and as far as I can tell te's already included that PR and prism has the pr as well um if the other clients could include that soon that would be really helpful because then we can get a visibility on every um

every client and when they're seeing

Globes

Barnabas Busa: got it yeah and uh one more quick note that we plan to have uh about 330,000 M which is a turn limit of five and uh we're hoping to make some deposits and exits right after Genesis and then uh we're going to have dun maybe a day or a day and a half later when all the deposits have reached the chain and then hopefully we're going to see a cut back from 5 to four because we're not going

to be able to test for the M defaults or there's no point of testing for the M defaults I I think it just makes sense to test going from five to

four

Tim Beiko: yeah that would trigger that would trigger the same code pass but using the the smaller presets minimal presets is that right

yes that's

Tim Beiko: yeah and I guess uh I assume we'll keep devet 9 running as well while we have devet 10 if we're still doing testing on it because I think it's probably valuable to have it at least for a while uh you

know in the case that say the 300,000 validators causes an issue or whatnot like the to have Dev n still as a fallback is that possible

Barnabas Busa: yeah Dev 9 is pretty low cost so we don't mind to have it around but we don't know how long we plan to have deut 10 and the whole idea is that Dev 9 should be very stable uh before we proceed to Dev 10 with like no more big questions which we still have at this point

got it

Tim Beiko: and so the yeah so um in terms of uh yeah getting ready for devet 10 so you said uh there's the uh the the pr that Perry just uh just linked that helps

better track the blobs um making sure that the meev pipeline works well and making sure things are are relatively stable on devet n and you think in the next week or so we can probably deploy Dev 10 is that right

Parithosh Jayanthi: yes oh yeah

Tim Beiko: and the trusted setup yeah thanks Barry

um oh yeah the

Barnabas Busa: yeah the trusted up needs to be updated by all the different clients and I think some of them make some recompilation or whatnot so

got it

Tim Beiko: yeah I guess do any clients feel like it's not realistic to

get this up in the next week or so okay and then I know uh we had talked uh a couple times about devet 10 being like the last devet if if things go well um so assuming devet 10 goes well in the next week or so um does it make sense um does it does it make sense to then uh start targeting Gordy uh in the weeks after that um so either I don't know if by next CL call we'll we'll have seen

the results but the varities by the next Al devs we should have um at that point assuming things are working smoothly um are people com comfortable moving to say Gordy I guess any oppositions or

push back

Barnabas Busa: I think we should definitely wait for the results of that

10

Tim Beiko: okay yeah I think that makes sense so um yeah I think if we can have that by at if we can have launched it by the next uh CL call next Thursday that would be amazing

um yeah and we can we can discuss it further there um yeah I guess any any client team want to share more about uh their progress or any issues they have or anything related to the to the foret itself um there's a comment by Marius in the chat about Peter wanting to have a discussion about bandwidth um I don't know is Peter on the call um no I don't know Marius yeah do you want

to um yeah I don't uh doesn't seem like he's here um I don't fully remember but um he managed to get his note up and running on definite 9 and kind of saw the bandwidth that it was um using because of all the blob spam and it was kind of ridiculous so uh we he started implementing a um a transaction Handler um that will only fetch one block transaction um per run whatever time that is um so it will not over like our

current transaction Handler would would just overload itself um because like if you connect to someone that has like a lot of blob transactions um They will announce them all and we will just fetch them in in indiscriminately and um so uh yeah I don't know if other clients have thought about this or if other clients also implemented it the way we did um because like the the G transaction pool actually now tops out at 10 gigabytes for blob transactions and um if you like if if you join like if you connect to a guest node and the guest note

announces um for 4,000 flop transactions um it will like murder your bandwidth um so yeah just I think we should have a discussion about I think the consensus layer should have a discussion about 3 six um like the bandwidth for blocks and like blobs and blocks and we should also have a discussion about the bandwidth for um uh for just the transaction uh uh spam and when you say I have a discussion about 36 the implication being like

24 would require less bandwidth or um well definitely two4 would require this bandwidth on the on the consensus layer but it doesn't have anything to do with the with the execution layer right um the the execution layer client teams have to make that decision if they they can support it um but they have to keep in mind that um there will be blob spam yeah I know that there were the was some work done on the gossiping on the SE side um I don't know if anyone who's

familiar with that is on the call right now um yeah and I yeah otherwise I don't know have any of the other um okay like Cent saying the cl cl networking issues is different um I don't know yeah do any of the other Els have thoughts on this

Marek Moraczyński: I think we are working on similar thing in NE mind right now but Marine could you share details

Parithosh Jayanthi: uh yes we're planning to have some kind of shotlink

about uh sending uh and requesting block transactions but it's uh it's not done yet but it it will be done before the

um I

Tim Beiko: guess does it make sense so maybe uh go into this in more detail on the Monday's testing call I don't know if this gives a couple days for the E client teams to like look at little bit more and then maybe we can have Peter uh come up there or um or or otherwise uh someone else from G sort of walk through

it in more details sure okay okay Marius uh I will be waiting for you on Monday um and then yeah if other client teams want to look at that um yeah uh by then we can yeah we we can discuss it more then um any other issues that uh any client teams want to bring up about the the fork

okay um anything else that we want to cover before going into eof otherwise uh Dano I think you're the one who's going to share the update is that right

Danno Ferrin: I think so um don't see any of the other typical people on the call been giving feedback on my slides um do I have screen sharing capabilities

Tim Beiko: uh try we'll see

yes

Danno Ferrin: all right cool so let me get to

um so the big proposal um today well in the update is um to move Prague towards being headliner for to make eof headliner for the upcoming prog release and we're going to give an update of um where we're at and what's been developed and what eof is to make sure everyone's on the same page for what it is so first when I say we and R I think that's important to um talk about that and I can figure out how to work the slides okay and there's four major groups of people working on the evm object format um the first team the team team that created eof um and and and did a lot of the early leg work in getting

it up and running is team ipsilon this is an EF funded team and it's focusing on evm improvements they also have another project that they run um they make a standalone C++ interpreter evm 1 and they used to work on the ewom so they know a lot about why wasm won't really work from from doing it which is really important to know that um through doing it why it won't work second group of people is we have execution clients um representatives from there got people from GE basally with never mind and occasionally we've had some Aragon um but they're going to you know work with mostly gets VM so it's going to be fairly easy to put there and at least back in January all the teams had the same quote unquote big eof implementation and we

were actually doing fuzzing on the container format and on implementations before it was decided that eof was not ready for Shanghai um part of the reason we discovered why eof wasn't ready for Shanghai was this third group that's been involved very involved in the past few months the compiler teams we've had representative from solidity and Viper giving very valuable feedback on some details of b um a few new features have been added um to support them but mostly it's been working on the finer grain details of you know we need this for the compiler this will solve some size regressions um it's mostly there we have most of the solutions we have we know that we need to do in either this release in a big release or maybe in a few op codes in the next release but their input's been invaluable and

validating that what we've worked for eof um is going to work within the compiler teams and another important thing is that the downstream users of eof the compilers themselves are on board with it um and I think another important group that has shown up is we had some people come in from from various data contract teams at store 2 is one of them they want to use the contracts for data and they've been you know interested to see how some of the changes we've been doing from eof will impact their work and what we have you know there's one op code they have proposed that would make their job a lot easier but even if we don't have that op code they're confident that what they're doing that St to will work with eof and will be acceptable for what their needs are so what is eof um evm object format

is mostly a container format for evm code um the big thing is it it separates code and data which is one of the big base problems when it comes to taking evm and converting it to the other any other format is where's the code and where is the data and can we make hard and fast rules about it solidity and Viper have adopted some conventions but those aren't enforced as part of the container format container format makes a separation a mandatory and it also requires that all code is valid so if you see um bad data in there um you know you can't see bad code in there that is Mas grading as data or data Mas grading is code if it's code it must be valid and it must be executable and data can be whatever it needs to be and the two

never mix and because of this we're able to fix a lot of evm evolution problems um a famous one is we're not able to add any op codes that take immediate arguments because of an interaction that if a jump Des is inside of um what would become covered by um invalid code that would make the next immediate a jump Target and get rid out jump Target in theory you're changing the execution of the contract um so that you know something that was was done away with pretty early in the Pro in the process and we're also able to prohibit a lot of problematic Behavior a lot of things that get in the way of supporting things like ZK and transation

to other formats and just transpilation between different versions of you know the evm if we need to change things so that gets it to the next question you know how many versions of eof were there going to be how is it going to work the idea is that eof will operate in parallel with Legacy evm smart contracts I don't think there's a reasonable way shortterm to ban Legacy evm code Maybe maybe in long term once eof has wide adoption and um we can lock down the addition of new contracts and do that deliberately um but as far as eof I think the plan is there'll only be one version and it would be if we need to update the format there would be standard um translations between the two but that's not said in stone but what's

planned to there is there just one eof version and one Legacy version now it sounds like we're putting two VMS in ethereum um but we're not the difference between e and Legacy evm are almost entirely in the packaging and the validation of the code and in some of the op codes that are supported um but once you get away from that the evm um Legacy evm and eof are the same they use op codes they use Stacks they access storage in the same way they access accounts in the same way they work with message frames the same way they revert in the same way memory and transient storage are performed in the same way um it's just a different way to package it it's whether you're you know whether you're driving a truck or a car I guess is probably the best way to describe Des

cribe it um there's still four wheels you still have to follow all the traffic rules um there's just a different place to put all of your all of your equipment goes in the back of the truck so um I would say eof is the truck because we separate the cargo from the people now um what are the major features of eof now that we got you know overview of how we're going to do it and where it fits in what are these big major problems that e is fixing and I've identified about eight major things that eof addresses the first thing is the container itself is a big feature set of EAP to separate data and code um static jumps something that people have been

asking for for years now that we can do a mediat it's something we can build into eof another thing that people have been asking for for years is sub routines um we have a a facility that does sub routines really nicely um code and data separation is another issue um that gets up um and and finally some of these things down here are some more recent discoveries as we're working with the evm working with these um ZK systems and everything else some things that would be very useful and valuable to make sure that we don't have to mess with eof that in theory this version of eof could be the one and forever if we get everything done right the first thing is we're removing code introspection capabilities that means that you can't take code put it into

memory and then deploy that um what you execute and what you deploy come in two different streams I'll talk about that in a slide later down gas observability is another problem let's say we need to change this gas schedule dramatically again um if you can't tell how much gas you're using and can't control some things about gas then there's easy solutions to change those schedules code and stack validation is another important thing um that we can make sure that we're actually putting a real code and that makes it easier to to add things to eof without having to reboot the world if we can guarant guantee that an OP codee that is not used doesn't show up until it's used and the last one that came up in the past

couple weeks that we've been talking about haven't committed to is to maybe prepare for address space expansion a little bit of evm trivia any op code that takes an address will only take the lower 160 bytes of the stack argument and the um top 100 um so bytes whatever is left over um are trimmed and this is used sometimes it's useful in some um AB decoding tricks uh but if we want to use a dress based expansion we need to make space for that and eof would be the right time to do it if we're going to break things that need to be broken for the future let's break them now in the eof container so that's kind of the theme going on there so the first thing is the eof

object framework described in E EIP 3540 um it defines a container format and it's got basically five sections the header the types for stack validation the code itself subcontainers which which is something we'll talk about in code creation this is basically if you have a factory contract that's deploying other uh contracts it's going to show up in the subcontainers and finally the data section where you can store your data and your constant in variables um the next VIP 4200 static relative jumps um fairly simple we ban um three instructions jump jump ey and PC and we add three instructions uh R jump R jump I and we take the opportunity to add a really useful

instruction a vector jump operation which will save a lot of code in things like solidity and Viper compilers they can do some really useful things with that operation 4750 we add functions AKA code sections and this is the sube support solution um code is broken into a separate code sections they're self-contained to support this we need to add three op codes call F return F which is basically your go sub and your return sub and jump F which is basically tail recursion support this this is something that could be really useful um for a lot of recursion Solutions you could jump F into yourself and other things it's something that compiler people get really excited about um Java wishes they have it and we don't so

we're going to put it in eof um and there's also stacky restrictions that are enforced with the op codes when you go between the functions so they actually act like functions you pass in three stack items one stack item comes out you can conceptualize it like that EIP 663 to dup and swap is a really old request to access um the full depth of the um of the stack um right now it's looking like it's going to be a dup end which dupes at an arbitrary depth in an operation called exchange this used to be swap in where you'd have two immediate arguments um but there's duplication like a a swap 23 and a swap 32 are doing the same thing so if we do some me tricks with um requiring them to

be in order of the stack um you can access twice the distance with smaller oper op a codes we may have a a two bite variant of the exchange these are some of the details are working throughout um now the old dup and swap instructions will remain even though we could get rid of them we don't want to disrupt the instruction set too much EIP 7480 um so now we're getting into some of the the higher level requests and this is for um remove code inspection capabilities and this is the read half of that so in order to prevent code from being introspected you won't should be ble to read code that other contracts have so we're going to have to ban the ability to read your own contract code code size and code

copy and also to read other people's contract codes EXT code size exd code copy exd code hash so the problem is we discovered in Shanghai is that um solidity will use this data um to write immediate uh to write constants they'll rewrite their code sometimes for constants for the constructors so to accommodate that um we allow access to the data section from within your code you can load data from your data section data load data load in is an immediate arget variant data size data copy um and you can access your data in your contract and you can expose it to other people if you want through methods um you know it goes in the stack and the data works just fine um now a couple of compatibility things is that the Legacy evm will not be able to use

EXT code into eof contracts to ensure this readability results um there are some standard responses that we have planned it'll look like really contract and you can't read it and also um data star I should have dropped that last line that that is something that's under discussion these may or may not be available to uh there's an EXT data copy the may or may not be available so I should have fixed that um last night the right half of the code introspection capabilities um comes from the creates and as we know when we do creates now we take the entire contract we put it in a memory we wrap around it the memory and we deploy those bytes um that is not

something that's going to work when the underlying execution is not necessarily interpreted evm if you're taking these contracts and compiling them to a ZK circuit um it makes it really difficult and you got to have these like terabyte RAM Systems to generate the proofs when you do that so we're going to propose a replacement called create three and create 4 um where you create your contracts but the code does not exist within the evm it comes from outside of the evm from two different places create three handles that where the eof container contains the code you would be deploying and this is useful in Factory situations where you're like deploying another liquidity pool you know what that pool looks like so it's going to be in the eof code and you're going to deploy it straight from there to get

your factory together and it comes all in one contract and it's all self-contained so you never have to see the code you can deploy it and the other option is create for and that's um where you get it from someplace outside of the the eof container or the evm completely and the initial plan is to have it from a new field in a new transaction type um that's going to we're going to need to see where SSV winds up in the next few months or we're going to need to put a new rlp type to get these transactions uh to get the the contract data in a transaction type and um you know this crate for is a bit flexible we could go crazy if we want with layer twos we could have layer twos that have a small stable of contracts that'll allow you to

do and create Fork can access those but for main net we're just going to do it in transaction typ um we need a new return code to handle adding data onto the end of these contracts and this is something that L of explicitly requested for their um immutable values um so they can if you say that you have a Conant finally to initialize in your Constructor we actually write that into the code that's deployed as part of data at the end of the existing data section so return contract also allows for auxiliary data to be added on to these contracts just data no code now to handle the removed gas observability capabilities um we need to address gas and the call Operations so call code's

on this list but whether or not 7069 advances call code is not going to be an eof it's going to be one of those ban instructions call code and self-destruct or will not be in the oof regardless of how things shake out in any of these other eips but the remaining four operations ban would be gas you can't query how much gas do I have left and call static call and delegate call the reason we need to replace call with call to stat call to and delegate call to is to remove the ability to specify how much gas instead replace it with passing in all the gas you have with some um stien restrictions and and resal restrictions so that it's it's mechanical and you know whether the 63 64 remains or gets changed is all transparent to the contract um and what's interesting is

we're also going to take the opportunity to remove the output location stack operands um to make it even Tighter and smaller because a lot of people just use the return data and there's we we could do return data copy add an OP code that can make things smaller and Tighter so your calls can be um as low as four bytes or three bytes depending upon which variant that you're doing if you're passing in um value or not delegate call is not three bytes delegate call would be like a three stack argument which would really you know make things a lot more compact on uh on calls now the Fallout of this is is a really valuable thing if we need to change the gas schedule and increase Sor operations 5X there's not going to be any contracts in eof that are going to be frozen because you can't specify two

little gaps going on to the next call this is the problem we had back in constant anop and something we fixed in Berlin with the access LS but if you can't specify gas which is by the way that's the default operation of all compilers when you do a call unless you specify gas it sends it all um that if we increase the gas then the solution to a gas schedule changes always then more gas at the top level transaction and finally we get to some of the more just details of of making sure the eof uh is works well 3670 specifies the code validation uh we check things like make sure the jump destinations are fine code sections exist the containers exist um and it also makes it so we can Mak future

evolution of the eof if there is code that is not going to show up we can use op code we can be sure that it's not being used elsewhere 5450 adds eof stack validation um this is some some inside stuff for compilers to make sure that we can do optimizations and interpreters this will allow us to create minimal size Stacks um for contracts rather than creating the big 1024 stack and hoping they don't overflow we can guarantee through code it's only going to consume 10 and we only need to make a stack of 10 and um we can optimize a lot of performance in in the in the interpreters because of this um I'll come back to Mary's discussion um at the end of this but that's a good

point um some miscellaneous notes um there's there's some Corner cases that we need to put in to make sure that things work out well one notable thing is eof and Legacy can freely call each other with one exception eof cannot delegate call Legacy and the reason we do that is because the next point which is self-destruct is banned so if you have an eof contract you could delegate call to a legacy contract that all it does is self-destruct and all of a sudden we have to deal a self-destruct inside of eof so that's why we don't delegate call you can't use delegate call as the escape hatch to get access to functionality we ban inside of eof um and another thing is eof and Legacy cannot cross create your eof factory can only create eof contracts

your legacy evm can only create Legacy contracts this keeps the Two Worlds a little more rational um and a little more safe so we don't have to deal with this big Matrix of what if this happens and what if that happens it's just a lot easier to implement so quick summary on the op codes um there is a net plus two of op codes available inside of e evm um there may be some more coming um there may be about four more coming to accommodate uh compiler performance regressions uh size and um mostly size regressions for code um but the minimum required um the required are these op codes um to address ancar we we're kind of removing self-destruct in Denon um

but in the eoff code you can't even have the op code we can't even have the sweep operation we're just getting rid of it completely um there's none of this games about can you do it in the same transaction um so we have nine operations that we are replacing functionality with to deal with um the improvements we're trying to do with an eof and the worlds were trying to change there are seven op codes that we are straight up removing with no Replacements um gas self-d distract call code PC the EXT ones um and we are adding nine op codes um to to add features that make sense within the eof um Vector jumps sub routines um unlimited dup and Swap and the data

support to handle the EXT code I mean it's kind of a replacement for the EXT but kind of not really um for the code copy and code size um and return contract for creates um so talking about some of the more inside baseball features of what's going on one of the biggest uh issues um is of course testing when you ship things for uh hard forks and I think we're going to have a little bit of a different uh a little easier time a little more well- defined time than some of these larger Network changes the reason is the AVM is fairly self-contained um we don't need to worry about Network interactions we don't need to worry about pairing with different um clel combinations I don't think we're going to need the same level of Dev net and test net and that's

because of the way that we're able to test it um we're going to write explicit reference tests these are the gold standards for are you a compatible evf is do you run these EDM tests um the client teams can help out because we need to test our own code and some of our tests become great reference tests when we test the edge cases the big Advantage we have is this differential evm testing that's been going on um Martin wrote some differential testing Marius wrote some um greo Guido wrote some and they've made some amazing findings and it's been pretty boring recently with their differential testers they've been running them for a while and haven't been finding much um Guido's got some you know what we been able to find for Bas so far is a few performance issues some Corner cases that are really um creative and inventive um that the

fuzzer was able to find um probably get a blog post about some of findings here in a few months once it's h shipped on hader's Main net um but these fuzzers are great at finding these strange problems and um we also have container fuzzing that Martin had written back in December January to test the container fuzzing so we can we can test that um so the big proposal is when eof is that it would be the headliner for Prague and I would think it' be three to six months after Cancun actually ships on Main net is when we would start or actually ship it on Main net my my thought of be we would ship at least three months after Cancun we would um start the testet cycle um but we' be doing DEET cycle as well before

then so bed over three probably so um I think Martin said we can't modify the gas schedule anyway since most contracts would be Legacy so right so this gives us the flexibility for eof to charge different gas schedules um but as far as um thinking outside of mainnet if we had layer 2os that were just eof um they could have much more flexibility in their gas schedule definitions if we had ZK systems that were all eof um they already are doing crazy things with their um gas schedules um uh and self-destruct was used to have consensus issue which some issues don't happen yeah that's why we need a that's why we

we test very thoroughly on EVMS very extensively so it's not that it's without risk in testing the risks are just shaped differently um and ancar in my opinion I would really like to see one more round of is this as Ford compatible as possible regarding gas interection but excited you just brought to mainnet ideally the next for um so yes so if anyone has any opinions on things that need to be addressed to ensure that EOS is maximally forward compatible please bring them up we have calls every um every Wednesday on weeks off of the execution call at about roughly the same time um call in with the evm channel um share all the information that you have

share your opinions now is absolutely the right time to bring anything else up um yeah and there's yeah there's there's still some the best Discord channel is going to be evm and the ef& Discord that's the best place to discuss this so that's the end of my presentation um open for questions concerns comments

Tim Beiko: thank you um okay uh Baron and has a couple questions do you want to read them off

and and uh yeah answer them

yeah sure

Barnabas Busa: so my main question is uh who is the UF champion and who is pushing for all of these changes to happen

Danno Ferrin: um I would say team ifon probably has the strongest ownership of it um I happen to have some slides ready because I presented about this at E Chicago um I'd be willing to slide in that role if if ipsilon doesn't want to but I think ipsilon is the strongest uh has the strongest uh stake in this right now

Barnabas Busa: okay my next question would be uh do we have a spec list ready and is this spec list like pretty much good to go is it

ready

Danno Ferrin: so we have a a hackmd that is a fairly complete list um basically it's complete list we're not adding new features um we might add some things like a jump fi for uh um uh conditional jumps and conditional calls and an EXT code cost but the list of possible ads is really slow and yeah like client basted it and that well that's the full spec right now there's some additions that um we're talking over with with Viper and solidity that might be added but that list is also small there's another list that has the open issues and those are discussed there um I don't have that on hand currently um but if you go into the evm channel and scroll back you'll find

the open issues link for sure um but as far as specs I think the only specs we are missing are um the data spec and the create 3 create Force spec and I think what's holding off to the create 3 create Force spec is we're trying to um get some signal on whether we should propose a field in the SSV or whether we should propose a new transaction type like the blob type um not you know not where instead of passing in blobs you pass in contracts um and so there are a couple more eips that will be posted and also just the whole drama with the EIP split um I hav't been writing eips until we get more on that um because we weren't sure where those were going to land for the for the Prague release but it looks

like the the splits actually going to happen they're just working on Final technical details um can we begin planning e only Dev Nets um so we're about about a month away from go ahead

Barnabas Busa: yeah you you mentioned we don't need like prer Dev nuts for intra but I think I think the fork transition is one of the major question questions here no

yeah

Danno Ferrin: so yeah we can test the fork transition for the devnet um I guess my comment about the dev Nets is um we're not really test we're not adding new network Behavior we're not shaking out Network behavior in the new clients so doing a shadow Fork um really wouldn't do much unless

we're going to inject new transactions and put in new e contracts and execute and exercise the new eoff contracts um whereas vers when we were doing um the merge and when we were doing withdrawal uh Shadow Forks were invaluable and the best way to test them I think so that's you know when I say testing is shaped differently um things that were invaluable for for the merge um I think more more useful is going to be um the fuzzing and um you know probably test networks and I think the best thing we could do is just get everyone to get their contracts when the when they got versions of solidity and Viper that will Emit eof and just compile them down into eof and see if see how things work out there um of course some features won't

work if you're relying on EXT code copying but the stuff that does work you know that would be probably the best thing is to take these existing contracts just probably go through ether scan get all the contracts and just compile them down and just turn on the eof flag so that would probably be the rep the replacement for shadow Forks

Barnabas Busa: yeah my next question would be is any e clients have any implementation of this

EF

Danno Ferrin: since we're not finalized on the spec um no um we did have stuff on big eof that was going to be finalized in Shanghai that was finalized in Shanghai I think nethermind G and Basu had PRS ready that were fuzzing to the same results um so that's um it shouldn't

take too long all the heavy lifting has been written to the clients or in the PRS with just parsing the container and making sure that there's interrupt between the Legacy and the evm and you know a lot of the stuff is already still there we're using the same op code Loops we're using the same facilities to access accounts and storage so it's just wiring those things in there

Barnabas Busa: okay thanks for all the answers

Tim Beiko: um there's a question around ERC so some erc's have tests for contract like erc721 unreceived how would that work without the code in

introspection

Danno Ferrin: so if if it's what I'm thinking it is um it's there's supposed to be an interface where you can send where you call a contract with a certain interface um with a certain fun certain function and if it understands the interface it says yes I support that otherwise it returns I don't have that interface so um when you check for un received you're not actually inspecting the bite code um because in theory it could be solidity doing it could be Viper it could be Fay faking it out and accepting an non-received ABI so the the that preambles for these VAR even solidity versions change a bit differently so you don't actually check the code to see if

you're compatible you call a function that says Hey do you support this and if it understands it and comes back and says yes then you know it's a 721 so eof supports the current framework transparently I expected to

Tim Beiko: thanks uh Ben I don't have that answered your question fully if not feel free to either speak up or post a

follow-up

Danno Ferrin: yeah I think it's ERC 165 is the one I was thinking of so that's got the the standard of how you would call a function to say hey do you support and you would be doing that um off chain typically to test for it um although some sometimes you wouldn't when you're being sent stuff

but

yeah

Tim Beiko: okay yeah and and uh and uh Alex says None of the yd U RC's actually inspect the code of contracts um okay so there's a Lucas has a question I think Dan you sort of covered this in your slides but what are the direct benefits of eof what does it solve the complications that the evm are quite huge so why is it worth it why should we ship it um I know you had a slide with like eight benefits so maybe

Danno Ferrin: go back there so these are the eight themes that we going to support an eof and probably the biggest reason we need

to change some of these things is the core of the evm was written over the weekend you know these are people that knew what they were doing with computer science they done compiler stuff but they only had a weekend to work on it and some of these design decisions they didn't have time to to think about what were the 10 20 year implications of it um and one of the things that I think that snuck in um is the push with immediates and that blocks out the ability to add other immediates and then there's also the segmentation of the code that you can't have code and data separated um so in order to support all that we can't change those with Legacy eof but in eof object framework um we get a format

where that is logical so what this is providing US is an opportunity to get a path to make this rational um to where when we get the broader eof adoption we can slowly tamper down the Legacy um make it more expensive toci been Legacy maybe just shut off Legacy um and get all the features in eof and then we could possibly um figure out a way to transition Legacy to eoff um so that is one long-term possibility um but I think the bigger problem that this solves with eof is ability to evolve the VM in a more efficient and modern way because otherwise we're going to start losing um language development to other systems and that may or may not be a bad thing

um but you know if if it's not the main system that main is using there's a risk um that you know we lose the the that the sum is the greater than the the the sum of the parts the whole is greater than the sum of the parts so yeah there is you know risk in doing this and risk that it may not be valuable but as far as um you know making an eof making the whole combination of ethereum main that valuable this provides a path to to solving all problems yeah so I just don't see how like which use cases would this unlock basically everything this this kind of um unlocks is just making existing

patterns in compilers kind of cheaper but is this really what we're like what what a Mainer should evolve to um I think um I like this idea of having um having like eof only L2 but um then I think in in order to support this kind of we need to we need to completely have these two separate EVMS have the Legacy evm and the the the you have evm and they cannot interact and this will break comp possibility so

kind of a non-starter um yeah I'm just not I and I've I've been quite vocal about it that I don't think eoff is a good idea at all um and um it's just like yeah we're we we're adding some stuff but we can add these most of the things we could add in the uh existing evm and and the things that we can't are not quite worth it for me um then like I haven't really seen a big push from compiler teams really wanting

this um maybe they want this but and um the other thing that I really dislike about it is that now the kind of this verification of the code becomes part of the consensus when you deploy a contract this the contract code has to be verified right um and thing like we can shoot our like it's it's um the verifications as I understand are not that complex um but we might want to do more complex verifications in the future and the thing is like if we if I

employ a contract that can evade one of those verifications then I've kind of totally broken the chain and um so there's a new like it's a new big class of um of consensus issues that uh of pot potential uh consensus issues that we might get with this right yeah um Anar got's hand risen on this question so I'll let him seems like he want to answer some of it or do you want to ask a question

Ansgar Dietrichs: well no yeah I was it's only partial answer but basically to the question of what what what is this useful for and and and and why would we

want want this like to me a a value of this that I think is maybe a bit less tangible but also very important is that right now a lot of the times when we want to make changes we were always very hesitant because it breaks existing code or at least potenti edge cases like anytime we want to do repricing of up codes we have to be very careful and uh with address Bas extension one of the reasons we didn't end up doing is that it kind of it's really hard to make backwards compatible one of the things that would excite me a lot about UF is just that of course it doesn't fix that we have existing contracts that will still have these same problems but once we have this out there and maturely supported with all the compilers we can

tell people that best practic is to start using EF and then at least that means that two three years down the road we can be a little we can start to be a bit more easy with making some comp breaking a small amount of Legacy contracts in a somewhat more aggressive way with repricing and all these kind of things because we have this great new more robust World um that we want everyone to be in anyway so to me it just makes it it's a really nice transition to hey this is the world if you really want to make sure your contracts are long longlasting and have completely reliable Behavior please move over there you know over the next one two years something so to me that's that's very appealing yeah but this only works if if we suppose that eof is the

end all be all of always and I don't see it this way like there like there have been changes to eof even quite recently and so I don't I I think like in five years we will say Okay e of version one wasn't uh didn't have like these five features that we really want and we're going to do do e of version two now and then we kind of like we're pushing all this this work onto onto client teams they have to maintain two different versions of the evm and uh maybe in the future even a third version um and um also like the argument that uh

layer two specific e of um versions would be nice because the L1 teams have to maintain the or are maintaining the the evm yeah sure like L2 teams they don't want to maintain the evm because it's honestly a pain in the S and um so now because they don't want to uh maintain one evm um they're going to push this all this new evm work onto the onto the the client teams as well and uh we have to maintain too so I don't I don't see this as a like just conceptually as a as a great way um

I think L2 teams should maintain their own software and and not really depend on L1 teams kind of providing the software for them and then building like small pieces on top but that's just a personal opinion all of all of everything I'm saying is a personal opinion right

Danno Ferrin: so there's there's a lot of issues there but the one I want to pick out is the idea that you know in five years going to keep adding features we've been adding features to Legacy evm since the beginning we've been dribbling op codes we just added op code two weeks ago but there's two categories of changes that evm and eof would both still support the first set of changes are compatible

changes you drop in a new OP code um that's easy um and there's incompatible changes like say we change what self-destruct does those take a lot more changes so what we're trying to do an eof we're trying to make as many of those incompatible changes at one time so we do it once so the container format ideally doesn't have to change again and can evolve in compatible ways so if we need to add a new profile type section there is an e EIP about evm profiles we could add a new uh header type and that falls into the uh the second point on the left as it would make invalid bite sequences valid so if you had that before you would add it you could now have have it by requiring validation and requiring things um become valid we make sure that garbage doesn't accumulate on

the Chain by submitting random bites to the chain we're not blocking out stuff that we couldn't do before there's the only validation that happens in in evm right now is it run time and we make sure that your uh jump destinations are not in the immediate arguments pushes so we ready do some validation um some jump test analysis but the validations we Define are they're linear time we're charging for them now with with with deploy um and a lot of these decisions that we're making for these compatible changes make it so that all the things we need to add to eof don't require us to change the operating structure and don't require us to change new bite code so it allows it to live there just the same um one example would be evm max if

we want to add modular exponentiation um we can add operations that have immediate arguments on it now which we cannot do in Legacy eof if we want to add a new argument that has Legacy operations we Break Stuff um I couple of my slides here show the story of how if we wanted to add um our jump with an immediate we would take uh stuff that was invalid and all of a sudden move it into immediate data um so we change a jump desk and we move it into immediate data when we break things if we add an immediate so stuff like that is what we're trying to fix so that we can G we can grow the evm in the future um I don't think that you know we're not going to be able to aify the

evm until we aify the consensus layer so that you know the evm is going to be frozen forever is is only going to work once we freeze forever the consensus layer once things stop changing then things can stop changing but this structure allows us to to grow rationally and to be able to do more things and grow in better ways to deal with these new features so

Tim Beiko: thanks uh Andrew's had his hand up for a while

Andrew Ashikhmin: um yeah to my mind a big benefit of EF is that it's more constrained so you have a separation of code and data and you disallow Dynamic jumps so because it's more constrained it should improve

um security of smart contracts and um uh facilitate um uh like verifications um verification of smart contracts either manual or automatic or semi-automatic so I think it's it's a step forward so I kind of disagree with this that we cannot freeze the evm without freezing the consensus ler I think those are kind of different things and at least I like this assumption that once you deploy a contract it's mostly mutable

but I don't know like it it would not be like we are breaking this assumption with with with self-destruct um but I uh I see the need for it and um yeah I don't know I know uh for the evm max I think we can build evx without immediates it would just not be uh super gas efficient and um I kind of that's where we're

Danno Ferrin: going to start losing compiler people if we say you can still do it

just not gas efficient they're going to say well I should just build it in sway or I should use stylus so that's that's the risk that we're looking at I see I understand the risk I have to think about it um yeah it's not a security risk it's more of an existential

K

Guillaume Ballet: yeah that was actually a question from marus I don't see exactly I don't could you detail the argument where it would be harder to um to maintain you know different versions WF as opposed to a

different Fork to me it looks exactly same um I don't think so um like if we change the behavior of an OP code in in different versions of DVM uh yeah um in different versions of DVM for example if we have now one up code that does gas introspection and one up code that does not um in our code that's twice the amount of up codes and um testing kind of

explodes because we have to test all possible um uh all possible versions of it and um if we go like if for example like now we have one call making something up no but uh if we have one call up code that does gas introspection one call up code that does not gas introspection and now we have a new version of the uh we have sorry we have a hard fog that changes the order of arguments for the callop code then we will have to maintain four four versions uh of the uh of the callop code that's kind of my wouldn't you just

change the format and then maintain one per uh per format version

Barnabas Busa: sorry uh okay

Guillaume Ballet: maybe I misunderstood but I mean like I don't see where the four comes from because for me if you change the callop code you would just um I mean we we can also take this conversation offline I'm not trying to uh to hog the whole thing the whole time but I yeah I basically I don't understand the four the four uh the four version I only C2 because one of them would be Associated to one format version and the new version of the the callop code would be Associated to the new to the new format version yeah but then we have then we have a h fog that changes

um that changes The Ordering of the of the of the arguments for example and then we would have to uh either like we would have to apply it to both versions and with this we would have to maintain four versions two old

ones

Guillaume Ballet: okay I get it thanks

Danno Ferrin: I think a more concrete version of that would be a dress Bas expansion um if you have a balance operation one that takes the the 20 by version one that takes the 32 by version um you know that's something that is if we're going to do a dress bace expansion is going to be a real issue and that I think is the best example of how one you might choose eof for things you can't do in evm um

because we can't just you know take off the top 12 bytes of of all the dress operations because there are Avi decodings that depend on the top bites um being ignored and there are some call datas that you can put in that will break if there are not trimmed um with some of the pack call data so there are contracts we would break with a dress Bas expansion and that's why you know even though it's a recent thing that's brought up is what if we want to do add dress space expansion for you know for for um for rent or whatever other use for it um if if we don't bring it in in a situation like this now we can't just break old contracts and with the container format you know we could flag to say hey this one trims this one doesn't that's probably not the best

solution I think the best solution is just from day one to not trim address arguments in in operan stacks and have it be different in eof and EDM but these are some of the things going in um gorgius given this all this complexity is 3 to six month timeline postal realistic um I believe it is because we're shutting down the final features um and we're there's no new features added we're adding you know maybe a few more op codes to address these features and we're going to spend a lot of the time testing and implementing um I have been very impressed with the differential fuzzing work that's been going on and has found a lot of strange Corner cases and very creative ways that I don't think we could write tests to cover so in

addition to writing the deliberate tests um I think the differential fuzzing is going to be a game Cher in our testing I think differential fuzzing and compiling old contracts are going to be um I it's is kind of a different way of doing differential testing is going to be our equivalent of Shadow forks for

eof um ongard

Tim Beiko: you've had your hand up for a while

Ansgar Dietrichs: yeah I just wanted to say um I mean it sounds like it's probably going to be a multi call conversation around whether UF is a good good idea or not I do think basically one aspect of this that came was briefly mentioned but I think will be important is kind of the the relation going forward between layer ones and layer twos and um with regards

to evm governance I think so far basically For Better or Worse it always fell out that we evolve the the evm and then L to in a way almost blindly follow um I think in the past there have been some ideas around at some point maybe layer 2 is just fing off having their own layer two evm standard L don't seem to love that idea so far at least um just B one thing I want to point out in that context is that um k y and I we we recently decided to initiate some sort of layer 2 evm governance call for like more layer two specific um um um topics um that that's going to Kickstart like like

start off next week and then have an inperson event uh during def connect uh I think basically there will be a lot of similar questions coming up from the other side and UF might be one example of you know Bally to what extent layer 2s want to just follow the layer one evm um so I just want to already flag obviously it's too too too soon now to talk about that because obviously that hasn't happened yet but I think this will be a more more important conversation around like Bally how do we govern the evm will we forever have the same evm between layer ones and layer twos um how do we basically merge the interest of these different groups so I just wanted to raise awareness for

Tim Beiko: thanks yeah and uh maybe we can post the link in the chat as well but it's on

the ethereum PM repo um so the call is next the first call is next Wednesday um I believe G you you were next

Guillaume Ballet: yeah I just wanted to give uh some push back on the claim that it's going to take that we could have a for three months after Cancun it's true that um that the the differential fuzzing tools are really useful but if they had they've been around for a long time if they had sped up uh Forks you know just just by the the the magic of their might uh we would know that already and I think U yeah we're we're looking at a much longer time

because I mean this is you know dankun was also supposed to be a fast Fork I don't think if we look at the two options veral and and eof both of them are we're looking at a at one year of work in any case um and the problem with veral is that the clock is ticking uh whereas all those U advantages that have been touted by brought by eof they are very nice to have I I I mean I want to make that clear I am a supporter of eof I just don't think it should be coming before veral because veral we have to go through the transition and the more we wait the worse it's going to get and there's really bandwidth like core

development bandwidth for one team um I don't see the urgency for pushing eof right now especially if um if it is uh uh that complex in in my opinion there should be since this is a format you can have several format version you could deliver um all those features little by little and if eof was a very simple container like if that was the only thing the fork was about I'd have no problem delivering having it delivered before uh before veral but because of that complexity I think it's very important to focus on veral right now and deliver uh deliver

eof afterwards or simplify greatly the scope of of that first e fork and then yeah I don't have any argument against it

Tim Beiko: I guess yeah just to chime in on the timelines like I think historically like 3 months is um like extremely unrealistic like what we've done in like a three- Monon range is like a difficulty bomb push back um I think as soon as you start to have actual features regardless of what they are like somewhere between six and nine months seems to be our our Pace um it's also worth noting like there's a bunch of other stuff people are going to want to do in the next fork and so um you know it it's it's probably unrealistic

to say we're just going to do eof and nothing else and therefore Fork's going to take that amount of Time same thing with veral um and so yeah I I I think it's it's probably a mistake to it's probably a mistake to like analyze it at any level Beyond like just relative complexity like is is veral going to be more work than eof or not um and then you know is as you said is there like more urgency to do verol um because um and and yeah historically as well like over the past couple years it's been kind of interesting where we tended to do like one big fork and one small Fork so like you know we had um 1559 uh and then a couple difficulty

bomb forks and then the merge and then withdrawals was much smaller and I would argue Denon is actually a pretty big fork I don't think it's like a quick Fork the amount of work on the blobs is quite huge um so like yeah coming out of this Big Fork I think it's it's worthwhile to to consider like do we want to move on to something you know really big right now and if there's a time pressure with regards to veral um because of the state growth you know does that like raise the urgency um or do we want to do something that's potentially smaller um and then do veral after that um and I think client teams should start thinking about that uh I understand that like obviously a lot of

the bandwidth right now is spent on on Cancun and so it's worth it's wor keeping the focus on Cancun and and like shipping that before we make a decision about what the next big thing is um at least having it you know started to roll out on test Nets and whatnot um but I think it seems at least on the execution L side that eof and veral are the two biggest potential candidates um so far so yeah I I think if El teams can start just looking into those more closely and understanding uh the trade-offs and and both in terms of like the value they bring and then the timelines um hopefully in like the next month or two we can start having like a more focused

conversation on like what do we actually want to prioritize um and by then yeah we should be rolling out Cancun onto test net so the the the amount of work that's actually focused on Cancun should be should be going down and and we'll obviously have def connect as well where we can spend plenty of time going over both all the veral and and eof uh updates um yeah um if security Maris is that still you yes that's that's still me um I think Ana said something interesting um see he said maybe death connect could be a good

place to have the do we want to go with UF at all discussion and I think just the fact that this is still a discussion means that like we cannot make a we cannot even talk about timelines like we did not there's no consensus that this is happening at all so we shouldn't talk about timelines we should talk about whether it makes sense to have this uh whether um uh whether it's it's a it's a good technical change and if we all say this is something that we that we want um if this is the consensus I'm fine with it um but then we should talk

about is this a priority over verle or not and then we can talk about timelines but talking about it right now where we don't even we we have no clear this is good or this is something that we want um it's makes no sense to me it I I I seem to be in the minority in this cause because I'm the only one arguing against it um but I know that a few people are also not very happy with it uh um so I would like to I it's I know the I know the the ipsilon team and and Deno have spent a lot of time

working on this um but I think it and it's it's it's it's quite harsh to say that after all this time we might not be shipping it but I think it's it's even worse to say uh let's see and and um and then in like we we push it another two years and then we say oh we are not going to ship it after all and so I think it we should make a decision at def connect um that whether this is something that we want and if it's something that we want um then we are going to do it

except for like technical uh challenges um and if we're saying this is something that we don't think is going to happen um I think it's just fair uh for for the team that has been working on it for all this time to have like a clear decision uh from everyone and um yeah I I already talked to the ipsilon team about this and I think it it would be really nice to to all come together at def connect and and discuss in person and and make a clear decision about it yeah I think it's like I don't think anyone disagrees that figuring out if we

want it is is is sort of a a first thing before when uh when we'd want it and how long it could take um I also think yeah it makes sense to discuss both eof and veral quite extensively at def connect um I'm not sure that uh we necessarily want want to take yeah I'm not sure if like a month from now we'll be in a spot where we're ready to like take a final decision um but I I know my hope is we can if if teams can get up to speed on both veral and Dev connect at both veral and eof in

the next month or so that we can spend the time in Dev connect like going deep into both of those as well as a bunch of other proposals um yeah after that we should be a in a pretty strong spot to take a decision um both for the next Fork what we want to prioritize but also yeah if for whatever reason we don't think eof is viable um yeah to to to make make that called at that point as well um yeah I I feel like we've been going on on eof for for uh quite a while at this point um obviously there's the evm channel we can use to to discuss it but

um yeah does anyone have any new topics or questions things that we sort of haven't covered um obviously there's a bunch of objections around you know the backwards compatibility and and figuring out um you know how this works with l2s um is there any other potential concern or or question that people feel we haven't touched on so far okay if not um then yeah so there is the evm channel in the Discord we're going to have the L2 call next Wednesday um I I forget the exact time but the the

agenda is in the PM repo um anything else anyone wanted to cover before we wrap up

Georgios Konstantopoulos: um I have a question on this General set of changes that we're discussing around the overall what is the right way to think about L1 and L2 Divergence for example you implement verticle maybe it's not implemented on L2 push zero is not implemented on L2 eof would plausibly take some time to get make its way on

Tim Beiko: I think that's exactly what we want to discuss on the L2 call next Wednesday um got it and and I think and part of the reason why it's probably worth discussing there is to have L2 people

chime in right like um yeah because yeah I I agree like I I think a lot of people realize that we don't have um a a super Clear Vision there so like at least getting that conversation started with l2's um yeah is is a good start uh yeah and then yeah Anar as a comment like the first step of this is also getting bringing the l2s together to chat about this stuff where there isn't uh as clear of a forum um as for L1 devs um and l2s are obviously way more Divergent than how they approach uh

things so yeah hopefully

we can start yeah I

Ansgar Dietrichs: just want to make sure that people like if if people want to show up next week that's of course fine but they shouldn't expect like it might just be a 1 hour call where 5 55 minutes is about just like you know what weekday do we want to have this call and who should show up and these kind of things and then maybe we have five minutes of briefly touching upon already like how do we see relationship with ler one or the l two relationship ler one or DM but it won't be a big Topic at for next FL because it's just too early in the process yeah

Tim Beiko: and then yeah we're also planning though a full day at Dev connect uh as part of the L2 days uh focused on this topic as well so I

expect in the next few weeks there'll be uh more information coming out on that too um anything else before we wrap

cool well

Tim Beiko: oh yes please can you can you make sure that we all get uh that we all get invites to those um to those events so that we can participate yes if uh so I mean all the L1 team should have events uh for the L1 workshop and then if anyone wants to join the uh l2l one day um so you can apply publicly I think

it's the L2 beats event um but if you have an issue uh getting in or getting a ticket and you work on L1 um yeah I guess pin me and I'll try to uh to help get you a ticket thanks or just tag L2 Beats on Twitter and ask them for one um anything else okay well thanks everyone and talk to you all Monday on the testing call

thanks him thank you thanks thank you thanks every

you J

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.