FOCIL: Past, Present and Future

Transcript

Hello everyone, it's great to be here. Thanks for having me. I'm Jihun. I do research engineering at the Ethereum Foundation. Fossil is the consensus layer headliner for Eigota, which is the upgrade after Kolibri Amsterdam. In this talk, I'm going to walk you through the past, present, and future of Fossil. How we got here, how it works, how it can evolve and work with other features such as frame transaction and blob streaming. The intuition behind inclusion list was simple. Let's make a list of transactions and force builders to include them.

The idea was simple, but it took more than 2 years to reach the design we have today. This is not an exhaustive list, but let me briefly introduce the design space and the key decisions we've made. The first question is, who builds inclusion lists? >> [snorts] >> Should it be a proposer? Should it be a committee? The main consideration here was how easy it is to compromise. If it relies on a single actor, it's much easier to bribe or collude with the next slot proposer.

Then there's conditionality. Should inclusion lists be conditional or unconditional? Making inclusion list um unconditional uh makes them valuable. They can be used for other purposes such as pre-confirmations or as a vehicle for MEV. It also effectively increases the block gas limit as side effect. However, with condition conditional inclusion list, builders can stuff their blocks to ignore ILs.

But the cost of that censorship increases exponentially thanks to EIP-1559. So Fossil went with conditional. So we have a committee and the lists are conditional. But where do they go? Putting them in a block seems straightforward, but there's a problem. Producing an inclusion list is free, so a malicious includer can exploit this to get free data availability. They can just stuff some random data they want to make on chain.

And that's why Fossil keeps inclusion list out of the block and propagates them over the peer-to-peer network. We did some research on incentive mechanisms for includers. Uh there are some technicalities, but the main idea is routing a portion of transaction fee to includers. But it does open the door to a lot of complexity, which we don't believe it just is justified. So we decided to start with altruism, and the mechanism works as intended as long as one committee member acts honestly.

Here's a QR code to the research articles. I'm not sure if anyone is going to read them all, but you can just throw all of them to your little agent and ask for a summary. So after years of research, we arrived at Fossil. But before jumping into that, let's do a quick recap on EPBS. EPBS separates the beacon block from the payload. You receive the beacon block first, then the payload, and this continues. If a payload is missing or late, the chain keeps progressing without it. So this is EPBS in 15 seconds. I know this is just the tip of the iceberg, but

actually this is all you need. Now, let's take a look at how Fossil works on top of EPBS. Inclusion committee produces inclusion lists. Uh each committee member pulls transactions from their mempool based on their strategy. It could be ordered by priority fee or time spent in the mempool or a combination of them. We expect some sort of client diversity here. It doesn't include blob transactions, unfortunately, because you don't know if the blob data is available, so you can't enforce it.

For instance, if there's enough gas left and a blob transaction in an IL is valid, then builders have no choice but to include that blob transaction. But a malicious blob sender could withhold the blob data, which will reorg the block as a result. But that doesn't mean that Fossil can't be extended to support blob transactions. Uh let me introduce that ongoing research uh later in this talk. Builders listen to the ILs and make sure their payloads include all the transactions from them.

They can order transactions however they want, and during network congestion, uh if their block is full, they can favor their preferred transactions over IL transactions. But they should include IL transactions as long as they can. >> [sighs and gasps] >> Attesters also listen to ILs and check if the payload includes all IL transactions. If it does, that payload uh they vote for the block, but if it omits any IL transaction that could have been appended at the end of a payload, attester expects that payload to be reorged.

I wanted to keep this part short because I assume many of you are already familiar with how Fossil works, but if you haven't come across Fossil before or just want to know more, uh feel free to ask questions later or just find me after this talk. Now let's talk about the future of Fossil. Let's start with frame transaction. A frame transaction is a a new transaction type that decomposes a transaction into abstract units called frames, and it also allows each frame to be more generic. So this structure gives us expressiveness that legacy transactions

don't have. In a transaction, you can find different set of computation. For example, verification where you check nonce, balance, and signature. Execution where you perform the operations you want. If you're using account abstraction like ERC-4337, you might have operations at the end such as gas refunds to the paymaster. You can see each group of operations on the left maps to a corresponding frame on the right. Uh this is abstracted and simplified code for the sake of explanation, so the actual code will look a little different, but I hope this gives you the intuition.

Let's walk through a few examples. Um imagine you want to swap tokens. Today, you need to make two transactions. One for approval and one for the swap. But with frame transaction, you can represent these as separate frames. You verify first, then approve in the next frame, and swap in the last frame in one transaction. Let's look at another case. Say you want to use a sponsor transaction. Uh first, you need a paymaster who has staked ETH in the entry point contract. The paymaster has to deposit enough funds to sponsor transactions, and that's

actually the first transaction. And a user submits a user op to a bundler. The bundler checks if the user op is valid and wraps it into a transaction. Similarly, these stages can be expressed as frames. Each frame can verify that the paymaster approved, paid the fee, and refund the unused gas to the paymaster. Again, in one transaction, but without going through off-the-protocol actors.

This is good, but it comes at a cost. Frame transactions turn validation into code execution. What I mean by that is unlike legacy transactions, frame transactions have to execute verify frames for validation. It is powerful because it gives us some sort of programmable validation, but this calls for some mempool rules to protect nodes from resource-intensive validation such as verify gas limit, accepting only one pending frame transaction for per sender, allowing only context-independent opcodes, and so on and so forth. But I do want to point out that this is not new. Uh ERC-4337

has its own validation rules, >> [snorts] >> and it inspired frame transaction rules. However, ERC-4337 rules are a bit complex so there's ongoing research on finding rules that are less complex, but suitable for frame transaction. For frame transactions accepted into the mempool, Fossil would add extra constraints on which ones can go into ILs. This is to make sure the work for builders and attesters are bounded and manageable. It does narrow things down, but we're aiming to find parameters that

can cover most of the use cases. So to summarize, frame transaction empowers the users to interact with the protocol directly without going through intermediaries. So you can use frame transaction for native account abstraction such as gas sponsorship, uh transaction patching, uh pass uh pass keys for your wallet, or session keys, and potentially even privacy protocol transactions in the future. And once frame transaction posts them into the mempool, uh Fossil takes it from there and guarantees timely inclusion.

So, that was the synergy between frame transaction and Fossil. Now, let me introduce an idea that enables blob Fossil. What I want to talk about is blob streaming. Uh the intuition behind blob streaming is uh let's sell a portion of blob space and propagate blob data ahead of time. This spreads and smooths out blob bandwidth, which eventually allows us to increase blob throughput. Okay, that's good, but so how is it related to Fossil? Um let's take a look at how it works.

First off, users have to buy blob tickets to earn the right to propagate blob data. As a side note, if you don't want to buy blob tickets, or if you need to include blobs uh in current slot, you can send blobs to builders directly. This is equal to private blobs today, and we need this feature for native rollups and synchronous composability. We also need this for ZK-EVM EVM, actually. Um the idea of a ZK-EVM is to replace transaction execution with proof verification, which means we don't have to have the full payload data cuz we're not going to execute it anyway, unless

you are builders or archive nodes or RPC providers. Then, what you want is you want to guarantee that the payload is available out there in the network, and then you have an access to it if you want to. To that end, we put block in blobs and treat it the same as other blobs. The difference here is that these payload blobs have to be propagated in that slot. That's why it cannot go through blob ticket. Um coming back to where we were, ticket holders can broadcast blob data using the same sampling infrastructure that we have today.

Um attesters receive and store the columns they need, and this happens on the CL, not the EL. So, when the corresponding blob transactions are included in a block, we benefit a lot from network perspective. So, committee members observe this and vote on availability of the ticketed blob data. We take the blobs that the majority of committee observed and considered available, and record their blob version hashes in a smart contract sorry, system contract.

Going back to earlier in this talk, Fossil doesn't support blob transaction because their availability is unknown at the time of inclusion list construction. But with this information, uh IL committee can now include any blob transactions that correspond to the version hashes stored in the system contract. Uh this is still in research phase, but this idea has been studied for a couple of years. Uh this will bring us more efficient blob propagation and blob Fossil, so please keep an eye on this.

So, that's Fossil. Um There's some technical issue. Oh, yeah, okay. So, um here are QR codes to the threads that I wrote, um one on Fossil and frame transaction, one on Fossil and blob streaming. Uh feel free to check them out if you're interested. That's all I have for today. Thank you very much. I know we still have some time left, so I'm happy to take any questions. >> [applause] >> Uh hi. Do you think that having the

inclusion committee >> [cough] >> communicate the uh inclusion list in some kind of like directed acyclic graph could actually enforce fair ordering? Um could you think that would be possible? Um would that be a possible improvement instead of like a linear kind of inclusion list? Um could you elaborate on uh the graph part? Yeah, so if you can get the inclusion committee to kind of reach like a weak kind of consensus on like the uh order of transactions in like you'd kind of that would be a directed acyclic graph that they're communicating to kind of actually order transactions in the inclusion list by like highest fee, you could um I think you could like enforce fair ordering,

and that would like eliminate a lot of the kind of toxic MEV um kind of stuff. I was just wondering if you think that's kind of Yeah, yeah, that's a that's an interesting idea. Um but I'm afraid that would make inclusion list valuable. So, um like fairness is uh it could be subjective. So, it could be used for good purpose like solving toxic MEV, but it could be anyone could be an includer. If you're an attester, uh you could be an includer. We take 16 um validators from beacon committee in each slot. So, there's a chance that you be you can become an includer at each slot. Then, anyone can impose some ordering rule that is beneficial for

them, which is actually like toxic MEV. So, the idea behind um Fossil is the you can design inclusion list in many ways, but Fossil is designed the way that inclusion list is uh um not valuable other than um utility purpose. So, you can use it for um specifying a set of transactions, but that's it. All you can do. So, you can't like unconditionally uh force uh inclusion. Uh you cannot enforce any like ordering, um and so on and so forth. And that prevents inclusion list to become a uh for example, a vehicle for other um

purposes, which is not uh the same not the main goal of uh inclusion list. one, and then we if we have time, I'll sneak in a second. Um This is I think the first time I heard that builders should include um things in the IL, not must include. So, could a builder that is uh say in the US say, "I'm going to exclude anything on the SDN list because I'm nervous about that."

Um so, it's nuance. The reason that I said should is there's a way that you can do censorship. Of course, it is costly, but you can. Like, you can stuff a block with like bunch of random transactions. So, if your block is full, then even if you have a you you you omitted some inclusion list transaction, it is fine. You can when network is congested, you can choose whichever transaction you want to include. Or if there could be an IL transaction which is not valid. Uh their nonce could be invalidated like the sender cannot afford the uh transaction. So, in this case, so you are you will be excused from omitting uh

inclusion list transaction. That's what I meant by should because like you you you you you don't have to include all of them because it could be invalid if there could be no space to include them. So, yeah, that's what I meant. Got it. Um if we do 1 minute, okay. I heard mempool, and we're also talking about let's have um nodes that validate no longer run an execution layer client at all. So, if I want to be part of an inclusion list committee, then I would still have to run an EL, I assume, so I even see the mempool.

That's true. So, um um it is after we have ZK-EVM when you just want to verify proof instead of execution transactions, uh then you don't have you don't have to run your EL, which gives you the mempool, which is necessary for includer. And in this case, what we are discussing at the moment is a partial statelessness validator. But how that will be exactly working out is still TBD, but uh yeah, that's the main idea because um running mempool itself is uh is is not cheap, you know? But, you know, we

are we want to keep scaling because we know that uh current state of score is not enough, but it comes at a cost. Like, it stays grow it stays growing, and it's hard to keep up with mempool because we want to have various types of transactions like uh frame transaction, and post-quantum cryptography is coming, and PQ signature size is big. So, everything considered, um there will be big change some changes to the mempool, I think, but uh what is the exact impact on, let's say, one is includer in the future is something we need to figure out.

Thank you.