zkSummit - Lightning Talks: Christopher Goes (Cosmos)

Transcript

so I am going to talk about permissionless entertain scaling with IBC which is not yet in zero knowledge although it might make use of zero knowledge in the future or allow existing non zero knowledge block chains to use zero knowledge features of block chains which have it so first enterplak chain has become a bit of a buzzword so I'll try to specify what we're trying to design here IBC is a protocol designed to be implemented as part of the state machine of a blockchain it could be implemented on block chains which support smart contracts like aetherium in a smart contract it could be implemented by custom state machines like some of what we're building with the cosmos hub as a

module in the state machine or a sub component of the state machine it could be implemented by lots of different future chains maybe para chains could implement IBC we hope if I managed to convince the people sitting in the front row IBC is designed to be used by heterogeneous chains so it doesn't require a common virtual machine we want it to be the case that different chains which specialize in different things maybe some of those things because their knowledge proofs can implement as part of our state machine IBC we want IBC to enable users of a set of chains to choose which chains they trust and how much they trust them we want it to be permissionless so that different block chains can open and close connections relay data packets tokens assets and

code in between each other without anyone other than the users involved needing to approve it so no governance required we want it to be in the same vein automatable smart contracts should be able to use the interchange system and we want it to be efficient at least in the amortized case such that most of the traffic and transaction throughput should be used by the actual data and the actual state transitions not the consensus proofs so the basics of how we do this are that we require an efficiently verifiable consensus transcript which is commonly known in blockchain parlance as a light client so in one in say two chains with an IBC connection but

usually we specify IBC is a protocol in between two chains each chain will run a like client of the other it will start out with a route of trust and it will relay header updates or some off chain process where we they had our updates from one chain to the other so that each chain tracks each other's like client and then can verify say any state on the other chain with a Merkel pal booth in order for this to be efficient these headers so these fragments of the consensus transcript need to be cheap to verify and the chains themselves need to have fast finality if you want to cross chain transactions to proceed quickly you also need a few particulars to be true of the incentive design so

specifically you need quite strong like client guarantees who want it to be the case that since IBC is only running like clients who wanted to be the case that if a liked client can be convinced of a committed state that wasn't actually committed someone gets slashed because hopefully that will disincentivize validators from lying about the state so you want stronger guarantees say then you might have an a Bitcoin like client so on top of verification IBC provides sequencing between two chains if you want to enforce invariants about the combined state of some set of chains maybe that's the balance the token are conserved you need to be able to reason about which events occurred in what

order on shards of State on different genes so in order to do this IBC provides as a protocol tcp like exactly once message delivery each chain implements queues encounters on the messages which prevent replay and only allow them to be committed assuming the protocols implemented correctly in a particular order so in in order to do this we need to merkel proofs from one chain to the other which are then verified against the SE root hash and the header and those merkel proofs include the sequence numbers of packets so each chain can verify that the other chain sent the packets in the order in which it is receiving them and processing them on top of this we can build a whole host

of different applications the simplest one is token transfers where on one chain may be the source chain for the token you have Bitcoin and then if you want to send Bitcoin using IBC to another chain you escrow it on the source chain in the IBC handler you send a packet to the destination chain proving that this Bitcoin has been escrowed on the destination chain you can mint call it a Bitcoin voucher virtual Bitcoin send that Bitcoin around on the destination chain maybe turn it into a user issue token on Zeke a sapling circuit send it in zero knowledge play around with it even send it to another chain when you're done you can burn the voucher and prove that

you've burned a voucher to the original source chain released the Bitcoin from escrow and now you have your Bitcoin back so in that sense it's not it's not like an atomic swap IBC enables token transfers across chains obviously can also enable the whole host of different applications multi chain smart contracts where you have different parts of a sort of complex multi chain state machine executing on different chains and you pass some part of the smart contract state closure as variables to the next chain and the sequence you can have delegated security which we're building out for the cosmos hub where the validator set of one chain so this is particularly useful for proof of stake the validator set of one chain agrees to

be / of all four equivocations faults committed on the second chain which are if they are committed submitted over IBC so that way say someone who wants to start up a blockchain but wants to rent out an existing validator set in return for some to be determined compensation can convince that validator set to accept slashing risk and so gain Economic Security of the original sort of Route chain IBC can also instantiate lots of different charting protocols depending on what sorts of ordering guarantees you want although we think it will be most useful in the case of heterogeneous chains where different chains can specialize in different application level provisions but users can use the same assets and can craft

complex interdependent state machines across several chains so what is the state of affairs we are trying to write IBC is an open protocol I want to emphasize that it's not although it's being primarily developed by Thunderman cosmos it is not dependent on the use of necessarily our blockchain or our token all the specifications are in the open at github comm slash cosmos slash ICS and we have a sort of ecosystem working group forming with file a weekly zoom calls which are recorded and you're welcome to join a person if you like let me know you can find us on twitter at cosmos or email me at CW goes at tender medCom we expect MVP implementation along with a

MVP final specification sometime in summer 2019 i don't want to be too specific thanks questions hey thanks for the presentation some still slightly confused if you send Bitcoin in an escrow and then prove it on to one of the cosmos chains how do you use the information of the burned token to release the Bitcoin inside the Bitcoin network itself how to use the information of the printer so on the cosmos chain you mint a Bitcoin voucher right and that Bitcoin voucher

is stored in some key in state which the source chain knows about the Bitcoin chain knows about that key in state and can read the amount of that voucher so then when that voucher is burned you can send a packet back to the source chain which proves that the amount decreased and the source chain will and it also the packet also contains data about which address the original Bitcoin should be released to then the source gate chain can accept that transaction so the Bitcoin to be clear the Bitcoin chain would need to change state machine to do this we have another more complex solution to work with the existing Bitcoin chain using like a multi-party ECDSA peg but to custom chains can understand to understand part of each

other state machine and then they can do this safely could you say something with more about the scalability of the of the protocol because I can see that when it's like one-to-one communication between two blockchains I see it working but in the future if there is many communication and/or many sightings or block since communication to one to each other a this means like a lot of medical proofs will need to be proof and so on so yeah how do you do you have a solution for

that oh ah that's a good question I mean IBC is designed to it's not specific to a particular network topology and we expect the network topologies that emerge to be reflective of the economic properties of the commerce that the chains are trying to provide so for example if there were a bunch of payment chains around the world most commerce is local most payments in Shanghai are to other vendors in Shanghai those payments in Oregon or to other vendors in Oregon occasionally those two chains need to settle you know Shanghai org and transactions but that's much better so we would expect the payment chains to be local or maybe to be only one hop away via IBC in most cases and the exceptional cases yes the payments are

slightly more expensive all right let's thank christopher again