All Core Devs - Consensus #158

Transcript

Josh Davis: Yeah, Brittany, when you are.

Alex Stokes: Alright! Let's go.

Josh Davis: Your life.

Alex Stokes: Okay, thank you. Everyone. Welcome to Acdc, number 1, 5, 8. The agenda is here. It's issue 1548. And the Pm Repo. so yeah, today we'll cover some Fussaka things and also open the Glamsterdam conversation. And yeah, let's go ahead and get into it. So 1st up with Posaka. We have Posaka devnet 0 Perry, would you be able to give an overview last time? I looked it looked a little little hectic.

Parithosh Jayanthi: Yeah, I think Barnabas might have the latest on that one.

Alex Stokes: Okay, great part of us. Would you mind updating us.

Barnabas Busa: So we basically set up 0 with being activated in epoch 256, and then every single Bpo will be 256 epochs later. So that will give us one day to observe if the Bpo. Is working as expected. If any clients are causing an issue, and we decided to go up, down and and so far, every everything seems okay. We had a few clients that that are still missing blocks and some clients that have issues appearing up. But we are actively looking into these issues. But the concept of Bpo seems to be working. Okay, okay.

Alex Stokes: Okay, that's good news. Cool anything else on Devnet 0.

Barnabas Busa: We had a bit of misconception regarding removing the block count in flow.

Alex Stokes: So.

Barnabas Busa: There's a a clarification that had to be done, and we had to add an additional block schedule for the full fork, basically on the side. So this, this was just basically saying that, hey in full, we still gonna be using 6 and 9. But yeah, as as I mentioned, this only touched the sales.

Alex Stokes: Alright makes sense, and that's already live on Demo 0.

Barnabas Busa: Yeah, this this was done before the 1st before even full went live.

Alex Stokes: Gotcha. Okay? Cool. Okay. Then, next up we have on our schedule today to get to a final Sfi set for Fusaka and I wanted to go ahead and cover this now, because it might inform Devnet one scope. So yeah, essentially, the only question we have is Eip 7, 9, 1, 7. This was the one that gives us a proposal. Look ahead. and it fixes kind of an edge case in the protocol where the proposal. Look ahead is dependent on the shuffling that mixes in the balances, and these can change an epoch boundary this is not great if you need to rely on this proposal. Look ahead, use cases like Pre comps. Obviously come to mind for for this type of thing.

And yeah, right now, it's Cfi. And the question then is, if we want to go ahead and sfi this, and if so, we could even think about scheduling onto a devnet. Generally the framing has been. Get a stable devnet with these Cfi things. Sorry, sfi things before thinking about.

Tomás Arjovsky: Yeah.

Alex Stokes: Moving to just shove more features in but yeah, wanted to open the conversation now, because I think we should finalize what we want to do here today. So yeah, maybe to kick us off. Then I see Lynn is here. I don't know if any of the Eip authors want to make a case for this. I think something that would be super helpful is also hearing from the community here, which in this case would be users of Pre comps. Any Pre comp providers. And yeah, trying to get a sense of the demand for this.

Lin Oshitani: Yeah, I can give a quick perspective from my side. So I think so. I think, like, if you look at the big picture like we have the rollic centric roadmap, right? And I think that was good like it. It makes sense to as a construction like you, post data to l. 1, but execute an L. 2. I think right now there's a lot of people who feel something wrong about the current roll ups like there. It doesn't feel like they're just scaling the old one, or they're just like an execution extension of the old one. I think this is one of the reasons why we have like so much pushback right now, for. like L twos.

and like going back to like our own scaling. And I think a core part of this is that of why it feels wrong is that I think one thing is a centralized sequencer, basically like just having a single server somewhere that's like sequencing your transactions. It doesn't feel like a natural extension of the old one. And yeah, like, it seems to like hurts the credible neutrality of the whole thing. And so like, basically, this will locks enable. And I think peace roll-ups are like the way to solve this. it enemies will up centric roadmap, but like without the centralized sequencer, it's the only construction that's working right now in Mainnet, where you can actually remove the centralized sequencer.

But, like the issue there is that we have very high latency, like we have to wait at least 12 seconds, or because visuals, they can't post every slot. So sometimes like close to a minute, if the demand is not high. So this is why we need pre confirmations, and to actually lower this time to actually have, like a competitive based roll up. And so I think in the end, what I thing is that, like ethereum scaling is very important. Velope is important for Athem scaling and paste roll-ups, I think, is important, for roll-ups and base pre confirmation is important, for base roll ups. So in the end, I think base and like for base pre confirmation, the cip will be like a very good

Oh, it! It's very much needed, like at least to do it in a non hacky way.

Alex Stokes: Yeah, do you have a sense of how hacky it would be? I think that's a question. At least I have is like. you know? I think so. Yeah, the cip aims to like patch kind of a edge case in the protocol and then to go ahead and trigger it. It's like, yeah, it's not straightforward. So I wonder if there's a sense of yeah, I guess how how important is it to fix this? Now.

Lin Oshitani: Yeah, I think Jason has been looking a lot right now. He's in the call from fabric. Yeah.

Jason Vranek: Yeah, sure, thanks, guys. So yeah, fabric. we're working on 2 goals is one to like help existing. Roll ups become based. And 2 is help. New apps, launches based roll ups. So one of those initiatives was working on these inbox contracts for rollups. And yeah, without this eip, it's it's pretty hacky, so like there's nice. I don't want to discount the importance of having look ahead. Stability. But for us, what really matters is allowing the look ahead to be accessible from the Beacon State. Without this, like, the problem we're trying to solve is that we need roll ups to be aware and respect the schedule of pre confers, and to do this they need a view of the look ahead. So without this, there's kind of 3 proposals. One that Tyco is working on right now is optimistic. Look aheads. You have to

optimistically post your view of it and add these incentives, or trust like fault proofs after the fact like you can always use eip 4, 7, 8, 8 after the fact. Another proposal is to sacrifice real time settlement, and l. 1. Composability, and retroactively determine the canonical L. 2. Head by figuring out who the proposer was. This is simpler, but a lot of the value prop of based roll-ups is real time settlement, and l, 1. Composability, unlocking things. and like a 3rd really hacky approach that might be the simplest on chain is just. You have to import all of the logic to derive the look ahead into your roll up state transition function, which starts to feel kind of like the beam chain effort. So adding the look ahead to the Beacon State just trivializes all these problems and makes it safer and cheaper

to to run these ropes.

Alex Stokes: Yeah, that makes sense. Mark, you have your hand up.

Mark Mackey: Yeah, I mean, I was just gonna say. I think a simple way of looking at the problem is is like. you know, these Pre. Comp. Protocols need to have the proposer on chain ideally ahead of time, and we know that there is an edge case where the proposer can change sort of last minute. And so I mean in terms of getting information on chain. You have a few options you can do. I mean ideally. You have proof that's with the cip, you can actually prove it. if you don't have that, you have crypto economic systems. But in this case, since there's an edge case where you know, people can stake on a certain proposer. But then it can change last minute.

I mean, I think you you end up with a really complex crypto economic system, because people said the proposal was going to be one thing, and then it ended up being another. Even if that's a rare case. The fact that it's an edge case that could happen makes it like really hard to do that. And then you're you're left with, I guess like you said either implementing like large chunks of the the bacon chain protocol on chain, or just having trust. So it I mean, it just doesn't seem like there's a lot of good options here, if we don't just make it provable.

Alex Stokes: Yeah, thanks. Okay, so yeah, a number of voices from people working in the space that would use this feature does seem like, there's some demand for it. I'd like to get a sense from core devs like how much of a lift this is to go into Fusaka. So I think that's kind of the big constraint here is, we have pure dos and Fussaka. I think we'd all like to ship that as soon as possible. The question then, is like, is this the right time to include this Vip? if we yeah risk Fusaka timelines at all, I think that's not great. At least, yeah, we should very intentionally make this make this trade off. So yeah, I'm curious. If any client teams have had a chance to look at this, or even have a sense of implementation, lift.

Mark Mackey: It's I mean, people may already know, but it's trivial in lighthouse. I think the so far, what it comes down to is basically, did your do? You already have a variant of the Fusaka Beacon State? Because I know some clients may not, since, as of yet the Fusaka Beacon State has not changed from Electra, so it's identical. And so some clients have just reused the Electra Beacon State. So if you already have a Fussaka Beacon State. It should be really fast. It really was quite easy in Lighthouse. If you don't, the question becomes, how much work is it for you to add a Fusaka beacon state. Just for for the devs that haven't looked into this that appears to be the main

The main question.

Alex Stokes: Yeah, yeah. Onsgar has a helpful comment here lighthouse and lodestar said above in the chat, that it's a pretty small lift. similar for Teku and see as a point around testing. And yeah, I guess this is kind of the core thing, at least for me, is without this. We don't touch the Beacon state in Fusaka, so we just don't have to think about it. If we do include this, then the Beacon state does change. And so it just increases sort of the scope here. That being said, you know, our bread and butter is testing state transition changes. So it's not anything. Super novel? Yeah. Okay, Otis, do you want to speak to this a bit more? Your comments here.

Potuz: Oh, I was just saying that, for prism is the same. It's just not as trivial as lighthouse that it's just one line change. But I've been told that we have this very well documented, and it shouldn't be a change that would take weeks. I think this discussion, however, is kind of irrelevant on the technical side. There's no argument on the technical merit of this cip, nor on the need of the eip, nor the difficulty of the eip. The only question here is, there are many easy changes that are not scheduled for Fussaka. The question here is, is this going to delay Fusaka testing. Is it going to delay the fork or not? If everyone agrees that there's no delay possible because of this.

then I think there's no complaint. If there's a risk that this is going to delay Fusaka having, we all have agreed that we wouldn't delay Fussaka under no circumstances, and this was part of our choosing on the scoping. Then I think it's that's the question that we need to ask.

Alex Stokes: Yeah, I agree. Sorry if you've had your hand up for a minute.

Saulius Grigaitis: Yeah. So in transfer it, or to to comment on portals ideas, I think I mean, any change actually should affect the delay, or whatever. I mean, it's it's a it's in any case extra work, and in any case extra effort. So I think, whatever we add, even if it's small thing, this almost 100% delays things because it's it's extra stuff. So this is one comment, another comment. I was just thinking theoretically, if we have a more predictable look ahead than we have now. There is a kind of theoretical, at least the way I think there is a theoretical decrease in security in some sense. So I mean, likely it's a very minor or neglect, but but likely there is. So that's that's another point.

Alex Stokes: Yeah, thanks. There's some good discussion in the chat here. So yeah, I think I'll start here. This is a question by pari, are there any unknown? Are there any unknown unknowns that could come up? And yeah, given that, it seems like implementation is straightforward. This is mainly a question of testing. There has been some testing already. I don't have the Pr handy, but there is one to the Fusaka specs from Lynn and Co. With testing there. So you know, it's not that. It's like, Oh, we need to go write the test. And maybe there's issues. We have tests testing can be expanded. And again, this is pretty straightforward. All the client teams here know how to pull down the spec test and and run them. So

yeah, are there any other things anyone sees that we should consider? Yeah, Mark.

Mark Mackey: Yeah, just an angle that I don't think has been mentioned is sort of like what our main priorities are as a protocol. And I think there's pretty widespread agreement that like scaling blobs is one of our main priorities. And that's basically why we don't want to delay Osaka at all. yeah. But I would argue that, like Pre comps. and based rollups are also one of our main priorities for for layer 2 experience. and that that's sort of why this eip is being considered, even if there are other eips that are also trivial. I I do think it's closer to our our main priority is a protocol, I guess would be.

Alex Stokes: Yeah.

Mark Mackey: Let's see.

Alex Stokes: Yeah, I mean one comment on the other eips thing like we've gone through the process. And this is the only other eip currently, like there are an infinite number of other eips we could be talking about. But this is the one on our plate today. So let's let's just focus on this one, but that, all being said, no one has really voiced any opposition, and people generally seem like it wouldn't be a huge lift. So yeah, I think we go ahead and sfi it, unless anyone would like to dig into that more. there is the option of boiling it if we absolutely had to say for Amsterdam or some other fork that also has a cost. But

yeah, that seems to be where consensus is at right now. Yeah. I was reading Perry's comments here. I feel like we were taking this the other way. I don't know, Perry, do you want to argue for this your your proposal versus the other way.

Parithosh Jayanthi: Yeah, I think my proposal is just that. First, st we need to have stuff on the test net so that we are make sure that there aren't any problems. But also just reading Tim's message that Sfi just basically means next devnet. So I guess there's a counter argument for what order we do stuff in.

Potuz: What's the timeline parry for? To have this in for the next Devnet.

Parithosh Jayanthi: The next one's on June 9, th and Devnet 2. We don't have a date yet, but we would like to have it in June.

Potuz: I think we can have this by June 9.th

Barnabas Busa: Ideally. 2 weeks after June 9. We could have dinner, too. And that would be basically what would go to Sepulia and Minnet.

Alex Stokes: Okay, so does everyone feel comfortable with targeting devnet one for this? Or should we target Devnet 2, yeah. Photos.

Potuz: Not sure about other teams, but for us, I suspect that June 9 or 2 weeks after is probably the same, because many of us are going to be in Berlin.

Alex Stokes: Anyone else. Any client teams want to speak to the timing.

Mark Mackey: This. I'm just, I guess, relevant question. Do any of the other existing clients besides prison not already have a a a variant of the Beacon State for Fusaka, even though it hasn't changed yet, because I feel like those are the clients that would take longer and and like, I guess my intuition is, if it if prison is comfortable by June 9, th and they have to do the extra work that other clients would probably be able to do the same thing. But I guess that depends on the load of the client. But yeah.

Alex Stokes: Yeah, I think I would say, just to keep velocity high, just of the general process. We would go ahead and aim for devnet one. So we'd Sfi today. this would be your chance to raise any concerns with that timeline. Yeah, okay, like Barnabas is saying the chat. No one seems to have any issues. So let's do it. We'll go ahead and sify this. Today we'll target Devnet one. And yeah, we'll keep moving things forward. Cool. Let me pull up the agenda. Then for the next item. Okay, yeah. I had a good. I had this next just to talk about pure dos again, because I figured it might inform the dem not one timing.

There were some more details came up like more issues and or details of Bpo, and also without our custody around the period feature set as people got into implementation. I wanted to take some time today to resolve those. So with Bpo. There was, I think a question around this Pr that would like back port this Vpo idea, I believe that's been closed. So I think we're good there. There was also a thread of conversation on discord around. How we want to handle Bpo and the context of networking. So there is a proposal to essentially mix in the Bpo schedule into the fork digest, so that this is legible in the networking layer, and this is good because you don't want to have to like necessarily appear with some other node who might be on a different Bpo than you. So it just keeps the networking layer much cleaner.

There is an also question at that point. If we should touch the fork version at that point it kind of becomes a hard fork. And this is, I think, really the question here is like, how much of a fork is the Vpo change? So let's see, I know, Raul, you were here, and you were looking into this. I don't know if anyone else would like to speak to this issue.

Raúl Kripalani: Yeah, sure. So I can give some some extra context here. With regards to the port version. the key question here is our vpo forks. Given that the change consensus rules are they treated? Should they be treated as protocol forks? That would mean changing the the fork version. The reason why we came. Why I particularly came to the solution was, at the Emr level. Here is our indicating what the next fork version is, and this enables fork signaling, and it enables that appearing so. But they're not indicating what the next fork digest would be so kind of like. The natural solution would be to change the fork version. But then, as we kind of like unravel this, there were more and more deeper changes required specifically to make everything work and line up nicely. We would need to patch the recon state as well.

Which, like, there is, I think, a kind of like a version of the world where that is desirable, because otherwise would end up, I think creating a secondary path for deploying consensus, breaking views with the network without actually representing, representing them as protocol forks, and I don't know what downstream consequences this could have like potentially in libraries and other tools, and so on. So that's kind of like the the top, the top node in the decision tree. But then, like downstream from that, there were a bunch of other proposals for the signaling. There was a proposal to signal the next fork, the next Bpa. Fork and the status Rpc. Request response. In the response. But the issue with that is that you would need to establish a connection with a peer, to then learn whether they're gonna follow the work or not. So this is costly, so still, like the if we decide to not

represent them as fork versions and just keep them at the at the 4th digest level. Then what I would recommend is adding here to the enr to indicate what the next Vp of work that's gonna be followed is, yeah, that's that's kind of like the the 2 different potential plots that we can go. We can go into either changing the 4th version or the fork digest, mixing it with the Bpo's, the next Bpo. Schedule entry. together with an enhancement of new E and R.

Alex Stokes: Cool. Thanks. Yeah. My sense here. And I'm very curious. Your client teams take on this. But my sense here is that if we make these deeper changes into like fork version. Then, yeah, it's essentially very close to our fork. And yeah, this could be fine, but it seems a little bit too invasive fork digest, I think, makes sense for the pairing arguments. And then, yeah, I wonder if there's like some middle ground? I guess you're saying you would. If we went with that approach we would do that, but then also add something to the Nr. Which is not a big thing, but it is still a thing.

Raúl Kripalani: Yeah, it would be pretty complex.

Alex Stokes: Sorry. What was that? You're a little quiet.

Raúl Kripalani: Would be pretty compact, but at a byte level it would just be a few bytes, so.

Alex Stokes: Right? Yeah, I'm I'm thinking, more. Just end implementation and testing that and everything. But yeah, any other client teams have any thoughts on how to handle this.

Sean Anderson: So in in lighthouse like, yeah. Fork version, change is like a bigger deal causes more changes, fork, digest change is more manageable, doable.

Alex Stokes: Yeah, okay, Terrence says, same with prism. And that's my sense as well as that's probably the right way to handle this is, make the change to the fork digest. So again, it's clear from the networking layer. What's going on with all your peers. And yeah, then having the enr, and maybe we'll maybe you could just reiterate like that just helps you manage this at the discovery layer.

Raúl Kripalani: Yeah, exactly. The enr is necessary to know to for 2 reasons for signaling and to discover the right peers that you're that are going to be following the next pork as you. The same next pork as you, so you can. You can continue connected to that one to 4 accommodities.

Alex Stokes: Right without having to connect and do the whole handshake and everything.

Raúl Kripalani: Exactly.

Alex Stokes: No. Okay.

Raúl Kripalani: Cool. So what I'll do is, it seems like consensus is moving in this direction. So I'll do a second version in the second iteration of this Pr and hopefully later today for folks to review hopefully that will resolve the contention here.

Alex Stokes: Okay, great. And this was a Pr to the eip or the consensus specs. Or where did this look.

Raúl Kripalani: To the, to, the, to the eip, and from there we can take a to the consensus standard.

Alex Stokes: Alright, everyone on board with this. because I think this was the last piece of vpos again. It sounds like we have them already, and like the core functionality, seems like it's working, which is really cool. At least we'll know soon enough, and then we'll round this out. Were there any other open questions with, Vpos. okay, cool. Yeah. Thanks for making this updates roll. And great. The other thing that I think we should touch on today under Pyrados is this notion of validator custody? So we had the feature, and just like a quick summary, the idea is you have additional custody requirements dependent on how much stake you have. So say there's so many validators on a node with this much stake, as there's more stake than you would custody more columns under periodos.

This helps with network stability and a bunch of nice things. The complication, I think, as it is right now, is the way the spec is written currently is, it's a very dynamic process where you should basically follow every change to, you know, any validators attached. And this is like a dynamic online process. I think there have been some implementation issues here. And in that case we should decide if we want to do something simpler. just to facilitate shipping. With this in particular, you only change the custody set you need to reason about, I believe, every 32. Eth. Right? So like per validator. And okay, thanks. Sanskar. Okay, we'll circle back to that. But yeah, so the point being is, it would be fairly infrequent changes. And so then there's, I think, a pretty good argument to make that. If this is a more static process, it works well enough.

Yeah, I guess I'd be curious if anyone has run into implementation issues with the current spec, and if they'd like to. Yeah, essentially propose, we go with the simpler option. any others comment. It's possible the people who are closest to this are not on the call today. so we can handle it. Async. But this is definitely something we should sort out in the next like week or 2, cause it's been this like a long running thread.

Barnabas Busa: Yeah, I think, yeah, I think we've been basically going back and forth on this or month.

Alex Stokes: Yeah. yeah, it's not a bad suggestion. Osgar. Just take it to the testing call Monday. Cause. Yeah, it looks like we don't have the people here today. Okay. I will try to follow up on this Async, just so we can get everything organized. And then, yeah, let's sort this out. Monday. Okay, cool. Sorry. I was just checking the agenda. So yeah. okay, so with that all in place I did want to check in on Devnet one. I can go grab a link to the specs. But yeah, essentially, just wanted to touch base. If there was anything we needed to resolve. Otherwise it sounds like we've added 7, 9, 1, 7 to them, that one. So we can make that update.

Let's see, we can iron out these things with Bpo. and we'll decide Valerie custody. But it's also framed as an optional thing. So I think if that doesn't make it until done that, too. That's acceptable, at least. Are there any other things for Devnet? One specs people would like to discuss right now we feel good about them. Okay. was there, do you want to just ask.

Ansgar Dietrichs: I mean, I'm just really just curious. Basically for just some sentiment check in terms of are we feeling kind of the focus getting nicely towards a conclusion here, or like, do we do? We? Are we secretly worried? And we might kind of need some extra time like, what's what's the kind of current state of things.

Alex Stokes: Yeah, maybe a different way to frame this is once we are now things with Devnet 0. Do we feel like Devnet? One will be at least, do we expect them that one to be pretty streamlined on top of that? And then from there would that put us in a place where we feel period office is stable. The next big thing after that, once we have something we feel like. A stable implementation of peer to us is then to think about scaling the bob count and ironing that out, which I expect will take over the summer. But yeah, the way I've been thinking about it at least, is get stable code. Then we essentially move to perf testing around the blog count. And that lines us up for Osaka.

You know, Terrence says here, after done that one just testing, testing, testing, testing. Okay. cool. So I think that was all we had for Fusaka. And yeah, thanks everyone I feel like that was pretty streamlined. I think we're making good progress there. So okay. the other thing today was Glamsterdam. And yeah, so some of this might be a little different or new, just given this new proposal we have to think around or how we think about, you know. scheduling hard forks, pacing them. And all this stuff. So we said we'd move to this sort of regime. Now, where this call is essentially focused on fork plus one, we'd have a lot of the core current fork stuff. Go to the testing call.

So what that means, then, is, we can now open the thread of Glamsterdam, which is the next work for this call. There's a couple of things here. And I mean, yeah, maybe just to get ahead of this. I don't think we should make any decisions today around Glamsterdam, but I did want to start to open the conversation the framing that Tim had in his proposal, which I thought was pretty nice, is to start by discussing the the focus of the fork. So essentially, you know. she lets me and focus on scaling should focus on ux. There's like a number of high level categories we could frame works around for what it's worth. I think most people would say that we should focus on scaling for Amsterdam.

But I do want to leave some room for that conversation again, just to get things started. After that there were 2 headliners on the Cl. Side. So far that have been proposed for Glamsterdam. I invited the authors of those vips to give a short review today. And again, the point is not to decide anything. But just to start the conversation. And then, yeah, a key bit, I think. Given all that context is for us to start to discuss today. What what community input do we need? I think this is something that came up with our scoping of Petra is not being as in sync with the community. And how to think about that. And so yeah, the the thinking is essentially to

open the conversation today. And then highlight different input, we feel like we're lacking. And then we can move forward on that for future calls. So with that context, yeah, Onzgar, you have your hand up so I'll let you speak.

Ansgar Dietrichs: Yeah, I just wanted to say that I think it obviously makes sense to kind of talk here, mostly about the Cl side focus and on on acde more about the El side focus. And I think in some ways the Cl side is a bit easier, I think, kind of across the general priorities that I think right now we we seem to want to to have, and of course we can discuss those as well, but I think mostly it's around well, scaling the l 1 scaling the blobs, making sure that also Ux and things like sensor resistance are in a good place. And so for Glamsterdam. That seems to just very naturally mean we will have to find some ways to continue the blob scaling that probably will already take up a meaningful portion of the attention on the Cl. Side there might be some El side scaling opportunities that will

require Cl. Help. So, for example, epbs, or some sort of delayed execution. Some variants of that would also be Cl side. So basically, Cl might also be able to help with that one thing that I think explicitly, because I think otherwise. Priorities don't make sense. If you don't say what they do not include, I personally think that on the Cl. Side, we've actually been a bit much on the side of focusing around just like features, for the users of the Cl. Users of the Cl. Are mostly stakers. I think over the last 2, 3 years. We've very much focused on delivering kind of just quality of life. Nice to have features there, I would say we should deprioritize that for a while. I think we're in a good place there now, after Max Cb. There are some proposals right around, like reducing the the withdrawal, time and whatnot. I think

these should very much be in the nice to have category like if we end up having room for that in Amsterdam great, but I think that should not be front and center, and the last thing I would also say is because fossil is already one of the proposed ones, and of course you'll hear arguments for that. I think we all agree. Fossil will have to be shipped soon, I would personally say right now, in the moment we're in time I would prioritize scaling, meaning that there are some arguments that fossil is also very crucial for scaling, because it reduces our reliance on solar building for sensory resistance. And so basically making building a bit more heavy is easier to do after we have fossils. So in that sense, fossil is also helping with the scaling. But I think we should basically, for the short term, be pragmatic about. Does it already constitute a bottleneck that we need to address now, otherwise I would personally wait with fossil, for like one or 2 more hard fogs. But yeah, so that's kind of my general mindset for what Glamsterdam should focus on delivering.

Alex Stokes: Okay, thanks any general comments on focus. Otherwise I think it might be helpful just to get into these headliner proposals to help ground the conversation. Okay? So then, I just went in order of proposal here. So the 1st one was 7, 7, 3 2 epbs. Put us if you'd like to give a short overview, and I guess, frame it. Then in the context of scaling ux these types of fork focuses that I think we want.

Potuz: Sure. Let me just share the couple of slides that I used for the protocol call. Let me see if I can do I do this? Here? It is. Alright. This is just a couple of slides. Most people here already know the mechanism. So I'm not gonna go over that again. I just want to mention quickly what are the scaling properties of epbs? it's simple. The Pbs gives you the following, it removes all of the broadcast of the payload and the blobs from the hot path. Instead of like having 2 seconds to broadcast the block, the complete block consensus, execution and blobs. You will have now between 8 and 11 seconds. and you will have now between 8 and 11 seconds, with the current slot times to broadcast blobs. The whole thing

bottleneck today for scaling blobs and for scaling in general. The bottleneck today is bandwidth. There's no other bottleneck that gets even close to bandwidth. So these numbers are just huge changes. and this is the only eip that achieves this thing of like completely decoupling the payload from the block and completely decoupling the broadcast of the blobs from the validation of the block. So that's the major change that the cip gives in terms of scaling. Of course there are other known scaling benefits which move around the trust assumptions on, on, off protocol players. But I've been told not to focus on this today. They are written in this slide. Let me just go to the next one

and other features that Dps has. It's absolutely, trivially composable with other proposals for scaling both on the El and the Cl. And it's easy, because of the mechanism of separating the consensus from execution. Logic. once you have different consensus and execution logic, then you can just tackle both sides independently. So compare, what's the complication of including fossil with other proposals for delayed execution? Of course Cpbs gives you delayed execution and compare it with the proposal on how to include this, for epbs for epbs, including fossil, is just trivial. It's just a single bit list that needs to go in the bid, including a block access list, is absolutely trivial. It doesn't even affect epbs at all.

So there's no changes that are needed. Whenever you want to make changes, either purely on the consensus side or purely on the execution side, because the logic is completely coupled. So that's what Dpbs does. It separates the payload from the block, and it makes it simpler to argue about changes on either side as it stands today. It only involves Cl changes, it does not touch the El at all. It doesn't even touch the execution engine. If you do this correctly, in the sense that when this execution, when the consensus layer gets the block, it doesn't even talk to the El to validate it at all. There's no even a single message to the local El. It can be tested in isolation because of this change because of this property. So whatever the El is doing in a fork, we can just test epbs separated at that time.

It's already been. It's already implemented almost completely. But there are some simplifications that aren't included yet, but it's fully implemented in Taek. One prism. And well, that's it. Let me just have this last slide with some questions that people typically complain about. There are many others. But these 3 I like. This is one that I get very common. It enshrines a particular type of auction, and it would just like, Give us this tech debt forever. No, there's no auction in epbs, not at all. The proposer can do whatever he wants. 99% of the pip is separating the block from the payload the auction part. It doesn't exist. What happens is that the payload has to be signed by someone that's just for simplicity, and that can be changed at any time in the future. In fact, all of the proposals that we have for Aps is execution tickets, and so forth. Rely on the separation of the payload from the block. So they rely already on the feature that epbs produces minimally.

It is not compatible with existing off protocol mechanism. That's that's just purely false epbs is compatible with anything that happens now, because you can continue doing whatever you're doing. Now, if you wish to. Epbs just allows you to do in a different way, but you can just still sign your blocks and your payload yourself and trust whomever external builder is going to produce you a payload if you just signed it blindly. it increases protocol complexity. No, I think I already argued that it doesn't. It's true that it's not a simple eap to implement. It takes time to implement on the consensus side, but it actually simplifies the protocol itself. It simplifies it because it separates the concerns of the consensus and the execution.

If you want to read more, these are resources. The 1st 2 are just non-technical, exactly in the same tense that I talked today, and the last one has more than what you wish to to look for on the technical side.

Alex Stokes: Cool. Yeah, thanks for the review. So yeah, I think in summary, like, if the framing of Amsterdam in terms of fork focus is scaling. Yeah, the argument here is like Pps gives us these pipelining benefits.

Lightclient (Matt Garnett): That's.

Alex Stokes: Directly helps us scale. I don't know if there are other questions from that. I did have one question. I believe there's given the way we separate the execution payload from the consensus block. There is some impact on how transaction inclusion, latency would be perceived effectively adding a delay. Could you speak to that a little bit.

Potuz: I'm sorry. Oh, oh, the delay of including execution is including transactions.

Alex Stokes: Right.

Potuz: Yes. So this is definitely an issue. So the issue here is, the following is, if you're sending a transaction today, the builder can produce can include it right at the moment that you're that you're sending it with the Pbs. There is a delay between what the proposal the proposer has committed to a blog. and that block is not revealed yet. However, this delay we're looking into like making the slot shorter, and we believe that we can push this delay to about like one second 1.5 seconds. We have been doing experiments with 6 MB blocks, and they show that we can actually squeeze the time in which the builder has to reveal their payload.

Alex Stokes: Okay. Thank you.

Potuz: Party.

Alex Stokes: How's it going.

Potuz: Question about 4 choice. I don't know if you wanted to mention there he is.

Alex Stokes: Rolling. Yeah.

Potuz: There is. And this is something that people typically ask about. And it's scary, because. frankly, because most people don't know what 4 choice is on ethereum. and there are a few that actually do know. And they have this concern. And I agree any touch on 4 choice is important, but most of our bugs have not been on 4 choice. Most of the bugs that we have seen, and the important security concerns that we've had had been around the execution engine, and actually the non separation of the consensus and the execution. However, there is a minimal change to 4 choice. The change to 4 choice is that now today you have a node in 4 choice means that you've seen a block, a consensus block and an execution block, and with the Pbs. A node in 4 choice would mean 3 different things. Either you've seen the consensus and the execution block, or you've seen only the consensus block, or you haven't seen anything.

So there's this one new feature that you need to account for that a consensus block might have come without a payload that was revealed. But that's the only change. We still rely on proposal boost in the same way as today to to enforce the security of the builder and of the proposer. And there's a little mechanism of merge view that I don't want to get into details today. But that's just very minor, which is just counting attestations from the Btc.

Alex Stokes: Right and just to clarify. There would be then like 2 proposer boost. because you'd have one for the 1st round, and then.

Potuz: No, there's only no, there's only one. There's no changes to fortress today except the node mechanism that I said so. There's only one proposal boost that enforces that the consensus block was there. and the builder can actually overload the existence of that boost to not to not produce his own block his own payload. There's no changes to 4 choice except this fact that attestations that are tested for a block that did not support the payload then don't count for the full node that has the consensus block and the payload in it.

Alex Stokes: Got it. Okay? And yeah, in terms of process, I will elevate this comment from Onsgar. That essentially, I think now, the framing is to just have an intro to these different proposals we will get, I think, much deeper into the weeds later on in the process. So we'd probably then, at that point, want to get deeply into like pros and cons and start, you know, weighing different eips against each other today, I just wanted to open the conversation. So yeah, let's just keep that in mind. You did mention Potus. There are 2 cl clients who have implemented it. I would assume prism. And what was the other one.

Potuz: Teku. We had finalizing, and that that accelerated the process quite a bit. Once you have more than one client is very simple to start testing.

Alex Stokes: Alright cool. Yeah. Thanks for the overview. Unless there are other questions for that, I think we'll then turn to the next proposal we have on the Cl side, which is fossil. let's see, is tomorrow on a call.

soispoke: Yup down here.

Alex Stokes: Okay, yeah, take it away.

soispoke: Thank you. Can you guys see the presentation.

Alex Stokes: Yep.

soispoke: Yeah, Hi, everyone. So yeah, I'm and I'm actually very happy to make the case for 8. 0, 5 as a headliner for for Amsterdam. So yeah, I thought I would just start by the explained 5 sort of prompt fossil. What fossil does is basically improving ethereum's censorship resistance? And it does so by enabling multiple validators to ensure that any transaction valid according to the protocol rules is included in ethereum blocks. so it does this by having multiple validators that build inclusion lists and impose constraints on the sophisticated builders that we have today. I am going to go through the mechanism real fast, just in case there are like 3 very simple steps that are important to keep in mind. The 1st step is about building and broadcasting the inclusion lists. So it's like you have 16 validators that are randomly selected to become Il committee members or includers.

and each of them basically monitors, the main pool, and includes like transactions that are comp pending in the public main pool. In their inclusion list up to 8 kB, which is like around 40 transactions per inclusion list. If if you take the median transaction size. and then you the broadcast broadcast, their inclusion list over the shared between network. And what validators do is they monitor the P. 2 P. Network, and they store the inclusion lists that are broadcast until a deadline. That's the view. Freeze deadline that, and that's 9 seconds into the start. And so at this point they keep forwarding like inclusion lists, but they stop storing new ones. Then the second step that's very important is about the builder, that is, including Inclusion List transactions in its block.

And so what the builder does is it also collects and store the inclusion lists, but it actually has additional time after the view. Freeze deadline just to make sure, like there is enough time for the builder to see all the available inclusion lists that were broadcast by the committee members. and so 11 seconds into the slot. The builder, just like, takes the union of transactions across all its stored inclusion lists and then include them in the execution payload before the full block is just like proposed to the rest of the network by the proposal. And in the last step that's like the enforcement step. Attesters also take the union of transactions from Inclusion list they sold according to like their local view, until the view freeze deadline, and they check whether all these transactions were actually included in the block execution payload by the builder.

This is where the folk choice enforced comes from. It's like a testers will basically only vote for the block if it satisfies inclusionist conditions according to their local view. So that's the mechanism. I want to briefly talk about some fossil properties the 1st one is that inclusion list, and the payload can be built in parallel, like during the same slot, which is sort of nice and they only need to be merged towards the end of the slot. And that provides real time, censorship, resistance, which is one thing we like. The second part is like we actually have multiple inclusion is proposals like, that's a very cool and central design consideration, and that allows to be quite robust to commitment tax. But it also gets us like a very nice one out of N honesty assumption.

and what it means like, we only need one Il committee member to build its inclusion list honestly and include transactions from the main pool without censoring for the whole mechanism to work properly. And the conditional property means that the builder must include all the I transactions until the block is, unless the block is full sorry and the builder is also not constrained on where inclusionist transaction transactions are included in the block or their order. And these 2, like last properties, are like, quite important, just to like prevent inclusion list from being crowded out by Mev transactions like, imagine if there is like dedicated additional block space, that is for Il transactions, and that will have to be included like I don't know. At the top of the block, or at the end of the block, we might, we will probably see, like some something like an il boost sort of thing emerge where like, you try to sort of like, include your valuable transactions but using il block space. And so

in fossil right now, we avoid this, because the Inclusion List transactions have no ordering guarantees, and they must be created before the builder actually builds the block. They are broadcast publicly. So there is really no point in trying to include your transactions with the fossil. Why, it matters well, I I think it's kind of a useful like. Censorship. Resistance is sort of like a core ethereum value. And today we have more than 80% of all blocks that are produced by like just 2 builders. And yeah, it's important to keep in mind that these 2 visitors can arbitrarily decide whether to include or exclude transactions from like most of ethereum blocks. And just by looking at the data you can see like these huge fluctuations in builder censorship. And that's just caused by like one or 2 builders that just suddenly decided to censor more or less based on like the fluctuations of their policies.

So what fossil does is like? It actually fixes this by giving power, sort of like back to the more decentralized set of validators to enforce inclusion constraints on builders, basically, and that restores fairness and ensures that theorems remain pretty neutral who it benefits, or I I think it's sort of like clear that it benefits, like all users, by ensuring, like their transactions are just included on chain in a timely manner as long as the network is that congested and without having to rely on like those 2 centralized entities, to not censor them. So I think it's like a big ux thing. and the primary benefits. I think the 1st one is obvious. The second one is actually sort of very interesting, because

it allows to scale ethereum without having to impose the constraints on the local blockbuilders. The idea there is like, if you allow validators with fossil to independently enforce transaction inclusion. Then it's a major step towards scaling ethereum throughput because it removes the dependency you have on local builders to preserve censorship resistance at the cost of performance and incentive, and I linked it there. But there is a really good article by Barnaby that goes into more details on this. But there are all these like the improved yeah. Ux that I talked about. I think when your transaction is sent for today, you have to wait for quite a long time like 7 to 8 bucks, I think. And enforce. You know that that actually drastically reduces the the time to inclusion for transactions that might be sensible. So it is an a improvement.

Yeah. So I I think it does like fit quite well with the the ethereum priorities. in terms of I mean it. It. Both are all scaling, and it improves ux so. But that's my perspective. I'm obviously a bit biased. It doesn't scale blobs, so it doesn't like do 3 out of 3. But you know 2 is quite good and a a secondary benefit. That was also brought to me recently. And it's kind of enable. It's nice, like it might actually allow some optimistic roll-ups to shorten the challenge period from 7 days to 2, 3 days. If their Tbs is not too big, but like it's, it's still like a an interesting benefit, I guess. Yeah, I'll just go on. Why, now?

I think. Yeah, we've been talking about having is, and like better solutions for censorship resistance. For a while. The builder market is inherently centralized just because of like the Mev and the private order flow dynamics. So I don't think that will change like anytime soon. And, on the contrary. Basically, we've observed, like increasing vertical integration across builders and relays and socials over time. So it's not like looking like it's going into in a super nice direction to be. To be honest, I think, observing how fossil behaves on Mainnet is actually also important to us to make decisions on future local changes. We might want to make for example, like this new idea of like delayed execution with Dkvms. I will. I forgot the link, but I will put it to it is like depending on, like the same view merge mechanism we use for fossil. So it would be nice to see it live on Mainnet and that will inform us on how to to deal with other proposals that are important for future upgrades. We need also fossil to

to to ship a case, in in my opinion. And then a very important for why, now I think it, and it's always like understated. But like we are like quite lucky that there is not that much censorship going on on the network right now at the protocol level? and if we wait and things change, and and they can like it could actually make protocol level changes to improve censorship, resistance a lot more difficult to coordinate and adapt. And I think that's a point that needs to be taken into consideration in like the sort of urgency in shipping fossil. And then I'll just finish by the technical readiness. Yeah, so 1st of all, 1st of all, is like the result of like multiple years of research on inclusion list, multiple proposals, new merge mechanism, and and so on.

It's now working and like, implemented on, on different clients. 5 clients have worked on it. And it's actually successfully runs on a local with prism loadstar teku and get interoperability. We are now working on the spec test for both the Cl. And the El. We've had 11 possible breakout sessions that have been like, at least for me, like very, very nice and useful and we address like sort of like security concerns around il equivocation. And so there was actually a problem in like a previous eip that was about inclusion lists. We've made sure it's also compatible with account, abstraction, delayed execution, epbs, blocks. access blockable access lists, and and other like proposals on the El and Cl. Side

and you can go on Meetforcil dot e dot limo. It's a censorship resistance web website that's using Ens and Ipfs, and there you can find, like an actual update on progress on the implementation side of things, but also like all the resources that are like useful for Fosso, both for, like the current proposal, but also like research directions and everything. Thanks. That's it for me. Thanks. Yeah, thanks a lot to all the co-authors, and but also, like all the client devs and contributors that have worked on this so far. It's been super nice to work with all of you, and that's it for me.

Alex Stokes: Great thanks for the review. Yeah. So you know, going with this focus or this framing of the focus of Amsterdam as some combination of scaling and ux, then, yeah, we have fossil that fits into that category. So, okay. any questions, I guess, to close out the segment on fossil. Okay, I think your hand was up for a split second. Well, that was.

Ansgar Dietrichs: Just for comment. I just wanted to say that, like, in a way, it's almost like we should also not over focus on these these focus areas, right? Like, I think the reason like, I think some people in chat were a bit amused that basically, like fossil, is now being presented as a ux and a scaling benefit. I think it is both, but it is much more crucially also delivering to one of like delivering one of ethereum's core values. And I think it's much more justified through that, like sensitive resistance is at the very core of what ethereum is all about. And one of the core things that also delivers for L. 2 s. And for everything right? And I think it doesn't need justification through these shorter term focus areas. I think the only the main reason why it is useful to have that conversation. How much does it also help with Ux? How much does it also help with scaling is

to ask the question. do we need to have that in the next fork? Or is it more? Something that we need to like slot in at the next convenient time. So I still think that conversation we should have once we kind of actually determine the scope of Amsterdam in a month or so. But I just wanted to mention right? Just like this is crucial to the future of ethereum. Definitely, I think we all agree on that.

Alex Stokes: Right? Yeah. And you know. it's, I think, perfectly fine to say that Cr is a focus of a fork, at least as a general statement. So we don't need to like gradually stick to just scaling or just ux, as like these, only options for the glen focus. Yeah, tomorrow.

soispoke: Yeah, yeah, I I just want to agree fully, like the I don't want to like make it seem like, it's as important for like scaling and and ux, or like, just like going through these lenses as it is for some social resistance. It's it's mostly definitely like a proposal force and social resistance. and I think it's like also interesting, because it can lead to these like pretty big improvements, in my opinion, in the future, and like in in scaling, which is interesting to think about. But yeah, I I didn't mean to like sell it as like a scaling eip. I don't think I want to do that, and I don't think it's it's fair. It's like it is a sensorship resistance, eip, and the argument. I think the the more convincing argument for me of why it should be included rather

like sooner than later is more about like the we don't know how censorship is gonna evolve on the network. And that's the part that worries me the most not like. Oh, we need to get fossil in because it's gonna unlock like a ton of skating. That's not what the where the urgency is, at least for me personally.

Alex Stokes: Makes sense. Thanks. Okay. Then, I think the other thing for today, I did want to try to start building the muscle memory of thinking about getting input from different parts of the community. So yeah, I assume this is a conversation that will probably also be informed by the execution layer. But assuming, then, we have this focus on scaling, possibly ux. maybe cr for Glamsterdam. Then, yeah, I think either of these headliners could make sense in that framing. One thing that we've historically, I think, lacked quite a bit is again input from the broader community. So I wanted to take some time to discuss and to make it concrete. We can focus on these 2 eips today.

And just yeah. start to start to highlight who you'd want to get input from to help inform the scoping discussion. So off the top of my head right now, I think we could pretty easily say that with Upps. There are a number of comments here that we're speaking to different people in the Mev ecosystem. So I think we should try to incorporate their input. And then, yeah, fossil. it's kind of a pretty broad set, simply just because it's all users of ethereum. But yeah, we mentioned roll ups. And yeah, I think there are a number of people we could incorporate there. And let's see, I was just looking at Tim's comment. Here, I think we should assume there will be more. I I don't know.

Tim Beiko: More candidates. Cl, head headliners. Yeah. Barnabas was asking the question.

Alex Stokes: Okay. right? So yeah, this is again, I just wanted to start the conversation. Today. I assume there'll be more and we'll cover them in future calls but yeah, okay, Nixo has a nice cloud here to solo state grocery Pbs.

Chanderprakash Sharma: Can I ask one question?

Alex Stokes: Sure!

Chanderprakash Sharma: Yeah. so like, as we are implementing thinking about implementing epbs for the ethereum cl. So if we think at the privacy level in because the future roadmap of ethereum is going to be the privacy level. So what are the impacts? It can like to the core protocol have any idea about it?

Alex Stokes: The question was, core impacts or impact to the core protocol from apbs.

Chanderprakash Sharma: No question was that like epbs is just like another way of the sensors of resistance compared to other mechanism. So my question is that like, if we, if we encrypt the for example, we are encrypting the blocks and transaction end to end.

Potuz: I can probably take. I'm not. I can probably take this. Justin here might be probably a better person, but I think that all of these primitives for encrypted mempoles already rely on some sort of separation, on some sort of delayed execution. An epbs gives you this, so it's tangential. But I think all of the private mempool mechanisms get only stronger when you have delayed execution.

Chanderprakash Sharma: Okay. Thank you.

Alex Stokes: Okay, thanks. Onsgar has an interesting take here that essentially the strive for community input should be more of an El focus than a Cl focus. I think we can debate that. I don't know if you had something to add to that, Anzar.

Ansgar Dietrichs: No, I mean, of course. Also, we should try it everywhere. I'm just saying I think it's more important on the Yale side, or more of a liking thing on the Yale side.

Alex Stokes: Gotcha? Oh, yeah. Potus.

Potuz: I think the I mean we have this this idea, that scaling the El means scaling the protocol, and then this the separation of the El and the Cl. But we see that one of our biggest bottleneck is networking and scaling. The Cl. Does affect this. So it's very hard to separate this. And we can actually talk about scaling vips on the Cl call.

Alex Stokes: Yeah. And I guess the general comment, there is as we get closer to a final Glamsterdam scope. you know. I think we will need to take these things together. We can't just say, Oh, the sales over here, the else over there, and they just are working off in a vacuum. especially given the nature of. Yeah, I think all of these vips we've discussed today have at least some impact on both layers. So we will eventually need to take them in consideration. At the same time.

Chanderprakash Sharma: Stocks. I have one request to you. I already mailed to Tim also, and you about like I like, recently joined the core protocol meetings because I was working on layer 2 protocols. Our paper is coming very soon so I have one to guess like where the meetings of the all rank. It's fine, because I also discovered the project management repo. But I did not find then I lately find in the discord. So there is a so many channels for it. so could you please approve like I got the meeting link in.

Alex Stokes: Yeah, I couldn't quite hear you. I think you're asking where you could find information about the Acd meetings.

Chanderprakash Sharma: Yeah, actually like I mail regarding it like as I read the report, like, I have to mail either the team or you stop about like to join the meeting. But actually I did not find any meeting link there, it only showing like there is the meeting in the calendar. But there is a no end meeting link, but fortunately I find through the discord. But many of the time I forgot to join, because the. There is the meeting link in your present in the my Google Calendar. So could you share the calendar or provide me permission to join that.

Alex Stokes: Yeah, well, it sounds like you've discovered the process. So yeah, we have agendas in the Pm repo that you've mentioned. And then also, yeah, the meeting information share on discord. So yeah, my email is in the agenda. So if you would like to follow up. let's just take this offline. Oh, yeah, I'm in fang.

Mingfei Zhang: Is there some time left for me to present my vip like 12 min. so I want to make it in a headline in the next folk hard, hard folk.

Alex Stokes: Yeah. So I replied, on the agenda about this the way we're thinking about this now is having this process for headliner proposals. So I think ideally, you would have I post on these magicians that proposes the headliner. If that fits the scope, and then we could cover in a future call.

Mingfei Zhang: Okay, okay, that's cool.

Alex Stokes: Okay, thanks. Okay, let's skip back on topic. So I did want to highlight different parts of the community that I think we should try to get input from, as we inform the scope discussion. And let's see. So we have different map ecosystem people, free Pbs, solo stakers there. Probably generally validators across the board. And yeah, anything anyone wants to call out for fossil. I think that would generally just be everyone. so that might be a harder set to get a concrete representation of okay? Yeah, I'll think about how we can get again concrete input from these different parties and incorporate them into future calls, as we continue the Glamsterdam scoping conversation.

And with that let me just double check. Oh, there was a okay, I guess I'll just call this out there's a poll here for the H. Star name for the upgrade after Glamsterdam. Let me just grab a link here. There's this post on Ethan magicians. So yeah, if you would like to chime in, you can do so there. And okay, yeah, I mean, okay, I see your comments here. I'll follow up with you after this. But yeah, otherwise, I think that was essentially everything on the agenda today. And yeah, unless there are any other comments? Then I will go ahead and say, we can wrap up early. yeah, I guess. Generally, just yeah. Be thinking about the different points made today around Glamsterdam, continue thinking about the the framing of the fork, and like, what are the sort of core properties we want to focus on. And yeah, I think, well, maybe I won't speak to next week. But

yeah, point being is, we will continue the conversation. And yeah, get to a Glamsterdam. Okay? Unless there's anything else. Let's go ahead and wrap up today.

Mark Mackey: Thanks guys.

soispoke: Thanks. Okay. Thanks. Everyone.

Alex Stokes: See you next time.

Ansgar Dietrichs: Thanks. Ron bye.

Chanderprakash Sharma: Thank you, everyone. Bye-bye.

Potuz: Bye-bye.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.