Gavin Wood

Substrate, Polkadot and the Case for On-Chain Governance

From one of the main Ethereum clients, to Polkadot to Substrate; Parity has become exceptional at developing successful open-source blockchain projects. Their latest effort Substrate provides a framework to easily create custom blockchains. Building on cutting-edge technologies like Web Assembly, Substrate also offers automated on-chain upgrades.

We were joined by Gavin Wood, who was previously co-founder and CTO of Ethereum and founded Parity. We talked about the early Ethereum days, how Parity got started, Substrate, Polkadot and his views on on-chain governance.

Topics we discussed in this episode
  • The genesis story of Ethereum
  • Why Gavin prefers reasoning from first principles to reading
  • How Parity shunned Silicon Valley principles to build an developer-driven company
  • Why they decided to work on a scalable blockchain from scratch instead of improving Ethereum
  • An overview of Substrate
  • The relationship between Substrate and Polkadot
  • How Substrate allows switching consensus in a live blockchain
  • Why Ethereum’s governance process is centralized
  • Polkadot and the case for on-chain governance
Sponsored by
  • Microsoft Azure: Deploy enterprise-ready consortium blockchain networks that scale in just a few clicks. More at aka.ms/epicenter.
  • Toptal: Simplify your hiring process & access the best blockchain talent
. Get a $1,000 credit on your first hire at toptal.com/epicenter.
Transcript

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, 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, Meher and I did want to speak a few minutes about a project we’ve worked 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 been our main focus since then. What we’ve been doing is we’ve been building validators and staking infrastructure for Proof-of-Stake networks. Also some slight disclaimer really, we haven’t yet done much work on Polkadot but it’s definitely one of the projects we’re very interested in, also working at it from that end, so we have this kind of relationship also from that end.

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. 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.

Brian:  Yeah, 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 in time blocks, that’s very interesting to think, also look on it. 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.

Hi, so we’re here today with Gavin Wood. 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. I remember recording that in Gavin’s apartment just briefly after he moved to Berlin. That was much before Ethereum had launched. I think it was just during the time of the Ethereum fundraiser, one of our very early episode, pre-video and a long time ago. Of course Gavin has done a lot of important work in the blockchain space. He joined the Ethereum project very early on. At the very start, he wrote the yellow paper back then, so it was a technical specification of Ethereum. He was the guy who originally developed Solidity and the C++ Cobalt client and then went on to do a lot of other important things including founding Parity and now Polkadot, so there’s lots to speak about. Thanks so much for coming on today, Gavin.

Gavin Wood:  Thanks for having me, Brian.

Brian:  First of all, tell us a little bit, how did you originally learn about Ethereum and blockchain and get involved back then?

Gavin:  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 didn’t seem particularly interesting, kind of pointless bottletop currency. I think I was not in a minority in basically writing it off as an irrelevant experiment. A couple of years passed and it’s early 2013 and I see these stories about the Silk Road and I see stories about how bitcoin is being used to facilitate this stuff. There were people using this. That was the first surprise, like wow. I kept an eye on the stories and I found one guy whose name is Amir Taaki and this guy seemed to be a revolutionary, crypto programmer, cyberpunk revolutionary guy so I figured he was an interesting kind of guy to speak to. So I reached out to him. I’ve done a lot of coding in the open source world for 10 or 15 years before and I had an email address that demonstrated this. I have a kde.org email address from the times that I was a KDE coder. I knew Amir would recognize it so I used that and sure enough he replied.

He invited me to his squat, the same one that I had seen him being interviewed in, which was interesting. I got the train down to London, met up with him. I met up with a couple of his friends as well. One of them was Mihai Alisie. I actually randomly said hello to Amir through this door opened to one of the rooms in the squat and Mihai was there in bed with his girlfriend Roxana, and Amir was like, “This is Mihai. He does Bitcoin Magazine.” I was like, “Hi,” and Mihai was like, “Hi,” and Roxana was like, “Hi.” But he closed the door. It was an odd scene. Anyway, he introduced me to another guy called Jonny Bitcoin, Jonathan James Harrison. He was a 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. He’d been talking to Vitalik about what he was thinking and this was pre-Ethereum. But not long after, Vitalik started sending early versions of the Ethereum whitepaper to various people in his email address book and one of them was Jonny Bitcoin.

When he found out about Ethereum, he thought it was a cool idea and he mentioned it to me in one of our times down the pub having a pint together. I was saying, “I’m such a good programmer,” and he was like, “If you’re such a good programmer, you should just go and program Ethereum.” I was like, “Fine, I will do.” I downloaded this whitepaper and I think even Jonny sent it to me, and he made the intro with Vitalik so I started chatting to Vitalik. 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 swept away into this new world.

Meher:  What was it about Ethereum that captured your imagination when bitcoin hadn’t done the same thing?

Gavin:  There are a few points, I guess. One of them was that I knew roughly how blockchain worked but I kind of learn things by implementing them and it seemed that Ethereum was a more enjoyable, a more pointful thing to implement than bitcoin. It’s like why would I implement something that’s already got two or three implementations that are perfectly good enough? Ethereum was relatively nicely specified. It turned out that there were quite a few holes in the specification but it was good enough to get going. That was just nice. That was a nice, clear coding mission to go on.

I was also curious to see how well it would work. It was doing stuff that hadn’t been done before. I was pretty sure that it wasn’t going to work but I figured that with enough tweaking it might eventually do something interesting. It wasn’t until later that I really got to grips with what Ethereum was and why it was so special.

Brian:  You said later you realized 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 some while to understand?

Gavin:  Fast-forward a couple of weeks and I’ve been implementing this for, I don’t know, four weeks or so and I get noticed that we should meet up in Miami, everyone’s going together. It was meant to be a hackathon. We were meant to all get down and finish coding Ethereum. It turned out that I was actually the only real coder that was there. Everyone else was busy doing other stuff. It was during that time in Miami that I was exposed a lot more to the bitcoin world, I was exposed to many different bitcoin people, I was exposed to some very interesting people, some self-declared philosophers and so on. 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 cryptofinance 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 cryptofinance 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 cryptofinance, is Ethereum just another cryptofinance? That’s how it was presented to a large degree in the whitepaper. If you read the original whitepaper, it had a little bit to do with smart contracts but a lot of the general gist was really a 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 nuts and bolts, purists, we’re making a platform for deploying and executing smart contracts. It was at that time that I was thinking, “Well, what is this platform? What does it do? What’s the generalization of it?” It was there that I figured, well, this is 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 there. They’re set by game theory but they’re different to laws of nature in that we can program them ourselves.

That was very interesting and it was 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 economic foundation for society.

Meher:  You mentioned another thing that you learn by implementing. Is that a habit you still continue?

Gavin:  Absolutely, yeah. You’ve got to balance it with some forethought, especially when you’re doing things like design, like protocol design. Particularly 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. 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. It forces you to really manage all of these edge cases, all of the corners that you might not think of when you’re considering the general vision or the direction that you want to move in. It’s very easy to get a concept, get an idea of something and think that you’ve designed it through, think that you’ve got it all covered. Then when it comes to coding, it doesn’t compile or you can’t code it in the first place. 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.

Meher:  Interesting. Would it be right to say that you’re not somebody that reads a lot of whitepapers necessarily? You get interested in an idea and you maybe write your own paper and you build it.

Gavin:  Yeah. I don’t know, I 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 keep saying and arguing new things, things that just seem correct to you from first principles, and eventually you’ll start discovering things that no one else has argued or discovered before. That second part really definitely appeals to me. I find that if I read too much, it’s 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, psychologically speaking, other parts. I can see the balance of like 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 and build on it.

But similarly in these very early stage industries where lots of ideas are floating around, believing that something is the optimal solution and just automatically using it or automatically assuming that that’s the case I think could be hugely problematic. I like to chat to people about new things because in that case it’s very easy to delve to the bottom of something and you can better understand whether it really is the best way of doing something, you understand the tradeoffs perhaps that were made, you can challenge. But that’s not the case for the whitepaper. Whitepapers are often written again like, as I mentioned before, the design of something. They’re not real implementations which means a whitepaper 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 whitepaper. But it means that it’s actually not the optimal solution and it’s maybe not even a good solution.

Meher:  I could see this approach working when let’s say you were an individual contributor, so you were maybe doing a PhD then you’d build Ethereum. Now you are also managing this organization and presumably there are 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?

Gavin:  Yeah. Thankfully I don’t have to do management. I managed to sneak out of that one. It’s definitely not my favorite thing. My role within Parity is I’m basically a team lead. I’m the one that tells people, “Look, you really need to review these people P.R.s.” I’m the one that sets the milestones. I’m the one that sets the whitespace policy which is I can’t tell you how important that is. But I’m not the one that has to manage per se. 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 if they 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 involved in for 15, 20 years now.

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. That’s what suits me the best. 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.

Brian:  Speaking about organization building and management, of course you did work for Ethereum, so you’re the C.T.O. of Ethereum but then pretty soon I think the Ethereum organization went into many different directions and it spun out a bunch of different organizations but one of them was yours which was called Ethcore and afterwards Parity. When you started Parity, what was the vision for Parity both in terms of what kind of organization you wanted to build but also what kind of impact you wanted to have with Parity?

Gavin:  I think it would be fair to say that some of the early days with Ethcore or 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. This is late 2015, early 2016. The industry was crazy, lots of things coming in. There was the DAO going on, there were teams coming in, there was a whole I.C.O. thing happening. It was a very generally mad time. There were lots of things pulling our attention. There was the idea of what about enterprise blockchains, what about building stuff for companies. Microsoft seemed to be coming in at the time with their sponsorship of the Devcon 1. There was also the idea of building out web3 and what if we did Swarm and Whisper and we put it onto a browser. It wasn’t clear that Mist was being developed at a substantial rate.

There were lots of ideas. There were lots of potential directions. 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. 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. Until then I was half buying into a lot of these Silicon Valley self-help books where they’re like, “You need to think about marketing and you need to think about company building. You have to have these particular points of culture.” There are so many of these books and they give you all of these bits of guidance, rules to follow.

The idea of building a company that was really just about being 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 the thought that dare not share itself because I figured that 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. I think a lot of that is down to my influence. We really do have a developer-driven mentality within Parity. Marketing and business development and product I wouldn’t say is necessarily lagging far behind, particularly product. 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.

That’s really enjoyable. When you’re driven from this kind of technical standpoint, it makes development so much faster because you have an idea about what it is that you want to get done. You have a very 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.

Meher:  I clearly remember I saw posts around information of Parity and I think the first target was to build a client for Ethereum. My first question in my head was who’s going to fund this team, who’s going to fund the building of this company that builds a client for Ethereum? Then a few months later you did raise your first round with 700,000 or something like that. You threw out at least parts of the Silicon Valley playbook, your first product wasn’t something that would generate enough money. Did you not struggle to raise money and get the company going?

Gavin:  Honestly, struggled but it was not something that we were going to get tons of millions for. At the time, we were seeing R3 start to raise crazy amounts. We saw 21 raise a huge round. Blockstream raised a huge round. I think Digital Asset Holdings, Blythe Masters’ thing, they also had a pretty big raise. There were people who were raising really huge amounts of cash for, in principle, at least blockchain-based products. R3 steered away from it in the end but that was its original suggestion. We considered ourselves to be more or less of the same class. We were developing next generation blockchain and in my mind, we had the better technology. I wasn’t super worried that we were on the wrong path.

That said, we weren’t industry heavyweights. Ethereum was still down at 80 cents or so at that time. It had gone up 2x, 3x more or less from the sale but no one really cared. We didn’t really have any huge amount of credibility. People could see that there was a platform behind us but there wasn’t much doing with the platform. Bitcoin was still very much king. Thankfully we had some people that did believe in Ethereum, if you like, believe in the platform. They were very quick to get us started. We didn’t really do the whole Silicon Valley thing of going around all of the things and having a pitch deck and having really slick product slides. We were like, “Look, we’re going to make an Ethereum client. We think Ethereum is 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 an enterprise play.

This could be an open source user-based play, we don’t know yet but we think it’s probably worth doing.” And, yeah, there were people who said, “Cool. We think you’re a good team and I think you’ll sort of be able to take it somewhere,” which was cool. And I’ve grown kind of 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 a bit of a club and tyou 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 get shipped build company. And that’s, yeah, I kind of go a little bit kind of . . . what’s the word? Not disappointed, but I think Silicon Valley has a higher opinion of itself than it deserves I thought so.

Brian:  Yeah, no, absolutely, I mean, it’s also interesting though that you had 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 of VCs where they’re like, “Okay, no, we missed Ethereum, so now, we’re going to have to fund the next Ethereum,” right? And 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 what was the genesis story of Polkadot?

Gavin:  So 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, I can’t remember exactly. And we’re kind of waiting with bated breath on Ethereum one and a half or Ethereum 2. We kind of waiting for this sort of new whiter paper to come so that we can start implementing it and, basically, there were bunch of things that happened. There was the doubt that kind of stole some attention from the core development team. And there were few other kind of bits and bobs. And it started to get a bit kind of, “Is this every going to come?”

And so sort of an off-chance conversation with Marrach one of the sort of kind of founder, developers of Parity, while we were in San Francisco, but Marrach sort of said, “Well, what if we sort of 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 I searched it, it’s substantially more complex.

So I kind of thought, “What if we could . . . let’s forget China, make it as Ethereum . . . as transparent as possible over 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, like, pretty much in the same conversation, I think we’re having a beer a maybe in San Francisco and it was there that I realized that you’re going to need the kind of, I think Ethereum calls it the beacon chain, but you need this 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. In the early days, he was in favor of different shards, having different levels of security. And it’s also similar to some of the other multi-chain designs like Bitcoin side chains 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, hardcode it, hardwire it 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 were all, basically, implement a 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 arbitrarily, like, kind of just general, just a bunch of bites, basically, then there’s actually no need whatsoever for them to all be the same. And that’s where the idea of the heterogeneous multi-chain came from rather than the homogenous multi-chain that is Ethereum 2.

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 the 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 that can just be linked, they can just be sort of executed and you can store what the software to actually validate these things or and the specification, the definition of a valid parachain shard. We 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 like the nature of the blockchain. It’s like Bitcoin has a particular nature, it’s to do with spend transaction outputs, it’s a very much currency chain. Ethereum has a different nature. It’s a smart contract chain. So you can actually define chains, they’re kind of different natures. And they can all sort of exist within this community, whether all being secured by the same operators 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 we didn’t really want to kind of jump the guns so to speak, but it seemed a lot of more reasonable to implement something that in and of itself was going to be a next generation play.

Meher:  Very interesting. So this progression of ideas is really nice. So Ethereum, okay, and within the sharded Ethereum or then we’ll need the central chain to be the arbitrator of final validity of some kind. Then like the idea of these parachains or these side chains, 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 manner, right? And so that leads into you picking like WebAssembly and allowing the straight 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 road that you did not pursue?

Gavin:  I mean, in principle, there were a couple of potential candidates. The most sort of obvious one, I guess, is L.L.V.M.’s I.R. code. So L.L.V.M., 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’s basically just passes 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 a specific hardware. L.L.V.M. looks after all of that for you. And so one of the ideas was just to use this intermediate representation or I.R. from L.L.V.M., which in principle, at least, is not architecture specific.

The problem with that is that it’s not designed to be architecture independent. Some architecture, there are particular I.R. up-codes or sort of I.R. 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’ve tried to use E.V.M., but, again, E.V.M. 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, it was me who gave it the E.V.M. before I came along, sort of the original incarnation of Vitalik’s white paper. It’s called ether script.

And it was really meant to be a scripting language. It was some of the early ether script 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 sort of came along, like, 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 leveled but it has some fairly high level aspects to it where 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 there, the storage at least, instead of in terms of 256-bit words.

And that basically means that almost all low level code is massively suboptimal because it’s all based from in these huge hip allocated chunks of memory, even though, only one or two bites of them are being used. So we kind of ditched that idea pretty quickly. I mean, 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 sort of the C.P.U. architecture. But one that was sufficiently kind of risk enough, so reduced in structure set computers where risk stands. And the idea is that it’s not got very many up-codes, it’s very simple.

So in principle, you can retarget it, you can recompile it into a sort of another architecture without losing too much performance. And the obvious one was A.R.M., the A.R.M. targeting, something like A.R.M. B5, but, again, we sort of having thoughts 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 a really well performing compilers that trans-compile it from WebAssembly into the native architecture. L.L.V.M. targets it natively, so it’s basically as good as something hardware like A.R.M. except it’s 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 sort of a primary thing that it imports and exports. It’s basically designed to be developable rather than designed to be implemented on fast hardware. And so, yeah, we figured it was probably the best choice and certainly in terms of its future, definitely, the best choice.

Meher:  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 e-chain has its own individual D.N.A. It’s specialized to do something unique which others are not. And so you want a way to express the individuality, the individual D.N.A. of e-chain in some like common way and what Polkadot is doing is it’s saying that the individuality of e-chain is its straight transition function, which is “Here’s the current state of the ledger, incomes, 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 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 are using this insight to build Substrate?

Gavin:  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 are doing . . . from the ground up, we’re building this software stat for Polkadot and I really hate seeing codes not be able to be reused. It’s kind of like food waste. That’s like, “Come on. Someone can eat this thing. I don’t like to throwing it away. I prefer to put it in a Tupperware and save it for later.” And this kind of Tupperwaring 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’s actually just generally good practice. There’s a lot to be said about this. If you sort of modularize your code, then it also makes it generic, which means that you have to be much more clear about what the interface is on, what’s been most popular 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 documentations probably going to be a lot better because you’re now having to document for external 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 the 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. There was at one point, I did a giant rename and sort of many of the Polkadot modules became Substrate modules and now, we’re sort of continue refactoring 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 light chains but not exactly light chains. And we always knew that there’s going to be some sort of S.D.K. . . . 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 sort of 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. That has much of the sorts of algorithms and the separate things that you need for building parachains, things like sinking the chain, things like P.R. networking.

And although that’s not finished yet, we’re still very much working on sort of 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 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 and 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 the 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 P.B.F.T. derived sort of consensus thing called Rhododendron. And that’s fairly similar to Tindermint that the Cosmos guys are using. We also have now Aura implemented and a derivative Aurora all around, which basically just introduces shuffling to the authorities. And one of things that’s sort of being actively merged at the moment is the G.R.A.N.D.P.A. algorithm that I call it S.H.A.F.T. actually, so it’s like kind of shaft. Sometimes, it’s called S.H.A.F.T., sometimes, it’s called G.R.A.N.D.P.A. I forgot what G.R.A.N.D.P.A. stands for but S.H.A.F.T. stands for Shared Ancestry Finality Tool.

And this is a new consensus algorithm that we came up with. I’ll say Web3 Foundation’s research team came up with sort of in concept 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 sort of mechanism. And what this means is that if you can code your chain in the 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 called the state transition function or the sort of nature of the network, the thing that interprets the transactions, executes the blocks, like 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 the set as the chain is ongoing. So you can switch between consensus algorithms even. You can move it from being a chain that sort of busy, going along on its own to one that’s integrated into the Polkadot. You can change it from a Rhododendron P.B.F.T spell chain into a G.R.A.N.D.P.A. chain or even a proof-of-work chain.

You can just switch between them as you choose. And the same could 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 that are kind of fixed functions chains because you have to go back to, 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 every using Ethereum has to opt in to the change and if they don’t, then they’re going to continue on the older version of that chain and they’ll come out of consensus.

Brian:  Yeah. So that was super fascinating what you talked about how Substrate works in this space. So let me just sort of rephrase it to see if I understood it correctly, right? So, yeah, Substrate is like framework for developing a blockchain. Now, if somebody who’d go today or today or maybe in a few months, but, like, in the very near future or maybe today and build this Substrate blockchain and now, they could use, for example, the existing consensus algorithms you have or maybe G.R.A.N.D.P.A. or maybe your Tindermint-like algorithm or something that exists today, they launch this blockchain and now, a year from now or something like that, Polkadot launches on the live chain and 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 be like on the security off the relay chain.” Is this . . . this would really be possible?

Gavin:  Yeah, that’s right. So that’s the sort of used case we’re designing for. So, yeah, pretty much all of the existing consensus algorithms require you to name validators, either hardcode them or more likely 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 if they lose some of their stake, if they do anything. 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 sort of runtime itself. So it’s like literally a storage item. You’ll basically just say, “Yeah, change this particular bits of storage. using G.R.A.N.D.P.A. or Rhododendron or whatever the consensus algorithm that the chain is using as to use parachain or we want to use parachain slot 42 and stuff.” All right. Cool. And as long Polkadot is expecting you, then it will just seamlessly sort each other out.

Brian:  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.

Meher:  So, of course, Substrate is very ambitious and so where is it currently at? As far as I’m aware, your plan is to release 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?

Gavin:  So we haven’t actually made any release, our schedule is to release our beta, 1.0-beta of Substrate real soon now, like, ideally before the Web3 Summit. So that’s like in a few days’ time. It’s certainly most of the codes that’s being 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 and the instant finality one, that’s a bit like Tendermint. It will have the G.R.A.N.D.P.A. finality algorithm. And I don’t know if we can talk about it about later, but it’s our sort of new, cool consensus sort of algorithm, that’s an iteration all to beyond the Rhododendron. And it has some stuff in common with the Ethereum 2.0 consensus algorithm. It takes a slightly different road but it is 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 derived probably from a Ouroboros which 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.

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 is 1.0 beta becomes 1.0 will be working a lot more on the tutorials. There may be some minor API tweaks but by large what you develop on 1.0 will be usable for the foreseeable future.

Brian: Great. 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? Today when you have an upgrade of significant consensus affecting upgrade of a blockchain and in general have a hard fork, right? There’s this big discussion around it, and then as hard fork happens people actively would 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. Here, we have basically these automatic updates where I don’t have to upgrade the client.

First of all, what is the big downside with hard Forks and how do you still have this level of accountability or control? Or this does lead to a lot of risks as well having automated upgrades?

Gavin: I think it’s fair to say that automated upgrades are like a sharp knife. They’re very powerful. You want 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 misused because they have the power to break your chain basically. As I demonstrated on the first on-chain upgrade last in 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 use them they’re going to expect them to be used.

Most disruptive technologies are powerful and there’s inevitably a bit of an outcry from the side,  especially the sides that are in some sense faked 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 follow-ups to Bitcoin that are better in various ways and yet the money is still behind Bitcoin and that’s 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 that blockchain being something that a lot of people in the blockchain think immutability , this idea that chain is well defined, that it should never move beyond the confines of that initial definition are forever at odds with those that believe blockchain should evolve.

Which means every time 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 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 very self-selecting ecosystem, the trustless or trust-free ecosystem basically full of people who 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, right? 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 or want to upgrade our consensus pretty much. The whole thing smacks of a bit of a Shakespearean comedy. 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 it’s like . . . that’s so different.

What we’re doing is exactly the same as what we’ve been doing already. The only difference is that we’re extending it a level up and we’re saying, “Well, look, these very important things that happen on the chain, potentially huge balance transfers, things like the DAO where you’ve got smart contract that’s controlling tens, hundreds of millions and it’s[fraud in some way.” Well, we’re just saying, well 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 usually they have some governance structure even if it’s like this one guy and he holds the key, a lot of them are much more complex than that, a 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 want to spend the 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’d prefer you to run rather than the code that’s running at the moment, we should run this other code.” It’s really just the case of extending the software model of a smart contract one stage higher and taking it onto the blockchain level. Really the only question that’s left, I mean, I don’t see a greater ability as any kind of a controversial thing. Yes, it’s powerful but so are smart contracts. It’s the fact that you can control money without having a resource to an organization, based purely on an algorithm. It’s really powerful. It’s fine, but we’re all here because we recognize the power and we think it’s probably a good thing for the world.

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 center?

Brian: Now, of course, Vitalik, and Vlad, and a bunch of the Ethereum people have argued that smart contracts is great but then the governance process, it’s better if that takes place off chain and if people can’t even have this like social consensus. And I think there’s a variety of reasons for that. I think that’s probably fewer 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, right? Because that’s 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 they will release plutocracy and controlled by the small group of token holders. What is your view of both of those concerns?

Gavin: 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 to our 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 of uncertainty that 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, as everybody expects. The notion 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 that 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. Thus, 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 doing off chain.

Brian: 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 contract and have this trustlessness control, and then auditability, but not when it comes to managing the system itself. I think that’s a completely fair point. However, then there’s the question of how is that process managed? Let’s say we accept that it would be desirable to have it properly structured and as a auditable process, then there’s still this concern around maybe a small minority of token holder’s controlling it. And in the case of Polkadot, I mean 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 the Parity or the foundation.

Of course, that does raise the question, if it is explicit process and if the token holders are the ones that determine it, how do you then also get a wide support, or is that something that matters?

Gavin: I’d prefix this and then serve 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. The governance processes for the major two, the top two cryptocurrencies are Plutarch plutocracy/oligarchy and dictatorship. 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 the 15% were sold in the original sale, 20% will be distributed one way or another, probably through a few fails and possibly an airdrop before launch.

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 build it and found it and community members, hackathons, all of that kind of crowd. And then another probably 10% 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. 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 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 just coin vote model for Polkadot. Even at its current state, and it doesn’t meant to iterate before release and even after release. We don’t have a straight point all the voting per se. It’s rather we do have an adage, a 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 the 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 like a minority of the chain or of the chain’s stake staying on the original fork, and that just seems crazy. It’s like having a maxim whereby 51% of the stake, so not 51% of the turnout critically, 51% of the stake can choose to choose to evolve the chain. That just seems like case of the self-managing, continued self-existence. Self-preservation I should say. Beyond that, we have something that’s much more adaptive. There’s a council which is this notion of a body that is brought in through approval voting and help. The idea is that through deferring to a smaller set of people they can probably bring about sensible changes or at least propose sensible changes to the chain that allows some degree of fast moving but still with a democratic safeguard or a safeguard that’s sort of coined democratic.

Now beyond that, 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 will be prototyping in Polkadot on the way to release and that will be continuing to prototype beyond release. Some of the ideas have come up. One of the things that Vitalik mentioned this quadratic voting which is basically where as you skip votes your votes become worth quadratically more when you do eventually choose to vote.

It’s a bit useless without some form of civil resistance but it’s not in principle if you didn’t have this civil 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. 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. 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 the price rises, if you do another referendum in order to undo the damage or whatever it will be. There’s a notion of economic motivation. When you got 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 that follows less the flows of the democracy and more the triumphs of the market. In addition to that, there’s all sorts of potential like future key mechanisms where people can bet on price going up and down and based upon proposals. And we’ve got a few other ideas that’s 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 the purely 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 DAP authors or maybe parachains are able to have votes, have a vote as a part of the notion of being a parachain. The parachains each have their own individual governance mechanisms that allow their users in order to influence what happens on the relay chain. There’s also an idea of voting through transaction fees. 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.

There’s quite a few ideas floating around as to how to make it not purely a coin vote things. 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 other things that 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.

Brian: Yeah. I think this is a good point, and like very much on this topic. We did have a few weeks ago we did an interview for Arthur and Kathleen from Tezos. And he made a similar point, right? This question was like, okay, the goal of governance in Tezos isn’t to replicate the democracy, it’s to basically build an efficient blockchain. And so I think if you look at it at 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, right? 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 sake 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. I think that also provides this very powerful balance where, okay, maybe a majority of coin voters could decide in 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 very powerful balance of power that you don’t have an existing political system, right? You can’t just say, “Okay, I’m going to fork this country and go my own way.”

Gavin: Yeah. I mean, there are certainly separatist movements that I would quite like to fork countries, but yeah, it’s certainly a lot harder and I mean, 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 government system. Basically when a vote happens, a minority can say, “We really don’t want this to go in 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.” Basically you actually do a split and that’s for balances as well.

And the idea is if we can make this a sufficiently trivial operation so that things like exchanges can automatically lift these extra tokens when it splits so there’s automatically a means of deciding who gets what name and who gets some derivative name, or even like automatically determining the derivative name, that would potentially lead to fewer splits because it’s like the majority would actually believe the minorities like they couldn’t help but believe the minorities threat 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, we don’t want to try and retail 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 reverted 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 that the chain will fork otherwise.” And I mean this is similar to the bicameral system in the U.K. 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 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 compromise where both sides are happy.”

Meher: 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 and governance can happen on these parachains. We can iterate our way towards better governing these systems over time.

Gavin: Yeah. Parachains basically have a similar . . . I mean, they all run on Substrate so they have similar mechanisms indeed to the relay chain in order to govern themselves, in order to upgrade themselves. And I quite like one of the things that the U.S.’s federal system is cool, is this idea that states can have various different 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 challenges that was actually the governor of Michigan that brought in that healthcare system, and obviously later said, “Oh no, I don’t think . . .

Brian: That was Massachusetts, a . . .

Gavin: Oh, Massachusetts . . .

Brian: It was there was Mitt Romney.

Gavin: That’s right. Yeah, yeah. Mitt Romney, exactly. 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 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 roll out to Polkadot, and the things that don’t, well, they stay on the parachain.

Meher: Cool. That brings us to the last theme, which is the Polkadot is a very ambitious project, right? You have new consensus mechanisms, you have Substrate to build parachains, you have interchange communication. There’s a lot you need to get right in order to launch the system and have it be maybe a fruitful ecosystem. Where is the project currently at in its lifecycle? What works well and what doesn’t? And when can we expect to see a release of the main name?

Gavin: We released PoC2. PoC2 was actually on-chain upgrade from PoC1, that was the first to my knowledge on-chain upgrade of a live network, a live public test net. And yeah, I mean it wasn’t just a flaky demo where you’ve just got like more minor relevant thing that’s been upgraded. This was like a full runtime upgrade. Aand huge amounts of things changed. All of the front times have to change to deal with the new runtime. This was actually a legitimate and also completely new test net. It’s just that it happened to have the historical PoC1 blocks before it. And all the PoC1 substrates or Polkadot could continue thinking.

Okay. PoC2 is out. PoC3 is right around the corner. It’s finished as aside except for this extra consensus algorithm, which will probably be our final Polkadot consensus algorithm. Pretty excited about that. And yeah, it should be interesting to see. PoC4 was scheduled for late in the year, New Year time. We’re probably a couple weeks behind on PoC3, so I would guess we’re looking more like late January 2019. And PoC4 basically takes Polkadot to feature completeness. It introduces the inter-chain communication and it will have a relatively sophisticated consensus mechanism in order to bring in the parachain blocks, it will have the validation, the fishermen and the collators.

Actually we already have collators. We already did the parachain thing in PoC2. I don’t know if there’s already a parachain deployed. Certainly there have been parachains deployed on closed test nets. The idea with PoC5 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, a UTXO chain on the test net, on the PoC, whatever it’ll be, four or five test net. And also start playing around with applicable consensus and hot-swappable consensus thing and all the rest of it. That’s likely to be done around April 2019. At that point basically we’ll switch to smaller PoCs and the audit will begin, so the components that affect things like the consensus algorithm, there was an interpreter and a few other bits, we’ll stop being audited probably towards the end of this year and the auditing will be going on in the background.

And as more and more gets sorted it’ll just flow into the audit. I would say we’re still roughly on track for our original release date of autumn 2019. And probably be towards the end of Q3. I’m going to eat these words, I know software projects never on time, but I’m going to say there we are, end of Q3 2019. We’ll know more once PoC4 is done. As I said, PoC4 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 that’s parachain development can basically already be started.

And hopefully those parachains, those changes 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 test net. Yeah. But we are slowly getting to the point now where it’s starting to feel quite real and that’s good.

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

Gavin: Cool. Thanks for having me on the show and I look forward to coming back in another four years. See what we’re going to chat about, what indeed did happen.