Privacy in Cosmos Live: Carlos Rodríguez Vega (Interchain) - IBC from Hero to Zero Knowledge

Transcript

hello yeah thanks so yeah hello everyone my name is carlos i'm the ivs engineering manager at interchain gmbh and today i'm going to be talking about one of the most important but sometimes difficult to understand core building blocks of ibc which is the the light clients yeah i'm gonna talk about what what they what they are why they are one of the different differentiated factors of ibc i will talk a bit also about the division for ibc and what part zero knowledge proofs could play in that in the future so okay so probably everybody is familiar with

ibc but for those that not that are not yeah just very briefly ibc stands for inter blockchain communication proto interpol interproxim communication is a protocol that allows sovereign independent chains to communicate with each other so yeah this picture at a very high level shows the main actors involved engaged in inter blockchain communication we have the nodes participating in two chains chain a and c and b and we have some off of chain processes called relayers that are able to submit transactions on each

chain um ibc relies very heavily on online clients to guarantee the correctness and the security of the protocol and this is one of the differentiating very distinctive factors of ibc compared with other comparing with other bridging bridge or interoperability solutions in general a light client is a client that connects to a full node requests new headers is able to verify by checking hashes and signatures that those headers are are trusted and are regenerated by the underlying blockchain and in the context of ibc chains run a light client of the

counterparty chain with which they communicate so in this case chain a runs a light client for chain b and chain b runs a light line for chain a the light client on on each chain tracks the consensus state of the counterparty and it knows how to verify proofs against that consensus state so for example if we talk about a very concrete example uh of the token transfers um for example if i want to send tokens from chain a to chain b um there would be a transaction in chain a that stores in a state a commitment

for sending those tokens that commitment a proof of that commitment together with a block header is relayed by the relayer to chain b and there the client the light client for chain a can verify that that commitment for sending tokens is actually stored and the tokens can be received and yeah this is the reason why we say that the design of ibc is trustless because there's no need to trust any other party except the two the two chains that are involved in the communication we don't even need to trust on the relayers we only need them for liveness we need them to submit

messages to update the light clients to transfer data packets from one change to another but we don't need to place any extra trust on them for the security of the protocol yeah um yeah now we compare with bridges another interoperability solutions uh one of the other solutions yeah there is an extra truss ledger we need to to trust the the bridge validator set and yeah what happens if you cannot trust the validator set of the bridge um yeah we have seen in the in the last months is several high-profile hacks like the wormhole wormhole attack

um yeah where the attacker was able to um to submit transactions with valid signatures from the validators of the bridge um yeah withdrawing basically the wrapped heath on solana and then exchanging it for east in ethereum this was actually the the main problem was that there was a smart contract exploit to do to be fair but but recently we also had the running hack where the attacker yeah running is an ethereum side chain but it was one that was very centralized so there were only nine validators and the the the attacker managed to take

control of the private keys of five of those validators to fake force withdrawals of the funds in the bridge so yeah as more and more value flows through cross-chain bridges this become a more attractive target for for the hackers so yeah cross-chain bridges and protocols are critical infrastructure and any attack any successful attack has cascading effects at the moment yeah the three largest by dollar volume hacks are our attacks on on bridges

so that's why yeah it's it's a critical infrastructure at the moment and yeah deserves special attention so if we talk about about the vision for ibc uh yeah ibc launched last year with one application with the fungible token transfers we released the interchange accounts recently and it went live live on the app this week we're going to release religious synthesization very soon and we have in the pipeline some very exciting features uh yeah some teams in the ibc community are working on ibcq queries which will allow a change to query to query the state of their counterparties

uh also also teams are working on nft transfers we also have in the pipeline features to make ibc more sustainable and scalable like connection and channel upgradability this will allow chains to take advantage of new features without having to create new connections and channels and we also have a multihub routing this is a this is a feature that will allow to send data packets from a source chain to a destination but hoping through an inter intermediate intermediate chains and yeah at the moment yeah the cosmos ecosystem consists of

more than 40 zones all of those interconnected with ibc these chains are built with the cosmos sdk they are using the tendermint consensus algorithm but the vision of ibc is to yeah make it a universal standard protocol for inter blockchain communication so we want to expand beyond the cosmos we want ibc to be used in in in other ecosystems and yeah for that reason we also need light clients for the consensus algorithms of those other blockchain ecosystems and yeah there are efforts going on uh on that front so

for example there is a work being done on a beefy lite client in go so this this would be the the light client that cosmos sdk chains can run to verify a state of uh chains built on substrate there's also work being done to develop ibc and a tender main light client in rust so substrate chains can run the tender main light client and verify the the state of cosmos sdk chains for evm compatible um chains that run the ib ib ft 2.0 consensual algorithm there's also a work going on to implement ibc and the ib ft lite

client in solidity this ibc this implementation of ibc solidity is also being used for a tender mean light client for the cello evm and there's also an implementation of the cello light client that is targeted to to run as a wasm binary in cosmos cosmos chains and beyond this there's also there would be also in the future work to implement light clients in other blockchain ecosystems like near or algorand and yeah another potential area of research that is it will eventually probably come to our roadmap

is the use of zero knowledge proofs um yeah we have we we consider at the moment like two use cases uh one of them is related to computation optimization or compression um yeah there are two places where this can be applied one of them is when updating like clients this is one of the most expensive operations because we need to verify the signatures of the validators that have signed the block header that is going to be used to update the lite client and also when verifying the straight transitions of a chain

there needs to be america proof computation to compute the a root hash and as a state trade state state trees becomes more larger the computation becomes more expensive so one post possible optimization there is to wrap or convert the miracle proof into a secret snark that is is verifiable in constant time independently of how large the state tree grows this imposes extra complexity on the approver to to create to generate the secret snark but the verification becomes cheaper for the for the verifier and the second

area of use is obviously a privacy so as more chains or zones are joining um that have a shielded features then it would make also sense to be able to send or receive packets in a private way so basically to have shielded transactions over ibc and yeah i would like to thanks also the folks at sicas socrates and noma for the time that they spent with us discussing these ideas and sharing their ideas on this topic and that's the end of the presentation so if you have any questions i will be happy to answer [Applause]

[Music] all right um i want to apologize i actually missed the beginning of your presentation but with what you just shared what's the road map or timeline for this for the serial knowledge yeah yeah um this is difficult to say it's really a very early stage kind of research idea we have other things still in the pipeline like upgradability multi-hop routing other features but this is something yeah that can come at

some point at the moment we don't see bottlenecks on on for example updating clients or computation of medical proofs but as the usage of ibc exponentially grows hopefully these are areas that could be affected performance-wise and then zero knowledge proofs could offer some some solution there and the first one the sort of light client is that using that kind of compression technique is that the idea there that you would make it like a smaller client yeah that's the idea yeah cool is it influenced by plumo is it influenced by plumo the cello like client at all uh or that no okay well i'll tell you about it okay

cool any other questions all right thanks thank you