RollCall #6

Transcript

but yeah welcome everyone to roll call number six that is issue 1071 in the PM Reaper Link in the chat um first thing to touch on is the blob basy Spike that we saw on June 20th um I think uh I mean first of all this was largely something it was due to organic demand um like this was just genuinely people using the chain as intended and L1 responded as expected uh which is good to see from an L1 perspective but obviously sucks if as

an L2 you ended up way overpaying for um posting blobs in a certain amount of time uh if that wasn't what wasn't intended to do uh I think as many people are aware here um we have uh a the D upgrade coming up in Petron L1 that's EIP 7594 which should hopefully help alleviate some of these things um and there was a Rak out call yesterday on uh pias and um one of the topics discussed there was potentially not

having uh the target be half of the Max um which depending on how we set parameters there could also help um I'm not aware I wasn't on the score I don't know if anyone here was does anyone know what the current idea what the current thinking is around Target and Max uh I'd like to just point out that the I was I was looking into the blob incident and um I don't think the L1 was working as expected um I found an issue with how well I guess it depends you know where you where you say the issue is but the way the transaction Pool Works um is

it rejects transaction blob transactions with gapped nses uh in the way op stack Works anyway is it only sends Batcher transactions from a it only accepts them from a single address so when the Batcher Gets behind it will submit multiple transactions um with consecutive nces uh and ordinarily that would be fine but it also turns out that g has a non-deterministic order in which it announces and requests blob transactions so if it were to request them out of order um one of them would be uh immediately rejected and then no not further propagated uh and so I believe that was leading to um propagation issues because what we were seeing is we

were continuously increasing the priority fees of our transactions and they would just kind of disappear um and I believe this is the cause of it uh I I've posted a a PR for GU there um I don't know if that was affecting non op stack chains but um I'm pretty sure it was a pro affecting our ability to land transactions anyway especially when it started getting behind um we had our system configured to submit up to five transactions at a time and and of course the more parallelism you have the worse this issue tends to impact you so just a recent finding I wanted to share I don't I don't know if it affected other chains but it was certainly a big issue in base um we had um you we were perhaps I think

3,000 blocks behind at one point trying to catch up and and that is act why we ended up overpaying also because at the point we started posting the Bader transactions we were including L2 transactions that had been submitted much much earlier um and were only charged for a much lower blob based fee so all these kind of conspire to just U um just kind of fed on into each other okay yeah that's definitely some interesting things yeah andas is there is there is that um is the non-determinism issue only um is that specific to G or is this also a

case for like bzo um I've pinged the nethermind folks uh uh I've ping the W folks I haven't um asked more broadly it may well be an issue um the other issue with G is it also was not requesting blob transactions right away so this exacerbated the problem it would basically um wait half a second after the announcement before fetching The Blob transactions which is kind of how it treats non- blob transactions because it's waiting for them to be propagated automatically but blob transactions aren't pre um broadcast so that was another uh factor in as well so basically it would wait till you know it got several announcements and then by that time the non-determinism was much

more likely to happen um so so that problem I think is specific to gu um at least it wasn't in nether M and it wasn't in WTH but the non-determinism part I'm still I'm trying to understand that and I've reached out to at least those client teams but anyway that's why I wanted to socialize it here a little more light Cent as a resident gu expert uh and comment on the chat do you have any thoughts on this I haven't looked this a whole lot but it makes sense to me the pr and I think that will merge this soon okay cool thank you um so it sounds like this is the the the the issue here

is primarily due to the non-determinism am I understanding correctly like if if if the the not the not allowing non scaps is generally okay if we could at least have determinism in how they were fetched I mean that'll certainly help I mean because it's networking you're never guaranteed anything um but yes the that in that PR exactly the fix is just that to just try to always request it in order and I I think that's probably good enough but you know getting rid of the nun Gap rejection would be another fix as well but obviously that opens you up to some denial of service issues so yeah and I think that's the bit of the spikiness around the meole and how The

Replacements work and and all of that for dos reasons I think has also produced a lot of the pain that happened during this event uh things like needing to double the fees um to to to replace is yeah not great but needed on the other one side just a quick question my stupidity um why are the blob transaction not announced just regular um transactions why are they not broadcast you mean yeah immed it just because they're much much larger than ordinary transactions and so we didn't the decision was not to eagerly um broadcast them which results

in some amount of redundancy so by not broadcasting them you're you're guaranteed to only fetch it once minimizing your would it make sense to have a to have a um to have a um um to have a um a digest um prodcast so so then you fetch it but at least you know that it's there so you're not running into into that into um into that issue that you're all of a sudden like oh wait like 10 transactions uh yeah that's not a bad idea there is this metadata that does come with announcements right now it contains um the transaction type as well as the transaction size but it does not

include for example the the sender and nuns um but you know not sure that's going to be necessary perhaps we'll see after this fix whether we encounter similar issues so one of the other proposals that's been floating around or one of the other things has been mentioned a bunch is the fact that because you can include multiple blobs per transaction becomes very hard to pack blocks um from like an aback standpoint and additionally I think that's a large cause of the uh conservatism with which

the l1s are treating The Blob mle um obviously it's not a like longer term fix but like would people or is there any interest in potentially having some like agreement amongst l2s to uh not post multiple um blobs at once per transaction would that be something that people would be interested in uh obviously it means that you can't amortise the uh the base transaction fee across as many blobs uh I mean I think that's something we would be open to um in fact we did try to turn the number of blobs per transaction down during the incident

thinking it would help but unfortunately because of the other issue I just described it made that one even worse uh because we had to submit more parallel trans transactions at a time um but once that issue is fixed I think that is a reasonable thing to um to implement right now I think Bas is submitting five blobs at a time um it usually means we're paired up with Tao which is usually sending one blob at a time pretty consistently um but this is a parameter um no issues with with changing it it still works yeah I think I I I I think it's largely a case of like um it might not necessarily be like it's not necessarily helpful if only one or two people change but if we can get most people to change and it makes it much easier to make these decisions because I

mean sure the napsack is one part of it but if we can just be more conservative in these things then maybe we can change the mol rules around how these things get uh like what's required as a replacement fee as well I if you only have one blob then you could have a a low replacement fee or has also has been discussed having another end point which doesn't replace the entire transaction but sort of just the header with the priority fee but I think that would be a bit more invasive okay um one of the other interesting things I found out with doing a bit of digging here is I think

um some have been pointed around at uh FL Bots for Flash bot is builder for not accepting blobs um as a compounder on this uh but doing a little bit of digging looks like flash Bots is only at 2% of blocks so I don't think that has a major impact on the total amount of chain through put although obviously not good to have and they have subsequently started accepting blobs again it's just interesting to see okay um they claimed it was a bug um and that it's apparently been fixed um but what I've been sort of tracking the

number of blocks with zero blobs um and it's gotten better it was 40% during that incident um and now it's 36 is percent um so it is dropping actually I just checked it right now it's down to 34% um so it does seem like some Builders are being a little more eager with blobs which is good news MH um do you have data into that per Builder no I haven't done any recent analysis breaking it down um we did it for the um during the incident but since all I've all I've checked is to make sure that flash Bots started to accept them they they definitely have I've seen

data where they have um y yeah I'm just curious us to see what's the remaining 34% or whatever you mentioned yeah I don't have the breakdown unfortunately okay all right uh any further items that people would like to discuss on this topic NOP okay moving on um there's um what was this uh alas uh wanted to raise some uh his rip on l1s load but I don't believe he's on the call or anyone

else who wishes to speak about that this was proposed by Ice melon but I speak on his behalf oh okay cool yeah uh do you want to speak about that for a little bit uh yeah I have a short presentation if that's okay I would share my screen and go through that yeah sure that's fine like I don't have permission yet to share you should know okay uh can you all see my screen now yep Zer okay thanks uh I also share this

presentation in the chat for your reference so hey hey everyone I'm Peter from scroll we recently proposed R 7728 called L1 pre compile so I want to take a few minutes to walk you through this proposal uh the idea of this precompile is to make it easier for L2 deps to use use any L1 State without you know having to care about MPT proofs uh we do this by introducing a new pre-compile that we call aanas load and basically this is just a simple interface over it C Storage at uh and this is a uh service that the sequencer kind of provides to depths on any2 network uh the proof verification is uh

not something that D should care about but it's left to the sequencer and to the provs and we believe that this is a simple building block that makes it easier to build any cross chain dep between ethereum and and the L2 there have been some similar proposals before Tao proposed A1 call and I think optimism a similar one called remote static call which are in a way more uh powerful because you could have like a full evm clock context in those proposals but at least in our experience at scroll this is not really feasible to implant at this point because we would need to have like zkm embed it as powerful but L fancy uh but

something more feasible in our view uh the spec is quite simple so this will be a pre-compiled simp it takes the contract address of an Al contract and up to five storage slots so this five is kind of the arbitrary number and would love to hear our thoughts on this um and then it issues a bashed RPC call to an1 note and then returns those uh red story slots to the L2 color uh so here's the details but uh this fairly straightforward just the encoding of the inputs and outputs in terms of gas uh so we have a fixed gas cost and a per load gas cost which

is based on this K uh one to5 uh constant uh the these are not the final values but our current thinking is that the fixed gas cost is around 2,000 uh and the per load gas cost is B selected to be the same as uh L SL load gas cost for called U slots uh the F fixed gas cost is quite interesting because this time the main cost I would say is latency the RPC call latency which is not a resource that we have experienced pricing as opposed to storage or compute uh so this is really uh not final this number here uh yeah to to answer Richard

Richard's question currently these only called I guess we could consider you know within the same transaction if you read same slot twice then the second time you can just read it from local cache but I think that's not really something that deps would use quite often so I'm not sure if that's useful but we can incorporate that into the RP from a Dev perspective this would be quite simple to use you can just static call Provide like a list of keys and the address and then use AI decode to decode the results and then use that so quite developer friendly I would see in impation we have a uh an example implantation I wouldn't call it

reference implantation because the the rip uh you know gas cost and some other details are not finalized yet uh there's two things I want to highlight here one is that we assume that the L2 node connects to another one archive node I think it's a reasonable assumption that the L2 node connects to L1 node but requiring it to be an archive node might be a stronger requirement that that is kind of an issue with this RP uh so the sequencer would need to execute a recent Adon state so full note would be enough here but any out to full note who wants to replay historical transactions would need to connect at least temporarily to an L1 archive node and then they could switch over to an L1 F node if they don't want to maintain that long

term the other prerequisite is that the L2 protocol has a notion of the latest seen Lum block number uh we at scroll have a spec for this already not live on Main net yet optimism also has a system contract that has this uh I'm not sure about other rollups but I think this is generally something that's useful in many context for rollups so it seems to be a reasonable U prerequisite to have um in terms of implantation I have I have it linked here we have a a g fork for our sequencer and we have a this examply implantation in that g fork and then the verification part is

uh basically we would do sequencer or the rollup would do the verification of the proofs on behalf of the user uh so that would mean that at proving time so at sequencing time you you can just call the get storage at RPC but at proving time you would need to get the corresponding State proof and you would need to verify it in a ZK inside a ZK proof or inside your FR fraud proof mechanism to make sure that all these reads were performed correctly one of the concerns that we heard is uh the latency like how fresh is the state that is available to to Al to deps uh I think vitalic mentioned this different

stages so the most conservative one is if the out to roll up only Imports finalized blocks uh which is safe you don't need to care about reorgs but the latency Is Not Great uh if you wait for 10 confirmations that would be stage one that's much better ux and the risk is not huge but you need to be able to have the RoR uh in the worst case and then the best would be just you know almost no latency or like one or two slots but then RoR something that you would need to deal quite often deal with quite often so uh how we relay this L1 block information to L2 is not in scope for this RP but this is an important consideration nevertheless and finally there a few

open questions questions uh the first one I already mentioned is it is it okay to require L2 no to connect to1 archive node as I mentioned for the sequencer this doesn't seem to even necessary but as someone mentioned in the telegram group uh currently it's not even necessarily required for L2 FL noes to connect to an L1 node at all you could just get the same information from the sequencer of course you would need to trust the sequencer on this but uh it's not a strong requirement now whereas for this rip it's definitely necessary to at least connect to one full node to be able to follow the chain dealing with the RPC errors is also an interesting question since these calls to this

precompile are part of the state transition uh you cannot you need to make sure that you deal with these errors in a deterministic way so our proposal now is in the sequencer you can uh retry or reject the transaction but once it's included in The Ledger uh the only thing that notes can do is retry so if your1 note has a connection issue or whatever then you need to retry until this call succeeds otherwise you cannot reproduce the state uh there the question of RPC latency so one aspect of this is how do we price this in in guess and also whether this will become a BT neck for for the sequencer uh we we think this is probably not an issue because the

sequencer would definitely use a local Noe so latency could be optimized uh it wouldn't call like inur or some remote Service uh but for follow noes this might be significant latency if they use some third party Service uh the fourth one again this is what I mentioned on the previous slide uh the more recent State we can expose to L2 deps the more useful it is and indeed some deps might want some guarantees that the state that they can read is recent and not from two months ago uh as for the guarantees with we don't have a great answer here although I mentioned this is not really in scope for this RP uh but this is definitely something that affects its usefulness

and we love your love to hear your thoughts on this uh the proving overhead uh we can only SP for speak for ourselves uh in scroll for us uh the MPT verification uh for L1 proofs is seems to be acceptable it's something that our provs can manage and this is basically the main selling point of this I slot compared to the previous L1 call precompile that I mentioned that this is feasible in the ZK context and that one is less feasible and finally a previous version of this pre compile allowed reading state from an arbitrary album block height or at least you know the last 200 blocks or something like that we removed this for Simplicity but some people

suggested that if we allow tabs to specify the block height then this might enable some use cases that are not possible otherwise so this is also so somewhat of an open question whether we should add this to the to the input list or not if you want to try it out we currently maintain an open devnet um so feel free to take a look to interact with it call dis spray compile and finally we have the rip and the discussions linked here so that's that concludes the presentation is that are there any questions thank you Peter have you had any like

when you talk about the dealing with different latencies um and whether you use only finalized blocks or more recent things um and you talk about just having to deal with it who's dealing with it there is this you imagine this being on the DAP side or on the L2 side you mean the latency for relaying the blocks from1 to2 yes so this this is something that the rollup would also provide for the users and as I mentioned optimism A1 blocks contract is an example for this already live I think on their main net but this is not part of this

RP uh okay yeah I think this is more like a prerequisite to the a yes but my my my my my my my question is you said that people have to deal with it but I'm asking who's who you envisioning dealing with it is there something that you expect el2 to have sorry um the the contracts deployed on l2s to have to like handle reorgs if they happen oh no no so this would uh be handled by the sequencer so if you rely on any L1 state that was reor then the L2 Ledger would need to reor accordingly I see if you relate relate any information that could could be

deposit messages but L1 block hashes also belong to the same category if you relate that and it's not true anymore then you will need to reor according okay thank you yeah uh adding one comment here is that um we think like the um to make the L1 SL more useful like to the developers it's should be like the uh using at this like at a stage one so because like otherwise reading a very uh like at long latency where making like the developers and uh and application read a very stale state

so my like the limit the use cases for for this for this uh pre-compile outside of sort of past Ro LS is this re re oring uh the L2 based on L1 reorgs is this infrastructure that already exists in some l2s

so I I believe optimism has this state derivation function based on that they can definitely kind of deal with reor at scroll we're working on this functionality currently we're still stage zero we just wait for finalization but there's I I don't think this is anything inherent to to Bas rollups non-base raps can also have this functionality I'm also to which as why was asking yeah any further questions on this topic

nope okay well thank you very much Peter um and then next topic I believe is uh Richard wanted to talk about rip 7740 uh pre-installing deterministic deployment factories yes and I mean it comes out from a pretty old threat over a year ago or two years ago um pre pre rip time basically where it was talked about should there be a pre-compile for create 2 so that it can be used by uas AC cross chains and at some point then they basically got to the point that some of

the rabs namely optimism started pre-installing some of the workarounds for this non-existence of the pre-compile for grade two um there were a couple I think um I listed some in the um RP there are a couple factories also used by safe we used multiple ones so that we can utilize them for deployment right and what we realized is that it's still a little bit of a hassle and actually also one of the bot necks if we deploy them we have to make sure that is such a deployment is our deployment Factory available because only this allows us to deploy to the same address with the same security assumptions on all places and it's actually not only a problem for us

but for a lot of other teams for example coinbase is also iing our Factory um a couple other factories being written and it's not always possible to use the one that is trustless deployed due to certain gas tradeoffs um gas pricing and gas limit tradeoffs um that is one part and the other part which extends actually on this problem is that currently so up to now there was no unified way across all rollups including the ones that are not type one type two so for optim arbitr and polygon and all the ones based on this these STS there it's possible that you just redeploy the contracts the factories

that you have in one way or another um but when you think about CK sync for example there's currently no way to actually get this done because create two obviously depends on the bite code and bite code is just different and so these two problems would be nice to push them forward in a way that we can say hey um this would be a major benefit if you deploy Frost Trin protocols if they can like be at the same address if you can especially for smart accounts um enable the same address or like deployment to the same address these are just nice at least security properties but can also be used for your properties right and this is basically where what I wanted to

figure out is is it even realistic to get alignment from the rollups on this one or do they say no we basically would have to talk try to get each of the rabs individually to commit to certain pre-installs for this one and then also not sure if anybody actually from the ZK sync stack is here or any of the non type one type two stacks not sure which other teams there also is there a a willingness to look into figuring out how we could bring or build a solution that goes across like that works so there these are the two questions for me before I would like push this further forward I want to avoid that it's basically a battle against windmills or whatever you to say however you say it

in English so not sure who is the best to respond I mean let's first the first question is there General willingness to Define such a list of pre-installs that I mean there are to some extent already present on most of the rollups it would be more formalizing this for new rollup spinning up based on existing Stacks that would be my first question basically if is this realistic or is it something that is very unlikely to get through I'm curious by pre-install do you specifically mean a Genesis preo or you don't care about the deployment you

just want to make sure that these are available on on NE um I ju simplified speaking I I don't care about the means they should be available um on all each rollup at the same address basically with same logic um I think optimis the one I referenced was optimism that's why I used pre-installs where it was then basically from the get-go but in the end if there are other more or easier ways or more feasible ways I would be fine with this too there I have to admit that I'm not that deep into the rollup space that I would say this is the best approach and would be happy for feedback so interestingly with base um the I

think it was a create two deployer the person tried to deploy it not realizing that bridging um funds over from mainnet increment of the nuts um and that completely broke it uh so we actually had to do a hard Fork where we um sort of redeployed to create two deployer at the expected address so this would have prevented that situation so I just wanted to point out that data data point um I do see the value of it I also think it's a good idea to have a standard list so we can track who's compliant and who's not that that's already good to hear

that uh that would give me at least some motivation to keep this pushing then do we have anybody here from the cas sorry to be ignorant on the who is working on a project but else I would have to reach out to them on a different Channel okay then maybe I will not be able to take part in the next uh rooll call it's during my holidays but I would take it on to either have somebody else represented or join the one afterwards even though it's a long time ago like a long time in the future but then I would try to align with CK sync and then I would try to present a more finer version where I would say this is ready to merge since it's currently a

draft that sounds great thank you um the I think this is a perfect thing to try standardize here and definitely see the use uh but also just to point out that we don't like part of this process is not necessarily having consensus and only one way that is compulsory to do it obviously it's nice if everyone agrees but if we end up with out lies it's too hard to include them that's also okay if you ship a standard that is mostly used or somewhat used by subset that's still an improvement over the Baseline great thank you Richard okay I believe those are all the

agenda items we had um does anyone have any other items I'd like to discuss GRE once twice um I had I had suggested um to discuss a breakout session about about the the AL transaction fees back yeah um sure should we do that async well I mean it's like it's like is there is there I mean the specs there right

it's it's um we would like to to get some feedback from from client teams so I think it would be good to to actually schedule that yeah but yes we can do it ASN but as long as it's getting scheduled uh sure we can we we we can uh we can we can make sure that happens okay cool all right any other topics oh just one last thing um there was a discussion thread um around L2 transaction statuses and the fact that they are not standardized in any way shape or form so um I I um a where was this happening and B what

ex okay yeah the roll call um telegram group because there's there's no there's no um common definition what what different statuses even if they're different me right I mean you can you can maybe call different things but it should it should it should you know the meaning should be the same if not the words even though the word word should also be be the same so um that we have you know equivalent to http codes that is clear what they mean right so um the the L2 s working group over on on the um open ethereum open projects um

Community took um made a proposal made a proposal put that on eth magicians yesterday and also on um open it issue in the r repo uh just to get the discussion going because I think it's it's um would be beneficial to the community if if there's a common uh if there's a common common um glossery um of these terms that everybody sticks to I think it's something relatively simple that could be um achieved um fairly corly

okay thank you um yeah we can see if there's people are interested in adopting something like that any further topics okay fantastic thank you everyone attending and uh we'll chat to you next time have a great day thanks right thank you