Inclusion lists have been a popular topic over the years, with various versions emerging, such as EIP-7547 and FOCIL. All these inclusion lists are constrained by a common trade-off: the Ethereum slot time. This talk explores the details of this trade-off and examines whether there is a "best" solution given these constraints.

Stage 4

I'm passionate about open-source and have been actively involved in Ethereum protocol development since late 2018. I started Prysm, a consensus layer implementation in Go, with a few others. I'm an author of several EIPs for inclusion and ePBS. I love Ethereum, and I can't wait to work on it for a thousand more years!

Terence

Inclusion List Inevitable Tradeoffs

 So this one is more again on inclusion this and it's more on the engineering side that as someone that has been focusing on inclusion this over the last year and I also started looking at fossil more and more and this is where my perspective in terms of engineering challenge with regards to inclusion is. So today, where we are, right? So today we have Ethereum slot and each slot is 12 seconds. And what are the constraints within the slot? So as a proposer, I want to propose a block. And I would hate to have my block gets reorg and that's not nice So I want to propose My block on the strongest head that's possible right and after I propose a block everyone else on the network that's running a node will verify the block and compute what is the head and As a tester their job is to attest to the head of the block So this is where the for choice follows if you use lmdGhost, and then as an aggregator, as optional, you aggregate attestations, and then the proposer essentially follows the votes for the next slot, and then it builds on top of the head. And then because of timing game, you can see there is a phenomenon that today, the attester caught up is at four seconds. So basically everything is pushed towards a four second mark. And that's kind of the equilibrium right now that everything happens within three to four seconds. And then between four to 12 seconds of nothing typically happens unless you are the next law proposer, you are listening to transactions, and you are building blood. So where does inclusion list fit in into this picture? So here I'm speaking in terms of Fossil. So Fossil is a EIP 7805 I believe, but go search it if you don't know what Fossil is. So Fossil is probably the best inclusion list design that I have seen so far that is mostly bully-proof, in my opinion. And then it has the same slot property. And then, so what Fossil does essentially is that it essentially allows secondary runs of proposals that are allowed to send their local block and then such that it can train the next slot proposer, essentially. So where does that leave us in the picture, right? So because of that, we have to essentially add this proposer in the middle of the 12 slots. That means that as a proposer for the inclusion disk, I have to essentially verify the block beforehand, such that I want to essentially propose the block beforehand such that I want to essentially propose the best inclusion disk effort, right? And then as a constraint, the next slot builder or the proposer, I have to essentially pack the inclusion disk into the block. And then if I miss inclusion disk, then I may miss my block. And also as a tester, I want to make sure that the block satisfies the inclusion this. So there are three more constraints as a builder, as a proposer, as a tester, which I cover here. So where are some parameters that we can play in terms of trade-off? So for example, how big is the size of an inclusion disk? If the inclusion disk size is so small that it may not be useful, but the inclusion disk size is too big, then you open up network for DOS concerns. What is the size of the inclusion disk committee? Because we want committee size to be reasonable, but then if the size is too big again you open up network does concern and then how much overlapping are there within the inclusion this and then what is the satisfactory rule right so as a proposal for the next slot as a tester i'm verifying the block like what like basically like how much of the inclusion this the proposal has to satisfy for the block block to be valid. So what are the concerns? So first concern, I think, is the increase of bandwidth and compute for node. Like, depends on how big your inclusion disk size is. And then, again, the second concern is that proposer, like, how much time do I have to build the block? And then, as a tester, how much time do I have to verify the block? So here are some open questions for us to study if we're interested in this inclusion disk space. How compatible it is with the future roadmap, such as peer-dos, such as EPPS? How does inclusion disk work with account abstraction? And then how can we add block transactions into the inclusion disk such that it doesn't open up those concerns? And then how can we better utilize local mempool for inclusion disk? Maybe we can just essentially send the transaction hash instead of sending the full transactions. Finally, will there be other protocol market for inclusion disk? And it's something that we need to study more. So yeah, if you're interested to contribute, hit up julian and hit up me and then yeah definitely i'm definitely very excited about this inclusion this design space thank you thank you so now we have time for a few Q&A. Please raise your hand if you have any questions. OK. No questions? OK, it seems that there's a question here. Yeah, super interesting. I had a question. So I don't know if you can answer this but um in any capacity are you thinking about doing fossil or inclusion lists for l2s like arbitrum or yeah and how is that different from wasn't the eip and what could be on mainnet right so there too today is most of the literature or all of the literature today they have just one sequencer right so the sequencer definitely have a lot of power say today if you want to force your transactions in there like if sequencer ignores you there's nothing you can do but then there's a lot of people say well you can force transaction through layer 1 but that's also not nice because you have to wait like 24 hours right but then like I think like decentralized sequencer kind of self-set if you assume an honest majority so I would say the space in terms of censorship resistance on there too it's it's definitely very different on there one because on there too you can essentially having like 1 million validators you could just have like 10 sequencers and then trust like honest majority and then as long as you assume some of them are honest, and they were, like basically, basically they have to include your transactions. Any other question? Okay, well, thank you very much for your talk. Please give some applause to Terence.

https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673473f09dbb7a90e128f649.vtt