So, you probably heard people say something like, "Let's put it on the blockchain." And as you can probably see from prior modules, that's really a misnomer. There's not one blockchain, it isn't the blockchain, there are many different ones. So, we've seen that there are public blockchains, private ones, ones that require permission, ones that don't. So, why is blockchain interoperability important? Really for the same reason that blockchain technology itself is important. So, while it's in its infancy, it clearly has captured the imagination of thousands of people around the world. So from developers, and people in technology, as well as people on the business side, those focused on social change, and the ways that this technology can transform our society in many ways similar to the way that the Internet has. One of my colleagues Paul Koolhaas, has a good quote about the future with a Web 3.0 that is buzzing with various kinds of blockchain. So, public blockchains, private ones, anonymous zero-knowledge proofs, all of which have various applications built on top of them. So, there's not one blockchain to rule them all, but a diversity of different blockchains for various use cases and purposes. The analogy to the Internet is also a good one because the Internet itself is not one network, but it's a collection of different networks. So, when we talk about blockchain interoperability, the value of different blockchains being able to share information increases the value of each of them exponentially. In the same way as in 1994, we couldn't really imagine the way that the World Wide Web would evolve to what we have today, the social networks, and e-commerce, and pervasive video. If you look at the way the different blockchains could interact, the possibilities are literally endless. Another point that's interesting to note is that Ethereum is the only blockchain that has a public version and a private version that are compatible. So, there are a number of companies who have private versions of Ethereum with a roadmap to move toward the public blockchain. So, now let's talk about a specific example of blockchain interoperability. In 2012, a developer named Joseph Chow created BTC-Relay, and a few years later he joined ConsenSys. The purpose of BTC-Relay is to take information from the Bitcoin blockchain, and use it in smart contracts on the Ethereum blockchain. So for example, say that I wanted to be able to pay someone in Ether based on having received a payment on the Bitcoin blockchain. I would be able to create a smart contract that takes in information about a transaction on the Bitcoin blockchain, and then executes the ether transfer once I have that confirmation. So, in order for my smart contract to work, I'm going to need some information in the form of a proof from the Bitcoin blockchain. So, the way that we're going to get this proof is in the form of a Merkle proof as we talked about in earlier segments, which comes from the header on a Bitcoin blockchain. So, instead of taking the header and the body, we can look at just the headers for our proof. So, the way that we get that into a smart contract and be able to use it, is through something called a Simplified Payment Verification or SPV. So, what we do here and what BTC-Relay does is have a copy, in effect a light copy of the Bitcoin blockchain, Bitcoin transactions that you can check. So, when the smart contract needs to know whether I've been paid at this Bitcoin address, instead of having to look at the entire Bitcoin blockchain, the SPV can determine that that specific transaction has gone through. The beauty of this design is that you can separate the different elements, and that increases security. So, BTC-Relay having the SPV and being able to verify means that BTC-Relay doesn't need to know what address my smart contract is sending to. It just needs to be able to verify that the Bitcoin transaction happened. For BTC-Relay to get the information from the SPV, it needs to be provided. The way this works is similar to other blockchains where there's an incentive for our participants for nodes on the system to provide that data. So, as we said, there are other approaches to blockchain interoperability. Another one is called the Interledger protocol. This is something that two employees at Ripple developed in 2015. Ripple is a company and a cryptocurrency that facilitates bank to bank transfers between different countries. So the way that the Interledger protocol works is by having various connectors, and validation stages as a transaction moves between various different blockchains. They've done a demo of this across seven different blockchains. Another approach to blockchain interoperability is Polkadot. You've probably seen a variety of interesting names in this space. So, Polkadot is planning to use three different components having a relay chain, parent chains which participate in the system, and then different bridges to connect to blockchains like Ethereum. So, Polkadot is planning on launching their genesis block in 2019. Another approach is Cosmos which is planning to launch in early 2018, and it's modeled on a concept called side chains, a different approach to working with the Bitcoin blockchain. The concept is to have a hub which the first one will be the cosmos hub, and then a variety of zones around it that connect. Then eventually, they plan to have many different hubs, and different zones can be a hub for different components. So, there are also various consortia that are working on different approaches to blockchain interoperability. One of them is the Enterprise Ethereum Alliance, and one of their goals is to work with various industries and working groups to develop interoperability standards. Another one is the Blockchain Interoperability Alliance, which is a group of several companies and taking their specific approach. It's also worth noting that there are supportive technologies that employ blockchain interoperability. So, there are a number of different files storage approaches. So for example, the IPFS, the Interplanetary File System, and Swarm where instead of files being saved in central server, they're saved in a distributed fashion.
