Interblockchain Communication & Interchain Topology by Christopher Goes (Devcon5)

I'm Chris I work from tournament research and I'm going to talk a bit about and I'll explain what the terms mean don't worry interblock team communication and the topology of the inter chain the polycentric inter chain is already here let's unpack this in the past few years we've seen what I like to call a Cambrian explosion of black chains it's continuing even more several new protocols were announced of this event one hypothesis says that these block chains will be selected out and slowly converged to a few single Ledger's which handle all of the state transitions all of the currency transactions all of the future complex decentralized financial protocols etc perhaps but another hypothesis says that the interchange will continue to branch out words that new protocols will continue to be built which can specialize on different sorts of use cases that new assets will continue to come into existence that assets and protocols will perhaps dissociate somewhat where an asset can retain its logical identity while living on a different and perhaps improved protocol that's what I mean by the interchange this set of Ledger's fulfilling a set of different use cases why might we want this there are a lot of advantages to having separate block chains as opposed to a few single ones one advantage is versatility different protocols can focus on two different use cases they can optimize their state machines optimize their educational materials focus their community focus their onboarding focus their user experience on solving certain specific problems really well as opposed to solving a lot of problems not so great this applies not only to the case of simply building a protocol but also to the case of governing and governing it over time if a single protocol has to cater to a wide diversity of use cases all of the interests of different users who probably want different things and for whom the protocol moving in different directions would be better or worse at different times have a hard time agreeing on how to change a protocol over time that becomes much easier if a use case is more focused if they can choose to focus their particular protocol and solving one particular problem and if they need a new problem build a new protocol another thing which I think is really important and sometimes under emphasized is minimizing exit costs of distributed Ledger's right now many of us I think would consider the exit costs of centralized platforms particularly those which control information to be too high but one of the reason the exit costs of Facebook or Twitter or Google suite are so high is that there's no possible interoperability if someone builds a web client which allows you to access your Gmail data Google will sue them or shut it down or prevent API access I think we should have the same concern in the same desire to minimize exit costs for Ledger's and that means continued asset interoperability so hard Forks can be contentious when they necessarily diverge when it's not possible for users to continue to use both protocols at once but if hard Forks could instead be Rican stood under a new mechanism where two different versions of a protocol can continue over time then people could use one version retain their asset other people could choose to switch the new version and retain the same logical continuity moving their assets to and from the original protocol but in order to do all of this we need a way for these different block chains in the interchange to talk to one another this way or a way that we've been developing is ibc inter blockchain communication IBC is a messaging protocol for the inter chain a general messaging protocol let's go back in time a few decades to the early internet when some similar problems were being solved different machines and often different sort of localized clusters and machines existed in different places around the world particularly an ARPANET around CERN in universities in the United States and in Europe and later across the world and those computers needed a way to talk to each other this was obvious many people built protocol to allow these computers to talk to each other and some of them I listed on the slide so we'll have a quick quiz raise your hand and keep it up if you've heard of X NS hmm not too many Apple talk a few chaos net IP x SP x IP should be just about everyone he came to this conference divided by a ticket using the Internet Protocol almost certainly why why were what for for these protocols there are tons more which I didn't bother the lists Huayra for these protocols unsuccessful in connecting all of the computers while one was I think there are a few reasons one is that the Internet Protocol was quite general it wasn't specific to a manufacturer or specific to somewhat closed hardware like Apple Talk it didn't rely on particular network cards it wasn't in humored by patents it was something where anyone could read the open-source protocol standard or what was open-source in that time and implement their own Hardware which supported it protocols like some of these and especially IP are non-contentious the Internet Protocol has a monopoly there are no other internet protocols but it's a beneficial monopoly or but Neverland monopoly because using the Internet Protocol doesn't prevent anyone from supporting other protocols it doesn't lock them into a particular token a particular infrastructure as they just speak this particular language at the edge where they connect to other computers we need something similar for block chains what does this mean in the context of blockchain interoperability how do we build this kind of protocol which can fulfill this non-contentious global standard requirement one needs to be modular this communications protocol needs to abstract over the different methods for verifying state of other block chains it needs to enable needs to create a standard such that block chains can check the other blockchain sent messages to it needs to be local the stands in contrast to a lot of charting protocols which are interesting there's all the different problem but charting protocols tend to require a glow topological view they require that one entity in the set of chains usually a root chain or root char and it's called different things but one entity in the set of chains has a view at all times of what the other shards are what they're doing it knows some sort of assignment and it can reason about the security properties of that system because it knows what the topology is for obviously we don't want to require this we want to allow the topology to exist amorphous ly as something that no chain in the system no chain and the inter chain has to know or reason about in order to use the protocol safely that's what we mean by locality and finally this messaging protocol that we create needs to be composable people need to be able to reason about the security properties of simply sending messages and receiving messages just like the reason about how you send and receive an TCP IP and then using those properties they need to be able to reason about the gestalt properties of complex systems which use those that book about us that's what we mean by compose ability to do this we've built a layered protocol similar to the OSI model of IP the first set of layers is called the tau or I like to call it the tau of IVC transport authentication and ordering the tau of ibc handles getting data physically using off chain processes we call real ayres from one blockchain to another or one ledger to another it handles authentication creating a standard for how different Ledger's can authenticate summaries of each other's consensus processes and use those summaries to check that particular packets were sent or received or not and it handles ordering getting packets when desired to the destination in order and exactly in order I'll have to summarize briefly over this protocol stack so I think I will just use a picture consider an IV see packets between two chains in protocol as written at the moment we have this entity called a module which you can understand as being a independent unit of execution running a ledger so this will map to different particular abstractions and different block chains in the case of aetherium it will map to a smart contract in the case of the cosmos decay we call it just a module in the case of substrate I think it's also called modules or packages or something but the concept is the same so a module on blockchain a will send an IBC packet that's number one it will head to number two the IBC module which will interpret that packet to determine how to route it the IBC module will then store it in state the consensus algorithm of blockchain a that's three will then commit that transaction commit to a state a state route a relayer that's number five will watch blockchain a figure out that an outgoing packet has been sent then send it on words in an incoming transaction to blockchain B when the transaction is accepted on blockchain B that's number seven the packet will be routed to the IVC module number eight on blockchain B and the IBC module on blockchain B will parse that packet decipher it determine where it needs to go and send it on to module B so all of the packets and packet received time out handling all of the basic primitives we build an IBC followed this structure and the key part that I would emphasize is that it's quite generic the block chains and modules need to have the ability to verify each other state but otherwise the trust model between these two modules module a and module B is similar to the trust model between two aetherium smart contracts module a doesn't need to reason about any of the other modules running a blockchain a module B doesn't need to reason about any of the other modules running on watching B or blockchain a they can simply once they establish this secure communications channel between each other send and receive packets and reason about this local system everything contained on this diagram is sufficient the understanding of it is sufficient to reason about the security of IBC what needs to come next we're calling the application layer this is a little analogous to ERC standards in the theory and standards for call data we've built IBC to be payload agnostic such that when packets are real AIDS sent around verified handled and timeouts by the protocol the protocol implementations don't need to stand what the data in those packets mean that only needs to be understood at the edges needs to be understood by the module sending or receiving these packets dealing with how they should be interpreted and what the semantics of particular packet data are in order to standardize this across the ecosystem again in a non contentious fashion we will need a set of application layer packet encoding and semantic standards some of these can probably build off some of the work with ethereum is done with ERC standards for called out of between contracts we hope to collaborate as much as possible some of them will probably be different opening up different use cases in things like cross chain account abstraction which someone recently submitted a Poe request for to the IBC spec repository which allows an account on one chain to control the actions to send transactions on behalf of an account on another chain through IBC simple packets of course like token transfer similar to a RC 20 the the semantics are a little bit different because you're actually transferring tokens between two block chains so you need to account for supply but call data is similar more complex use cases we expect will emerge over time including things that look like sharding but are architectural II a little different if you have mutually comprehensible VMs on two different chains you can relay code between them through IBC and you could use this two alongside a algorithm for determining how to relay code over time maybe some sort of load bouncing you could use this to create protocols which look like charting but they still have this local security reasoning you only need to reason about the block chains you're directly talking to IB / IBC no one needs to reason about the topology of the whole network all of this work is online you can find it at github comm slash cosmos left ICS we recently release released candidate for of the IVC spec I would stress that it's not done we are waiting on a few auditors to get back to us and of course welcome any feedback or questions trying to test with several possible block chains which aim to utilize IBC but it is definitely in a state where you can read it and understand what we're trying to achieve with this protocol why it fulfills that design criteria of modularity locality and composability and how you can get involved and help so please do you found a star thank you [Applause] you