RollCall #11

Transcript

uh hello and welcome everyone to roll call number 11 that's issue 1294 in the PMS repo uh Link in the chat um I think we're going to start off with updates on what's happening on the L1 so I'll hand it over to Anar for that quickly yeah hey everyone nice to see you all again let me share my screen can you see my screen yep perfect yeah so um this time around I called the update um ACD and research update because the second part of it

will be a bit more kind of forward looking more researchy um either way starting with the ACD set of things so um we are kind of currently in the process of rolling out pectra um as as we announced kind of on or like as we talked about on last roll call the um two test net Forks have happened since heski and apoia um unfortunately with quite some issues not sure if you um you might have you might have um read about that so on the aleski side um we basically there were there were quite quite severe issues that um caused into it caused like a pretty long kind of period of non finality um we now have a

stable is um I looked right now and like it's still struggling a little bit to find finalized but like we basically now have a stable-ish version of of heski again as of as of basically um earlier this week um and then we had the seoa um for that went with that that basically had comparatively much um uh smaller issues just just some some small El configuration bugs that very briefly um cause some issues but but has has been stable basically almost since basically after the for um yeah so if you use uh uh either of those for testing I mean especially Soo of course then um that that that should be good good to go but as a consequence um because soleski kind

of took quite some time to rescue um there is definitely uh some some kind of some delays to the to the main it for roll out for pectra just maybe for context both of these bugs on on both heski and zolia were like spe like specific to the specifics of the test net so um none of that should directly affect the safety of the main roll out but there's still kind of delays um as as as people figure out next steps especially because there's some some ideas around say launching an additional test net given that kind of heski had these these these major issues um all of this means that while there was initial hopes for a pector roll out in April now we are looking more at a

May timeline details to be determined if that if you're kind of curious about that or if that timeline really is important for for you then tomorrow's ACD would actually be a good one to listen in or maybe even if if you specifically want to get involved to to attend and because I um it looks like there like um there'll be a lot of um discussion around this um now in terms of how this affects um blobs in particular which I I think is is one of the major things that the L1 provides for you all right now um so for one of course it means that the pector itself with the 2x um blob increase will be slightly delayed hopefully Again by not too much and but

then also one thing we are working working on um very intensely behind the scenes is that we we try to make sure that the work on piia does um is going is is is continuing basically on track meaning the idea was that people right around now that a lot of the the the um c devs um are now shifting more resources towards focusing on on ramping that that effort up um and that's still happening so um and and of course pasas is the kind of the the piece of the the upcoming um fusaka Fork that will um bring like a a large bump to to The Blob throughput and so the Hope here is that um we can we can chip uh fusaka um without like an equivalent delay of like

a month plus and so that that that we basically still have a relatively short timeline here to to to this further blob increase uh speaking of faka uh I have a slide on this as well um the exact scope is still to be determined and because allod is still busy with basically cleaning up pectra um it hasn't has hasn't had time to like finalize the the plan there but I think the most likely scope that we're looking at is really a very small for that really focuses just on podas and then on the on the El side UF is this this feature that has just been waiting to be shipped for a long time so now is probably the time for it um and then otherwise really only like small extra changes like there's some repricing of of of of the pre-compile maybe things like like a minimum blob

base fee that we discussed in the past on this call as well um but but really kind of like the fusaka is looking like it's it's going to be very small and hopefully very fast for that's that's kind of the goal um and then in particular kind of on these features there there has been a small update on the P side um of for moving the proof generation for for for the for the blobs to the send I think Kyle you wanted to briefly talk about this right uh yeah so basically the one of the logic constraints is having um the the block Builder have to create all of the proofs before they can uh start disseminating uh this across the

network um and this creates a bottleneck because sort of once they're finished building their block only then do they can they finish making all the proofs um and this like particularly on um uh solar stakers who are running low Tio hardware and if they don't use if they don't Outsource they building to M boost end up having to um have a lot of pressure on them to create these blocks and uh the tradeoff basically is if we don't enforce that uh if we make the um solar stakers build these blocks then it uh and and make the proofs um it is much more likely that we're going to have to go with a lower Target so the idea is that if we have a

um if if we Outsource this rather to the people creating the transactions in this case IE sequences um then we can a will have them the the the the cell proofs created ahead of time and then um B that means that we can like they already have much higher Hardware requirements and much better bandwidth low latency uh and so there's much less pressure on the um the the the the people building the blocks and putting the blobs in the blocks uh and so hopefully that allows us to push up the uh blob Target and blob Max so that's sort of where this trade-off space lies right now um the main ask here is that of course this now

like shifts the uh burden of creating these these proofs which to be clear are not particularly heavy and are highly parallelizable uh and can be done ahead of time basically as soon as you've decided what you want in a blob you can create the proofs um but yeah putting this now on the sequences as opposed to or whoever submits the transactions as opposed to the uh uh people including the blobs right and my understanding is that the El clients that that you basically would already use to to submit um transactions that they will expose functions for that um so I think the idea is just to double check that there wouldn't be any issues for any l2s to

basically add this to to the pipeline um shouldn't be but I think just something to be aware of right car I think that's yeah pretty much uh as mentioned it's a very small extra amount of work so yeah I don't don't foresee it being a major thing and no no major um like additional work required in terms from like development standpoint but would change sort of what needs to be done uh and just want to check that that's okay sort of Outsourcing this complexity yeah that makes that makes lot sense um maybe we can I mean I I I wouldn't necessarily assume that there's direct feed pck on this point but just in case anyone has already come across

this or has any thoughts on this yeah otherwise um yeah it's really more more something to just be aware of so as we as we get closer to um to fusaka to pasas that um that that's just like a small a small kind of update to to the kind of the BL blob sending pipeline you you'll have to be aware of um okay then um there were also two other points where I also wanted to briefly ask for feedback or at least make you all aware of that there is potential for giving feedback um um over the kind of in the next few weeks um so the first of those two points is um given that people people are really

starting to try to to to to Rally around this idea of having having fusaka be a as quick as possible follow on for after pectra um there is a question here as we kind of test pias um specifically because the the idea would be on paper at least that pasas could bring a pretty significant up um um increase in the in the blob through putut we we kind of the theoretical maximum that that that we could get without without increasing load on the on the weakest notes on the network would be an 8X increase so that could could get us from from Petra's six blob Target to to to like a fullon 48 blob Target um the problem is that that will probably require a while to to get to stability and that that requires a more

sophisticated test like devet approach where you have to actually like make sure you have a realistic bandwidth topology between the the the devet nodes and these kind of things um and then there might also still be bottlenecks that come up as we kind of push to that through Port so the question is a little bit um we we foresee that there might be um some some lower throughput number we we we would get to stability on first um and then have we'll have to have the decision point of like do we keep pushing on the dev Nets to try to increase the the the throughput um to this full maximum of 48 blobs um potentially waiting for a roll out for the fork for whatever time that takes maybe a few extra months or something uh or do we ship it basically once we reach

theability with a more moderate initial um throughput increase say to 12 or 24 or something like that blobs um and then have um people people already starting to talk about these um um um block parameter only for BPO Forks where basically we would then have like a like a once we once we can get to stability for the 448 we would maybe a few months later we would we would basically unlock that on Main net um so so the the ask here the question here is just um for teams that have some kind of idea of where their blob needs will be um is is this the kind of thing where you'd rather have Main wait to then immediately jump to the maximum that we can deliver of course no promise that we

could get to 48 at all but like possibly 48 um or is this something where you you all would would would prefer to just have a an initial bump um as soon as possible uh in fusaka and and and would be fine with with basically the the full one coming a bit later so um that's something where I mean I'll if if if anyone here already has thoughts now that would be good to talk about and otherwise it's just something where I think you should be aware that that this will be a question that will be um will become important I would expect like maybe two months from now or so so by that time you should have a good opinion on which of the two kind of approaches you you'd prefer so that um when L1 makes a decision uh it can kind of take

your preferences into account but yeah is there is there anyone who who has a strong opinion today already on what what would be preferable here um shining in a little bit from like uh base pect perspective I posted the link uh in the chat about our St um so ideally uh since we are like already like pretty like heavily involved in P so our stance is that ideally we would ship P Das as soon as possible um maybe in September so that we can have have continuous like block Target bumps I think from maybe like realistically from 6 to 24 something like that will be very good uh increase and for L arm fors we

could do like block parameter forks with um like no hard for cashes Etc to eat the pain of like quitting a new hard Ro but uh for further increase props we could do poo Fox and the like to like further push it up yeah that's um really good feedback and I think yeah I I I realized now I I should probably put on it's always hard with time lines I should have put on like some some some at least approximate timelines to to contextualize this a bit more I think September is indeed that's kind of like the very best case kind of optimistic fast roll out um of course there might be delays anyway right even

even to get to stability on like a somewhat lower throughput number um but but September is the kind of thing where if everything goes very smoothly then that that that could be in the cards for like if we really try to prioritize roll out and not prioritize getting to the the maximum um um throughput level necessarily um whereas yeah if if we if we if we were to prioritize just shipping shipping at at the maximum throughput level immediately then we are looking really more like trying to do it by the end of the year possibly even sliding into into next year so um yeah anyone else with feedback yeah I think um

Francis with with Bas has has already been been been relatively active so so so I think you You' have already kind of encountered this question in the in the past so it makes sense that that you had an opinion so for everyone else it's really more about like just be aware that um that is a question that we'll probably run into and so um yeah do do do spend it a moment over the next few weeks thinking about yeah what what your take on this is um okay and then the last one on fusaka feedback that's a quick one for me um there has been Desire by several kind of cives to introduce a per transaction cap on how many blobs a transaction can come with um given that on uh pectra we will already increase

the maximum blob size to to nine um most likely we would not want to introduce a cap lower than nine because presumably people already have pipelines that that that use up up to up to the full nine blobs so you could imagine a cap at 9 or 10 or something 12 16 I'm not sure there something in that in that range of basically the maximum amounts of blobs that could ever be in a in a transaction um the idea here is just that like it makes block building and the me poool kind of side of things a bit a bit simp if you can reason about basically worst case maximum blob sizes per transaction um to note here is that the um this cap um could later on be lifted or or bumped up right it's it's always easier to

introduce a low cap and then increase it in the future rather than to basically start without a cap and then basically bring it down later um so it it wouldn't necessarily have to be a permanent thing um it seemed from our side that probably there isn't really any specific reason why why why this would be a very costly change for l2s um but if yeah the question here is just is is there is here some is there some some some L2 maybe that that actually really is excited about the um um um economies of scale effects of of sending many blobs at once and and would be very sad about about such a per transaction cap or or is this just something where people would be fine with that direction if you are thinking about this

I think another component to consider is there two possible forms that this could take and one is that if this uh cap is enforced in the mempool or if this cap is enforced in protocol um this may sound like semantics but effectively if it's in the mol then if you are communicating directly with a um a block Builder SL relay uh then uh you can subvert that and go up to much higher limits um but if it is enforced in protocol then that can never be done so that's one consideration um and so if you're

thinking about it um that's that's yeah definitely something yeah um and again our the default assumption is that that's probably fine um so yeah if this if this kind of no feedback now um again just the something where like you should probably just double check if there's any kind of anything that would meaningfully get better if you could send 40 transactions 60 transaction 40 60 blobs within a single transaction or something um and you'd be really sad of losing out on that opportunity then that's feedback you should give over the next few weeks um otherwise there's a

good chance that fusaka will launch with such at least such an initial um cap in in one form or another um yeah that's all from my side on fusaka I I did have one last slide and as I said like a little bit more kind of like longer term just to give a bit more guidance on um kind of what the path here will look like Beyond faka because we have heard from layer twos in the over the last few months that in general especially on the blob side um basically having a bit of a better understanding of the medium-term road map for ethereum would be useful and so I mean this is not this is not in any any level of depth at all but just to give you like a very quick kind of rough understanding of kind of where at least right now it

looks like the L dl1 might be going this is a little bit kind of my my attempt of just like summarizing where I think the discussion is at this might not be fully representative but just you have a bit of a feeling so um basically we we have the the medium-term and the longterm medium-term meaning like the next two three FS after fusaka and then longterm say think 2 3 years from now basically um so in the medium term I think on the on the SE side they really is now a lot of appetite to focus a lot on blob um um throughput scaling um Beyond most other features there might of course there's always like some individual features that are really important on the SE side like sensorship resistance that might still make it into Forks but I think the

main focus will be for the next few Forks on scaling the throughput um basically there is p us just even you know as we talked about getting it to them this kind of maximum throughput of 48 initially and then basically just like later versions of this over the next few FKS that that will continue to to to bring up the the throughput I think right now we we see a good path for another few X bump um and then of course we we're now kind of starting to evaluate or like starting to explore what what what basically the path beyond that will look like it's not like we have a specific um plan there yet but but the idea would be that um we make sure that there will always be um successive um throughput increases coming in in the next few FKS and there's there's more on this maybe soon

there's some considerations right now about different alternative paths and everything it's not concrete enough yet to to to be a specific ask so I'll not go into too much now but just just to flag that and then on the execution layer side that's actually a really interesting one um we kind of for the first time in a long time um on the on the L1 side are now working on um execution layer improvements again that that that have the explicit goal of scaling the throughput um I think like vitalic for example had had a blog post a while ago like that that um that basically some sort of like 10x plus minus um increase uh would would be important even even in a in a very rollup Centric uh worldview um and also there's of

course a lot of other reasons for for trying to have have higher throughput on the L1 so this is something where like we on the L1 are starting to to work on um much more in a much more focused way again on and that's again a departure from I think Last 5 Years there was very little of this work going on last four years at least and the most interesting point here is that of course many of you all are also now working on evm based execution systems um and are also currently working on scaling kind of the throughput significantly beyond the the current L1 style of throughput level um so there will be quite a bit of overlap in terms of techniques um changes that that could benefit both the L1 and the l2s and the settings are of course not

identical some things are possible in the L2 that are not possible in the L L1 but there will still will be synergies and so the question here and again for now this is not specific ask or anything but like just keep it in mind I think a really interesting question here is how can we leverage these synergies how can we make sure we don't just duplicate the effort um and that that any kind of changes that the L1 brings are also than useful for the L2 and the other way around that L2 improvements that have already been done or that are in the works can also benefit the L1 um and then of course also how does this intersect with these kind of um L2 evm Common Core ideas that we've talked about in the past um so basically I think given that this this the the the

L1 side here is changing quite quite quite a bit right now um this this is kind of like an active area where where I think people are currently trying to figure out how do we move forward in the best way um again no specific ask right now but like I think if you have thoughts on this um maybe now is not the right time to discuss this but do do reach out to us on the L1 side um I think K and I would be good kind of contact points to then these these conversations because I think having tighter collaboration um across evm um uh chains in the ecosystem on these points I think would be very beneficial for everyone um yeah and then just to round it off um I did uh put on just just to have some context in the long term we

also have like more kind of Step function uh increases on both of these CL and El sides Brewing so the CL that's kind of you might have heard about the Justin's kind of beam chain approach that I would just call it the proof of stake V2 basically where you just have like a bundled upgrade to to a version of of of the of the consensus mechanism that has many many nice features hopefully like something like uh single slot or three slot finality where you have much faster finality you have shorter slot times these kind of things um all of this hopefully coming coming with a beam chain in a few years um and then on the execution layer and that's maybe a bit more relevant for you all um there is now a pretty focused push on the L1 side towards ZK evm and then also

um uh uh Native rollups and of course ekm is kind of following what a lot of the l2s have already been doing and then native rollups it's a bit the other way around that's more way like the L1 is now exploring leading in a direction that would become relevant for many of you all so this is again something where I think our paths will kind of be pretty closely um tied together in the future so yet another area where we have to kind of figure out the best form of collaboration um yeah that's all for me on this I just points that I feel like I wanted to mention let me you see in chat if there's anything on this or if anyone has thoughts on any of the of this just now would be the time as well but again this was less less a request for feedback and more

just like some some initial guidance I guess um very quick like thoughts my personal thoughts about beam chain I saw like J's kind of like tweet about it it seems like on the call number one we plan to have eight CL teams um like basically eight CL clients to to to do that um it feels like not super necessary I guess I I would my personal opinion is that to

try to cap it at three because of the already the big coordination effort we saw on the uh like C like five clients uh situation so my personal opinion for like since to move faster would be like to cap the number of uh Sal teams or like EO clients in the future so that we can have less coordination efforts and like much faster implementation speed and much more Focus yeah I think that that that's good feedback I think in general context here is that um while a lot of these kind of proof of stake V2 features have been brewing for a while just and specifically came in with this vision of

having it be a one-time kind of Step function upgrade instead of like iterative roll out for these individual features so for now he's kind of the Project Lead of this beam effort and he comes at it with a kind of um very specific um Direction uh I think there are still a lot of questions around this including what you just said like I think kind of how many beam teams do we need how does it relate to the existing consensus layer teams um I tend to agree with your take on this actually um maybe I wouldn't quite C it at three but I think plus minus this is kind of what I think we should we should roughly come out on um I would say though just just for context like I think given that at least for layer 2os I don't think many of the features that the beam chain will

bring directly will be so relevant I think kind of the The Blob throughput is and and then the the El side changes I think are more directly impactful for l2s and maybe with the one exception of um or like the exception of faster finality and and shorter slot times um I I think the question is more once we once we move over to the beam chain does it impact the speed at which we can then say for example continue to roll out further um the a throughput changes right and so so there I think we have to make sure that we are uh in a play in a in in a space where we basically make sure we we we keep or ideally even improve our iteration speed and and and and and are not ending in a situation when when now we basically are even

slower than we are today so yeah but yeah good feedback and one other like additional point to this is that in the beginning with the beacon chain um there were also several more clients that ended up dropping out um as development went on and I think Justin's trying to cover for that um that eventual loss so yeah it's I think more based on that more based on trying to be inclusive and welcoming and saying hey everyone can do what they want to do for now and then see where things get us in the future I think it's very it's very easy to say you want to

start a project but to actually like sit down and ship a client is very hard work is I'm sure all of you are aware um so I think it's yeah trying to cover for a bit of those losses awesome yeah as I said kind of a lot of these topics will kind of be more medium term for us to to kind of to to to get it more into over the next few months and but yeah then that that would be all from from my side for the kind of ACD research update great thank you Anar um next

topic is uh we have uh Jack trumer to talk about RC 7755 um and sort of what's the latest happening there yeah sure thanks Carl uh let me just give me a second to I'm gonna paste a couple links in the chat here and then I'll share my screen so here's a demo app that we put together and then use a link to the current repo cool um can I share my screen it looks

like I am not allowed to oh sure sorry give me one sec I think I pressed the button now that should allow you to do that awesome thank you you okay can you guys see my slide yep we got you cool all right so hey everyone I'm Jack from the base team uh I've been working on rrc 7755 so I'm going to provide a quick update today uh so this is previously known as our IP 7755 you may have heard of it as that it has since been categorized as a uh

request for comment as as opposed to a core Improvement proposal so um hence the name rrc 7755 it's like an ERC but for rollups so this is how it'll be referred to moving forward um to give a little bit of a background for anyone who's unfamiliar it is a standard for cross-chain calls in the ethereum ecosystem um but is designed in such a way to be flexible enough to support non evm chains in the future and the uh the core architecture is similar to a lot of the intent protocols that the ecosystem is becoming familiar with now um it relies on three main components there are contracts for message passing um sophisticated offchain actors that we're calling fulfillers for relaying messages

on behalf of users and then a settlement layer for verifying call delivery as a precursor to fulfiller compensation so um you can see in the diagram here um what this uh architecture looks like for like the basic happy path route a user would on a source chain submit a request to an outbox contract uh where the request specifies exact calls to make on a destination chain and the request is also accompanied by some sort of funds for compensation for a fulfiller to uh respond the outbox then alerts the fulfiller network by emitting an event uh if the request makes sense the

fulfiller submits the request to a destination chain inbox contract which is defined in the standard uh and the fulfiller also fronts any fun needed for the call execution in this call the inbox contract then routes the individual calls to their specified targets and if all are successful it creates an execution receipt in its storage in such a way that it's like I guess considered immutable like it can't be changed or deleted after it's created and the existence of that receipt in storage is used as the target of a storage proof that the fulfiller can then generate after a delay to submit back to the source chain outbox contract to prove that they delivered the calls and and if that checks out the outbox releases the funds for compensation and

this is enabled by state sharing between ethereum and its Roll-Ups so you can imagine if source and destination here are two l2s that roll up to ethereum they are posting State representations to a shared uh like L1 and then from Source chain if you have an L1 state representation exposed in its execution environment you can prove something about the L1 State and uh like I said assuming the destination chain is posting State representations to L1 you can then prove something about the destination chains state so um that's kind of high level how it's working if you want to learn more I invite you to read The Proposal so over the last couple months we've been doing a lot of testing on uh testet the contracts are currently

deployed to basoa optimism saoa and arbitrum sapoia for uh to to start with and all possible routes between these three chains have been successfully tested end to end so I can confidently say the Paradigm Works which is uh very exciting and so the contracts for a V1 are now in a locked state for audit and um yeah so that's the current state of of the project to get it to this point it involved implementing a handful of like State validation provs and this is because different chains have different data models on L1 so if you want to prove something about their state there are subtle differences in terms of um like implementation

details there so what we have right now is approver for op stack and arbitrum um chains based on finalized state so we'll come back to that in a little bit and then uh there was a contribution from the cross chain Alliance team uh of creating a hashy prover which relies on relayed block headers from an oracle aggre aggregation Network that they have called hashy and this will be huge for connecting um nonm chains in the future and uh um yeah so another area that uh we spent significant effort on in recent months is to add smart Account Support so for like the standard request flow or like a basic 7755 request the

payload is essentially like an encoded calls array where you specify the call Target um encoded call data and if any like native value is needed but uh We've also added support for the payload to be an encoded user op and so this support reports if uh users are using smart accounts they can also relay cross chain messages here that will utilize their smart account on both both chains and uh more details on that in the next slide we'll come right back to it and then lastly just a quick shout out I I just pasted the link in chat um but we have a demo app to showcase the 7755 flow um and that's what this link is here and what the screenshot is of in the top right um feel free to play around with

it and uh let me know any feedback or if anything doesn't make sense it is not meant to be from the perspective of the end user where like for example if you're trying to bridge funds you just click Send and then your funds magically appear on the destination chain um it's purposely manual and tedious and shows you every step that needs to happen for that to like work out so when you when you interact with the demo you're interacting both as the end user and as the fulfiller so just an FYI to dive a little bit deeper on the account abstraction support um to give you some context here the motivation behind this came from a concern that was raised at Devcon back in November in Thailand um of the transaction flow that

I went through a couple slides ago being like fine for token swaps or like any arbitrary unauthenticated calls but in the event that the target destination of the call depends on message. sender um and you would need the sender to be the user like the requester themselves then that's that architecture falls short so if the user is actually a smart account um there's quite a bit of ERC 4337 infrastructure um already widely adopted on many chains that could be reused here uh in the 7755 context and uh that would allow us to Route the call through the smart account directly here as opposed to an inbox contract which would solve

that authentication issue from the targets perspective um but then you run into like if you just have like an iive smart account integration with no pay Master functionality you run into that the smart account needs to be funded for gas and call execution on the destination chain which kind of defeats the purpose of one of the built-in and variants of the system where the fulfiller should be the one sponsoring gas and uh funds for call execution so to solve that we introduced uh pay Master functionality to the system uh that was originally the inbox contract itself but uh ultimately decided to separate it into its own contract but is owned by the inbox contract contct and the core I guess responsibility of the

pay Master is to store deposited funds for fulfillers that are earmarked for sponsoring these 7755 transactions and so in order for this to work a fulfiller would have to predeposit uh funds of whatever like currencies they want to support on that destination chain into this pay master and the pay Master keeps track of uh the allocation of funds like between the fulfillers themselves and then instead of submitting the request to the inbox contract itself the fulfiller actually submits the user op to the 4337 entry point contract and so from that point the request goes through the standard 4337 flow so I'll brush like I'll I'll skip the the standard

steps there um and just talk about the pay Master like what's relevant here um for the validation of the transaction um like I said the pay Master should have pred predeposited funds from fulfillers so uh at like the current moment this requires the fulfiller to be the like the transaction origin um so like the fulfiller wouldn't be able to relay or like forward the request to a bundler um just like as a call out I guess but uh so from the pay masters perspective the fulfiller is tx. origin and because of the fact that the fulfiller is the one submitting the message it's kind of like built-in authorization to spend the funds assuming there is sufficient funds

predeposited and so that's like the core idea behind the pay masters authorization logic here if that checks out then the calls are routed through the smart account itself um and that's like the sender from the perspective of the target like I said and then after call execution the entry point calls back into the pay Master with a posttop call uh where one of the inputs here is like a call result enum that specifies if it was successful or not so that allows the pay Master to then um validate that the calls were successful and only if they were we could create a receipt in the storage of the inbox contract up here and once that receipt is created uh the rest of the 7755 architecture can work as as

previously designed and this is um secure if the pay Master is owned by the inbox so that these two addresses are um like aware of each other if that makes sense so looking ahead uh have a couple of I guess um notes here this is the repo link that I pasted in the chat where all this work is happening um like I said earlier the contracts are under audit right now um optimistic they'll be ready to go uh and be considered quote unquote main net ready by the end of q1 that largely depends on how the audit goes of course if there's any findings how long

it takes to address them um but that's just like a rough timeline looking ahead the official proposal is slightly out of date at the moment all the work that in progress of the proof of concept has gone through in recent months so I'm spending time uh getting that up to date that shouldn't be longer than like within the next couple days I should have a PR up that um brings the proposal back up to date so would love feedback once that is ready uh the base team will also be spending time working on U and building up better documentation and just blog Post in general about the standard just to spread General awareness and education about how the system works as a PSA to any solver networks out there I want to chat with you um one like having

the contracts ready for mainnet is one thing but the system doesn't work without fulfiller support or solver support so um I would love to chat if any solver networks are interested in supporting I am currently in in conversations with a couple teams as well as the oif uh implementation team to add 7 755 support so that would be huge but of course the more the merrier also as a PSA to other L2 networks that don't fall under the data model category of an OP stack chain or arbitrum I want to chat to you as well if you want your chain to be supported by 7755 um we'd have to work together to get a prover setup for uh like that's customized to your specific data model um so that's another call out and then for Dev workor

itself like I said earlier the op stack and arbiture improvers are based on finalized state which I think is a necessary feature to have for maximum security um but the problem with that is the opportunity opportunity costs for fillers having to have their funds locked for uh like the entire challenge window of an optim optimistic rollup so I'm interested in getting Prov set up against unfinalized state where requesters can set their risk threshold of um how close to finalization they expect the state to be in order for a fulfiller to be able to prove against it and this is uh in an effort like to add a mechanism for

making the requests more attractive to fulfillers if they don't have to wait as long uh this next idea was from the arbitrum team or rchain Labs team uh to add caching solutions to prevent verifying the same state twice so that's kind of like an optimization idea that um I plan on working on in the near future and then lastly I'm very interested in uh checking out uh verifying ZK snarks of storage proofs and seeing if that can be used as an optim optimization technique and the examples I've gone through so far the route is just like L2 to L1 to L2 so there's those two hops of proofs that are needed but once l3s and Beyond are in the picture you can imagine proof

routes could get more and more complicated and so having a way to verify these proofs of uh routes that increase in complexity without the proof verification increasing in complexity I think would be very valuable so just a couple ideas that are going to be top of Mind as we move forward and that's all I have for today so yeah thanks for your time and uh let me know if there are any questions or concerns or just want to chat about any of this I'll be around on Telegram and x and um all all that fun stuff so thanks Jack um can I ask a question really quickly yeah yeah I was wondering so like if do do you guys are your all your transactions Atomic or like what

happens if I need to do like a refund to the pay master in the middle of the transaction uh let's see here so can you explain like exactly what that situation would look like yeah for example like let's say the final call fails then does the pay Master lose its gas deposit um so like maybe for example you're allowing for some partial execution so some of the steps will succeed or up and others will fail or maybe you just want a fully like atomics transaction where either everything is successful or not so I just wondering which one you're doing I see um yeah right now it's fully Atomic so they they either all settle or none of them settle um at least that's the intended uh idea of the design here and

um yeah so that it the the storage receipt will only get created if all of the calls are successful um I guess I'd have to look deeper into it in terms of the 4337 infra if some of them succeed and some of them don't how that refund mechanism works I actually I'm not sure off the top of my head I'd have to look into it yeah and then the the other question I had is let's say if the user triggers a bunch of different calls in quick session how do you guys handle the ordering so like for example with smart accounts you can have two dennes um so are you guys using that that non or or how are you doing like this the ordering um that's an interesting question uh so

the the standard uses uh uh a canonical not as well um but mostly for ensuring that every request is unique in terms of the ID generation because uh the the each request gets an ID that is a hash over the request data in terms of how the fulfillers order the transaction on the destination chain there's nothing in the like core architecture that enforces is that um there is I can point to the um the proposal itself there is a pre-check mechanism that could uh probably be used to enforce ordering um if we wanted to do something like that but uh the the like the core contracts that I went over today are unopinionated

about transaction ordering okay so thanks for clarifying cool thanks for uh thanks for your time everyone or may I just ask one more uh quick quick question um yeah presentation curious how you think about this in relation to the um super chain interop stuff I know that um obviously there's super tight coupling involved there and I know they don't necessarily wait for finalized uh blocks to um

finalize the um or to from a user perspective have the um call go through and um just kind of curious how your solution relates to that and then how the user experience will relate um given the extra length that interop seems to be willing to go right now yeah I see um so it's kind of like a separate solution and the way we've thought about it up to this point is that the super chain interop solution could be like the core interupt choice for being within op stack chains um and then 7755 could be used to bridge from Super chain to external chains um in the ecosystem it still requires building uh op stack provs because if you're sending

messages back into op stack chains from outside of like that Network super chain interop isn't relevant there like You' need something to bridge that Gap so um that's kind of how I'm thinking about uh 7755 and uh I forget if there was a second part of your question how close do you think you can get the user experience on the more General solution which is yours to the more specialized solution the interop thing I see in terms of like the the user-facing interface that you would yes work with um I I don't have an answer for that off the top of my head I'll make a note to Circle back around on it cool thank you uh one I question um could you

quickly run uh the demo through the Versa app uh if if you can share your screen and run the demo that I think would be great even to to share later on social media or whatever sure uh yeah give me one second sorry yeah I didn't I didn't see that hands raised when I was sharing my screen earlier no re okay so uh let's say we connect um okay so yeah this is the demo site it

right now is set up so that you're uh working on behalf of a mock account and this uh like the the base setup that the site loads with is you're bridging some amount of eth from arbitrum aoia to base aoia um and so that's what these steps are gonna like walk you through as a first step it assumes you have to prefunds already funded but I um have not added a way to skip a step so we're going to go through it anyways um let's say we want to bridge uh 0 one e so uh we'll go ahead and transact to

preunit cholia transact confirm oh sorry uh give me one I'm gonna stop sharing to get this password sure sorry about that oh yeah it's all good one second okay okay um here we go

okay so um you can see here we just had uh the point one it might have gone through twice because of my redoing it but um I prund this account with 0.1 eth so now um from the destination change side we'll have to pre fund the pay master and this is because of the 4337 flow that I walked through in the slides we have a paymaster deployed to Bas apoia and uh by default it is for supporting user op uh submission to destination chain but to support better Capital efficiency um you can also use the pay Master uh like for regular accounts as well so uh from the fulfillers perspective um this is this is what I have in in test eth we

can go ahead and transact to pref fund the pay Master with the0 one e that's going to be needed for the call execution so we'll go ahead and add this so that's that's where this is coming from here and I forget if I said earlier but the purpose of this demo is going to be to bridge what I set here 0.1 eth from this account on arbitrum apoia to this account on base apoia so uh the first step here is going to be to uh yeah so these first two steps were kind of like to set up the the scene for like having this ready for that bridge transaction now we can um start like this is the first transaction first and only transaction from the end user

perspective where you submit the request to br the eth from from arbs aoia to basoa so we'll go ahead and transact this is going to create the 7755 request with an encoded call array of essentially um transferring that amount of eth from the destination chain inbox into the account it's like into the account here and so what's going to happen is the inbox will pull the 0. one E from the pay Master then execute the call that says to um transfer the eth into the account itself and I'm confused why this isn't the demo Gods aren't on my side um something must be going on with the the balance update but we'll proceed oh

sorry I I forgot where it was we have to fulfill the request to see the balance update on the destination chain so all good um what we should have seen there was the point1 go from the account into the outbox on Source chain which it did and what you're seeing is 0. 102 this uh is adding just a hard-coded 2% uh fee on top of the value as the the compensation for the fulfiller um this is kind of like a naive approach just for demo purposes in like a production environment there likely is going to be some more sophisticated uh mechanism for pricing what these transactions are going to cost but that is an unsolved problem uh at this point so now on the destination chain as the fulfiller we will fulfill the

request and now is when we should see the pay master balance get pulled into the Inbox and then routed to the account there we go um and at this point in time from the end user perspective this is done like the end user got 0.1 out of their account on arbitrium apoia and it showed up in their account on Bas apoia um so like they can go on with their life like nothing else is happening here but now behind the scenes the fulfiller needs to come back to Source chain to claim their compensation out of out of the outbox here and the way they do that is by generating a proof of the of that execution receipt and the destination chain inbox contract so that's what this step is going to do and uh for the demo because we don't want to have to wait

for Bas aoia finality on sapoia we're using that Hashi prover that I that I mentioned um which is going to relay block headers from Bas apoia directly to arbitrum apoia and then prove against that block header so that that's what this proof is is doing here um it just looks like a bunch of yeah numbers and letters but um that's I figured it'd be useful to see what it actually looks looks like if we go to the next step uh this is now going to trigger sending the Bas aoia header into aritmia it's just necessary to be able to prove against for the demo um this is a step that would not be needed in a production environment and yeah so now that that's there we can claim the reward so this is

going to use the proof from this step here and uh that'll result in pulling the 0. 102 eth out of the outbox and into the fulfiller so we go ahead and transact there should see the balance update in a second hopefully up here if it doesn't I might just have to refresh yeah I just had to refresh so we pulled the 0.12 eth out of the outbox and it's now in the fulfiller and that closes the loop on the transaction flow that's about it so um the the demo so

that's like kind of the basic setup that it is preconfigured to to show but you can also like I I added a Mach usdc so you could mint yourself some some mock usdc um to to play with that and see how the flow changes for like using an erc20 um and then it also shows a smart account flow it might be kind of confusing because this doesn't actually have you use a Smart account least with the way the demo is set up um this just creates a user op under the hood and then has the fulfiller submitt it to the entry point contract on destination but um I guess it's it's just confusing because from like the the UI perspective it's kind of doing the same thing but um

under the hood it's actually a a user op so that's that's what's happening here just to show that it's supporting both request types um and then there we also have optimism spoa in here so you can try different chain connections or combinations and and uh and yeah feel free to play around with it great thank you for the de very interesting yeah thank you yeah that was amazing thank you very much um another question is is it possible to have some kind of like call back to the originating chain um or would that have to be like as a part of

the proof that's normally generated or would you have to make that a second um 7755 call from the sort of the destination chain back to the originating chain I think uh as a first pass idea on how that could work it probably would have to be a separate 7755 call but if you make one of the encoded calls in the request um another 7755 request coming back into outbox on that destination chain you could probably do it that way um their contracts yeah the contracts themselves don't have like a call back mechanism

but it should be flexible enough that you can encode a call like another 7755 call within the original request if that makes sense okay cool thanks okay well uh thanks very much for that uh awesome demo Jack that is all we really have time for today but uh thank you all for attending and uh chat all async uh yeah please I appreciate feedback on all those P topics mentioned earlier and uh yeah have a great

week thank you bye guys thanks everyone thank you bye