Episode Summary
Executive Summary: Tim Bako recounts his path into Ethereum, from early entrepreneurial experiments to client work at ConsenSys and his later role coordinating All Core Devs. The conversation explains how Ethereum upgrades are actually made, why client diversity matters, how EIP-1559 was developed and vetted, and why protocol governance remains decentralized despite common myths about central control.
Main Topics: Tim Bako’s path into crypto and Ethereum (Priority: 5/5): Tim describes early business experiments, learning computer science, and his eventual move into Ethereum after following it casually since the DAO era and then more seriously during the 2017-2018 cycle. How Ethereum client development works (Priority: 5/5): The discussion explains what Ethereum clients do, how much of client behavior is specified versus discovered through implementation, and why client teams need deep coordination across trade-offs, testing, and network compatibility. Client diversity as a security and resilience property (Priority: 5/5): Tim argues that Ethereum benefits from multiple clients because it reduces systemic risk, prevents single points of failure, and preserves room for innovation without forcing every team into the same architecture. The EIP-1559 process (Priority: 5/5): Tim walks through why Besu/Consensys took on EIP-1559, the technical simplifications made to the proposal, the economic analysis that validated it, and the communication work needed before mainnet adoption. All Core Devs, governance, and decentralization (Priority: 4/5): The role of the All Core Devs call is framed as coordination rather than centralized control. Tim emphasizes rough consensus, the limits of even Vitalik’s influence, and the importance of community adoption. Public goods and incentives for client maintenance (Priority: 4/5): Tim argues that client development is under-incentivized relative to the value it creates and proposes upside-sharing mechanisms, such as treasury contributions, to improve the risk-reward profile. Future roadmap: statelessness, merge, and async governance (Priority: 4/5): Tim identifies statelessness, proof of stake, and better governance processes as his next priorities, including a desire to move Ethereum coordination toward more asynchronous decision-making.
Key Arguments: Tim believes Ethereum attracted him because it was a genuinely new platform with real protocol-level problems to solve, unlike many derivative 2017 projects. Client work is not mostly about reading specs; most of the hard work is in messy implementation details, cross-client compatibility, and undocumented conventions. Multiple clients are essential because they improve resilience, let Ethereum survive client bugs, and enable new architectures to leapfrog older designs. Ethereum’s governance is decentralized in practice: no single individual, including Vitalik, can unilaterally force protocol changes through. EIP-1559 succeeded because a team with bandwidth and technical expertise invested heavily in simplifying the spec, proving the economics, and educating the community. Client development needs better incentives; current compensation covers salaries but not the upside that crypto-native builders often capture. A robust future for Ethereum likely requires statelessness, proof of stake, and a governance process that depends less on synchronous calls and more on accessible, asynchronous participation.
Data Points: First ETH purchase timing: Bought ETH the day before the DAO hack - Tim says his first ETH purchase was to contribute to the DAO, and it went through right before the hack happened. Startup attempts before Ethereum: 3 years managing a painting company - He managed a house-painting company before pivoting into tech and crypto. Early entrepreneurial age: 15-16 years old - He says his first business, an online t-shirt company, happened when he was in high school. Ethereum job search window: Late 2017 to 2018 - He began seriously looking for Ethereum work during the ICO boom and got his first role later in 2018. Client team structure at launch: V0 client with only mainnet sync and archive-node/full-sync capability - Tim describes Pantheon/Besu’s early state as very limited before it grew into a fuller Ethereum client. All Core Devs cadence: Every 2 weeks - Tim says he moderates the coordination call on a biweekly basis. EIP-1559 initial transition design: 1% transition period, later 99%/100% over months or a year - He explains that the original spec used a gradual transition that was later simplified away. Research timeline for 1559 economics: About 3 months - A professor and team studied 1559’s economic/game-theoretic properties and produced a formal paper. 1559 analysis paper length: 50 pages - Tim cites the resulting paper as a key credibility boost for the proposal. Number of major client implementations: 4 clients - He notes that Ethereum has multiple client teams with different trade-offs. Merge-related coordination window: About 2 months for upgrades - Tim says network upgrades typically take around two months once code is ready, though merge timing depends on ecosystem readiness. Client diversity target: More than 1, less than 10 or 100 - He argues Ethereum should have multiple clients, but not an excessive number, to preserve resilience without fragmenting coordination. Potential client-maintainer upside proposal: Donate a percentage of treasury - Tim suggests new projects could contribute to a fund that rewards client developers. Planned scope of core protocol priorities: 3 major items: merge, withdrawals, statelessness - He frames the merge and withdrawals as immediate goals, then statelessness as a key next protocol challenge.
Pivotal Quotes: "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." — Host: Opening framing for the podcast’s focus on the people behind Ethereum’s code. "If your engineering process requires genius to work every time, you don't have an engineering process, you have an artistic performance." — Rick Dudley (quoted by Tim): Tim uses this to argue that Ethereum governance and core dev coordination need more formalization and less dependence on heroics. "No client team can single-handedly push a change unless they kind of convince everybody else." — Tim Bako: Tim explains why Ethereum governance is decentralized and consensus-based rather than controlled by one actor.
Implications: Ethereum’s future depends less on charismatic control and more on resilient coordination, client diversity, and sustainable incentives. The episode suggests protocol governance is real work: technical, social, and political, with major upgrades requiring broad trust and adoption.