All Core Devs - Execution #165

Transcript

thank you [Music] [Applause]

foreign

Danny Ryan: this is all core devs execution layer meeting 165 this is issue eight one five my chat's going through no can someone's here oh that's okay anyway double that angle difficulties um but we can keep moving um anyway this is issue 815 on the PM repo and I am subbing in for Tim bako today all right looks like we have is somebody from the dub sorry yeah yeah yeah cool okay so the

first thing up is we do have an SSD impact analysis uh that was done by dadab um if you all want to take it away you can screen share

and give us a give us a look

Neville Grech: sure thing thanks Danny let me just share my screen all right so uh thank you for hosting this uh this meeting and inviting me here so uh over the past three weeks we've conducted another study um this one has to do with the migration

of the rlp format to SSD of some MPT commitments which are stored in the receipts and transaction route respectively so um this is obviously your work with some of my colleagues one of them is is on this meeting as well um yeah so what was the original scope of the study so the um the issue with you know making changes to um execution layer data structures in the block header is that so there's some protocols that might

actually be using these and Performing proofs on top of these um so these two EIP so that's 64 66 and 6404 um are you know migrating the the encoding from this from rlp to SSD um now what is the impact of such a change on these protocols we've tried two different approaches for completeness so in one approach we've analyzed all smart contracts deployed on ethereum so we have a data set for that on contract Library so the static analysis and the other approach employed Dynamic analysis

so we actually looked at the transaction behavior and try to determine whether there were smart contracts that are actually doing you know verifying proofs over these data structures yeah so and we are already had an idea that perhaps you know the centralized Bridges might be doing this sort of thing but you know over our you know over like a couple of years ago we also saw like you know historical blockchain events oracles and other weird stuff that cannot be discounted so we found you know and examined these these projects um and try to determine what is the provenance of this rlp encoded data is

it coming from Layer Two is it coming from layer one itself now note that um you know in this meeting we're deciding uh discussing whether to you know make changes to to layer one but not Layer Two so if you know layer 2 changes then it shouldn't affect I mean it shouldn't affect uh you know decisions that are being made on layer one um yeah and then of course there's you know other other things like for instance is some of the data being relayed via centralized um centralized Keepers and things like that so you know if there's some element of centralization through which some of

these data is being passed through then perhaps even if you know the changes are being made you know the centralized systems can be upgraded okay and of course all of this study has been done on you know recently used or high balance or part of non-protocol contracts now this um if we determine that the protocol was affected we explored you know upgradability options okay so to get into a bit uh more detail about the um the effect of the changes so here's the ethereum block header

here's some of the fields um there's three routes there there's a state route which is a root Hash a global State also include coded using a Mercury transactions routes and receipts root again so these are roots of Miracle trees containing transactions and receipts respectively so 6466 is changing the encoding of the transactions from rlp to SSD and in case of the receipts as well so this will obviously make a a

big difference to the to the hashes that are are going to be calculated so if there was some smart contract which is actually re-verifying these than um those will will actually be broken so throughout throughout these three weeks we've determined that actually there are three protocols that um will be affected by this so one of them is is layer zero and in this case layer 0 is also being used by ZK Bridge in some way so you know both of these

Protocols are affected you know specifically um the um one of the light nodes is is being used and it's going to be affected in the case of telepathy which is doing the doing very complicated things that is also going to be affected um now in all three of these protocols we've also found out that there are and in all cases only eip6466 so the receipts route had an impact now the estimated impact is you know subjective um but um so for instance you know the

the subjectivity comes from the fact that you know how can we determine whether the the protocol is easy to upgrade we're not exactly sure how easy it is but you know we've we've seen that for instance if they're using um you know certain software engineering patterns we know that they're upgradable um how often is the protocol used um and then you know especially on the more complicated protocols there's you know alternative configurations and some configurations the protocol is affected and some it isn't now most importantly um before we started the study um we already had an idea that perhaps you know some some of these

decentralized Bridges like like an optimism or polygon there is a possibility of them being affected and indeed um you know these Bridges were being flagged up time and time again in our analysis because they were doing proofs of rlp um encoded commitments and um but in actual facts these are not being affected I mean these these were out of scope because in both cases for instance polygon and optimism um the data was coming from Layer Two and being verified on layer one okay

Danny Ryan: do we know

when data goes from layer 1 into Layer Two are they utilizing um the the layer one commitments or do we is that a blind spot

Neville Grech: so what we did is we we looked at the protocols that were deployed on ethereum but then most most of these larger protocols they would have um you know similar contracts on other chains so when we found that um they were actually doing um the you know verifying these kind of proofs on layer one from layer 2 data we also checked on the other chains whether a symmetric thing is also happening

Danny Ryan: right

Neville Grech: uh and in this case we didn't find that that was happening but say for instance in the case of layer 0 we did find that that was happening

Danny Ryan: okay thank you

Neville Grech: okay so I'll go into uh to the two different approaches we used so we used the static program analysis um we were very literally try to find just by looking at analyzing smart contract byte code uh just to be like fully complete whether the byte code we're implementing you know rlp decoders and using that say for instance in Miracle tree proofs now it looked a bit daunting at first

but we actually did manage to mechanize an analysis for identifying these and the um the main Insight from this is that all of these RP libraries if they want to you know decode rlp correctly they need to actually contain some constants such as the ones that I'm selecting here because these are actually needed because you need to do comparisons or you need to subtract these constants to get for instance length fields and things like that um so we what we did is we try to see whether there's like patterns such as for

instance you know the variable is being compared to a constant in either direction and things like that so you know in multiple different ways and it turns out that you know this analysis yielded quite a few contracts and you know I'd say most of them were they weren't actually false positive indeed you know having you know combination of those constants being used in Expressions such as comparison expressions and then using that to you know decide you know which which part of the loop to execute and things like that it was basically an rlp decoder

now uh one other thing we did is because um ethereum bytecode is you know doesn't have variables um what we did is we the analysis was performed on a lifted version of the bytecode so in contract Library we we have this constant data set of decoded smart contracts and sorry um decompiled smart contracts and they're be compiled up to various levels and one of those levels is three address code which is very faithful to the original semantics of the bytecode but it's it it contains variables instead of you know stack operations and so once you have that and it is easier

to you know perform comparisons um you know looking at certain patterns in the code and of course you know there's other things you need to do so the the compiler generates a lot of code which needs to be optimized and things like that and you know we had analysis passes to to de-optimize some of the codes it's you know it wasn't work which was conducted for this but it is a data set that we're constantly analyzing you know for security vulnerabilities and things like that okay so um we've also tried the second approach um to find you know affected contracts

and the reason why we wanted to try two different approaches is so that we can get kind of like more confidence out of the you know data sets and you know be sure that you know each approach has its own blind spot but you know we combine two approaches together uh you get better results so so biodynamic analysis what we actually tried to find is identify contracts specifically some functions within those contracts that received rlp encoded data as part of their call data it's part of their arguments now how do you do that reliably in order not

to get a lot of false positives not to because what's special about rlp encoded data um and we will see in the next slide um assuming that the rlp encoded data is of type bytes then because of the way Abi encoding works so in API encoding you'd have the first four bytes being the selector and then you've got chunks of 32 bytes being individual arguments now when you have something of type bytes apart from having a pointer to where the bytes start

right before the actual data in that byte array starts so I'm putting my cursor here right before that you have a length you have the actual length of the um you know the the array in the next 32 byte and chunk and so on and it also happens to be the case that rlp encoded data also contains a length field and it's you know frankly encoded because you've got the first byte to give you the left yep

sorry that's just somebody I muted I muted them all right no worries yeah so the um the first byte is actually the length of the length and then you've got the actual length here of course there's like differences here but you know if you go through you know as we did like all the call data over a million blocks and you check for these like heuristics like this we ended up getting a a pretty good data set of around a thousand smart contracts that were actually doing RP RPD decoding now there was also a source of

um false positives in this data set because there are many contracts you know such as for instance unismol flash swap or things like that that just relay the call data from one contract to another without actually interpreting it and so what we did there is we um we actually assessed for every smart contract for every pump public function that it implements uh the number of times it actually is receiving rlp encoded data in its argument so if it was receiving more than RP encoded data on more than 10 percent of the time that it was being invoked then we we put in the data set to be inspected later

so then what we did is we combined these two data sets and we we found out that it's mostly the same contracts that were being flagged and um we inspected the most popular contracts out of these out of these data sets a lot of contracts and big protocols were flagged you know as I said before you know like like polygon and optimism um a bit torrent and you know many other protocols and then obviously there were false positives as well but I'm just saying you know like um contracts or protocols that are decoding are LP encoded data but most of

them we found out by painstakingly going through each one of these contracts you know one by one trying to understand the protocol um there was always some reason why this particle would be unaffected and these are the three reasons right so one of the reasons was that the protocol didn't really do MPT proofs over this rlp encoded data even though they are the the data was rnp encoded um you know such as the case of for instance when you have uh flash loan contracts or things like that which which relay um call data arguments so the second case which is the most popular case is is that a contract was

actually doing uh you know proofs but the provenance of this data was coming from Layer Two Chains or other side chains and then when we looked at the same protocol um again on other chains we didn't find asymmetric relationship there and then finally the protocols we're doing uh you know proofs over MPT commitment but they were unrelated to win scope imps the IEP such as for instance um you know the state route or custom data structures that were being created from centralized systems um and so you know this wouldn't be

these wouldn't be affected yeah so the important unaffected protocols that we found so these are unaffected where where polygon Bridge optimism and bittorian the bridge so Victorian Bridge um was mostly used between Toronto I believe and ethereum and you know we didn't find a symmetric path where um you know like the implementation on the opposite chain so the chain to which they were bridging to um what's doing it like like similar

proofs as was happening on ethereum interestingly there was another protocol called telepathy which we marked as being affected but in many cases it was being flagged up as doing rlp encoded um you know proof commitment checks but these were on the storage route but then there was part of part of that protocol doing that on on the receipts route as well don't say something um okay all right uh so so yeah I mean these are the affected protocols so I'm going to

give an example here and they are zero um this did exactly uh here on layer 0 which is validating um one of the proofs and the data is stemming from receipts root in the second case ZK Bridge was integrated into layer 0 as an oracle um and you know in some cases we found that it was being configured with with the ultra right node in layer zero so that's also affected and in telepathy that was more complex

yeah indeed so

against iron and yes I was one of the collaborators that worked on this report but never and indeed telepathy was a very different based on the other bridges in the sense that it actually uses consensus layer data but um it turns out that they depend historical summaries field on the historical Summers buffer which uh contains commitments from execution layer uh and which of course right now are a function of a seeds root so when this changes uh they will also be affected because they

assume the data in the execution layer blocks are assessing a rnp encoded so changing battery will affect the smart contract

Neville Grech: so yeah and of course it was also being flagged up for things that that were unrelated as well okay so so in conclusion you know just just from you know what we found out we think that the impact is overall it is moderate but in all three cases we found you know upgradeability possibilities um now I I gotta stress that rlp encoding um on and then you know like reproving

MP3 commitments happens a lot on chain um and it's actually took quite quite a bit of time to go through and filter out you know cases where um this was going to be affected versus not most instances were indeed unaffected um in all three cases that we found in layer Geo for instance the default inclusion Library can be upgraded and ZK Bridge you know with layer 0 fixes this then it's going to fix DK Bridge but you know they can also Implement their own proof validator which might

add some technical debt and again in telepathy they can also upgrade the inclusion proof logic so uh thank you do you have any questions and also you can find the full report I'll share it with you on on the chat and and also this presentation as well

awesome thank you I have a quick question given your the tools analysis and some of the kind of heavy filtering you had to do to remove uh what we think are false positives what are the chances we miss something what's the confidence level on

completeness here

Neville Grech: yeah so um the reason why we we did two different approaches is in order to maximize this now if you want to be even more rigorous than this theoretically you would have to go through every single chain that we know about and repeat this on all the different chains now the problem with that is that you know you will flag similar contracts but they will not be exactly the same perhaps and so again you have to do a lot of inspections of all of these contracts we did a little bit of this so specifically

we looked at a sample of so we ran one of the dynamic analysis which which was easier to run on multiple chains we ran this on a sample of BSC data we run a sample on on Phantom data as well but essentially I mean what what was happening is that these these protocols were deploying uh you know similar contracts on on different chains of if you find a contract which is doing that on ethereum you're more you're most likely going to find the same contract doing it on other chains and it's probably the case that there weren't you know protocols bridges

that were being developed for other chains with no similar symmetric contracts on ethereum

got it other questions

Łukasz Rozmej: yes if we're talking about other chains and coordination right because this is not a blocker for us or anything do you have the tools for this analysis available for them

Neville Grech: um yeah so part part of the tool chain is open source but you know another part is closed source so you know we can you know give you accounts for instance on on one of the tools we have internally called Watchdog and some of the analysis can be repeated um again so so on the other on the other chains we're limited but on the ethereum Chain we're we fully support that

Łukasz Rozmej: and second question so if I understand the conclusions the conclusions are there is no blockers but it needs a bit of coordination uh when doing this upgrade with all affected parties

Neville Grech: yeah I I would go with with these three

affected parties I think layer zero already knows I mean they've they've they've read the or some of the developers have have read this already and then you know the other two we can we can contact them as well and I guess you know the uh the news will spread as well we'll also put this up on our Twitter account you know maybe we can do the same thing on some of your accounts but I I don't think we'll find um a completely different protocols they will be similar to what what these Protocols are doing

Danny Ryan: great thank you any other questions

okay I appreciate it we dropped the link in the chat for the full report uh check it out obviously this isn't something we're making a decision on today but this is really good information to help us make decisions in the future there were a lot of discussion points in the chat is anything anybody want to surface anything for this discussion now okay great thank you for the detailed analysis um next up are just general Dan Cancun updates

um any test net updates that we want to relay or other updates relevant for today

Parithosh Jayanthi: yeah we have um devnet7 up and running since last Friday and just the test now it's been finalizing we've also submitted a bunch of blobs to it and triggered um at least one or two issues in the test map um I think some of them have already been patched and some are still open there's an issue tracker so please refer to that for more details and besides that once we have all the patches put in we're gonna just continue spamming the network to see how we'd perform with the three six blobs being

full all the time so far we've headed for short durations of time but we haven't had it for a longer duration of time and there's a message from Justin from the security team about a deposit processing issue um if someone from teku could have a look that would be great or I think Techo and prism could have look that would be great

Danny Ryan: what layer of the stack are we seeing were the couple of issues is networking consensus

Parithosh Jayanthi: I'd say it was networking issues um I think Mario's has a lot more information on that and if you want so expand on that election

Marius van der Wijden: yeah so uh gas had an issue with European coding of the transactions on the on the networking layers so uh transactions weren't relayed correctly the that was fixed now so it's that was the only thing like it like transactions between guest nodes were were were relayed but not with the others and the others implemented this correctly so

Parithosh Jayanthi: I think there was also an issue with um the message size right with the two long messages being requested

Marius van der Wijden: um yeah but this not really something that we can change on our end basically we can just say hey give us give us messages give us these messages um and the someone on the other side has to respond um there was an issue in Geth where we would we would not tell the other nodes the correct size of the messages I don't think anyone is really like has implemented this this part where we

really use if 60 like the new e68 mechanism to say um to filter messages and say okay we now want block messages or we only want messages that are smaller than X so yeah that's something that still needs to be implemented I think some clients even might even um still send blob messages over each over other protocol versions I think especially ethereum JS because they don't have e68 yet so either they are not

not sending any block transactions or they're using e66 which is not good

Danny Ryan: okay thanks for the updates um any other

yeah another mindfulness uh an issue would you almost have a fixed as an image we'll deploy it soon it is connected to message size uh which was mentioned right right

so let's fix themselves away

Marcin Sobczak: we have a mechanism of limiting uh size of transactions which we are handing but we had a bug in calculating size like length of block transactions and it's already fixed will be merged in a few minutes and probably image for that that seven will be updated today as well

Parithosh Jayanthi: um assuming that all the fixes are in and devnet7 is relatively stable do we then start planning

would you guys prefer that we start playing the next one with all the other eips or should we continue just keep in devnet 7 Up and stressing it more I'm not sure which approach we're gonna take right now

Danny Ryan: I know on the consensus layer at least a couple of teams have voiced the desire to move towards the full feature set for the next test net but in terms of the timeline if we want to stress devnet7 and there's some some iterative pure 4844 uh updates that people want to do then you know that that makes sense so preference for when we move to do so but I don't know if there's a Time preference for

when we move

Marius van der Wijden: we don't have 4788 yet in in the code and I think at least one or two other eaps I would rather use this time to uh to stress test definite seven and in parallel work on work on getting those other things in and and not wait with the stress testing until the next

definite

Parithosh Jayanthi: how about we add all the tests required for the next devnet onto Hive so that we

can already anyone who's ready can already start testing and making sure I have the screen and in the meantime we keep that Net 7 around at the stress test seven at seven that'd be a good doesn't block any one approach

Marius van der Wijden: sounds good to me

Danny Ryan: yeah I think so we don't need to be setting the date for the next test snap but allowing clients to be in the position to move there Mario

Mario Vega: yeah do you mean uh with the high test do you mean um the EIT tests or the for example the dev uh the peer-to-peer issues tests or both of them

Danny Ryan: yeah because ultimately both uh starting with consensus and then moving to w2p makes sense unless you think otherwise

Mario Vega: uh yeah we are still working on having all the atheists um I think a couple of next weeks uh we should have them already for testing yeah sure and I would I believe the eip's are going to be

dominantly

Danny Ryan: kind of consensus assess rather than the P2P test in terms of the workload on your end contrary to

444

Mario Vega: yeah definitely I think I think foreign

was like uh one-off um because because of the different transaction formats that we used uh in the in the header versus the the peer-to-peer um so that's not gonna be an issue for the other areas yeah

Danny Ryan: yeah so Barnabas just to Echo that obviously unless major issues are found with devnet7 and pure for before testing the intention is that the next devnet would be full featured for dencoon um but we're not setting a timeline for that Nest test net we're gonna allow

people to develop the full feature set while stress testing

Parithosh Jayanthi: I'm talking about issues with two four slash three six we only had three six for a short curation so I think it's too early to make a call on either one

Danny Ryan: cool and we can on Monday we were before call we can spend some time talking about uh if there's networking stuff the surface looks like Nimbus is having issues but we don't we don't really have Clarity on if on our small test net three sixes

changing the impact uh but we will continue to bring that up either on the call or before on Monday if we have time I mean if we have information or on existence clear call next week and Barnabas just for your information the latest consensus layer spec release and test uh does have the full feature set on the consensus layer so if you're building the spec for that devnet you can point to whatever the latest releases

Barnabas Busa: great thanks

okay other Dan discussion points

wow did someone on mute okay good

Danny Ryan: moving on uh there's an item from the Snake Island myself a should override Builder flag and being introduced into the engine API um this was discussed something since their call last week and uh General consensus that getting this flag in the engine API is high priority for them and very easy uh it's because it can be introduced uh and

um always sets a policy execution there and a no op if they feel like Lincoln says there so you can kind of introduce the flag and then add feature functionality to it over time uh but Mikhail can you give us the information on this and what people are thinking

Mikhail Kalinin: okay so I'll just quickly go uh give the context on on this flag and then the discussion on whether it glued it into Cancun so uh should a ride Builder flag and the proposal is to add this flag to the get payroll response is basically true or false this is the way the El to communicate to see all that there is some censorship is

happening in the network and cl should make its own decision about that so the way um the way it's supposed to work so yeah we'll have some heuristics uh and uh to find the evidence of censorship transactions censorship in the network and according to this heuristics made a decision and returned this back with the build payload so we if we were client diversity for implementing this heuristics so so they're completely unspecified for this reason and also if El does not implement the any of the heuristics it should always return false

so yeah as the instead it should be in all and also consists their client uh should may also ignore this track even if it is sad the truth so it's completely free process for both parties and consensus they may use other sources of uh this this to feed it into their decision-making process about censorship uh so the the main reason why this flag should be returned by El is that El has information like mempool and the reworks which is uh a pretty big chunk of data uh that it does not want to expose why any API and it doesn't make sense to to

be exposed so that's the way it is supposed to work and getting back to to the Cancun so we want to include this into Cancun as Dennis said the sale clients are on board with that and considering that the engineering complexity it's really low and also we have a prototype in Geth of those heuristics virus can give more details on that so considering that the complexity is low and the utility is quite high of that flag so the proposal is to make it into that's basically it

Lucas um so my question might be premature

maybe Mario's should come first but the question is what's the status of research of this heuristics and are there like many of them proposed are there are they in any way like stacked on historical data right against historical data and my question stems from actually client diversity so think that a client would implement this in a way that would plug a lot of false positives right and then stakers might be discouraged to

this client because they would get lower rewards so it may affect like uh this kind of things too so hence my question

Danny Ryan: I suppose in theory that is possible you know if you always if you had a client that always said true and you could never write that and UCL listened to the El you know in the extreme obviously you would have lower words that said I know there are discussions of a number of simple heuristics for example um transactions sitting in the mempool for X time that certainly could have been included profitably in a block

where you know these end up looking like pretty deterministic uh but I also you know this is primarily to elevate the El to have a voice in you know the fallback functionality um you know and there's any number of reasons even Beyond censorship that you might uh perform such fallbacks but are there any are there any write-ups or deeper discussions of potential heuristics here I know potos has thought about them

Marius van der Wijden: so um I have not really thought about it I just implemented this very simple

heuristic if a transaction has been react out at least two time no three times um then we suspect that someone is um censoring um it uh this is just the first heuristic that I thought about um so it's not not back tested it's not not really yeah it's just something to to prove that it's actually possible to implement this and and and and and show that it's

very easy to implement those heuristics

because

Łukasz Rozmej: uh so okay let's say uh someone New York transactions three times you have this uh like you you managed to find this out and so for how long do you return

the slack

Marius van der Wijden: uh forever afterwards

Łukasz Rozmej: okay that's probably also not optimal

Marius van der Wijden: no as I said this is very much a draft of this uh of this concept um it's just to make sure that this concept kind of works

Danny Ryan: um yeah I mean and and defining optimality is

certainly up to the client right like if you have any heuristics go off you can flip a coin also good idea ways if you are concerned about that to delay those concerns go on sir

Łukasz Rozmej: good idea from Ben that if we have empty blocks fairly empty blocks that could take transactions from the transaction pool but didn't right so someone is trying to uh like tensorably block space in in general not certain transactions good idea for a heuristic

Danny Ryan: yeah I mean I guess the way I think about it is primarily this the El has a

lot of information this gives a way for the El to give an opinion to voice something about that information um you know and and because it's very wide open then you know you know you have the faculty to decide how when and if to voice that oh yes yes

Łukasz Rozmej: I'm totally agreeing with the concept right uh the concept is great and we should implement it ASAP and it's very simple because we can right now just returned false for some time uh just wanted to highlight that this opens quite a not trivial uh problems uh that may have better or worse solutions that in my

opinion need some res maybe needs could uh could be helpful to have some research on that's what that's what I meant agree

Ahmad Bitar: um one thing that I noticed also about the code I'm not entirely sure about it but I was thinking that if someone posts a transaction with a bit of a low fee or a low uh priority fee and that's the reason why it's not included uh with the current approach that Marius has this might flag as censoring when it's actually not

no no

Marius van der Wijden: no it's

um like this only tracks uh if a block gets like if a block gets react out and uh like we see three blocks in a row getting reoped out and they mean they contain the same transaction then we suspect someone is doing

Ahmad Bitar: so we're talking about only reorging not

not being included the the heuristic that I implemented yes

Danny Ryan: so the main question here is is anyone opposed to getting this into the engine

API spec it is a single uh Boolean flag in one method that other than implementing the engine API you don't have to do anything immediately um this would probably be slated for that full feature devnet that we're talking about called devnet um Xeon opposed to that we have support uh from the consensus layer teams Mars right now we do not have the IEPs for the engine API the engine API is more of an implementation detail around the outer consensus spec but I'm uh I'm not sure if there was

Mr sarcasm or not good sorry

Dankrad Feist: what are we going to do with this flag when we have it

Danny Ryan: in the event that the execution layer says true the consensus layer can decide to fall back to local building instead of that booster any sort of X outer block building

Dankrad Feist: oh but sorry that's that doesn't I mean okay so but then marius's approach of detecting it doesn't make sense because he is detecting it using reorg blocks right

Danny Ryan: right so implementation that okay all right go ahead we can debate we can debate that right because

if the if the attacker has the ability to reorg then they're going to just reorg it again um we can debate the technique yeah

Dankrad Feist: I mean yeah so like I mean I think like such a flag only makes sense if you can detect an attack and you have a remedy for that attack like yeah if like we can if we can detect block Builders are not including it then that flag might be interesting but if like we're detecting something completely different and extrapolating from that oh censorship is going on then it doesn't make sense to like affect this part of like I don't know the two that don't seem to be

Danny Ryan: there are many other heuristics that do not involve reworks you're right there is a Nuance

Dankrad Feist: all right but I'm simply saying like I mean it definitely has to

be one of those like otherwise it doesn't make sense to me

Danny Ryan: agreed I think the most obvious ones are monitoring them pool and with respect to what was included in the main chain and that does not have to do with reords and can allow for something uh there might be

Dankrad Feist: in that case you have to make a judgment about the tips but I think like you can say if transactions with lower tips are getting included um then then you could like say a censoring attack is probably going on

Danny Ryan: but I do think we you and I agree that

there are techniques that are valuable here and relatively simple

Marius van der Wijden: and this this also I think this heuristic was uh kind of naturally grown and in the beginning it was just um just a log output if we have this if we see this case basically just an indicator that the censorship going on and for that one the heuristic was fine I agree that for falling back to local block building this heuristic is

not really on doesn't say anything so yeah as I said the the heuristic was something that was thought up in like five minutes just to see that the concept works

Mikhail Kalinin: so yeah thanks a lot for the discussion recapping uh if if there are no if there if there is no opposition on the call if anyone listened to to us and has an opposition to this tiny change please express it in the EAP or sorry in the QR yeah we have no idea for that and uh I

will be aiming to merge this on next Monday that's the plan

Danny Ryan: great thank you Miguel okay um next up 478 bounded storage has been merged Alex do you have any thing you want to discuss here

Alex Stokes: uh not really I mainly just calling it out uh we've kind of had a little bit of back and forth on the design uh and the pr that was merged is kind of the last uh or sort of you know the product of

all those conversations so basically it's storing blockers from the beacon chain and the storage is now bounded using like two ring buffers and yeah I'll just point you to the pr uh if you want to see the details a few people have implemented it and said good things so sounds like this is uh the way forward for this EIP right now

Danny Ryan: great and this had no impact on the consensus layers

book yep

Alex Stokes: yeah that was that's been handled other places uh there's uh support for an engine API so that's all set and then yeah all this was really doing was just changing some of the implementation

details of the actual pre-compile but otherwise same basic idea

Danny Ryan: yeah great any questions for Alex um that's all we have on the agenda for today are there any other uh discussion points announcements concerns at this point okay thank you everyone uh I believe Tim will be back for the next version of

this call in two weeks talk to you all very soon

Pooja Ranjan: thank you

thank you thank you thanks so bye

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