Polkadot Decoded. Una Charla de Bar con Gavin Wood, Fundador de Polkadot

Well, I met Aeron and Al probably at lunchtime when we were like 11 years old. But I met Aeron later since he lived not far from my grandmother's house, so when I used to stay there in Lancaster, I'd go on his paper round, help him deliver newspapers and talk about various things. We also worked together a bit in school on other random projects, one of which was a nice little computer game. Al, of course, I met in school, but we became much closer friends at some point after we all left school. Most of us returned to Lancaster for beers to catch up on how life was going. A few years later, we ended up talking a lot about various scientific topics, especially computers, and we ended up working very closely together at the foundation.

The origin of electronic music, yeah. My first computer was a Texas Instruments TI 99/4A. I got it second-hand from the guy across the street for about 10 pounds. It wasn't the best machine, it was pretty old even when I bought it in '88 or '89, but all my friends at school had Spectrums, some of the lucky ones had an Amiga 500, but that wasn't going to be my destiny for some years. I guess the good thing, in retrospect, about having this Texas Instruments machine was that it really didn't have any games. It came with some version of Basic, didn't even have the manual—I just had to learn by trial and error. But a friend in the same housing estate had the manual, so I borrowed it from time to time. More likely, I'd go to his house because he sometimes wanted to borrow it, and I'd read it while he was playing. That was my way of self-teaching. Eventually, I got a Spectrum, a ZX Spectrum +3, which had a disk drive, but the disks were incredibly expensive. It had CP/M? No, three-inch disks. So my Amstrad PCW had three-inch disk drives and CP/M, and that was so bad—like three pounds per disk or something, completely unaffordable. So I mostly programmed on that and then on the Amiga 500. That's when things started to get a bit better: I could make music, made some music snippets on the machine, and also made some video games. One of them was like a Bomberman clone. I co-created it with Aeron. Aeron did all the graphics, and it ended up looking quite good, even got a pretty decent review in the biggest magazine at the time for the Amiga.

I'll share the magazine page. I think it was September 1996. A pretty well-reviewed game, although they said in any other week it wouldn't have won the top prize, and they noted that Bomberman Professional is a much better game to play. Light criticism.

It's great. We loved playing board games—we still do, although I don't have much time for many board games these days. But we used to go to a board game convention called Sheffield Triples. This was something we all liked from childhood, though unfortunately it's moved location now, it's kind of outside the city part of Sheffield instead of at the university. But I digress: the idea was that we used to go to a board game shop. If you've seen the Simpsons, you know the comic book guy. There was a guy who ran this board game shop in Lancaster who looks quite similar to the comic book guy in the Simpsons, and he also had a stall at this convention. So it became a kind of focal point of the year, as much as Christmas or Eurovision, a time to get together and play some games. And one of these years, I thought, some of these games have interesting mechanics, wouldn't it be nice to try to combine them? So around Christmas or New Year of 2000—actually more like 2008 or 2009, I guess—we were sitting in the pub, I think it was, I can't remember who of us it was, but I don't think I was involved. Then we said, let's try to make this game with a chessboard and a deck of cards. I think we went to a shop in the Lancaster area and bought a couple of packs of cards and a chessboard. I remember going into one of these pound shops and buying the necessary equipment. And then, you know, having a pint of beer, marking some cards and marking the board, and thinking up some rules. It was great fun, we did it for quite a few days in a row. Eventually the rules matured, and then it turned into a case of production. Aeron spent a lot of time cutting small wooden blocks.

Sure. This was a bit after the board game escapade. It didn't take long to realize the board game wasn't going to make us millionaires, so we decided to try to do something a bit more useful for the world, I suppose. And we had the idea of doing a PhD in music visualization, creating big light shows. We built a system that could help run and orchestrate light shows for concerts and nightclubs. Aeron and I formed a partnership, Lancaster Logic Response was the company name, and we set out to build a box that could extract music from audio and send lighting instructions to the common lights that could interpret them. We spent about a year and a half doing this, and we installed it in a couple of clubs in London. We made some business contacts—one of them still owes us 80 quid, and we won't bother holding on to that. That nightclub was amazing. I was there with the drill, drilling into the wall to mount all this advanced lighting modules placed in the wall of robotic lights that would swing to the beat of the music. Getting it all set up was great. And Gav, you're wearing a rather luminous shirt today to make sure the light works. The DMX instructions could be created from the software I was making, connecting it to music information retrieval systems similar to what I studied for my PhD. I remember doing a gig with my housemate at the time, who was an electronic musician, installing it in this club and having a real-time light show where we were pumping different elements of the music into the box. I made a pretty nice design for the box—the physical thing installed in the nightclub looked quite sweet. I remember one notable engineering decision: we were trying to use a Raspberry Pi to run the software to generate the light show. It needed to connect to a Wi-Fi controller, but the Raspberry Pi's Wi-Fi card would randomly disconnect after about an hour and not reconnect. We tried an external Wi-Fi card, same problem. The drivers on Linux just weren't made for mission-critical Wi-Fi. We eventually concluded the best way was to get a super cheap router, like a 10-pound router, put it in the box with the Raspberry Pi, have a wired connection between them, and then the tablet would connect to the router instead of trying to have both connect via Wi-Fi. It worked perfectly. The only issue was we had to somehow get power into the router. So the crucial engineering element of this whole thing—connecting daisy chains, the nightclub lights—and we had a beautiful box with a laser-engraved logo and a really cool-looking antenna sticking out of the cheap router. But the critical engineering aspect was making sure the heatsink was attached to the casing well enough so that the whole thing wouldn't melt after an hour of operation in a crowded club.

Well, Ethereum actually started in Lancaster with these guys. For me at least, Vitalik had published the white paper maybe one or two weeks before I saw it. One of my colleagues told me about it—Johnny Bitcoin, who is also a colleague of Vitalik's. That would have been around early December, I guess. Mid-December, I was going back to Lancaster for Christmas and was in the pub with, I suppose, probably these two guys, and said, oh yes, I'm going to start coding this protocol called Ethereum. And we were like, oh yes, fair enough. So I went to Daos', a mutual friend who also went to school with us, when they were just after Christmas, usually relaxing there for a few days, often over New Year. That's when I really started. I think I initially started coding Ethereum a few days before Christmas, but many of the bigger commits were between Christmas and New Year 2013. I remember sitting on the sofa with probably Aeron and Al wandering around the room trying to help Jeff, the other coder from the Ethereum founding group. Fast forward, we got to, I guess, June or July, and I think it was June when we persuaded you to go on a road trip—it didn't last as long as a road trip, it was more like a hitchhike to Berlin. But we stayed in Berlin for a time, moved there together. I stayed there for a few months, I guess, around mid-2014, and that's where we were when the Ethereum crowdsale occurred. Not long before the Ethereum crowdsale, I think the three of us got together and started thinking about proof of stake for the first time. I think it was when we were staying in Bleichestrasse in Berlin in this fairly large apartment, and it was the three of us, and we were trying to come up with a proof-of-stake algorithm. At that time, we were looking at all the other things, and Al came up with a way to overcome the next attack, which I think was probably the most important proof-of-stake protocol at that time. We thought, okay, if we know this amount of hash power and can enter with this attack in this 15-second timeframe, then we can take over the next protocol. That was something we all came up with in a couple of hours on that apartment floor. So we came up with a design for a proof-of-stake algorithm, but we never pursued it, of course, because everything was focused on getting proof of work done on Ethereum. Then we pushed forward, had EthDev set up in Berlin, and as a subsidiary of the UK operations, also UK operations were set up. So it was a pretty busy time, but fortunately it turned out well and Ethereum was delivered. But I remember trying to persuade Al to come in at that time, and yeah, it wasn't going to happen. It wouldn't be until a few years later that it finally did. He came and said, can you give me a job at the Web3 Foundation for a while between academic activities, and as you said, you're still here.

Sure. I'm sure everyone here knows we've been working toward the final phase of launch for some time. Parachains have been around the corner for a while now, but we're at the point where we have reasonably enough confidence to send our canary network into the void and sniff the atmosphere. Our parachain supplement has been running reasonably well on Rococo; we've seen a lot of different chains there, they've progressed very well. So we decided to start the final stage of launch, which involves introducing it into Kusama. It happens in several stages inevitably. The first is to implement the parachain logic—everything to do with parachains in the runtime and in the validator code of the network. So validators need to upgrade to client version 0.9, which supports parachains. Fortunately, the vast majority on Kusama already have it. Then the Kusama runtime needs to be upgraded to support parachains—runtime upgrade 9010—and that all happened last week. Next, we introduced a deployment parachain, which happened on Monday: the parachain Shell. I wrote its runtime in the last few weeks. It's very, very simple—probably the simplest runtime ever written. It really does nothing except listen for upgrades or authority changes, so it only knows how to upgrade itself. But it's a good first step because it has to progress; we can see the block number increasing, blocks being added and finalized, and they're being validated and backed. This is all a very important test to make sure it's working before we do anything serious, like starting to issue a real parachain such as Statemint or Statemind for Kusama and then issuing tokens. Shell was launched on Monday. We found a couple of bugs—well, a few bugs, but you always find bugs in software. They are being fixed, and we expect to release 0.9.2 very soon, today or tomorrow, which will fix these issues. Once we're sure Shell is running smoothly for 24 hours, we'll upgrade it to Statemind. Statemind is a common-good parachain, so it doesn't have special tokens or anything; it's useful for Kusama overall, allowing anyone to issue tokens. Eventually it will also support NFTs and be compatible with XCM, so other parachains can own and move tokens stored on Statemind. This should hopefully happen later this week if all goes well. Once that's done and we're happy Statemind is running correctly, we'll start the auctions. Other teams will throw their hats in to deploy their chains. These will be the first parachains deployed on a relay chain in the world, so expect chaos—but hopefully not too much. Auctions will begin soon; I'll post a blog when we finalize it, but it seems likely the auctions will be for seven days each. Five of those days may or may not count towards deciding the winner; it's a candle auction but retroactive. Basically, two days are like a normal auction: if you bid highest, you definitely win over previous bids. After those first two days, the running period becomes this uncertain final period, which will continue for five days anyway, but we'll choose a random point in those five days when the auction will be decided retroactively. This means even if you bid higher later, there's a chance it won't be counted; an earlier, lower bid could still win. This has been thoroughly analyzed by the Web3 research team, and it's a solid plan, I'm told. The expectation is that the highest bids should come within two days, and there won't be many large bids in the final period, but we'll see. So seven-day auctions one after another. We'll do five initially, then see how Kusama is behaving, and if it looks good, we'll probably leave it for a week or two. If it looks good, we'll continue—conservatively, but expand as much as we think the network can handle. It's worth noting this is the first time we've done this, so Kusama is very much the canary and the coal mine here. It's both an experiment and running tests on testnet or even unit tests. We don't know how it will behave with real incentives, real transactions, real code, real teams making real mistakes. Once Kusama seems stable with a few parachains, maybe even multiple, we'll start the same process on Polkadot.

It's taken maybe 20 to 50 experienced developers, depending on how you count, three years to get to where we are now, which is right at the point of launching fully functional parachains. Compare that to the few weeks it took me and Jeff to get a working version of Ethereum. A few weeks for one developer versus three years for 20, 30, 40 dozen experienced developers. That just shows exponential complexity. Bitcoin still doesn't implement the white paper. Ethereum, we were talking about Ethereum 2 proof of stake in 2014. It just takes so long to do anything worthwhile. But with a metaprotocol that has upgrades and forkless governance, the fluidity means these kinds of updates can happen much sooner.

Ah, no, it's not a bionic arm—quite the opposite. It's not an arm of the future; rather, it's a hand of the past. It's a piece of armor. I'm not really a knight, so I don't need it day to day. It was a gift from an old friend, a lovely guy named Louie. Louie, if you're there, I hope Thailand is going well. He bought it on a random, presumably lonely night in London in 2014 on eBay and showed it to me when I was around that weekend. Last year, he said something like, your apartment looks a bit empty here, you have a lovely piece of armor. So I said thanks, and now it's one of my pieces. A small part of Polkadot's history. Louie was the designer—he wanted a chain like a nice chainmail vest—but I couldn't. I saw one in San Francisco before Burning Man a few years ago, but I was convinced not to buy it. The better part of me said I should, but the person I was with at the time insisted it was impractical. I think it would be great because it would build muscle mass and burn energy. But going through airport security probably wouldn't allow a chainmail vest. Obviously you don't walk through a metal detector. It's proof of stake, not for burning energy—personal energy, okay.