Jihoon:Okay, thank you. Hello everyone, welcome to Fossil Breakout 21st. Today, we have a research presentation.
Transcript
Jihoon:Luca from L2Beat will gonna give us a talk about fossil and native roll-ups.
Jihoon:A native roll-up is an EVM-based roll-up using the execute precompile, so you can minimize the risk of bug, governance, and so on and so forth. For anyone interested, please take a look into this article.
Jihoon:Let me share it in the chat.
Jihoon:After the talk, we can share development updates, as usual. So, please welcome Luca from L2Bit. Luca, if you're ready, the stage is yours.
donnoh | L2BEAT:Hey, everyone!
donnoh | L2BEAT:Thank you for inviting me. So…
donnoh | L2BEAT:I don't have a… I don't have slides, because I was in…
donnoh | L2BEAT:Singapore this week, and didn't have the time, but maybe it's even more interesting this way.
donnoh | L2BEAT:So, I can maybe share the, Let me see…
donnoh | L2BEAT:The… that website that you shared in the chat?
donnoh | L2BEAT:And what I want to do is to… let me say…
donnoh | L2BEAT:is to give you kind of a small introduction on native rollups, the idea behind native rollups, and why I think .fosale, is useful, is very useful here.
donnoh | L2BEAT:Especially for native roll-ups, but not only. So…
donnoh | L2BEAT:The idea behind native rollups is… so let's assume, first of all, that we have, statelessness on all 1, so we can…
donnoh | L2BEAT:we can execute transactions, we can perform the state transition function L1, without having the full state, so we just have
donnoh | L2BEAT:Pre-state route, we have a post-state route, and we have a list of transactions, which are possibly, you know.
donnoh | L2BEAT:Stateless, traces to be able to execute them statelessly.
donnoh | L2BEAT:And now the deal here is… if, L1…
donnoh | L2BEAT:pool nodes can perform a state transition function which is stateless. In principle, they can perform the state transition function on arbitrary states, not only the state of L1.
donnoh | L2BEAT:So, in principle, these L1 full nodes can apply the set position function.
donnoh | L2BEAT:With the state of the roll-ups as well, right? And…
donnoh | L2BEAT:If done, you know, naively, with re-execution, it doesn't bring many benefits, because you would consume the same resources.
donnoh | L2BEAT:But if we also assume that we have ZK on L1, this becomes much more interesting, right? So…
donnoh | L2BEAT:The idea behind native rollups is to reuse the same stack that is used for Ethereum itself, but for the…
donnoh | L2BEAT:For the… for the roll-ups as well. So… The goal of…
donnoh | L2BEAT:the NativeOps proposal is to implement a precompile, which is called the execute precompile, which it… what it does is basically, a recursive function to the state transition function. I have two variants in my documents, one that does a
donnoh | L2BEAT:recursive call just to the apply body. I assume that, you know, you are familiar with the… with what I'm talking about in the execution layer, given that, you know, post-sale touches this stuff.
donnoh | L2BEAT:So one variant only does a recursive call to apply body, it skips the header checks, while the other variant does, you know, it's a recursive call to the state transition function with all the header information, so this is a little bit more…
donnoh | L2BEAT:is a little bit longer, while the other one is a little bit shorter. And the reason why we have both, because a lot of rollups today, they skip header checks in the first place, so it's interesting to have both. In any case.
donnoh | L2BEAT:The idea here is… The executePrecompile takes as an input.
donnoh | L2BEAT:all the information that goes in the block environment, that is then used in the block environment, of course, and the transactions, right? So, an input is the list of transactions, which is ideally a link to a blob, or many blobs.
donnoh | L2BEAT:And then, all the information that they usually require for this, for this block environment. So, for example, the chain ID, this is specific to each roll-up, this is an input. The pre-state, this is supposed to be saved in a contract, another one, and you pass it again as an input.
donnoh | L2BEAT:You can have arbitrary guest limits, you can have arbitrary coin base, this could be, you know, a predefined address, it could be…
donnoh | L2BEAT:set to be the same as the L1 Coinbase, if you're, for example, a base roll-up.
donnoh | L2BEAT:And… in general, you know, all these values can be inputs.
donnoh | L2BEAT:And…
donnoh | L2BEAT:And these inputs are then passed to the apply body, which does the actual transition, and checks that the…
donnoh | L2BEAT:transition from a pre-state, which is again a state root, and a post state, is correct, using the same execution environment that Ethereum already uses.
donnoh | L2BEAT:And the cool, like, a cool way to reason about native rollups is
donnoh | L2BEAT:The same is that… the same relation that there is between the consensus layer
donnoh | L2BEAT:and the execution layer for Ethereum. The same relation can be… Phones!
donnoh | L2BEAT:between L1 and L2, in the sense of…
donnoh | L2BEAT:For example, the broadcast limit
donnoh | L2BEAT:no, sorry. Like, the Coinbase is something that information that comes from the consensus layer, right? Like, all the information that comes from the consensus layer
donnoh | L2BEAT:now comes from L1, from the perspective of a native roll-up. So, another, like, obvious example is, Randall, right? This is something that comes from the consensus layer. For native roll-ups, this is an input that comes from L1.
donnoh | L2BEAT:And L1 can decide whether to, like, either pass the things from the consensus layer, or, like, the same things the other one already has, or do something else.
donnoh | L2BEAT:And this is quite cool, because now you kind of have a programmable consensus layer in the form of a smart contracts, which is… which is super interesting.
donnoh | L2BEAT:So this is the, like, short LDR about native rollups.
donnoh | L2BEAT:And… the… The important thing about this precompile is, okay, we want to do this recursive call.
donnoh | L2BEAT:So that, you know, the reason why we want to have this recursive call, by the way, is twofold. Our first reason is
donnoh | L2BEAT:we want projects to upgrade every time Ethereum upgrades, automatically, so if there's, you know, if there is a fork, this changes, because there is a new structure, a new…
donnoh | L2BEAT:pre-compiled, and it is also a new transaction type, let's say 7702. They would also be automatically supported on the native products as well.
donnoh | L2BEAT:So they… these roll-ups wouldn't need to have their own dedicated governance just to be… just to have feature pilot fever one, and the second reason is…
donnoh | L2BEAT:To be bug-free, because if there is a bug.
donnoh | L2BEAT:In a native roll-up, it also means that there is a bug on a one, and…
donnoh | L2BEAT:it's gonna be fixed with a fork. This is not…
donnoh | L2BEAT:what happens today if there is a bug in our rollout? If there is a bug, then L1 is not gonna save them.
donnoh | L2BEAT:So, so we want to do this recursive call, but the thing is, the L2 environment is a little bit different compared to L1.
donnoh | L2BEAT:It's not enough to do this, naively.
donnoh | L2BEAT:And that's why, like, there is… there are other things, around.
donnoh | L2BEAT:Not many, because, again, we can see that it's very short.
donnoh | L2BEAT:But we need some… some things. So, for example, one thing that needs to be supported is messaging.
donnoh | L2BEAT:From L122, and I have this page that describes
donnoh | L2BEAT:The way that current system works.
donnoh | L2BEAT:like, at least popular ones, or, like, our most interesting ones, or unique, like OpiStack, Lina, Type, and Obstac, how they implement L12 messaging.
donnoh | L2BEAT:Which is used for deposits, token deposits from L1. You deposit the token on L1, it needs to appear on the L2, and then you need to implement withdrawals, from L2 to L1, right? Messagingsystem.
donnoh | L2BEAT:For example, is able to burn those tokens on L2.
donnoh | L2BEAT:And, unlock the tokens that are locked in an escrow normal.
donnoh | L2BEAT:And… One of those differences?
donnoh | L2BEAT:from L1 execution environment and the L2 execution environment is forced transactions.
donnoh | L2BEAT:So… we really want rollups to have the same censorship resistance as L1, as Ethereum. And this means that
donnoh | L2BEAT:If, for example, you have a rollup that has a centralized sequencer, and the centralized sequencer is censoring you.
donnoh | L2BEAT:you should be able to send your transaction on L1, And…
donnoh | L2BEAT:have the guarantee that if L1 includes your transaction, then also the L2 will process such transaction.
donnoh | L2BEAT:And… you know, I… I work at L2Peat, and…
donnoh | L2BEAT:One of the most difficult things to implement for a project, is forced transactions.
donnoh | L2BEAT:They're very complicated. Every project kind of has a different way to implement forced transactions. For example, if you look at OP stack.
donnoh | L2BEAT:They have a new transaction type.
donnoh | L2BEAT:This transaction type is called a repository transaction, and they need to heavily modify How the derivation works?
donnoh | L2BEAT:I can show, maybe…
donnoh | L2BEAT:Like, in the derivation, if you look at the… this is the OP.
donnoh | L2BEAT:spec…
donnoh | L2BEAT:when they derive the transaction list, like, it's quite complicated. Of course, I will not go into the details, but they…
donnoh | L2BEAT:kind of… significantly modify DL1 execution environment to be able to, support first transactions.
donnoh | L2BEAT:If you look at Arbitrum, the way that Arbitrum implements first transactions, it is even more complicated. They have not one new transaction type, but they have many.
donnoh | L2BEAT:This many.
donnoh | L2BEAT:And… There are projects that try to minimize the, the diff.
donnoh | L2BEAT:with L1, so one example is…
donnoh | L2BEAT:Linear. Linear is a project that wants… To be an L2…
donnoh | L2BEAT:without touching the execution clients at all, right? And…
donnoh | L2BEAT:Because of this, they have been particularly struggling with implementing first transactions.
donnoh | L2BEAT:Because R1, again, doesn't have a concept of first transactions.
donnoh | L2BEAT:And… We talked with them for a long time. They presented us with a doc.
donnoh | L2BEAT:With a proposal for forced transactions.
donnoh | L2BEAT:And basically, you know, the simpler way you can implement first transactions today in a system is to…
donnoh | L2BEAT:like, with a centralized sequencer, is to have some windows some periodic windows.
donnoh | L2BEAT:where anyone can sequence transactions. So basically, you have…
donnoh | L2BEAT:These windows, where you become a base roll-up.
donnoh | L2BEAT:Linear called, calls this block base blocks.
donnoh | L2BEAT:So every now and then, there can be a base block.
donnoh | L2BEAT:Which is problematic, because if you… for a certain period, you're paced, you get into the… all the complexity of being paced.
donnoh | L2BEAT:of having base sequencing. So, for example, you have degradation for pre-confirmations.
donnoh | L2BEAT:And the UX is not great, in general.
donnoh | L2BEAT:And… We also talked with Aztec, you know, which is this privacy L2, and also for them.
donnoh | L2BEAT:It has been, like, they're not TBM, but also for them, it has been, like, quite challenging to implement first infrastructure mechanism, and they also are planning to…
donnoh | L2BEAT:Maybe use this base windows?
donnoh | L2BEAT:Oh…
donnoh | L2BEAT:But in any case, the message that I want to send you is, implementing forced transaction is very difficult.
donnoh | L2BEAT:And…
donnoh | L2BEAT:So, if we want to implement first actions for a native roll-up, what is that we would need to do?
donnoh | L2BEAT:Either we go with this base of Windows, but again, the UX is terrible. I don't think anyone really would want to do this if there is another way.
donnoh | L2BEAT:The other way is… dot…
donnoh | L2BEAT:So, the high-level idea of forced transactions is the sequencer is answering you, you send that transaction on all one. On all one, you have a smart contract that queues
donnoh | L2BEAT:These transactions, right?
donnoh | L2BEAT:And then, you need to have a mechanism on all one, such that…
donnoh | L2BEAT:You take the sequencer batches, the list of transactions, to the sequencer.
donnoh | L2BEAT:Wants to post.
donnoh | L2BEAT:You take this first transaction queue.
donnoh | L2BEAT:all-in-one, where anyone can just push transactions to this queue, and then you need to have a mechanism to check
donnoh | L2BEAT:That the sequencer actually includes the transactions
donnoh | L2BEAT:That are in the first transactions, right?
donnoh | L2BEAT:So, you know, this might sound familiar. Basically, the first resuction queue is
donnoh | L2BEAT:Works as an inclusion list, and you want to force the inclusion list in the
donnoh | L2BEAT:In the sequencer botches.
donnoh | L2BEAT:And to do this, it is difficult, like…
donnoh | L2BEAT:most of the time, this is done as part of the derivation, but, like, in general, this is done as part of the state transition. This is not a check that is on L1, because checking
donnoh | L2BEAT:That some transactions that you have saved, let's say, in storage, on L1, are included in a blob.
donnoh | L2BEAT:Because the sequencer on OpenL2 posts stuff in a block.
donnoh | L2BEAT:probably requires a ZK verifier. And the purpose of native rollups is that, you know, we want to simplify managing
donnoh | L2BEAT:a roll-up at a point in which projects do not even need to think about ZK verifiers, right? So this is a problem.
donnoh | L2BEAT:So, I was looking at fossil, and…
donnoh | L2BEAT:And the cool thing about Fossil is that it implements exactly this mechanism, from an execution layer perspective. So I'm, you know, I'm not looking at the consensus layer at all, because
donnoh | L2BEAT:It doesn't matter for native rollups, in the sense of the consensus layer everything that L1
donnoh | L2BEAT:fetches from the consensus layer, and a native rollup will fetch from a contract on L1.
donnoh | L2BEAT:So if, you know, I looked at the spec, again, I'm not super familiar, but my understanding of the spec is
donnoh | L2BEAT:There is this new inclusion list that is added to the state transition, and then…
donnoh | L2BEAT:there is this, validate inclusion list transactions, I think, which does exactly, the thing that forced transactions are supposed to do.
donnoh | L2BEAT:You have the list of transactions that comes from the builder, you have the inclusion list that comes from somewhere else, and then there is this piece of code that checks that the…
donnoh | L2BEAT:Dot the… The transactions that come from the builder include an encryption list transactions, right?
donnoh | L2BEAT:So now, if we have this on L1, Aww.
donnoh | L2BEAT:also the execute precompile would be able to make use of it. So…
donnoh | L2BEAT:If we go, you know, this is the execute precompile. At some point, the execute precompile would do a say transition call.
donnoh | L2BEAT:with a blockchain and a block. If we have four cylinder 1, here we would add an inclusion list.
donnoh | L2BEAT:And… These inclusion lists would come from a smart contract. So again, the idea here is
donnoh | L2BEAT:there is some function that allows users to send transactions one-on-one. These transactions with the full signatures are saved in the smart contract, and then
donnoh | L2BEAT:the… This list is passed as an input to the execute precompile, so that the
donnoh | L2BEAT:State transition of the roll-up is conditioned based on these encryption lists.
donnoh | L2BEAT:And this would allow to have… to implement first transactions.
donnoh | L2BEAT:Without having to worry about a dedicated mechanism to check for inclusion.
donnoh | L2BEAT:So, I talked about, you know, checking inclusion in a blob.
donnoh | L2BEAT:This is not something that Fossil handles today, or is supposed to handle.
donnoh | L2BEAT:but… I'm kind of thinking in the future, because… when…
donnoh | L2BEAT:Ethereum will move to ZK.
donnoh | L2BEAT:The idea here is that L1 itself will also post It's transactions.
donnoh | L2BEAT:To blobs.
donnoh | L2BEAT:So, Fossil in a ZK ward.
donnoh | L2BEAT:also kind of needs to check inclusion, within blobs. This is, like, a future problem, open problem, whatever, but, like, I'm assuming
donnoh | L2BEAT:that's… L1 will fix for sale with blobs.
donnoh | L2BEAT:By itself, eventually.
donnoh | L2BEAT:And… Native roll-ups will be able to use the exact same mechanism.
donnoh | L2BEAT:For… for this.
donnoh | L2BEAT:So, I think I can… Stop here, if anyone has questions.
Jihoon:Great, thank you, Luca. So,
Jihoon:You've covered what native rollups are, challenges of implementing forced transactions for rollups with centralized sequencers, and how can we add forced transactions to native roll-ups.
Jihoon:If I understood correctly, I think the main idea is to use the inclusion list transactions field of state transition function to enforce the forced transactions, and
Jihoon:Those will come from a smart contract.
Jihoon:And any user can send and save transactions to the smart contract, whichever they want to enforce, right?
donnoh | L2BEAT:Yes, yeah, exactly. So, the… the thing that I still need to figure out, and that maybe, you guys can help, is…
donnoh | L2BEAT:how to handle the complexities of sending transactions to a smart contract compared to the mempool, right? Because it could be that you send a transaction to inclusion lists, these are used as an input to the state transition, but…
donnoh | L2BEAT:these transactions don't actually get in because of, you know, gas limits or whatever, right? So…
donnoh | L2BEAT:There is a problem of, like, resubmission, because… It could be, you know.
donnoh | L2BEAT:But they don't… like, we don't have a mempool that keeps the transactions. These transactions are actually consumed.
donnoh | L2BEAT:So this is kind of the complexity that needs to be solved, but I'm pretty confident… like, I'm pretty optimistic that they can be solved. Also because,
donnoh | L2BEAT:Existing roll-ups already have this problem.
donnoh | L2BEAT:In a way or the other, with first introductions.
Jihoon:So, as long as we… Somehow have the transaction included in a blog.
Jihoon:It's… okay, right? As long as the transaction… Has… have no problem.
Jihoon:When it's…
Jihoon:when it interacts with a smart contract, like, there is no, like, revert, no whatever, that just… yeah, if that execution goes okay, then all we need to care is whether the transaction is included in the block.
donnoh | L2BEAT:Yeah, yeah, like, what I'm worried about is, let's say,
donnoh | L2BEAT:a transaction is at the tip of this queue, right? It is…
donnoh | L2BEAT:It is used as an input.
donnoh | L2BEAT:Of this transition, recursive call, like, as a… in a crucial list.
donnoh | L2BEAT:But then… The transaction is skipped.
donnoh | L2BEAT:I don't remember exactly where, this is done.
donnoh | L2BEAT:Like, where is it?
donnoh | L2BEAT:Here, right?
donnoh | L2BEAT:Where does this continue? In the spec?
donnoh | L2BEAT:What happens if a transaction is skipped? You would need to resubmit the transaction on L1 in this queue.
Jihoon:Yeah, the… that part is… so, you can see to continue here. The first one is to check the… if the IL transaction is not a blob transaction, because currently we don't support blob transaction. Right.
donnoh | L2BEAT:Yeah, that's fine.
Jihoon:Yes, you know, because of some possible other factor. And the second one is, actually… is…
Jihoon:It checks if the… Not included
Jihoon:IL transaction could have been appended at the end of the block.
Jihoon:So… What we want is…
Jihoon:if an IELT transaction is not included, then we are executing lines below 1,110, you know? And…
donnoh | L2BEAT:Yep.
Jihoon:If we are hitting that line, then…
Jihoon:we want to see if the IL transaction cannot be appended at the end of a block. So, when we try to validate and execute a transaction at the end of a block.
Jihoon:if we have any kind of, you know, exception, then that's fine. That IL transaction is validly omitted.
donnoh | L2BEAT:Yep.
Jihoon:So that's what the code is trying to achieve, and… Oh.
Jihoon:Right, I guess you're saying that there could be a possible case that a forced transaction can be validly omitted for some reason.
donnoh | L2BEAT:Yeah, yeah, exactly. Like, what happens in that case? In a fossil, a normal fossil, I think it would remain in the mempool, right, and can be, picked again.
donnoh | L2BEAT:I would assume.
donnoh | L2BEAT:In this case, you probably would need to resubmit.
donnoh | L2BEAT:Your transactional one.
Jihoon:I guess it depends if the transaction cannot be included In subsequent blocks.
Jihoon:For whatever reason. Then… the transaction will be evicted from the mempool. Otherwise, I think includeers will
Jihoon:Yeah, pick it up again in the next IL, just as Potter said.
donnoh | L2BEAT:Yeah, yeah, exactly. So, like, this is kind of the difference that needs to be, thought a little bit more in the context of native prolops.
Jihoon:Hmm, host.
donnoh | L2BEAT:To how to handle, like, resubmission.
donnoh | L2BEAT:But again, as I said, I'm pretty optimistic that there is a… there is a solution somewhere.
Jihoon:Do you have similar cases, today with forest transactions?
donnoh | L2BEAT:So… Like, the only case…
donnoh | L2BEAT:No, I don't think there is.
donnoh | L2BEAT:Because… So for optimism, the way… the way that in OP Stack works is there is…
donnoh | L2BEAT:Kind of always pays for forced transactions.
donnoh | L2BEAT:They always allocate some space.
donnoh | L2BEAT:Just for them.
donnoh | L2BEAT:So, I think there isn't the issue that…
donnoh | L2BEAT:There isn't enough space in the block, I think.
donnoh | L2BEAT:In Arbitrum, the way that it works is…
donnoh | L2BEAT:The sequencer decides when to include them.
donnoh | L2BEAT:And it has a… some time… window.
donnoh | L2BEAT:Which is, like, 24 hours, I think. It's pretty long.
donnoh | L2BEAT:And if it doesn't include this transaction in 24 hours, then the user can, force it themselves.
donnoh | L2BEAT:And the, like, the L2 is kind of forced to… to process this transaction. It is inserted.
donnoh | L2BEAT:I cannot be skipped. The only case that is kind of similar, is… Mmm…
donnoh | L2BEAT:No, it's not actually very similar. But basically, there is this case where you send a message, and this message fails on the L2, and you need to resubmit it. Like, it fails because maybe you specify the gas limit, but then, unexpectedly.
donnoh | L2BEAT:The L2 gas changed.
donnoh | L2BEAT:And then it fails because it goes out of gas, and you need to submit it.
donnoh | L2BEAT:And in that case, you need to actually send another transaction.
Jihoon:Got it. So, in that case, we need to… the user needs to send another transaction to force included.
donnoh | L2BEAT:Yeah, unless… unless there is a way to…
donnoh | L2BEAT:Know if a transaction was skipped or not.
donnoh | L2BEAT:Because if you know it… You could, like, keep those that are skipped because of… Gas limits?
donnoh | L2BEAT:Or… I don't know.
Jihoon:Right.
donnoh | L2BEAT:But probably, probably it's not, it's not, it's not feasible to implement this.
Jihoon:Yeah, I agree, yeah.
Jihoon:maybe the situation is not equivalent, but I'm also optimistic that we were gonna be able to find a solution for this case.
donnoh | L2BEAT:Nope.
Jihoon:Yeah, great. Yeah, does anyone have any question?
Jihoon:For native roll-ups, or fossil native roll-ups?
donnoh | L2BEAT:And by the way, sorry, the thing that I… that I forgot to mention is this is, like, super relevant for native rollups, but it could also be used by existing roll-ups as well.
donnoh | L2BEAT:So, all major EVM rollups, like Optimism, Base, you know, Arbitrum, Scroll.
donnoh | L2BEAT:Tyco, Linear, and whatnot. They try to minimize the difficult one.
donnoh | L2BEAT:So, even if you're not native, you could… Try to minimize the diff.
donnoh | L2BEAT:By implementing first transactions in this way.
donnoh | L2BEAT:Already, without being native.
Jihoon:Is it okay to understand that if we implement fossil in L1, that's gonna replace forced transactions?
donnoh | L2BEAT:I think it is possible, because again, all the EVM rollups, what they do is that they just fork what is on L1. So if they fork L1 and POSIL is there, they have this mechanism that they can potentially use for personal transactions.
donnoh | L2BEAT:I don't think any of the current follow-up teams are looking into this, to be honest.
donnoh | L2BEAT:Because, you know, they have many things to think about, and…
donnoh | L2BEAT:Yeah, either they already implemented this, and changing might not be worth it.
donnoh | L2BEAT:But for those that haven't.
donnoh | L2BEAT:or for those that maybe wish to simplify their design, it might be worth it. So, I… one example is linear. As I said, linear is kind of struggling.
donnoh | L2BEAT:I would recommend Linea to look into this.
donnoh | L2BEAT:Oh, Nope.
donnoh | L2BEAT:Like, well before native rollups.
Jihoon:So… Luca, you shared, some challenges.
Jihoon:that… L2s are having.
Jihoon:to implement forced transactions, then if we somehow succeed to have fossil in L1, then…
Jihoon:It'll be good for them, because they don't need to worry about it anymore.
Jihoon:maybe there's another reason that we… why we want to have also in L1.
donnoh | L2BEAT:Ehh… yes?
donnoh | L2BEAT:Also, like, on the other hand,
donnoh | L2BEAT:projects can already implement… like, L2s could already implement Force Hill, even without having a tunnel one, right? So…
donnoh | L2BEAT:In the sense of…
donnoh | L2BEAT:like, if their goal is just to have a fossil-like mechanism, they cannot implement it. If their goal is to minimize the deficit L1, which is what most projects want, then of course you need to wait, for L1 to have fossil.
donnoh | L2BEAT:I think that it might not be a good enough argument to say
donnoh | L2BEAT:we need fossil on L1, so that's a…
donnoh | L2BEAT:They can already do it. And this, you know, in all core devs' calls, this happened many times, that someone wanted to have something on one, just to have it on the tools as well.
donnoh | L2BEAT:And… My feeling is that this is not a strong enough argument for something to be included on one.
donnoh | L2BEAT:But…
donnoh | L2BEAT:It is something to keep in mind. Like, in practice, my opinion is this would simplify the work for Altos.
Jihoon:Yeah, I get it, yeah. I guess it's,
Jihoon:There was an argument to have delayed execution over EPBS, because it could be more beneficial to L2
Jihoon:But, yeah.
Jihoon:when we are considering some feature for L1, then we should prioritize L1 over L2, so… yeah, that's a good point. Patas, do you wanna share something?
potuz:What does it mean fossil on L2? L2 doesn't have 4 choice, so… what part of fossil, or what is fossil on L2?
donnoh | L2BEAT:Yeah, yeah, yeah, so the idea here is to…
donnoh | L2BEAT:Try to reuse the check that is done on the execution layer, where you have
donnoh | L2BEAT:a list of transactions that is checked against another list of transactions, which is the inclusion list, right? So the idea here is just to reuse this check on the execution layer.
potuz:Oh, okay, so it's just a matter of, like, using a function that is just a simple check, that is an implementation detail. It's not a mechanism.
potuz:It's not a mechanism design, it's not part of consensus, it's not… it's just simply reusing that part of code in the year.
donnoh | L2BEAT:Yeah, yeah, exactly. So, there is the need for roll-ups to have a check somewhere that
donnoh | L2BEAT:the centralized sequencer, the list of transactions that the centralized sequencer is sequencing, includes forced transactions. Forced transactions come from somewhere else, like, usually a different function in a contract.
donnoh | L2BEAT:And to implement the check, That the sequencer batches include forced transactions.
donnoh | L2BEAT:It is difficult, for roll-ups.
donnoh | L2BEAT:Without modifying
donnoh | L2BEAT:without heavily or, like, significantly modifiable one. And the idea here is, if the execution layer already has this check.
donnoh | L2BEAT:The roll-ups can…
potuz:reuse this. And by the way, you're assuming that the check is going to be the same. You're… you're, you're assuming…
potuz:one condition on rollups, that rollouts are going to be using, first of all, the engine API. So, already this drives Arbitrum out.
donnoh | L2BEAT:Yeah, yeah, yeah, of course, of course.
potuz:But, I mean, there's a bunch of conditions on Fossil itself and on the way that this will be implemented in ELS that would just drive down the number of rollouts that could use this, could reuse this code dramatically.
potuz:Because also, the conditions on being inclusible for L2 might be very different than being includeable for L1. They might depend on different things than just gas limits and whatever it is.
donnoh | L2BEAT:Yes, yeah, exactly, so… The main reason why I advocate for this L2 fossil is mainly for native roll-ups.
donnoh | L2BEAT:Because…
donnoh | L2BEAT:It is, I don't know if you joined, late to this call, but I discussed how Arbitrum implements first transactions, and Arbitrum implements first transactions with new transaction types. It has new transaction types.
donnoh | L2BEAT:And it kind of modifies derivation a little bit.
donnoh | L2BEAT:And…
donnoh | L2BEAT:For native rollups, we cannot have dedicated transaction types just for first transactions. So how can we implement first transactions?
donnoh | L2BEAT:Without new transaction types, and without doing crazy things.
donnoh | L2BEAT:The simplest thing is to…
donnoh | L2BEAT:Like, if L1 already has a mechanism for forced transactions, more or less, on the execution layer, the native rollups that the only thing that they do is a recursive call to the situation function, they would be able to reuse.
donnoh | L2BEAT:the same exact mechanism. And of course, this restricts
donnoh | L2BEAT:The design space for forced transactions a lot.
donnoh | L2BEAT:If you want to implement something else, Are this different on fossil?
donnoh | L2BEAT:What you can do is pass an empty inclusion list to the execute precompile, And then, have a…
donnoh | L2BEAT:external mechanism that does this for you. You could have, for example, a ZK verifier, that does…
donnoh | L2BEAT:I don't know, the check in a different way. But the cool thing about the inclusion list being an input to the execute precompile is that, for example, you can implement delays.
donnoh | L2BEAT:Right? So, you can pass, for example, let's imagine that this inclusion list is a queue on L1 in a smart contract.
donnoh | L2BEAT:You can have a delay of, let's say.
donnoh | L2BEAT:12 hours or 24 hours before these transactions actually are feeded… are actually feeded in the execute precompile. And this would kind of… you… you kind of… you would be able to kind of implement these delays
donnoh | L2BEAT:that chains like Arbitrum and Optimism have for reverse transactions, not to invalidate pre-confirmations.
donnoh | L2BEAT:But yes, like, I agree that this limits the design space. But native roll-ups are supposed to be very, very similar to…
donnoh | L2BEAT:So, all ones.
donnoh | L2BEAT:And I don't think, you know, from a user perspective, it makes lots of… A lot of difference.
Jihoon:Great, great. Maybe we can have one more question if anyone has… Any?
Jihoon:Otherwise, we can move on to the next topic, because we have only 20 minutes left.
Jihoon:Alright, thank you for your presentation, Luca, and thank you for all the Q&A, and if anyone
Jihoon:Pop up with another question, then just feel free to ask him in the chat.
Jihoon:Yeah, so,
Jihoon:For development updates, does anyone want to share some updates?
Jihoon:Maybe I can go first. I'm currently adding some unit tests for inclusion lates to store.
Jihoon:And then I'm gonna share a document that lays out test cases. Won't be exhaustive from day one, so please feel free to contribute.
Jihoon:I haven't started it yet, but it would be… look like this, so…
Jihoon:I'm not sure where to put this. I'm gonna ask Justin about this. It may be placed under Foster for Implementer Repo, or…
Jihoon:kinds of spec repo, if it's possible. Not sure yet, but yeah, that's what I'm working on at the moment.
Jihoon:Does any client… Have any development updates?
nflaig:I guess from last meeting we had, the update is that we can run on 6-second slots now, since we use BPS values.
nflaig:This is also the updated spec.
nflaig:And then we updated or fixed our fork choice FCU calls to also pass the EL. I think that was one other issue, that there were empty IELTS.
nflaig:And yeah, pretty much what I shared on the description. So all bugs should be fixed now.
Jihoon:Thanks for sharing! I actually haven't tried that out, but do you still see the…
Jihoon:What was the error? Beacon block timeout error.
nflaig:Yeah, I still saw that, with Geth, yeah.
Jihoon:Yeah.
nflaig:used to be random, even before FULU, before EIP7805 fork.
Jihoon:Hmm.
nflaig:So, I'm not sure. Yeah, also we run with Fulu Genesis, so maybe there's some issue related to Fusaka, I don't know.
nflaig:But I don't see on the CL side what's the issue.
Jihoon:But you don't see such error when you are working with
Jihoon:other features, right? Like, we don't have such, error in…
Jihoon:Olesky DevNet, for example, so I think.
nflaig:Oh, yeah.
Jihoon:yeah, there's something wrong with the, get prototype, I guess. So, I… I rebased it, actually, last week, but I haven't,
Jihoon:had any luxury to spend my time on it yet. Yeah, let me take a look into it after I'm done with this testing stuff, and yeah, thanks for the progress on the Lone Star side.
nflaig:Yeah, I think I… so with REF, I also didn't see the issue. There's some random inclusion list unsatisfied blocks.
nflaig:Which I'm not sure, where the issue is. There's one issue I know about in Lodesta, that we use the same cutoff for attestation, review, freeze, and proposal cutoff.
nflaig:But I don't think that matters in a local DevNet, since all IELTs should be available before the attester cutoff anyway.
Pelle:That should be fixed now, though. There was a bug in just some encoding for the ILs and how we were reading it from the engine API, but in recent tests, I haven't seen any missed blocks from, unsatisfied ILs. So, definitely check the newest commit.
nflaig:I said, do you have an image, public, from IF?
Pelle:And I do not have an image up right now. I can work on that, though.
nflaig:Alright, thanks.
Jihoon:I guess.
Jihoon:That's that for Lodestar, and… Do we have… do you have more updates on Red's side?
Pelle:I've been working with Katya to get the metrics working. It's… there's some issues with, like, how RETH does metrics that I'm looking into right now, but we have some basic metrics up, and then we're also looking at adding the ones you suggested as well.
Jihoon:Great, having that said, do you… yeah, Katya, do you wanna… Add something?
Katya:Yeah, hi everyone. So, regarding the metrics, we, we bumped into the problem that how to count, valid and invalid,
Katya:transactions, because, for example, it depends on implementation. If you bump into… if you have, like, one invalid transaction.
Katya:For example, how it was in Wrath, they just, break the validation, all the validation process, and that means
Katya:They may have one invalid transaction, and others can be considered as invalid, but in fact, they are not invalid, so I wonder how other clients
Katya:implement this? So, do we really… can we really count invalid transactions in this case? So, we are discussing
Katya:This new list of transactions, like.
Katya:valid and invalid size bytes, gas usage limit, is it possible to count on the EL side?
Katya:And also these, you know, the number of invalids. For example, for consensus layer, we just consider, the inclusion list itself.
Katya:If it's valid or invalid. But on the yield side, we operate with transactions, and it's a little bit tricky to count invalid transactions in this case. I don't know, Jihoon, how it is implemented on the gas side? Maybe, you know.
Katya:Or… or we may discuss in the Discord.
Jihoon:Yeah, so, on the sales side, transactions are just bytes, so they don't, you know, but…
Jihoon:interpret what the transaction is, that's why we just care about enclosure list on the sales side, but on the EL side, we know how to handle transactions, so we can… if we want, we can look with more granularity.
Jihoon:So the suggestion that I've made was just an example. I don't have a strong opinion on the metrics, so if you feel like this is too much, then, yeah, we can just decide to not add
Jihoon:new metrics, but on the GAT end.
Jihoon:When… so there's a code that checks if there is a leftover enough guest left.
Jihoon:to add any missing IL transaction, so…
Jihoon:We could use the code to… Logue whether the…
Jihoon:missing IL transactions, was…
Jihoon:Left out because of gas limit or whatnot.
Jihoon:Yeah, so,
Jihoon:from your perspective, what kind of metrics do we want to have on the EL side?
Jihoon:Like, even on the CL side, if you feel like we have too many metrics, then we can, you know, just trim it out and leave it with only necessary ones.
Katya:Yeah, I don't mind, any additional transactions, just, I want to be sure that other clients… because I think for Pele, he had to change the code to count invalid transactions, so, maybe he can add as well, like.
Katya:More on this.
Jihoon:Yeah, spell it?
Pelle:Yeah, sorry, I think there was a little bit of a misunderstanding. When we were first talking, I was thinking invalid as in transactions that make the block invalid, not, like.
Pelle:invalid traction, transactions because of gas and whatnot, so that should all be fixed now, so it's not really a worry, Katya.
Pelle:But we should be… sorry about that, yeah.
Katya:Yeah, yeah, and I wonder if other clients can count the number of invalid transactions, if it's not an issue, just to be sure.
Katya:We can also discuss in the Discord.
Katya:Shut up.
Jihoon:Yeah, sounds great. In general, do you think… we have…
Jihoon:Too many metrics compared to other topics.
Katya:No, I don't think so. It looks…
Katya:It looks quite good. I would think… I started to build a dashboard, like CL and DL parts separately, but now I think, you know, that it's better to combine, for example, the metrics regarding payload, it's better to combine them on one panel, maybe.
Katya:And to easily compare CL and EL parts, for the metrics which correlate with each other.
Jihoon:Hmm.
Jihoon:But… Do you think it's better to somehow separate the CL and EL In that one panel.
Jihoon:It's just a, you know, design choice, I guess.
Katya:Yeah, that's the design choice, so, I will try to mix them,
Katya:As the same way as I shared the screenshot, right? So, you can see both EL and CL for this email metrics. Let's say how many transactions sent and how many transactions received.
Katya:So, for these metrics, maybe it makes sense to put them together, but we can still discuss whenever it will be finished. On the rev side, I will share the whole dashboard, the whole picture, and we can discuss as well.
Jihoon:Yeah, that was great.
Katya:If it's not an issue, for example, for EL clients to see both, CL and DL metrics.
Jihoon:Hmm.
Jihoon:Yeah, we can, continue discussion regarding it.
Jihoon:Do we have any other updates?
Katya:I have a quick question about,
Katya:engine new payload, V5. So, currently, V5 is used for block-level access lists, and it will be the same V5 for… for fossil, or it depends if it will be SFI, or…
Katya:I just… I don't know how versions.
Jihoon:Yeah, so, I think it depends on whether we…
Jihoon:what's it? Whether we SAFI fossil or not, so if we SAFI fossil, then we…
Jihoon:gonna… I think we're gonna merge those two changes into one V5.
Jihoon:And, yeah, so if we… the bell's already there, so I think it has priority, so if we decide to not include the fossil in Glamsterdam, and somehow, let's say, we want to add it in edge fork, then we want to use V6 or something.
Katya:Got it, thank you.
Jihoon:Yep, thanks.
Jihoon:All right, do we have any other updates or questions?
Jihoon:Otherwise, we can go ahead and wrap up this call, and…
Jihoon:Have another car after 2 weeks?
Jihoon:Alright then.
Jihoon:Thanks for joining, and have a great rest of your day, and see you guys in two weeks.
Katya:Thank you, bye.
nflaig:Thanks, yep.
Jihoon:Bye-bye.
Pooja Ranjan:Thank you.
Chat Logs
00:04:27
Jihoon:https://native-rollups.l2beat.com/
00:18:59
Peter:You could fall back to permissionless sequencing if the centralized sequencer does not relay forced transactions. (Deterrent with permissionless fallback instead of "based windows”.)
00:29:24
potuz:includers will reinclude it in the next IL
00:35:05
potuz:what?
00:35:22
potuz:we have weakly calls about all the subtleties of FOCIL
00:36:59
Jihoon:Replying to "we have weakly calls..."
Do you want to share more about it?
00:44:01
potuz:Replying to "we have weakly calls..."
it's mostly about censorship assumptions on L1, FOCIL doesn't remove the main problems
00:44:23
Jihoon:https://github.com/ethereum/execution-spec-tests/blob/main/tests/amsterdam/eip7928_block_level_access_lists/test_cases.md
00:49:33
Jihoon:Replying to "we have weakly calls..."
Interesting, could you elaborate more?
00:49:35
Katya:https://github.com/ethereum/execution-metrics/pull/4#discussion_r2406702189
00:50:48
Katya:Example - execution_inclusion_list_transactions_invalid_total
00:51:44
potuz:Replying to "we have weakly calls..."
yes: one assumption that rollups *do not make* on L1 is that an attacker holds < 50% of the stake. And it makes sense not to make this assumption because the rollup bridge may contain more than that value. FOCIL would be fantastic to guarantee censor resistance in less than a challenge period without this assumption, but unfortunately it needs it
Summary
11 highlights
· 2 action itemsExperimental
Summary
11 highlights · 2 action itemsExperimentalnative rollups and focil
- Luca presents native rollups: EVM rollups using execute precompile for bug-free, auto-upgrading L2s00:04:38
- Forced transactions difficult for rollups; most require heavy EL modifications or new transaction types00:14:10
- FOCIL's inclusion list mechanism can implement forced transactions for native rollups without modifications00:21:17
- Existing rollups could adopt FOCIL-based forced transactions to minimize L1 diff00:33:54