 All right, Ethereum 1x. Let's talk about it. For those of you who don't know, just a quick intro. For me, I'm at the Ethereum Foundation. I worked at a bank for a few years. I have a wife and three cats. And I mainly work on community security and DevOps at the Ethereum Foundation. So if you see me around, please say hi. I'm friendly. So the thing I want you to take away from this is that ETH 1x represents sustainability. That is a really cheesy hashtag that we came up with at one of the 1x meetings. And I really like it because it describes how we're trying to keep the chain together and how we're trying to make Ethereum 1.0 last for as long as necessary and keep the network running and efficient for everybody using it. Oh, before I start this, there's going to be a time for Q&A at the end. So please get your questions ready. We'll have mics at the audience, probably just in the aisles, I believe. So when that happens, I will let you all know. Oh, it's actually going to be at the front. So line up at the front when you have questions once my presentation's over. Wow, that cough echoed. Here's the beginning. We had ad hoc meetings in Prague during DevCon 4. There was about 25 people there. You could see some of them in that image. And we talked about how to achieve sustainability. We were saying, there's a lot of state bloat. There's things going on that are going to fundamentally change Ethereum when 2.0 comes around. How can we best prepare for those in 1.0 while keeping the network very, very active, or not active, but very efficient, very optimizable for people to use? So from that meeting in Prague, we came with four working groups. The simulation working group, state rent working group, the chain pruning working group, and the eWASM working group. So simulation working group was put together to understand how can we look at how much state bloat is affecting Ethereum? What can we do about coming up with graphs, figures, numbers to help us understand more? The state rent working group, which has now turned into the state fee working group, which has now turned into another whole working group kind of a thing, is about addressing the growing state, maybe advanced snapshot syncing and stateless clients are also explored later on. There's just a ton of stuff. Like ETH 2.0, Danny's going to talk about this after me, but ETH 2.0 is going to have a lot of changes and figuring out how to store information in a way where it's not going to blow up people's hard drives. So can we address some of those problems now? I mean, the fact is, people are just storing this data for free. And it's a difficult thing to incentivize and figure out what to do with. You can't even run an Ethereum client on a regular hard disk drive anymore. It has to be on a solid state drive because of the disk IO reads or the disk IO. So that's that working group. We have chain pruning. Can we archive blocks? Can we archive logs? How many of you here are DAP developers? Keep your hand up if you use logs in your DAP. Keep your hand up if you're a cheater and you're using logs because they're a cheaper storage than on-chain storage? OK, yes. That's exactly why we might need to archive logs. It was never really explicitly said if we're going to have logs last forever. They're supposed to be for error messages and for just tracking certain things. But now that they are a cheaper way of storage, that's unbalancing things a lot. And it's causing some state bloats. So can we archive those? Can we maybe make it so that you have to fetch them from an external source? We're looking into things like that. And then there was the eWasem working group that determines what from eWasem is going into 1x and 2.0. A lot of eWasem workshops and talks are around DevCon. So feel free to jump into those for more information. So at the time of Prague, basically between late last year, early this year, sustainability meant a renewed effort to invest in the existing ETH 1.0 network to ensure it can survive and thrive indefinitely. So that's what I alluded to earlier. That's the first version of what sustainability is. I'm going to get to the second one later. So ETH 2.0 is sexy right now. It's like the new hot thing. Everyone wants to work on it. But we still have this 1.0 chain. And up until last year in Prague, there was some kind of discomfort and some things that we really need to address about the fact that developers were dropping off doing stuff with 1.0 to do stuff on 2.0. And we need to make it so that 1.0 is still sustainable and 1.0 is still fun to work with and has goals and its own driven architecture just like 2.0 has. So not that we don't like 2.0, but it is the sexier younger brother of ETH 1.0. And we need to make sure that 1.0 and 1.x stays in the forefront until we can get to 2.0. OK, so this was kind of, I don't know how many of y'all remember this controversy from last year, but like the Prague meetings that I talked about, the ad hoc ones with 20 to 25 people, a lot of people said those were secret meetings. And the reason for that was we did have this note sheet passed around during it that I think someone from Consensus took, and they basically took notes down and they were going to be released later, but they got leaked early because one of the core developers thought that people should know about the notes before we were ready. So we were talking about 1.x in Prague. It was like 20 people in a room. There were other ad hoc meetings all over the place. And so people interpreted this as, oh, these people are coming together to figure out what's happening to Ethereum without anyone else's input. This isn't like the core developer meetings where it's all open and out there and streaming. So we did an experiment. Because of the 1.x initiative starting, we wanted developers to be able to speak candidly without fear of media misinterpretation. Sorry, Lee, sorry, Ken with coin desk. I know you're out there, but yeah, without fear of media misinterpretation. So we had an ETH 1.x core dev meeting on the 30th of November of last year to solidify plans for workshops and things like that, but we used Chatham House rules. And what that means is everybody attends the meeting and you take notes, but you don't attribute those notes to anyone in particular. What you do is you just write the notes down and everyone can talk about what happened at the meeting, but they can't mention names. So we decided to just try that. We didn't record or stream the meeting and the community pushed back on that. So we decided to not do that again. So that's kind of the end of that, but it was really interesting to me, and I put this in the presentation because this kind of jump started a lot of enthusiasm for transparency and really showed us what the community values within Ethereum. And I thought that was really important. We had a 1.x meeting at Stanford that was streamed and recorded in January, and that one had a lot to do with Alexi kind of running the meetings and doing a really good job of getting us all organized and talking about the things we needed to do in 1.0 to achieve sustainability and on-chain pruning and stuff like that. Berlin, I didn't get to go to that one. It sucked because I didn't get to go, but in April we had another meeting that was also streamed and recorded. You can find all this on YouTube. It's hours of really good content on 1.0 and 1.x. And a lot of different stuff came away from that, including more working groups. We had EVM Evolution, which is improvements to the current EVM around speed, safety, and interoperability. That one's currently not doing anything right now. That one got some feedback from different developers that they didn't really want it to be put in, so that working group is no longer in existence as far as I know. There's the testing and infrastructure team. They kind of have a working group where they're trying to build these tools, these cross-client testing tools, and other things for compatibility. There's the finality gadget, which is using the 2.0 beacon chain to finalize ETH 1.0 blocks, which is a really, really cool idea. That one's actually about to spin up a lot more, that's gonna be a lot more news from that coming soon from what I've heard. EIP 1559, the fee market change. That one, if you've seen Eric Connor, Econar, or Vitalik Buterin talking about that, that's making transaction fees more stable and predictable by splitting the transaction fee into two different types of fees. One of them is burned on chain, and the other one is the predictable fee. So after all these meetings, it's been about a year since Prague, where are we at with sustainability? What is it now? And I'd argue that it's about improving processes and making protocol changes to ensure the sustainability of the Ethereum 1.0 blockchain. And what I mean by that is, unlike the version one sustainability, where it was just about, let's keep the chain alive, let's do some stuff with reducing state bloat and rent and all this other stuff, now we are looking at improving processes, making protocol changes, making things more energetic and exciting in the 1.0 chain. And I've been seeing a lot more participation because of that. I think that people are getting really excited about what we can do today on Ethereum and without having to exactly know what the future brings. This is an example of the current EIP process. So this is like my favorite, or one of my favorite improvements right now, which one, yeah, Ethereum EIP process. So I'm an EIP editor, I'm involved in that. And right now it's kind of hard to jump into. The EIP 1.0 is our technical standard for how to submit a change to the Ethereum protocol or a community standard. And it's really hard to digest right now. It's kind of long, there's all these different EIPs, you have to format them a certain way, and we wanna make that a little bit easier. So right now we have work in progress, draft EIP, accepted EIP, main net client implementation, network update, and then the miners mine the new blocks and then we're at consensus. And what we do is we take these EIPs and we stuff them into these hard forks and they're on a certain date and time and we do that by block number. And that's not really efficient because it makes us rush. We don't have test cases up yet. We have to pressure everybody to work really hard and really fast at this, you know, normal, this original model of how we do things today. Instead we want an EIP focused network upgrade model where we have our draft and then we have the all core devs green light these core EIPs. From there we get into the implementations, from there we get into testing, and then it's only accepted after the test cases and the implementations are finished or near finished. And what that's gonna help is instead of us deciding early on like, okay, we're gonna put EIP one, two, and three into this hard fork on this date so we're gonna have to rush to the finish line. Now we just do a hard fork when the EIP is done. And if there happens to be more than one EIP done at the same time or there's like really ones that are really close together, that's great. Some of the challenges behind this are gonna be letting clients, exchanges, people like infrastructure projects like Infura and Cloud Front know when these hard forks are happening. So we're gonna have to bump up our communications. We're gonna have to ramp up and assign people to know when these things are happening. And that's actually a job that the Ethereum cat herders which I'm also a part of is gonna hopefully have a really big job in accomplishing. Here's another really cool change. This one is a graph from Alexia Kunov. And this is how, whoops, this is how things want to work in the future. Vitalik or people on the internet or other core developers have an idea and they're smiling and they like, I really like this idea. So they're going to put an improvement proposal out there maybe on Ethereum magicians form but it's not formal yet. Then there's a working group formed around each proposal and research project and then others can optionally participate. There could be client implementations, other improvements but it's not like we're having every core developer look at every EIP. We have these working groups of people who are interested and they present their case and they do the research and the simulations and the testing cases and the implementations and work with teams. And this is a lot better than how we've had it before where the core devs have to look at every EIP. I want to make a note here that these improvements that I'm talking about aren't done yet. It's a work in progress and we aren't even at consensus as this is how it's going to be. We kind of have to come to rough consensus about this but this is definitely what I'll be pushing for as we go forward into this new era of ETH1X. So how is this all going to get funded? We all know that there's all these grant programs out there for ETH 2.0 and different tooling projects. The Ethereum Foundation earmarked $8 million back in May for the next year of ETH 1.0 and 1.x research that was announced at Ethereal and we're working to bring full-time ETH1X teams and coordinators together. That's also a work in progress that you'll be hearing more about in 2020. So yay, we got funding. We have excitement. We have everything we need to really bring the ETH 1.0 chain into its next evolution before we hit 2.0. So if you wanna know more, Google Alexiakunov's Medium, his blog has a ton of good posts on that. There's an Ethereum wiki page that has the ETH 1.x history on it. It talks about the Berlin meeting and the Stanford meeting and it has links to the YouTube pages. Also check out the PM repo on Ethereum's GitHub. That's the one where we have the bi-weekly core developer meetings that myself and a few others help coordinate and run. For every core developer meeting that happens every two weeks, we have a full transcript of notes that's in the PM repo and you can go back three years and see notes for every meeting. Also YouTube streams and live recordings of almost every meeting. Contact me if you wanna help. If you're a low-level developer, this stuff is more like not for people who build dApps necessarily except to get their input. This is more for low-level client developers and people working on the protocol or the networking layer, but if you're interested in that and don't know where to start, please reach out to me. I can connect you with the right people and I'm not an angry, frustrated person. I'm happy. Happy to help. So everyone, thank you so much. Start to come up to the front for questions. The microphone's over there and yeah, anybody got questions? If not, I can talk about my tabletop RPG podcast, but that's like very unrelated. So I don't know how many people are gonna enjoy that. Oh, some fans. Hey, what's up? Introduce yourself and then pose your question. Hi, I'm Saren. I'm wondering what's the soonest that EIP 559 might be implemented? Awesome. EIP 559, that was on this one, the theme market change. That's a good question for Vitalik and Eric. I'm thinking 2020, they can definitely go in. We still have to come to consensus around it, but I have not seen much opposition personally for it. I think it's a really important change that a lot of people are very, you know, like they really like the idea of that. It will change the user experience a little bit and the experience for DaptEVS, so that is something to take into consideration. But otherwise, I think that that's a really good idea.