All Core Devs - Execution #114

Transcript

[Music] [Music] [Music] [Music]

[Music] [Music] [Music]

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

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

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

so [Music] [Music] [Music]

[Applause] [Music] [Music]

[Music] [Music] okay hello everybody um well oh sorry my mic goes off

Tim Beiko: hi everybody welcome to awkwardev's 114. um a couple things on the agenda today uh lots of blood updates and then if we had time there were two other discussion items um first on the list uh martin you identified an issue with 1559 i guess today for you yesterday for me um do you want to take maybe just a few minutes to kind of walk through

like at a high level well it was and i know that micah i don't know if he's on the call had put together a set of like potential ways we we could fix it

yes so the issue is that a transaction under 5059 has two new fields which are integers um and like any other interview they are arbitrarily large integers and the same is true for previous interviews that were there such as yes price but in practice you cannot i mean if you set a high gas price you're going to have to

pay that high amount however these two new fields um we only use one of them and the the the price that you are paying is based on the minimum of the two so it is perfectly fine to set the one megabyte large integer into the other field and thus you can create these types of nasty transactions which do not cost more which are like a megabyte in size but only costs doesn't pay for that exercise um and this is yeah this is ugly and um it turned out after i

so i we discussed this a bit on the old quarter channel and it also turned out that another mind and um also some uh the c plus pass implementation that hyper basis is working on uh and perhaps a few others are actually capping this to 256 bits which is not according to this classification and which would lead to a consensus issue if one of the feelers um yeah included a such a transaction in a block so yeah it posted another service and obviously it's it's a consensus problem already

and yeah mikey you can talk about the alternatives if you want or are there any questions okay like everybody gets it uh so a few few options we have

Tim Beiko: on the table uh one we could just say these fields have to be 256 bits or less or some other arbitrary value 64 bits is probably too small but we can talk about that another option is we can say that the the premium must be less than the max because it doesn't really make sense to have your premium higher than your max

because you'll never pay more than your max and then we could separately say that the max times the gas limit you must have that much in the account and so i think some implementations already do this for gossip and so would just be extending that to consensus um the last option which i just thought of um is we is is there any reason we don't just say throughout the entire protocol numbers will always be 256 bits or less just like protocol wide or do we have any use for things bigger than 256 bits

um i think we don't uh but

Vitalik Buterin: i think there wasn't really a good reason behind uh behind to not doing something like

that again the beacon chain protocol was constraining everything 64 bits anyway um i i do think that it will take a change of that scale will take longer than london uh so it would like if we go down that direction it might make sense to start to make that a special feature exclusively for the new 50 50 night fields and then like do something more comprehensive for the next work yeah sure yeah and it feels uh i i skim the cordets before this oh sorry enzgar you have your hand up

go for it yeah i'm just uh wondering in general

what would be the arguments

Ansgar Dietrichs: for or against requiring that the balance of the sender is sufficient to cover the kind of the specified pcap times times guess because in some sense it feels like the right thing to do regardless right because it's somewhat somehow misspecified transaction if you can't pay for it

who couldn't theoretically pay for it so um so what what the what i think the

Micah Zoltu: the point of contention around that is that so the rule would be so the first rule which i think is fairly non-controversial is that the max deeper gas should be more than the max priority people gas just intuitively makes sense that you're the total

is should be larger than the the part of the totals right i think that's so i think people are getting agreeing on that the other one says that this underbalance should be larger than the gas limit times the max fee for gas whereas the like in the actual cost is the gas limit times the effective uh fifa gas which is one of the two and it might not be the max vapor gas it might be only you know priority people yes but this so this rule adds a harder requirement than the actual execution it requires you to have more money on

your account than will then you will be charged so that's the kind of non-intuitiveness of the last rule but i think it still makes sense to have that

right i feel like you know wouldn't it also simplify memphis handling because you you like otherwise you might let in a transaction into your mempool that at the point of inclusion all of a sudden this cannot pay for itself anymore or something i think it would

Micah Zoltu: simplify many things yeah and i don't really see a downside

yeah their education is around like you

know the sender's transaction varying to accommodate and then not accommodate their max fee but it does sound like an edge case

i would say that it makes sense to limit the you know limit this numbers by the formula binding it to the account balance but i don't think it it should be the only protection i think there should be two for places where protection is placed because they kind of like you know they're i think they we should at least for these fields just introduce the limit on how big they are and then if we want on top of that we can introduce the limit on

the other you know the the the with the balance because i think it's it's much easier to reason about the first limit than to reason about the second limit

Micah Zoltu: so let's talk about the consensus changes were you talking about non-consensus changes

alexa no i talked about both so i assume you assume that erp

1559 has to be modified to address this issue and i suggest if we modify it we introduced two rules in it uh you know well basically first rule is consensus issue is consensus rule that would require the um

that every oh there's these specific fields for now we don't want to basically mess up the whole you know go through the whole all the protocol but these specific fields potentially all the new fields that erp 59 1559 brings needs to be limited by by 256 bit but then on top of that the non-consensus uh requirement for the transaction pool to not allow those transactions with the um like that they can't pay for themselves but i don't i see it's it's not normative it's uh it's some sort of optimization thing

yeah yeah i mean that i

Martin Holst Swende: in my opinion that's an implementation detail and it doesn't really matter what we do

because someone can if someone can mine block where the gas limit times the max vapor gas is larger than the standard balance it does matter if clients have implemented this in consensus or not because it can later change bits we need to be really careful here about what is consensus and what is not

yeah so

i would suggest just do changing consensus which just simply limits the size of the numbers that's it because it's the simplest thing you could reason about

right

Martin Holst Swende: i mean it's pretty simple to reason about in my opinion whether standard of balance is above gasoline at times max vapor gas and it's

also very reason about whether max vapor gas is larger than max power to be yes and the thing is if those two so the the max people got larger than max periodically makes yeah it obviously places a constraint on max p or gps and the other rule places a constraint on the maxwell gas which implicitly makes them both need to be less than 256 bits right because the balance cannot be above 256 bits so if so in my suggestion that i put on the agenda

i posted the four rules but the top two rules uh are implicit by the second two rules so they could be made early as a kind of you know cheap early check before accessing the state or they could be omitted because they are implicit in if you follow the other two rules

and it's

Tim Beiko: am i right in saying that like at least two of the clients already have those first checks right like i believe that's what nethermine said and i think open ethereum uh they said they're already doing this check so it's almost like they have this rule um even though it's not explicitly documented

Martin Holst Swende: yes and that's yeah that's that's what i said that yeah it's a consensus issue right now

uh lucas so

Łukasz Rozmej: to clarify we're not doing the check we are just using the type that won't accept anything else so we will have like an error when uh when we try to like this realization that is bigger

yeah so that

Martin Holst Swende: you won't accept the the cannon chain so the effect is that you will reject it

right yeah exactly

Tim Beiko: so i know is anyone actually opposed to pulling in all four rules um

just because this way we you know it seems like the first two are fairly trivial and the last two are are kind of needed um and just like for like maximum kind of clarity and alignment between the implementation would is everybody fine just putting in those four those four checks and the ones that martin had in the lcord f so max cheaper gas and max priority smaller than 256 bits then a max fee bigger than the max priority and the balance bigger than gas limit times max

fever gas why not both most times you see bigger union bigger or equal right oh yes sorry yes uh all bigger equal yep i mean

i would put the first three as

the is the consensus rule but it's the third one the fourth one which is the center balance thing i don't know if we should because it will be enforced anyway right in in a different

Martin Holst Swende: no it won't the fourth might so if we don't explicitly specify it

it's not necessarily

Vitalik Buterin: right like the idea is that if you have a transaction that has an insanely high max key and you don't have enough money for it then if we do nothing then the transaction would be valid if the base key is just not high so it doesn't get that high but if the bc is high enough then it would be

um excluded whereas with uh this proposal it will just always be excluded

Tim Beiko: yeah and if we did not have the last ones are there like weird things that like mev could do for example like i have a transaction in spot one that then sends money to an account that had like one of these funky transactions which is right after so the transaction kind of only becomes valid i don't know

Tomasz Stańczak: um yeah i just wanted to raise this so the opportunity check that happens in transaction pool it's up to the clients and it's not part of the consensus but if we are checking if it's greater

than max vapor gas times gas limit since it's not necessary and it's done just before the transaction is executed that's how i understand that this role is proposed to to verify just before the transaction is executed um oh sorry actually i start to think that i i need more info why we would need to enforce this exam it might be that you want to keep the transaction alive does it attack in a way the transaction pool if we base it on the max fifa gas like you could push a lot of transactions with high max vapor gas for the accounts that have low balance and they would just stay in

the pool for a long time because we would think that their value all right

Rai Sur: well is anyone is anyone prioritizing not by effective by effective max fee because the way we do the eviction is that if you did send those you know really high max

fuel gas load balances they'd still end up getting evicted yeah but this affects your effective max vapor gas affects your is how about kind of

Ansgar Dietrichs: not enforcing it on the consensus side but still recommending that clients just don't accept those transactions

that seems like so

Martin Holst Swende: i think we should

discuss the consensus rules first and that's yeah so it's a consensus rule um i mean we can also discuss the transaction pool how we should behave and what we can recommend but let's try to try to determine what consensus rules we should have

Lightclient: so we agreed on the first three requirements that you posted and we're just discussing this fourth one now or is there still questions about the first three

agreed on the first three and i would prevent fourth to be at install for now because i think recommendation we don't actually need the third one uh technically the first two would be sufficient

just the 256 bit check that's all we missed that's what we do know if if we're looking for like the absolute minimum change i'm not really thinking this one i i would i mean

Martin Holst Swende: i think if we need to change this at this point if we had two checks or three checks i don't think it matters a lot and i think it's if we add this check which makes sense it's just sensible check i think yeah i don't think that adds more overhead i would i would prefer to have all three of them

Lightclient: do you prefer to have the fourth one as well

Martin Holst Swende: personally yes

Lightclient: so it seems like the last check is mainly to avoid some free call data since it's bound to 256 bits i don't know what the average size of the fee cap will be maybe it's like 16 bits or something but the rest of it could potentially just be free call data

oh yeah i would i would totally exploit that um because like when you're doing mbv stuff everybody every bite counts since you want to minimize your gas costs and so i would definitely bit pack stuff into the max fee for gas because i'm always like

if you're doing maybe stuff you want to be versus your pax fees whatever and so you could pack that with all your data but you cannot access it on chain can you you can't access it now but i would guess in the future there may be an op code to access yeah i was kind of assuming that you eventually were gonna opcode for that but if not then that would protect it well i also would add that at

the moment for example there is an implicit uh consensus rule that regarding the gas price whereas the sender balance equal more than equals the gas limit multiplied by gas price and it happens because because by the rules first before the transaction gets executed it has to purchase the gas

like and then the balance gets so the balance gets subtracted by this amount and then if there's anything left then this gets returned and then it's important because during the execution of the transaction if if if the transaction observes the sender balance it will be without this ether that has been used for purchase so but now if we introduce the rule that central balance more than gas limit multiplied by max sv but when we purchase the gas using effective work at the moment we're purchasing the gas using effective or whatever i don't know remember what we basically we're using the different formula um i don't know it's like it is a bit more confusing

is that if you observe the balance during the you know i think if we introduce this requirement we probably should also change the way that the gas is purchased is just it will have to be purchased uh in the amount of gas limit multiplied by max fee for gas because then that would make sense if it's a consensus rule

Micah Zoltu: so i just for another week argument for number four um generally when building things that are security critical i'm a big fan of having as many assertions as possible um just because it makes it easier to think about the software and reason about it if you know that there are certain constraints in place and so in this case since it doesn't really make sense to

allow uh the sun the center balance be less than the max um and users and wallets whatnot can easily implement that and ensure that's true it gives us just one more thing that we can assume while we're writing the software and while i worked on it this isn't a strong argument it's just kind of like engineering tends to be easier if you have more constraints because there's less to think about

less problems you have to worry about well i'm

suggesting that if we do introduce the fourth constraint we also change the logic of the gas purchase because the downward will be consistent it will even if if we require already that this this the balance is enough why don't we just purchase that much gas and then that would automatically be implementing that

restriction and it will be consistent so you don't have to have like differences in terms of how much you purchase the gas for and then there's another constraint and so i think it will be cleaner to uh to do to do that

Martin Holst Swende: what you're describing sounds to me like you like it it sounds to me like a very large change into the mechanics of

e1559 well it's in order to no i don't think

i think it's in the same level of change as the fourth constraint and i think uh this is actually the equivalent in terms of complexity because all you need to change is the

the buy gas function i mean in other clients is a different name but essentially by changing this function to uh to purchase gas differently you're you're implicitly introducing the restriction number four

but you know

Lightclient: i think you also need to change how you refund gas because the actual obviously yes yeah the actual cost i mean i don't i don't i think it's the same thing i'm not sure which would be more complicated and my intuition is that the check itself would be simpler just to have a one-line check and then do the gas purchasing as it is but they're equivalent

so i think

Micah Zoltu: if we did that it would have potential down

effects somewhere down the line if we ever implement um transaction type that lets you execute as the eoa by sending the transaction because in such transactions you hypothetically would be able to send your remaining check your balance from the eoa's context and so that would have an impact so if you want to sweep your account for example having been able to do that will be much harder if you have to set the gas limit to exactly what the base fee is going to be i'm sorry not the estimate the fee for gas to be exactly what the base fee is going to be in your future block um again this is kind of just future proof trying to future proof things a little bit because we have talked about adding that type of transaction at some point

also isn't the only reason that the right now basically you're charged in advance with or the full gas limit just to ensure that you're actually able to pay and so i don't see a similar kind of um reason to to do that with the full fee cap because you already know that you'll only be charged at the actual effective base fee so yeah it seems a little bit artificial

Lightclient: i think the only reason to do it is to avoid people using this for free called call date call data and it's not useful right now because there's no way to access it but it might be in the future

uh you could

Micah Zoltu: so you could use it if you're

if you're a bit packing this for like something that looks at call data like a layer two solution that's using call data as its mechanism for data storage

Martin Holst Swende: basically um you cannot put one megabyte in it we fixed that but you could still pack 256 bits into a field that will not be validated when just tag along with every transaction if we find it bounded by the balance there's a lot less freedom and that's kind of why i find my favorite i also intuitively did not think it was good when michael first suggested it because it's

yeah doesn't map to the actual cost but i i'm not gonna die on the hill but i yeah i obviously prefer fourth rule as well

i'm in favor of capping it well so martin uh and mike do you want to cap it on like a memphis level that or like on consensus level so we also just reject blocks okay so reject blocks okay so yeah i'm i'm i'm

Martin Holst Swende: speaking about the consensus rules here

yeah yeah and

Tim Beiko: it's worth noting like if we cap it just in the mempool you know especially now with stuff like mev geth you know

most of most of the miners will be modifying the mempool implementation so um i i doubt it actually makes a big difference into what actually gets in a block uh if somebody really wants it there

what are what's

Lightclient: the argument for not doing this check

Ansgar Dietrichs: well you could have situations where let's say i'm sending two transactions and they both basically barely if they were to to consume the full kind of price that i'm willing to pay that barely i'm available to to pay for them but then i maybe bump the first one and it goes in at the higher price and then i'm basically i'm slightly miss specified the second one and you

couldn't be able to pay for it at the highest price but because the base is low enough i effectively can pay for it so what's the reason it should not just go in it seems like it's not a malicious transaction it's like a transaction that does everything right it just happens to be a little bit kind of specified and for the highest possible price or something like i think this could potentially organically happen

Lightclient: i just think that's an incredibly uncommon sort of experience whereas this is likely to be exploited by many people on a regular basis if there's no check

Martin Holst Swende: yeah i mean it's it's it kind of feels like the scenario where

you're in an auction and you make a you make a high bid is it like a closed auction you make a high bid and it turns out you don't have to pay the highest bid you made you you don't have to pay the second highest it's one of these you know enos auctions or something but so you so you made it and no one called your bluff but you kind of the the the bid shouldn't have been accepted in the first place because you couldn't you made a bid that you couldn't cover for that that's kind of one other way to see it i think maybe

how easy would it be to remove this kind of requirement

in the future if we were to say like 559 is new we want to be as restricted as possible in the beginning but if someone really feels strongly about it they could just create an eip for future fog to remove this

check again because that may be a good place to keep it at it's generally easier to remove constraints than add them so if we want like flexibility to start with more constraints then later remove them if we want

that might seem like the most practical way forward so i think uh thomas you were kind of

weakly against the fourth one would you be okay if we went with it and potentially remove it in the future if we see there's a there's a valid reason

to yeah weekly

Tomasz Stańczak: against means that if others think that it's worth to implement it for them totally fine

is anyone strongly against going with the four set of constraints uh by martin uh that i won't try to describe again did not make mistakes but the four posted in all core devs um a person sorry on the uh issue for

for this uh this call oh i have a yeah so the question is is that fourth constraint would be work as alexei

Łukasz Rozmej: uh explained it so when we are

reserving gas for the transaction before the actual execution we would just reserve more or how would that

be

no i think it was more that you still reserve what you reserve now but additionally you also require that the center balance equals more so it's kind of i think the what we're trying to agree on is the not what i suggested but i think what martin originally came went with so there will be different uh numbers that you have to reserve and you that you have to restrict

on it this would

Martin Holst Swende: just be a one assertion added at a certain place in the code

that just says assert that this is true at this point and that's it so in theory that should be the on it should be i guess technically two assertions will be required if we go with all one two three four the minimum change for any client is just two assertions need to be added of course we'll specify and we'll get that into the ipf we agree on that so we can see where they go

yeah i'm thinking if there are any potential issues if we like don't specify when this assertion happens exactly but maybe i'm thinking too much into it

yeah i think you are because as you process

Martin Holst Swende: a block you process the transactions one by one and for every transaction you check the validity one of the existing constraints is that you know the the intrinsic gas must be the gas must be more than intrinsic gas the gas times the gas price must be invested in the balance etcetera and this is just two more of these rules that are validated during block processing

i

Łukasz Rozmej: would have to validate it dynamically during block production so yeah and if we pick the transaction

yes as

Martin Holst Swende: you try to add it to the block that

you are trying to build you would do the same

check yes wouldn't clients be just expected to make sure these transactions would never make it into memphis no i mean yes from kind of yes from one perspective but i think that my clients have a pretty clear distinction between what is consensus and what is a memphial and those two do not really share necessarily the same rules i mean the mampool can for example be more restrictive about things it can throw away transactions which

have a gas cost of one or zero or three previously whereas the consensus you have to just accept for example zero gas price transactions because otherwise you make consensus and yeah make sense

Tim Beiko: okay so it seems like we're good for all four rules

um yeah does anyone want to voice a final disagreement on that and if you know we decide that the fourth rule is not needed in the future um um then we can you know somebody can submit an eep to remove it and uh and uh yeah obviously yes so there's more checks more code more complexity um yeah i think that's just the trade-off there okay uh so no i guess no blockers um let's go with the force the four

consensus rules um does anyone want to submit a pr against 1559 either i don't know today or monday

depending on i can do that okay

Tim Beiko: so martin um once once your your pr is there um we'll need an author to merge it uh yeah so either vitalik or i can ping abdel um and uh yeah once once that pr is merged i'll make sure to update the london spec with the with the latest commit

Vitalik Buterin: um sounds good

Tim Beiko: cool um anything else on on that issue okay if not uh the next thing uh i had

was um basically just giving you a quick update on uh baikal it seems like there's been like a lot of uh you know testing on it in the past couple days there seems to have been some issues with like some signers not necessarily including all the transactions um i don't know if anyone you know maybe just wants to recap

kind of the testing that's happened over the past few days and and what are some of the issues we've seen nobody knows

Martin Holst Swende: nobody knows what's going on right

yeah so i guess you know from my perspective

Tim Beiko: from the outside you know it seems like i think it was kareem and somebody else were trying to uh kind of spam the network with transactions

sorry yes i can say i did some uh spamming on the bike called testnet i sent some eap 1559 and legacy transaction at the beginning i tried to send directly this transaction to the bezu sealer it seems that bezu was working fine sometimes neither mine was not completely fill the block and get but i think it's maybe because i was sealing directly all of the transaction to my sealer so i

tried today another thing it was to send this transaction to another not the sealer and also some other transaction to another node and seems better get fill the block and also bezou i think when i did the test netmine was not running so i'm not sure but it seems that it was not running so honestly i don't really know if there were what is the status for determined because i think yesterday in the determined had some issues but maybe netanyahu will have more context but for bezu and yet it seems that it's okay

but i can continue i have a several tests to do with a different uh fake up with different heap so i will try to do several tests during the next day yeah we were discussing that internally for the changes so you see the transaction palm is behaving slightly we are in the process of merging some um like mev solutions to the transaction polling undermined and also like rewriting some bits of transaction polls so we see a slight more instability so we'll be fuzzing that internally as well but we had more discussions equivalent team uh today and yesterday about it

and and

Tim Beiko: was open ethereum on baikal yet

uh not officially we are in sync but uh we don't have social releases okay did you see any like issues or were you know were your nodes working fine well until today we are we were in a scene but they were fixed in the meantime so um i don't know

Tim Beiko: on the turbo get side alexa did you see anything special

or no we just had one issue where we forgot

to activate the erp with the refunds uh with the refund reduction and i think it's interesting that it only occurred uh like five days ago so i suppose that was the first transaction which actually had this kind of things so yeah but now it's fixed and it's called everyone right away now it's not true yes anymore oh that's true yes aragon um thank you um so given it seems like you know there's still a bit of kind of finalization that people

Tim Beiko: uh that we need to do i guess with with baikal and we will have um you know some changes in 1559

what do people feel is like the best way to test those like further changes do we want to potentially hard fork baikal do we want to just write tests for it and test on the proper test nets um we could spin up a new kind of devnet there's obviously some kind of cost in terms of you know it's a bit more complicated to do that um yeah how how do people feel we should go about just testing these latest checks on 1559 and like the couple issues we've seen in baikal

so i don't think you want to fork icon

because that means you need to do all the clients need to define a new fork and then essentially you have eips on top of eips or for rules of the popular crews so if if the consensus rules change now i guess bicarb was always meant to be a primary investment and just nuke it and restart if we restart

Tim Beiko: is it possible to just like restart baikal and that we just change kind of the genesis um but like all the kind of current infrastructure and everything we have around it stays there or should we have like another

network with just like another name to make it simpler um or you know are people like comfortable enough to say you know we implement these things we add reference tests and we just you know fork robston um i guess that's the part i don't have an intuition for

sorry no no no no if you change the eip at least let's do another round up okay perfect

Tim Beiko: so in that case should we just create like a third one

i don't

uh i don't know who created by

call and how much effort it was so i can't you say i personally don't mind to just move the chain and

start with a different chances it was me peter yeah okay um you can't answer yeah

Martin Holst Swende: it's pretty simple

not a big concern to create a new one to be clear yeah yeah okay does any i guess you know does anyone oppose kind of creating a new one obviously you know yeah this will just is it going to have a different name or is the same name sorry that's my point

Tim Beiko: does that make a

difference to people

right well i suppose there will be a little bit of a confusion if it says still the same name but i don't mind yolo apparently yeah i don't know it's just because yeah i know we had like a faucet and all those things

Tim Beiko: will we have to change those things if we create a new network or will they just keep work and you know will they work if we just reset the genesis

um but um another question is that

do we already have transactions that are breaking those rules

or not

i would suspect that we might have transactions back in the fourth row okay yeah possibly the third rule as well i know that someone mentioned having experimented a bit i think joking experimented a bit with uh stuffing crap into either of these fields because

one option would be to shut it down right now the the by call examine whether we had any rule breakers and if we didn't then we just simply restarted with the new rules and if we did then we have to start a new network

Martin Holst Swende: we don't have to stop it i mean if we just add these checks and try to sync and it should be

fairly obvious

right i mean maybe optimistically we

should try to do that salvage the buy call just in the neurals and if it doesn't work then we can launch the new one

yeah i

Tim Beiko: i like that approach does anyone disagree with that

well makes sense

Tim Beiko: okay so we add the new checks to 1559. try to sync by call um if it works great we'll just update the bicar spec with the new commit if it doesn't work then we'll start calaveras which will be a copy of baikal but uh with the 1559 with the 1559 changes yeah and nobody please break by call in the next

yeah a couple hours uh i don't think it's actually possible well it's not possible to do the first two rules unless you can act as either okay so yeah let's try that um i'm trying to start in yokomora they already broke roll three or four maybe yeah and it's worth i guess uh after the call or if somebody wants to do it now we can maybe

ping him on discord and ask directly he might know um okay and so i guess obviously this kind of invalidates you know the testnet blocks we had potentially for june 9th um i'm curious you know what the teams feel like what's the best approach to kind of get to test that's do we want to do this and then potentially you know set the blocks on the next call that people want to look at potential blocks now that are like a week or two from now um i don't know what's like easier just in terms of you know obviously knowing that these changes work but also managing kind of the release cycle for clients

what was the question so on the last call we you know we tentatively agreed to try and have the first test network on on june 9th um it seems like unlikely if not impossible to keep that if we want to give at least like a week if we want to give at least a week's heads up to the community for a test network that means by like tuesday next week we would need a client release given we're still making changes to the spec and we want a new network you know that's probably not going to happen um so do people feel like we know enough to set a potential like you know block on the test nets and and have clients implement that or do we want to wait and see how things go

on on baikal and potentially calaveras and that means you know on the next call potentially we set the testnet blocks um yeah so my five sense

Martin Holst Swende: is that i still i mean yes we we are we have some work to do um and it's it's yeah it's it's gonna be pretty hard to get everything done in time but on the other hand i am personally not too scared about breaking or screwing up testnets a

little bit so i think it might be fun anyway other people may have other opinions

in that matter today so yeah

we are planning to still kind of modify heavily modified transaction pool and i know that as people would say this is not kind of critical for the test net but still as uh martin also mentioned it is this is some work to do there and uh in the result of that if we do go ahead with these test net blocks it's likely that the test the first test method will work will

not look anything like the mainnet basically they'll be running the code which is very different from uh regarding the transaction pool i mean i don't know if anybody's actually planning to to test transaction pool changes and test nets i don't know is any plan for that or is it we're gonna just do the some kind of unit tests and other things

Tim Beiko: so at the very least one thing i think we should do on the test nets is have a a kind of time where we try to spam them and and like you know send a very high number of transactions

and you know make sure that that actually works that like the base fee is working and that you know clients and miners are including transactions and beyond that i i don't know

and so do we already have tools for this kind of things i mean the existing ones that like when somebody said i think kareem said that he's spamming that is do you kind of use some kind of tools that you've already created is it could be used in a test net uh like is it easy to interpret results and stuff like that

Tim Beiko: so yes we have a tool that basically the tool we have can just send a very large number of transactions and i i think the only constraint on it is we need a large ether balance on that network

so for robston specifically i think we would need to find you know some

robston whale who could uh who could fund it was the ropes in well i'll ask him i've

Tim Beiko: been looking for one this week so i'll ask him

i think we in the gut they might have uh some

ropes in either yeah um and

Tim Beiko: it's just because the base fee kind of increases exponentially like the amount that you're gonna burn doing this for one hour is is very high um yeah so uh but but yeah so aside from that i don't think we have any tool in your infrastructure to test like more complex

things in the transaction pool

because another thing is that on the test net i'm not sure about the tests in this but

i would suggest that it's easier to test something like this on a very constrained network where you have a very low gas limit because then you get to the this exponential thing quicker but at the same time if you're using public testnets which are heavily used you don't really want to constrict those

things too early i don't know if it's uh yeah it might disrupt some people um yeah and i think yeah

Tim Beiko: i agree with that my preference there is the kind of do then robsten and then gordy so we can do

maybe like this spam test on roxton which doesn't have a ton of you know real world usage and then maybe we can you know do a smaller one on gory or something like that but yeah gordy does have actual users um yeah so i think we should try to ha you know go from like the most artificial to the most used network

um we basically

with this spam test we might basically price everybody out for whatever the duration

Tim Beiko: for like an hour yeah yeah um okay so clearly yeah guest aragon

still has like some work to do i don't know whether the other teams feel and thomas i guess you just mentioned you had also some transaction pool work that you're doing um yeah so it's don't know it seems to me like people will probably be much more confident in the state of things two weeks from now um you know would it be realistic to you know like do we want to just have the discussion in two weeks and potentially kind of set a block that's fairly i guess uh close from the next call um you know the constraint being obviously

we don't want the difficulty bomb to go off and and uh and uh you know on main net and we want some kind of large amount of time on the test that's before that um and i guess a more concrete way to ask that question is like if we come to the next call and things are are generally good with regards to clients um is like a few days sufficient for clients to put in fork blocks and um and pull out a release right like if we if we come to the next call and we decide we're forking in the test nets in like 10 days can clients have a release like two three days out after that so that we can then kind of advertise those releases and people can

update yeah probably okay i'm not hearing any objections so um yeah so i guess okay so let's do that then let's you know take the next two weeks to uh obviously do the changes to to the spec and test things on on the on the dev nets uh make sure that like the transaction pool uh stuff is is done um on the next call you know assuming everything goes right we can we can pick a block and it doesn't have to be too far out in the future for the first test net

um and you know teams should probably expect that we'll be pulling out the release with the fork blocks in in the couple days after the next call okay um anything else anyone wanted to discuss for london specifically okay uh if not uh we do have some extra time uh again and uh yeah alexa i know you had uh something you wanted to talk about with regards to gas pricing and denial of service

protection

quick just the uh yes api call do you want to mention oh right

Tim Beiko: sure i was gonna mention at the end but yeah uh it it makes sense to do it now uh so this week we had a call with wallet providers uh to discuss kind of the ui changes the 15 uh bring and stuff like setting defaults for users um one thing that came up during that call is basically all the walnut providers and whatnot rely on the gas estimator oracles apis like stuff like eat gas stations guests now and whatnot um and how they implement you know their their uh their predictions for gas prices will matter a lot um so we're get organizing a call next week next friday at uh basically awkward ev's time

uh with these gas api providers um to basically just discuss yeah what's the best way to to uh to provide these estimates post 1559 um the link is shared in the agenda obviously anyone here or listening that that kind of is affected by that is welcome to join

um yeah yeah just send me your email or the people on your team you think would be interested in joining and i'll add you oh and uh okay so light client found a

Tim Beiko: transaction that invalidates the fourth rule

on baikal already so we will have to restart it um so in that case okay we'll go with calaveras i'll put the spec together today as soon as the new pr on 1559 has has been merged and we can we can use that and stand it up next week cool anything else on london okay um so yeah alexa over to you

okay so i am going to just introduce

this topic briefly so just to make sure that people kind of aware of it it's not at the moment a call for action but it is just to for your awareness is what we are planning to experiment with and what so to explain like when i talk about decoupling or the worst case performance and average performance that's what i would mean so the the context is essentially the question about the safe gas limit and uh which is deter like how is it determined and like where are you know is it the correct way or good way of determining the limit so as far as understand the currently the limit

for the safe gas price is determined by a couple of things one of them is is kind of the sort of the dos limit so limitations of how what is the worst so what is the time to run to the worst constructed transaction that would consume this entire limit for example and as we saw in the block was recently published is that there used to be some really i mean really simple but very potent uh transactions that could cause a very large um run times and so but you know that was mostly based on the state access which was underpriced so now even if we do

a lot of uh kind of let's say that without in our product we do reduce the state state access cost and we also can put some bloom filters on it and other things um even if we do that there are other bottleneck which will appear with surface is the um the pre-compiles for example so the pre-compiles will be the second target because they're currently as far as i remember they're currently priced like when we do repricing or pre-compiles sometimes i think there's certain um sort of mega gas per per second which people they keep in mind i don't know what that number is right now maybe 25 maybe 40 i know and the repricing of the pre-compiles is actually

using this kind of made-up number which is kind of the target sort of safe uh gas limit which is like 40 or 25 i don't know the different pre-compiles of suppose were were computed using different targets and so what me what it means is that yeah there could be like a worst case transactions which then uh targets those pre-compiles like there's lots and lots and lots of pre-compiles and then even if you optimize the state access you know you're gonna hit those things so so does it mean that we are completely constrained by those things well actually i think it would not we're not so we can so my idea is that we are going to experiment with and i uh sort of want to make people

aware is to to try to stop so i call those things execution bombs i think the terminology existed before is that so if you think about the analogy that the true transaction that carries that kind of explosive load that is really hard to execute um currently it is not getting stopped anywhere because the transactions are usually not executed on the way to the to the minor nodes or to other nodes and they go straight into the core of the whatever of the node and just explodes there essentially like different type of nodes have different uh implications for that for example miners might start uh mining empty blocks uh the other nodes might you know stop processing things and

stuff like this so but the idea that i'm going to look at is to try to stop those execution bombs before they reach the core um to form some kind of protective perimeter around the nodes to stop those things so that obviously implies that the the things that will form the protective perimeter will need to be able to verify or check or try to figure out whether this particular transaction is actually going to explode and so that's the main idea and the way we are going to experiment with this is uh according to our architecture plan at some point we will split out the transaction pool component um using some

some interfaces and we're going to experiment with the transaction pool component actually trying to execute transactions and capture those execution bonds and try to diffuse them before they reach the the core um and the the reason why you have to get it separated is because you might want to have a multiple transaction pools around your nodes so if one of them kind of is being slowed down by the boom the other ones are still working and so forth to create some sort of flexible uh architecture flexible kind of deployment to to do that so that's the the crux of the idea and uh i just wanted to introduce it and uh to let you know that we are going to try to

to experiment with that and anything anybody wants to contribute to that uh obviously welcome

that's it

Łukasz Rozmej: i have a comment to that so if you are protecting transaction pool you're not really protecting the chain that much because someone can just mine this block and put it directly on the chain

so that's not there yes

i didn't go into detail details on that but uh so if you go deeper a little bit deeper so you can notice that there are two cases that you have to think about first case is where attack is basically performed

by non-miner because they're basically just putting the transactions in the pool and the second type of attack is the attack made by the miner itself and so you need to look at them differently and they might need to have different protections because i think generally the miners are not incentivized to bomb the other miners around unless they are a majority but the people who are not mining they might have whatever completely different incentives

so that

Dankrad Feist: isn't gas our protection against these

those attacks i mean that's exactly right yes i mean it's easy but yes but however the

gas is a very blunt instrument and as we saw

it we we actually do need to uh modify the gas cost quite frequently and a lot of times we have to keep the real reason for gas modification some kind of secret because we cannot disclose that this is because of some kind of this button with this balance so you either basically have to change it in a rush as it was done in 2016 or you have to keep it as a secret kind of or maybe a open secret and then try to introduce the change on the different pretext so what i'm suggesting is that it it does not um it does not negate the role of gas as the protection but it creates

additional layer protection which allows us to be a bit more relaxed about you know those vulnerabilities if they are found we can actually fix them in a good time and we can we could be kind of much more professional about it rather than trying to like you know have these open secrets and stuff like this

um i mean

Dankrad Feist: i guess i feel like it's very likely that you can find some sort of metrics that work well but the concern is like what about transactions that are caught by your metrics but i'm not malicious they just happen to like have very high resource consumption

like you're kind of losing this idea that you can pay for your gas

i would like to listen to uh the other couple of people that raised their hands if you don't mind so i'm we can return to this discussion as well

it was my head sorry uh yeah

Martin Holst Swende: i think it's an interesting idea but i don't and i think it's worth pursuing and exploring i don't think it changes kind of the threat model and i think

because i do think that miners have an incentive to bomb other miners uh because once you start building on top of importing another book that you want to build on top of it's kind of hard to just throw it away and try another buff even if it comes in and once you have spent the minute importing that block why not build upon it so yeah i i don't think it changes anything intrinsically but yeah it will be interesting to see what you come up with

when implementing it okay what about michael yeah i think yeah this is interesting

idea um i was like

Mikhail Kalinin: going to ask about metrics have you thought about it because like first obvious thing is the execution time of transaction but it's too subjective uh what what else could we use is like io or cpu cycles but it could probably be difficult to measure for a particular transaction so what are your thoughts on this

well so basically and

my thoughts actually go very far on this and so in the first approximation uh we could simply use uh some kind of time timeouts and some other limits on the you know when we execute the transactions inside the

perimeter uh we can use uh some kind of physical constraints in terms of like how long is it allowed to run like how much how much state access is performing and so forth and abort the transactions while once it's passed to this limit but on the second iteration which might come later i actually would i'm planning to run some sort of pre-processing on a transaction to try to figure out before even running it on a specific state to actually run to try to figure out if it's possible to figure out to predict whether it's going to hit a lot of state [Music] for example that would catch those those attacks that were published on the on the blog

and lots of others including the ones that we also found which were were targeting specifically aragon and all those attacks that i could think about it that would be they actually all these classes of attacks they could be eliminated by the static analysis uh or by whatever abstract interpretation but obviously that is a bit further away into

it so it might be iteration two or three of this project yes you think

Mikhail Kalinin: i was asking because like after the marriage we will be operating in a time restricted uh environment like this at us more probably than it matters today i mean it could be even like one of the

very simple but effective protection for block proposers so if they see that the block like is not being proposed or it takes a lot of time to execute a block uh they are about to publish

so it probably yeah i don't know um yeah much about it yes and also

you just reminded me on another connection that i uh made yesterday so this is actually so i think it goes into a similar direction as the another trend which is going on right now which is a you know about mev right and the flashbots which is the way of trying to democratize the meb across the ecosystem

and currently the way it works is that you have a kind of independent flashboard runners who are running essentially their own transaction pools to try to construct the bundles and so the the separation of transaction pools from the core has already happened it's already happening in flashbacks mev world and i think it's only natural to to to to to basically just follow that as well so i think what i'm suggesting and what is happening in flashbacks for land is already steps in in similar directions i also think that uh these special checks for the transaction to go through

the pools obviously will increase the latency of the transaction propagation i mean especially if your transaction is a bit strange i mean it's a bit hard to find out what it does and then it takes some time obviously as it hops through those perimeter it will take time but that's okay because uh the kind of the straightforward transaction will go very quickly because you can simply see that they're fine but the the strange ones they will go slower through the pool and they will end up at the minor slower later but if the miner wants to take a risk of taking those things they can simply do it by the flashbacks so essentially it creates it furthers the idea there's two lanes like a fast lane where people take risks and the kind of

slower lane where the public lives where the people are putting their transactions which has all these kind of perimeter protections where the bombs are getting intercepted and and and things like this so this is actually the the vision of the future i have when considering the what happens with the flashbots as well anyway thanks for listening and i appreciate the feedback so far

and with unkrat we can have a chat about it in maybe in telegram after call if you want to

sure could you add me to this chat as well please uh yeah yeah i mean if somebody is kind enough to create the channel for that i can drop in right okay i'll do that oh sure i do not know oh take take it eleven

crypt yeah okay uh so hi guys this is gogender and uh i have co-authored this draft eip with piper and just for this pasting the eip link which is sort of collating uh the transaction level access list which the clients would be generating for eip2930 and what we are doing is we are trying to collect this access list on block level and if you go through so we what we want to really do over here is present the cip and get some feedback again this is nothing we have we don't right want to put anything actionable

on the table as of now uh so if you look at the eip then the ei so eip says that access the block travel access list is sort of a set between access addresses to uh which says which is basically you know what we are saying is that okay this address is accessed in this transaction number and it consumed this slots in that this list of slots in that transaction number so that is sort of you know access list we are trying to build on the block level and then there is a construction for sort of serializing it into a canonical list

and what we are saying is that you know for this list to have any meaning as an index into the block so that you know other miners can do cache warm-up or the people who want to validate the blogs they can sort of you know pre-load or do any parallel optimizations because you know you can look at this block list and you can create a partially ordered set of addresses that are accessed and then you can sort of create parallel computation chains on the transaction so so there are a couple of ways in which this access list can be used and for any of that to be relevant and valid what we are trying to say is that there is there is a need for

excess least fruit we also include it and for that we will have to have a canonical definition of how to serialize the access list and how to hash them and in our proposal what we are saying is we can just go straight for our json string serialization as of now or and hash it with srj-256 and have sort of a url like encoding in which we are also not only encoding the construction type of our access list whether you know we are just serializing it in a normal way or we are sort of forming a country out of it to hash and but we are also sort of saying that you know what but what is so we as we are saying

to two things what is the construction type for hashing and what is the serialization format so serialization format could also be upgraded to ssd and uh hashing could also be upgraded to either carte or it can you know if uh that is an easier way to go about so but but the thing is that you know we can have an upgradation path for these access lists uh over the time without changing anything in the block structure what do you piper

Piper Merriam: yeah so at a high level the details of serialization hashing things like that are all up for grabs but the general thing that i wanted to

propose here is putting this in a subsequent hard fork to get a new field into the header it represents the canonical hash of this access list so that there is a mechanism for us to begin to start um essentially experimenting with with block witnesses at a verifiable level um so that's the that's the general gist uh not the upcoming hard fork but i'd be looking at seeing about adding this after that hard for it to get a new header field for this um anybody have feedback

on that yeah

Martin Holst Swende: um so if i started correctly it is not just about

you know taking the declared access list and collating them into a big heap it's it's about taking the generated access list that were found during this execution is that

great

Piper Merriam: uh that is correct yes uh this is the reference to 2930 is more just because we already have an access this format

Martin Holst Swende: my concern here were something which is not explicitly allowed but you want to use this in some way shape or form for verification witnesses and what i think is problematic is that in the rules of 29

29 if you call something and in that scope it accesses something in the next something else and then it reverts out to that scope then that access list touch it becomes undone so it doesn't actually leave a footprint on the global access list but if you want to execute this in like a stateless way and then use the generated global thing and as soon as you enter this new call scope which will revert you will find yourself in a scenario where it makes an access to which you don't have the data because the it wasn't present

in the in the global list and then it becomes kind of hard to execute from that point on because even though you can infer that yeah probably this scope goes out the gas you can't really verify it because you don't have the full data i think that might be a problem with this

Piper Merriam: um so i guess maybe there's a miscommunication here uh in my mental model of this construction uh storage slots that were accessed in call frames that ended up reverting would need to be included in the access list

but then you are talking about either adding a new type of global access list or modifying the existing one

which means that this cannot really you know utilize the existing framework for got 29.99

Piper Merriam: that wasn't clear to me so that's something that we'll have to dig into uh how hard of a blocker is that for you um is that a significant

difference yeah

Martin Holst Swende: it is actually a significant one and the reason we made it this way i mean it would have been simpler to just have if someone tries to access something or someone actually does and then his scope goes out of gas we just let it sit that would have been easier instead of having this journal that means you could have called into

something at the cost of 100 because you already called into it that could try to touch something else costing two thousand six hundred doesn't have the gas rate because you only specified well zero gas or one hundred or something and it reverts back and now all of a sudden you only paid one hundred gas would call you successfully made you didn't pay the extra 2600 for the call that failed but suddenly you still have this other thing in the access list so that would have been a back door to put anything in the access

list at the cost of

Piper Merriam: got it so the naive approach here would just be to have a separate uh separate tracking for this essentially

um and and and anyways yes so that but this is just me solutioning off the top of my head um yeah but but i can see that that this does not easily piggyback on top of the existing uh framework that's in place yeah thanks for letting me know

uh michael you have a comment

Micah Zoltu: yeah just wondering so do we need to add this to the block header or could we just add a key in the state route essentially

Piper Merriam: i'm not following what you mean by that

i think that is the proposal i think michael suggested that he's just under the state group for that thing which i think is what you is what you meant piper

Piper Merriam: um uh yes i am not just i'm not suggesting we add a big payload of data to the block header i'm suggesting we add a uh 32 byte hash of some sorts to the block header that represents the canonical serialized form of the access list so that out of band somebody could receive an access list or a witness um and uh and and from the witness

construct an access list and then from that or just from the access let's verify that yes this is the access this specific block it's a otherwise you have griefing vectors if we start trying to build anything that really matters off of witnesses because right now you can't verify that it is the witness until you actually do the execution and griefing backers and things like that um there i think there also is benefit to existing clients right now which is that if access lists uh become something that is circulated uh independently then clients could fetch prefetch these and preload states

speed up execution of blocks

things like that

um i have a comment on this but it's kind of again it's a bit more general is that what i started to look at is um you know with the advent of let's say access list and previously different rules for computation of gas cost for different operations which i never really liked um but now i understood kind of how to how i would fix this um and that is i'm going to start writing it soon so we are trying to introduce something called t evm which is basically like a the version of evm that

would be would not have those things like uh self-destruct list access list uh all sorts of other things which kind of goes on top which essentially is that if you look at evm now is that it has a sort of a sort of clear evm which is the certain number of resources it's called stack it's got memory it's got some sort of io which is the storage operations and that is fine and those things are manipulated by the op codes but then on top of that you have ever growing uh sort of what i call the ephemeral structures which are actually kind of also modifying the behavior but they're not really treated as the resources of ebm so for example access lists

and self-destruct lists and now there's uh you know proposals have another one and the all different caches of state which affects the uh the cost of the uh store so my idea is to actually propose the different the modifications to the evm um in the in in form of what i call tvm which actually brings those ephemeral structures into the light which means that assigns a specific resources like i actually see it is the associative memory which actually has its proper op codes to operate them rather than building them as a kind of add-ons to the vm logic actually have them cleanly implemented in the in the virtual machine and i know

it's not it's not a small project but so i finally understood like you know i don't like those addons and then the more these are doms we bring the harder the you know the less cleanly specified the evm actually becomes and as i noted in some of my talks last year most consensus issues are actually happening in these addons not in the evm itself because these are loans a bit harder to specify

you know you know yeah so let's see

Piper Merriam: i don't think that this has any uh tangent or like any effect on execution there's a no proposal in here that this would modify execution in any way this would be something that would be kind of the result of execution so it's more like

metadata about execution

so you're not suggesting uh essentially but then if you if that doesn't modify execution that martin's arguments about backdooring the access list is not valid isn't it right

Piper Merriam: uh i think martin's argument was that in our proposal i believe that we suggested that this framework was already in place in clients and what uh what martin pointed out was that that what clients are doing is not sufficient for what we are wanting to do and so we can't piggyback on top of that

okay

so then in this case i agree that if this uh what you're suggesting is not in any way affecting the behavior of evm then of course it's not an add-on but

it's simply something else that you add to the consensus field

Piper Merriam: yes it is more akin to like the bloom filter

though

Micah Zoltu: does affect the evm so it's in the evm that you have to record those it's metadata you have to record as part of evm execution so like in your evm module is where you're gathering the data and so i think that's what it looks at getting that is those types of add-ons where we're adding stuff to the evm execution is where we're getting a lot of complexity additions into the clients

Piper Merriam: uh correct but this is overhead um this is not uh this shouldn't have the sort of combinatory complexity that things like like this

doesn't affect gas price changes this doesn't affect execution this is uh this is pure record keeping during execution and then afterwards uh you you know serialize it hash it and stick it in the header similarly to how you record bloom filter entries and stick them in the header uh and there was a question i saw come up in chat but i lost it about about why um i but i didn't see

i don't remember what i can i think it's

Micah Zoltu: probably mine um so i was just asking um before i disconnected i was asking why not include this in in the state route just as like have the well-defined path everybody knows that if you go to this path in the state route you will find the access list is there a

situation where we want to be able to validate the access list in a scenario where we do not have the ability to validate the state

route

Piper Merriam: uh yes so if you are fetching state on demand and you don't have that state um well i guess you know there's maybe an argument here that says if you can vegetate on demand then you can fetch but supposing somebody hands you a witness and you want to verify that that they didn't give you the wrong witness or that they didn't give you extra you know they're not griefing you in some way they didn't um then having the access list is a a mechanism for verifying that

it doesn't bundle the protocol to the business format itself so that's kind of why we do

access list instead of business so should wouldn't when the person hand you that witness bundle it could include a proof of the um a proof of the access list along with the proof of all the state they're giving you right fair so given you a bunch of proofs sure so so i'll say um the

Piper Merriam: my preference towards the header is near convenience but i recognize that changing the block header is uh is complex and so i'm absolutely willing to uh like like i would put that just down into the do we use sse or do we use a tree to canonicalize and have the access list so i'm happy to have

that discussion i'm not married to one or the other um this is more about i'm curious if i'm going to get resistance from this since we don't have stateless right there i'm wondering if somebody wants to make the argument we shouldn't do this because we can't use it yet but my argument here is that we need to start using this stuff so that we can start understanding how we pass witnesses around start experimenting with them and start being able to build things ahead of the ability to do uh formal fully protocol supported statelessness

um i think

Tim Beiko: so we just have a minute left uh so

i guess it probably makes sense to move this conversation

i think

Piper Merriam: totally we do not have to to resolve this i'm glad that i got to put it in front of everybody and the eep link is out there so please go let me know what you think

Micah Zoltu: what channel

should we talk to you in about this uh witnesses would be a good one in r d okay cool um and yes there is also eph research link also mentioned in the eip so if you have any comments you can drop in there okay awesome um yeah just uh somebody on the youtube chat said my mic cut out for a quick moment during the call

Tim Beiko: so just to summarize for the viewers

the london stuff uh in case that was not in the recording um so we're updating the 1559 spec we're gonna start the new devnet calaveras which will have the fix for 15.59 um focus on that over the next two weeks have the client teams kind of finish their implementations especially regarding the transaction pool and then in the next two weeks uh depending on how how that went we can figure out what we do about the public test nets and when we want to fork those um yeah that was pretty much it thanks a lot everybody for joining and i will see you in two weeks

thank you

[Music] [Music] [Music]

[Music] [Music]

[Applause] [Music] [Music] so

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

[Music] [Music] [Music] [Music] [Music]

so [Music] [Music] [Music] so

[Music] [Music]

[Applause] [Music] [Music] so

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music] [Music]

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

foreign [Music] [Music] [Applause] [Music] [Music] you

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