Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Gavin Wood: Substrate, Polkadot and the Case for On-Chain Governance

Episode Date: October 31, 2018

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 covered 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 Episode links: Parity Technologies Website Polkadot Website E199 - Peter Czaban - Polkadot: The Internet of Blockchain Networks Substrate: A Rustic Vision for Polkadot by Gavin Wood at Web3 Summit 2018 Substrate in a nutshell What is Substrate? How Polkadot tackles the biggest problems facing blockchain innovators Substrate testnet launched Epicenter episode from 2014 with Gavin Wood about Ethereum & Ether Sale Thank you to our sponsors for their support: Deploy enterprise-ready consortium blockchain networks that scale in just a few clicks. More at aka.ms/epicenter. Simplify your hiring process & access the best blockchain talent . Get a $1,000 credit on your first hire at toptal.com/epicenter. This episode is hosted by Brian Fabian Crain and Meher Roy. Show notes and listening options: epicenter.tv/259

This is Epicenter, Episode 259 with guest Gavin Wood. This episode of Epicenter is brought 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.m.s.S.compsenter. And by TopTow. 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 toptile.com slash epicenter. Hi, and welcome to Epicenter. My name is Brian Parin. 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,

Polka, Parodies. 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, Mejana, 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 Course 1. 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, you know, we've been building validators and kind of staking infrastructure 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 at it from that end. So we have this kind of relationship also from that end. 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 will be a positive some game with Epicenter. and the viewers will get more insightful questions from the two of us because we have this experience with Corus 1. 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, you know, we've had so many conversations about so many different projects and have this, you know, fairly superficial knowledge of a ton of different things going on.

But then when you actually try to build, you know, this fundamental infrastructure that will make a blockchain work and, you know, actually make it secure inside blockchain. That's very interesting to think 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, you know, DefCon is going on in Prague.

Sebastian is in Prague. I am in Prague. Unfortunately Mejou, you can't make it this year. But, you know, we have a few other people. Sonny, 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 730 to 930. So I hope to see many of you there. If you want to learn more about it, just go to episode.com.4. That's D-E-V-C-O-N-4.

And you know, you can learn about the details there. And I hope to see many of you there. And now let's go to the conversation. Hi, 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. I think it was just around the time of the Ethereum fundraiser during the Ethereum fundraiser. So one of our, you know, 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 that was kind of a technical specification of Ethereum. And he built, you know, 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 PolkaDoh.

So there's lots to speak about. Yeah, thanks so much for coming on today again. Thanks for having me, Brian. So first of all, tell us a little bit, like how did you originally learn about Ethereum and blockchain and get involved back then? I guess it started in 2013, really. I was aware of Bitcoin a couple of years before

when it first hit slash dot. but I don't know it kind of didn't seem particularly interesting kind of pointless bottle top currency you know I think I was in the 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 this stories about the Silk Road and I see you know stories about how you know Bitcoin's being used as you know to facilitate this this stuff and it's uh you know it was like wow this is i mean there are people using this that that was a that was the first kind of surprise it's like wow um and i i sort of kept an eye on the stories and i found one

guy whose name is amir taki and uh you know this this guy seems to be kind of a revolutionary a kind of crypto programmer you know cypher punk kind of revolutionary guy so i figured he was an an interesting kind of guy to speak to so i i reached out to him. I've 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, you know, 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 Elisi, who I actually randomly said hello to him. Amir sort of threw this door open to one of the rooms in the squat, and Mihai was there in bed with his girlfriend, Roxanna. And he was like, oh, this is Mihai. He does Bitcoin magazine. I was like, hi. And Miya was like, hi and Roxanna was like hi and then he closed the door again it was kind of an odd kind of scene anyway we 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 and he'd been chatting to Vitalik about what he was thinking and this was kind of pre-a-thes 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. And when he found out about Ethereum, he sort of thought it was kind of a cool idea. And he mentioned it to me, 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, you know, I'm such a good programmer. And he was like, well, if you're such a good program, you should just go and program Ethereum. I was like, fine, I will do.

So I downloaded this white paper, or I think even Johnny sends it to me. And he made the intro with Italic, so I started chatting to Patelic. And yeah, 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. And so what was it about Ethereum that, you know, kind of captured your imagination when, you know, Bitcoin hadn't done the same thing? I think, I mean, there's a few kind of points, I guess.

One of them was that, you know, I kind of knew roughly how blockchain worked, but I, you know, I kind of learned 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, you know, why would I implement something that's already got like two or three implementations that are perfectly, 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, it was good enough to get going. And that was, 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's, you know, 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, 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, you know, so sort of special. 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, like, tell us about this. Like, what is this essence of Ethereum that it took you somewhat while to understand? I guess it was sort of fast forward a couple of weeks and I'm in I've been implementing this

you know I don't know for four weeks or so and I get I get sort of noticed that you know we should meet up in Miami everyone's getting together it's meant to be a hackathon you know we're meant to sort of all get down and start coding well finish coding Ethereum it turned out that I was actually the only real coda 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 sort of talking about the state of the crypto world, how Bitcoin was cryptocurrency and things that were sort of crypto finance were coming out. Mastercoin was fairly in vogue at the time.

And there was an idea that MasterCoyne 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. And 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 sort of the original white paper, it had a little bit to do with sort of 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 were making a smart contract, we're 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 there. They're sort of set by game theory, but they're different to laws of nature and 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, you know, the vastness of what this, 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. So you mentioned another thing that you learn by implementing is that a habit you still continue? 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 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're 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 the sort of edge cases, all of the, all of the, the, 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 think of an, you know, 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. 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. Yeah, I don't know. I remember reading a quote

by someone that was basically like you know, it's important to stand on the shoulders of giants but also eventually it's similarly important. to kind of keep saying, 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, that second part really definitely sort of appeals to me. I find that if I read too much, it's very difficult to, it's kind of like you'll 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 like, well, you know, if it's already been determined that that's the correct solution, that's the optimal solution, then, you know, 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 or automatically assuming that that's the case, I think can be hugely problematic. And so I don't, I kind of, I 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 the 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. So I could see this approach working when, let's say, like you were an individual contributor, right? So you would maybe doing your PhD, then you'd build Ethereum and has your approach changed as you have?

So now you're also managing this organisation. 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? 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

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 sort of involved in for 15, 20 years now. And I don't think, I mean, you know, 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 rules. If you've listened to previous episodes with Marley Gray and Matt Kernar, 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- Authority template, for example. It's ideal for permission networks where consensus participants are known and reputable. Ethereum on Azure has on-chain network governance that leverages Parody's extensible proof-of-a-authority client. Each consortium member has the power to govern the network or delegate their consensus participants to a trusted operator. And Parody'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 and enterprise, check out AKA.m.S. and start building today. We'd like to thank Microsoft Azure for their support of Epicenter.

So speaking about organization building and management, so of course you did work for Ethereum, right? So you're a CTO of Ethereum, but then pretty soon, I mean, I think 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 this was called Heathcore and afterwards Parody.

So when you started Parody, 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. 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 kind of see where this takes us. That was what we did. There was beyond that. So when we're talking like kind of 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, you know, this is late 2015, early 2016. This is a, the industry was kind of crazy, lots of things coming in.

There was the Dow going on. There was, I don't know, teams sort of coming in. There was a whole ICO thing happening. It was a very, like, generally mad time. And there were lots of things sort of pulling at our sort of attention. There was the idea of what about enterprise blockchains. What about, you know, building stuff for companies? What, you know, Microsoft seemed to be coming in at the time

with their sponsorship of the devsaurus. of the DevCon 1. That was also the idea of, you know, sort of building out Web 3 and like, what if we did swarm and whisper and we put it all into a browser, you know, wasn't clear that Mist was sort of being developed at a substantial rate. So there was, there were lots of ideas, there were lots of potential directions. And in the end, we just basically stayed through to our developer culture, which was, let's just build stuff.

Let's just start with building what we know how to be. build, we'll start with building Ethereum, we'll do it right, we'll do it in the way that with 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 kind of until then, you know, I was kind of half buying into a lot of these Silicon Valley self-help books where they're like, oh, you know, 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, many, 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 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 kind of a dirty, you know, it's kind of like the thought that dare not share itself, because I, you know, I figured that that was just going to be, that was, 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, has, has become. And I think that's, you know, a lot of that is down to my sort of influence. And, um, um, 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. 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 innate idea about what it is that you want to get done.

You have a very clear and concrete vision. It makes product development, that 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. So I clearly remember, 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 is like 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? I wouldn't say struggle, but it was not, 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 raised a huge round. stream raised a huge round. And I think, what is it, digital asset holdings, was it? Live Masters thing. They also had a pretty big raise. So, you know, 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, but that was its original suggestion. And I think, you know, we kind of considered ourselves to be more or less of the same sort of class. We were developing, you know, sort of next generation blockchain. And in my mind, we had the better technology. So I didn't, you know, 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, you know, it was, it had gone up, what, 2x, 3x more or less from the sale, but like no one really cared. And so, yeah, it was, we didn't really have any huge amount of credibility. People could see that there was a platform behind us, but it wasn't that much doing with a platform. Bitcoin was still very much king. Yeah, it wasn't, thankfully, you know, we had some people that did kind of believe in Ethereum, if you like, or believe in the platform. And they were, they were very quick to get us started. And, you know, we did, we didn't, we didn't really kind of do the whole Silicon Valley thing of going around all of the things and having a pitch deck and having a really kind of slick, you know, product.

slides and 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, a few of the, there were people who sort of 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 think I've grown kind of,

having since 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 it's a bit of a, there's a certain talk, you've got to kind of talk the talk to be accepted sort of as a potential member of that club. and you know we were never really a talk-the-talk company we were a build we were a get-the-ship-built

company and that's yeah I kind of go grow a little bit kind of what's the word I'm disappointed but I think Silicon Valley thinks more of itself but has a higher opinion of itself than it deserves that's saying yeah I know 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 and Silicon Valley sort of like, you know, missed out on. And then, of course, now there was 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, right? And it's like, so it's interesting how this, you know, how this sort of played out. But let's speak about Polka, though. afterwards, right, you build parity and then PolkaDoth has become this major thing, or, you know, major focus of yours. So how did the Genesis, what was the Genesis story of PolkaDont? So rewind to 2016.

We've been working at Parity for about six, seven months. I think we began, we began coding the Ethereum client, late Novemberish, 2015. and yeah it's like June, July, August. I can't remember exactly. And, you know, I'm sort of, we're kind of waiting with baited breath on Ethereum, one and a half or Ethereum 2. We're kind of, you know,

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 Tao that kind of stole some attention from the core development team. And there are a few other kind of bits and bobs. And, you know, 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 Marac, one of the sort of kind of founder developers of parity,

while we were in San Francisco, we started, oh, Maric just sort of said, well, what if we sort of built something like that ourselves? You know, 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 kind of, it's substantially more complex. So I kind of thought, what if we could, you know, let's forget trying to 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 Pocod came from. It was essentially, you know, can we create a shodd of Ethereum. Following from that, like pretty much in the same conversation, I think we were having a beer at some bar and after we met a VC maybe in San Francisco. And it was there that I realized that you need this kind of, you're going to need a kind of, I think Ethereum calls it the beacon chain. 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, he was a favor of different shards having different levels of security. And it's also dissimilar to some of the other multi-chain designs like Bitcoin's science. chains and Cosmos where you can have different sets of validators for the different subchains. In my mind, they always needed to be the same sort of security guarantees. And so it was one way of doing it, the obvious initial thing to do is just to fix it, hard-code

it, hard-wire 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 implement little bits of Ethereum and the main beacon chain or the main relay chain, as we call it in Pocod, 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 bites, 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 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 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 a sort of, executed and you can store what the software to actually validate these things, although indeed the specification, the definition of a valid power chain, 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 needs.

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 spent transaction outputs. It's 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, kind of 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 a next generation play. Very interesting. So I, this progression of ideas is really nice. So like Ethereum, okay, then we need a sharded Ethereum. Oh, then we'll need the central chain to be the arbitrator of final validity of some kind. Then like the idea of, oh, then these para chains 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 web assembly and allowing these chains to allowing like their straight transition functions to be written in in web assembly it makes a lot of sense um 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? 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 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. Some architecture, there are particular IR op codes 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 contract. I mean, at the time, you know, when... 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.

It was, you know, some of the early Ether scripts 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, you know, sort of came along was like, well, this is pretty low level. I don't think, you know, 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, you know, that basically means that almost all low-level code is massively suboptimal because it's all being stored in these,

you know, 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, 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, so a CPU architecture, but one that was sufficiently kind of risk enough. So reduced instruction set computers, what risk stands on. The idea is that it's not got very many op codes, it's very

simple. So in principle you can retarget it, you can recompile it into a, into a sort of another architecture without losing too much performance. And the obvious one was arm, the arm targeting something like arm v5. But again, we sort of having thought about it a bit more, we kind of figured, yeah, probably not the way to go, especially when we have something like WebAssembly, which is increasingly supported by, you know, outfits like Google and Mozilla, it's very much likely to end up with, you know, really well-performing compilers that transcompile it from WebAssembly into the native architecture. LLVM targets it natively, so it doesn't, you know, 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 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 initial, as a sort of primary thing, getting imports and exports. It's basically designed to be developable, 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. 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 trust pilot 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 Rodek Ostrowski.

Roddick has experience as a lead software engineer and data scientists 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-Corder consensus U-Port 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 Roddock for your team, go to TopTal.com slash

epicenter for a no-risk trial. A TopTile 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 supportive epicenter. At this point, we've basically covered a big key insight, and that key insight is Polka.orgadot 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 like common way. And what Polka dot 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 straight transition functions of all of these heterogeneous chains in one common way that would be nice and then polecard out ended up picking up the washam 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. Okay, so yeah, what is substrate? So substrates many things. Substrate began as a desire to abstract out the common bits of Pocodop that could also be used for building other chains like you know we were doing from the from the ground up we were building this kind of the software stack for Pocodot and I really hate seeing code not be able to be reused it's kind of like you know food waste it's like come on you know someone can eat this surely I like throwing it

away I prefer to put in a Tupperware and say it for later and there's kind of Tupperowing 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 put force, 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 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's 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, you know, 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 substrates heritage, it wasn't a thing initially.

It was just Pocod. And over time, it's like there was at one point, like I did a giant rename and sort of many of the Pocodot modules between substrate modules, and there was sort of continual refactoring to take much of the Pocodocode and turn it into generic code within substrate, and then eventually the repository split out, and we have now a separate substrate repository. Now, we always knew that building chains in Pocodops, so we call these chains parachains,

because they're like kind of parallelized chains or they 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 a, not the way of the same thing, only very good for, you know, sort of building the Pocodot relay chain, the sort of big chain in the middle, and building other chains that have nothing to do with Pocodot, but it's also good for building these para-chains. It has much of the sorts of algorithms and subroutines that you need for building power chains, 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. So substrate is probably the world's biggest bet against blockchain maximalism. It's, you know, the whole point of substrate is to make making new chains 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 will.

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 tendament that the cosmos guys are using. We also have now aura implemented in 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 that the 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 parochane or Pocodop that lets you form consensus based around using the Pocodot relay chain, as your sort of 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 Pocodop 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 plug-able, but not just plug-able. 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 the Pocodot. You can change it from a rhododendron, PbFT-style chain. into a grandpa chain, 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 and 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 you know 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 into, you know, on the sort of continue and the old version of the chain. And they'll come out of consensus. 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.

So you have substrate. There's like framework for developing a blockchain. Now, somebody could go today or today or maybe in a few months, but like, you know, in the very near future and say, or maybe today and built this, you know, substrate blockchain. And now they could use, for example, the existing consensus algorithms you have, you know, maybe grandpa or maybe your tenement-like algorithm or, you know, something that exists today. They launch this blockchain. And now, you know, a year from now or something like that, polka dot launches. and then that chain could actually decide to, you know, on the live chain, say, okay, we're going to swap out the consensus and we're going to start using PolkaDoc consensus

and rely, and we get rid of our own validators and we rely on the security off the relay chain. Is this, this would really be possible? Yeah, that's right. So that's the sort of use case we're designing for. So, yeah, you know, the 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 if 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 Pocod with little more than a single sort of change in the in the chain sort of run time itself. So it's like literally a storage item. You basically just say, yeah, change this particular pit of storage from using grandpa or rhododendron or whatever the consensus algorithm that the chain is using is,

to use parachain. And we want to use parochane slot 42. Right, cool. And as long as Pocod is expecting you, then it will just seamlessly switch over. 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. 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 PUC and what can it do? So we haven't actually made any release of... Our schedule is to release our beta, 1.0 beta of substrate, real soon now, like, before the... Ideally before the Web 3 summit.

So that's like in a few days' time. it's certainly it's certainly you know most of the code has been written it's now just the 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, I don't know if we can talk about it later or whatever, but it's our sort of new, cool consensus sort of algorithm that's an iteration or two beyond a 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 Orand block production algorithm in for 1.0 beta. and we have a, we will likely for 1.0 have an iteration on that that's sort of derived probably from a ruboras, which is a kind of slightly, it's actually got quite a lot of similarity with Oran, but it's a little bit,

it's basically been demonstrated secure as long as a few particular guarantees are given, so that's likely to be our sort of final iteration for consensus on substrate and Pocodop. 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 it hasn't, 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 than maybe some minor API tweaks.

But, yeah, by and large, what you see with 1.0, what you develop on 1.0 will be usable for the foreseeable future. Great. 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 of, you know, significant consensus affecting upgrade of a blockchain, and in general, I have a hard fork, right? So there's this big discussion around it and then, you know, this hard work happens. People actively, they want to full note, they have to download a new client. And, you know, to the extent that people and

miners actually use their client also determines whether that change gets accepted. So here we have, you know, basically these automatic updates, right, where I don't have to upgrade the client. So first of all, what's what is the big downside of hard forks? And how does that, how do you still have this level of accountability or control or this lead to a lot of risks as well, having, you know, automated upgrades? So I think it's fair to say that automated upgrades are kind of like a sharp knife, you know, They're very powerful. You've 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 their last April 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're used, they're only used or 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, you know. And it's like, no, no, no, you know, when you're pushing the fold, you are developing these things, and they are to some degree.

Dangerous, sharp knives are dangerous, but it's still 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 you know 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, you know, a lot of people in the blockchain think immutability, this idea that a blockchain is well defined, that it should never move beyond the confines of that initial. definition and forever at odds with those that believe blockchain should evolve so 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 and 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, right? That's what consensus is. So we're stuck in this ecosystem where, you know, the key differentiator from the rest of the world is that we're all about consensus technology, and we can't form a consensus and then to upgrade our consensus technology.

the whole thing, you know, smacks of a bit of a Shakespearean comedy. So what's the solution? Well, the solution is that we have, 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, you know, it's like, oh, 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 Dow where you've got smart contract that's controlling tens, hundreds of millions and it's flawed in Subway. Well, we're just sort of saying, well, yeah, we recognise 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 it holds the key.

A lot of them are much more complex than that in multi-sig 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 technical implementation of protocols like substrate that allow this kind of upgrade 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. You 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. So really the only question that's left, I mean, I don't see upgradeability is any kind of a controversial thing. Yes, it's powerful, but so is 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 fucking 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 upgrade ability, the question simply becomes, what are the specifics behind taking the decision to upgrade the chain? And how do we, you know, how do we ensure that it's, you know, it has appropriate fail-safing? Now, of course, Vitalik and Flat and a bunch of the Ethereum people have sort of argued that, you know, 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 there's probably fear of the riskiness of on-chain governance, 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 what is that process controlled with? And generally, it will be the token holders, right? Because that's kind of the basic unit of significance, right, in a blockchain system.

since you don't really have real world identities there. And then there's this fear that they will use plutocracy and controlled by the small group of token holders. So what is your view of kind of both of those concerns? 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 and payments. It was taking the risk and uncertainty out of having your accessesed 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 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 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 to get to get 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. this 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. Yeah, no, I mean, I agree with you that there's something very ironic and strange to say, on the one hand, we need to use smart contract and have this, you know, trustlessness and control and auditability, but not when it comes to managing the system itself. So I think that's a completely fair point. And however, then there's a question of, you know, how is that process managed? Let's say we accept that it should, it will be desirable to have it, you know, properly structured and as a, as a auditable, you know, process.

Then there's still this concern around, you know, maybe a small minority of token holders controlling it. And, you know, in the case of Polka, right, I mean, I don't know what the distribution of tokens will. will look like in the future, but at the token during the fundraiser, I think it was around 50% that were, you know, either the parity or the foundation. So of course, that does raise the question, if it is explicit process and if the token holders are the ones that determine it, like how do you then also get, you know, a kind of wide support? Or is that something that matters? So I prefixed 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. 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 to the top two

cryptocurrencies are plutocracy slash 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 Web 3 Foundation on the launch of Pocodot.

So although 50% was sold in the original sale, 20% will be distributed one way or another, probably through a few sales and possibly an air drop before launch. So that means that over two thirds will be. 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, you know, 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 power. 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 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, you know, that are brought up by people like Vitalik and Vlad over stakeholder voting, which is partly why we don't have a strict, you know,

just coin vote model for Pocod. It's, even at its current state, and this is, you know, is meant to iterate, you know, before release and even after release. We don't have a straight sort of coinholder voting per se. It's a sort of, you know, it's a meant to iterate, you know, before release, you know, before release. coinholder voting per se it's rather we do have an adage a sort of maxim which is if more than 50% of the 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 if you don't listen to the majority of a coinholders if actually 51% vote in a particular way you know 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. So it's like, you know, having a maxim whereby 51% of the stake, so not 51% of the turnout critically, 51% of the stake can choose to sort of, can of choose to evolve the chain. That just seems like a self-managing, continued self-existence, 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, you know, kind of help.

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 proposed sensible changes to the chain that allows some degree of fast-movingness without, we're still with a democratic safeguard or a safeguard that's sort of coined democratic. Now, beyond that, I still, I'm not, you know, this is a first effort. I don't think this is going to be a, 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 Pocod on the way to release and that will be continuing to prototype beyond release. So some of the sort of ideas have come up. So one of the things that Pitalik 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 civil resistance. But it's not, in principle, if you did have this civil resistance, then it would become pretty easy. 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 the price rises, if you do another referendum in order to undo the damage or whatever it'll be. So there's a notion of like 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 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 like future-archy mechanisms where people can sort of bet on price going up and down and based upon proposals. And we've got a few other ideas that's 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 like having, not using coins as the purely a way of deciding who should be voting for what or whose opinion should matter, but also using, you know, positioning community,

potentially even this notion of like there being a body that decides, who are DAP authors, or maybe para chains are able to have votes, have a vote as part of the sort of notion of being a parochains. So the parochains 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. So whenever you issue a transaction on the relay chain, you can put in a vote or you can. can, your account at least gets a little bit more voting power. So there's quite a few, 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 the 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 of implementation if we think that they're promising. 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 like, you know, 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 like you being used to like the system of democracy, right, 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. So I think that also provides this very powerful kind of balance where, okay, maybe a majority of coin motors 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 an existing political system, right? You can't just say, okay, I'm going to fork this country and go my own way.

Yeah, I mean, you know, there are certainly separatist movements that I kind of 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, it was actually to make forking the network part of the government system. So basically when a when a vote happens, you can say, well, 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 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, you know, when it splits, so that there's automatically a means of deciding who gets what name and who gets, you know, some derivative name, or even like automatically determining the derivative name, that would potentially lead to fewer splits because it's like, like the majority would actually believe the minorities, 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 sort of support by saying, well, if you're willing, to like put all of your coins up in order to in order to say you know no in order to try and veto it then we will listen to the veto will say well this vote this vote actually got vetoed

it won't go through it can be re-voted again maybe in a month or in two months or something but you know it's enough for them to um to basically say you need to think about this some more guys because you know this is a 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, you know, it's not to say we'll block it forever, it's not to say that, you know, 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. Great. It makes a lot of sense. I'm really curious to see all the governance experiments that will happen on Polka dot. The other thing, of course, is when you have so many different parachains experiments and governance can happen on these parachines so we can iterate our way towards better governing these systems over time

yeah so parachains basically have a similar I mean they all run on substrate so they have similar mechanisms to indeed to 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 think it was Massachusetts. Oh, Massachusetts. It was the, it was Mitt Romney. That's right, yeah, yeah, yeah, Mitt Romney, exactly. So the idea that, you know, you can have two states next to each other, like Texas and California that have, you know, 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 Pocod where each of the different parochains and their communities can experiment with their various governance systems and the things that work get rolled out to Pocod and the things that don't, well, they stay on the paratrochain.

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 parachines, you have interchained 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? dozen and when can we expect to see a release of the main net? So Pocodot itself is we released POSC2. POSC2 was actually an on-chain upgrade from POSC 1 that was the first to my knowledge on-chain upgrade of a sort of live network, a live public test net and yeah I mean and it was also it wasn't just a you know a sort of flaky sort of demo

away you've just got like one minor relevant thing that's been upgraded. This was like a full runtime upgrade it like huge amounts of things changed. All of the front ends have to change to deal with a new runtime. This was actually a legitimate alter, you know, completely new test net. It's just that it happened to have the historical POC1 blocks before it. And all the POSC1 substrates or Pocod could continue sinking. Okay, so POC2 is out. POC3 is right around the corner. It's finished, as I said, except for this extra consensus algorithm,

which will probably be our final Pocodoconsetor algorithm. Pretty excited about that. And, yeah, it should be kind of interesting to see. POC4 was scheduled for late in the year, sort of new year time, were probably a couple weeks behind on PSC3, so I would guess we're looking more like late January 2019. And POC4 basically takes Pocodot to feature completeness. It introduces the interchained communication, and it will have a relatively sophisticated consensus mechanism in order to bring in the parochane blocks.

It'll have the validation, the fishermen, and the collators. Actually, we already have collators. We already did the parochane thing in POSC2. I don't know if there's already a parochane deployed. Certainly there have been parochains deployed on closed test nets. The idea with POC5 is to bring in the substrate executable itself as a parochane collation system, so that basically we can start running.

things like smart contract chains, potentially a Bitcoin chain and a UTXO chain on the Tessnet, on the PSC, whatever it would be, four or five test net. And I'd also start playing around with plugable 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. We'll 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 will just sort of flow into the audit. I would say we're still roughly on track for our original release date of August 29th, sorry, autumn 20, 2019. Probably towards the end of Q3. I'm going to eat these words, I know, you 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 PSC4 is done, as I say. PSC4 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. RSDK is basically substrate and that's going to be continued to be developed. So that's para chain development can basically already be started. And hopefully those para chains, those sorts of chains that are being developed, in substrate now can be deployed to Pocodot with relatively few code changes around maybe March time next year for that Pocococet test net. Yeah, but you know, we are slowly getting to the point now where it's starting to feel quite real and that's encouraging.

Cool. Well, Gamine, 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 Pocod develops and how it will do in the real world. 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.

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 slash 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 guest, 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. So thanks so much, and we look forward to being back next week.