From Bitcoin Magazine to Ethereum 2.0: Vitalik Buterin on Building a World Computer

Buterin joined the Bitcoin community in 2011, first writing for an online outlet called Bitcoin Weekly and then for Bitcoin Magazine. After about a year at university he dropped out to work on Bitcoin full time, and he spent roughly six months traveling to Bitcoin communities in New Hampshire, Spain, other parts of Europe, Israel and San Francisco. Lex Fridman asks whether his distrust of centralized control really came from playing World of Warcraft. Buterin says the event happened but calls it a joke that this is why he works on decentralization.

In Israel he met teams working on what people were calling Bitcoin 2.0. One approach, colored coins, used Bitcoin's ledger to issue other kinds of assets. Another protocol, Mastercoin, also supported things like financial contracts and domain name registration. Buterin worked with these teams and came to see that Mastercoin could be improved by making it more general.

His analogy is that Mastercoin was a Swiss Army knife, with 25 transaction types for 25 applications. He realized several of those could be replaced by something general-purpose, such as one generic financial-contract type in which you specify a mathematical formula for what each side gets. A financial contract, he explains, is an agreement where parties put up collateral and receive different amounts depending on conditions like asset prices. Options and contracts for difference are examples, and the hard part is that they must be enforced in a system where nobody can be trusted.

Buterin pitched the Mastercoin team on scrapping their feature list and putting in a programming language instead. They liked it but said it was too complicated for their roadmap. He replied that they did not seem to realize how revolutionary it was, and decided to build it himself, at first under the name "ultimate scripting". After a few more iterations the idea became a blockchain whose core unit is the contract: an account that holds assets and has its own memory but is controlled by code.

If you send ether to such a contract, he says, only the contract's code determines where it goes next. That is the sense in which you are sending assets to computer programs, and why these are called smart contracts. He originally expected to work on it casually for a couple of months, publish it and go back to university. After the white paper came out, a huge number of people expressed interest, which he had not anticipated, and the project turned into a long development slog.

The hardest challenges, he says, turned out to be social. Having been treated kindly in school, he assumed everyone in crypto would be similarly altruistic. His method for finding co-founders was what computer scientists call a greedy algorithm: he took the first 15 people who replied offering to help. As the project grew, disputes broke out over whether it should be a non-profit or a for-profit, and some people tried to gain advantages for themselves.

This led to a governance crisis about six months in, another nine months later and a third after that. After about four reshuffles of leadership, Buterin says, the structure now seems stable and happy. He still thinks most people are well-intentioned, and says part of his attraction to decentralization is that power attracts people with big egos, which lets a small percentage of people ruin things.

On the technical side, Buterin says Ethereum fell victim to the first law of software development: when someone gives a timetable, you take the number, move up to the next largest unit of time and add one. A project estimated at three months ended up taking about 20 months to launch. He puts this down to underestimating the sheer technical complexity, including research challenges.

One such challenge was the long-promised switch from proof of work to proof of stake. Instead of burning computing power on meaningless math problems, participants prove they hold coins inside the system. If you lock up 100 coins you become a virtual miner, and the system randomly assigns you the right to create blocks at intervals. Someone with 200 coins is a virtual miner twice as big and creates blocks twice as often.

Fridman raises the criticism that this favors the rich. Buterin agrees it is a fair criticism but says proof of work is even more so, because you also need to buy physical hardware and burn electricity. Attacking proof of stake would require a very large share of all locked coins. On energy, he cites a then-current claim that Bitcoin uses as much as Austria and says Ethereum is only about half an order of magnitude smaller.

Ethereum 2.0, Buterin explains, is a bundle of major upgrades, the two big ones being proof of stake and sharding. Sharding addresses scalability: instead of every participant downloading and verifying every transaction, each one handles only a small, randomly assigned portion. Because the assignment is random, an attacker still needs a large share of the whole network to corrupt any one shard, so the system stays redundant and secure.

He considers both upgrades hard but sharding harder. Proof of stake only changes the consensus layer, while sharding also changes networking. Today nodes gossip everything to everyone, which would defeat the purpose, so Ethereum needs sub-networks, quick switching between them and communication across them. This has not been done in any cryptocurrency before.

On who builds it, Buterin names Danny Ryan as a de facto development coordinator. The Ethereum Foundation does research in-house, but implementation is done by independent teams at separate companies around the world, which he says requires almost non-stop cat herding to keep everyone agreeing on the spec. Ethereum 2.0 has three phases: phase zero creates a proof-of-stake chain alongside the existing one, phase one adds sharding of data storage but not computation, and a final merge moves the existing system onto the new chain.

Phase zero was almost fully implemented at the time, with security auditing and testing remaining. His hunch was that it was about as far from launch as the original Ethereum launch was when it was four months away. He does not expect many people to move in the early phases, since existing applications will stay on the current chain until the merge happens all at once.

Asked about Casper FFG, the consensus algorithm planned for proof of stake, Buterin says it combines two schools of design. One tolerates up to 50% faulty participants but depends on network synchrony, meaning messages arrive within a few seconds. The other tolerates 33% faults but is safe even without synchrony: once something is finalized, it cannot be reverted, even if the network goes wonky right afterward.

Fridman asks whether publishing papers openly is essential to crypto. Buterin says it is nearly mandatory because crypto is about not having to trust operators, and a closed-source system defeats that point. Openness has also proven a great way to collaborate, and he describes the Eth Research forum, where ideas are posted in a half-formal style. Most new ideas, he says, are small nuggets that do not need ten pages of introduction and filler.

Returning to Casper FFG, he explains how it behaves: with more than half the participants honest and synchrony holding, the chain proceeds normally. If synchrony fails, the last few blocks may be replaced, but anything already finalized stays. He calls this a best of both worlds, and points listeners to the paper on arXiv that he co-authored with Virgil Griffith.

Asked for the most beautiful idea in Ethereum, Buterin first points to the fact that money can emerge out of a database if enough people believe in it. Then he highlights composability: if you build an application on Ethereum, someone else can build an application that talks to yours without needing your permission or even talking to you.

His example is the game CryptoKitties, about breeding digital cats. Someone else made CryptoDragons, where you play by feeding your dragon CryptoKitties, built entirely as an Ethereum contract that accepts tokens defined by the other contract. The teams never needed to coordinate, and he says this scales to entire ecosystems of software, especially in decentralized finance over the past two years.

He gives two DeFi examples: stablecoins, tokens that hold a value equal to one dollar while backed by cryptocurrency, and decentralized exchanges. He describes Uniswap, a contract that holds balances of two tokens and keeps their product constant. Trading moves you along an x times y equals k curve, the amount you add and take out is set by the change in each balance, and the slope at your point on the curve is the price. This lets an exchange function even with very few participants, and Buterin says it is simple to set up and valuable.