This Epicenter interview with Gavin Wood traces a line from his first encounters with Bitcoin and Amir Taaki, through the early Ethereum period, to the design of Parity, Polkadot, and Substrate. A recurring theme is Gavin's preference for reasoning from first principles and learning by implementing systems directly.

Transcript

Overview

This conversation moves from Gavin's origin story into a deep technical discussion of why Parity chose to build beyond Ethereum, how Polkadot emerged from thinking about sharded Ethereum, why WebAssembly became the abstraction layer for heterogeneous chains, and why Gavin sees explicit on-chain governance as the natural extension of consensus systems.

Finding Ethereum

[00:14] Narrator: This episode of Epicenter is brought to you by Microsoft Azure. Configure and deploy a consortium blockchain network in just a few clicks with pre-built configurations and enterprise-grade infrastructure. Spend less time on blockchain scaffolding and more time building your application. To learn more, visit aka.ms/epicenter. And by Toptal. Experience a new way of hiring as Toptal delivers only the top 3% of applicants, including highly skilled blockchain engineers. If you're looking to scale your team with the very best talent, visit toptal.com/epicenter.

[00:51] Brian Fabian Crain: Hi and welcome to Epicenter. My name is Brian Fabian Crain. I'm here today with Meher Roy. We're going to have Gavin Wood on in a second. Of course, Gavin Wood, who's done so much important work around Ethereum, Polkadot, Parity. So we had a really fascinating conversation with him. Actually Meher and I both said this was one of our favorite interviews in a long time that we've done. Now before we get started, actually we did want to speak, Meher and I did want to speak a few minutes about a project we've been working on, a company that we started at the end of last year called Chorus One. We haven't really mentioned that so far, but this has kind of been our main focus since then. And what we've been doing is we've been building validators and kind of staking infrastructure for proof of stake networks. So also some slight disclaimer really. I mean, we haven't yet done much work on Polkadot, but it's definitely one of the projects we're very interested in also working on from that end. So we have this kind of relationship also from that end.

[01:52] Meher Roy: Yeah, and it's actually been fun working on building a validator. I feel it's making me a better interviewer because for many of the projects I'm starting to know the internals of the projects much better. So I think, I hope it'll be a positive sum game with Epicenter and the viewers will get more insightful questions from the two of us because we have this experience with Chorus One.

[02:20] Brian Fabian Crain: Yeah, no, I totally agree with you. I think that was also one of the things with me that really attracted me about it is that we've had so many conversations about so many different projects and have this fairly superficial knowledge of a ton of different things going on. But then when you actually try to build this fundamental infrastructure that will make a blockchain work and actually make it secure and sign blocks, that's very interesting to think on. Also, you know, sort of look under the hood. So that's also been one of the things I found really fascinating about it. But I'm sure we'll talk more about that at some point in the future.

Now there's one other announcement that we briefly wanted to make. So this week actually, DEVCON4 is going on in Prague. Sebastian is in Prague, I am in Prague. Unfortunately Meher, you can't make it this year. But you know, we have a few other people. Sunny, I'm not sure if he's here, but so we are organizing a meetup and the meetup is going to be on the 31st, around 7:30 to 9:30. So hope to see many of you there. If you want to learn more about it, just go to epicenter.tv/devcon4. That's D-E-V-C-O-N-4 and you can learn about the details there. And I hope to see many of you there.

And now let's go to the conversation. So we're here today with Gavin Wood. Gavin has, you know, we've known him for a long time. Actually I was looking back just earlier and he was already a guest. It was episode 31. So that's over four years ago. And I remember recording that in Gavin's apartment just briefly after he moved to Berlin. So that was before Ethereum had launched, much before Ethereum had launched. I think it was just around the time of the Ethereum fundraiser. During the Ethereum fundraiser. So one of our very early episodes, pre-video and a long time ago. Of course, Gavin's done a lot of important work in the blockchain space. He joined the Ethereum project very early on, kind of at the very start. He wrote the yellow paper back then. So that was kind of a technical specification of Ethereum. And he was the guy who originally developed Solidity and the C++ client and then of course went on to do a lot of other important things including founding Parity and now Polkadot. So there's lots to speak about and yeah, thanks so much for coming on today, Gavin.

[04:44] Gavin Wood: Thanks for having me, Brian.

What made Ethereum special

[04:47] Brian Fabian Crain: So first of all, tell us a little bit, like how did you originally learn about Ethereum and blockchain and get involved back then?

[04:59] Gavin Wood: I guess it started in 2013 really. I was aware of Bitcoin a couple of years before when it first hit Slashdot, but I don't know, it kind of didn't seem particularly interesting. Kind of pointless, bottle top currency. I think I was not in a minority in basically writing it off as an irrelevant experiment. And a couple of years pass and it's like early 2013. And I see these stories about the Silk Road and I see stories about how Bitcoin's being used to facilitate this stuff. And it was like, wow, there are people using this. That was the first kind of surprise, like, wow. And I sort of kept an eye on the stories and I found one guy, his name is Amir Taaki. And this guy seems to be kind of a revolutionary, a kind of crypto programmer, cypherpunk kind of revolutionary guy. So I figured he was an interesting kind of guy to speak to. So I reached out to him. I'd done a lot of coding in the open source world for the, I don't know, 10 or 15 years before. And I had an email address that sort of demonstrated this. I have like a kde.org email address from the times that I was a KDE coder and I knew Amir would recognize it. So I used that. And sure enough, he replied and he invited me to his squat, the same one that I'd seen him being interviewed in, which was kind of interesting. So I got the train down to London, met up with him, and I met up with a couple of his friends as well.

One of them was Mihai Alisie, who I actually randomly said hello to. Amir sort of threw this door open to one of the rooms in the squat and Mihai was there in bed with his girlfriend Roxana. And Amir was like, oh, this is Mihai. He does Bitcoin Magazine. I was like, hi. Mihai was like, hi. And Roxana was like, hi. And then he closed the door. It was kind of an odd kind of scene.

Anyway, he also introduced me to another guy called Johnny Bitcoin, Jonathan James Harrison. And he was kind of man about town in London. He had a bunch of friends and he'd been staying with a bunch of people in a place by Barcelona where he met Vitalik Buterin. And he'd been chatting to Vitalik about what he was thinking. And this was kind of pre-Ethereum. But not long after, Vitalik started sending sort of early versions of the Ethereum white paper to various people in his email address book. And one of them was Johnny Bitcoin. When he found out about Ethereum, he sort of thought it was kind of a cool idea. And he mentioned it to me in one of our sort of times down the pub having a pint together. And he said, look, if you're — I was kind of saying, oh, I'm such a good programmer. And he was like, well, if you're such a good programmer, you should just go and program Ethereum. And I was like, fine, I will do.

So I downloaded this white paper and I think even Johnny sent it to me and he made the intro with Vitalik. So I started chatting to Vitalik and yeah, it was — I was working at some really boring, horrible Microsoft coding at the time, and I just wanted something to clear my mind over Christmas, kind of a nice little project. And this seemed to fit the bill. So I started coding up Ethereum and before long I was sort of swept away into this new world.

[08:40] Brian Fabian Crain: So what was it about Ethereum that kind of captured your imagination when Bitcoin hadn't done the same thing?

[08:48] Gavin Wood: I think, I mean, there's a few kind of points. I guess one of them was that I kind of knew roughly how blockchain worked, but I learn things by implementing them. And it seemed that Ethereum was a more enjoyable and more pointful thing to implement than Bitcoin. It's like, why would I implement something that's already got like two or three implementations that are perfectly good enough? Ethereum was relatively nicely specified. I mean, it turned out that there were quite a few holes in the specification, but it was good enough to get going. And that was just nice. That was a nice, clear kind of little coding mission to go on. And I was also curious to see how well it would work. It was doing stuff that hadn't been done before, and I was pretty sure that it wasn't going to work. But I figured that with enough tweaking, it might eventually do something kind of interesting. It wasn't until later that I really kind of got to grips with what Ethereum was and why it was so sort of special.

[10:07] Brian Fabian Crain: So you said later you realized, okay, Ethereum was actually so special and it took you a while to come to grips with what it was. So tell us about this. What is this essence of Ethereum that it took you somewhat while to understand?

[10:24] Gavin Wood: I guess it was sort of fast forward a couple of weeks and I've been implementing this, I don't know, for four weeks or so. And I get sort of notice that we should meet up in Miami. Everyone's getting together. It was meant to be a hackathon, meant to sort of all get down and start coding, well, finish coding Ethereum. It turned out that I was actually the only real coder that was there. Everyone else was sort of busy doing other stuff.

And it was during that time in Miami that I sort of got thinking about — I was exposed a lot more, let's say, to the Bitcoin world. I was exposed to many different Bitcoin people. I was exposed to some very interesting people, some sort of self-declared philosophers and so on. And we got a few interesting conversations and some of them got to talking about the state of the crypto world, how Bitcoin was cryptocurrency and things that were sort of crypto finance were coming up. Mastercoin was fairly in vogue at the time and there was an idea that Mastercoin was providing financial contracts on the blockchain that was going to facilitate this whole new wave of crypto finance, lending and contracts for difference and all sorts of things like that.

I was trying to figure out what Ethereum was. If we've got cryptocurrency and crypto finance, is Ethereum just another crypto finance? That's how it was kind of presented to a large degree in the white paper. If you read the original white paper, it had a little bit to do with smart contracts. But a lot of the general gist was really kind of a better, more true and complete, better scripted version of Bitcoin. There wasn't really this idea of building cohesive, decentralized applications at that time. It was very much coming from a sort of nuts and bolts purist making a platform for deploying and executing smart contracts.

And it was sort of at that time that I was thinking, well, what is this platform? What does it do? What's the generalization of it? And yeah, it was there that I sort of figured, well, this is kind of crypto law because what we're doing is we're creating new laws. They're laws because we can't work around them. They're laws like the laws of nature. They're just sort of set by game theory, but they're different to laws of nature in that we can kind of program them ourselves. And that was very interesting. And it was like at that point that I started to realize the vastness of what this software would change. It was really going to change the way that society was going to basically work. It was going to provide a whole new sort of economic foundation for society.

[13:31] Meher Roy: So you mentioned another thing, that you learn by implementing. Is that a habit you still continue?

First principles and implementation

[13:40] Gavin Wood: Absolutely, yeah. I mean, you've got to balance it with some forethought. Especially when you're doing things like design, like protocol design, and particularly kind of where the stakes are high, it's important to think through and prove things. But in general, I find that I can deal with things a lot better. I can internalize them, if you like, in my brain. I can understand them a lot better if I work through and I code them. And the thing is, if you code it, it's basically just formally and strictly expressing what it is. It's not really doing much more than that. And it forces you to really manage all of these sort of edge cases, all of the sort of corners that you might not think of when you're sort of considering the general vision or the sort of direction that you want to move in.

And it's very easy to sort of get a concept, get an idea of something and think that you've designed it through, think that you've got it all covered. And then when it comes to coding it, it doesn't compile or you can't code it in the first place. And when you realize why it doesn't compile, it teaches you about why your idea maybe isn't as good as you thought it was, or at least isn't as complete as you thought it was.

[15:03] Meher Roy: Interesting. So would it be right to say that you're not somebody that reads a lot of white papers necessarily, you get interested in an idea and you maybe write your own paper and you build it?

[15:20] Gavin Wood: Yeah, I don't know. I kind of remember reading a quote by someone that was basically like, it's important to stand on the shoulders of giants, but also eventually it's similarly important to kind of keep saying and sort of arguing new things, things that just seem correct to you from first principles. And eventually you'll start arguing or discovering things that no one else has argued or discovered before. And that kind of second part really definitely sort of appeals to me. I'm not — I find that if I read too much, it's very difficult to — it's kind of like you get led on down a particular path, down to a particular way of thinking or way of considering a problem, and it shuts off, kind of psychologically speaking, other paths.

And I can see the balance of, well, if it's already been determined that that's the correct solution, that's the optimal solution, then you shouldn't try and reinvent the wheel. You should just follow on and build on it. But similarly, in these very sort of early stage industries where lots of ideas are floating around, believing that something is the optimal solution and just sort of automatically using it, automatically assuming that that's the case, I think can be hugely problematic.

And so I kind of like to chat to people about new things. Because in that case it's very easy to kind of delve to the bottom of something and you can better understand whether it really is sort of the best way of doing something. You understand the trade-offs perhaps that were made, you can challenge. But that's not the case with a white paper. And white papers are often written again like, as I mentioned before, the design of something. They're not real implementations, which means a white paper might on the surface seem as though it's delivering so many things. It's the best thing since sliced bread. But actually when you get into the nitty gritty, there are all sorts of corner cases that you don't think about because they're not presented to you in the white paper. But it means that it's actually not the optimal solution and it's maybe not even a good solution.

[17:45] Meher Roy: So I could see this approach working when let's say you were an individual contributor. So you were maybe doing your PhD. Then you built Ethereum. And has your approach changed? So now you're also managing this organization and presumably there's like lots of other people that are building the same. Have you had to change in your approach on how to learn, to manage an organization, a team of developers, not just yourself?

[18:16] Gavin Wood: Yeah, so thankfully I don't have to do management. I kind of managed to sneak out of that one. It's definitely not my favorite thing. And my role within Parity is I'm basically a team lead. I'm the one that sort of tells people, look, you really need to review these PRs. I'm the one that sets the milestones and I'm the one that sets the white space policy, which is, I can't tell you how important that is. But I'm not the one that has to sort of manage per se. Like management comes with quite a lot of other things that are non-technical and that's something that I've stayed well out of. The closest thing I do to management is that I interview people that want to come work in the team. But beyond that it's very much the same open source mentality that we've had, that I've been sort of involved in for 15, 20 years now.

And I don't think — I mean, it's evolved. Of course we have new tools, we have GitHub, we have pull requests, but basically it's still just being a programmer and that's kind of what suits me the best. And there are people who are better at doing things like management and doing things like organization building, and that's good because they can take on those roles.

[19:53] Narrator: If you've listened to previous episodes with Marley Gray and Matt Kerner, you know that Microsoft is committed to providing enterprise-grade tools and infrastructure for blockchain developers. Well, the Azure Blockchain Workbench is perfect for organizations building consortium networks. Take the Ethereum Proof of Authority template for example. It's ideal for permissioned networks where consensus participants are known and reputable. Ethereum on Azure has on-chain network governance that leverages Parity's extensible Proof of Authority client. Each consortium member has the power to govern the network or delegate their consensus participants to a trusted operator. And Parity's WebAssembly support allows developers to write smart contracts in familiar languages like C, C++ and Rust. Azure Blockchain Workbench was created on the same principles that drive all production services in Azure. So you know you're relying on secure, redundant infrastructure that can scale. And with built-in services like authenticated APIs, off-chain databases and secure key management services, you can scaffold your infrastructure in just a few hours. To learn more about Azure Blockchain Workbench and how Microsoft is advancing blockchain usability in enterprise, check out aka.ms/epicenter and start building. Today we'd like to thank Microsoft Azure for their support of Epicenter.

Building Parity

[21:03] Brian Fabian Crain: So speaking about organization building and management, so of course you did work for Ethereum, right? So you were CTO of Ethereum. But then pretty soon, I mean, I think the Ethereum organization went into many different directions and it kind of spun out a bunch of different organizations, but one of them was yours. So first was called Ethcore and afterwards Parity. So when you started Parity, what was the vision for Parity both in terms of, I don't know, what kind of organization you wanted to build, but also what kind of impact you wanted to have with Parity?

[21:36] Gavin Wood: I think it would be fair to say that some of the early days with Ethcore/Parity were pretty muddled. There was one guiding light which was let's build an Ethereum client, let's do this from the ground up and let's see where this takes us. That was what we did. Beyond that, so when we're talking business plans and marketing and all that sort of stuff, there were lots of ideas floating around, but to be honest, we didn't really know. It was a very — I mean, this is late 2015, early 2016. The industry was kind of crazy, lots of things coming in. There was the DAO going on, there were teams sort of coming in. There was a whole ICO thing happening. It was a very generally mad time and there were lots of things sort of pulling at our attention.

There was the idea, what about enterprise blockchains? What about building stuff for companies? Microsoft seemed to be coming in at the time with their sponsorship of DEVCON1. There was also the idea of sort of building out Web3 and what if we did Swarm and Whisper and we put it all into a browser? It wasn't clear that Mist was being developed at a substantial rate. So there were lots of ideas, there were lots of potential directions. And in the end we just basically stayed true to our developer culture, which was let's just build stuff. Let's just start with building what we know how to build. We'll start with building Ethereum. We'll do it right, we'll architect it in the way that we think is best from the ground up and see where it takes us.

And I think, at least for me, it was probably not long, four to six months into having the company where I started to realize that the company I wanted was very much a technically focused company. So until then I was kind of half buying into a lot of these Silicon Valley self-help books where they're like, oh, you need to think about marketing and you need to think about company building and need to think about sort of, I don't know, you have to have these particular points of culture. And it kind of gives you all of these — there are so many of these books and they give you all of these sorts of bits of guidance, rules to follow.

And I kind of — the idea of building a company that was really just about developing and delivering the best technical solutions without having too much of a consideration for some of the other aspects, particularly around marketing, was almost kind of a dirty — it's kind of like the thought that dare not share itself, because I figured that wasn't following the rules, it wasn't following the advice, that wasn't what the company culture was allowed to be. But it turns out that that very much is what our company culture has become. And I think a lot of that is down to my sort of influence. And we really do have a sort of developer-driven mentality within Parity. And marketing and business development and product, I wouldn't say is necessarily sort of lagging far behind, particularly product. We do have a fairly sort of — we try and do product development as part of software development. But I would say the biggest part of our attention falls on making really great software and for that matter really great platforms for building software.

And that's really enjoyable. When you're driven from this kind of technical standpoint, it makes development so much faster because you have sort of an innate idea about what it is that you want to get done. You have a very sort of clear and concrete vision. It makes product development and makes project management so much easier than in the early days where you're trying to be very much more market-led. And that's substantially more difficult to work with as a developer.

[26:36] Meher Roy: So I clearly remember, like, I saw posts around the formation of Parity and I think the first target was to build a client for Ethereum. And my first question in my head was like, who's going to fund this team? Because who's going to fund the building of this company that builds a client for Ethereum? And then like a few months later you did raise your first round with 700K or something like that. So you threw out at least parts of the Silicon Valley playbook. Your first product wasn't something that would generate enough money. How did you — did you not struggle to raise money and get the company going?

[27:28] Gavin Wood: I wouldn't say struggle, but it wasn't something that we were going to get tens of millions for. I mean at the time we were seeing R3 start to raise crazy amounts. We saw 21 raise a huge round, Blockstream raise a huge round. And I think, what is it, Digital Asset Holdings, was it Blythe Masters' thing? They also had a pretty big raise. So there were people who were raising really huge amounts of cash for in principle at least blockchain-based products. I mean R3 sort of steered away from it in the end. That was its original suggestion. And I think we kind of considered ourselves to be more or less of the same sort of class. We were developing sort of next generation blockchain. And in my mind we had the better technology. So I wasn't like super worried that we were kind of on the wrong path.

That said, we weren't industry heavyweights. I mean Ethereum was still down at like 80 cents or so at that time. It had gone up what, 2x, 3x more or less from the sale, but no one really cared. And so yeah, we didn't really have any huge amount of credibility. People could see that there was a platform behind us but there wasn't that much doing with the platform. Bitcoin was still very much king.

And yeah, thankfully we had some people that did kind of believe in Ethereum, believe in the platform. And they were very quick to get us started. And we didn't really kind of do the whole Silicon Valley thing of going around all of the VCs and having a pitch deck and having really kind of slick product slides. We were like, look, we're going to make an Ethereum client. We think Ethereum's probably going to be significant. We think it may well end up being the platform of choice for anyone who develops on blockchain. This could be a sort of enterprise play. This could be an open source sort of user-based play. We don't know yet, but we think it's probably worth doing. And yeah, there were people who sort of said cool, we think you're a good team and we think you'll sort of be able to take it somewhere. Which was cool.

And I think, having seen Silicon Valley up close and personal, the show that based itself on it is actually pretty true to life a lot of the time. It's really not — it's a bit of a club and there's a certain talk, you got to kind of talk the talk to be accepted sort of as a potential member of that club. And we were never really a talk-the-talk company. We were a builder, we were a get-shit-built company. And that's — yeah, I kind of grow a little bit — what's the word? Not disappointed. But I think Silicon Valley thinks more of itself, has a higher opinion of itself than it deserves, let's say.

[31:09] Brian Fabian Crain: Yeah, no, absolutely. And I mean it's also interesting that you had like Ethereum and nobody in Silicon Valley cared about Ethereum. And then it became this massive success and then it was this entire thing, right, that basically the VCs in Silicon Valley sort of like missed out on. And then of course now there is this huge tendency with VCs, right. They're like, okay, no, we missed Ethereum, so now we're going to have to fund the next Ethereum. So it's interesting how this sort of played out. But let's speak about Polkadot. So afterwards, right, you build Parity, and then Polkadot has become this major thing or major focus of yours. So how did the genesis — what was the genesis story of Polkadot?

Genesis of Polkadot

[31:55] Gavin Wood: So rewind to 2016. We've been working at Parity for about six, seven months I think. We began coding the Ethereum client late November-ish 2015. And yeah, it's like June, July, August, can't remember exactly. And I'm sort of — we're kind of waiting with bated breath on Ethereum 1.5 or Ethereum 2. We're kind of waiting for this sort of new white paper to come so that we can start implementing it.

And basically there were a bunch of things that happened. There was the DAO that kind of stole some attention from the core development team and there were a few other kind of bits and bobs. And we started to get a bit kind of, is this ever going to come? And so just on a sort of an off-chance conversation with Marek, one of the sort of founder developers of Parity, while we were in San Francisco, we started — Marek just sort of said, well, what if we built something like that ourselves? Could we do it?

I was like, well, I started to think about a design for a sharded version of Ethereum that was as simple as possible. I'd already come up with this notion of chain fibers which was back in 2014, and that was also a kind of sharded Ethereum. But it tried to keep the original Ethereum sort of ease of development of smart contracts and particularly how smart contracts can talk to each other. And as such it's substantially more complex. So I kind of thought, what if we could — let's forget trying to make it as Ethereum-transparent as possible for developers and let's say, right, well, we're going to change some of the assertions and assumptions that developers can make. Maybe it's not going to be quite as easy to develop upon, but let's try and make it as simple as possible. And that was basically where the original idea of Polkadot came from. It was essentially, can we create a sharded Ethereum?

Following from that, pretty much in the same conversation, I think we were having a beer at some bar after we met a VC maybe in San Francisco. And it was there that I realized that you need this kind of — I think Ethereum calls it the Beacon Chain. But you need a sort of main chain in order to validate all of these shards to make sure that they're not doing anything that they shouldn't be doing. And it was always in my mind super important that the shards should all have the same guarantees of security. So this is different to some of the early things that Vitalik was saying. He was in the early days in favor of different shards having different levels of security. And it's also dissimilar to some of the other multi-chain designs like Bitcoin sidechains and Cosmos, where you can have different sets of validators for the different sub-chains. In my mind they always needed to be the same sort of security guarantees.

And so it was one way of doing it. And the obvious initial thing to do is just to fix it, hard code it, hardwire it, to be — for that validation algorithm, that thing that's running checking that all of these different shards are doing the right thing, was to be just Ethereum, right? So the shards are all basically implementing little bits of Ethereum and the main Beacon Chain, or the main relay chain as we call it in Polkadot, is checking, making sure that they're all doing the right thing.

But then I figured, well, what if we let the chains do different things? I mean there's no real need to fix them all to be doing the same thing. And as long as you make the message format that's being passed between them arbitrary, like kind of just general, just a bunch of bytes basically, then there's actually no need whatsoever for them to all be the same. And that's where the idea of a heterogeneous multi-chain came from, rather than the homogeneous multi-chain that is Ethereum 2.0.

And it was again not much later still, I think it was maybe a couple of weeks later. But at that point I was like, well, hold on. We've got this kind of platform called WebAssembly. And WebAssembly lets you basically describe any program. You can compile many languages to it. It's just a sort of generic abstract machine specification and it's nice and simple. Why don't we just encode this validation function that could be different for each of these different shards as a WebAssembly program, and then they can just be linked, they can just be sort of executed, and you can store what the software to actually validate these things, or indeed the specification, the definition of a valid parachain shard — you can store that on the relay chain itself.

And so now what you have is this kind of completely generic mechanism for bringing together many different shards, many different chains that all have their individual kind of niche or individual — well, we call it a runtime. Technically speaking it's a state transition function. But basically I like to think of it as the nature of the blockchain. It's like Bitcoin has a particular nature. It's to do with unspent transaction outputs. It's a very much a currency chain. Ethereum has a different nature, it's a smart contract chain. So you can actually define chains of various varying different natures and they can all sort of exist within this community where they're all being secured with the same apparatus and they're all able to pass messages between each other.

And so it kind of evolved basically from a "how would we scale Ethereum" to "why don't we actually implement this?" Because it's doing — we didn't really want to kind of jump the gun, so to speak, but it seemed a lot more reasonable to implement something that in and of itself was going to be a sort of next generation play.

[38:30] Meher Roy: Very interesting. So this progression of ideas is really nice. Like Ethereum. Okay, then we need a sharded Ethereum. Oh, then we'll need this central chain to be the arbitrator of final validity of some kind. Then like the idea of these parachains or these sidechains, they should be heterogeneous. And of course now if they're going to be heterogeneous, then you need some way to distill and express their difference in like one common, in one common manner.

[39:08] Gavin Wood: Right.

[39:09] Meher Roy: And so that leads into you picking like WebAssembly and allowing these chains to — allowing the state transition functions to be written in WebAssembly. It makes a lot of sense. I'm curious, like why you picked WebAssembly in particular. Did you have some other choice that you did not — some other road that you did not pursue?

WebAssembly and heterogeneous chains

[39:38] Gavin Wood: I mean, in principle there were a couple of potential candidates. The most sort of obvious one, I guess, is LLVM's IR code. So LLVM, if you don't know, is a compiler framework. It lets you sort of not have to write half of the compiler. If you want to make a new programming language, you only have to write the bit that basically just parses your program and specifies in a machine-independent manner what your program means, but you don't have to do all of the sort of taxing things of trying to optimize it and actually targeting specific hardware. LLVM looks after all of that for you.

And so one of the ideas was just to use this intermediate representation or IR from LLVM, which in principle at least is not architecture specific. The problem with that is that it's not designed to be architecture independent. There are particular IR opcodes or sort of IR fragments that are kind of particular to some architectures and it becomes quickly a fairly problematic sort of platform to try and build on.

So one or two of the other things — we could have tried to use EVM, but again EVM is really not designed for this kind of general specification of state transition functions of validity. I mean, it's barely even sort of well designed for smart contracts. I mean, at the time — so EVM, actually it was me who gave it the EVM name. Before I came along, sort of in the original incarnation of Vitalik's white paper, it's called Etherscript and it was really meant to be a scripting language. Some of the early Etherscripts were written literally as just like Bitcoin Script, so just like the mnemonic and then any of the arguments to the mnemonic, so it looked kind of like assembly, kind of macro assembly. And I sort of came along and was like, well, this is pretty low level. I don't think calling it a script is sensible at all. So I came along with this kind of notion of the Ethereum Virtual Machine.

But it is reasonably low level, but it has some fairly high level aspects to it where it sort of deviates significantly from common hardware. One of the obvious ones is the 256-bit word size. So the stack and the memory is done — the storage at least is done in terms of 256-bit words. And that basically means that almost all low level code is massively suboptimal because it's all being stored in these huge heap-allocated chunks of memory, even though only one or two bytes of them are being used. So we kind of ditched that idea pretty quickly. I don't think it was ever really given an afterthought.

And was there another one? Oh yeah, there was one other possibility that we mooted and that was targeting it to a particular hardware, but a particular hardware — so the CPU architecture — but one that was sufficiently kind of RISC enough. So reduced instruction set computers, what RISC stands for. The idea is that it's not got very many opcodes, it's very simple. So in principle you can retarget it, you can recompile it into another architecture without losing too much performance. And the obvious one was ARM, targeting something like ARMv5.

But again, having thought about it a bit more, we kind of figured, nah, probably not the way to go. Especially when we have something like WebAssembly, which is increasingly supported by outfits like Google and Mozilla. It's very much likely to end up with really well performing compilers that trans-compile it from WebAssembly into the native architecture. LLVM targets it natively so it's basically as good as something hardware like ARM, except it's going to be probably much better supported. And it's also simpler, it's easier to work with. You've got various bits of tooling that let you do programs very easily. You've got functions as a sort of primary thing, getting imports and exports. It's basically designed to be developable rather than designed to be implemented on fast hardware. And so we figured it was probably the best choice and certainly in terms of its future, definitely the best choice.

[44:59] Narrator: Hiring is stressful, let's face it. It's a long process of sifting through resumes and interviewing candidates without any guarantee of quality. But it doesn't have to be this way. Companies all over the place are experiencing a new way of hiring with Toptal. If you go to their Trustpilot page, you'll see that of the hundreds of people that have left reviews, over 98% were four or five star ratings, including one guy who wants to give his developer a bear hug. That says a lot. Toptal gets all this great feedback because they focus on their clients and their top priority is quality. They only accept the top 3% of applicants, including highly skilled blockchain engineers. One of these engineers is Radek Ostrowski. Radek has experience as a lead software engineer and data scientist for Sony and Expedia. Then he discovered blockchain and he became totally consumed with Ethereum. He worked as a consultant for the firm Start on Chain, and his Time Locked app won the top quarter ConsenSys uPort and Identity blockchain hackathon. Then he expanded his reach through Toptal. He worked with a bunch of clients on projects such as smart contract development and a PoC that leverages blockchain. If you want to hire engineers like Radek for your team, go to toptal.com/epicenter for a no-risk trial. A Toptal director of engineering will deliver your next hire in as fast as 48 hours, and you'll get $1,000 credit when you decide to hire. We'd like to thank Toptal for their support of Epicenter.

[46:21] Meher Roy: At this point, we've basically covered a big key insight, and that key insight is Polkadot is going to have all of these heterogeneous chains. Now you can think of like, each chain has its own individual DNA. It's specialized to do something unique, which others are not. And so you want a way to express the individuality, the individual DNA of each chain in some common way. And what Polkadot is doing is saying that the individuality of each chain is its state transition function, which is here's the current state of the ledger, in comes a set of transactions or events, and there's a function that will take it from the old state of the ledger to the new state of the ledger. If you could represent the differing state transition functions of all of these heterogeneous chains in one common way, that would be nice. And then Polkadot ended up picking up the WASM standard to express all of the state transition functions in one common way. Cool.

So like, it makes sense, right? So we have come to this piece of the story, and now, of course, this piece of the story ultimately leads into Substrate, doesn't it? So just tell us what is Substrate and how you're using this insight to build Substrate.

What Substrate is

[47:46] Gavin Wood: Okay, so, yeah, what is Substrate? So Substrate is many things. Substrate began as a desire to abstract out the common bits of Polkadot that could also be used for building other chains, like we were doing from the ground up. We were building this kind of software stack for Polkadot. And I really hate seeing code not be able to be reused. It's kind of like food waste. It's like, come on, someone can eat this food, surely. I hate throwing it away. I prefer to put it in a Tupperware and save it for later.

And there's kind of Tupperware-ing food is a little bit like abstracting code. If you turn it into a module ready for reuse, then it means someone else can eat it later. And it also kind of — it's actually just generally good practice. There's a lot to be said about this. If you force modularize your code, then it also makes it generic, which means that you have to be much more clear about what the interfaces are. You need to be much more clear about the definitions. If you're trying to get other people to use it, it means that they're going to help maintain it. It means that they have a stake in your code base, which means that they might end up fixing some bugs or at least catching some bugs. It builds community. It means that your documentation is probably going to be a lot better because you're now having to document for external people rather than just internal people. And that means that as your internal people change, as more people come on, it's much easier for them to get to grips with it. So there's just huge numbers of reasons why it's really sensible to abstract and modularize your code and get it to the point where it can be used for multiple projects, internal and external.

And that's kind of where Substrate came from. If you look at Substrate's heritage, it wasn't a thing initially. It was just Polkadot. And over time, it's like there was at one point I did a giant rename and many of the Polkadot modules became Substrate modules. And there was sort of continual refactorings to take much of the Polkadot code and turn it into generic code within Substrate. And then eventually the repository splits out and we have now a separate Substrate repository.

Now, we always knew that building chains in Polkadot — so we call these chains parachains because they're like kind of either parallelized chains or they're kind of like chains, but not exactly like chains. And we always knew that there's going to be some sort of SDK to be able to — we needed that sort of thing to be able to build more of these chains and sort of hurry things up. And Substrate, it turns out, is not only very good for building the Polkadot relay chain, the sort of big chain in the middle, and building other chains that have nothing to do with Polkadot, but it's also good for building these parachains. It has much of the sorts of algorithms and subroutines that you need for building parachains. Things like syncing the chain, things like peer networking. And although that's not finished yet, we're still very much working on that aspect of Substrate. It fits very nicely into the design of Substrate.

So Substrate is really a blockchain framework, if you like. Substrate's actual reason is to be the antithesis of blockchain maximalism, right? So Substrate is probably the world's biggest bet against blockchain maximalism. The whole point of Substrate is to make making new chains really, really, really, really easy. Like, as easy as building smart contracts almost. The idea is that you just pick and choose which bits you want. There's maybe even a library of modules that you can choose from. You select the consensus mechanism you want and you end up with a chain that's as good as, if not better than one that you would have hand-built yourself.

Now the idea is that these consensus mechanisms that you can choose from, we've already implemented a few of them. So there was our PBFT-derived sort of consensus thing called Rhododendron and that's fairly similar to Tendermint that the Cosmos guys are using. We also have now Aura implemented and a derivative of Aura called Aurand, which basically just introduces shuffling to the authorities. And one of the things that's sort of being actively merged at the moment is the GRANDPA algorithm. I call it SHAFT, actually. So it's like kind of SHAFT, sometimes called SHAFT, sometimes called GRANDPA. I forget what GRANDPA stands for, but SHAFT stands for Shared Ancestry Finality Tool. And this is a new consensus algorithm that we came up with — I should say the Web3 Foundation's research team came up with, sort of in concert with Parity, and particularly Rob at Parity. And I guess we can talk about that a bit later. But it's one of the sort of things that you can pick, one of the consensus algorithms that you can pick.

And the idea is eventually to have another consensus algorithm called Parachain or Polkadot that lets you form consensus based around using the Polkadot relay chain as your mechanism. And what this means is that if you can code your chain in Substrate now, then it means your chain will be able to be integrated into Polkadot later.

The other really nice thing about it is that it's both the consensus algorithm and the runtime. So the runtime is what we call the state transition function or the sort of nature of the network. The thing that interprets the transactions, executes the blocks. It's what makes Ethereum, Ethereum and Bitcoin, Bitcoin. And the idea is that these can all be hot-swapped. They're all pluggable. But not just pluggable, they can actually be changed in situ as the chain is ongoing. So you can switch between consensus algorithms. Even you can move it from being a chain that's sort of busy going along on its own to one that's integrated into Polkadot. You can change it from a Rhododendron PBFT-style chain into a GRANDPA chain, into even a proof of work chain. You can just switch between them as you choose.

And the same can be said about the runtime. So you can actually take your chain and just turn it from a Bitcoin into an Ethereum chain. I mean you have to define exactly how that would work with the accounts and stuff. But basically if you can imagine it, if you can code it, then it can be done.

And that's massively different to the current generation of blockchains. And actually even most of the next generation blockchains that have what we would call in the graphics industry a fixed function pipeline. They're kind of fixed function chains because you have to go back to the sort of — I mean basically they're not designed to ever change. We see this in Bitcoin that's sort of terminally not designed to ever change. But we also see a lot of it in Ethereum where it was never designed to be upgraded. So in order to upgrade it, basically all of your users, everybody that's ever using Ethereum has to opt into the change. And if they don't, then they're going to just run off on the sort of continue on the old version of the chain and they'll come out of consensus.

[56:00] Brian Fabian Crain: Yeah, so that was super fascinating what you talked about, how Substrate works in this way. So let me just sort of rephrase it to see if I understood it correctly. Right, so you have Substrate, this framework for developing a blockchain. Now somebody could go today or maybe in a few months, but in the very near future and say, or maybe today and build this Substrate blockchain. And now they could use for example the existing consensus algorithms. You have maybe GRANDPA or maybe your Tendermint-like algorithm, something that exists today, they launch this blockchain. And now a year from now or something like that, Polkadot launches. And then that chain could actually decide to, on the live chain, say, okay, we're going to swap out the consensus and we're going to start using Polkadot consensus, and we get rid of our own validators and we rely on the security of the relay chain. Is this — this would really be possible?

Live upgrades and consensus changes

[57:03] Gavin Wood: Yeah, that's right. So that's the sort of use case we're designing for. So yeah, pretty much all of the existing consensus algorithms require you to name validators, either hard code them or more likely that we have proof of stake systems. But in all of these instances you do need to incentivize them not to misbehave, usually through slashing. So they lose some of their stake if they do anything bad. And the idea is that eventually you'll basically just be able to move it to Polkadot with little more than a single sort of change in the chain's runtime itself. So it's like literally a storage item. You basically just say, yep, change this particular bit of storage from using GRANDPA or Rhododendron or whatever the consensus algorithm that the chain is using, to use Parachain. And we want to use parachain slot 42. Right, cool. And as long as Polkadot is expecting you, then it will just seamlessly switch over.

[58:14] Brian Fabian Crain: Yeah, I think that's absolutely mind blowing. So I'm super excited to see how that's going to turn out. And yeah, I mean you guys are certainly developing some very interesting technology there.

[58:26] Meher Roy: So of course like Substrate is very ambitious, and so where is it currently at? As far as I'm aware, your plan is to, like releasing Ethereum, release a series of PoCs, each with more complexity over the previous one, until you have the final Substrate. So what's the current PoC and what can it do?

[58:50] Gavin Wood: So we haven't actually made any release. Our schedule is to release our beta 1.0 beta of Substrate real soon now, like before the — ideally before the Web3 Summit. So that's like in a few days time. It certainly — most of the code has been written. It's now just a case of merging it and testing it. So I'm pretty happy to sort of claim that this is going to be out within the next week or so.

The 1.0 beta sort of has enough for doing fairly general chain development. So it will have the Rhododendron consensus algorithm in, the instant finality one. That's a bit like Tendermint. It will have the GRANDPA finality algorithm in. That's our sort of new cool consensus algorithm that's an iteration or two beyond Rhododendron and it has some stuff in common with the Ethereum 2.0 consensus algorithm. It takes a slightly different road, but it's basically a progressive finality thing. We also have the Aurand block production algorithm in for 1.0 beta. And we will likely for 1.0 have an iteration on that that's sort of derived probably from BABE, which is a kind of slightly — it's actually got quite a lot of similarity with Aurand, but it's basically been demonstrated secure as long as a few particular guarantees are given. So that's likely to be our final iteration for consensus on Substrate and Polkadot.

1.0 beta will have mostly finalized APIs. The beta is primarily there because firstly it hasn't yet been audited. That's something that we are looking into. And the documentation is still a work in progress. But over this period of the next two or three months, as 1.0 beta becomes 1.0, we'll be sort of working a lot more on the tutorials. There may be some minor API tweaks, but by and large, what you see with 1.0, what you develop on 1.0 will be usable for the foreseeable future.

[1:01:54] Brian Fabian Crain: Right. So we spoke before about this power of this on-chain automated upgrades. And it obviously is amazing or super interesting, but of course, power, it has two sides, right? So today, when you have an upgrade, a significant consensus-affecting upgrade of a blockchain, in general you have a hard fork, right? So there's this big discussion around it. And then this hard fork happens, people that actively run a full node, they have to download a new client. And to the extent that people and miners actually use that client also determines whether that change gets accepted. So here we have basically automatic updates, right, where I don't have to upgrade the client. So first of all, what is the big downside of hard forks and how do you still have this level of accountability or control? Or does this lead to a lot of risks as well, having automated upgrades?

[1:02:54] Gavin Wood: So I think it's fair to say that automated upgrades are kind of like a sharp knife. They're very powerful. You got to be sure that when you use them as part of your chain definition, there are an appropriate amount of safeguards in place to be sure that they can't be used malevolently and they can't accidentally be sort of misused because they have the power to brick your chain, basically, as I demonstrated on the first on-chain upgrade last April at EDCON.

But because they're powerful doesn't mean that we shouldn't do them. It just means that we should develop appropriate safeguards to make sure that when they're used, they're only used when we sort of expect them to be used. Most technologies, most disruptive technologies are powerful. And there's inevitably sort of a bit of an outcry from the side saying, especially the sides that are in some sense staked in the current technology, to say, oh, this is very dangerous, very powerful. You probably don't want to do that. And it's like, no, no, no. When you're pushing the fold, you are developing these things and they are to some degree dangerous. Sharp knives are dangerous, but a chef will prefer to work with a sharp knife than a blunt knife.

In the case of blockchain upgrades, upgrade paths for software are very, very important, especially in the early days and especially when you have so much economic inertia behind them. We can see this with Bitcoin. There are many sort of follow-ups to Bitcoin that are better in various ways and yet the money is still behind Bitcoin. And that's kind of problematic because Bitcoin hasn't got an upgrade path. There is no really easy way of upgrading Bitcoin.

Why is it problematic specifically? Well, hard forks are generally considered mutations of a blockchain. And as such, their — blockchain being something that a lot of people in the blockchain think immutability, this idea that a blockchain is well defined and it should never move beyond the confines of that initial definition, are forever at odds with those that believe blockchain should evolve. So which means every time a hard fork is proposed, unless you have someone that basically everyone can rally behind to say, fine, this is a dictator, they dictate that it changes, then you're stuck with a big problem of how do you decide when the upgrade is necessary enough that everybody should switch onto the new chain and they should all indeed do this procedure that you just described, upgrade their software and all the rest of it.

And that decision, that mechanism for sort of globally deciding this in a decentralized manner, and particularly one that's full of people that actually don't really trust anyone else because that's why they're in this — it's a very self-selecting ecosystem, the trustless or trust-free ecosystem, basically full of people that don't really trust anyone else — it becomes very difficult to agree, which is ironic because the technology that we have here is technology for making agreements. That's what consensus is. We're stuck in this ecosystem where the key differentiator from the rest of the world is that we're all about consensus technology and we can't form a consensus on when to upgrade our consensus technology. The whole thing smacks of a bit of a Shakespearean comedy.

So what's the solution? Well, the solution is that we extend our consensus technology to dictate not just what happens on the chain, but what happens with the chain itself. And this isn't a crazy idea. This isn't something that is like, that's so different to what we're doing. It's exactly the same as what we've been doing already. The only difference is that we're sort of extending it a level up. And we're saying, well, look, there's very important things that happen on the chain, potentially huge balance transfers, things like the DAO, where you've got a smart contract that's controlling tens, hundreds of millions and it's defrauded in some way. Well, we're just sort of saying, yeah, we recognize that sensitive software exists on the chain. We also recognize that the chain itself is sensitive software. So just as much as the things that happen on the chain are controlled by algorithms that have underlying — usually they have some sort of governance structure, even if it's like there's one guy and he holds the key, a lot of them are much more complex than that with multisig wallets and all the rest of it — well, let's apply a similar governance structure, perhaps something that's even more sophisticated, to make similar decisions. But these decisions are about the chain.

And if you understand the sort of technicality, the sort of technical implementation of protocols like Substrate that allow this kind of upgrade to happen, you realize that Substrate is actually just a meta version of Ethereum. All we're doing really is we're saying, rather than have a smart contract that dictates a particular state transition function, we're saying that there's actually just a single runtime that is the chain and that dictates a state transition function. And just as a smart contract can say, instead of running this code, I want you to, from the next block, run this other code. That's all we're saying. With Substrate, it's like, from this point onwards, I prefer you to run — rather than the code that's running at the moment, you should run this other code. It's really just a case of extending the software model of a smart contract one stage higher and taking it onto the blockchain level.

So really the only question that's left — I mean, I don't see upgradability as any kind of a controversial thing. Yes, it's powerful, but so are smart contracts. So is the fact that you can control money without having recourse to an organization based purely on an algorithm. It's really powerful. It's fine. We're all here because we recognize the power and we think it's probably a good thing for the world. So with the on-chain upgradability, the question simply becomes what are the specifics behind taking the decision to upgrade the chain and how do we ensure that it has appropriate fail safes.

The case for on-chain governance

[1:09:52] Brian Fabian Crain: Now of course Vitalik and Vlad and a bunch of the Ethereum people have sort of argued that smart contracts is great, but then the governance process, it's better if that takes place off chain and if people kind of have this social consensus. And I think there's a variety of reasons for that. I think there's probably fear of the riskiness of on-chain governance and the power as you phrase it. I think another big concern is that if you do have an on-chain process, then what is that process controlled with, and generally it will be the token holders. Because that's kind of the basic unit of significance in a blockchain system since you don't really have real world identities there. And then there's this fear that it will be plutocracy and controlled by a small group of token holders. So what is your view of kind of both of those concerns?

[1:10:53] Gavin Wood: If we go back to basics about what blockchain is about, it's about a trust-free decentralized means of following specific processes. It's about taking the risk and uncertainty from how a system will behave. For Bitcoin that system was currency payments. It was taking the risk and uncertainty out of having your assets seized and about how much it would cost to transfer those assets. For Ethereum it's much more abstract. It has smart contracts, but in essence it's taking the risk and uncertainty out of particular business processes that smart contracts can encode. It's all about taking well-defined processes and removing the risk and uncertainty that they will be executed as you expect.

Governance of a blockchain is a process. If it's not a process, it's arbitrary and probably random. It will only work effectively if it's a process. On-chain governance is simply the effective execution of that process. It's a well-defined, formally defined, strictly defined process and it will be executed as you expect, everybody expects.

The notion that you can — that in some sense it's better to either not have a process or have a vague process that's vaguely followed by people vaguely commenting on social media and getting together in vague groups and vaguely coming to some vague decision. The thought that that is better than having a well-defined strict process that's executed correctly is absolutely nonsensical. It's the most stupid thing that Vitalik has ever said and I can't believe anyone could possibly believe it.

Yes, it is a powerful thing. Yes, there need to be safeguards. Yes, the processes need to be properly designed, but none of that means that it should be done off chain.

[1:13:09] Brian Fabian Crain: Yeah, no, I mean, I agree with you that there is something very ironic and strange to say on the one hand we need to use smart contracts and have this trustlessness and control and auditability, but not when it comes to managing the system itself. So I think that's a completely fair point. However, then there's a question of how is that process managed? Let's say we accept that it should — it will be desirable to have it properly structured and as an auditable process. Then there's still this concern around maybe a small minority of token holders controlling it. And in the case of Polkadot, right, I don't know what the distribution of tokens will look like in the future, but during the fundraiser, I think it was around 50% that were either Parity or the foundation. So of course that does raise the question, if it is an explicit process and if the token holders are the ones that determine it, like how do you then also get a kind of wide support? Or is that something that matters?

[1:14:25] Gavin Wood: So I prefix this answer with a couple of points. The first is that Bitcoin is essentially controlled by Bitcoin Core and seven or eight miners, maybe a few exchanges. Ethereum, if it wants to do a hard fork, is a dictatorship. If Vitalik states this is the way Ethereum should hard fork, ETH will hard fork that way. Ethereum Foundation has a trademark. Vitalik controls the Ethereum Foundation. It's as simple as that. So the governance processes for the major — the top two cryptocurrencies are plutocracy, oligarchy and dictatorship. So I reckon we're doing pretty well if we have stakeholder voting already.

But that aside, yes, there's actually only 30% that will be with the Web3 Foundation on the launch of Polkadot. So although 15% was sold in the original sale, 20% will be distributed one way or another, probably through a few sales and possibly an airdrop before launch. So that means that over two thirds will be in the hands of the many, so to speak. And actually the foundation will be giving away about 10% of its tokens to various people that have helped sort of build it and found it, and community members, hackathons, all of that kind of crowd. And then another probably 10%-ish will go to the teams behind the implementations. At the moment that's primarily Parity, but the idea is to find some other teams as well. So there won't actually be more than 10% held by any individual actor at the time of launch. And that's still a fairly sizable chunk, admittedly. But it's far beyond — far below the amount that would be required to actually push through arbitrary changes to the chain.

Beyond that, I absolutely agree with many of the concerns that are brought up by people like Vitalik and Vlad over stakeholder voting, which is partly why we don't have a strict coin vote model for Polkadot. Even at its current state — and this is meant to iterate before release and even after release — we don't have a straight sort of coin vote of voting per se. It's rather, we do have an adage, a sort of maxim, which is if more than 50% of the coin holders, of the coins, vote to make a change, then the change is made. That just seems to me to be an economically sensible thing because if you don't listen to the majority of coin holders, if actually 51% vote in a particular way, that's such a sizable majority that they could probably fork it and just go along with a new fork anyway, and then you'd be left with a minority of the chain stake staying on the original fork. And that just seems crazy. So having a maxim whereby 51% of the stake — so not 51% of the turnout, critically, 51% of the stake — can choose to sort of choose to evolve the chain. That just seems like a case of self-managing, continued self-preservation, I should say.

Beyond that we have something that's much more sort of adaptive. There's a sort of a council which is this notion of a body that is brought in through approval voting. And the idea is that through kind of deferring to a smaller set of people, they can probably bring about sort of sensible changes or at least propose sensible changes to the chain that allows some degree of fast-movingness, still with a democratic safeguard or a safeguard that's sort of coin-democratic.

Now beyond that, I still — this is a first effort. I don't think this is going to be the final thing, but it's somewhere on the path to something sensible, a sensible way of governing a chain. Beyond that, I do think there's all sorts of interesting avenues to go down. And these are things that we'll be prototyping in Polkadot on the way to release, and that will be continuing to prototype beyond release.

So some of the sort of ideas that have come up. One of the things that Vitalik mentioned was quadratic voting, which is basically where as you skip votes, your votes become worth quadratically more when you do eventually choose to vote. So it's a bit useless without some form of Sybil resistance, but in principle, if you did have this Sybil resistance, then it would become pretty interesting.

Beyond that, there's also the idea that you don't vote with coins. Instead you vote with coins that have been locked. So essentially when you go to vote, your vote is how long you will lock your coins for if your side of the vote turns out to win. So it's like, I think this is a really good upgrade, or I think this is a sensible rescue and I'm backing it with my money because if it turns out not to be a sensible rescue and the price drops, then I'm locked in for that price drop. And everyone else that voted against it gets to sell their DOT tokens or whatever, their currency, and then buy back. If you do another referendum in order to undo the damage or whatever it'll be. So there's a notion of economic motivation. When you get economic motivation, it becomes much more like a market mechanism, much more where people have to put the money where their mouth is. And you end up with something less like a — something that follows less the flaws of a democracy and more the triumphs of the market.

In addition to that, there's all sorts of potential future mechanisms where people can sort of bet on price going up and down based upon proposals. And we've got a few other ideas that are sort of sitting on the back burner about how that might work.

All in all, I think — oh yeah. One of the other things I should mention is the idea of not using coins as purely a way of deciding who should be voting for what or whose opinion should matter, but also using positioning, community, potentially even this notion of there being a body that decides who are dapp authors. Or maybe parachains are able to have votes, have a vote as part of their — part of the sort of notion of being a parachain. So the parachains each have their own individual governance mechanisms that allow their users to influence what happens on the relay chain.

There's also an idea of having voting through transaction fees. So whenever you issue a transaction on the relay chain you can put in a vote or your account at least gets a little bit more voting power. So there's quite a few ideas floating around as to how to make it not purely a coin vote thing. Some of these are things that we've implemented like the council, others are things that we definitely plan on implementing like coin lock-ins for vote. And others are things that sort of definitely deserve further research to see if we can come up with a reason as to why they would work and push forward with implementation if we think that they're promising.

[1:23:14] Brian Fabian Crain: Yeah, I think this is a good point and very much on this topic. So we did have, a few weeks ago, we did an interview with Arthur and Kathleen from Tezos, and he kind of made a similar point, right? This question was like, okay, the goal of governance in Tezos isn't to replicate a democracy, it's to basically build an efficient blockchain. And so I think if you look at it that way, maybe coin voting is less offensive. I think if you look at it coming from the perspective of you being used to the system of democracy that manages this environment that people function in, then I think people get very upset. And if you're like, okay, this is not a good system.

And I think of course also one of the big benefits of especially proof of stake blockchains is if people don't like it, it's really easy to fork, right? And it's really easy to launch a new network and have different distribution of token holders and get rid of the ones you don't like. So I think that also provides this very powerful kind of balance where, okay, maybe a majority of coin voters could decide something in some way that serves them specifically, but if they end up losing the user base because they decide to fork the chain, then that's also a very kind of powerful balance of power that you don't have in an existing political system. You can't just say, okay, I'm going to fork this country and go my own way.

[1:24:38] Gavin Wood: Yeah, I mean, there are certainly separatist movements that kind of would quite like to fork countries, but yeah, it's certainly a lot harder. And one of the things that we're not implementing, certainly not for a year or two, but vague ideas that I've had was actually to make forking the network part of the governance system. So basically when a vote happens, a minority can say, we really don't want this to go in, like to the point where we will destroy our account balances on this chain and fork the chain into a new chain where you guys don't get your account balances, but we get ours. So basically you actually do a split, and that's for both balances as well.

And the idea is, if we can make this a sufficiently trivial operation so that things like exchanges can automatically kind of list these extra tokens when it splits, so it's automatically a means of deciding who gets what name and who gets some derivative name, or even automatically determining the derivative name. That would potentially lead to fewer splits because the majority would actually believe the minority's — like they couldn't help but believe the minority's threats because the minority would be held to it, basically. Their balances would get wiped if the vote went through with the majority.

And because they can make these credible threats, you can also build into the governance system more credible minority support by saying, well, if you're willing to put all of your coins up in order to say no, in order to try and veto it, then we will listen to the veto. We'll say, well, this vote actually got vetoed, it won't go through. It can be revoted again, maybe in a month or in two months or something, but it's enough for them to basically say, you need to think about this some more, guys, because this is a credible threat and the chain will fork otherwise.

And I mean, this is similar to the bicameral system in the UK where you've got the House of Commons and the House of Lords. The House of Lords can't indefinitely block a vote by the House of Commons, but they can send it back to the Commons a handful of times in order to say, look, we really don't think this is a great idea. You guys need to kind of reconsider this. And I think these more sophisticated systems, particularly ones that play on time, that say, well, it's not to say we'll block it forever. It's not to say that a sufficient majority of turnout will always win. It's rather to say that sometimes you just need to think a bit more and you can come to some sort of compromise where both sides are happy.

[1:27:49] Meher Roy: Great. Makes a lot of sense. I'm really curious to see all the governance experiments that will happen on Polkadot. The other thing, of course, is when you have so many different parachains, experiments in governance can happen on these parachains. So we can iterate our way towards better governing these systems over time.

[1:28:11] Gavin Wood: So parachains basically have a similar — I mean they all run on Substrate, so they have similar mechanisms to indeed the relay chain in order to govern themselves, in order to upgrade themselves. And that's kind of — that's very much — I quite like — one of the things that the US's federal system is kind of cool is this idea that states can have various different kind of social economics, they can have different welfare systems, they can experiment with different medical care systems. I think notably, was it Michigan that had a version of Obamacare before Obama brought it in? And it was — who was he? It was one of Obama's challengers that was actually the governor of Michigan that brought in that healthcare system and obviously later said, oh no, I don't —

[1:29:11] Brian Fabian Crain: That was Massachusetts.

[1:29:13] Gavin Wood: Oh, Massachusetts, was it?

[1:29:14] Brian Fabian Crain: It was Mitt Romney.

[1:29:16] Gavin Wood: That's right. Yeah, Mitt Romney, exactly. So the idea that you can have two states next to each other like Texas and California that have vastly different welfare systems, taxation systems and all the rest of it, basically governance systems, is really great because the things that work can be rolled out nationwide and the ones that don't, at least it's only a state that's kind of got a failed experiment on its hands. And I see the same thing happening with Polkadot where each of the different parachains and their communities can experiment with their various governance systems and the things that work get rolled out to Polkadot and the things that don't, well, they stay on the parachain.

Polkadot roadmap

[1:29:57] Meher Roy: Cool. So that brings us to the last theme, which is Polkadot is a very ambitious project, right? So you have new consensus mechanisms, you have Substrate to build parachains, you have interchain communication. There's a lot you need to get right in order to launch the system and have it be a fruitful ecosystem. So where is the project currently at in its life cycle? What works well and what doesn't? And when can we expect to see a release of the mainnet?

[1:30:33] Gavin Wood: So Polkadot itself — we released PoC 2. PoC 2 was actually an on-chain upgrade from PoC 1. That was the first, to my knowledge, on-chain upgrade of a sort of live network, a live public testnet. And yeah, I mean, and it was also — it wasn't just a sort of flaky sort of demo where you've just got like one minor irrelevant thing that's been upgraded. This was like a full runtime upgrade. Huge amounts of things changed. All of the front ends have to change to deal with the new runtime. This was actually a legitimate, completely new testnet. It's just that it happened to have the historical PoC 1 blocks before it, and older PoC 1 Substrate or Polkadot could continue syncing.

Okay, so PoC 2's out. PoC 3 is right around the corner. It's finished, as I said, except for this extra consensus algorithm, which will probably be our final Polkadot consensus algorithm. Pretty excited about that. And yeah, it should be kind of interesting to see.

PoC 4 was scheduled for late in the year, sort of new year time. We're probably a couple weeks behind on PoC 3, so I would guess we're looking more like late January 2019. And PoC 4 basically takes Polkadot to feature completeness. It introduces the interchain communication and it will have a relatively sophisticated consensus mechanism in order to bring in the parachain blocks. It will have the validation, fishermen and the collators. Actually, we already have collators. We already did the parachain thing in PoC 2, so there's actually — I don't know if there's already a parachain deployed. Certainly there have been parachains deployed on closed testnets.

The idea with PoC 5 is to bring in the Substrate executable itself as a parachain collation system so that basically we can start running things like smart contract chains, potentially a Bitcoin chain and a UTXO chain on the testnet, on the PoC, whatever it would be, four or five testnet, and also start playing around with pluggable consensus and hot-swappable consensus and all the rest of it. So that's likely to be done around April 2019.

At that point, basically we'll switch to smaller PoCs and the audit will happen, will begin. So the components that are fixed, things like the consensus algorithm, the WASM interpreter and a few other bits will start being audited probably towards the end of this year. And the auditing will be going on sort of in the background and as more and more gets sorted, it'll just sort of flow into the audit.

I would say we're still roughly on track for our original release date of autumn 2019. Probably be towards the end of Q3. I'm going to eat these words. I know software projects are never on time, but I'm going to say them. There we are, end of Q3, 2019. We'll know more once PoC 4 is done. As I say, PoC 4 is basically feature completeness. And at that point we'll be fairly happy about the protocol and it's really just about getting the audits through.

Yeah, that's basically it. Our SDK is basically Substrate and that's going to be continued to be developed. So parachain development can basically already be started and hopefully those parachains, those sorts of chains that are being developed in Substrate now can be deployed to Polkadot with relatively few code changes around maybe March time next year for that Polkadot PoC testnet. Yeah. But we are slowly getting to the point now where it's starting to feel quite real and that's encouraging.

[1:35:10] Brian Fabian Crain: Cool. Well, Gavin, thank you so much for coming on. That was super fascinating to speak with you. And I mean, there's really a lot of very interesting things you're working on, a lot of great innovations. So yeah, thanks so much. It's exciting and look forward to seeing how Polkadot develops and how it will do in the real world.

[1:35:28] Gavin Wood: Cool. Thanks for having me on the show and I look forward to coming back in another four years to chat about what indeed did happen.

[1:35:40] Narrator: Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv/subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter so you get new episodes in your inbox as they're released. If you want to interact with us, the guests, or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show and we're always happy to read them. Thanks so much and we look forward to being back next week.