[trustless://eil] Soispoke - FOCIL: Restoring Censorship Resistance on Ethereum

Transcript

Um and next we are going to have a talk on fossil from a researcher from the robust incentives group at theium foundation. So I spoke. Big round of applause. [music] >> What the answers? Yeah. [music] Straight straight into every note, every screams. We need this man. [music] Not a question.

Yes. Yeah. Yeah, we watch fade [music] away and stall. I catched every speck [music] till it hit the wall. Won't repeat that fate. [music] Won't pretend it's fine. Pretend it's fine. Fil's what we need. And we need it on [music] time. And we need it on time. when they dodge the second guess.

>> Hi everyone. >> What a theoretic entrance. Shout out to Cena that actually came up with the song. I I yeah I thought it was really cool. Um and I am not BK but uh I will try to give a talk about Fossil today. Let's see how that goes. I mean, if it's going to be a while, we

can replay the song, I guess. Just like what? Yeah. I mean, you can talk too. Um, I mean I can also just start talking

and >> what? >> Yeah, but I can do the first without the slides, I guess. Okay. All right. Let me try this. I think the the slides are not needed for the first part hopefully. But okay. Yeah. Um, uh, who here heard about Fossil? Just to get an idea. Okay. Nice. All right. Cool. So, yeah, I'm going to be brief then, but I I did want to get, uh, you guys up to speed and maybe start with like a bit of context on like the history of censorship resistance on on Ethereum. So at first um you know back in the days we just had validators um and the validators were it was kind

of nice because they could just like do all the things we asked them to do which is you know proposing blocks um building their own blocks attesting to blocks and all of like the validators could could basically do anything and that was very nice um because that meant like the censorship resistance properties of the network will actually be dependent on the number of like independent nodes you had on the network. Um which is I don't know very core to like trustlessness and software resistance permissionlessness and everything. Um so that that was good. Uh but then something happened uh and that thing is MEV. Um and so it stands for maximal extractable value and

basically MEV is um the value you extract by ordering transactions in a block or like inserting some or removing some and you like can pack your block in a way that allows you to extract like a lot of value from it. And it turns out so I mean if you guys are familiar like sandwiches front running back running all of this is basically me. Um and so the sort of like annoying thing about this is that it's actually you you need to be quite sophisticated to do this well and to build optimal blocks you actually yeah need to like have like I don't know beefy machines and and run a ton ton of like combinations to find

like the best ones. And so we ended up having a bit of a problem because um you have now like a sort of nice um separation between um validators that could be sophisticated and like really good at this game and validators that wouldn't be able to be good at this game. So you have like a difference in the rewards you get from me between validators. And that's obviously bad because it means you know if you keep doing that uh you will have like a big centralization force and you obviously don't want this for your valid validator set. So what to do? Um the solution flashbots people and then EF researchers of course like came up with was uh PBS

so proposer builder separation. And so the idea was was to say okay like this role of like um building blocks and ordering transactions can be completely separated from validators and we're going to get this new kind of nodes and those nodes are like called builders and they're going to be really good at doing this. And then how are validators going to get the blocks from them? Well, there's going to be an auction for each block and so builders compete with each other um and try to outbid each other and then all validators have to do really is just like um pick the block with the highest value uh and um and propose it to the rest of the network.

But this is proposal builder separation. This is what we have on Ethereum today. Meth boost if you guys have heard of it. And I think it's nice like I I I still think like the idea is actually valid and nice. Um wow. Um but um the problem with this um yeah no what what is nice about it is like it actually kept the the validator set decentralized which is obviously something we want. What is not so nice is that the centralization forces we talked about were actually really really strong. Um yeah and and basically like stronger than we thought they would be I think. Um so now we have

like if I'm if I'm being very nice three but like really two huge builders uh building like more than 90% of the blocks on Ethereum. Um and so why is that bad? Like you like you know they're still competing with each other like they build like valuable optimal blocks. validators still get good MV rewards and are unsophisticated. The obvious problem is obvious is censorship resistance. Um because if you have like these two massive builders building like 90% of all Ethereum blocks, if they just like decide they don't want to include your transaction for any reason, well, you don't have to, right? And then what happens is like if your transaction as a user for example

is censored by these two big builders, you have to wait like 10 12 15 blocks until you luckily um end up having a local builder that is not relying reliant on these two big builders uh to like include your transaction. So you degrade your UX by a ton and it's not that hard, right? like you have to bribe basically like two two parties that are like not huge companies either. It's like it's pretty easy to bribe them I think. Um so yeah, I mean that's obviously the big problem. Um and I think slides are going to be a bit needed here. Um but I'll keep going I guess. Um

yeah. Yeah. We'll do a Q&A. Okay. Sure. >> Yeah. Hello. >> Anyone has any questions so far? >> Yeah. So, wait. First up, everyone knows how hard it is to pretend without sli present without slides, and this has been amazing. Um, but while we have some technology hiccups, does anyone ask any questions about what's been talked about so far? >> Who's going to be the guinea pig? >> Let's walk. >> You got anyone?

Um hi. >> Hi. >> Hi. So, uh, what's Fossil? >> What's Fossil? >> Yeah, that was my next slide. >> Um, Fossil, yeah, stands for fork choice and forced inclusion list. The acronym is a bit stretched but um and it is like the solution proposed to sort of like solve the problem of having these two big builders and a bunch of validators. Um what it does really is like it lets validators that are still decentralized impose constraints on on these big builders. So how it works is like you have validators, you choose 16 of them every set. Um, and what they're going to do is like each of them is just going to

build what we call inclusion lists. Inclusion lists are just like lists of transactions they are seeing in the public meool. And then they're going to send these lists over the network. And the builder will have to see these lists, right? And basically what the builder has to do is like you have to take all these lists, take the union of all transactions across these lists and the builder has to include these transactions in its block. Yes. if you want the block to be canonical. Um, so at see the same inclusion list basically and they're going to do the same union of all transactions and when the block like comes by the next builder or proposer they're going to like see like okay did it actually include all the transactions that I saw if not I'm just

not going to vote for its block and it's never going to make it on chain. So it's really a way to allow the decentralized set to regain power over like block construction and allow like allow multiple proposers to give additional input um that the builders have to just like yeah comply with. I guess a follow-up question would be like um as a normal user, how does it differentiate like does it look at transaction history and it's kind of like okay you're clearly like doing me and stuff but this is a user user op so now we're going to make sure that it's in that inclusion list like what's the criteria for inclusion >> so yeah that's a good question I so basically what the validators have to do

is like they look at the public mele and they see any transactions and they ordering they order it according to some naive rules like you can take like priority fees or like time spent in the me pool and like all these very simple rules and all of them they include it and if they are honest like that is like you're going to get like perfect censorship resistance right because like they're going to include every transactions they see in the me pool and the builders will have to like include it in its block. Um, what's really cool about for is like even if like 15 out of 16 people also want to censor your transaction for some reason, you only need you only need one to be honest for the whole mechanism to work. So you have

like a honest minority assumption which is really cool because that transaction you know will be part of the union of all transactions across II is um so it that's why it like boosts censorship resistance like crazy and it gives like extremely good inclusion guarantees basically. Um oh I think the slides work >> clicker right there. >> Oh great. Thank you. >> Yes. >> Uh so those were my beautiful slides. >> Woo. Um yeah, this is the mechanism. Okay, let me just like recap. You have like the includers here. They build lists. Um the builder uh sees them and has to include these transactions that

are in the list in its block. Otherwise, the attesttors that are here just won't vote for the block. So yeah, pretty simple. Um yeah and then that come I don't know it it feels weird sometimes to me for me to like just like say why censorship resistance matter because I I feel like trustlessness and c sensorship resistance and permissionlessness are like sort of like the core reason we're building blockchains in the first place. Uh but you know I think censorship resistance particularly is about like guaranteeing equal access to block space for everyone. Um it's about like only relying on protocol rules to decide

who's going to make it on chain or not. Um and by only I mean like really only like you don't rely on any external information to make your choice. like you ensure that everyone that submits the transactions to be accepted by the protocol like actually gets it. Um no matter where they are, who they are, what they want to do, it just gets in. Um and it has some Okay, I I took some examples because sometimes it can feel a bit abstract. Um, but it's also really important from the protocols p perspective and sometimes like people don't get get that uh and because like fossil feels like a defensive sort of vibe like we protect the protocol or whatever but it actually allows scaling

like without fossil like it's it's going to be like very complicated to scale without completely degrading the censorship resistance of the protocol. And the reason is very simple. Um basically if you scale um so you increase the gas limits or or you go to ZKVMs and you have to also generate proofs for your block. Um what you do is like you increase the load on the builders, right? Like you need to build bigger blocks or you might also like need to actually prove um that these blocks were were valid. Um, if you do this like the local like the small local builders I talked about that are now

like basically completely upholding the censorship resistance properties of the network by themselves. I mean we're going to see less and less of them just because like not everyone has access to a beefy machine, right? Like not everyone can afford not to connect to the dominant builders and be completely altruistic and like miss out on like the me rewards. So the more we scale the more we the less we will have like local builders probably and the more reliant we will be on on the two dominant builders and if if we don't have fossil that means like we will slowly or quickly see the censorship resistance properties of the network that are not great today but like degrade even further basically. So we really need in so we can actually aggressively scale while like maintaining some sensorship

resistance. Um it's such a cool foundation now that's a bit technical but like it does I think we are moving to a world in which um you know validators don't do everything anymore that's clear like now you have builders with fossil you have includers um we also want to like separate the role of being an atttor to the proposer so you can like sort of like preserve the consensus related duty and sort of like shield them from me externalities and fossil is like a first step in doing that and we need fossil before we can build the the rest of like this sort of like specialization of nodes. Um, so yeah, it's also like important for the future.

Uh, what about institutions? Yeah, I don't know if you saw Danny Ryan's talk and also Vitalik's talk yesterday, but they gave like cool examples about like why institutions scare. Um, what they hate is like counterparty risks. So they hate like to be potentially having someone screwing them over, right? And if you don't have fossil, it's quite easy to do, right? like you are a big large institution. You're like, "Okay, I will bribe these literally two companies so they don't include the transactions of my biggest competitor." What you do is like you slow down the the UX of your competitor by 10x, right? It's it's pretty pretty effective and I don't think it's like that costly to do. So, I think if you want to safely on board

institutions, we also need something that guarantees their trans their transactions will be included. Um yeah, you can do all sort of like weird stuff, right? Like you can manipulate the market by just imagine you censor all transactions that are like sell orders for a given token. It's obviously bad. Um and institutions are like probably don't want that. Um yeah, for L2s it's cool like um so shout shout out to Luca Dono um who's looked at into this and um you have like very cool cool specific niches why fossil is important. There was a post by Vitalik a week or a few weeks ago on like shortening the

withdrawal windows and I think um fossil allows you to do that way more because um basically reduces the cost of um submitting your first challenge transaction to the L1 by a lot and that alone allows you to basically reduce the exit withdrawal window which is better for UX for interrupt for a lot of things. Um it you can L2s can also build on the infrastructure that fossil provides to build more robust forced inclusion mechanisms which is known to be quite a bit of a pain for L2s right now. So I don't know it's also another thing that's cool it will be also very

important if we get to native rollups. Um and then yeah I guess for users I mean I I I said quite a lot already but basically for me for is also like the great sort of like equalizer. It means like if you're like a single individual user behind your computer and you want to I don't know buy if with stable coins or whatever. You have the exact same inclusion guarantees as like a huge organization trying to rebalance its portfolio or whatever. You also have some quirky niche cases that are like important. I think imagine you use a and there's someone that censors your transaction to um top up your collateral uh so they can liquidate you later.

That's also quite bad. Um and that's also why you need for for users. Um yeah, I mean I think the list can go on and on and on because just like inclusion guarantees are just like important. Um okay. Yeah. One thing I want to finish with and it's very crucial I think right now because yeah generally I feel like everyone likes for I don't want to like be super like overly positive but like people do like it. Uh the question right now is more like when do people want it in the chain. Um and there there are like quite stark differences and one one thing it gets a lot is like oh but there's not

much censorship on the network right now. Do do you think it should be a priority or whatever? Yeah. I mean I I I feel like if you think about it for a minute um you're like sure I agree like there is not much censorship right now on the network but like if there was a massive censorship event on Ethereum and and that's a risk like it's always a risk it would be terrible right now because like it would basically affect the sort of like narrative around Ethereum being this like credibly neutral layer everyone can transact on like I don't know it will be pretty bad I I think like if something happens and we don't have like the protection needed to make it okay um then I I I do think there is a sort of like a big risk for

Ethereum and then you know you have to wait for the next hardcore to ship the solution to a problem that already is live. I don't know it just doesn't feel like a sort of like healthy situation we want to be in. Um and yeah then you have you know a lot of support for from core devs. you have um an EIP that's more ready than any EIP other EIP I think like it's work it's been worked on like by seven clients like five CL ones and two two EL ones um and they're interrupting with each other like it's yeah it's it's pretty good uh in terms of progress and like having client adoption um for the first time for glam start we also like explicitly asked the

community what they wanted to see in the fork and everything and there was a lot of support for it So now the arguments for not including not including fossil in the next fork are really basically about fork cadence and fork discipline. Um which is basically no we need to ship a hard fork for Ethereum every six months. It's very important because it gives some asurances that Ethereum can ship and stuff like this. I think it's fine. Uh I I agree it matters but for me like I would be fine like if the the fork gets delayed by like a couple of months so we can include for as fast as possible. I do think there's another argument that's for complexity like you

don't want to have too many features interacting with each other in the fork and I get that but I feel like if that's the only reason why we don't want to include fossil in the next fork then we need to act [clears throat] like at least SFI like schedule it for inclusion in the fork that comes after like we need to have like guarantees that we will ship this at some point because I don't think it's going to get easier to ship that um and so yeah that's why I'm I think we should do as soon as possible basically. Uh and if you want you know to support this uh or fossil or whatever like be loud like come on forums come acd like say why you think it's important and I think um yeah the sort of like continued support for

the community is very important for EIPs and we do listen to what everyone is saying so so yeah um please keep supporting it. Thank you.