Interblockchain Communication for Eth 2.0

Transcript

you know viola who patina is are you here to fix we're gonna type in

to z1 then I'll just continue he sent me the link [Music] [Music]

we can actually live it soon five six you can put anything because he's in there hello hi there can you hear me can

you see the screen sure I also have AIDS cool well it's a little tricky but I can't see the audience so I'll just assume that there is an audience thanks for coming coming to you from coronavirus proof remote zoom and this is IBC and they're into it Sarah Christus and I work for an entertaining game huh so to start off I'm gonna cover

the agenda for this talk first I'll go over some of the hard problems hopefully a pretty comprehensive list of all the hard problems and cross shard and cross chain communications I think the hard problems did cross shard communications than the hard problems and cross chain communications are mostly the same and I'll go over what those are and how they can be solved by sort of common solutions between these two I see a lot of different protocols I'll give a quick introduction bolts on top of IBC or in cooperation with ABC and I'll talk specifically about what components constitute the IBC protocol and how they work to solve

those problems then I'll give a quick overview of my limited understanding of the state of Cross charter communications planned for these to be to at the moment talk about what problems seem to be receiving a lot of attention what problems haven't yet received some attention and where I think you know it might make sense to be focused a little bit then I'll analyze where obviously could help if - in particular for the task of our communications in dealing with some of those are problems that I'll get to and I'll talk about if I VC burns be integrated into leaf - roadmap what approximately that would require what it would look like how it would compare or need to be integrated with some of the existing solutions which

have been toast and what next steps we need to happen to realize that please I don't know if there's a provision for questions maybe I'll just take questions at the end that's easiest whoo so let's talk about hearted problems and cross charge chain communications you'll notice that I've put cross shard and cross chain here in the same category it's because I think the hard problems are mostly the same the difference between shards and chains is simply difference in authentication in the case of multi chain communications you have changed but heterogeneous consensus algorithms which must authenticate each other and the case of multi across shard and lots of short communications you have chains for the independent

execution but where you have sum up your information about what their consensus may be you know what the validator cells going to be maybe you know exactly what the shards are so the difference is in authentication for the most Dale Earnhardt problems they say what are the heart drops first is transport you need to get data from one shard to another shard or what change one of the chain needs together the right place so you need to get up there you know within some reasonable type bounds the second is authentication you need to ensure that when you're sending data from one change in one charge to another chain is hard it's write data you don't want someone to be able to send the wrong data and accepted by accident that would be some kind of fraud the third is ordering you in order to reason about

behaviors composite behavior applications which exists on local shards removal chains you will need some or potentially many kinds of ordering guarantees provided by the communications mechanism that allow you to reason about what states are possible and what states are impossible the fourth related concern is state dependent / ethnicity so in thinking about you know from the high level as a user or an application developer who's developing an application that exists that has state on multiple search or multiple chains you might need certain state transitions to be dependent on one another or atomic you might need to book a hotel and train at the same time you know either both or right right that's sort of the classic case but there are

also cases that dependency all the other thing is that first or perhaps some complex interoperation between multiple finance contracts things like that the fifth concern is denial of service resistance you want to make sure that whatever your communications mechanism is it can't be easily dust because these are all Punk networks the sense of concern are sort of related fleet you have to think about when the kippah is if the concerns is the topology of your network whether you have a fixed set of say shards where you know all the validators the fury and whether that's changing how that affects what you think about as your are protecting strong

education in particular for your communications protocol how that affects what you think about if you ever have to reroute messages for one place to another because apology changed and relatedly the last hard problem I list here is load balancing this applies in particular discharge systems where you have some kind of uniform contract environment but you want to balance the exit of the compute load or a storage load across different charts as you need to come up with the protocols do not and probably one that is resistant to adversarial actors who wants to for us so as you'll see only really one of these problems authentication and do some with us degree load balancing is a specific to Chardon systems as opposed to

to fix cross chart systems as opposed to cross chain systems the authentication changes but all the other heart problems basically remain the same whether you're dealing with homogeneous or heterogeneous consumers so what's obviously in which of these problems is solved IBC is a messaging protocol for the interchange so it's basically it's solving the same same set of problems more or less as eath phase two as to think about as charted contract system has to have to think about but it's solving them in the context of heterogeneous chains with different consensus algorithms different state machines and anthropology which is not know and would just change a customer so IBC addresses some of these problems and

it purposefully does not addressed others of these problems because we think that they should be addressed a higher layer on top of this base protocol which promise it is does it addressed IBC solves transport getting data for one place to another it's also education ensuring that the data that you're receiving on one chain say one module or contract is in fact the data that was sent by another module or another team it solves ordering ensuring you if you want ordering dependence between packets of data that you're sending around you get it it can handle completely dynamic topologies what you don't know is that a change of chars our Fiori and a can change even when you have messages in flight to be changing all the time and it deals of course with heterogeneous change the consensus algorithms

obviously does not solve at least natively it does not solve denial of service resistance so we have some sort of yeah implementation mechanism on the chains on which running it IBC does not solve state dependence atomicity at the or protocol error instead you have to build that on top or I guess you can rely on the watering properties but then you have to reason about what sort of composite state guarantee to comply to construct your application accordingly or build something like a lock protocol on top of IBC second IBC does not solve load balancing you would do that on top and IBC in particular which may be relevant to its compatibility you do does not currently deal with Forks of

all access issues that verification of consensus charger chains can be performed you know in a five sense that the other sharks retains commit to a final results new project two quick myths that I don't want to bunk IBC is not cosmos Pacific the cosmos hub of blockchain plays no necessary or central role the word hub in the word zone as you might've heard in our media just referred to expected sort of roles in the topology particular teams will play there's no sort of commissioning system you can use IBC without connection and the second myth is that IBC is not just about Torah transfers in fact the core obviously protocol obviously ta o is not a bunch of assurances that all is constructive

in the payload agnostic fashion which I will get to right now so the first part of the IBC that we call jokingly the Tao of IBC for transport authentication and ordering what does this consist of IV C is written as a layered protocol stock you can think of this is pretty similar or analogous to the OSI model and not just VIP where different layers sit one on top of each other it just provides an interface the next layer each provides a head of security guarantees and the layers themselves could be instantiated in different ways so just as different layers of the tcp/ip protocol can be instantiated sometimes an Hardware sometimes and stuff whereby physical and virtual devices and they just have to remain protocol compliant as long as the

devices remain protocol complain could build you know HTTP websites etc further protocols on top of it even though the implementations of the primitives very IBC works exactly like us there are a set of communities that are abstractions which have certain properties in which you can use to which you can combine together to get the high level messaging application transport ordering properties you want but then those primitives can be instantiated in different places so the key primitives in the talib IBC our clients connections channels packets and modules clients serve to allow you to verify consensus transcripts so in the case of a multi-chain system clients will allow you to check as basically a light client lights will allow you to check that it's

a software or another to be committed to a particular state which you can use them to verify the contents of that state such as how many messages and the case of the charted system clients would essentially be proxies you might be using the let's call different things that polka done it's called to relay chain in the theory 2.0 that's called the beacon to you but you might be using a central chain as a proxy to verify the stage on other sites but it works basically the same way connections serve to associate to change the two shards allow them to refer to each other in a way the defense command in the middle attacks and these for forgery channels services data fight between two modules so obviously uses these sort of agnostic term modules a module is just an independent unit of

code execution it could be a smart contract it could be a module in a state machine framework such as the cosmos SDK or substrate but critically modules are isolated from each other and they may not trust each other so IVC allows modules to create a secure data channels to other modules just as you might be writing in a theory in contract to not want to worry about what the other contracts that we theory of change were correct or not to the released about to practice your contract you don't want to worry about whether the other contracts and some other team apart from the ones you specifically want to talk to are correct and IBC lets you do that packets are aware of course all the actual actions app so all of these lower abstractions are payload agnostic they don't specify what actual data is being

sent around or what it means they don't specify the semantics of it that's all contained in the data packet and the data packet can be routed between these modules only the endpoints only the modules at the end of the channel at each other the channel need to understand how to interpret that data how to create packets how to parse packets and treat them accordingly then the final element here would support something touching upon is we layers three layers and IBC are simply off chain processes that are was responsible for physically transporting data from one place to another so this can coincide with validators validators who are running these networks obviously running their swords willing to change the back system status that can service be layers but it doesn't necessarily need to coincide so we separate it as a

role so is a quick physical layout of what this all looks like step by step you start out on module a on the left number one module a sends an IBC packet that gets routed through the IBC module running on chain a and gets committed to in the consensus algorithm chain a or say included if this were a charred and septic chain it would be included in the next block of the shard then I really mayor picks it up sends it over to chain B or short B it gets routed to the appropriate module module B and module B can handle a bit as necessary and logically succeeds modulae might send back an acknowledgement of success or if it fails it might send back a notice of failure with the appropriate error codes

of the module a can take action to revert state changes or whatever and then there can be ordering guarantees imposed on top of this if you want order between packets such the first path you know the packets will be received in the order in which you sent or if you don't care about the order or if you want some more complicated directive a directed acyclic graph all of these things are possible so on top of the core protocols of the application layer packet semantics application layer packet semantics and IBC are a lot like ER c or e IP standards in the theory and which talk about specific kinds of cross contract calls except in the case of IBC we're talking about calls between different modules essentially on different chains written even in different languages whether they could

be smart contracts but the basic idea the basic concept doesn't say each packet contains some serialized data that serialize data has particular format and then format can be interpreted in appropriate fashion by the sending and receiving ends to do something you might use packets to send oh and transfers you might use packets to delegate control of an account on one chain or a smart contract on one charge to another chain or another contract for another shard you might use packets it's something similar to a contract taking one of the two proposals we'll talk about the second to do interchange code relocation where you transport contracts between state machines compatible VMs or execution environments so let's talk about briefly then what the current

state of cross charge communications is in eath - based on my sort of survey of the research landscape so far there's been a lot of reasoning about atomicity the train and tell problem or the composable TFI problem there are proposals for supersedes contract yanking moving contracts around to get atomicity merge blocks where you sort of requirements on this chart consensus in order to have combined blocks every so often where you can execute atomic transactions optimistic state roads optimistic concurrency read/write basically mutual exclusion lock sets which is something similar in terms and multi-version concurrency control or started Byzantine atomic print which is a protocol specifically for Fault on our

clock there has been as far as I could tell not too much reasoning so far about dynamic topologies I actually don't know what the exact number of shards currently proposed for ec2 is but it seems to be a fixed fixed number maybe one that would change later but not one another change day to day the distance seem to be too much reasoning yet about how to deal with specialized execution environments that might not support the same sort of contract VMs and there doesn't seem to be too much reasoning yet about application specific concurrency techniques of course sometimes you really just deluxe but locks are quite expensive in a cross state context or cross sorry contacts they require large transactions you reason about das concerns etc so I think that some proaches from the academic

literature like conflict resolved opal datatypes dirty keys or less variables which uses sort of a space concurrency technique since they require don't require locking or require more limited locking might be applicable here so if I BC were to be integrated into the two specification process where would it is effect obviously is a critical layer that would sit between shards in the beacon chain and contracts or higher level of current protocols so the sort of application layer of IBC is basically equivalent across the state contract calls in e2 and the Tao of IBC the transporter quantification and ordering layer that's between those cross chain contract calls and sort of the or

stations obviously it's compatible with most of these existing proposals if it were to be fitted sequential receipts basically the same thing is ordered I beseech and also you already have that built in the protocol contract a king would sit on top of IBC is enough patient layer protocol merge blocks are not yet possible because they actually in effect so the consensus rules the shards and IBC is not written that way although we must pool to alter edge to work that way optimistic secrets optimistic concurrency kind of depends on the mechanism but some form that should be possible feedback right mutual exclusion locks are possible over I received an application layer protocol in charge of Byzantine and Roman commit as possible on top of IDC it's even thought possible across heterogeneous chains it's kind of like running a B of T algorithm on top

of B of T James in a sort of fractal sense so if we were to integrate IBC into the eve to map what would this look like and what are the pros cons and next steps pros of integrating imec whether you call it IBC or not is not the most important question it's more about whether you construct this kind of layer layered protocol stack and whether it's instead of you know one one way the ease to spec process could go for phase two is that there's sort of one cathedral concurrency solution that's built into the core protocol and everything kind of has to use it and maybe Nessun fancy

features like merge applause that's one approach to it has some advantages IBC is not that approach IBC is a much more layered approach so if you were to interpret IBC it'll be more like you build these layers and they support more and more advanced sorts of currency or atomicity primitives and reasoning and then depending on what your application needs you can interface with the crossing communications facilities provided by if two at a different layer you might just need a synchronous message something you might need some sort of worrying you might need something more complex to get out to receive those requirements were really very based in the application so I think there's something to be said for allowing applications to interface with your assistant apps different models so IBC provides in that sense quite a few

advantages but it's a clear set of abstractions it separates concerns because of the way IBC is written it's very easy to deal with topology changes because I see doesn't make any assumptions about topology in the first place so the number of shards changes even dynamically I see Angela it's easier to reason about directly in applications developers who are familiar with channels or other concurrency primitives that go airline or something will be familiar with the interfaces with jxe exposes it's easy to fall level protocols like sharding business he'd commit on top of IBC and it would also provide a natural unified interface to non eath 2.0 chains for contracts of the contracts kind of handled talking to other contracts on ease - and talking to

other modules on other chains in the same fashion maybe another chain in this case could even be one way ex-cons IBC would require ulceration as it stands to handle some of these concurrency cross chain rashard mechanisms that require alternate census rules and look at the moment IBC doesn't do that and it would also require illustration to handle roll back screen on tonality at the moment of disability both of these alterations are possible but they would be substantial so we weren't figuring out exactly what that would mean and if - really wants to integrate those into its mechanism or not finally what would be the next steps so far I think of

course most of us are operating in silos here I mean specification IEC and alongside lot of other fantastic contributors and notably our electrical systems all its interchange am aha and I know there are lots of fantastic scientists and researchers working on new specs if we were to try to integrate things in this fashion I think it requires an intensive discussion of collaboration perhaps on the e3 search forums you know I think words were pretty flexible with between the IBC team and the e 2.0 spec team to figure out where IVC would fit one of hearts were fit what parts we need to be changed and if it all makes sense so if that sound to be interesting and if you

want to learn more get in touch or talk about what we would need to do to actually integrate IBC into the youth - a map you can find the current specification which is basically finalized at least the version that we'll be deploying on cosmos at github comm / cosmos / ICS and you can find me on twitter twitter.com slash DWG oh yes thank you [Applause] thank you and unfortunately we don't have time for questions oh I was not speaking you know unfortunately we do not have time for Q&A but you have is Twitter's and thanks for being here with us and zoom and please reach out to him if you have any question and thank for

your work on our ATM - thanks everyone