LayerZero - Bryan Pellegrino
Ethereum Denver·Sun, Oct 9, 2022, 12:00 AM
Transcript
hey everybody [Music] brian pellegrino from layer zero uh they didn't really give me a topic to talk about today so i don't have slides or anything else and i thought rather than giving like a generalized pitch which i've done a thousand times and you guys can just find online i would rather spend time talking about what i think are kind of the biggest issues of people building when they're building anything cross-chain and multi-change if you guys don't know what layer zero is uh omnichain interoperability protocol so just working on seamless cross chain um i guess just to judge the audience can i just see a quick show of hands of people who are actually building something as in like deployed a smart contract partner project etc all right like 20 you know 15 20 something like that which seems fair um okay so i think a couple of things uh some obvious some not so obvious um the first thing that i think is pretty obvious is when people are building right now like almost any cross chain solution looks something like this you have these two chains that are atomic and state they don't know anything about the rest of the world they only know everything about themselves they need to communicate kind of like the broad solution is somebody's going to throw their own chain or consensus mechanism that sits in the middle you'll write a transaction from the source over here this thing in the middle will somehow come to consensus as the validity of that transaction and then it will write a transaction out uh obvious issue with that is if that consensus mechanism that lives in the middle breaks it typically has the ability to just arbitrarily write messages to every application on every chain so you have this entire entire pool of systemic risk you saw this with poly network hack and a bunch of the other hacks where uh the hacker basically made himself the only validator in the network was able to tell all the applications living on the destination chain like hey i definitely put 680 million dollars over there like give me 608 million dollars over there and it has this really kind of broken incentive structure where maybe this structure in the middle uh you know maybe it secures like five billion dollars but then uniswap pops in and now it you know secures 20 billion dollars and then ave opts in and out secures 50 billion dollars and every new participant opting into that system is making it significantly less secure for every other participant in the system unless the bond of that one system is growing like non-linearly relative to what's being added which has just never been the case so i think one is is that structure and that everything lives in one central system of risk and i think the other thing that i personally think is not thought enough about right now is the fact that everybody in every system right now subscribes to the same set of hyper parameters so an example of this is take two very different use cases so the first use case is like you're gonna verify on chain b that you own like a copper sword and a game on chain a it's like you know not something that maybe needs that high of security and use case number two is you're gonna transfer 500 million dollars across chain on chain like these are just very two broadly different uh actions that are being done here and yet they both need to opt in to the exact same set of security properties so this can be whether they bypass an optimistic roll-up or don't bypass an optimistic roll-up this can be whether you're going to wait five blocks 35 blocks or 100 blocks when coming from a source chain against reorg a bunch of different things that go into this but i think it matters what the application is doing and i think it's really important that in time all of those decisions move up the stack and live at the application layer i don't think it's going to make sense long term for every application again to just be like for the construct that sits in the middle to set the hyper parameters and everybody opt-in or not to that i think that's typically going to cause huge fragmentation in terms of what types of applications can subscribe to these different systems uh and it forces people to kind of shy to one side or the other they need to do something that's that's more secure than what they need or something that's much more worse less secure than what they need but it's like the only viable solution um and so you know i think when the way we're framing these problems and the way that we think about these things is really a way to again take that decision making away from actually the protocol layer and move it up to the application layer and make something that's more modular whether this is a consensus mechanism that uses more nodes less nodes whether this is uh you know right now we have a huge number of basically consensus mechanisms that do this uh some are fraud proof systems some are uh sets of validators some are subsets of validators within solana or tendermint or whatever that might be and again each of these may be appropriate for single applications or a couple like small groups of applications but not necessarily appropriate for everything so i think modularity of choice is something that's hugely important and not at all being discussed right now and again i'm happy to sort of dive in later i i didn't want to spend the time just kind of chilling what we're doing but more talking about the space more broadly i'm happy to talk about like how we are addressing that or how we're thinking about that but i think it's important to frame the problems differently and to frame the way that applications uh or contracts are starting to interact with these things um the other thing more which has definitely changed since but prior to us kind of talking about our initial approach i think everybody was strictly focused on value transfer like any bridge that you looked at any communication system you looked at with the exception of maybe ibc was strictly value transfer and i think we really moved that more towards like hey value transfer is just a subset of generic messaging like why do we care about value transfer as a thing like make a system that's good for all generic messaging systems and that can be whether this is uh unified governance across a bunch of chains and casting votes whether this is um the process of just like state synchronization or running a cron or sharing state or synchronizing state across a bunch of apps across a bunch of chains there's a bunch of things that are not strictly value transfer and i think broadly the space has moved in that direction where a lot more people think are thinking about messaging a lot more people are thinking about uh generic primitives as opposed to just this one thing of value transfer um but yeah i i think in general those are the three things that i think about that are different than the way that most people are thinking about it right now so um i can kind of go into anything from there i prefer a q a style question i like i always mention on any panel i ask the moderator to be as controversial as possible so i very much value adversarial lines of reasoning if anybody has questions or wants to start talking about this i'd like to field anything and then we can go from there and i'll talk about it michael [Music] yeah so the question is uh chains like chia have extremely complicated block headers like how do you basically deal with interactions between chains or maybe have different block constructs uh i think there's a couple different ways so the question really comes down to like what does a validation mechanism look like are you actually taking this header from chia and needing to validate it like in solidity on the evm like that's one totally different thing where like you need to actually uh take and do this validation or proofing mechanism that's a bunch of things where this is figuring out how to do a proof slice of proof of history and validate on the evm or whether this is figuring out how to just like take an mpt and walk it on another chain um but then there's obviously like you can pair that down and you could be passing potentially like payloads directly it really depends on what the validation mechanism looks like in the middle uh and i think that itself is one of the more interesting questions and like okay getting communication is fine like once you're just passing this payload but how does val like the whole problem is how does validation happen and people are addressing this with uh with zk like there's a huge field of research and how that is uh so i don't think it necessarily has to matter right you could have so you have this problem of um non-linear growth where like let's say you are validating an mpt directly on another chain and you're validating like us a lot of proof of history on ethereum or on an evm system and then you go to tendermint and then you're substrate and then you get a chia and you've got all these other systems and like on every new proofing mechanism that gets introduced you have to uh grow that to every other chain so there's like a prospect of potentially taking uh like locally basically doing the translation there and like basically having like a universal proofing mechanism but i even think that is like way too complex and probably not needed it's more just being able to validate the payload itself uh and again it's it's just this coordination problem so i i don't think there's a clear answer to it yet but i do think it's a very interesting question anybody else if somebody has one if not i'll just go back to talking about general stuff all right um if somebody has one just like flag me down and talk about it um so okay i'll talk a little bit about what we do um so again i kind of just grab broad systems or like this middle chain system chain here chain here people are going to throw their own consensus mechanism in the middle and that controls everything that's like the entire validation and if that breaks everything breaks so it's your classic hub and spoke model where if the consensus mechanism of the hub is broken like all these folks are totally wrecked um which is obviously a concern right uh you're you know it's fine now if you're securing a couple hundred million dollars but when you're talking hundreds of billions of dollars uh it needs to be thought through a lot more uh then you have cosmos ibc which is like the total opposite where you're gonna take the complete block history of one chain you're gonna take every one of its block headers and write them sequentially uh to the other chain and vice versa so you're just going to maintain a on-chain like client of each opposing chain directly and then when you have that and assuming uh you know nobody has like misproven any of the blocks that are being stacked in these block headers then you can just like arbitrarily validate a transaction and do the validation directly on chain which is like amazing and you would definitely want to do if rights were free but like rights are incredibly expensive on blockchain so you know like 50 to 100 million dollars per day per chain you tied pairwise to ethereum in that manner um so it's just not really a viable solution in the current state um so the approach that we took was a couple different things one was reinvented this thing called an ultra light node which is effectively the process of rather than taking and validating every single block even if you only care about like two of them you stream blocks on demand and do ad hoc validation you still have this problem of you have these two chains and they don't know anything about each other and they can't know anything about each other so you still need to like pass that state from one chain to another uh system like ibc do this with sets of validators submitting block headers uh we basically break this up into two parties uh we call them oracles and relayers but it's a little bit of a misnomer and oracle is any system that takes a block header and submits to the destination chain and a relayer is any system that takes a transaction proof and submits to the destination chain and those can look like anything right so you have bridges today that are like single sgx servers you have bridges today that are like very small sets of validators uh you have bridges today who do a ton of different things uh and so this could look as simple as uh individual servers where like an application wants to own that themselves or as complex as like the complete set of solana validators acting as the oracle on one side and the complete set of tendermint validators acting as the relayer on the other side so those can be as distributed as you want or need them to be but i think the most important thing of an architecture that shifts in that direction is that choice lives at the application layer so each application opts in to exactly what oracle they want and exactly what relay they want and while that may not seem that important early on what it means is that if an application runs their own relayer even if 100 of the other participants in the network are completely malicious there is nothing that anybody can do to affect the security of that application unless it's colluding with the person passing the block headers or the oracle in this case against themselves so they're colluding with them against themselves that's the only way that they will ever have uh any ability to basically affect their own messaging and so i think giving that choice at the application layer what it does is like it gives you the ability to either externalize or internalize this risk from most applications building like they just don't care they're very content to have chain link as their oracle and coinbase as their relay and like that's a valid option for them they're like okay i can accept the choice that you know both chain link and coinbase are not going to be malicious at the same time and colluding and you know acting against me and like i'm willing to price that risk at x and i'm willing to sort of externalize that but then your ave or whoever some huge application coming up with tons of liquidity then maybe that's not an acceptable outcome right and so then maybe uh applications who do care they have the ability to just run one piece of this construct and have complete control over their own security and what it does is that it creates all of this risk where before we have this kind of central pool of systemic risk that consensus mechanism breaks everything's gone and now you have very narrow shards of application specific risks so um you know you have some big oracle and they somehow go rogue and they're in collusion with relayer a well only applications accepting messages from exactly that oracle and real layer a get affected at all this very narrow band of risks so anybody using relay is b through z anybody relaying their own transactions anybody using any other oracle completely unaffected uh so you've also at the same time whereas before let's say an oracle controlled everything if that oracle breaks everything's gone if this methodology basically makes it so the cost of attack on that oracle goes up you know instead of winning everything the cost to attack it still remains the same but the payoff is drastically reduced so rather than winning everything you're now winning 130th or 1 300th of total system risk so it increases uh the cost of the attack effect the effective cost of the attack on an oracle exponentially is just like an extremely attractive property to have when you're talking about these sort of validation systems it makes it so that this bonding mechanism or whatever mechanism your you know oracle structure we're talking about now uses uh is much much much more capital efficient when risk is sharded heavily as opposed to centralized um okay they told me i was like super up against the time so how are we doing for time five more minutes um on that i will ask if there are any questions and again adversarial lines of reasoning very welcome none all right um okay so yeah i mean i think i i think that's one thing that is super interesting and again i think you will see a very very strong move away from these sort of like central pools of systemic risk because we've seen time and time and time again whether it's the billions of dollars in hacks or whether uh you know it's the fact that none of these systems have more value bonded than they're securing uh that it's just like not a reasonable way to approach the problem and it's too capital inefficient to do so that way um so i think you will definitely see things move in that direction i think you will see application choice uh move up the stack heavily uh again where each application like rather than having i don't know bridge a you know you have this grid and like bridge a lives here on the trade off of like cost and security and like bridge b lives here and bridge c lives here like you're going to have this pareto frontier where you can effectively like assign your own properties in each application like they're obviously priced accordingly right and you're just paying you're paying for some measure some measure of risk and the way that like the ethereum network is very willing to pay for high security uh in other chains are like well whether willing or not they're paying less for that security right and so you give application the choice of like what does this cost what is the operation that you're trying to accomplish and what are you willing to pay for that risk and like what is the the downside risk of that and so i think again moving choice to the application layer is going to play a huge role in defining a system that's modular enough to stand the test of time um and again i i think the highest order goal at least the highest order goal for us at lara zero is like connect every contract on every chain it's like that's purely what we're trying to do is just seamless messaging between these but there's a lot of nuance and like what does that actually look like um because it's it's easy to say like oh you'll have the seamless messaging and that's great but there's a lot of properties that go into that and sort of like that each application either manages or adopts and oftentimes they don't know what they're adopting and oftentimes they're forced to adopt things that they don't want to so creating a system that puts control of application layer i think is uh is one of our highest order goals um all right i don't think i have time to run through a full rant on anything else so i will stop there for the moment
Automatic transcript — names and jargon may be misspelled.