All Core Devs - Execution #95

Transcript

hello and welcome to ethereum core developer meeting number 95 i'm your host hudson jameson we have a jam-packed agenda for today um if you haven't already uh check out the agenda there's a note from me and uh james hancock about yolo v2 uh and there's a list of eips that may be up for consideration for yolo v2 based on feedback from last meeting and and various chats since last meeting so that's going to be important to look at but let's go ahead and just go to the main agenda where we're going to be addressing many of those eips in general the first one is i have potentially

removing gas refund but i think alexi did you say in chat to skip that one or another one uh yeah that one but i you know if you want i can just give one minute summer yeah sure we're not gonna have a discussion but uh it's just i just say why i i'm not ready yet for it for the discussion yeah go right yeah so okay so something came up that i didn't appreciate uh recently uh so it came up yesterday actually so um i was always unconcerned about uh things like gas token and uh chi or whatever you pronounce it and so yesterday somebody gave an idea or somehow i came to the

idea that i started to look at the transaction pool and i saw quite a lot of transactions which were essentially minting like they were pending transactions and they were pending to mint um qi tokens or gas talking too and they were set at different prices and so in my mind that imagine that it's like a kind of order book so this is how i realized that transaction pools is basically like one-sided order book where your bid for the um sort of for the for the gus prices and then i sort of realized that you know if it was a a order book then essentially those orders placed uh in a particular uh placed in particular orders are to

make sure you're basically by the dips like in the traditional or two ways order book you would uh if you were like a whale or something you would put a lot of um a little bit all orders so just in case that the price will fall and then you just scoop those uh scoop those dips basically and i thought the the same analogy could be applied to this minting of this gas tokens um and but then of course i realized that there's a complication there usually on the exchange you can cancel the orders pretty much at no cost but in a transaction pool in order to cancel the order you either have to replace a transaction with another one with the with the higher gas cost

which will divert the funds and then you have to pay 21 000 um gas and multiplied by the whatever gas price is or the other way potentially to remove your transaction from a pool is essentially spam the pool so much that it will most nodes will actually push it out which i don't know if people are using it but it just occurred to me today um and so somebody said in in the chat that you know if there's the case that people were just putting the a lots of bids for the lower gas prices um then at some it might be that this would be the reason why we'll never be able to lower gas prices because as they get lower the kind of

people buy the dip and then the price go high again um that would be kind of okay but then i started to look at the magnitude whether the historically the the kind of how much gas has been um captured by the by the minton or those tokens uh and so i only looked at the qi token for the last 100 days and so far i found that the um the magnitude wasn't consistent with the basically assertion that this is what causes the sort of the gas price to rise because i think is the minting of the qi token consumed anywhere between one to two percent of all the gas spent on

the blocks but i would like to just to see more and so i am trying to get more kind of detailed data to see whether the minting is actually happening on when the gas price goes down so let's say that if gas price goes up and there's no minting but then the ghost price go gas price goes down there's minting but even then i don't think we are actually in the magnitude where we could sort of blame this effect for the sustained high gas prices so that's it so i hope to come up with more data later okay thank you very much um does anyone have any quick comments but before we move on this will just be continuing discussion and they'll get

in the not getter chat no longer get our the discord all core devs chat otherwise okay thanks alexi i just realized i screwed up the agenda i had more things on here that were part of the eips that we listed below uh and it got screwed up so i'm gonna fix that as we're going through and then i'll let everyone know when it's refreshed uh like e is missing and a few like item e and a few other things are missing so i'll fix that uh um before we get into that i want to do the note about yolo v2 in berlin because the next three eips are related to that so can i do that first yeah go right ahead james that'll be great while i'm fixing this

uh yeah so i've i get a lot of questions about berlin and timing for berlin and the reason that i haven't talked much about timing for berlin is because the first step is to get yolo v2 together and then yolo v2 will decide what will go into berlin and there is there is the possibility that something goes into yolo v2 and doesn't make it into berlin so when we're talking about eips that could or if or not that are trying to go into yolo v2 it is possible that they go into berlin but i want to be very clear that it doesn't mean that these eips are going into berlin but that they're being considered for the test net first and for client

integration testing and then that will be used to determine their inclusion oh you can can i just have a small comment is it possible to uh to call it like berlin v2 for example instead of yolo v2 because that might be a bit more consistent uh i would rather not because i don't want the clients one to write in berlin into their client code and it isn't there are things that could go into yolo and wouldn't go into berlin at all so i think conceptually i'd rather keep them separate like one is one one is the hard fork that will be going into

maintenance what yolo is is it's an integration test net where clients can all build something and then make sure it works together but they could decide not to have it go into berlin or not or go into a hard fork at all like uh like a an example is the general purpose transaction types one like it would be very unusual to include two two seven one eight without also including a new transaction type but we could have two seven one eight be added into yolo v2 with a dummy transaction type so that all the clients are working have the same code together and and integration testing can start happening

so there there just is some nuance that i don't want to set expectations the community that this is a list that is going into berlin but we are moving closer and getting closer to berlin and i and um i don't want it but what are we going to be calling the test net after berlin i mean is it going to be some other city name after that the client integration test nets we'll just do a yolo v3 oh okay we could rename them to something else but the the intention isn't is to do client integration testing not to do uh main net testing

because i just saw that if i just started if we if we start to use the your the name yolo for the test nets then uh can we just use something which actually says something like dev test net or something like that instead of yellow i don't i just don't i don't understand why we have to use the name yolo for this so [Music] so for the yolo um which is maybe a kind of flippant name but uh i uh my the way i see it is that when we define yolo v2 then we won't bother with like what's the order between yolo iran and yolo v2 and how do they interact with just

override yolo b1 uh put yellow v2 in its place and then guest will no longer support jolo b1 and just override and that's it's i mean we could name it ephemeral blah blah blah but i think it's good with the name which clearly spells out that this won't be long time supported okay i see agree with that okay was that all you needed to talk about james for that one unattended but that so as we move forward talking about that's the context i'd like everyone to remember okay sounds good to me um

are we cool to move on to the next one oh james you cut out if you were talking button is delaying itself uh yes ah got it okay uh up uh refresh the agenda i now have better stuff in there uh links and more explanation on the eips um okay so eip 2718 type transaction envelope um this one is from mike zoltu and it's in draft status right now this i believe is not wait is this um eligible for inclusion james uh i don't think it is but it it should

be applying to me i don't think it's 2718 is that both for inclusion oh yeah at least that was the decision and i think it was 92. yep yep like lion's right okay great uh micah are you on the call and able to um discuss on mike oh i missed all the chat over here if uh okay micah are you on a mic no mike okay um so for that one does anyone want to speak on that or if you want to do a quick paragraph typed

up micah do you think i could speak or piper could speak uh i have a question sure sure martin so um there's this proposal to that access list in transactions and i think that got started out trying to be one of these type transaction thing and then mike commented that it's it actually isn't uh if i understood it correctly and i'm not really sure why that is so um why it's not considered to be in line with

this specification mike is finding a mic but until then is there any response that light client or piper can provide i can only speculate as to any conversation you had but it may have been as simple as that there are no formats defined right now that define an access list that 2017 2718 is purely a format for giving us extensibility in the transaction layer so you could implement i guess a transaction type that had an access list but i'm not aware of a 2718

type transaction that does that and it looks like maybe there is one i see things flowing in through chat maybe 29 30. um martin does that maybe answer in the direction of your question so 21 29 30 was the one i was referring to and i think yeah mikey made a comment on the pull request um yeah made by misunderstood i would love to if someone gives an overview why what's cool about this yeah so mike is about to get a mic um until then also note that item f is discussion about combining some of these eips

into a new transaction type uh potentially and i think that might solve some of the confusion uh since some of these may seem to overlap if that's kind of what you're implying until then let's just let's go ahead and do this piper do you want to give an overview of this real quick about what it is just for everybody yes uh so keep 2718 type transaction envelopes uploads i'm getting feedback here you're good now cool okay uh so it essentially changes the the format of the transaction to have an

outer envelope and a leading uh integer that is the type of the transaction so rather than the transaction being an rlp list of all of the things that we think of as transactions um what we do is we add an extra list around it um micah if you want to jump in and take this you are more than free to sure can you guys hear me okay yes uh so yeah so the as piper was saying it's just a envelope that makes it easier for us to have multiple transaction types so previously we've always had one transaction type i believe through all the history of ethereum but we currently have i think two or three or four eips that want to

introduce changes to the transaction and so the initial idea was rather than trying to guess what kind of transaction type it is based on how many elements it has which is of course prone to error because if you have to happen to create two transaction types that have perhaps a variable number of elements or something you can get overlaps and you have replay issues where you can replay one transaction type as another so a bunch of headache is involved if you have multiple transaction types without a mechanism for distinguishing them so the idea is is to just create an envelope that just all the envelope has is just an integer that says what transaction type it is and then a single payload field rl rlp encoded just because that's what we use everywhere else and that payload field then is how you interpret that

is dependent on the initial integer and so you now have multiple transaction types it's very easy for the clients to figure out what they're looking at also in theory you could have i don't know if we'd actually want this but in theory you could have some client that actually only speaks certain transaction types and they can just look at that first field and be like oh i don't know what that is so i'm going to drop it from my pending pool or whatever i don't think that actually works once you get into runtime but with some of the eips 1559 stuff we've been talking about there is maybe a possibility where we're doing like transaction type upgrades where some clients may only speak the newer types and they may not actually understand the older types and that kind of ties into what it likes you're saying with having clients that

don't actually know the old evm so similar thing again i don't know if we'd use that as a feature but it's there so yeah just trying to simplify the addition of new transaction types so it's not a headache for every client developer every time i want to add a new one so how do you how do you ensure that i mean if three transaction has this opec block [Music] the thing that is signed um i mean you you wrapped it with something else and how the insane yeah yeah so the i think i know we're getting out here the for the legacy transaction type so we for transaction as they currently are we

will wrap them just as they are so we won't change the signature on them for every other transaction type that happens after that the idea is is that you should always include the transaction type number in the signature and so that way you can't run into this replay problem where you can have maybe where you have to worry about okay well the signature of this maybe kind of aligns with the signature of the other one because you should always be signing the trend the transaction type as the first item and so you shouldn't have any overlaps with signatures but then the signature is essentially part of the envelope not part of the payload so the signature is included in the payload it will sign a part uh sort of yes or no so the

signature is included in the payload and the reason we do that is because we want to make it so future transaction types could use a different setting algorithm or they could be a multi-sig or they could you know do something totally different besides signatures like we're not just asserting how you have to sign things or how you have to assert legitimacy signatures start by hashing the message if you you want but basically what you wind up with is you have this outer identifier and then you have a payload and first thing you have in that payload must be the same identifier so why not just skip the outer one so we we could definitely if it's desired we can

um we could get rid of the the inner wrapping however that does mean that we will be stuck with rlp for all future transaction types the goal is having just the opaque payload as the inner one was making it so you know for now we can use rlp for the inner but if later we wanted to use some other something else for uh on the actual encoding we could the they deal with the the signing is when you're signing you will for for example 2711 implements this and so the thing that you sign is the envelope but you store the signature inside the payload and this works similar to how transactions work right now where the transaction that you send you know it adds the signature into the thing that you signed and so it ends you

appended on the end just like we do with the current transactions and so it is a little bit weird but it's not out of the ordinary compared to the current system i don't agree because currently we sign a transaction and we append the signature we don't sign the there's no envelope whereas in your case i sign something and then i embed the thing that i the signature into the thing that i just signed right well so like the way that i think about what currently happens is that when you sign like in the current transaction type when you sign the transaction you're basically signing the transaction but like you're signing everything except you pop the signature itself

off of the uh off of the rlp list and in a yeah 27 18 transaction like when you figure out what the signature hash is like theoretically there could be a lot of different ways to figure it out but they would all basically just involve kind of either popping off or zeroing out or doing something to kind of take out the signature from the uh from the payload i wanted to just read out thomas has a comment from the chat that you could sign and then extract some of the signed as designed makes sense one is protecting against replay the other gives a hint on serialization i don't know if we want to i hate taking

up too much time so let me know if you guys want me to stop but the one argument i would make that this is effectively the same is because the thing that you sign you actually are signing the rlp included or the rlp included transaction which includes the length prefix which includes a number of items and the thing you sign says there's six items but then you jam three more in for the signature and then you change that first number the length to nine and so we are already doing this thing where we're actually changing the thing that we signed after we sign it because we're adding the signature into the the thing we signed and where you see that is in the rlp length prefix because that just staged from a six to a nine for your current transaction

yeah fair enough okay so we've gone over this one a bit um i think people mostly understand how it is um one thing that i want to suggest this was talked about at a cat herders call ethereum cat herders call um there's this idea that during times in the core developer call when there's a lot of questions around something or maybe two similar eips or things that are um not maybe conflict maybe conflicting ideas or things that need more like clarity to um have some like a breakout room in the discord where we have one of the cat herders

organize the people who are around those eips and people who have commentary and collect those people into one chat room to chat it out over the next two weeks before the next meeting so it doesn't have to happen during the meeting not that it's not that it's not valuable to happen during the meeting but um you know we only have so much time etc so does anyone have any thoughts on that as far as supporting that any ideas that that might go wrong or anything like that sounds good okay it makes perfect sounds okay great so let's go ahead and go for that

let's move on to the next eip so people can kind of talk about it and then um i'll go ahead james um would we consider including it in a yellow v2 as as a group would that depend on the rest of the discussion around the other transaction types uh in my in my opinion no okay so it's it's not one thing that because you on number f number f on letter f it says general discussion on the idea of combining some of the eips to create a new transaction type so if that were to happen then it wouldn't be in yolo so i was thinking or is that not one of these that would

be included i don't know i think i came up put that item up there and my like the things the transaction types that i had in mind were actually were things that would be intended for inclusion after berlin so like i think i i had in mind principally like account abstraction in 1559 and uh one or two more that are not expected to be in berlin territory got it okay my my suggestion here is that 2718 not get bundled with anything else so that we can get it in as soon as possible because we have all of these other

things that are going to want to build on top of 2718 and it would be ideal for us to get 27 18 out the door with minimal complexity so that we can essentially get it out get everybody on board with it and then start building on it in subsequent hard forks excellent okay it's one of the things that are holding back 1559 development because if this was accepted you'd have to redo certain parts of the implementation but they can't do it until it's implemented so they know how to redo it so this would be good for berlin or good for yolo at minimum it would be good for yolo and if there was another transaction type going into berlin then it would be good for berlin but it's at least good for yolo because

then we have client implementations that people can build around okay so your question james was can we put this into yolo is anyone heavily opposed or heavily for or whatever yes i am strongly for putting it in the soonest hard fork i believe it's simple enough and that implementations are underway or beginning to be underway from a consensus point of view like introducing 2017 is uh right it's not quite a no it's not quite a noah because like you would still have the the transaction type that just has a wrapper over the existing one right

uh correct clients would need to update how they are sort of handling transactions at the network layer and it'll make some minor modifications to the header in the sense that the computation of the receipt and the structure of the receipt changes slightly as well so um it's not it's not utterly trivial but i don't believe that we'll find out soon once people start implementing whether or not there's anything hiding in there but my my gut knows that there probably isn't in its first one is it is it not it's not backwards compatible so once it's introduced there's no other so the you can't have like a unwrapped transactions of legacy type

right that would be only if it went to maintenance if it was on yolo we could still destroy it no no i'm talking about mainnet so i so what i'm basically i think certain proposals in the past were were kind of got complicated at the stage when we needed to decide how the actual transitions going to happen um like at certain like because basically what the the network nodes have to do they talk to each other all the time about the transactions and then um sort of it doesn't it's not necessarily synchronized with the block time so it's like they can pass each other transactions like i'm starting a node i'm downloading some transactions from another node

and then this block hardware block happens i said oh i need to change the transaction format now so yeah so that is mentioned in the arp the current eip says that on the fork block you will need to do one of two things as a client either purge your pending pool or upgrade all the transactions you're planning to pull to the new type and individual clients can choose which of those options they take but they will need to do one of those as currently defined and so there will be no no more over w p2p there's no more sending legacy transactions unwrapped you have some wrapped ones and um but alexa does make a good point that i don't know enough about the clients to say whether that's going to be a problem so that would be something that would be good to get feedback on

those numbers should be very simple to generate just the time it takes to re-encode that's the average size of the transaction pool worth of transactions in the new type i suspect it is not actually that long seconds maybe and it's something that would be a lot easier to test if we had it on yellow v2 sounds like people wanted on yolo v2 so i think we can say that's a decision made unless anyone have any objections before we move on and the great thing about this is if it doesn't work out we can pull it from

the next yolo v3 or whatever else okay uh number c uh eip 2929 gas cost increases for state access opcodes um that is vitalik and martin yeah so i guess to give a quick description of the eip it basically increases the gas cost for first time accesses within a transaction to any particular storage slot or to any external accounts including using calls or using the exed cop opcodes or whatever uh to either 2100 for a storage slot or 2600 forum in account um and the

justifications for the core justification is basically mitigating against denial of service attacks and making uh gas costs kind of more accurately reflect computation time and so the um the blocks that take the longest to process or the i o heavy ones and this basically recuts the amount of io that a worst case block can have by about a factor of three um the other nice uh property that this eip has is that because it only charges for first time accesses and accesses to the same thing after the first time within one transaction uh dropped to a cost of um only 100 there's a lot of like it turns

out that from some numbers that martin or martin ran on and uh the girl i think it was the girly test net so you know to take them with a grain of salt but they but they still reflect like real code that um that people are writing and running and it's looking like uh gas costs um of average applications would only increase by about two percent and this like this sounds uh like very um optimistic and crazy given that we're talking about tripling the gas cost of a major function but and if the core reason why this happens i think is basically because like first of all a lot of applications

are written very inefficiently and they just end up loading the same thing many times um second there's some ins i think solidity it's standard to do an ext code size or before you call um and so the gas cost would actually only increase from like 1400 to uh 2600 instead of from 700 to 2600. and then there's a lot of use cases like erc20s for example where you ask a load and then s store the same thing and the gas cost of those would uh actually slightly go down under this eip uh so basically it fairly kind of surgically targets making expensive the thing that needs to be made expensive but

in the numbers seem to suggest that gas costs for average usage are not going to change uh change much at all um so that's uh kind of the core of what the eip does and 29 29 30 which um introduces access lists is meant to be a a potential companion to 29.29 and the reason basically is that you know if any eip that increases gas costs uh run runs into the risk of causing things that work before to not work anymore and the previous round of gas cost increases uh 1884 ended up i think breaking like a couple of contracts

so if we really care about minimizing uh those risks as much as possible then 2930 basically it allows you to pre-pay for the gas cost of acts of uh accessing transactions or um or accessing accounts or storage slots um by yeah putting that in an access list and so everything from there will just kind of pretend as though the gas cost of accessing things is 100. one thing i forgot to mention is that the gas cost increases and if exempt calls to pre-compiles and calls to self so it actually i think ends up superseding a couple and including the functionality of a couple other eips that people have

been trying to push historically okay um are there comments on this yes i have a comment so i um looked at it uh more closely a couple of days ago and yesterday as well so it's so in the beginning i think it was quite a simple proposal right it was like four things but of course later on it was expanded to include certain exemptions and the both the biggest the kind of thing that was added was the to exempt the um kind of the repeated access uh and uh

it's something uh new that has been added to the i guess to the not to the evm itself but the to the thing around the edm uh which is basically now to maintain the the sort of the read list the read access list which we did not do before um so because at the moment we only maintain a right list for this eip2200 so but now we have to maintain a read list for the accounts and read lists for the storage which is yeah it's a bit complex more complications so um i would generally i understand the motivation for this but i would generally see this as a not a correct solution i would say and the correct solution

that i would see is the combination of two things is essentially first is the increase the gas cost as you wanted to but in order to address the problem of like how do you make it viable instead of introducing this relatively complex exemptions you can introduce a a specialized primitive to address this issue so that you can kind of cache these things using the evm code rather than embedding it into the kind of in the evm to make it uh it's like um you're adding like a cpu caches um inside the cpu like level one level two level three

i mean i know that it might be a bit longer process uh but that's basically my opinion is that it's it's a kind of goes into the same vein with the as the eip2200 which i was opposed to and i my alternative suggestion was to introduce the transient um storage um and the main objection was that all the people have to like rewrite their smart contracts and they would never do that but as we saw recently they do that all the time and they migrate and it actually happens so so i don't really see this if there is a correct primitives in the evm to make these things viable they probably will use it

and i think like i don't know i definitely rate the complexity as being kind of i guess lower than that and my basic uh like the place where i'm coming from is basically that like the thing that this introduces is like that this uses is this kind of concept of transaction-wide global variables and there's like yes transaction-wide global variables are tough and like you know we have to deal with with like the rules for reverting them and so forth but we've basically already figured all of that logic out so like for example we have um refunds which is a transaction-wide global integer we have self-destructs which is a transaction-wide global set so it is implementable kind of

entirely using existing data structures um now i like i mean if there is a proposal for what uh what alternative solution there is and that can um and if capture behaviors around like say ex decode sizing in accounts and then calling it while up and the uh paying the gas cost one so i could be interested in hearing it but i just the my instincts that like there's there is value in having this out in uh kind of the fairly short term uh and basically yeah my main proposal for uh for any of these

uh sort of things to uh for so basically the problem that we're trying to solve with these exemptions is that obviously if it's within if an information is kept within the same execution frame then you can simply keep it on a stack right so you don't need exemptions you can just read the stuff and then you keep it and then you reuse it from the stack rather than re-reading but what the problem that you're trying to solve is that what if the you are reading the same information but from the different execution stack uh from the different like so from the sub-call so let's say that this uh kind of this particular um you know xcode cache was called in this execution frame but then you code something else and then it calls the same execution sorry it

calls the same contract or account then you basically give exemption and i have a so first of all does this really is this really important my first question is that do people actually do that um quite often maybe they don't because i don't see the point of doing it so much and secondly if they actually do that i would rather again introduce the the mechanism for that rather than basically what i'm you know it's very rather than making those operations more complicated uh you know i usually i was against uh introducing a kind of really sophisticated gas pricing rules for op codes

uh and now they're becoming even more complicated uh it seems especially for the read operations so i don't quite agree uh one thing you mentioned is like do people do that and like vitalik mentioned solidity does it every time you make a call it doesn't exclude first and then it does the actual call and in that in many cases the actual cost of that x codash plus the call do not actually equate what's going on under the hood and we're not actually adding another cache layer here where what we're adding is just um

boolean basically have this been accessing in this context or not and it's i think it's simple the mechanisms of this eve are simpler than the net store gas changes we just crack their origin value the current value and do juggling with those variations of what they can be implementation-wise this i thought it actually turned out pretty i mean not trivial but at least not too hard actually not too amazing and another thing to keep in mind is that nick if we're talking about implementation of alternatives that

would actually require contracts to use different primitives than like for example if you want to get the gains of uh not not double charging for an s store followed by an s load which is what erc20 tokens that do to do twice in every transaction then like you pretty much have to redeploy every year c20 tokens so okay so yeah so i i was going to say that my main concern was not about the performance of this stuff because i think performance could be achieved pretty easily my main concern was about obviously complexity because i did find that i mean as martin said it probably a different case but

i did find one of the reasons i was was really hating the self-destruct and things like that and then um is because it's just enormously complicated to get right especially if you want to modify that code a little bit and things just start falling pulling out and so the this particular eip i guess you could simplify it by saying that hey did we lose alexa oh there we go he's back yeah so yes i think that's oh yeah

actually i i have uh i just pushed on my internet cable so yeah so basically if we could say that this um these um this kind of cache that doesn't it survives all the reverts then probably it will be easier because a lot of the complexity comes with or what i have what happens if i do this but then i do undo that and then do it again and so forth do you think that is specified already uh like these are things that we've already done is the thing right like we already have a transaction-wide set which is like basically which is like the list of self-destructs and then we have an integer which is the reverse and i mean like we basically ironed out all those consensus issues in 2016.

i don't know yeah and alexa i totally share all those concerns and that's why i did an actual implementation of it to see how how bad it would be and how invasive it would be um so i urge you to take a look at how it became in the end okay um i mean it utilizes the same things that we already have for rolling but the journaling mechanisms and rolling them back yeah the thing is i wanted to have find a way not to use a journaling mechanism uh and this is where gil got really complicated because i did for so you know i do believe that the journal mechanism

is itself too complicated so but yeah i will try um great i'm just time boxing this real quick um if you can move this to discussion on the magician's thread and if you want to request a breakout room um and the discord for this for further discussion uh just come to me or pooja or edson from the cat herders and we can set you all up with one and get people corralled in there um so thanks for that one um that was 29.29 right yes so 2930 would be optional access lists uh and that one is also vitalik and martin

yeah so and i brought up 29.30 just briefly when i'm talking about 29.29 the idea is basically that it allows you to prepay the the higher gas cost for accessing storage slots and addresses for the first time and this is intended me both as a mitigation to the risk that uh 2029 would uh break contracts that have a higher gas or that had that rely on fixed gas limits um which they're probably there likely aren't uh aren't many but but maybe a couple it's kind of similar to what we saw in 1884

and it's also basically a stepping stone toward having that access less infrastructure in there which could be used for other things okay uh any comments on this real quick is that do you want to uh consider them for efi or is it too early yeah is it at that stage um i mean the eip itself is not super complex and like if we want to have one transaction type um i guess so what what's the calculus like one thing is that if we want to have one other transaction type along with the

2718 then this is probably the simplest one to include the second thing is that from a perspective i'm the perspective of like if you really care about making sure that 2929 doesn't um end up like breaking any any existing contracts then if you do 29 30 at the same time then you're completely fine if you delay 29 30 by one hard fork then like basically those contracts could just be accessed after that second hard fork i just like to mention also that i mean um i would love it if you could spin up the network uh with this if some other one other client would also care to

implement it then we could just try it out and see if the implementations are correct and i thought i think it would be really good i'm all for for having it as yellow v2 or just some little tiny i don't know another mindset or whatever yeah i was going to say if perhaps that means it's a good fit for going into yellow v2 for just that purpose yeah and we actually skipped asking that question about 2929 but it sounds like 2929 and 2930 would be a good combo to put into yolo v2 am i reading that right or would that not be good uh i'd say yes but i don't i want to hear others

thoughts on that i feel like it would be simpler to have it all in yellow v2 rather than manage these two test nets in parallel um but it's not a super strongly held opinion um would oe uh nethermind or baysu do you all have strong opinions on implementing these as far as uh either complexity concerns or um kind of roadmap concerns for what you're doing right now would this be something you'd be cool with putting in yeah i was thinking about like um if we stop filtering those then yellow v2 might be so big that would be hard to implement everything

especially with the assumption that only some of them will go to the actual production chain managing um i mean i like most of the proposals and i understand why they are introduced um not super convinced yet by the optional access lists usability at this stage without anything that that follows up and i think this will be redesigned a lot before we actually start using it but maybe maybe i'm wrong here um i mean not particularly you would like to see 2935 in the mind for for other reasons [Music] yeah everything else seems to be

relatively simple or we already have it okay uh anyone else besu or open ethereum or even or actually trinity too sorry i forget that sometimes um sorry sagan what's the question oh the question is from what we've talked about so far so 2929 and 2930 in particular uh are there concerns with complexity or implementing this into something like yolo v2 from anyone's perspective um i honestly i cannot answer this question

before looking at more deeply into this eve myself so i can't answer right now um since we're having to since we already decided yellow v2 should probably have 2718 and that's going to take some time to implement anyway and hash out a little bit in the comments uh let's yeah let's let's do 29 29 and 29 30 on hold is my suggestion james do you have a thought uh i'd like to just put them in as trying to get into yellow view too but not accepted yet yeah yeah that's that's kind of what i yeah that's that's that's what i was implying yep so 29 29 and 29 30 we'll go on the list of stuff to figure out if we get into

yellow v2 cool 27 27 18 is yellow v2 currently the next go ahead i was goodness oh sorry yeah i was gonna say like i guess based on thomas and vitalik's comment about 2029 and 2930 2029 feels like it might be something we want to do like like it's easier to say it's it's in yolo v2 because if we put it in like this awkward in between states then it becomes hard to figure out what is yolo v2 so i i would push towards having 29.29 in in yolo v2 and then for 29 30 we can just wait and see

um and and you know worst case if other things are more important or come up and whatnot i we can deploy it in the next upgrade and it's it you know it is a possibility um yeah uh thomas is saying the same thing in chat on about 2029 so i i i'm fine with moving that in as they said cool i'm good with that anybody else so it's a which tools have been or will be changed to support the new transaction formats and more importantly the optional access list um [Music] because it's one thing that clients support the feature in the the yolo test net um what ways could devs and users submit transactions

which tools are going to support these so i can speak on yeah going good micah i can speak on 20 27 18 real quick so the transaction types the clients can do the upgrades for type tran transaction type zero and so for transaction type zero so which is the legacy transaction type applications that are talking over json rfpc can continue speaking the exact same protocol they've been and then when the client receives that over json rc pc they would upgrade it to the new transaction type zero envelope transaction and then send that over to p2p so only ethereum client should need to do 27 18. once we start adding the other ones in then yes we'll need to

get app developers will need to integrate and we'll have need to have a new json rpc endpoint and stuff like that but just for 2018 app developers don't need to do anything json rpc shouldn't need to change for when we're only supporting the lexi type rap martin did you have something or was that what you were gonna echo uh no i was gonna say that basically for for the emergency case that you need to unbreak a contract flow you need to add an access list there doesn't need to exist [Music] tools that i mean all the tools don't need to support access lists as long as it is possible for someone who's somewhat technical

to use a tool that support that has it now with one more general rollout that every everything uses access list because it's cheaper and we have so a little bit of rebate on the gas there yeah it of course will need more support and all the various tools that people use to make the transactions i just mean the point of having it on the test notice so that it can be actually tested tested across the client so there needs to be some kind of a tool which supports the access list option right yeah well basically i mean i get any client which has its own key handling and transaction creation

uh i'm not that well versed but i i mean jeff has it i know the parity has it i suppose that the other guys the other notes has it too they would probably build something so go go iteration would just have it the transparent transparently added um to the rpc method yeah the same transaction i guess yes how would that be ready for the yellow v2 is that something we should plan for um yeah i mean i have implemented the first part which is the

changes in consensus i have not yet looked at actually implementing the the new transaction type so i i can't really say but i would suppose that yeah if we do the the new transaction type but then we also have to add the new endpoint to create such a transaction but i don't know how long that will take because i haven't done it yet and just the last question on that is there any kind of test suite for transactions today um in the ethereum tests yes there are transaction tests i think they were kind of introduced when we change the transaction format

with e.525 so at least we could have a set with the access list okay any other comments okay so 2929 going into yellow v2 2930 still discussing the next item on the agenda is eip2315 simple subroutines for the evm um that one i believe is already no wait that is not in yolo yet right yolo b1 you're saying it's not a yellow

v1 okay yeah it is it is oh it is one okay so that'll just go over into yellow v2 it looks like um so i don't even know are there any updates to that eip i think that was greg's and martin's uh well the only update i have is that we did write the custom first serve targeting subroutine and the subroutine implementations and that particular factor has not yielded any results uh as in you know finding um yeah so that's a good thing yeah yep okay great uh we'll move on okay i

didn't quite hear what you said martin i said that there was a custom poster written to target the subroutine implementations and yeah found no issues with the implementation and there was one last feature we were discussing on not jumping into subroutines which which i'd like to discuss if it could go in i'm a bit more a bit more liking it than i used to i recently read over everything that was written about it okay is that something that should continue in the magician's threat in your opinion

yeah i put a i put an entry there to get it going again okay great so that one notice yeah so i'm going to say for this one i'm taking notes on some of the decisions made so i'm going to say for the simple subroutines continue discussion and ethe magicians okay the next item is the general discussion for combining some of the above eips into a new transaction type i know that uh light client and james were talking in the zoom chat a little bit to clear things up on that um what came of that is this still an item we need to discuss or are we kind of clear on it i don't think we got to anything clear

but i also don't know if we have the time to really get into it okay let's skip it for now because we're still [Music] that might be something that coalesces naturally as we have the breakout room and stuff like that yeah i'd like to hear that that's all right with client uh live client before we move on to sure yeah yep that's fun okay um next up we have eip 2935 save historical block hashes and state uh this one is vitalik yeah so and i can make this quick the basic idea of the eip is that you just stick the block hash into the um

into the a the storage of a particular contract um before a pro you stick the uh the hash of the previous block into a storage slot before processing the current block and so you just have a contract that just maintains an ever-growing history of storage hashes and so very simple and dumb uh just way of ensuring that blocks have a quick merkle path to all historical blocks at least since the eipos introduced um i mean in terms of state size growth it would add something like two and a half million states or storage slots per year which is i think like a gain of relative like one percent relative to the occurrence of storage size so it's

actually not not even particularly large and and the main benefit and there's a lot of different applications that benefit from this but they're generally in the category of uh me creating layer two protocols um that allow use users to prove things about history to them to other users and so reduce the need for people to personally store historical information comments on this uh but you know the so if you're going to prove uh some header like start some historical header you would need to rely on the fact that your

uh state route is correct right and you know if you want to figure out the state which is correct you have to verify the whole chain of headers from the beginning so it's kind of circular no well so not quite right because so first of all if you're a light client now then you're already relying on one of these kind of well okay what you can do is there are protocols that allow you to verify a proof-of-work sub-chain right so you can basically like just look at a provided subset of headers that match a 100x difficulty threshold or something like this uh so there are and there are things that you can't do

and and the other thing is that as a client you might have uh downloaded verified the header chain historically but like you might not want to keep it around so okay i would like to i mean i i think we have considered that in the past but uh the reason i said i guess it wasn't really it didn't go in because we could not find uh kind of appealing use cases for it um so i yeah no it's like i was actually talking talking to people from a gas station network and heal off about this and he is really excited and intense about some

about something like this going in so i don't know maybe i should set up a chat with him well essentially like i you know the gas station network for example i mean i don't know like is this is there is a problem that i can't run the nodes or something or uh i don't know like they are in just looking and like looking into uh history related things so vitalik is this is this in any way like an alternate direction from putting a header an accumulator in the in the header itself

um it is just uh and it does do similar things it is just simpler and dumber like because it's probably literally under five lines of code in the context of the of the existing ethereum protocol so thomas you had a comment in the zoom chat um that there would be some defy solutions around this yeah we have some projects that we're building that would greatly benefit from 2.35 being available so that would save a lot of gas and to unlock some additional opportunities for for pricing and delivering products because uh this discussion's kind of on

why now right is that what you were getting at alexi or why in general uh well yeah because we i just kind of remember that we had we spent huge amount of time in the past discussing the similar proposal and in the end so i kept asking the question why are we doing this and in the end we couldn't find the like we were thinking that we're doing it for this reason but then which it turned out there wasn't really anybody who could tell us like what was the reason so i don't want to do the same thing so if yeah is it correct that under this proposal if you have a recent header then it then you could provide a merkle proof

that some arbitrary historical header from history is part of the canonical chain behind that header is that that alone is a huge benefit for uh for for the protocol itself because it means that it allows clients to actually forget the header chain and it allows us to prove historical canonical blocks which today if you really want to have you know real deep knowledge about the whole history you have to keep the whole header chain which is you know multiple gigabytes alone is a objectively valuable reason to have this um so does that does this go on list of

things that would be good to do for yolo v2 so we could look at it integration wise yeah we would love to see it yellow i would you can even provide some use cases and start showcasing them maybe in yellow v2 already what was that alexi no i just wanted to basically be kind of to keep an eye on the the the number of items you want to include in your v2 and i don't remember what was the exact purpose is that uh do you want to kind of unbundle them later to try to to put them into different uh upgrades because i could see that we're doing the same mistake that we did before is that

uh kind of having this wild enthusiasm to put a lot of things in it but when they realize oh actually you know we can't do them all together we have to start splitting them up so um i think it's fine to look at them the proposals but it doesn't mean that we have to pile them up in the same release yeah that's exactly and that's actually exactly why we're putting them into yellow instead of saying let's put them in a test net going into berlin uh because we've had bottlenecks before of a lot of the arguments i find with eips come down to we don't have we don't have real like implementations that can be tested across clients to see different benchmarking metrics for instance so putting them in yolo allows us to do that because then

we have cross client testing of these things before we decide if it's actually going in or not for things that are very much wanted but we haven't gotten all of the kinks out yet so that's kind of why i think yellow is important there's also other perspectives of why yolo is important but that's kind of where i come from okay so it was my my sort of misunderstanding what the yolo is because i it's sort of like it's not just simply some ephemeral test net but it's this kind of pile of things that just whatever you just put whatever you want in there yeah version three we can take crap out

version four we can put stuff in etc it's it's just a easier way to say we're not having a per we're not messing up or not messing up i guess is the right phrase but we're not affecting things like robsten or gourley permanently while people are using them but we're still getting the things like benchmarking and other benefits out of it these ephemeral test nets as we're calling them it only lives once sorry i had to do it does that answer your question alexi yeah yeah that's fine thank you okay um and we're i mean there's always a chance that we can do other strategies in the future but we've kind of i think having these yellow test nets are a good opportunity

for rapid testing of well not real testing but rapid examples of these eips going into actual client code um i mean the only the only concern with that is i just that essentially what you're doing by bunching up lots of things in it you're essentially making it mandatory for anybody who wants to join yolo to implement all the changes that have been in that that were put in so that's why so it was like if you put 10 10 eips into yolo v2 then unless you implement all 10 of them you will be kicked out of it pretty soon because i suppose that you're not going to implement all of them and yeah and the thing is for more advanced eips like 1559

that's going to be different than like optional acts or what was it 2929 because one of them is much more simple complexity-wise so the reason a lot of them are going in and we're talking about a lot of them are because the complexity around them are pretty pretty small in my opinion from what people have said yeah like and the i think um if the only reason i'm i suggested 2935 is basically just because it literally is two lines of of specification which is so it's not really a kind of a one like one-to-one comparable against like say and it's some new cryptography pre-compile or whatever oh mikey you might be right i don't know

the complexity of 1559 but that might come up in a little bit if we get to the update um and that's why in the conversation i'm asking the clients if we like like to get them in and if if a client feels strongly not to have something because it increases the complexity too much please uh express that and um the other thing is for the ones who haven't had a chance to look over this a lot so um if you're a client and you know you're not you're not comfortable yet saying put it in or don't put it in you can go into the chat afterwards in the next day or two and just say hey i changed my mind or hey let's let's rethink this and we can talk about it in

chat um so that's not like i mean the decisions we make here should stay but there's i mean if there turns out that we need to change our mind after the fact because of an extenuating circumstance or a misunderstanding that's not the end of the world yeah that's another benefit of it of it being around yolo is it's it's we can undo things also is it easier okay so next up we have uh eip 2711 sponsored expiring and batch transactions uh that one is micah um i would suggest that we table this one and unless micah feels strongly simply

because we already have a lot of stuff on the table and maybe we want to get 2718 in place first before we tack on extra stuff on top of it but i'm totally fine with presenting it as like this is something that's coming michael what are your thoughts i'm okay with either giving a quick overview for those who haven't read it or just saying go read the ap eip or discussing it whatever you guys think um my opinion is to give an overview but we are explicitly saying this is not to be considered for anything today including yolo and this is an overview just to give people an overview so it may be discussed in future meetings so yeah michael uh you can do it

so this was originally supposed to be the first uh type 2718 type transaction since then there's been several others that are probably going to make it in first but the idea is is to give a new transaction type that addresses just a handful of user experience nuisances that kind of cause problems in the dapp space so it would do a few things one is sponsor transactions so instead of having a single signer on the transaction you would have up to two signers so you can either have one signer like normal or you can have two signers the second signer is the one who pays for gas and the idea here is someone who uh you can use some layer two mechanism or off-chain mechanism or

you're paying someone with paypal or whatever it doesn't matter but they pay for your gas and so you would sign a transaction that goes inside of an envelope basically and then someone else would pay for that and so it solves really people are calling it meta transactions but it solves them at layer one which ends up being a whole lot cleaner than trying to solve them in the dapp layer the other thing it adds is batch transactions the idea here is you can do one or or more transactions and they will be atomic in the sense that all of them will make it in in the order you specify with nothing in between they're not atomic in the sense that they will all fail or they all succeed what this does it solves the horrific ux problem of erc20 approvals which we actually see elsewhere besides

just crc 20. so instead of users having to sign a transaction that says i approve this app to spend my stuff and then wait for that to mine usually and then sign a second transaction which then says okay now app go do this thing you can just sign a single transaction that basically does two things in a row and so it's a simple it's it's a little bit of overlap there with account abstraction like if we already have the account abstraction then this probably wouldn't matter much but account abstraction i personally feel like is much farther away whereas batch transactions are pretty easy once we have 27.18 third thing it does is adds an optional expiration field which basically means this transaction is no longer valid after a certain timestamp and so everybody can just drop it from their pending pool after that timestamp

we see apps multiple apps in the ecosystem are building this into their contracts you can swap in the canonical example where they include a deadline which is default to 20 minutes in the future and if your transaction doesn't make it in time then your transaction still lands on the chain currently because that's how it works but it just fails instantly and this results in just a huge amount of waste of gas with frustration for both users because they're spending gas and nothing's happening it's a no-op essentially and it's causing some amount of the gas usage or gas price problem and so expiring expiring transactions would just allow us to have a mechanism for dropping transactions that one's probably the most contentious honestly because it theoretically introduces a dos attack vector where you can submit transactions that

expire like one second in the future which is just enough time for the nodes to propagate them which is waste a bunch of network bandwidth and then drop them so they never actually make it we could maybe nodes can do things about that such as saying i will just refuse to accept any transactions that aren't at least 10 seconds in the future so but that's the one thing that's maybe contentious i think i think the rest of it i don't think there's any real issues with it again mostly to solve ux problems at the dev layer the things that have been frustrating users for years now that's in summary um martin did you have something yes so i'm curious about batch transactions so right now a transaction whether it's valid or not

it's pretty easy to determine uh it's announced right and does it have balance basically and if you have batch transactions make it up like nine transactions in a row which are fine and then comes number 10 and depending on what happened on transaction number nine makes transaction number 10 invalid because it maybe removed some balance so the sounds like adults so the i believe uh we can talk about this offline if you disagree with this but i believe that is actually solved by the fact that the the there is one gas gas payment for the entire batch so you don't pay per pay gas per individual transaction

you pay for the whole batch and so either there's and you can deduct that before the transactions start right because as we always do we deduct the gas first and then we execute the transactions i believe and so it would be the same thing so you'd deduct the gas first then you'd execute all the transactions and if they run out run out of halfway through it just means maybe some of those transactions start failing but you've already paid for the gas for all that up front actually one thing i'm curious um how does um this um multiple transaction thing interact with global variables so like how do like are things like the refund counselor and the self-destruct list processed at the end of every one of these sub-transactions or only at the end of the whole batch that is a question that someone more intimately familiar with uh how

clients are implemented would need to answer and i have not addressed in the ap currently so definitely if someone knows the answer to that let me know and i can update the mp to include that or we can change it as necessary to make that work i don't know wow um so the refund self-destruct and et cetera mechanisms are one of the most perverted parts of the evm so um if we go down the path of introducing bash transactions i would really strongly vote towards keeping the current every current mechanism so essentially we would just execute one transaction after the other but otherwise they would be as if they were separate individual transactions because otherwise we're just shooting ourselves in the foot with the extra

corner cases right i agree about that but then you land in the problem again that but if you have nine batch transaction and then comes number 10 which is invalid because it tries to send 1000 ether and doesn't have anything and that means you you can't do anything with a whole batch we um another just kind of zoom in zoom out general question um what like have we thought if thought about like if the intended use cases things like making it easier to do the um approve and approve a token and then use a token workflow um the alternative which is like basically

allowing a top level like eeos to basically delegate calls so allowing top lovely ways to just temporarily run a piece of code from their contacts so they'd be able to do multiple calls there's actually an efp out for that um so yes that is an option and if we had that we it might actually make batch transactions not a thing my main concern with the main reason it was added here is just because i think all the other solutions that problem i believed were more complicated um however i i might be missing something here such as you got to talk about the self-destruction what not that makes this actually much harder and it would be easier to just allow eoes to do execute delegate code

in which case we could drop bash from this yeah by the way if you can if you if anyone knows the eip number for i'm letting you know he always run code you can just like paste it the chat and be happy to just look at it okay anything else on this um so micah you meant the rich transactions where you meant the yeah 2803 or the other one from the transaction package which i guess is competing with with your work as well uh i believe rich transaction is one i'm thinking of there was someone else who wanted a slightly different implementation so i think they also submitted the vip

the one i'm thinking of is 2803. yeah i actually had a as part of um what we call the eton x64 we had a modified version of that um because the current version of rich transactions uses some pre-compiles but i think it's a much simpler option than having these transactions anyway i have a question regarding the how would any of these transaction types the features that combine so there's the the access list how would any of that combine with the your proposed transaction types instead that was we would need to come up with new transaction types for

all these different combinations yeah that was a discussion item f that we skipped over basically uh it's there's definitely one can imagine a situation where you would want to do both you know a batch transaction plus include an access list like that makes sense where you want an expiring transaction plus an access list so it kind of makes more sense to combine these if we can whether we do that or not is probably a bigger discussion than we have time for i do think we should have it though because i think it it does matter great um i gotta time box this but thanks so much for the overview micah and um we'll move on to the next item eip1057 next steps um i think greg you had told me in chat that instead of going into

any decisions today because there was some um further feedback behind the scenes that you just want to give just an update right and you also posted a comment in the agenda yeah there's a long comment agenda we don't get we don't need to get into for a couple weeks uh andrea one of the authors uh got out of the hospital a couple weeks ago so he's reviewing the code he wrote before he went into the hospital on the old uh kick exploit we are coming we are really coming the decision that there's no exploit there that it would be so difficult to exploit and even if you did the other miners would look at your blocks

and say no we won't accept these so we're looking at the general area that he was in but we're not sure there's anything there to worry about and that will that will simplify the proposal and uh otherwise it's it's under review uh we can talk about it some more at the next meeting as far as any hurry um existing a6 will start falling off of the network probably november based on the block number uh and based on when the dag gets too big so that'll be the first time that we would want to deploy prog bw if we do so next next time

okay thanks greg um the next item item 2a yellow slash yellow v2 and berlin state test update i've been writing down which ones are going into yolo v2 versus which ones aren't going into yolo v2 and which ones will just be continued discussion so i just wanted to read those off that's okay with you james uh yep and there's one more i wanted to talk about of that okay um so just reading these off just to confirm and anyone speak up if this is inaccurate um add eip 2718 type transaction envelope to yolo v2 add eip 2929 gas cost increases for state access opcodes to yellow v2 continue discussion of eip 2930 optional

access list so that is not added to yellow v2 continue discussion of eip 2315 simple subroutines for the evm and the ethereum magicians forms that one is already in yellow v1 add eip 2935 save historical block hashes and state to yellow v2 eip 2711 sponsored expiring and batch transactions was only discussed today as an overview for the purpose of future discussion and not to be considered for inclusion efi or anything else at this meeting so those will all go into the decisions made category in the notes and i'll paste that into the zoom chat for the note taker today um and then there was something else and i won't do that till james is done with

his comment just in case i need to add anything else so james you can go ahead uh first that matches my notes as well um the two that are left to talk about is 2565 rep the re repricing of mod xp pre-compile which i think is pretty safe to say that it should go into yolo v2 yeah and i can provide a quick update there james uh so just as a quick update on that that's moving into final uh status as an eip mica has provided some good commentary just to um clarify and sort of make it more spec focused um there's an implementation in open ethereum i've provided some comments on

a pull request to make sure that's compliant with the final specification and then i also have a gist for how to implement it into geth and i will paste that into all core devs as well great any comments on that from anybody anybody against putting that into yellow v2 for any reason or anything like that okay what was the other one james 2046 reduced gas calls for static calls made to pre-compiles uh who was that that is alex is eip and it's

just been on the proposed for a while and that's the last thing that's the one for static call actually for that one uh if we did the what is it 29 29 and it would be reduced to 100 because the pre-compilers are already in the accesses okay so 24 20 46 uh if we did 29.29 it would supersede 2046. yeah i think so okay uh it just it's more a matter of whether um if 2929 goes into yolo but not going into berlin

2046 can still go into berlin because there are no blocks for this it will become a change of constant which will be absorbed by 2929 going in at any time after if it doesn't go into bourbon i mean the only thing which stopped 2046 from being kind of included already quite some time this was one particular precompiled call in gas which is fixed by upr which should speed it up three times so there is no longer problem that some pre-compiles will become underpriced if uh call cost is reduced

so then do we have both of them in yellow or do we say we have 29 29 and yolo but we but there is an option of doing 2046 in berlin if 2929 doesn't make it to the end um i just wanted to say that those can be treated separately whether uh 2929 goes into berlin or not and how it will happen uh it will most likely depend on implementation and testing okay so do i leave it in the pending list or do i put it into the yellow v2 list uh first let's let's yeah let's get opinions who has thoughts

i proposed 24 to 6 initially and of course i would be happy if it would go in but at the same time if you do have 29.29 and it accomplishes the same without adding less rules less changes to the rules then i would personally prefer to to go that route because if you do 2046 and then we do 29.29 then we have these two separate changes added to the system which may be unnecessary so then we keep it as pending as we're looking at 2929 in yellow v2 that's what that sounds like to me

that sounds good to me okay anybody else have a comment on that okay um i'll paste uh all the decisions made stuff that i mentioned into the chat we'll probably go over a few minutes in time if people can stick around if not feel free to drop but we had two more things one of them was the eip 1559 update and the other was an update on the account abstraction eip and denial of service study so first eip1559 update i think that was tim yes sir i'm having a bit of an internet issue can we do the other update before it should be fixed in like two three

minutes yeah sure so this one next one is um uh will and it's account abstraction uh the eip and the dos study if you click on the agenda the comment has links to both of those um and we'll go ahead yeah yeah cool um so uh just want to briefly mention it i think in the next awkward devs we want to actually have a more thorough discussion um but one of the bigger concerns around account abstraction in general in the direction were basically the dos vectors that and the vulnerabilities around that so we released a study on youth research

that goes into the various dos vectors we built a basic version of account abstraction into geth when we collect collected a bunch of data on what the impact would be um and how how that would affect uh something like aa if that were to uh be included in the ethereum network um so definitely recommend people uh people go through that and in general it's it's a interesting case study on the transaction pool in general within guth and looks at things that are not just a related as well um so there's probably some interesting content there uh regarding the eip uh vitalik uh posted that so i'll let him uh talk

about that himmer onscar um yeah passing that off um so i think in account abstraction like we've talked about the um idea in a lot of different forms in different contexts but basically the goal is to allow or expands the set of conditions that transactions can have for their validity for inclusion in the chain so basically conditions where um that determined like based like how conditions that uh determine like basically whether or not

a transaction is even valid in the first place whereas currently that's restricted to being just an ecdsa signature and um anthony's check and there's a whole bunch of different use cases for this but we kind of break them down into a couple into two major tiers one tier is what we call single tenant account abstraction which basically is like mostly smart contract wallets multi-stakes like new signature algorithms and various things like that and multi-tenant has to do with applications that become represented by single accounts and and so we've figured out the a roadmap that basically implements a single tenant account abstraction so basically allowing

smart contracts that satisfy particular conditions to be top level accounts that execution uh transaction execution starts from first and then and expanding out to a multi-tenant over time um where it and in general the set of consensus changes is fairly small it's largely changes to a minor strategy uh or minor strategy and network relaying strategy but this this is the thing that uh will has uh written a big denial of service study that's available in youth research and there's a lot of arguments in the eip as well uh so to clarify like this is definitely too complex

and like much to come and much too new for it to be considered for berlin but like likely um some point after that and um i guess the eip is uh i mean is there and it's the end that's kind of ready for more people to look at okay any other comments on this and we can add this in future agendas okay uh tim are you back for eip1559 sure yeah um so i i shared uh the update i think on the agenda uh but we had a call last week an implementer's call

uh so just give a quick overview of where things are at uh right now we have a test net between the base u and death implementation which is being done by vulcanize um it's still finding some corner cases with the spec and whatnot so it's been good to just test things in consensus um we also have uh the ef doing some uh simulations on the eep so barnaby from the ef uh first worked on on just trying to simulate what it looks like when there's spikes in transactions and how do they resolve over time and now he's gonna start working on some more complex models around uh having agents trying to outbid each other and and having

just a bit more elaborate strategies another thing that got announced in the past couple weeks is that tim rufgarden uh who's a game theory and computer science researcher at columbia is going to be doing a formal analysis of of the eep uh and and mostly trying to compare kind of the you know the the design of the eve with what we currently have on mainnet and other proposals like the escalator fees um next steps from here uh is to to get more client implementations and probably start running a small proof of work test net uh while the research is continuing uh there's a bunch of potential changes that are that are being discussed for the eep so we're trying to just uh move things

forward uh and and incorporate those as as it makes sense uh 2718 was one of those so it's good that there's some resolution on that um yeah i think that's that's pretty much it i don't know james do you have any other updates uh james you're on me maybe i we can't hear you yeah i'm on mute i was saying a funding update but i don't know if we need to go into that we're already pretty over yeah we're over time um so yeah just pasted the decisions made the note taker has gotten those next time we're going to be adding account abstraction to the all core dev

meeting agenda we'll also be adding the ethereum cat herder survey results to the all core dev agenda next time um pooja has already started in the eth r d discord uh the breakout room and has tagged people who may want to be in there for that discussion and they're going to be setting up uh there's different times to have a real voice meeting on that that have been suggested so please vote on the suggested date and times in there if you've been tagged or if you want to attend anyone's welcome if you aren't in the discord server uh in the agenda there is a link to the discord server um i think actually if there isn't just um find me or find someone who can give you a link um i have a link and i can or an invite

code and i can give it to you all right thanks everybody this went a little over but i think it was really productive and we will see you in two weeks on september 17th 2020 at 1400 utc have a great weekend everybody thanks thank thanks you thanks bye thanks thank you [Music] [Music]

[Music] so [Music] [Music] [Music] [Applause]

[Music] you