RollCall #3

Transcript

great hello welcome everyone to roll call number three which is issue number 944 in the uh PMS repo Link in the chat yeah great so uh today I think the main thing I want to touch on is uh 444 Readiness um we had a breakout on this um and the consensus there seemed to be with that a lot of people still have lot of work to be done here um but things are generally trending positive um and then it's come up five C on ACD uh on on L one side with people just uh wanting to figure out where all

of this is so uh if any of the teams on here um who have been testing I'd love to hear sort of where you are in in this process with deploying blobs on the various uh for for forast Nets Zach hey everyone uh Zach from ZK sing so as far as our uh I guess testing efforts right now we're at the point where we've been uh running it locally with uh pretty much uh I would say no

issu slash one maybe uh minor inconvenience uh our plan is to roll out to sepolia today um but other than that it seems like we're pretty much ready to go especially with the mainnet release being um solidified one thing that I was actually curious about and um if this isn't the right meeting uh let me know but so on the ex excution layer clients I saw that with gu it only allows for um one if a blob transactions in the men poool that's the only transaction that can live in there um this kind of uh

makes us de not only does it deviate from the behavior of a standard transaction but it makes us do some additional logic as in the past we used to fire off a bunch of transactions uh namely for a given batch we would send over the commit prove and execute uh around the same time so I'm curious if this is um other people are kind of experiencing the same issues as well as if this is a temporary solution until uh full DK sharding or the number of blobs increases or if this is something that we should uh expect um in the long term

thanks um i' actually don't have an answer to that is anyone else encounted a similar issue but only be able to play one blob per block uh on Tao side um I don't have anything to report mostly because uh it's a Chinese New Year uh uh holidays and we'll start integrating EIP 4844 uh starting from next week okay um does that mean that uh what does that mean in terms of timeline for you guys in terms of shipping does the like are you going

to need a few weeks after void 44 goes live before you guys are ready to deploy clubs just an expectation I'm talking about test net we're not even in main net yet so yeah yeah yeah will be uh EIP 444 um compatible uh as soon as we launch okay great any other team testing hey uh I'm Derek from offchain Labs I can give a quick update on our side for the arbit stack so e 444 testing continues uh and the formal Dow proposal on chain was

submitted yesterday uh so that puts us on track for I think just after midnight Eastern on March 13th to activate on midnight assuming the Dow process goes smoothly nothing major to flag on the testing front but good thing to uh to note maybe other teams have experienced this is that we've been monitoring and in talks with a few RPC providers in terms of beon chain RPC availability uh as well as support for archived blobs uh so this is for like syncing of nodes uh so we're just kind of monitoring and working with infra infrastructure providers there as for sapoia ARB sapoia we will probably activate it sometime next week um but

that date isn't confirmed yet um but everything's on track good that sounds that sounds pretty interesting yeah I think the the rpcs are one of the things that always take a a little bit of a while for uh to catch up from the tooling standpoint um but given the femal nature of blobs yeah that's that's really important to get right anyone else

on SC yeah um so I I just want to briefly mention because um kind of Z touch touched on it that um I'm I'm not super familiar with with the um current situation in in gu but just to flag it as we kind of move in the future hopefully hopefully on a kind of attractive timeline move Beyond 444 into kind of higher scaled uh sampling based kind of throughput for for data availability um basically it it's it's a bit of an open question in general how to basically handle the the mle side of things um one of the reasons why there's

special Logic for for for me mle and again I'm not super Focus where where the S it up but at least why that was a conversation in the first place is that um because of the big size of of individual blob transactions it's it's much more of a potential thust vector and so nodes in general just have to be much more careful with how how they handle these transactions and so as we kind of keep scaling at some point basically this the peer top M Pool will become less and less of a good instrument for getting um basically Bob transactions to um to to to to build this and I think we're also going to look into kind of

different alternative architectures for for this uh I think the the mle will always at the very least kind of be be a good kind of fallback and and kind of sensial resistance vehicle but um basically what what what I'm trying to say is just that kind of it it might be a good idea for for people in general to already kind of start thinking about in the long term as as we will have want more blobs like what are the best ways to reliably um um get get them from from people that that want to sent them to to to to build us um I think that that that that is going to be a more more more relevant questions question in in the

long time um yeah so on that uh note I totally get the rtion on uh The Blob men pool um for potential do reasons and so having a single uh only blob transaction in there um somewhat makes sense but I guess is it a completely separate menol and that's why the rules are not just restrictive to you can only have one blob transaction in the men poool or uh is it or is it not a not a different men poool and it's just is being overly

restrictive to uh normal transactions as well also again happy to uh uh redirect these questions to a more appropriate Forum or uh meeting yeah um I mean ultimately I definitely um not not the right person to answer this I think kind of reaching out to to Cent directly probably the the the right way to go um but I I do know that yes like Sally um most at least I know this from G that that basically for the for logic in the men pool is is is

really mostly separate from the normal men pool so so it really is treated basically as as two separate me pools my understanding go okay any other client want to uh touching on how their 444 testing is going before we jump on to the next topic going once

okay um next topic so um as I'm sure many of you know I was one of the main people running the uh the kzg ceremony um and so uh I submitted it into the uh ethereum specs repos sort of the output of the ceremony and uh I had a bug in my code that produced the wrong ceremon output so for all of about one day there was we had the correct version then I made some other changes and I put in the the incorrect version and I have restored the correct version um this was just after our previous roll call uh roll

number two anyway uh point being that uh please just check the version of the uh ceremony file that you you have after the ceremony file um is is the latest one as per the uh the contentor specs um SL whatever uh kcg Library um you're using I believe all the uh the libraries that have those hardcoded already have the the correct version in and have had for very long time I don't think they ever imported the correct the incorrect version but uh just flagging this to make sure that everyone is on the uh this version of the uh the ceremony output and uh to please the instructions are in the the link I dropped to to

verify it yourself um as this is sort of like one of the key security aspects of of this whole change okay any questions on on this topic no okay great um let's see uh next okay um my agenda for some reason keeps seem to change here I would like to do a quick uh recap

on the the breakout calls that have been happening so I'll hand that over to ancar just to touch on sort of what happened on the last uh last few breakout calls okay yeah sure um so so so basically um for those that maybe have not joined these these pord calls since last roll call we we've had um three kind of record calls all also on on the Wednesdays um kind of on the off Wednesdays physically between the last one and this one um touching on on on on different kind of um topics uh one of them was on F B Readiness uh which which

I guess we kind of already discussed on this call as well um the second one on fee markets and the third one on on kind of pre-compiled um on on I think it's probably like if if you kind of if you didn't listen to them and and are curious you can you can find the recordings online basically on on fee markets we talked about um both kind of the um potential potential for for for kind General repricing but also specific specifically about a kind of multi-dimensional um uh basically they one kind of pass through um um um um pricing and and the the idea about quite

new transaction type there so so that there could be specific followup um um at a at a point in the future um and then on the pre-compiled side um we we basically mostly tal talked about the the kind of the challenges with with kind of shipping a new IP and uh where where we at there um so definitely recommend go listening to to the recordings if that's interesting to you and you didn't catch those um a question that I had now would be um for for for the people here maybe that that that were part of of these calls um just just basically a little bit of General feedback did people generally like these does it make sense in the future to to continue um them uh

what kind of frequency do you do you would you would you like to see them at um yeah maybe a little like a little bit of of feedback for for this format makes sense to to continue would be would be useful yes my personal feelings of them is that

they've been sort of helpful to touch on some of the topics that we haven't like being able to touch on so much um but I feel like the frequency has been a bit High part of that I think is just the sort of starting out in testing but uh the idea of not having this roll call be something that where there are too many calls um although the breakouts are optional but to have have it a bit less frequent I think would be would be a helpful thing moving forward yeah that that seems reasonable and and I'll I'll be happy um maybe someone else can feedack uh in the loal

channel we can keep talking about it and and and also if if you have specific topics you would want to see a breakout we can up with that as well my understanding is uh we we have Justin on the call um who wanted to to um um after after this um also kind of briefly talk about uh kind of this topic of sh sequencing pre- confirmations on this call but my understanding is um maybe car and Justin correct me but that that there was also interested in having a breakout session uh two weeks from now um to go more into more detail um is that right at least on my side yes that would

be great okay yeah so then basically we would already have one specific uh breakout uh to tonight basically so so uh two weeks from from today again same time uh we we will have we will have a breakout on CH sequencing and pre-confirmation so if you uh like or if if you're interested in what you'll hear in a second from from just in here is like basically teaser then two weeks from now will be the time to to to go really into detail and basically um that will be a breakout session where we kind of with Justin we have a guest kind of leading these so so this is in the future also a format that we want to basically experiment more with um to basically bring in bring in experts on

different topics um where where makes sense and and basically have them read these bracket cards um so for now that's going to be the only breakout uh in between this roll call and the next two nouns and then there might be um might be one more breakout after Justin depending on whether we can p a topic um but we will announce it but then there will not be a breakout uh next week that that would be all for me and break on the topic breakouts yeah so then on that topic uh Justus want to talk a little bit about what he's going to be talking about so hand over to Justin to sort of touch on give give a short overview of what he what would he'

like to talk about in his break out perfect thank you K Anar um so yeah this is a a teaser on what I'm calling the ethereum shared sequencer uh you can also think of it as the ethereum sequencing and pre-confirmation layer um you know a lot of us here know that FM can be used as shared data availability can also be used as shed settlement uh for rollups uh but it turns out that it can also be used as shed sequencing uh with with pre- confirmations now in terms of research one of the exciting things that was discovered is that we can add this pre-confirmation layer um without a hard fork and there's a I guess a design that

can be presented in the in the roll call um in in a couple weeks on February 28th um and if you're especially interested in this topic there's also a dedicated call uh that's happening on Friday this Friday the the 16th at 2m UTC so um there will be a presentation there uh with all sorts of uh you know meev infrastructure people uh researchers uh rollup people as well as as as investors and uh the goal of of of that call on Friday is is a coordination call to try and get everyone aligned in

this multiparty dance that needs to happen for for shed sequencing to to be a reality now in terms of why shed sequencing I I believe is valuable is because it unlocks uh at synchronous composability uh which if if users want that you know can provide a lot of network effects to to ethereum and to the the rollups in general and um I guess I'm a little opinionated in terms of what I think is makes a good sequencer a good shed sequencer and uh you know some of the the properties that I value are you know security uh credible neutrality and and and network effects and um I would argue that that ifirm of maximizes all all

three of these things it's the dfm sequencer is maximally secure maximally credibly neutral so that all the rups and their competitors can be can feel comfortable operating into it um and it's also um has the most Network effects today in the sense that it has half a trillion dollars of of of assets ec2s nfts and and if um which is a couple of borders of magnitude larger than than the the next uh you know largest sequencer so yeah that's that's basically the teaser I think I might have one minute for for a burning question but otherwise that's that's all from me

yeah just just DM me if you if you want to be part of the of the call on Friday okay thank you Justin definitely yeah looking forward looking forward to uh to to to to hearing out the full breakout and uh yeah we'll see you on Friday's SP I guess moving on to the next topic um which is uh rip 7614 exposing the full call stack do uh contracts within the ebm um I believe the authors are here and would like to uh pitch their RP for

five minutes maybe field some questions thanks Carl yeah we're here um janer did you want to talk through it real quick yeah up hand up if you're speaking we can't hear you m

you're muted ah I see you're aware I can't unmute you from your your end but I have submitted a thing to ask you to unmute maybe leave and rejoin a second yeah

uh I guess while we're waiting for this we going touch on the next topic very quickly um which is that we have a new RP editor um blush which I think most people here are pretty familiar with um from his uh contributions with the uh R1 code pre-compile and yeah he'll be helping Anar and myself out in terms of just getting some stuff uh cleaned up on the repo and uh generally just helping make sure that the RP side say is nice and clean so yeah welcome okay CH let's see if this works

are you able to unmute now uh I can't unmute you but I can only request you to be unmuted okay oh seems like this is a this is a fun one uh Andy are you able to speak to any of us while we're uh waiting for to rejoin or anyone else from this team Carl let's let's see if Jer can do

it um I'm not I'm not an engineer so I won't be able to D there you go sounds okay works now thank God yeah hi everyone this is J from open zeppin so uh we've been working on this uh new uh pre-compile um that is uh that exposes the col stack and uh the main reason why we want to wanted to develop something like this is because we want to mitigate a potential attack pattern that is possible by using delegate call and proxies and having this kind of pre-compile inv visibility also uh levels the attackers uh with the protocols by giving uh information about

the rest of the addresses that are involved so um I posted the Forum link uh to the chat if anyone wants to have a look at the proposal or the discussions we're really curious about your thoughts about this so um I want to say there are uh two uh counterpart two uh components of this uh Improvement one is the col stack that is uh widely and theoretically known um but has never been implemented and the second is a pre-compile interface that allows exposing this to evm so um we've implemented we propose a call stack that is uh really simple that keeps uh track of the op codes uh

addresses and the function signatures and this call stack is only updated whenever uh any of call call code delegate call and static call up codes are executed so it's only these up codes which manipulate the call stack they push into this SK stack when the frame enters and they pop from it when uh the frame exits so um and the second component which is a pre-compile uh is merely provided as an interface and it has an encoder that allows the contracts to call so that the call stack data could be retrieved in any point of execution so in the in the proposal we're uh reasoning about these uh two

different parts and also the gas cost of these two different parts as well um and we think that this is uh something that is fundamental to um strengthen the screen on chain screening solution and making uh onchain screening more transparent in terms of rules and we we believe this is the first step to implementing and we believe that there's a there is a second part of this screening which is uh checking the addresses that is provided but by this precompile but we don't necessarily think that this is the problem we want to solve in this proposal we were only trying to pres present a way to give more visibility to the contracts about

uh about the culture so um I'm curious if you have anything to add Andy nothing to add for me janer um but I know uh I think I see Ariel from spherex uh who was involved in this too I didn't know if wanted to give Ariel a chance to to maybe add any comments he had to yeah sure sure um yeah in Spooks we are working on uh runtime prevention of Medici transactions and this um pre-compiling inter phase uh will let us uh have access to more uh features that will uh be able to decide better if a c

transaction is malicious or not we have uh seen um hackers getting more sophisticated with how they um trying to conceal their efforts in exploring um certain uh protocol and this new ability allows us to expose them and prevent their malicious transactions from being [Music] finalized um has has a very thorough security analysis of this been done yet as to uh

how effective it'll be is it useful or will it always be useful I mean as as someone who's been in Java for years these stack analysis tools are how a lot of the various um sandbox breakouts were caused because they're relying on that to ensure their security so I'm a bit concerned that it's not going to be bulletproof it may be useful as an additional tool but I also have some more technical comments that I'll put in the uh magicians throughout it should be extended to creates and um there's some specific solidity things um there the magicians to add a more appropriate form for that um sorry do you mean if uh this

this Improvement has any security implications on the client implementations is that what you mean um are you sure that it can't be circumvented by just being even more stealthy oh uh yeah that's a good question that's something we're always thinking and attackers will always get smarter it and this is something that probably fuels the cat and mouse game uh since we're trying to increase the visibility but we think that there is this once uh once the contracts are flagged uh on chain and that's the one way to prevent the attackers on chain and that means uh the contracts protocol contracts who would want to implement

such checks would want to check these uh oracles Whit list or Black List whatever reputation and risk scores and once uh those are checked they will they will be checked against the message sender the caller contract but it's possible for the message sender to hide its logic behind proxy by using a delegate call to an actual logic contract so the actual logic contract could be flagged and but the the actual call wouldn't be the logic contract because of the delegate call made by the proxy so we want to mitigate this problem and we think that this is something the hackers will adopt once onchain prevention Solutions become more more

popular and we want to uh preemptively um make this uh not not POS hard harder to make so the second thing we're thinking is um once the addresses there there can be more visibility on the addresses can there be another way of changing the code in the same transaction without giving visibility or um and anything that allows you to uh execute arbitrary code and we we don't while we don't see a problem with the latter yet we uh have a problem with the former and so we think that before the contracts and interact there there should possibly a reasonable space until offchain detection mechanisms uh have

develop an idea about uh these uh contracts and that those will be uh flagged onchain by the offchain uh detection so we think that this uh this these kind of checks will be complementary to the precompile uh we are kind of right now um proposing and that means attacks can be detected before they are executed and they can be detected with high Precision then and the onchain uh the onchain updates can be made in reasonable time then attacks can be um Can can be prevented being done by address or by uh

the um collector um so we mainly think the first way to do that is by address because uh in detection we think that um there is some U hard re resource in intens work to do is it is resource intensive for evm so offchain doing detection offchain is much more powerful than trying to do it onchain we can do a lot of more things in offchain as well so um which is why we mainly think that the addresses could could be flagged on chain and this uh solution could help combine this with that and implemented screening kind of solution if protocols

uh opt into but of course since we're exposing the op code and the function signatures it could be possible for anyone to implement an onchain anomal detection solution as well so which makes the the prevention solution the prevention logic more transparent Andreas please yeah so what what if the proxy deploys the attacking contract and the attack is done from The Constructor that's a good question uh the kind of question we have been uh considering since early days of developing this proposal so um it looks like we we we are able to say part of

the call stack implementation say note down the addresses that are deployed as part of the same transaction and then provide them as a second list uh that that have been created Created and create to and and and those ones that are appear in the call stack so once once they are uh provided one could then check if this this deployed address this is bigger than larger than zero and then depending on that uh call could be reverted thinking that one of the callers was deployed in the same transaction and it hasn't been uh scanned off chain but we think that it's possible to circumvent

this um by deploying the contract in a first transaction in the same block and then executing the attack in the second transaction in the same block that would give us no visibility and again um it would also still be very difficult if it was were in uh different blocks even because then the offchain uh offchain detection would need to uh race with compete with the attacker to be faster with the update onch so we think that this is uh a problem to solve Al together with uh lists provided by external sources and written on chain so any contract who

would be securely be able to act would need to have some age uh on the Chain uh we believing um I've already mentioned this in the uh aame magicians uh but from the point of view of ZK rollup this is uh this sounds uh hard to prove uh efficiently and also from the point of view of uh evm design in general um like the people at Epsilon uh usually wants to have a predictable um uh size and compute cost but this is uh Dynamic uh

because it depends on everything that has been done before and not just on the inputs um so I think this will be uh quite um problematic on that front and the other thing is that um even in C for example which is the lowest uh of the highest level language you don't manipulate the stack because um when you use the instructions called long jump and set jump uh it breaks um uh uh uh memory management uh well a lot of thing a lot of assumptions so um I think

this will need uh lot of iring out uh before it's um implementable I'd say in at least in a in a ZK rollup uh and the netam minism uh makes me think there is another attack very Vector uh just to Dos uh smart contracts that use this uh by uh having a quite a large call stack for example um M momy thank you I I seen your uh feedback in the in the Forum post under the for post so thank you very much we believe that we need to have more uh ZK conversations on how

this could be adopted but um from the um I actually tried to reply uh to your concerns in the fir I'm not sure you have seen them and uh what we're proposing as part of this proposal is a a brand new call stack that hasn't existed so it's not related to the stack in each frame um that is used by the op codes that are pushed to and popped from and so nothing in the compiled code none of the op codes can none of the user written custom code code can actually manipulate this call stack it's merely a representation of the execution itself so ideally one could try to reconstruct

the state of the C stack by just looking at the cult Trace which I believe is already used by some of the ZK EVMS BR proofs I'm I know a little bit about how scrolled is it I I believe taon might be doing something similar but I'm not sure um so uh we we believe that it could be maybe somehow uh part made part of the tables used in uh circuit generation and and proofs so since it's manipulated by only certain up codes and it's not manipulated by user code and we think that testing this is pretty straightforward and the type of inputs

are kind of really simple and the in the reference implementation we Tred to mimic how the other stack is is implemented so and we want to propose this with a pre-compile interface because it's easier to evolve um given all of these uh all of these uh simple uh situation do you still think it it would be difficult to implement this in zkm or do you still believe that it's still very complex to implement even if it's like has this this little level of complexity um I to look at um like zkm secet uh all the co um data Etc that you static call call

code but I'm pretty sure uh those are um some of the biggest circuits that we have uh and those where we concentrate uh all the audit resources um and bugs as well also how would you how would you get that get get that frame as an as an as an you would have to do that as a what as a truth table I mean that's where I'm like that's that would be you that would be very could be very large and could be I mean even if you use it as a private input it would be very expensive just just from from from the number of of constraints that would

generate yeah I'm not sure how that would be exactly used to generator as I'm not very uh Savvy about the topic but I would say the values at the time of calling the pre-compile might be more useful so ideally I think one could try to construct a table by um by looking at the pre-compile uh interface calls and then try to determine by looking at the trace which of the call call Del call static call calls would be in the call stack at that time and then put it into the table um but yeah again this this is something I'm imagining and I don't exactly if if it would work and we we definitely need more suggestions and research on how this could be

implemented okay thank you Jenna um think is a sort of good overview of where we are and some of the the complexities of this RP um I think let's put take more discussion to the forums um so that was it for the main topics but I see that we uh have someone from the G team who's now joined us like client um the ZK sync People earlier mentioned that they're having issues submitting more than uh one one blob per block um so is it possible for the whoever was that raised that issue to just explain a

little bit more what that happen I can see uh yeah sure so um the scenario that um we were encountering it wasn't uh one blob per block uh because we were actually we were able to post uh more than one blob it's when we submit our blob transaction if it's not included immediately uh we're not able to uh submit any other transactions as we get address already reserved uh in the RPC response and so I understand due to potential uh do uh situations there might be

restrictions on having multiple blob transactions uh not multiple blobs um but my question there is if that's a short-term restriction or that's going to be long-term even as the number of blobs increases and then if there is any particular reason that it's not just uh isolated to blob transactions themselves but if there's a blob transaction in the men pool um 1559 or Legacy transactions can exist as well like Cent you have any insight into

that hey um I think address already reserved is supposed to mean that you're trying to send a transaction so we have the the different types of transaction pools now we have the normal transactions The Blob transactions pool I think address reserved usually means that you have a pending transaction in a different pool so if you have a legacy transaction pending and then you try to submit a blob transaction you would see uh address already reserved or vice versa so so if you have a blob transaction pending and you try to send Legacy it's going to say address already reserved right uh yeah and that's the uh scenario that we're running into and I

was just curious you said blob transactions though so are you sending different types of transactions from the same address Yeah so basically our uh we have three transactions when it comes to uh a batch we commit the batch prove the batch and execute the batch uh only committing is a 4844 transaction uh because that's kind of where uh our Pub data is L1 and that's probably going to change at any point so I would recommend looking into submitting the non blob transactions under a different address okay uh yeah we played around

with that uh the downsides uh again more our downsides for that are uh anyone running our sequencer then uh needs to uh keep track of two addresses and infrastructure around that but um good to know that uh we should design around that rather than it being changed and then I'm not sure if you have any insight is this something that all uh execution layer clients are going to be uh implementing or is this uh specific to gu I think this one might be specific to guess right now but the yeah the

mechanics of actually propagating The Blob transactions across different clients that's something that's being debated right now okay I mean it's possible it changes in the future it's just that's the kind of higher level design for the different different transaction pools for GU and that's mainly because I don't think we found a good way to separate the concerns between the two pools there's a lot of problems with allowing Legacy transactions to bump off blob transactions and the code is kind of isolated in two different places so it's not something that would

change in the near future but it's possible longer term if we come to a good a good way of allowing that to happen Okay cool okay thanks that was uh very helpful to understand and to clarify and then I think that brings us to the end of uh the agenda does anyone else have any points they would like to uh discuss just as a more General Point okay I'm gonna take those a not

then well uh thanks everyone for attending this is uh this has been a fun fun call thanks some some good discussions that we had the uh next call um we'll have the breakout on the 28th of Feb and then the uh the next call will be on the day of launch for 4844 so that will be uh fun to see so uh it'll be definitely an exciting one see you all on the 13th thank you Carl thanks

like thank you thanks by everyone thanks