Bankless - Tim Beiko | Layer Zero

Episode Date: November 30, 2021

Tim Beiko runs the core protocol meetings for Ethereum. His path into crypto began in 2017, buying the top. But he stayed in the space, initially working for Consensys and their Besu Ethereum Client before trailblazing with EIP-1559's implementation. This conversation covers his story into working with Ethereum core developers, the role and landscape of Ethereum clients, and coordinating the maintenance and upgrades to the Ethereum protocol. With the merge on the horizon and barbarians at the gates, humans like Tim Beiko work to keep Ethereum as credibly neutral, efficient, and open as possible. Can Vitalik impose his will on Ethereum? Is it centralized? This episode has the answers. ------ 📣 OPOLIS | YOUR CRYPTO CAREER https://bankless.cc/Opolis  ------ 🚀 SUBSCRIBE TO NEWSLETTER: https://newsletter.banklesshq.com/  🎙️ SUBSCRIBE TO PODCAST: http://podcast.banklesshq.com/  ------ BANKLESS SPONSOR TOOLS: ⚖️ ARBITRUM | SCALING ETHEREUM https://bankless.cc/Arbitrum  🍵 MATCHA | DECENTRALIZED EXCHANGE AGGREGATOR https://bankless.cc/Matcha  🔐 LEDGER | SECURE YOUR ASSETS https://bankless.cc/Ledger  🧙‍♀️ ALCHEMIX | SELF-PAYING LOANS http://bankless.cc/Alchemix  ------ Topics Covered: 0:00 Intro 4:30 Tim Beiko Before Crypto 12:27 Getting into the Space 16:45 Working for Conensys 20:56 Clients and Values 26:48 Forks of GETH 31:52 Clients as Businesses 37:42 Keeping the Balance 44:57 EIP-1559 51:47 Coordinating Core Devs 59:00 Communicating Code 1:05:17 Security 1:11:18 What the People Want 1:14:18 Who is a Core Dev? 1:21:07 Facilitating Forever 1:26:00 When Merge? 1:30:47 Closing ------ Resources: Tim on Twitter: https://twitter.com/TimBeiko?s=20  ----- Not financial or tax advice. This channel is strictly educational and is not investment advice or a solicitation to buy or sell any assets or to make any financial decisions. This video is not tax advice. Talk to your accountant. Do your own research. Disclosure. From time-to-time I may add links in this newsletter to products I use. I may receive commission if you make a purchase through one of these links. Additionally, the Bankless writers hold crypto assets. See our investment disclosures here: https://newsletter.banklesshq.com/p/bankless-disclosures 

Welcome to Layer Zero. Layer Zero is a podcast of unscripted conversations with the people that make up the Ethereum community. Crypto is built by code, but it's composed by people. And each individual member of the crypto community has their own story to tell. Cypherpunks understood that the code they write impacts the people that use it. And Layer Zero focuses on the people behind the code because crypto is people all the way down and always has been.

Today, I'm speaking with Tim Beko. Tim Beko has a similar timeline with getting into crypto as I did, got into the top of of the 2017 markets and then found his way into what niche fits him best. Started working as a client project lead at Consensus, project manager. And then eventually he hand-raised and used his position working on the Basu client to really focus on EIP-1559. And Tim raising his hand to take that effort on EIP-1559 led him into the role of being the all-core devs coordinator.

So this podcast is really a lesson in the dynamics of what it means to make upgrades to Ethereum. And very, very true to what I think Layer Zero is all about is like what code and who is proposing this code that ultimately becomes part of Ethereum really needs to be considered because the code dictates how people's lives will look. What Ethereum is will impact the people that use it. And Tim Bakos at the heart of what changes make their way into Ethereum and what changes do not. And so this is a fantastic podcast to answer the. question, are there just centralized actors that can upgrade the code? Can Vitalik just get whatever

he wants into code and upgrade Ethereum as he see fits? We've talked about these subjects directly. And then also talk about some overarching decisions and problems that will inevitably be part of Ethereum's future and what we can do to solve those problems now. Also, this is a lesson in client diversity and client development. And so just a very informative podcast. So let's go ahead and get right into this layer zero with Tim Beko. But first, a moment to talk about some of these fantastic sponsors. that make the show possible. The AVE protocol is a decentralized liquidity protocol on Ethereum,

which allows users to supply and borrow certain crypto assets. AVE version 2 has a ton of cool features that makes using the AVE protocol even more powerful. With AVE, you can leverage the full power of DeFi Money Legos, yield, and composability all in one application. On AVE, there are a ton of assets that you can supply to the protocol in order to gain yield, and all of those same assets can also be borrowed from the protocol.

if you have supplied collateral. Here you can see me borrowing 200 USDC against my portfolio of a number of different defy tokens in ETH. I'll choose a variable interest rate because it's a lower rate than the stable interest rate option, but I could choose the stable interest rate option if I wanted to lock in that interest rate in permanently. V2 also features the ability for users to swap collateral without having to withdraw their assets, trade them on un-swap, and then deposit them back into AVE. With AVE, users can do this in one seamless transaction, saving you time and gas costs. Check out the power of AVE at AVE.com. That's AAVEE.com.

Living a bankless life requires taking control over your own private keys. Not your keys, not your crypto. That's why so many in the bankless nation already have their ledger hardware wallet, which makes proper private key management a breeze. But the ledger ecosystem is much more than just a secure hardware wallet. Ledger is the combination of the ledger hardware wallet and the ledger. Live app. And if you're used to seeing all of your crypto services and favorite Defy apps all in one spot, Ledger Live is where you want to be. Not only does Ledger let you buy your

crypto assets straight from the app, but it also hooks into all of the Defy apps and services that you're used to. Using Ledger Live, you can stake your Ethan Lido, swap on Dexas like Paraswap, or display your NFTs with Rainbow. You can also use Wallet Connect inside of Ledger Live to connect to all the other Defy apps that keep coming online. Defy never stops growing. And the Ledger Live app grows alongside with it. So click the link in the show notes to see all of the DeFi apps that Ledger Live has and stay tuned as more apps come online. And if you don't have a ledger hardware wallet, what are you even waiting for? Go to ledger.com, grab a ledger, download Ledger Live and get all of your Defi apps all in one place.

Hey Tim. How's it going? I'm good. How are you? Pretty good, my man. Pretty good. Still in Seattle about to head into a plane to get back to San Diego from the holidays. Where are you at? I'm in Vancouver and was just in San Diego yesterday to celebrate Thanksgiving with some friends. Oh, bummer. We missed each other. I'm up north and you went down south and I was down south and you went up north. I see you have one of those cool NFT things. I can't remember what the name of that NFT project is in your background.

But I remember looking at that. Yeah, I think they're called Crypto Trees. So I bought it. I didn't mint it. I'm still looking for a good NFT backgrounds if you will have suggestions. This one is... You're going to get flooded with suggestions. Yeah, this one is like decent, but I don't know.

I'm not like 100% in love with it either. I feel like that's how NFTs go. You never actually feel completely in love with them, so you always have to keep on searching. Yeah. So Tim, let's go all the way back. For those that don't know, Tim is one of the lead efforts coordinating the ETH one.

So I don't think we call it ETH one anymore, but also largely the EIP-159 efforts. But let's go even further back. When was your moment that you first heard? heard about Ethereum. Right. A friend of mine told me about it, and I ignored it the first time. That was a mistake.

Second time I heard about it was in the context of the Dow, but when the Dow was a fundraising project and not a hack, and that seemed interesting. And I actually bought my first ETH to contribute to the Dow. I bought the absolute top. I think like my buy went through on Coinbase. there's always like a couple days, like literally the day before the hack happened. Yeah, so that was my introduction to Ethereum, was the Dow getting hacked. I feel like this is a great exemplar story.

Like your friend tells you about Ethereum, you ignore it, and then you buy the top. This is how people get into crypto. Exactly, yeah. What kind of experience? What was your work life, your career trajectory before crypto? Right. So I kind of started out more on the business side. I always started a bunch of projects.

When I was in high school, I had an online t-shirt company. Shopify, I don't think, existed back then, but today that would be like a Shopify store. Then I actually, I managed a painting company for like three years, like actual painting of houses. I realized that doesn't scale really well. So there's like really diminishing returns to scale with like physically painting things, got interested into tech because it seemed like something you could like scale easier. And instead of going to college, a friend and I figured out why not try and start a tech company. So we spent a year trying to start a startup, didn't work out. The idea was to try and basically Airbnb for your luggage space.

So if, say, you're living in Bali and you want something from France, we would like match you with somebody coming your way. And then you could pay them to bring whatever you want. and that was also like a horrible tech idea because that also doesn't scale really well. But learned a lot about technology and also realized how little I knew. I kind of taught myself to code a little bit while we were doing that. And when the startup didn't work out, I went back to school to do computer science instead of business. And basically did that. And then, yeah, after that, I worked as a product manager and kind of kept doing that.

It felt like a nice intersection of like being. involved in the engineering side, but also not like just writing code. So you always have had an entrepreneurial spirit inside of you? Yeah. Yeah, yeah, pretty much. Yeah. Did I extend even earlier than that or is that kind of like the early stories? I think the T-shirt business was the first thing.

And it was interesting because I was like, I don't know, 16 years old at the time or 15 years old. And it was just like so hard to do everything from like getting a PayPal account, right, because you're not a teen, you know, getting like set up on, I forget what I use for a storefront, but like the equivalent of Shopify, like all those things are quite hard if you're not 18 years old. Yeah. Was it the pursuit of capital or the spirit of building something? Like what really resonated with you about it?

Yeah. So definitely the building more. Capital was nice in that it was mostly like unconstrained, right? Like when you work a job, it's like, you know, you can work more hours or find like a, you know, slightly better paying job, especially when you're like 16 years old, your options are quite limited. And so, yeah, like, I guess working on something that's, like, self-directed, but also, like, you know, if things work out, you do get, like, a higher payoff. Yeah, I think those two things were really the gist of it. And then what made you decide computer science when you went back to it? Was it?

That wasn't your undergrad, was it? Yeah, undergrad. I guess trying to code, I liked it. I realized how little I knew and, like, how flaky everything I was writing was doing. So, you know, there's a lot of, like, debates about how, like, useful. it is to understand the theory behind like computer science versus like just doing like say a coding boot camp and I think I'm very glad I kind of started with like the boot camp approach and actually you know got to building things really quickly but after that you kind of just realize how little

you know so then going back and looking to theory and I spent a lot of time in undergrad also doing AI and that was really interesting to learn and so yeah I you know I I enjoyed kind of getting just a better understanding overall of like how these things work behind the scenes. So after you graduated with a degree in computer science and then you had some experience, you know, building, being an entrepreneur, like where did you think you were going to take that? Yeah. So one thing I realized when my company didn't work out is I didn't want to start another company

unless I knew I was like the best person in the world to do it. And it was just something like meeting like as I had my startup, I got to meet a, you know, a bunch of other founders. And to me that seemed like one of the really, not necessarily like, necessary things for companies to work, but like it greatly improves your odd. If you feel you're like in the top, you know, one or 0.1% of people that can actually tackle this problem. So I'm, you know, I was and still am kind of fine, you know, not starting a company for its sake, but waiting until there's something where I'm like, well, nobody else can kind of do this better than I can, right?

Or, you know, the vast majority of people can't do that. And so, yeah, yeah, and I also realized while I'm, well, I'm. I was kind of running my company, you know, we were like a startup of three. I didn't have like a good feel for like, what does like a successful 10% company look like? What does like a successful 50, 200, you know, 10,000 person look like. So during my undergrad, I tried to intern of like a bunch of different sized companies to like get a feel for like, you know, what do they look like. And then after my undergrad, I basically went to like a midstage startup for a year working on AI. and that was, I think, late 2017, early 2018.

By that point, I had been kind of following Ethereum again, like, pretty much. But there's not a lot of jobs on Ethereum if you're not an engineer. So an AI kind of felt like a better kind of career path. So, you know, I worked in AI, kind of followed Ethereum on nights and weekends. And at some point, just started searching for a job full time in this space. I got just really bored of it after like eight months. months. And so I was looking at any Ethereum job I could find. Yeah. What was the process of like work Ethereum balance for you before you got your job in

Ethereum? Right. Tell me about that. So if I have to describe it quickly, it's like booking your conference room for yourself and like reading the beige paper, you know, like you're doing crypto zombies. So I would try to like if I wasn't too busy at work, you know, take time there to like, you know, study your read up on interesting things, spent a bunch of time on the Ethereum subreddit, the quality there was quite high. And I didn't actually go to like Ethereum meetups. Like there weren't a lot of them in Montreal. But I managed to get my AI company to pay to send me to a blockchain conference in Austin.

And then when the first East Berlin happened, my goal was to go there and try. I bought a ticket for East Berlin, a ticket for DevCon. And I was like, I'll just go to those places and like get somebody to. to give me a job. And I was really lucky that I actually landed my first job right before going to East Berlin. But that was kind of my plan. It was like in person.

It'll probably be easier to like meet these companies and and yeah, find, find a good fit. So this was in 2017-ish, right? Yeah, late 2017 early. I guess Eastburden, the first one was in 2018. So I kind of started looking, you know, late 2017. Again, probably like right before the top. And then kept looking throughout like the first half of 2018 and got something a bit

later in the year. Yeah, no, our timelines are about the same. So why Ethereum? Because in 2017, like, there was everything, right? Like, there was Eos. There were a billion Bitcoin forks. Like, why Ethereum? You know, I'd known about Ethereum since, like, the Dow and just the project really

resonated with me. It did seem like it was trying to build something like genuinely new. I, you know, I'm just like not that interested by, say, like, Bitcoin Forks, you know, where they, like, tweak a parameter and, like, you know, kind of derivative projects. So I, and I don't know, in 2017, aside from Ethereum and like Bitcoin, and maybe a couple smaller ones like Monero or stuff like that and Zcash, there weren't like a lot of actually legitimate projects. And I also felt the risk reward of working on, say, like an ICO project was pretty bad.

And that's kind of what got me to decide to work out of Ethereum full time is when there was this ICU boom, I was like, you know, all these projects might fail, but clearly it shows there's like demand for Ethereum, right? Like, there's demand for like using this platform. And also the thing that I realized was like how kind of broken Ethereum was. Like, I don't know if you remember then, but like ICOs could like plug the MMP pool for like two days or something like that. And it was like really hard to get a transaction in. And I was like clearly there's a lot of work to do at the protocol level. There's like some demand for the protocol itself. And all this stuff built on top still feels pretty speculative. And I was not, I didn't feel like I knew enough to be able

to say like, you know, this is like a project that is actually going to make it. Yeah. So, yeah, Ethereum just felt like, I don't know, like the platform where there was like the most actual activity innovation happening on it. And in a spot where there was still a lot to do to actually improve the protocol. While you were going through this 2017-28 journey of learning how to get into the space, were you more of like a lone wolf or did you have like company like a friend to go with you? I remember in 2017, like I had like five or six like friends in a group chat.

right and so like that we all kind of shared knowledge what was your dynamic like that no like yeah like yeah the exact opposite like completely alone yeah there's like one guy who told me about ethereum and bitcoin and like we're not like close friends so like you know i you know i i like message them probably 10 times in the span of three years about it but like yeah no i didn't really have anybody i knew interested in to that and i feel like that it was also kind of true when you were building your businesses your early businesses when you were first experimenting with being an entrepreneur Were we also a lone wolf then too? More or less, like, a lot of them had co-founders

or I had friends involved in that or made friends through the process. So I think, you know, a lot of them probably started with me more or less alone, and then, you know, I kind of brought people into it. Yeah. What was your first job in Ethereum? So I got super lucky.

Consensus was just starting your protocol team and they needed product managers. So actually, I tried, I think it was like early in the year, I applied, I interviewed, and they're like, we're kind of looking for a product lead and not like a single PM. And we'll call you back if like we ever hire single PMs. And I thought they were just being polite and like say no.

But actually did call me back like four months later. They're like, well, we hired a product lead. Now we're looking for actual PMs. Are you still interested? I said yes. So it was just like such a perfect fit. And at that time, consensus was building a client from scratch. So I basically joined right after they had like the call it the V1, but it was really

more like a V0, like a very basic client. that could sync the mainnet, only had full sync, was only an archive node. So aside from working in theory, it really didn't do a lot on main net. And then over the next couple years, we basically got to build that and add kind of all the features you expect in like a standard Ethereum client,

like fast sync, pruning, all the JSON RPC support, tracing and all that stuff. Did this client have a name? Yeah, so it was called Pantyon. It's Basu. Oh, yeah. Yeah, yeah, I remember it. Yep, yep, yep.

Yep. And it still exists today, yeah. Right. Did you feel like equipped or like qualified to be able to do that? Like was that a challenge for you? Right. So I'm not sure there were a lot of people who would have been like 100% ready. I thought I, you know, I'd say probably 50% there.

My biggest like surprise or learning when I first started is I assumed I could like read the spec, you know, like the yellow paper or the beige paper. And like, that would be like 80% of the actual client, right? Like, these are like the rules of a theorem. But it's more the opposite. It's more like 20%. And like 80% of stuff in clients, like, for example, Fast Sink doesn't have a spec, right? Like the spec, there's like a PR on Geth that explains how it works. But it's like, yeah, there's so many things that are kind of like that where they're not,

or there may be specified somewhere, but you really have to know where to look for. And it's quite obscure. And you kind of have to learn by like either using the other clients or, you know, like trying to understand what they did. So, yeah, you know, that was probably the part where I had to like ramp up the most, was just, you know, understanding all these parts of Ethereum that are like specified in weird corners of the Internet. And is that true just because of like the chaotic nature of Ethereum?

Just it was a young ecosystem. People weren't really writing stuff down. Like, why was that true, do you think? Yeah, I think that's part of it. I think the other thing is maybe like you don't know in advance what, what will be like the popular feature. So, for example, like, SNAP sync, or sorry, fast sync is what Get implemented in Parody at the time had Warpsync. And SNAP sync actually turned out to be, sorry, fast sync.

Snapsing is what they have now, so I keep referring to that. But fast sync just turned out to be like the better of the two. And so everybody kind of converged towards that. But like when they were implementing it, you know, we kind of didn't know that in advance. And for example, for tracing, it's the exact opposite. Parity's tracing APIs are actually the ones that everybody, say like ether scan or exchanges use, and then the geth ones are less used.

And so, yeah, same thing. It's just like, you know, people kind of didn't necessarily know in advance which one would work. Or also like how people would use them, right? Like there's a bunch of like quirks and like tracing APIs like, you know, how you want it. Like figuring out if a transfer has actually happened can be quite hard. If it's like a smart contract that's, say, sending in the RC20,

you actually need to run through everything and make sure it doesn't revert and only then can you actually mark say the tokens is transferred and so over time people like exchanges or block explorers they just gain really deep familiarity with these APIs and they know all the quirks around them and how to handle them and like

yeah these things just become kind of cemented as like the standard even though they didn't set out to be used like that or used so extensively basically one of the things that me and Ryan are particularly obsessed with those are like, and the broader Ethereum ecosystem are like the values of Ethereum. And when you start to like build out a client, is that way you start to become related

to those things, like building out a client and also like making sure that Ethereum like retains the values that it was originally purported to have? Like was that a relevant conversation when you were building out this client? Yeah, I think the biggest one is like, you know, all core devs is probably the place where that like plays the biggest role. And I think the questions we had at Basis specifically is like, you know, given basically was funded by consensus and consensus is like a big organization in the space like, you know, should like our views reflect, you know, consensus's position every time?

Should you have people kind of reflect their own views? Like how do you, how do you make sure that like you build this in a way that's just aligned with the other teams? And so, yeah, I think we weren't, you know, super explicit about like, okay, what are like the values we want to embody as much as just like what the like every interaction we have like how does that reflect you know is this like a net positive for the ecosystem um yeah so i think it's yeah it's kind of all these small decisions of like how you act and like you know the the battles you picked and the things you know kind of when are you when are you willing to just like you know let others win and and and it's like the hard part about the theorem like we have you know four clients and they all have

like different tradeoffs that they make and sometimes you know some feature can be like harder for you to implement because of your architecture or stuff like that. And just thinking about like, okay, how do we make sure this all works when we disagree with people? Like, how strongly do we want to express that? And, you know, overall, like, does this make Ethereum better? Or, you know, does this just benefit us?

And I think we've tried to be really mindful of that. And the team still is. So I'm no longer there. But I think they still do like a really good job of that. So it's less about like the Ethereum values and more about just like the technical details of like, if we build this in this way, will that trip up other clients that build it in a different way? Yeah.

But I think, yeah, I think one of the big values is like decentralization, obviously. And like having multiple implementations was always something like that was important to Ethereum. And it was pretty critical like in 2016 when there were the Shanghai attacks. And even now, like, you know, if one client has a bug, it's great that we can have others kind of pick it up. Even more so with the merge with the fact that like staking penalties are like anti-cornerated. So I think it's just like this idea of like decentralization and like resiliency is probably the one that like as a client team you spend most of your time thinking about. And that's like another interesting conversation like, you know, how much time or how little time I guess client team spend understanding what's happening on Ethereum. Especially as it grows in complexity.

Like you literally can't understand everything that's being built. So just trying to figure out like, you know, where do, where do. On what, like, Ethereum value, can we have an impact and, like, you know, how do we make sure we do a good job there? Yeah. Do you remember, like, a particular, like, decision or issue that had to just, like, really be unpacked, like, for a good example for the listeners, just so they can wrap their head around, like, these small choices that had to be made, what you would have to consider

and what that process was like? Sure. So I can go, like, very technical, like, much more broad, but, like, the very technical one, for example, is the eth-networking protocol. So the format by which nodes communicate with each other. So when they send a new transaction, how is that formatted? And this is like, you can think of it, like how nodes talk to each other on the network. The four, you know, these formats all have like assumptions embedded into them and we improve them.

And oftentimes if you want to create, say, like a new sync algorithm, when you're syncing, you're basically asking a bunch of nodes on the network for data about the network. So this is where things change a lot. And I think there's a lot of time where, like, geth has been, like, building new syncing algorithms, and they've, and supporting these networking formats is something that adds, like, a lot of technical debt to them. And they really benefit when other teams kind of drop,

you know, are able to also quickly deprecate that so that they can just, you know, refactor their code and make their syncing work better. So that's an example where I think we've always tried with the Basu team, even though we might not be implementing the same syncing algorithm as them for like another year to try and see, okay, how can we prioritize this thing? Because it helps them. Another thing that's really basic is just like adding testing infrastructure, right?

Like the EF maintains a lot of the Ethereum testing infrastructure, and it's really valuable when other client teams are able to like spare some resources to help improve that. And that's one thing we try to be mindful about. bit more high level and probably relevant to like most of your listeners is like EIP 1559. So when we decided to start working on that, it felt like something where we had kind of the skill set in the team and we also had the bandwidth. And like literally nobody else in the client teams had, they all had the skill set obviously,

but they didn't have like the bandwidth to do that. So that just felt like something that was like super valuable for Ethereum where there was a lot of work that could be done. And we knew that like we could do a lot of the work. you know, ourselves and then get it to a point where it was like a bit more ready so that when we started involving other client teams like the, you know, the foundation has been sent. And that was stuff like obviously implementing the EIP itself, but just like building tools to test it better and stuff like that. So yeah, that was probably one of the biggest one in the

past couple years where like I think we were able to really have an impact. I've always thought like the position of being a client dev is really, really interesting because is there's a little bit of like evolutionary fitness that goes into clients, right? Like bad clients drop off, good clients, you know, become downloaded more. And the cool thing about crypto is it's all like biomimicry, right? And so whichever client can get themselves replicated more is therefore a successful client. Yeah, at the same time, like clients can't be in too much of a competition with each other because you don't actually want one client to have a monopoly, right?

You don't want one one little organism to dominate the whole entire ecosystem. because then the whole ecosystem will die off because you can't have centralization on one client. So I've always thought it's like there's this tug of war between like you want to make the best client, but you can't make it too good because then you then you smother all the other clients. What was the conversation? Is this a conversation with client teams? Yeah. So we've had this.

I think every team kind of agrees they're not going to make their client worse. Right. Like so, you know, like whether that's like the get team or, you know, Aragon, like they're all, you know, say very good. on certain aspects. Like, I don't think any team is willing to compromise to, like, make their client worse, you know, for, like, the sake of client diversity, just because, you know, at the end of the day, we do want, like, to offer a good product for the users. I think what we often compromise on is, like, making the client better, but slower, right?

Like, it's like, we have, we all have, like, these roadmaps for what we want to do, but then if other people kind of have other stuff that's really important to them, you know, we're sometimes fine just like, you know, not not doing something, but just making it in a way that, you know, gives others time to adapt and stuff like that. And for example, you know, like this happens a lot. Say with the Aragon team today, they have like a completely different architecture. And so oftentimes, like, if we can do things that like allow them to implement that better, then I think we really should try and do that. and because even though they might not be the most popular client on the network today, they're potentially the most popular client in like three years.

And leaving the room for that is what allows us to have people who come in and decide they're going to build a whole new client. And I wouldn't be surprised after the merge kind of the assumptions around like what the network should provide and what's not kind of change. And there might be a new team that pops up and that's like, well, you know, we're going to build a client who like doesn't care about anything before the merge. You know, if you want to validate proof of work, sorry, we just don't support that. But we can be like really optimized for validating everything starting from the merge, for

example. And I think it's really valuable. You want to leave the space for that because this is how, you know, we keep having like better core infrastructure for Ethereum. And I'll add a note, like I'll shield the clients a bit more. Like when when you hear about like Ethereum killers or like, you know, especially EVM compatible Ethereum killers or even like roll-up solutions. A lot of them reuse clients from Ethereum.

Like a lot of them, you know, will just fork geth and like build their whole kind of basically network around it. Tron, Avalanche, optimism are all forks of geth and polygon as well. So I think that shows you like how good the software actually is. And we want to make sure that, you know, we keep this software really good. But at the end, we give the space for people to come in and build even better software on the foundation. And for example, Aragon, which used to be called Turbo Geith is a client that, like, stores data in a much more efficient way. But that also started as a fork of Geith.

And now, you know, they still can bring some changes in, but they've made like major modifications. So they're, I'm not sure it's like, it's fair to them to call them a fork of Geith anymore. But they definitely started out as that. And yeah, I think it's really valuable that we leave the space for new people to come in. and improve on this stuff. I want to keep on going on this conversation, but since we touch on it, like,

why is everything a fork of geth? Like, why guess? It's just so good. And so I guess a couple things. So I guess is extremely good. It's also the oldest still running client. So there's a lot of, you know, people who are knowledgeable about it.

I think the license is quite friendly. And, and yeah, like also people probably expect that it's going to be maintained forever. Like, for example, parity was very, very popular as well. And the original team kind of walked away from it. And there's been others who've, like, attempted to maintain it. But like, it's a really hard job to maintain a client. And so it's, you know, even though some teams, you know, can commit a few engineers,

it's, there's like uncertainty about like, well, will this thing actually still be there like in five years or am I going to have to move off to something completely different? And I think the Get team has like shown that, you know, they'll, they've been, since basically the start of Ethereum and they'll probably be there, like, up to the end of Ethereum. So isn't this just like a massive public goods problem with, because like if we need these clients to be maintained basically until Ethereum dies, like, how, how do we expect these clients to just be maintained for the next like, you know, multi-generation timeframes?

Right, right. So I think luckily, like the space has grown in terms of funding. And I think what regards to. to just like basic maintenance, like think about it like paying maintainer salaries, we're probably getting into a spot where it's, it's, I wouldn't say easy, but like, it's a manageable problem. So whether that's like, you know, through large grants, either from the EF or others, uh, or through clients have, you know, working with say layer two teams or whatnot, um, that can then get paid for that work. Like, I think there's, there's more and more options

where like, you know, starting a client can be, say, like a profitable business. business in a way. I think the biggest challenge and something I, you know, I want to spend more time on is aligning the incentives so that the risk reward of working on a client is, is better. So right now, you know, most client teams, or most client teams like devs at best have, like, equity in the company they work for, right? Like, everybody who works at Nethermind has, like, Nethermind equity. Everybody who works at consensus has consensus equity. But that's like a very indirect, like value creation to capture mechanism. And there is like obviously some amount of risk to work on the protocol, but it's less than

like starting your own, you know, DFI project, for example. You're not like starting from scratch. But I still think that the kind of reward for working on the protocol, which is, you know, from zero pass your salary to like some equity in some company that's like tangentially related to the client and also not necessarily correlated with like Ethereum's rise. That's like way too low. And so what, you know, the risk is that people are able to take like a little bit more risk.

So they go from like working on the clients to starting their own D5 project, which is obviously riskier. But then instead of getting, you know, 10 times the reward or like five times the reward, they get like 100 or a thousand X times the reward, right? And so what I really want to make sure is like that we can. create mechanisms where we can have some like rewards for these people that's correlated with like the overall growth and adoption of Ethereum. And what this could be in practice is something like, you know, asking projects to like donate

the percentage of their treasury, you know, when to some fund that goes out to client developers, for example. And something like that where like if you can get new projects like that are just starting you out to have like a social commitment to that, then. you know, a subset of those projects will be really successful, and that kind of provides some upside to the different people working on this stuff. Obviously, once you get into the weeds of it, there's like a ton of this details about, like, how do you, you know, how do you decide who's in, who's out of the list, you know,

how do you white people, how much do you ask for projects and whatnot? But like generally, I think this idea of like, if we could get projects to provide some sort of like upside contribution or fun, that would help make working on a client like a much better risk-reward kind of proposition. And it'll never beat, obviously, starting a successful defy protocol. But, like, doing that is also taking way more risk. And I suspect there's a lot of people who'd be happy would just, you know, like, slightly better upside, given the risk that they already take.

Yeah. So that's one thing I think is really important and where the community can really kind of innovate on in the next couple years. Is there a world where it doesn't have to rely on, like, donations or contributions, but there's actually a way to, like, turn this into a business. I know, I'm pretty sure, like, it's, like, blasphemous for a client to, like, have some sort of, like, you know, fee in it, right? Like, but, but is there any way to... So, so a lot of them, a lot of them have businesses, but the problems, like, those businesses are, like, they capture such a small percentage of the value.

So, for example, like, a very common business with, like, uh, two or, like, you know, consensus clients is, like, you can offer professional support to, like, staking services, right? Like, consensus does this. And I'm sure, I'm not super familiar, but, like, I'm sure. basically every team will do this. It's like if you're Coinbase and you want to use, you know, consensus as client, you can get like, you know, enterprise level support. And consensus obviously generates revenue from that. And I think this is why I was saying earlier. Like, I think you can build a sustainable business into starting these clients, but you, but they don't have token gains, right? Exactly. They don't have like the exponential upsides that you see in like a lot of crypto native stuff. And I haven't seen like a good proposal to like embed that in clients directly.

that doesn't require, say, like, you know, on-chain allocations, the dev funds, and I don't think that's something we want to do. It starts to feel like a cartel, right, at that point. Exactly, right. Yeah, yeah. And, like, I would be very uneasy to have, like, something on-chain that, like, sends funds to a bunch of addresses or to one addresses that just seems. And there was a proposal for it a couple years ago that got shut down pretty hard.

So I don't think we'll get, we're not going to get funds from the protocol. And I think the revenue is nice, but it basically pays for the salary. And it's almost like we need some. mechanism to pay for like the upside or like the equity and that's like the bit that's missing. And yeah, donations totally might not be the final or like the best approach. If people have suggestions, send them to me. I'm happy to try and to try and get those working. For a thought experiment, for example, say we figure out as an ecosystem how we do actually

attach the upside potential of a token to building a client. And then say again in this thought experiment that we successfully figure that out. And then all of a sudden, clients and tokens are paired. And then like we have some sort of just like mania where like, oh, I can like make my token go a thousand X by starting a new client. And then we go from having like a handful of clients to like hundreds and thousands of clients. Is that a problem if we have like hundreds and hundreds of clients? So I think, you know, the easy solution to that problem is like you time gate it.

Right. Like so you time and feature gate it. So you say, you know, your client has to. be live for a year and like the if you want to build a new clients, you know, come see the EF's grant program or some other, you know, Molluk Dow or something and like, you know, we'll give you funds to like actually try this and prototype this.

But like I think if you have any that sort of mechanism, you require clients to have been live for like X amount of time. And it's like extremely hard to start a client. So like most people will give up before a year, I suspect. So, and I don't know, maybe like a year's too short. Like maybe it's two years. I don't have a strong opinion. And then you like feature gate it as well.

It's like, well, can you like sync the mainnet and like process these blocks? Like or, you know, post-merge, can you like be a validator? So there's like a couple of things that like, and say if you're a validator, like, can you like keep these metrics, right? Like can you like attest to like X percentage of the blocks? Can you propose blocks on times? And I think it's it's not that hard to define like the baseline for what a successful client is.

It's quite hard to build it. and there's been, you know, probably 50% of teams who've tried that, like, have not made up to, like, this bar historically. So, yeah, I think that would be the way to go. And, like, and then, you know, if we have twice as more, like, there's a, you know, there's a discussion to have, like, you know, how much do we need? And does it bring you extra efficiency or not? And that feels like kind of a happy problem. If, like, the problem we're having is, like, too many smart people want to work on this. You know, I'm sure we can figure out a way to have them work productively.

I want to pick up the client diversity line again because are there conversations in the very, very, very, very long term, like 50 to 100 plus years about the inevitable centralization of Ethereum onto one client. Do people think that ultimately one client will kind of win out? Or is there like a conversation that like, oh, we can, we just need to be able to balance it just enough? Right. What are like the long term thoughts about client diversity in the very,

long term. Yeah. So I'm sure people like have very different opinions. So like I can speak to myself, like in what I see. But like it's so one of the challenges with like not the very long term, but say like the short to medium term is like people have like a really strong sense of pride in what they built. Right. Like so people who build a new client, they're not going to like pack up and go home and like be like, okay, I'll just like work on geth instead. Like people put like, you know, huge amounts of resources and efforts into that. And so I think they, they want to make it successful. So I think there's like this,

this, I don't know, like inherent, like motivation for different people who started these projects to keep maintaining them. You know, I think I would be weary of only having, like, a single client, like, in the future. Like, if you told me that, like, I don't know, in like 50 years we have, like, two or three, that seems like less bad.

And the challenge is, like, if one client goes down and has a bug, then like the Ethereum network basically stops working right and and again that's maybe something that like we change your mind on as a community but so far we've had like an extremely strong bias on Ethereum to like the chain doesn't go down right and Ethereum's been has had like a higher up time than Bitcoin the Bitcoin chain has like very early on in its life you know stalled for a while they put out a budget fix like that hasn't happened on Ethereum and and I think there's especially like as more and more economic activity.

gets built on Ethereum, right? Like, you, you, what we're selling, basically, the people building on Ethereum is this, like, settlement layer that does not go down and that you can always rely that, like, you know, post-merge every 12 seconds. There's a new block that comes in. And if for some reason the chain had to go down, like, for two days or, like, even a day, and this is, this is like the, you know, the amount of time you'd expect, like, an A-plus engineering team, if there's a bad bug to, like, wake up in the middle of the night,

find what the issue is, fix it, test it and ship it, and get everybody, you know, to update their nodes. You know, realistically, you can't do that within like less than 12 hours, probably. And like, if the Ethereum chain went down for 12 hours, that'd be terrible. Like, just think today, you know, what would happen with like defy? What would happen, you know, with like all the businesses who like rely on being able to accept payments with all the insurance that's like on Ethereum. And if you look out five, 10 years in the future, it's like if Tranfai is selling you on this, imagine it's like market close in the U.S. or in Asia and like, you know, you're selling for the day and like Ethereum's down.

So like if people had to like expect Ethereum to be down, I think you take away, you know, 50 plus percent of like Ethereum's value proposition. And so I think we really want to be in a spot client-wise where like this can't happen, right? And I'm not sure what the right number is. it's definitely bigger than one. I think it's also bigger than two. Like it's not 10 or 100, but like somewhere in that range,

I think is really healthy. And I think it becomes even more healthy after the merge because some of these bugs can have impacts on like people's stakes, right? So if there's just one client and there's a bug in it and the chain goes down, you know, you basically, you know, can lose people money that are validating on the network. And that's also something like, yeah,

It's a big part of the value proposition. Like, you can be a validator and earn income. And if you do things right, like, you shouldn't be penalized. So, yeah, I, yeah, I know, this is my opinion. Like, some people might disagree. And I also think, yeah, if we want Ethereum to keep innovating in, like, 50 years, the way to innovate is often to build something new. Because, like, for example, Geth could not build what Aragon has built just because they need

to support all the current Geth users. So, like, new teams are able to kind of leapfrog and kind of, you know, if in 50 years we have like all zero knowledge based Ethereum, I suspect we'd have a client that's built to like support zero knowledge proofs like from the core from day one. And that would be way more efficient than whatever zero knowledge implementation is added to geth. Just because you can take all the decisions making those assumptions. So yeah, I think we'll always keep a few.

It's really important for the resiliency. I don't know. Some people might disagree with that though. I definitely want to get into the zero knowledge conversation later. but I also want to pick up on Tim's story. Hey guys, I hope you're enjoying the show with Tim thus far. In the second half of the show, we are getting into the details of what does it actually mean to make changes to Ethereum?

Who actually is a core dev? Am I a core dev? Are you a core dev? Some interesting conversations, some interesting thought experiments coming up in the second half of the show. Before we get there, a moment to talk about some of these fantastic sponsors that make the show possible. Alchemics is one of the coolest new defy apps on the scene.

It introduces self-paying loans, allowing you. allowing you to spend and save at the same time. Deposit the die stable coin into the Alchemics vault in order to get an advance on the interest it generates. Borrow up to 50% of the total amount of your deposited dye in the form of Al-USD stable coin. Here's the craziest part. The loan pays itself back and you cannot be liquidated. Unlock your assets potential in the ultimate Defy Savings account. And brand new to Alchemics is the ETH vault where you can deposit ETH into the application.

borrow Aleeth against your deposits while having your advance gradually paid back over time. V2 is rapidly approaching, which will allow for even more collateral types, plus a variety of yield strategies to choose from. Harness the power of Alchemics at Alchemics.fI. That's A-L-C-H-E-M-I-X.F-I. Follow Alchemics on Twitter at Alchemics FI and join the Discord in order to get involved with the Alchemics community and also Alchemics governance. Arbitrum is an essential.

Ethereum scaling solution that's going to completely change how we use Defi and NFTs. And now it's live and has over 100 projects deployed. Gas fees on Ethereum L1 suck. Too many people want to use Ethereum and it doesn't have enough capacity for all of us. And that's why teams like Arbitrum have been hard at work developing Layer 2 solutions that makes transactions on Ethereum cheap and instant. Arbitrum increases Ethereum's throughput by orders of magnitude at a fraction of the cost of what we are used to paying.

When interacting with Arbitrum, you can get the performance of the same. centralized exchange while tapping into Ethereum's level of security and decentralization. This is why people are calling this Ethereum's broadband moment, where we get to add performance onto decentralization and security. If you're a developer and you want to save on gas costs and overall make a better user experience, go to Developers.offchainlaps.com to get started building on Arbitrum. And if you're a user, keep an eye out for your favorite Defy apps being built on Arbitrum. Many DeFi applications on the Ethereum L1 are migrating over to layer 2s like Arbitrum, and some are even skipping over the layer ones entirely and deploying

directly on layer 2. There's so many apps coming online to Arbitrum, so go to bridge.orghum. Now and start bridging over your eth or any of the tokens listed, and start having the defy or NFT experience that you've always wanted. Tim, you came on a lot of people's radar because of your efforts on EIP-1559. Can you talk about the transition from working on Basu into EIP-1559? You touched on it a little bit, but just keep on going down that story. Yeah, so I kind of mentioned earlier, like, you know, at consensus, we always tried to think about, like, what are things we can do that really help the community and that, like, we're maybe uniquely positioned to do. And 1559 kind of fit that bill perfectly because it was like a huge effort.

Like, we knew getting into it would be huge. We underestimated all big, but we, we knew it would be big and bigger than we estimated. And we also, like, you know, we wanted people to use Baysew. So we were like, well, if we're the first ones to get like a test net with 1559, you know, people want to try that and it'll be it'll be good for us um and we also saw like you know no one was really working on it so like there had been some original efforts done but the team had kind of stepped away um or you know they they weren't super like it was it was like missing momentum basically um and um and it seemed like something that was just uh mostly like desired by like a very large part of the community like it was somewhat contentious but like it felt

like an, I don't know, 80% bet that like this thing will actually make it on chain, assuming it's safe. And finally, also, yeah, sort of knowing when 1559 was first presented, the Get team, like, basically had a bunch of technical issues with it, and no one had, like, really addressed them. But we have, like, a really clear list of, like, problems to solve. And so, yeah, so we, you know, we decided to take, like, one or two engineers, have them, like, look into it really deeply at first to understand, you know,

are we missing something here? And then, you know, we just started kind of prototyping it. I started running calls with, like, the people who had been involved in the past to see, like, you know, like, what have you guys done? You know, what were like the blockers? What are like the things we're missing to get the main net? There were a couple, like, really big changes we made to the spec that really helps simplify it. So, for example, the original 1559 EIP had like this transition period. So it was like, we're going to have a hard fork.

And like, on the hard fork block, you're going to start with like 1%. of transactions in a block can be 1559. And then over like six months or a year, I forget, you know, you'll have 100% or maybe 99%. Like you always leave a bill of room for like legacy transactions. But you kind of transition this way. And that was super complicated because like we would have clients maintain like two different memples, one for 1559 transactions, one for normal ones, have to create a block and like you need to like cross check them. And if we got to the spot where we wanted to like actually deprecate legacy transactions, you have this problem. of like somebody signed a transaction five years ago.

They walked away in the woods and like now they come back and they want to submit it to the network and like they can't because, you know, we've bricked it. Ah, right. So that's one thing that like even though in theory it might or in practice it might not matter much like in theory felt very important to keep this property. Like if you've signed an Ethereum transaction, we shouldn't like lock you out of the system. And so Micah Zoltu found like a really smart way that we could convert legacy transaction. to 1559 one, where we set the gas price to both the max fee and the priority fee.

And that allowed not only to solve that problem, but also to simplify the spec hugely because then we had a way to have a single mempool and you can just like treat all transactions as though they were 1559 style transactions. And, you know, like we just spent like a year basically, that was one of like the bigger kind of, you know, fixes to the spec, but we spent like a year going over. this and trying to figure out, you know, what are like the problems here or how can we fix it. The other huge one was there was no proof or like analysis that showed 1559 actually worked.

Like everybody who, yeah, everybody who like had specced it and like looked at it from the client's side kind of understood intuitively why it would work and why it was a better system. But like some people were uneasy. They were like, well, you know, what if we're wrong? and so basically there was And this question is about like we don't really know until we see it in action and we can't really know ahead of time

is that kind of the issue? No, it was more about like the economics of it like we don't know if this is like a sound economic system and like when you think about it you're like it it sounds like it but like we were scared that like some economists would just look at it and be like

oh no this is absolutely broken like you know somebody will do this and like you know kind of bypass the system And so somebody basically helped and hired Tim Rothgarden, who's a computer science and game theory professor or economics professor who specializes in game theory. And he basically spent three months with his team researching 1559 and trying to come up with a formal proof of model of like, does this actually meet the goals that it's intending to? And he published a 50-page paper, the TLDR of which was yes, it basically does. Yeah, and that was hugely valuable because at least there was something we could point to that was like, you know, somebody with like deep expertise in this field who also understands Ethereum, like, you know, was able to analyze this and like there was no like massive shortcomings in it. So it was just like, yeah, spending the time to doing all this.

And towards the end, we got to a spot where like we were actually ready to put this on the main net. And I think there was more work around like trying to educate the community around like what 1559. does and doesn't do. So I spent a bunch of time, wrote a bunch of articles trying to explain that and, like, you know, what can people expect? Like, for example, like, you know, people thought 15-269 would, like, massively lower transaction fees on Ethereum and just trying to explain, like, what does it actually do to transaction fees? And similarly, you know, there was a lot of talk about, like, minors and how would minors react? So I spent a bunch of times working with folks not only to analyze that, but also to, like, talk with minors and, you know, try to explain to them this change.

and trying to explain to them, you know, other revenue sources that they could get and like how to prepare for that. Yeah, so it was a lot of like very technical work at first and kind of transition to more like community outreach and just like a lot of explaining 1559. So a lot of your EIP 1559 work came through working on Beesu? Yeah, yeah, basically. And it was extremely helpful to be in that position because I had a dev team. that could actually write the code, right? And then you actually transitioned into a different role in Ethereum. How long after did that happen?

Yeah, so basically, I think I'd been a consensus for two and a half years or so. And I was always, like, involved in the awkward devs call because I was on one of the client teams. But I was also kind of the less technical person on those calls. Like I was kind of the only non-engineer there, basically, alongside Hudson. And sometimes, you know, other folks show up like Pooja and, James Hancock was there also earlier on. But like, you know, the call is basically 90% engineers and then like some kind of people

like us who are more on like the project and product management side of things. And towards basically the end of 2020, I was talking with Hudson and he mentioned, you know, he had been doing this for, I think, five years up to then and wanted to move to something new. And, you know, that just felt like such a great opportunity. like it felt like something where I knew kind of, you know, how awkward devs worked. I think I had some ideas about like how we could potentially improve it. And also like my time, like my opportunity cost for doing this wasn't that high. Like you don't want an engineer to run awkward devs.

Like you want them to like write the code. So I was like, I'm one of the few people who like understand how this whole thing works. But also I can't actually write the clients. So like the next most valuable thing I can do is is try. and manage or run this whole thing. And so, yeah, I got to talking with Hudson, and it seemed like a good transition. One thing the EF was super mindful about is they really don't like taking people from projects and, like, bringing them into the EF.

They really want to, like, you know, push many projects to thrive. So one thing we did was I took basically six months to transition out of my role at consensus so that we could hire somebody new and train her, who's basically, the new product lead for Basu today, Sejida. And I kind of started working part-time at the EF and went part-time at the consensus once we had hired Sejeda so I could just, you know, kind of help onboarder. And then, yeah, over basically, I think it was around March, I was just like full-time at the EF and no longer had consensus.

For the listener that isn't familiar, which, I mean, includes me at this point, can you just like TLDR explain like M5 what Hudson and now your role? is with the EF? What is it that's really happening? Right, right. Not super easy, but like, so the main thing is every two weeks, there's this call where all the different client developers get together to discuss changes to Ethereum, right?

This is how we plan, you know, network upgrades, how we discuss, you know, new EIPs and whatnot. And you need like a moderator for this call. So that's kind of my job. Like a very basic level is like every two weeks, I sit on this YouTube. call and I, you know, try to make sure that we, you know, we get through all the topics. From there, you know, to make sure, like, those calls generally go well, I spend a lot of time thinking about how can we make, you know, client development like a sustainable and, like,

thriving thing. And so that, you know, that includes things like working on grants programs or just, you know, talking with the teams and organizing workshops when we need to. So just like, you know, making sure that like the kind of working environment around this is good. And then the other half of my job is basically explaining all the stuff that we do to like the broader Ethereum community. And so stuff like this podcast or like, you know, writing these tweet threads that I do or writing articles, just trying to like take what we spend like all our time on and make it accessible to somebody who's like obviously familiar with Ethereum.

but doesn't want to spend two hours every two weeks listening to this call and trying to dig through like EIPs and pull requests and whatnot. So yeah, I really see it's kind of like twofold, like internally work with the client teams, make sure that like we're, you know, we have a roadmap for Ethereum. We're executing on it and like trying to like unblock the biggest blockers, whatever they are as they come up. And then kind of sharing what's happening with the broader Ethereum community so that they can have like a feeling for what happens. And obviously you can participate. If there's something that they support or disagree with, then my hope is like, somebody can just like skim my tweet threads and be like, oh, man, this is like a terrible idea. And then like engage on this like one specific issue rather than to have to like listen to all the calls

all year long and like the hope that, you know, nothing goes wrong. Right. So you're a relayer between the community and all the client teams. Right. Relating the data. Yeah. And then both ways, right? like, hey, client teams, like, the community has these concerns.

Or, like, hey, client teams, like, there's this thing called the IP1 and 559 that the community really, really, really likes. Yeah. And then probably vice versa, too, right? Yeah, and I think that's giving me too much credit. So it's like, if I had to simplify it, I think I'm a better relayer from the core devs to the community. And we've actually hired somebody to do kind of the opposite.

So Trent Van Apps works with me closely. And if I had to describe, I'd say he basically does the opposite. that he's like better at going to the community and get into their opinion and bringing it back. Or like if we have something that really affects kind of the community, like he helped a lot with 1559 and now with the merge, for example, trying to like reach out to like all the projects. Yeah, so it's basically two full-time jobs. One is sending the information out and the other one is getting the information.

Yeah, and we obviously work outbound and inbound. Yeah, yeah. And we work really closely together. Yeah. That's cool. So like, what's that like? Like what's it like to work with all of the client teams? Like are,

because they're all engineers, right? And so like the, they're engineering type that, like the meme is that engineers, they're really good at code, but they're not really good at communicating. And sometimes they're all kind of like lone wolves. Like,

what's that experience like? Right. I think most teams have like some people who like are actually pretty good at both, who are good on like the engineering and like the more project management level. And typically they'll like self-select those people and like have them participate. So I don't necessarily have to interact with all the engineers, right? I can interact with like the subset who decides they want to like participate in like the project management. But yeah, like I mean, and I think I kind of see it as my job to like fit around their schedules or like their constraints rather than the other way around.

Like, you know, they have to like write all the codes. So, you know, yeah, I just generally try to to work in a way that's convenient with them, whether that's like whatever platform you messaged them on or like. what time you schedule meetings with them, just like all these small things that like, you know, ideally don't add too much friction to their day job of actually building the clients. But yeah, like, I don't know,

most teams have been, like, great to work with. Like, I don't have any complaints about, like, them. And I think the other part that's, like, really interesting is I worked with those and spend most of my time with those two, but I also, like, tend to work with basically everybody who submits an EIP that gets, you know, some amount of traction. And then I kind of help them

you know, get this in front of the right people and do that as well. So, yeah, I know, I'm stoked. Like, I get to work with, like, all the smartest people working on the protocol and kind of observe and, like, sit around as they, like, build a theorem. Do you worry about, like, your own impartiality, impartialness? Yeah. Like, do you, like, hey, there's the thing that I'm interested in.

Hey, core devs, let's focus on this. Or, like, are you kind of like a steward that is supposed to be apolitical and just facilitating communication? Right. Have you ever to balance that at all? Yeah, yeah, totally. It's something I think about. So, for example, when we did 1559 and when we decided whether it was going to be included, I asked Hudson to come and run those calls because I obviously had like a strong, you know, feeling there.

I think, yeah, generally I'll try to be on the more impartial side. I think you can't be like 100% impartial as well. And this is like when we were having 1559, you know, conversations, for example, you know, Sometimes there are some bad faith arguments, and if you just give, you know, as much of a platform to like bad fate arguments as to like good fate arguments, you're not actually being impartial, right? You're kind of tainting the thing. And I think that's something that's like a bit more subtle, like that I try to think about a lot. At the end of the day, like, you know, I can't really do much, like even if I feel really strongly about something, if the devs don't want to implement it, like, you know, I can't force them, right? And this is true of anyone, not just me.

Like, you need to, like, actually convince people. Because, and then it's like, even if I convinced the devs and, like, all the community hated it, well, nobody would download the software. And so they'd have to do that. So I think you need to be somewhat impartial, but it's also, what I spend, like, a lot of time, like, focusing on is finding out, like, what's the actual bit on which people disagree and, like, focusing the conversation there? Because I think a lot of time we lose, like, there's, like, you know, say 10 arguments.

but there's actually like one or two of them that are really important. And like if we if we get like resolution on those, people will like, you know, be okay with like all the other small issues. And so when we have like these discussions, one thing, for example, I found really helpful is outside of the Alcor Dev's call, reaching you out to all the client teams and being like, hey, what do you guys think about this? What do you guys think about this?

So that I can get to the call and be like, well, you know, have the teams think this, have the teams think that, you know? And like we can discuss this like one specific point. friction and like ideally move it forward. Yeah, so I, yeah, I know. I think being somewhat impartial is really important. I don't think you can be fully impartial. And another, so for example, another, like, bias that like I and I think all

devs have is like, will benefit the Ethereum main net over other like implementations of Ethereum, right? So this idea of like interrupt, like, we won't try to like kneecap other implementations, but like we'll always kind of put the Ethereum mainnet first. Right. And, you know, that's obviously a bias because somebody from like, Selo or like Avalanche come on the call and be like, well, you're not impartial. And I think we're fine telling them, well, you know, like, we want to focus on the Ethereum

main net. And like, so yeah, I think there are like these decisions we've made. And I try to like adhere to like the rough social consensus. And yeah, just to try and highlight like the biggest point of frictions between different people so we can ideally like spend most of our time discussing those. This line from the cypherpunks, I'll repeat whenever I get the opportunity is that cypherpunks understand that the code they write impacts the people that use it. Right.

And like the all core devs call is like, it's like the war room for all changes, all bits of code that, you know, in theory will impact generations and generations down the line. Yeah. It's probably really, really draining to think of every single decision as like, all right, well, what about three generations from now? What about 200 years from now? Right. But like, is that people's thoughts and considerations like behind the scenes?

So I think the part where we have it may be slightly easier than that is people are willing to attack the Ethereum network today. So we could usually get by saying like, you know, will somebody attack this, right? Like, if they can. And I'm not sure that's like a perfect proxy for like, is this going to be good 200 years from now? But we can also make more changes in the future, right? like if we realize something's wrong in 10 years, I hope we'll be able to change it.

So the one kind of main bit we always think about is like, you know, what's like the security implication of this? And basically every EIP that gets proposed kind of goes through this. Somebody like is using Ethereum. They're like frustrated by something and they're like, man, I have like this perfect idea of a feature that like, you know, would make this so much easier. They talk to other projects and they're like, they all agree to like,

man, this is great. Like such a good idea. And then they come on a cordev call and like they get pointed out, well, you know, this like has like three security issues in it if we introduce it. And then at least half the EIPs just die there. And then once they usually make it in, you'll have the author kind of then spend, you know, months and in some cases years, trying to come up with like some workaround that's like provides the feature that the originally wanted to, but is also safe.

And this is like 50 to like 90% of the work of actually getting an EIP on the mainnet is like, okay, how do we, you know, make sure that it's safe? And that's really like the main lens by which we kind of view things. Obviously, there's like this implicit assumptions, like we want to do stuff that's useful to people, but generally that's not like the hard part. Like it's easy to like look at a new feature and be like, okay, yeah, this would help, you know, because it lowers gas costs, because it improves U.S. and whatnot. But then it's like it has all these other problems like that people might exploit.

and how do we address those? So obviously vetting the code for making sure it doesn't break Ethereum is really, really important. But have you ever experienced a social attack as in somebody's trying to make their way into the all-core devs team to calls to implement some, you know, some social coordination attack? Because as we know, even outside of crypto, like most hacks are just like people, social engineering other people, right?

Right. Is any story like this ever arisen? So I think what we see a lot, a lot, might be an overstatement. But what we've definitely seen a few times at least is people who come in with an EIP and they have like an incentive to get it in, they're like much more unrelenting than the people who don't want to get it in. So like say you come up with an idea and it's like you really want this and people are like, well, there's problems A, B and C with it.

And then the next week you come up and you're like, well, I really want this idea. and like the person doesn't want to like repeat like I told you you know there's problems A, B and C and you see that like it's almost like a war of attrition where like people would like try to bring up stuff over and over and over even though like the fundamental issues with them had not been been like addressed. And I think we've seen it a bit less recently. But yeah, in the past I think you know, the way with that is we would just like tell people like, you know, like you can't really come back on the call until like you've.

address these things. And once you have, you know, we're happy to. But I think that's really the things, like the imbalance between people who want something and people who don't want it, the people who don't want it having to like constantly rejustify why. And like not wanting to. Like it's, you know, like it's not really their job. So that's one thing I'm pretty mindful about. You know, I think that like more subtle engineering attacks, you know, say like very like, I don't know, like, extreme scenario, like the NSA infiltrates like, you know, a core dev team. I think this is where the client diversity also kind of matters because, like, no client team can like single-handedly push a change unless they kind of convince everybody else, right?

And then even if the client teams agreed, then they'd have to convince the community to do that as well. And you can imagine stuff where, like, you only need to convince the client teams, right? Like if it was like some backdoor in a cryptography function, you know, the amount of people running notes who can actually verify that is quite small. But like if somebody was coming and like shilling, you know, like their BLS 12 library nonstop and like, I don't know, say like the get team was like, oh yeah, we're really on board with that. And like other teams thought something was like fishy about it. It would probably just stall, right? Or if not, you know, other teams would be like, okay, we'll do this. but we'll use a different library.

And so you kind of mitigate any impacts of that. And also, like, it's worth noting a bunch of teams have people that disagree with each other on the team. So it's quite possible that like somebody, again, say this example, somebody tried to put a back door into guest, you know, that the get team might not agree about, you know, do we want to use this library or not. And so I think this is where it's really valuable. Like you don't want to have just one implementation that's guarded by one team because like, if for whatever reason that team got compromised, like, you know, the other teams kind of act as a sanity check. And that's, that's really good. Yeah. So part of the ethos of this whole industry is that it is reflective of what the people want, right? And the nature of open source systems is that

you can contribute to them if you think that you have something valuable to contribute. So vet this statement for me. If you have something that you think should go into Ethereum, you can actually get that done. And I'm talking about, like, not you or the client teams, I'm talking about Joe Schmo from, you know, wherever, wherever in the world, has a really good idea, but he doesn't know you. He doesn't know Danny Ryan. He doesn't know any of the client teams, but he has a good idea. Can he actually get that code in there? Or is, uh, that is actually updating the code gated to a very small privilege number of people. Right. So I've actually, we have EIP1, which kind of describes how to do changes to Ethereum. And I've, I've updated it at a note about

this. You know, I think the difficulty, the difficulty is proportional to two things. One is how big of a change you're trying to introduce. If like, you know, uh, something that happens all the time, for example, is some teams working on like roll-ups, for example, use a pre-compile and they think the gas cost is too high and, you know, they come in, like, we don't necessarily know them. And they're like, look, this gas cost is too high. It would help us a lot if it was cheaper and we've run some benchmarks and we think it's safe if it's cheaper. So, like, you know, they can come in and like they're obviously familiar with Ethereum. Like they don't know anything, but like it's a simple change.

They're able to add a rationale for it. And that's pretty straightforward. If say you want to like change how, you know, say an idea on the scale of EIP 1559, like you're going to need a lot of like time and effort and convincing people to do this. So I think, yeah, like one part is like the difficulty is proportional to how big the change you want to make is. And it's also proportional to like how big Ethereum is, right? Like, because you're changing the system not just for yourself, but for everybody else, right? So basically the more Ethereum grows, the harder it is going to be to make big changes because

like you just have so many different people that depend on it. So, you know, like can like a random person who knows nothing about like Ethereum come and, you know, make a massive change? Like, realistically no. Can they come, you know, without having like connections and like propose something that's like intelligent and like well scope and like be heard and like have with critique like 100 percent like we get ton of those. If you're not sure, you know, you can reach out to me. I get emails from people that are like, I want to come on all core devs and talk about this and I'll try to like let them know, you know, just like set their expectations. And even if they have an idea, you know, I can tell that like, look, even if this works,

this is going to be something that's going to take like a year plus to get done. And like, you know, if this is something you want to commit to, I'm happy to help you. And I'll put you in touch with people who can review and give you feedback on this. But like, yeah, people should expect that it's not like a trivial thing to come on Ethereum and change the protocol. And that's by design. So Tim, who is an all-core dev? How do you define that?

Right. Hard question. So I think we use all-core devs to define the call, not like the people. And I think I've tried to like break it down between like client developers. so the people who actually write code into one of these clients. And then we have a bunch of other folks on the calls for extremely valuable, like researchers, obviously, EIP champions. I find it easier to think about it, that, like what the people actually do.

I think when people ask this question, they're like asking implicitly, like, who gets to make the decision. And, you know, it's a balance. Like I've mentioned this a couple of times already, but like even, for example, this is, I'll think like the, I don't know, most, like, steel men version of this is, like, Vitalik really wants to change. Vitalik has a list of changes. He really wants to scan Ethereum that, like, don't get adopted because, you know,

for whatever reason, people don't think they're safe or, like, they're just not the priority. And, like, even him, like, can't, like, force something through the process and get, like, everybody to, like, drop everything they're working on. Unless they all agree that it's worth it, right? Quickly, can you just, like, rattle off a list of things that you know that Vitalik wants that isn't going in? just a really quick list. I don't have the full list,

but the one he talks about a lot is removing self-destruct. That's like his one of like the fairly simple, you know, things we could actually do that has a lot of like kind of ripple effects, right? And that's an example where I think he'd be happy if we like decided like, oh, we're going to remove self-destruct really quickly. And then when we look at this, we're like, well, how the hell is this going to work? and nobody else, I guess, you know, by nobody else has spent their time like figuring this out. So I think that's a good example where like, you know, and there's valid reasons for removing yet that helps with a bunch of stateless stuff and whatnot.

Like he doesn't just want this for fun. Like there's a strong rationale for why, you know, I guess as a group, we just end up having other priorities and like nobody has made that their number one priority. So even him, and I'm not saying like it's not going to happen, but it's like, even him can't like get everybody to drop everything and focus on like the thing. And if, you know, he might come up with a proposal that's like important enough, but people would have to all make the call like, oh yeah, he's right. And like we should drop everything to work on that. And so, yeah, when people ask about like, you know, who has like the power to make these decisions, obviously like the group decides, you know, what code goes into what hard fork. We have this concept of rough consensus, so we want people to generally agree. We won't, you know, require like a hundred percent agreement.

Like, a lot of people will just, you know, sometimes say like they disagree, but not enough to block it. If people have like really strong objections, like, it is possible for somebody to like, you know, single-handedly block or like delay something if they have like a sufficiently strong objection to it. But there's no hard and fast rule here. And then, yeah, even so if you have consensus amongst all the client teams and like some of the folks, like say the EIP champions or the researchers, you still need the community to adopt the change, right? And you need everybody to upgrade their nodes. And I think we try to be like, we don't want to be into a spot where like we just ship a bunch of software and nobody upgrades it. That's actually very confusing. Like it's bad and it's a situation we want to avoid.

So, like, generally, the core developers won't, like, ship an upgrade that they feel would not get adopted by the community. But it is a possibility. Like, if for whatever reason we, you know, we messed up there, like, we misread things and, like, the community decided this is actually bad, you know, they don't have to upgrade. And, yeah, so I think, you know, obviously, if you want to make changes to Ethereum, there's, like, a lot of value in spending time to understand. how this process works and and you know kind of gaining trust from the people in it and you know providing good contributions and whatnot um but i don't think there's like anybody who can like single handedly like change or like derail the process at this point and and i think that's like really really healthy uh it's it's probably way underrated like when like if you look at say like the the straw or

like the straw men like arguments against like our governance process and like how uh you know people will like say again like Vitalik can I influence the entire roadmap and what actually happens I think there's like a massive gap there and like yeah that's that's really really valuable so in phrase differently would you say like a core dev is somebody that has a good idea the motivation to actually commit to that good idea the resources in order to prove that that idea is good and then and then like you know is ready to follow through on carrying that idea all the way to the very end of its execution. That person is a core dev?

Yeah. Yeah. And again, it's like a fuzzy label, right? Like, so like that seems generally like a good definition. I think like what I don't like about this label is it's also like, say you have like a researcher, right, like who spends, you know, two years coming up with something and they don't actually implement

it. Like they're not a core dev in that they don't write code, but they're like hugely valuable because like they've done like the work. Like for example, everybody who like worked on the beacon chain spec but like doesn't write code for it. You know, I mean, I don't know. Like, you could debate whether you call them a core dev or not, but like,

they're definitely a super critical part of the process. And, you know, I call it like a researcher, but they're involved in the protocol governance, for sure. So, yeah, it's a fuzzy label. I'm getting the visions of the Spartacus meme, where everyone stands up and they say, I'm a core dev and I'm a core dev. So, oh, yeah, I wrote a tweet that helped the core devs, like, Like, learn something.

Like, oh, I wrote the introduction paragraph for the CIP. I'm a core dev. I'm a core dev. Yeah. Yes. And like, I mean, I don't know. I don't want to like exclude people from it. And I think, yeah.

Yeah, maybe that's a point. We'll just start calling it all core devs altogether and get rid of that problem. That's pretty funny. Is Amin Soleimani a core dev? I mean, I think a lot of people like almost dismiss Amin because he of his attitude. He's made like mega important contributions to Ethereum. He's worked on state channels. Moloq now is obviously huge.

So, you know, I think, like, people are too quick to dismiss. I mean, yeah. So, Tim, are you going to just facilitate these core dev operations for, like, the rest of your life or what's next on the horizons for Tim? Man, I don't know. I think it's really hard in a space that moves so quick as Ethereum to, like, have, like, say, a five-year plan, right? think because, you know, yeah, is it possible to predict?

I, you know, I felt like obviously when I joined this, like, one of the main things I needed to do was get the merge done. Like, that seems like a no-brainer. You know, like, and we're working on it. It's the next big thing. We're also going to have like, the withdrawals from the beaking chain won't come in the same upgrade as the merge. They're going to come a few months after.

And like, you know, if I think of like the merge being done for me, it's probably those two upgrades. There's a bunch of stuff after that I feel really strongly about at the protocol level. So the biggest one is stateless. So the idea is that the amount of data on Ethereum kind of keeps growing over time as more people use it and there's more data stored. But it'd be really nice to have a way to cap like how big a node is for a bunch of technical reasons. But, you know, just to have like kind of a constant or ceiling on the node size, that's something we've been talking about since. like 2017, 2018, and that I think after the merge, we have a good shot of like prioritizing

that and like sharding, but sharding happens much more on the consensus there side. So like the beacon chain teams will probably handle sharding for like, you know, 90 plus percent, whereas stateless happens mostly on the execution side. So I think that's like another big problem that like I have a, I've basically been there since we've started talking about this. I have a good feeling for like what the different trade officer. are, how we can maybe get this done. Yeah, I feel pretty strongly about getting this onto Mainette.

I think if we had shardine and proof of stake, and I also felt pretty strongly about EIP 1559, with EIB 1559, proof of stake and stateless, I think, you know, Ethereum could probably go along for 10 years without any upgrade and, like, still be, you know, be good. You know, I think there's a bunch more stuff we'll want to do to make it even better. But, like, yeah, those things just felt to me, like, the major. kind of flaws or issues with the protocol, and I'd really like to help fix them. Is your entrepreneurial itch sufficiently scratched right now? I mean, I think, you know, my work is great in that it is extremely self-dressed

did like an entrepreneur. And I think I do have like the ability to like shape things, you know, like the other big part of like stuff I like to work on, which is like a bit lower on my priority list. But it's like, how do we formalize the governance processes for Ethereum, right? Like, um, and one thing, for example, I think is like a flaw in our process. Like, I don't like that we actually rely on these calls every two weeks to make decisions. I think it's like a bit, it's not great for like, uh, different time zones and like people who can't make the calls. I think some people also like are not, you know, most comfortable, like going on a call and like talking about stuff.

Like they're more comfortable writing. Um, so I, I would love it if like we move to like a mostly async governance process. And we would still have calls, you know, obviously we're going to always need calls to, like, discuss stuff. There's things that's just higher bandwidth to discuss on video. But, like, another way to phrase, this is like, I would be really happy if, like, the way that I end this goal, this work is, like, by putting myself out of a job that you don't need somebody to run those calls every two weeks. And you're still going to need people to facilitate. But, like, it does feel like the amount of context that, like, myself or Danny needs to have to do this is extremely high. and like I would love it if you were able to like, you know,

have a much simpler process where basically anybody, say, with like a project management background, would be able to take in if like for whatever reason I stopped doing it. So I think that's from like a process perspective. That's like something that bugs me. And Rick Dudley had a tweet about that, I think a few years ago that stayed with me. He said, you know, if your engineering process requires genius to work every time,

You don't have an engineering process. You have an artistic performance. And I'm like, I feel like we're not quite an artistic performance on all Cordeves, but like we are a bit too close to that side for me to be comfortable. And I really like it if we had something that's a bit more formalized and less dependent on like live calls that are run with people with a ton of context. Yeah. So yeah, we'll see. I mean, once all that stuff is done, we'll see what I do next.

But I feel like I've got it out of my plate for the next couple of years. So if somebody pinned you down and forced you to answer, what would your answer be for a win-merge? I'd say 2022. So that's a good hedge. The whole year. Yeah. If you had to pick a month. Month is hard, right?

So the reason picking a month is hard is because, you know, what I can control is like how much focus, you know, we have on the merge. And that's like my main thing, like making sure we keep, you know, the vast majority of our focus on that. I think assuming, and then the other thing that's hard is like, you know, we might find like a massive bug at some point. And like, if we find that, it delays things and it's like, it's hard to know by how much. But like assuming we didn't find that, I think like early next year, like sometime in February, we can probably have the code like done. Again, we might not like, that might not happen if there's like a major issue. But assuming we got that, the question is then

how quickly can the community upgrade for the merge? And this is a bit hard because the merge is like a really different upgrade. It's not just you update your node and that's it. If you're a validator, you're going to need to run an execution client as well. If you're like, you know, Coinbase or like Binance, whatever running nodes, you're going to need to like kind of change your setup. And we want to make sure that the community has time for that. Like we don't want like the merge to work at like the consensus level.

but then everything breaks, right? Like all the staking pools break, for example. Like, that'd be terrible. And so it's hard for me to gauge exactly how much time the community needs. What we've been doing, Trent has been taking the lead on this, is having these merge community calls. And literally, they're kind of, we'll share some updates, but most of the call is just like answering people,

like wallet developers, infrastructures, questions. And also figuring out, like, what do we need to do to get this like in an easily, in a good form for you to upgrade? So we've had one a month or so ago. We have the next one this Friday. I think that's a way we can kind of speed run the process where, like, we don't want to wait until the code is completely finished, just like reaching out to, like, infrastructure providers.

We want to solve as many of their issues proactively as we can. And then it's like, yeah, so like if the code is done in February and like we need two months, we usually take about two months to deploy an upgrade. That's like, you know, April. But if for whatever reason, like, you know, if Ether scan was like, well, this is completely going to break things. And like, we just learned about it at the last second. we'd have to make a call.

Like, you know, do we make it three months or do we go with like a broken? And I say ether scan, but like I suspect would be like all block explorers, right? Like, and so that's why it's hard. Like I would be disappointed if we don't get it in like the first half of next year. And I'm doing everything I can to get it, you know,

within like as close to possible to the start of that first half. I don't think, you know, like I think the code is not going to be done until like January or February. So, like, you know, I think it's unrealistic to expect things like before, you know, April-ish, or late March or something like that, if everything went like absolutely perfectly. But yeah, then there's like a couple months that is just unclear how quickly we can get this out. And I think everybody involved in this kind of prefers safety over like shipping it like two weeks earlier.

Yeah. So it's a matter of just not only having the code and having that just vetted and tested, but also watching Coinbase raise their hand, and Coinbase says, hey, we're ready to go. Ether's hand says, hey, we're ready to go. And just like, oh, we get a gist of like everyone kind of says they're ready to go. And so, like, let's go ahead and do this, I guess. Yeah, basically.

And also, like, we need to make sure things, like, mostly don't break. So it's fine if they don't have, like, perfect support. Like, we saw this with 1559, right? Like, Metamask didn't, like, support it, like, right out of the gate. It took them a couple weeks after. And I don't know, I'm fine with that. assuming like it doesn't like lock out users in any way, I'm fine if like, you know, the protocol upgrades and then like things are maybe a bit like like sketchy for a week

or two just as like infrastructure sets up. But you just don't want to fundamentally break anything. Right. You want people to be able to use the old version and have that work. And yeah. So I'm not saying we need to wait for like every single like infrastructure provider to be ready, you know, and there's good competitive pressures amongst them. Like, for example, you know, if finance supports it but not Coinbase, like, Coinbase obviously wants to do it. If, like, you know, Infura supports it but not Alchemy, alchemy wants to do it. So, like, I'm, you know, I don't want us to like do kind of central planning here, but I do want to make sure we're not completely breaking some major parts of infrastructure. Yeah.

Well, Tim, this has been a fantastic lesson as to, like, what it's like to be working on a client team and also just working very, very close to the heart of Ethereum. If there's one thing that you wish was more common knowledge throughout the broader Ethereum ecosystem, what would that be? Yeah, I think that bits I mentioned earlier about the process actually being quite decentralized now at the governance level. I think even within the Ethereum system, some people might have like a picture that like, you know, certain folks are able to push stuff or like, you know, to like single-handedly veto stuff. And I think, yeah, that's like gone less and less true. And that's really healthy. Yeah, so that's probably the one thing. Yeah.

Well, Tim, I hear those criticisms and critiques all the time. And so thank you for coming on and producing a show with me where I can actually point people to actually direct them here. So this will be a new resource for that. Awesome. Awesome. Tim, thanks for coming on. Thank you for having me. Cheers.