Blockchain Interoperability Explained: Polkadot & Scalability

[00:00:02][Music] my name is Rob I work on a project called polkadot which is a block chain for interoperability and scalability just meant to be sort of the next generation blockchain but in this talk I'm going to be focusing just on that interoperability aspect talking a bit about what interoperability is why we want it and how we can achieve it so so the next button doesn't work but I can keep talking so I would jump in - are you sure this this screen is completely wrong but okay so the two sides of blockchain there are basically two key components that go into constructing a blockchain so the first is the state machine and this is what you're usually interested when you hear about a blockchain project what are the changes that are actually agreed upon whether it's transactions what kind of data that are stored whether it's using an account model or something with unspent transaction outputs like Bitcoin what's agreed upon what's stored on Shane so the state machine abstraction sort of encapsulate all those possible blockchain state machines that that could exist that people want to develop the other side of blockchain is the consensus algorithm that's how we reach agreements on which state transitions from state a to state B to include on chain so that would be an agreement between a permissionless set or a permission set or you know could be completely decentralized it could be centralized you can actually make a blockchain out of all of those different things as long as they fit the properties of a consensus algorithm so one common mistake I see people make is thinking that proof of work or proof of stake themselves or consensus systems we're actually their incentive layers on top of consensus systems to make them decentralized and permissionless so what is interoperability the goal is to connect blog chains with distinct state machines and consensus and when I say that I also mean to support things that we haven't even thought of yet so supporting the past present and future supporting the things that have already been built like Bitcoin and aetherium or other chains supporting the present so that's basically what we think is possible now but hasn't been built and also the future to support state machines and consensus systems that we haven't even thought of yet but over the next 10 years probably will be invented pushing the state of the art even further and we want those things to be integrated into an interoperability system as well so this is sort of one thing that we think would be possible with a interoperable system so we have sort of this this polkadot interoperability chain at the center we have a private chain which is managed by a bank and that might coordinate balances of accounts of actual people and we have the etherium chain which is public and we have a supply chain which is focused specifically on that use case of supply chain and all of these could communicate and send messages between themselves so we would have a smart contract running on the etherium chain completely permissionless decentralized sending messages to query something like a private bank to get a balance and also communicating with the supply chain to determine exactly where something is in its in its provenance so to address the status quo a little bit we have the fact that one size doesn't fit all when it comes to blockchain different projects have different requirements and trying to force everything to use a single mechanism for writing their their state machine is not always going to work it might be overly restrictive in terms of data formats or what kind of computations they can do in ways that actually slow down the amount of computation or work that can be done by the chain we also see that enterprise needs aren't being met so enterprise private chains are usually reluctant to put their stuff on the public chain to put it at the mercy of the public governance and and what they want is usually to manage their own data but make it accessible to the public chain so the fact is that many enterprise networks are just sort of existing in their own bubble and that information isn't just isn't available to public applications so one goal of interoperability is to basically allow those private chains to exist but also to make their data completely accessible from the public chains as determined by the private chain so it's not at the whims of the governance of the public chain but it's still accessible and right now the landscape is fragmented there isn't going to be one chain to rule them all and that's immediately obvious if you look at the landscape which is just that ever almost every blockchain project is starting its own blockchain and the only way that they can communicate right now is through centralized services and that's really diminishing the network effect which could exist between these projects so these are the things that we want to address so some future benefits of interoperability it would be that there's more room for specialization if you don't lock blockchain projects into a specific model for the work that they do they're free to use whichever computation or data formats are most convenient for them most suited to the work that they're trying to do which means that it'll actually have a higher throughput overall we have this more powerful network effect that I discussed before and we have seamless upgrades of consensus and governance just by having the interoperability framework sort of agree on what the next thing is going to look like what the next stage of consensus or the next governance model is going to look like we can upgrade it without affecting any of these sub projects that are hooked into the framework at all so to think a little bit beyond tokens the interoperability of tokens is clearly desirable and when a lot of people think about interoperability that's the main use case that they're thinking of how do we get tokens from one chain to another how do we do decentralized exchange at a completely trustless way but this is actually only the tip of the iceberg arbitrary message passing is much more important because we can always encapsulate token transfers in arbitrary message passing but we can encapsulate so much more like smart contract calls across chains so I'm on chain a and I don't have smart contract capabilities I know that there's a smart contract on another chain that I'm connected to and I can just make this message pass to it requesting execution of the smart contract and get the result back asynchronously or you can go vice versa and you can have a smart contract platform which is by definition a little bit less efficient because it's strictly more general but it's aware of a chain that does highly focused kinds of computation for things like privacy or processing data for AI or IOT kind of stuff and it can call out to that and register devices or requests highly performant computation get the result back so interoperability kind of goes both ways so one attempt for interoperability might be federated bridges where you have an authority set on a chain which ferries messages between that and another chain so one main problem there is what if the other chain gets reverted or one of those chains gets reverted but the other one doesn't and that's a problem I'll talk about a bit in the next slides that's a fundamental problem of the security of the space the other problem is proving this behavior of authorities and slashing them and when I say slashing I'm talking about this economic game that we put together to incentivize authorities not to misbehave that misbehavior should be always detectable always attributable and always slash Apple so you can get rid of people's funds when they misbehave and that's an incentive for them always to be honest the other problem is that you need some kind of bridge between the data formats of the connected chains so to talk about attacking weak chains I'm talking about two chains that both have finality so technically they are finalizing blocks so but a pure proof-of-work chain doesn't actually finalize anything but a proof of stake system which uses a classical consensus algorithm might actually finalize stuff and it's not supposed to be reverted but that's really just with a specific security bound like three million or ten million depending how much stake there is on the network so we have this chain one on the top and the stuff in orange is finalized and this green block sent a message to another finalized block on chain two but if we have this validator set on the first chain misbehave and they would do that if they're purely rational actors if they were just bribed three million dollars overall they'd perform a reversion of the finalized block the finalized green block so it's no longer in the chain and the source of this message now doesn't exist anymore but chain two hasn't been reverted and the receipt of the message is really still there so from one perspective one chain we have a message received that might transfer tokens but the tokens on the source chain still exist so all of a sudden you have this duplication and this kind of attack is actually reasonable to try and pull off if you have an attack vector which is worth more than the cost of attacking the chain so our solution to that is to have a chain specifically for relaying messages so we have one central relay chain which ferries messages between all the attached chains and you can attach change through the governance process and one goal is that we can make this sort of hierarchical in in the future the relay chain validates other chains state transitions in lockstep so you don't get this issue of one chain being reverted while the other hasn't been and they transmit messages when they're known to be good so slashing is also possible easily because the stake is all in the rate relay chains denomination we don't have to worry about trying to make a market between the denomination of stake on one chain versus another because it's all in the same unified currency so the KO validation of the attached chains also gives us this benefit of opt-in pooled security of attached chains where these chains don't actually need to have their own consensus algorithm but they can just sort of rely on the consensus of the relay chain which is has a number of benefits for security because they don't have to compete over security resources with other chains but it's also really useful for development because all of a sudden if you're a developer with a good idea you don't have to come up with a consensus algorithm or implement one or gather security resources for it you can just write your interesting state machine which is probably the first thing that you cared about and plug it into this interoperability Network but it's opt-in so we can have chains that have their own consensus and bridge them although it is still vulnerable to the problem that I described before we would have the relay chain validator set managing external bridges to those chains with different consensus so this is a little bit closer look of the diagram that was on the last slide so we have this relay chain at the center we have a pair of chain which is an attached chain that relies on the same consensus as the relay chain so it's part of that pooled security and they're different shapes there are lots of different shapes here to represent that the state machines of these chains are actually different and then we also have a bridge to a public network like etherium so all of these chains can now interoperate the ones which have been registered with the polka dot network even well after aetherium already was a thing and it has maybe some kind of novel innovation but it can still communicate with an aetherium public net or perhaps a Bitcoin public network or something for privacy or whatever there is that people can connect via bridges so yeah with pooled security the key problem is that gathering security resources for a chain is difficult you basically have to find miners or find stagers and you have to make sure that the overall value of the security resources is not easily attackable so we're even seeing that these days which is that small proof-of-work chains are being attacked all the time because those big mining companies in China can just overwhelm them without any problem so they're competing over limited resources and a lot of these resources might already be concentrated so just to reiterate this point that innovative state transitions can be embedded into the relay chains consensus is really good thing because all of a sudden we're dealing with the aggregate of all the security gathered for all those chains as opposed to the maximum this is sort of a diagram which explains that so another major challenge would be just custodianship of funds on an external chain there isn't really a general solution yet because it sort of falls out from that problem of reversion of weaker chains that I outlined before and these bridges will usually require very specific behavior on the part of the relay chain validators and handoffs to new validators are difficult for example if these validators are managing a multi signature wallet on some external chain and when there's a new validator set on the relay chain they need to hand over the custody of this multi-state wallet to the new set and that might be an involved process that may not be that easy on an external chain we also need of course this mitigation strategy maybe introducing some kind of special economic gain there's certain cryptographic techniques that we can use to sort of prevent betrayal by having the betrayers betray each other and we are looking into that but there isn't really a general solution so just as an example of what I mean when I say that you can integrate a private chain it's basically integrating a pair of chain into the network which uses its own consensus algorithm but this consensus algorithm is just what has been signed off on by the private authority so polka dots pooled security is checking that everything included in polka dot has been signed off on by the private network authorities but it obviously can't produce blocks which have been signed by the private network authorities and that means that the private network can determine exactly which data wants to make available it may only make sort of a manifest of what changes exist or what data exists right now available without making the transitions that got us there available and now the data would be available to all other chains on integrated into the polka dot network but it would be completely managed by the private chain authorities thank you very much if you want to check out the development of this we've actually got it all opens worse for the first implementation it's being developed by parity technologies at this github URL there's a couple other websites you can check out if you're interested in learning more about polka dot and if you'd like to connect here some twitter handles you can shoot messages to I guess this is the time to take questions actually Rob we've kind of run out of time for questions okay sorry so don't ask you can ask him questions later I don't want to hear your questions no you can come talk to me afterwards and I'll answer your questions thanks a lot thank you very much [Music] [Music]