 I'm Chris, I work for Tenement Research and I'm going to talk a bit about, and I'll explain what the terms mean, don't worry, interblockchain communication and the topology of the interchange. The polycentric interchange is already here. Let's unpack this. In the past few years, we've seen what I like to call a Cambrian explosion of blockchains. It's continuing, even more, several new protocols were announced at this event. One hypothesis says that these blockchains will be selected out and slowly converged to a few single ledgers, 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 outwards, 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 ledgers fulfilling a set of different use cases, why might we want this? There are a lot of advantages to having separate blockchains as opposed to a few single ones. One advantage is versatility. Different protocols can focus on 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 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 on 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 ledgers. 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 reasons 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 and the same desire to minimize exit costs for ledgers. 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 reconstructed 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 blockchains and the interchange to talk to one another. This way or a way that we've been developing is IBC interblockchain communication. IBC is a messaging protocol for the interchange, 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 in ARPANET, in 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 protocols to allow these computers to talk to each other and some of them I listed on this slide. So we'll have a quick quiz. Raise your hand and keep it up if you've heard of XNS. Not too many. Apple Talk. A few. ChaosNet. IPX, SPX. IP should be just about everyone. If you came to this conference, you bought a ticket using the internet protocol, almost certainly. Why? Why were what, four? Four of these protocols and there were tons more, which I didn't bother to list. Why were four of 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 encumbered 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 other internet protocols, but it's a beneficial monopoly or a benevolent 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. They just speak this particular language at the edge where they connect to other computers. We need something similar for blockchains. 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, it needs to be modular. This communications protocol needs to abstract over the different methods for verifying state of other blockchains. It needs to create a standard such that blockchains can check the other blockchains sent messages. Two, it needs to be local. This stands in contrast to a lot of sharding protocols, which are interesting. All the different problems. But sharding protocols tend to require a global topological view. They require that one entity in the set of chains, usually a root chain or root shard, 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 IBC, we don't want to require this. We want to allow the topology to exist amorphously as something that no chain in the system, no chain in the interchain 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 you could reason about how you send and receive in TCPIP, and then using those properties they need to be able to reason about the gestalt properties of complex systems which use those simple components. That's what we mean by composability. 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 IBC, transport, authentication, and ordering. The tau of IBC handles getting data physically using off-chain processes we call relayers from one blockchain to another, one ledger to another. It handles authentication, creating a standard for how different ledgers 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 IBC packet between two chains. In the protocol as written at the moment, we have this entity called a module which you can understand as being an independent unit of execution running on a ledger. So this will map to different particular abstractions and different blockchains. In the case of Ethereum, it will map to a smart contract. In the case of the Cosmos SDK, 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 route. A relayer, that's number five, will watch blockchain A figure out that an outgoing packet has been sent, then send it onwards 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 IBC module number eight on blockchain B. And the IBC module on blockchain B will parse that packet to decipher it, determine where it needs to go, and send it on to module B. So all of the packet send, packet receive, timeout handling, all of the basic primitives we build on IBC follow this structure. And the key part that I would emphasize is that it's quite generic. The blockchains 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 Ethereum smart contracts. Module A doesn't need to reason about any of the other modules running on blockchain A. Module B doesn't need to reason about any of the other modules running on blockchain 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 Ethereum, standards for call data. We've built IBC to be payload agnostic such that when packets are relayed, sent around, verified, handled in timeouts by the protocol, the protocol implementations don't need to understand what the data in those packets mean. That only needs to be understood at the edges. It needs to be understood by the modules, 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 call data 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 pull 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 transfers similar to ERC-20. The semantics are a little bit different because you're actually transferring tokens between two blackchains, so you need to account for supply, but the call data is similar. More complex use cases we expect will emerge over time, including things that look like sharding but are architecturally 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 alongside an 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 sharding, but they still have this local security reasoning. You only need to reason about the blackchains you're directly talking to over 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.com. We recently released Candidate 4 of the IBC 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 blockchains, 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 the design criteria of modularity, locality, and composability, and how you can get involved and help. So please do. You found a star. Thank you.