zkSummit - ZK0x02 - IBC & private-public blockchain interoperability- Christopher Goes (Cosmos)

Transcript

[Music] afternoon my name is Christopher goes I work for cosmos and also Crypt iam labs and I will be talking about inter blockchain communication or IBC and how we might be able to use it to enable public private blockchain interoperation so a little bit about this talk first to lay the groundwork IBC and cosmos get conflated a little bit which is partially our part but IBC is a protocol so it's separate from a particular implementation in a particular network anyone can implement IBC in their blockchain state machine and communicate

as I'll explain it a bit with other block chains implementing compatible IBC I'll go over our design goals in constructing the IBC protocol hopefully managed to explain a rapid version of how to do it yourself on your own blockchain and finally walk through an example of using the inter blockchain communication protocol to connect the etherium in Z cache block chains to allow you if you hold any ERC 20 tokens to send those a or C 20 tokens through IBC over to Z cache spend them privately using the Z cash as ek snark circuit and then perhaps later perhaps knots in the back to aetherium where they would

convert into the original a or C 20 but before we get to that fun demo I'm gonna tell you how it works so what inter blockchain communication interblock chain communication is a mechanism first and foremost for relating data packets between two chains which we'll call a and B off chain real layers so perhaps a server in the cloud on your desktop it doesn't matter are responsible for watching the first chain chain a and committing IBC packets which are sent so publish to chain a and a cryptographically verifiable way sent to chain B when published to chain a they contain some destination data which will allow these real ayres to figure out which chain B they should publish the

packets to and therefore route the packets car I'll get to that in a bit these relays importantly are not permissioned so there are different kinds of fee models you can implement on top of IBC to properly incentivize everybody a very simple option is simply that the person sending the sequence of transactions sending the asset over into blockchain communication pays the fee to relay relays themselves other options include fee payment in the sending transaction that goes back to the relay err so that may be a central group of relays could relay very efficiently IP the ibc protocol is a payload opaque so just like say the tcp/ip stack does not define the data payload for the layer on top of it IBC only defines ordering

semantics and correctness semantics for a packet delivery it does not define what the application does so any kind of application invariance you might want to implement on top of IBC you can do so and you can implement these invariants because IBC messages are authenticated so it's not just that we're sending data from one chain to another that would be useful but much more useful is the ability to provide guarantees across the combined state of two chains or maybe even n chains so we have some rule set right we have a rule set on the second chain chain B and that rule set defines a subset of packets published packets from Cheyney to chain B which chain B

will accept we can make whatever rules that we want and the IBC protocol defines rule set which will be executed in the state machine of chain B that gives us a lot of really useful guarantees which I'll get to in a bit but at the very high level we know that if a packet has been received on B so I BC relayer committed a transaction on the second block chain B and transaction succeeded then we know something about the state of a on chain B we have some guarantee that chain a when this packet was sent had some state because chain B verifies a proof you want some way for the state machine so independent of any trusted we they're no trusted user only the state machine of chain B is required

to verify the proof that this packet was sent on chain a the different ways you could verify that proof the way we're planning to implement it initially not quite a Bitcoin style like client but if you're familiar with the Bitcoin like client model it's pretty similar where you have Merkel state proofs for sub state so the IBC packets will contain a proof that it was successfully published on chain a and then when chain B receives the transaction which attempts to send that packet to chain B chain B will check that proof check the Merkel path and assert that it was in fact included in a trusted header of chain a another way of doing this which I'll touch upon later it would be

an intermediary peg zone so sometimes you might not have the option to change the state machine of chain B if you're working with a capable contracting language on top of a vm like the EVM you definitely can but if you want to utilize IBC with an existing chain where you can't change the state machine at all like Bitcoin or Z cash or perhaps chain where you just have less control you might want to use something called a pig zone so what must you trust for IBC this is integral you trust the consensus algorithms and you just like client verification only but if and only if those two are correct can you assert all the invariants that IBC will allow you to assert use cases so the basics as I've alluded to IBC will allow you to

transfer tokens fungible tokens non fungible tokens possibly other kinds of tokens across multiple chains you can conditional eyes contract execution on aetherium or or transaction output locking perhaps on Bitcoin on the state of another chain so you could say that some contract on a theorem can only execute if Bitcoin was sent to such and such address and z cash was sent to another address you can conditional eyes on the state of multiple chance at once in some ways IBC is is like sharding there many charting proposals but it would allow you to split and paralyze the contract logic against multiple chains with compatible virtual machines so you could shard the code of your

contract on two different chains IBC exposes a channel like primitive if you've ever worked with golang or another language which exposed is a channel on which you can send and receive in which blocks or so to speak you could write contracts using channels that would translate into lower-level IVC calls you can compose hybrid state machines with different VMs so you can't you can't really short a contract against different PM's but you can still have a sort of virtual contract on top of multiple chains which ends up using different underlying state machines so evm cosmos and z cash for example another example use case were really interested in is delegated security

so since IBC provides proofs of actions on one chain to another you could use IBC with multiple proof of stake chains to delegate the security of one chain to another what does that mean that means that if a validator commits a protocol fault an attributable protocol fault on one chain then that chain sends an IBC packet over to the other chain maybe a chain with more value at stake or a chain where all the validator sort of agreed to use as a consensus point and the validator can be slash' belong that chain so even if the chain which are sort of running your VM Owen maybe doesn't have as much value at stake or doesn't have as much security if you can

get your validators to agree to accept being slash' belong another chain that process can be conducted in a verifiable way over IBC so the key point is that IBC allows for heterogeneous chains it's not a sharding proposal to split the same chain into multiple pieces and paralyze execution that way it's a sharding proposal to split any number of chains into any number of pieces and paralyze or don't paralyze whatever you want and the advantage of that we think is that sovereign chains can have really custom and may be really risky features right you know bitcoin didn't want to add zero knowledge proof because they were kind of untested

crypto which is a reasonable concern you don't want to put the Bitcoin network at risk you don't want infinite inflation if the trusted set up was compromised but this way with IBC you can elect to send your assets to the chains which have the features you want to use make use of them there send them back or not and choose whichever it's a profile you want to accept so how does this work more concretely with implementing what we'll say is a cross chain contract or a model across multiple chains at once you want to be able to preserve invariants contract invariants across the combined state of several chains so let's say you have a fungible token which is defined by any number of units of that beat

token being exchanged for any number other same number of units it's fungible and a finite total supply so you can't mint tokens out of thin air and you can't maybe you can delete them but you can't delete them for the simple example how would you do that over IBC so the IBC send packet on chain a would burn the asset or escrow it perhaps so if you want to send an A or C 20 token you would have a contract on aetherium and you would send your tokens to that contract which was then escrow them in the contract until later and it would provide an IBC send proof that those tokens and fitness code then on chain be when the IBC packet is received you can mint what we'll call tea vouchers so tea

vouchers are another token they're token a native token of chain B which could have like a different rule set although it needs to have the same basic fungibility guarantees and then later on when you're done with chain B you've done whatever you want to there you can burn the tea voters on chain B and redeem the previously escrowed tea tokens back on chain a so one interesting question here is which is really the voucher IBC does not natively have as a protocol one canonical chain or any canonical chain so is it is that the asset T on chain a is the tea vouchers on chain B which was original nobody knows the state machine of B of course must verify that the state

machine of a actually burned these tokens so there are different ways to do this the way we will implement initially and in sort of the cosmos IBC implementation will encapsulate most of this knowledge in the state machines themselves right so when we right an IBC connection on chain B we will know that the IBC send concerns a state machine on chain a execute such and such logic and we'll know that it burns the tokens that is a little limited in that it precludes implementing connections and certain orders because you have to know that beforehand you have to know that when you're implementing the IBC connection on chain B what type of packet corresponds to burning t tokens on chain

a other future options for less limited versions would involve some degree of compatible VMS where you could verify the code itself so if the code as it is and etherium is accessible in state and you can prove that some certain code is that some certain address then you could have more dynamic connection and reconnection logic so after a burns T in either case on when sending the IBC packets they write some data to a provable store Merkle store most likely and then B can verify the light client proof of the written data I'll get to exactly what the data is in a second but the important part is that the data couldn't have been written if T hadn't been burned right that's the guarantee you

want on J and B you want to preserve the total supply across both chains and to do that you need to know that when you're minting these vouchers on chain B you burn the vouchers on JEA okay so IBC implementation concept one connection connection is the set of data stored in consensus state necessary to verify packets between two chains so to open a connection between two chains you need to start with what we call a root of trust a root of trust could be a Genesis block an initial validator set a connection creation that needs to be defined when whatever you're using to implement the IBC connection is deployed which might be a smart contract which

might be a governance software upgrade which might be something else any connection user notably can check the route of trust so someone has to decide what it is but anyone else who actually uses this connection could verify that it is what they expect then you want to once you start with your connection update headers so to verify Merkel proofs in subsequent blocks of packets that have just been sent you need new headers from the source chain to verify that the packets have been proved in state so you need some function which allows you to verify an update from headers at one to header set to what tender meant this function tracks the validator set in checks at 67% of stake has signed the next Valladares that has subsequently

there's some fancy bisection ways to make that faster if you have infrequent IBC packets but the essence is simply that you check that each this governing stake of the proof of stake network signed the next update then you know the trucks trust the next header and Nakamoto consensus the previous chain continues with most work seen as long as it extends that sequence of blocks headers yeah a lot of a packet proof verification as I mentioned so closing a connection usually you don't need to close an IBC connection it can remain open forever and if you want to continue sending packets between those two chains there's no need to open a new one however in exceptional cases you might need to do so if there were a fork

depending on whether the connected chain was proof of work or proof of stake this varies but or if there were a safety violation where some chain committed a protocol fault maybe you know signed two valid histories and the case of prove mistake what and how this must be done depends on the kind of Byzantine event that occurs so if it's some identifiable fault it could be easily done automatically if two headers two valid headers at the same height Pretender meant consensus are both published to the IBC contract do you know that a protocol fault has been committed and you can close the connection and stop any further packets from being transferred so on top of a connection we have messages and IBC implements vector

clock for two processes which in our case are block chains and then messages can have ordering guarantees over the Spector clock so if we have two chains a and B some packet counter I X&Y events on these two chains which are other transactions we know that when a will if a sends back a tie before B receives packet are he receives pakka died before he gets the receipt for packet I a sense for packet I before a sense for packet I plus one and those three things are all guaranteed by the state machines we implement IBC in right so we implement that QLogic which I'll get to in a second then we know that if X is before a send packet I X will be before be his

received packet I and if Y is before because received packet I who I hope you before it gets the receipt from Mac and I and you can see that we can provide like counterfactual proofs or how total supply is conserved this way this is generalizable although we probably won't do it initially but it's generalizable to an end process vector clock if you want to order events between multiple chains so that you might all construct a packet sequence so that you would always know that a event a on chain a happens before B unchain B happens before little C on chain C so the ordering guarantee can be used to reason about the combined state of both chains as a whole with the example of

fungible token total supply if packet I is sent on a chain a then we burn the tokens back a tie is received Unchained B we meant the vouchers and we know because of that counterfactual there we know that the tokens must have previously been burned on a it's a total supply is conserved counters and metadata are used to prevent replay so replay is a concern with IBC because these packets are just data right you send you you send a transaction to chain a which provides an outgoing proof for packet packet I to chain B and then that proof is some data so we only want that proof to be usable what's on chain be and can be only and we want chain B to know that it came from Jane a how do we

do that we have four queues so each chain for each chain a has two queues one for outgoing packets from A to B each drawing the packet information so it can be proved with a marker path including a sequence counter and an incoming queue for receipts from her sent from B to a to acknowledge outgoing packets Jane B has the reverse set of cues outgoing packets from Jane B to chain a and incoming receipts from Jane a to chain B each cue keeps a counter and packets can only be sent and received in order so the state machines on chain a and chain B check that if you know I'm receiving packet I on Shane B

that I've already received packet I minus 1 and I won't accept packet I plus 1 till I've seen packet I each IBC packet include is a five tuple including a type so this is used from multiplexing which isn't important for understanding the protocol but it easily allows you to reuse a single connection with multiple applications a sequence which is the ordering guarantee to prevent replay of the same packet on the same source and destination chain the source chain which has prevent massacre ratings you don't want it to be the case that I could pretend to be sending a packet from chain C to chain B when in fact the packet came from chain a the destination which prevents the same thing except for replaying on another chain where you

masquerade a packet which was intended for B but instead attempts to confirm it on chain C instead and data which is the opaque application-specific tailored so these combined with the cues give you the guarantee that packets are committed once exactly once in order from only one chain to only one chain receipts acknowledgments and timeouts so an IBC receipt is an IVC packet back to the source chain which proves the original packet was received and acted upon right so that may that what that means depends on your application in the case of the tokens simple fungible token example it means that some vouchers were minted on JP and then once chain a gets that IBC receipt back with the receipt is just a

standard packet we call it a receipt to distinguish its use case once chain a gets that receipt back it can delete the data for the Markov proof and it can also do some safety things with regards to acid escrow which I'll get you later the IBC time-out on the source chain will allow you to specify in an IBC packet as an additional field so this is optional a timeout tu which can be specified as a block height or as a timestamp if you have a consensus timestamp relative to the destination chain state so in the state of chain be the destination chain if you want to implement the safety needs safely needs to reject packets past T T must be proved back to the source chain

if you want to be able to release assets so one concern with IBC is what happens if chain B is censored or offline or the transaction fees are super high or for some reason you can't get the receipt packet the destination packet confirmed on B and timestamp allows you to to guarantee that if that doesn't happen you can still get like a header proof from chain B the timestamp was passed something into this packet hasn't actually ever been confirmed and then you could re release the tokens us Croton chain a and try again why what does IBC give you first it gives you one asset many chains as its can be freely transferred with Zend your

Bitcoin from Bitcoin to aetherium to cosmos to Z cache then back or not it's always the same at Bitcoin we're not creating new assets here through that path going back through Z cash through cosmos through theorem and then back to Bitcoin you can always get your vanilla Bitcoin back assuming all those chains are working as usual maybe even through another path if people are willing to exchange IBC assets created through a slightly different path which we expect to happen multi-hop routing can reduce the implementation cost since as long as the sort of the API is between different block chains implementing some subset of IBC like I received for fungible tokens are the same then you can route your IBC packet through block chains which

implement connections to the other the other change you want to get to as long as the path exists and it's permissionless you can set up a chain implement IBC with an existing asset and add new features without asking anyone's permission which we think is an important characteristic new features old security when you need privacy send your Bitcoin to Z cash if you want maximum security keep it on the Bitcoin chain you need to be a little careful if you're doing this kind of transactional style IBC about link ability has a great blog post on this the link ability of something like transparent shielded over IBC is basically the same as the link ability of transparent shielded just on the Z cache chain so

when you send your assets to Z cache which is the example get to in a sec they initially start out as transparent and then you can shield them and transact them as shielded but when you send the back over IBC they become transparent again doing it this way there is using Z cache example there's no trust at setup risk because the IBC contract on the Bitcoin or on the pay zone can track the total supply in or out every time a packet is under received which escrows or on escrows tokens and as you know as long as you keep if you don't trust the trusted set up if your Bitcoin is on the Bitcoin chain you don't need to accept the risk of inflation but anyone who trusts the trusted set up can elect to send their Bitcoin to Z cache and accept that risk

risk is always opt in these these guarantees are generalizable for most kinds of assets you would want to transact over IBC and also other more complex contracts opt in upgrades this is one thing I am most excited about many many there are lots of really interesting governance proposals coming out view of them so far feature minority protections but there is a way or an interesting possibility of a way to do chain upgrades over IBC or some part of the IBC protocol which would not require governance and which would provide full minority protections so to do this you would copy here let's say I want to change Bitcoin I would copy the Bitcoin chain I would add some new features and

create an IBC connection back to the old chain I wouldn't make a new asset but anyone could elect to move and perhaps this Bitcoin to Bitcoin through a cosmo zone move their existing assets to the new chain if they want to do or they could keep them on the old chain security why that's the concern right is security so what if the new chain isn't mined by a lot of people or doesn't have a lot of value at stake with with simple proof of stake it's just less secure initially and you accept that risk but it will be more secure as the staking token moves in the original chain to the upgrade of chain with delegated security as I mentioned earlier since the new chance if the nutrients validators accept being slashed bull on the old chin over IBC then you got the

same security because the same value is at stake in proof of stake no need for a new asset and both chains can can peacefully coexist if half the stake of a proof of stake chain you know slowly moves over to the new chain of IBC you end up with two proof of stake chains which can continue on their merry way consensus requirements let me quickly check time okay I'm okay consensus requirement state finality IBC safety requires finality otherwise coins could be double spent so we're in the consensus landscape can we work this in tender mint and similar pbft have instant finality so as soon as a block is confirmed we know it's final we can

send an IPC packet Kasper FFG has fast finality now commode a consensus into which I would clasp proof of work and tezo's and the latest proposal of or ago sprayers that I've read proof of stake have probabilistic finalities you need to pick a threshold and a number of blocks after which you accept a transaction and that's an IBC packets final you can vary the threshold if you want to based on the transfer amount which might correspond to risk in your threat model pre verification which is a state machine concern with the smart contracts with a custom state machine you can do this natively so you can implement all this IPC logic in your state machine but if you want to use an existing chain without smart contracts

you might need to use a peg zone what is a peg zone so a peg zone is something called an accountable federated peg federated peg this were kind of all the rage a few years ago and then they seem to have fallen out of fashion but the main difference between what we conceive of as a peg zone and some of the previous proposals is that all of the peg zone validators are accountable and /table if they do anything wrong so you to do this we need a multi signature which could be weighted or K of M depending on the chain on the peg chain you want to join with the zone so on Bitcoin Iran sea cash in the future this might be a multi-part ECDSA protocol

which has some nice advantages but those are not quite production ready yet then you have a second tender and chain which has the same validator set as the multi signature account so transactions which are committed to the second tenorman chain must be signed by the multi signature and then can be relayed to the main chain to Bitcoin or to see cash transactions which were signed but not committed to the bridge or attributable andersz ossible or transactions which were not committed but were signed are also attributable and slash shovel and depending on the multi signature update if you have a key of M or weighted it's a little different but you could also slash for failure failure to update the multi signature of the validator set has

changed and because there aren't as many concerns about slashing in cases when a transaction has to be confirmed because the people you're slashing or also the validator set of the chain so it's not in their incentive to censor themselves and you can configure on this peg zone how many confirmations you treat as confirmed for the purposes obviously proves to other chains so an example how you would use this to join the etherium use obviously to join the etherium chains and the CAS chains to convert your ERC 20 tokens to and from c cash user issued tokens what RZ cash user issued tokens z cash user issued tokens are a super cool proposal and hopefully

someone from Z cash here can correct me if I get anything wrong but I did read the latest version of the issue which would implement Bitcoin style colored coins on Z cash or something very similar this is not in sapling sadly but hopefully will come pretty soon and alternatives to this exact example you could implement without a new circuit would be easy cash fork per IRC 20 token which exists just for that token or implementing Z cash the asset as an e rc 20 contract on etherium how do you do this so first you need to choose how to associate each ear C 20 token contract with a unique uit identifier which we presume to be some

string an easy way to do that is IVC slash aetherium slash contract address and that way of doing it has the advantage that you can create this identifier lazily on-demand so you can implement this whole system without knowing which tokens you're doing it for you can just do it for aetherium tokens generally and then later on at whatever tokens or new tokens which are created after you implement the peg what so then this will allow you to take a or C 20 token vouchers on the Z cos chain which our user issued tokens and do anything you would do with the user issue token on the Z constrain they can remain shielded they can be shielded transfer it you get the full privacy properties of the Second Circuit but then if you want to take them back to etherion maybe

there's some etherium specific years C 20 interaction with another contract on the VM you can convert them over IBC back to the original year C 20 tokens and do so what components do you need to implement this you need a dedicated smart contract on ethereum that holds the ERC 20 tokens in escrow when people deposit them in order to redeem the factors on Z cash that contract provides the proofs that we talked about earlier the proof necessary for the ABC packet that some amount X of some token Y has been Esperanto theorem then in the peg you vary the peg zone you verify proof that the user issue token has been burned and you released the escrow de Arce 20 tokens on aetherium when you

sent the uit is back from Z hash so some of the channel ordering semantics that I talked about earlier are optional IBC is a pretty much all or protocol you can take the pieces you need and leave the pieces you don't and in the case of transfers you don't need quite so much ordering it's fine if they're commutative so the Z cash multi signature peg chain is responsible for maintaining a multi-sig account on Z cash and then the signer set of the multi signature account signs the ten Dermot chain commits blocks verifies the proofs and any of the validators on this chain every to be slash' ballif they commit an attribute of a fault signing a run transaction failing to obey what whatever is written to the page chain so

step one if I'm a user wanting to convert my ear see 20 tokens since the Z cash user issue tokens what do I do I send my year see 20 token we'll call that T on the etherium chain via the usual transfer call to the IBC smart contract then the IBC contract esko's that ERC 20 token and blogs that escrow event in aetherium state tree including all the requisite information to mint the vouchers on the Z constrain so the sender of the token the amount destination address our public key on the see Josh Peck chain what happens we get this IBC packets the CIBC packet started by this transaction being sent on ethereum then a relayer has copied the proof of that transaction the event

log over to the Z cash peg train a transaction on the Peck chain then the see cash spec chain verifies that proof once the Sukesh peg chain is verified the proof the multi signature account signs a transaction which mints these or Shu tokens on Z cash in the amount that was proved in the original packet to whatever destination public key was provided and then what that person who had fact the public key which could be the original user not can receive the users who tokens spent them as normal coppice and people pay perhaps for at least authorities storage as was presented earlier then once they're done doing that if they're ever done doing

that they can send the back to aetherium in reverse so burn the uit on Z cash which will it will need to be made transparent first but that doesn't have any privacy implications because you have to do it to send it back over obviously anyways burn the UI T and Z cash submit the proof the C cash back chain and then the IVC relayer will submit the proof of the burned uit to the ethereal smart contract which will underscore the tokens and you now have them back on a theory what are the properties of this model it is permissionless its option anyone can implement it for any token which chain to keep on keep your assets on and when to move them up the asset older no risk for the existing year c 20 token in this

case holders since the contract contract total supply when the UI T's or shielded on Z cash you can Woolsey cash level privacy same level of link ability is the transaction dresses and the unshielded sparrin addresses when you send over IBC you have to be careful about that but the implementation is also scalable the same logic one peg chain can handle probably all of the ERC 20 token contracts that will ever be in existence and tantrum and will always be a faster consensus algorithm future of research again let me check a time okay I'm gonna speed through this I'm gonna take questions so any questions yes 51% attacks on the pic

chain so a proof-of-work effect chain or a proof of steak victory proof of steak Peck chain so usually improvement at least in tournament proof of steak the threshold is not 51% it's 34% to halt or 67% to control and I'll just go back to my other slide so what if consensus breaks there are a few different ways in this could happen you could end up so IBC cares about some notion of valid and valid isn't maybe Dora notion of valid but IBC's notion of valid is a chain that can provide like clamp throughs that verify so in different Byzantine scenarios you might get no valid chain you might get invalid chains if the stake splits 50/50 on a proof of stake chain you will get no valid chains so no progress can be made

if you use IVC timeouts on the source chain than any packets were in progress you can recover the assets for but you'll end up with an assets split across two chains right so you'll have some a or C 20 tokens on theorem some factors on C cash right now you just accept that risk it would be possible to influence some kinds of fraud proofs but that does impose pretty complex requirements on the state machines of both chains because they have to verify much more about each other governance on one chain if the chain has government's could apply an irregular state upgrade and credit tokens at parity with balances on the other chain right so if the first proof of stake chain has governance the second one

halts the the first one governance could elect to the tokens back for the holders of the the peg token on the second chain but that's not the ideal case so we're still working on this it's that mystery question other questions no other questions all right then Thanks so you can find this back at that link I'll post the slides my email is cwg OES at tender and calm

and I encourage you to check out the breakout on zero knowledge state transitions 1540 in breakout room two to continue a discussion in this vein thank you