EthCC 2: Chris Chung

hi guys we were kind of running late so if you didn't come to see me you're gonna have to sit through my thing anyway so my name is Chris I'm from Claire Mattox here to talk about interoperability kind of blockchain interoperability but more generally how we can kind of achieve more platform agnostic interconnection of systems so first the boring part use climatic s-- we're blockchain R&D company based in London and we have a lot of research going on in many of the main areas of blockchain so consensus privacy into economics so incentives and some governance and identity stuff one of our main kind of developments is our own etherium client so it's a fork of go theorem we've made some modifications to make it suitable for our needs but it's designed to be kind of a platform to allow the construction of commercial networks and one of the main projects that were building using our client is the utility settlement coin which is a very ambitious project we're working with seventeen cancer banks in our consortium and we're trying to catch arise central bank money on a blockchain and so in the regulator context a lot of the focal areas are very important to us and the way that we design those for our use cases very important but the idea is what's the vision so why we why we doing all this so most of the work that we do is to to get to the web 3 vision our vision of peer-to-peer Internet infrastructure decentralized everyone's vision right and we do that kind of via our initial object USC project which is try to disintermediate a lot of the centralized components of the way the financial markets work in nowadays which is the first step that we believe to be towards that decentralized peer-to-peer ecosystem so to interconnect the future so to what we see in the future is actually a network of networks a decentralized network of decentralized networks each of which carry out their own function corporations got that concept of a network or you guys as a community can sense where network for certain use cases and certain purposes and with these scattered networks they may be brought up they may be disparate they may be implemented differently speak different languages but all we want really is an interconnected future where all these systems can be in harmony talk to each other interact as you might need as you might need them to be so in a global decentralized future how can we build and facilitate all these disparate systems to talk to each other and interact without being siloed as they are today so another interoperability project right why another one so I'll talk a bit about where Interop has come from and where we want it to go a lot of conversations traditionally have talked about topic swaps the idea of just transferring value or token ownership between different chains that to us is not all interoperability is because that only restricts one use case you can only transfer token value saying with portable tokens so the idea is being okay the complexity of atomic swap survived let's say hash time locks which are a use case specific mechanism let's get rid of that porter token to another chain and then you can do the same things natively on that chain that's who ask kind of fulfils the same thing it's just another value transfer so there are projects that tried to tackle it from a protocol level in a more generalized way like cosmos polka dot probably heard them and they're quite good but problem with us is that the opinionated nature of that protocol and the kind of centralization of the way that that protocol gets upgraded means that it restricts the use cases that you could possibly use it for so for us high value low volume trades wouldn't work on that mainly because one you have token backed incentives to secure the network which restrict the upper limit of the value you can transact and secondly you have kind of subcommittees that decide how that protocol changes and gets upgraded and that's very centralizing we don't like that at all and the goal is we want generalize on interoperability and what is generalized interoperability so the idea of being natively on one system how can you interact with another one as if it was on your own seamlessly so you you as a user could not tell whether or not you are executing a transaction a cross chain or within your own chain generalize insurability allowing you to leverage all parts of any system you're trying to connect and perform transactions and state transitions natively without having to deal with the complexities of inter operating between systems and we think the current climate hasn't really really tackled the goal of generalizing interoperability well enough to fulfill the vision of an interconnected future so ion is our approach for trying to make that more open and more agnostic so it's an agnostic framework so as you saw before atomic swaps are very use case specific they built mechanisms around facilitating the transfer of tokens what that meant was you couldn't do anything else but atomic swaps so we use case agnostic because we want to allow developers to develop any cross chain application they may want to wear platform agnostic so what that means is they've persist the specifics of the framework don't tie itself down to a certain chain or a certain implementation and it's not opinionated on how that mechanism works as polka dot on cosmos are an infrastructure agnostic so we don't want to make architectural or trust assumptions to facilitate interoperability because those don't translate to all settings and so we want what we want to do is make it easier for developers to look at their chains that they want to connect and say okay what what do we want to do what what's the cross chain application we want to write they don't want to care about all the complexity of having to deal with the finality concerns of two different chains the way that these chains right state to the ledger all that complexity all they care about is how do I do this thing between these two chains and so part of the goal is abstracting away all that complexity and giving providing an interface for the developer to write these smart contracts through an expanding library of interfaces so that the interfaces are an implementation of what we define the protocol to be which I'll get onto a bit later and the main idea is we try to leverage the characteristics of the target systems so we don't want to add more opinionated mechanisms to decide how that happens but we say okay if I change its etherium and our chain is near Oreos we use those characteristics so we don't undermine the security properties of those systems and very importantly no token backed and no ico so we're not dodgy so how does the protocol achieve this or what's the architecture so like I said you have an application layer so given a set of implemented in interfaces the developer can then use those to develop the applications so that's the use case side and then you have the protocol layer so this layer is where most of the complexity of interoperation is hidden away from the application layer and the protocol layer is separated into two other layers a state persistence layer which stores knowledge of state from a knowledge within the system and a validation layer so the idea for us is for two chains or two systems to be able to interoperate they must know about each other and that entails that data must be transmitted between them and when that transmission happens that data must be stored on the on the opposing chain and then validation of that state to ensure that the data is correct and was not forged so these two layers make up the complexity of how those those systems would connect I'll dive into each layer now so state transmission so like I said two chains can only know about each other if you can submit data between them so if you do have two chains the way that you would do that is obviously each chain may be completely different it could be a theorem and an completely different chain or it could be two ethereal chains and the way you connect that is by constructing a block in the format and submitting that as a state-transition transaction onto the other chain what that does is it allows your target chain the entire history to some extent of the other chain which allows you to verify a transaction on another chain and data and execute a transaction on your destination chain dependent on that what that allows is that generalized interoperability now you have access to the state transitions and the data from another ledger and with that you can leverage to create transactions that are dependent on data from another chain so if you want to verify that Bob did pay you on chain B you get that transaction over you verify those the transaction metadata to ensure that he did do that or if you're into operating with another chain that doesn't do things like aetherium maybe like I village of fabric the way that they write state to the ledger is different but what you can do is leverage that state and say okay what's the data here and I'll use that on my theorem chain deck so you can execute transaction so that allows you a very open set of I guess hooks that you can use to develop your applications on and this doesn't undermine the the properties of the system because you can leverage data from another change is how you would if you were natively on that chain this layer is the layer that the application developers would interact with so application developers would say would query state from another chain after it's been persisted and then use that state stored at this layer to then execute their transactions but validation so when States submitted it has to has to be validated otherwise you can forge block data and maliciously prove that you had sent that you never set on another chain to try and cheat Bob what how does how does it work so this is kind of a core part of what makes the protocol secure the validation layer checks and verifies the consensus result of your target chain so when blocks are mined and written depending on the consensus algorithm used to reach that state you have to then verify again that the the algorithm that did that and so what you're insuring is that blocks are transmitted definitely were constructed and mined before you can submit it so let's say for a proof of authority chain or BFT chain where you have validates at sign of each block when that Windows when that data comes over for submission on your destination chain you can check the signatures against the block to ensure that the block was actually mined and validated by the validators that you've reported what that does is it guarantees the correctness of the data being transmitted what the validation layer also does it becomes the teller of finality so as soon as data comes in and is submitted for persistence it's available for use by application developers for trial for transactions what that means is only state that has validated to being final to be final should be passed down to your storage layer this prevents kind of probabilistic finality problems where you might have orphan chains or forking and kind of executing a state transition on an orphan chain with caused problems so ensuring that your validation has some guarantees of finality means that you don't run into those issues once again it's leveraging the characteristics of your two chains and it doesn't make any assumptions on mechanisms that could undermine the security properties or either chain so what we implemented so far so cool name ion ionosphere that's just a name we give kind of the the library of all implementations under the iron protocol so currently we've implemented an aetherium aetherium interoperability with a few different consensus mechanisms we've done click thority istanbul bft you're probably thinking okay so how can I fit this into main chain proof-of-work is a bit of a hard one because it's proof-of-work so part of the idea there is you could generate a threshold finality before you submit blocks or you allow everyone to submit every fault that ever possibly happened the the risk there is it's up to the user to know which chain is main chain before they interact with state from another chain but essentially whatever incidence algorithm gets implemented in future as long as you implement a validation layer that replicates that consensus mechanism you can validate correct blocks actually we've also done a hyper ledger to fabric work-in-progress that proves that we can take state from a fabric chain submit that to an aetherium chain and interact with fabric state so we now have basically probably one of the first actual direct interoperability is between two different them into block chains and we have a few of the kind of implementation so transact ion is the the base pvp atomic swap use case built on top of the ion protocol repository there simple shares is a basic fabric network that you can set up that does a share issuance and trading which allows you to execute a trade of a share and then settle that on an ethereal side so the payment like being on the etherium chain and actually a couple of weeks back we did hackathon with ion and a lot of the attendees did some great work so at horror and model day an fx swap between two aetherium mate and pub chains so between rinkeby and rinkeby an actually our autonomy network sorry Santander jury could work they did debt issue floo so issued debt between a fabric chain of the theorem chain so they issue a debt on the fabric side and tried to do something with it on the etherium side and the three labs and i think i here somewhere tried to do private calculation of Libor rates and to publish it on a public chain for the venues on a set private chain via the verifiability of of the state transmissions so i honestly that's what we've got implemented so if you guys kind of want to see what it's about get involved possibly contribute there's a lot of implementation that needs to be done for every context that i on could be used for so currently these are the implementations but the idea is implementing the protocol for what you could envisage as your two connections between the systems that you care about with the consensuses that you may use will widen the set of libraries that can make it a bit more universally interoperable so what can you build right so as i spoke about the proof of work validation layer that's quite finicky and it's really dependent on your tolerance for finality possibly at some point when the theorem super no comes out you can we can build proof of stake validation layers and then applications what can you build on top of these systems so a death spot across chained X so maybe I've tokens sitting on different chains you can something between each other atomic swaps obviously the the classic or just arbitrary data transfer a lot of value nowadays is just data they're not you can prove something arbitrary data transfer is probably the the ultimate one and the way you do that between multiple different chains is up to you obligatory we're hiring and I guess find us online we're open source so a lot of the implementation stuff is open source we've got a white paper coming up that should detail a lot of aspects of of the framework and the vision so if you guys wanna have a look we've got some articles on it on medium too and if you are contributing or you want to see what's about any having issues throw some questions on Gitter or you can ask me questions now thank you very much [Applause] I thanks for the presentation can you just go to put it in your face can you explain in the first state in first stage sorry you kind of transmit the data in form of transaction from one on the right yeah and the second phase you kind of validate it yeah by like if I got you right emulating the consensus of the source yeah yeah example let's say you have to if you're you sidechains both are EVM based power and one is let's say proof authority one of one is proof of stake and both are using tender mean consensus so when you submit when you submit that state when you construct your block for submission you have to have also the metadata with it that you can use to verify that so with a proof of authority you have validated signatures in your extra data of your aetherium block we just the validator that that what we take the block basically infeasible yeah you take the whole block you take our block but what that does is that encapsulates all the transactions that happened and you can make verifications to that because in the in the block header you have you have two two things that we use it as transaction tree root tea tree root and with those you can assert that any transaction in that block existed in so you can make a verification that any transaction exists there using those two pizzas to the block header both it's important obviously first to validate the block header so when you submit the block you can date the signatures to make sure it was a real block otherwise you can just include random transaction and then verify that transaction exists that it's a bit of a finicky mechanism because also block headers don't contain that much State so all you have is a merkel route that proves that way doesn't prove just it's a hash of all we thought all the containing transactions so you have to kind of deliver a local before any given transaction for that yeah okay and then once you submit that you can then using that proof say okay well this transaction happen this is a vendor admitted parameters and then you start on your other chain yeah yeah see me off I think there's a question here last question so yes so I was wondering if you have interoperability between two chains a and B and then between B and C do you have a transitivity and I can direct between a and C Oh what could we'll need to make it easier because for example do you need self-describing data that can be read by any chain you you have if you have a stronger describing how your data can be read yeah and any train you you have implementation for yeah so that's a good question and the idea is that if you have a B C a can talk to be a can talk to see or P can talk to C so kind of the routes that you take is dependent because that that bilateral connection is very specific because of the way that that data needs to get transmitted and translated so when you construct your block for submission and that gets stored on on your destination chain the way that it then translates that data to leverage it for your transactions there is is specific to that biologic connection so you have ABC and they're all different systems a and B will connect differently a and C would connect differently B and D would connect differently but you can have let's say linear so we call it continuous execution so a linear execution of code that's dependent on state sequentially between a lot of different chains so you can end up with let's say a serial execution of of something that may be a payment rail where trade initiates on one chain it gets executed here and the payment settles here you can have that go through and basically you have like a seamless set of transactions that will throw the flow through network which is amazing for us because that's the seamless nature we want right we don't want to have to think about all that complexity we just want to be able to execute it's actually a series between networks I've answered your question thank you very much guys [Applause]