Is Shared Security A Myth? With Toghrul Maharramov

Transcript

welcome back to aan layer unlock virtual event today we have togu from stroll welcome to igen lay unlocked an interactive educational Journey Through the igen layer ecosystem created by technical Founders and builders for the entire crypto Community a special thank you to our partners all Lair polymer authentic skate and lrange for helping to make this happen our goal is to raise raise the collective knowledge of the Igan lir ABS ecosystem and unpack the technical designs of the top teams in space welcome to Igan layer unlocked welcome back to Ian layer unlocked virtual event today we have

togr from scroll following a fun presentation from modular March several months back uh about modularity being a meme today he's filling the role of the myth of shared security so glad to have you back man uh I know Robbie's wishing he was here he's on a flight but uh that's all good and looking forward to this thanks for having me yeah today I decided to follow up on what we T talk discussed last time and to talk about the myth of shared security or I think another way to title it is why uh the lack of shared security is actually good so l2's reaking protocol

trustless and quotation marks Bridges what do they have in common they all have rely on shared security or to be more precise shared Security in quotation marks so before I proceed let's first Define what shared security is so shared Security in the most layman terms is when a protocol a and protocol b share security if an only if the failure of the latter always results in the failure of the former and vice versa so they're completely interdependent we can formalize it but but first in this case fail doesn't

mean a project not being successful so a not successful project can still be in terms of like user base Etc can still fail in terms of it security so that's what we're talking about here it has nothing to do with the success of the project uh so let's say we have a function failure that defines an arbitrary failure of the protocol and then it can basically cause a failure of protocol a and so shared security is when a failure of protocol a causes the failure of protocol B so it's equivalent and so for example in in a scenario where you have

shared security every time an L2 fails the underlying L1 also fails every time a reaking protocol fails the underlying L1 also fails every time time a trustless bridge fails the underlying the underlying L1 also fails but before we proceed I just wanted to like highlight one thing trustless Bridges actually do not exist it's another me myth I'm not going to go into it because it's unrelated to the discussion today but just as a side note when whenever somebody says that there's a trustless Bri just ignore them they're probably just like yeah I mean there's yeah that word is um is blasphemy in in crypto and in

blockchain um but I think that so so real quick on your definition of shared security basically it's two two parts so protocol a and protocol b share security if and only if the failure of the latter always resorts results in the failure of the former and vice versa and so um applying this to like reaking basically we have uh ethereum um validators that are that are engaging in proof of stake and then we restake this this ethereum to then extend this this security to in Ian layers case avss and kind of other uh other services that use uh this this restak eth um but but those those

Services aren't exactly inheriting the security of the under Ling base eth it's it's this restak eth that they're underlying and so like like how do you how do you put how do you put this definition of shared security uh more into the context of uh the relationship between ethereum validators and the restake eth uh that is being used to extend the security of those validators there's no shared security I'll I'll expand on it later there's actually no shared security here uh you can argue that there's some form of shared security from the perspective of slashing if you have deterministic slashing that you can say that ethereum enforces slashing conditions for the

avss but that's only the case if there is determination stick slashing but even then I wouldn't call it shared security it's shared accountability almost like like ethereum enforces the guarantees that it'll enforce slashing conditions in case any occur okay so for the rest of this of this conversation we are OB the understanding that from your perspective shared security is again protocol a and protocol b share security if and only if the failure of the latter always results in the failure of the former and vice versa so basically if one goes down the other goes down regardless because they're sharing the same Economic Security or they're sharing some

security model that requires them to be both uh you know running if you will yeah they're completely independ interdependent so one thing also is should fail with no exceptions got it all right so I lost where I was oh yeah I was here so yeah do not exist whatever it's just a side note uh doesn't isn't really related to to the this discussion but yeah uh so do those claims actually hold in real world does is it true that every time an L2 fails the underlying L1 also fails luckily we didn't really have haven't

really historically had any major L2 failures but there were liveness failures etc etc like certain censorship Etc and basically luckily no and you might ask why luckily that that that sounds like a bad thing but actually I don't think it is and the reason why I think luckily is a good is is is a good reason is like yes simple answer is yes luckily but but a more complex answer would be not having full shared security enables us to deploy um hundreds of different uh instances are well to use with different

experimental properties different reaking protocols etc etc without risking basically failing everything that is related to it because think of it this way if if there are I think there are around 80 l2s currently deployed on ethereum if shared security was true then every time a single L2 failed the L1 would have failed and because it shares the security with other l2s those l2s would have failed as well which means that you have a cascading effect where every time there's a failure of a single L1 L2 everything fails which is not a good design and so yeah as as I just described imagine if failure of a single L2 caus the cascading failure of

all the other l2s reaking protocols and the base layer it's not a good design and so I think from this perspective no having shared security is a good thing because you you can ensure that certain properties are inherited and I'll cover that later but you also ensure that the the the failur are isolated so one fails nothing else fails of course you can argue that like in case of I lir and restake eth if if a big portion of eth is slashed then it'll have an impact of ethereum but it will not cause ethereum to fail it'll cause the security the economic security properties to drop etc

etc but it will not result in the failure of ethereum and uh the the correct question would be does that mean that share security is a scam well it's not that simple the the the simple answer is no and the reason why that's the case is because protocol can share partial security or partial Economic Security theoretically protocols can also share full security let's say in case where all the e that are St in ethereum are also restak then it it it will be sharing full security I will be sharing full security with ethereum but realistically it's unlikely to be the

case after the 100% of St e is also re into I layers so in most cases it'll be partial Economic Security and so as an example a stage two rollup deployed on ethereum shares the following guarantees with ethereum which means that it shares the for the following security with ethereum so one is data availability which is basically the your ability to download the relevant data to reconstruct the state within a given amount of time so let's say the ethereum makes the data available and it guarantees that if you want to download it within let's say a week or two weeks you'll always be able to after that if you're talking about

historic data the protocol itself doesn't guarantee it but because you have so many services built on top of it such as um block explorers rpc's Etc especially for big projects like ethereum it's unlikely that you're ever going to have a case where you are unable to retrieve the data from somewhere else historic data second is ordering which is a side effect of data availability which means that once the the the the set of transactions is ordered in a certain way so for example transaction one comes after transaction two sorry transaction two comes after transaction one Etc then it'll always stay the same as long as the as ethereum

functions properly so it will always guarantees once the ordering is finalized that the ordering will stay the same and third property is eventual sensor ship resistance that's done for forced inclusion which means that basically in case the L2 is sensoring you can always force it the transactions the transaction that D2 is censoring its inclusion through d one and finally ethereum enforces attestations to correct this for a rollup which is different from correctness guarantees because ethereum cannot guarantee that the rollup is correct it can just guarantee that the the state transition that it tested to

is correct based on the fact that the fra proof or the zero knowledge proof that is used by set rollup is functioning correctly so if it's not functioning correctly ethereum can do nothing about it and the funds can be stolen Etc and then let's go to reaking particles as yeah just just briefly to um uh on those on those four components of the stage to rer I I put out this tweet the day I'm still trying to really wrap my head around how this works um and the Tweet was basically like that data the data availability uh part of the blockchain whether it be using ethereum or using uh you know Ian da or Celestia or something else is um I is more important to the quote unquote

finality of the chain than than the ethereum based Slayer itself in the sense that like uh being the being able to reconstruct the blocks uh of the state in a given period of time is the most important part of a rollups kind of ability to uh do a hard fork or kind of uh attest to its validity and then kind of the ethereum L1 is just there to confirm the validity of of the data uh um that that has been posted and then basically you know publish the block and run the state transition function so like that's like a a a mental model that I'm like working with and I'm still trying to kind of really fully finalize

how are you thinking about this I the idea between uh where where in a stage two rollup where ethereum uh L1 enforces these attestations to correctness and then runs the data availability uh like both of those within a stage two R how how does which in that relation reltionship which is the more important quote unquote uh part of that puzzle to the rollups finality and security uh and kind of why so in terms of finality I would say it's ethereum because ethereum is responsible for the ordering so let's say if the da layer I don't know it doesn't matter let's say you use celesti

as a DA layer it declares that a certain ordering is the chronical one but ethereum rejects it because there's a certain Force transaction That was supposed to be included beforehand then ethereum basically rejects that ordering and so ethereum is the final instance in terms of determining what ordering is correct and therefore which data you should source of course in terms of sourcing the data then the da layer is more important because even if ethereum says that a certain thing is correct but you're unable to recover that data then it doesn't matter what etherum says so there are two different things here in terms of who has the final say it's always ethereum in terms of who plays a

more more most important role for actually making that data available to you for you to retrieve it then it's the da layer of course yeah and when you say forced Transaction what exactly do you mean by a forced transaction that would cause some sort of uh invalid State transition so an example so so usually and I'll use arbitrum terminology but that's not the way arbitrum works but an example of a design for example let's say uh usually rollups have two inboxes the sequencer inbox which is the L2 transactions that are ordered and published and then the

second inbox is called the delayed inbox it's the inbox of the L1 to L2 messages so let's say if you deposit the L1 uh eth on an L1 the Contra to the L2 contract it takes some time to be processed and actually be deposited on your L2 Contra into your LT wallet and that can be used for forc inclusion as well so in terms of the design the the bridge is usually agnostic whether it's an L1 to an L2 message or a forced inclusion it treats them the same way and usually how it works there's a delay so it sets a timer let's say I don't know 24 hours until when that transaction has to be processed and if

the transaction is not processed by the L2 within that time frame then the L1 can force the the inclusion of that transaction into the L2 and so the way you can design it so there are a few different designs for example in arbitrum after that delay expires anyone can call the bridge and basically move that transaction from the delayed inbox into the sequencer inbox making it canonical but you can also design it in a way where it's more automated so let's say if the sequencer publishes uh an ordering but it doesn't include the first transaction into the

queue after the delay expired then the bridge will just reject that ordering because it it it will always give priority to that transaction that is that has an expired delay on it and therefore in this design the ethereum always so the bridge always has the last say of what the ordering is and therefore what the finalized ordering is and as a result you can derive the finalized State Etc ET referment and therefore that's why I was saying that ethereum always plays the bigger role in terms of determining the finality if that makes sense yeah yeah it it does and I I now I understand deeper that the forc

inclusion concept and why why those Force transactions are are important so just kind of like broadly for for ethereum uh for stage two rule up today based on our current definition that we have established uh about shared security uh you know these these four properties that you spoke on are are the key uh four things that exist in a stage two rollup that would you know if if any of these happened um then then uh or if if any failure of any of these properties happened at either level um it it would cause the other to fail um but like I don't know if it's a silly question but if if the rollup stopped uh posting data to ethereum or something

then ethereum wouldn't fail like like how does a stage two rollup like it can never cause the L1 to to to to fail could it so so that's why I didn't mention liveness because ethereum can never guarantee livess for they all do it can but let let's as an example so eventual censorship resistance um with delayed forced inclusion the only way that delayed Force inclusion can fail is if ethereum fails so uh because it's enforced by the smart contract obviously we're abstracting away from the bugs because if we were to include the bugs and like the assumptions that that all the smart

contracts are not completely bug free Etc then we'll have a completely theoretic and useless discussion about how nothing ever shares any properties whatsoever but I think like for sake of this discussion let's assume that everything is ideally implemented and there are no bugs and essentially like in in case of evental censorship resistance the only way it cannot be enforced if is if ethereum fails so so I'm not sure if shared security is even the right way to describe it but it's essentially I guess yes it is so ethereum is just like is enforcing the security for the rollup in in case of eventual censorship resistance so that

would be the case of shared Security in in with regards to this specific property that doesn't mean that every other property so for example with regards to State transition correctness ethereum cannot enforce State transition correctness because it does not run the full nodes it trusts that the proof mechanism that is used by the rollup be it uh TR proofs in case of optimistic rollups of zero knowledge proofs in case of uh ZK rollups are functioning correctly and if they're not then ethereum has no way of enforcing and saying oh actually you're you're being not truthful here this is not how it works and that's it

agreed okay fantastic so so these are the four properties that that um and could so so it's data availability ordering uh eventual censorship resistance and um the the state transition function the attestation of the correctness of the state transition R but not not actually not like verifying the the actual the information of the transactions within the blocks of the l2s just confirming that that these that this is the correct block and the correct ordering and it's been done on the L1 that's been yes yes and and confirming that the proof that is used by the the rollup has actually tested to correctly because imagine a

scenario in where in which the let's say that the the bridge is faulty and it cannot verify the correct proof then you don't even know there there are no guarantees in terms of what the state transition was whereas in here there are certain guarantees obviously it's not equivalent to ethereum's guarantees but there are guarantees that at least if the proof system is functioning correctly then ethereum is guaranteed to en force it correctly understood all right uh so those were the properties that are uh shared by rollups by stage two rollups with ethereum and uh in terms of reaking

protocols they the ones that are deployed on ethereum shared share partial Economic Security with ethereum so um and I explained before that you can theoretically assume that a that a leaking protocol can share full Economic Security with ethereum but in reality it's unrealistic that it's ever going to happen and so to be more specific it means that the funds that are utilized to secure ethereum eth St eth can be opted into also securing other protocols um in this case it will be reaking protocols and that's where the name

reaking come from you you stake you stake an already Stak asset and so you get reaking uh and by the way reaking protocols do not have to utilize the native based layer asset for reaking you can you can imagine a scenario in which um I lay accepts any other assets I think I think they started they already announced the support of um ethena SD or whatever it's called Uh by them so and you can imagine how they can extend it to other assets even stable coins obviously the risk parameters are different but they can extend it to

Sable coins or other tokens obviously there are certain requirements and I'll I'll I'll I'll talk about them in a bit so and actually if you look at it if you abstract away from this whole like shared security discussion security provided by reaking protocol de by a certain amount of dollars let's say1 billion dollars of a base layer native asset so in this case e or a nonnative asset let's say a for example is identical the the the only difference that you can make you can claim to make is that basically

in you would need assets that have good liquidity and and are available because if the asset and if the if the asset doesn't have liquidity and it's extremely volatile then those security properties can change quite drastically whereas with something like e even though you can argue that it's also volatile it's not it's unlikely to lose 90% of its value in a day so the volatility is quite different to let's say mcoin so it's unlikely that anyone will ever use meme I guess people will but like but realistically it's not a good idea to use meme coins to secure uh a restate

protocol but yeah but but any other asset that has good liquidity and is not volatile it's not that volatile relative to meme coins it can be used and there's no difference from the protocal perspective and so realistically no security is shared what when we say shared Economic Security we just mean that the the assets are shared there's no actual Economic Security shared per say because you can imagine a scenario in which uh ion layer a a certain AVS within ion layer fails and ethereum functions completely as intendent there's no no repercussions and so there's there's nothing shared there

it's just the underlying asset that is shared there's obviously one caveat here and one thing that is shared is that the base layer enforces the slashing conditions of the reaking protocol which means that and obviously we can argue that let's say in certain cases where slashing conditions are not deterministic so they're voted by Committee in that case obviously the base layer doesn't enforce anything it just enforce the enforces the attestation on the slashing condition being triggered but let's say in a case where slashing conditions are deterministic then the Bas layer actually enforc those slashing conditions and uh I I've done that before and I think it's time to repeat

it again let's roast some of the claims that l2s and restating protocols make so funly enough I went through quite a few of the rollups and L2 websites and almost none of them make claims that are they're fully secured by ethereum at least on the front page which I was surprised about i f more people would be talking about that but but an example of this is mantle so secured by ethereum experience high throughput with our Revel security by ethereum's rollup technology all in in a familiar evm environment the correct way to say it would be partially secured by ethereum then I layer with shared

security to hyperscale ethereum partially shared Economic Security to Harper scale ethereum would be the correct way of saying it and then then symbiotic with symbiotic is a generalized shared security system enabling decentralized networks that which sh whatever symbiotic is a generalized partially shared Economic Security System enabling the centralized networks so you can see how things actually sound different when you add those like it seems like a small change but it actually makes a lot of difference at how it comes off and I I I think I took enough your your time so so I will jump to a conclusion shared

security is a my but it's actually a good thing that it is a myth because otherwise everything would have failed because of one single component which is not a good design in my opinion so thank you very much sweet yeah a couple questions I'll just pull the pull the slides down um okay so uh this is just going to get straight to the bare bounds of it what is is the what what is the biggest concern that you have with reaking right now um and how do you see this concern being addressed or is it like being talked about uh and thought through um generally speaking what is your biggest concern about

reaking I think my biggest concern is the fact that um that it can potentially introduce a cascading effect uh of in terms of the risk for ethereum from the perspective of the restake e so let's say if a big percentage of staked e is restak into igon layer uh then and obviously most of the avss nowadays are either secured by multisig or have no slashing Etc it's not very fleshed out and obviously this is not uh a criticism of its final form because the same can apply to rollups

rollups most of the rollups currently are also secured by multisig Etc and obviously none of us want that and so the end end game for rollups is is to avoid having those multix Etc and the same is true with ion layer but but in its current design it can even though it won't resol in long-term detrimental effects to ethereum but let's say if a mass slashing condition is triggered or or in case the the multi-c failed a lot of the E that is currently securing ethereum is also going to be slashed which means that ethereum security

budget at least temporarily is going to drop quite significantly obviously the the game theory dictates that if if the the the amount of E stake decreases then the the yields will go up and therefore more people are going to stake e whatever but at least temporarily that's going to have a detrimental effect to the economic security of ethereum and when you say the the economic or the the security budget that's just like the total amount of e staked basically yes and in a slashing event that number goes down because of well slashing and um that could be

problematic at a large scale yeah and again I don't think it's it'll have a long-term impact let's say if something there's a mass slashing evento on ION lay it doesn't mean that in two years time ethereum is still going to be struggling with economic security but at least short term it'll have an impact on the properties of ethereum and the and the like Economic Security yeah so if you're if you're thinking about building a rollup in today's world versus is building in in ABS on on Igan layer on a different uh reaking Pro uh protocol like what do you think about as the differences for Builders or for um applications to

deploy with different Stacks is there is there a specific reason why application type A would want to be a rollup versus an ABS or vice versa are you thinking about the landscape between launching new rollups versus launching abss or restak protocols from IG L as well as other uh restating teams yeah I I guess you can also if you really wanted to you can launch a an i layer back roll up secured by I layer that that design is also possible I I guess it really depends on your specific use cases and what you're

tackling um um if if you just want to focus on building a specific app and you don't really need a fully fleshed blockchain and like a fully fleshed VM etc for that app and you just want to scale that app then it doesn't really make sense for you to launch a roll up and deal with all the infrastructure Etc it makes much more sense to launch an ABS and to spin up an AVS and just run this specific app it's less hustle so so it really depends on the your target markets and also like what your demands are in terms of like handling infrastructure

Etc got it um I think those are my main two questions that I had following the the presentation I appreciate your time um thank you thank you for coming out and sharing these slides and uh these insights I mean overall it's always a fun time with you but this is a particularly pressing time in in this landscape and that's why we're doing this series so uh have learned a lot and contining to feel that this is a a nent form of I layer a nent form of this kind of notion of shared security and that as you hinted to this is not the final form of this protocol design um you know slashing for igen will go live for ethereum eventually I

think that you're on the right track I think that we'll see restake Bitcoin restake I know there's protocols for restake tether uh these types of things um so I worry a little bit about like the over rehypothecation of like all the all the coins that possibly we can restake um so yeah definitely gonna be interesting to watch that that that part of the equation play out yeah for sure I you actually surpris me that someone has F of doing a restate their protocol that would be an interesting look because yeah I don't I don't know I I think RW a introduce additional risk and you have to be very

careful with them because let's say if for some reason reaking contract is sanctioned then your essentially your entire security budget is bricked within one second yeah which is problematic um yeah to say at least but then like I mean the the the advantages to that system are like you get that understanding that you have this catastrophic uh mechanism that could abely brick you but like the on the other side you get basically the most stable stable asset uh in the crypto markets today to restake oh yeah I I definitely can see the upsides and so I

I guess if there was a way to use Ry or something along those like an actual decentralized stable coin then then it would be an ideal tradeoff where you you weren't at risk of a centralized operator pulling some shenanigans on you but also you would have the most stable asset in terms of volatility that you could have securing your protocol yeah yeah it just kind of brought me up up to something else uh um before we run what what is the what is your immediate Thoughts with regards to the idea of this inter subjective token design aside from like the 45 page white

paper um and kind of like the the very deep level technical research uh I mean like like do you do you foresee these more like uh subjective uh dispute resolutions or like arbitrary offchain or onchain kind of disputes uh or even just like in any sort of contractual agreement between two parties um seeing this idea of inter subjectivity coming more and more on chainer and like how do you think about this idea of inter inter subjectivity yeah I in going back to the 45 page white paper they lost me at page 25 I'm like I just don't have the

patience to go through 45 pages but in general I think I think I I understand that for certain use cases uh objective slashing is not possible and uh subjectivity is required so for example in the case of oracles there's no way you can objectively slash an offchain event an oracle feed based on on an offchain event onchain because your blockchain has no idea what's happening in real world it can only object L gauge on based on what facts it's been provided internally and and so for certain designs I think it's

necessary but I'm also afraid that people are just going to resort to S subjectivity A Lot in cases where objective slashing is possible but it's finicky and you have to like spend a lot of time perfecting the design and like it's not as easy as like oh condition a condition B do a small verification and just slash but it's it can be like something complex I can't come up with an example right now but but I you can definitely think of some and people are just going to use this shortcut because it's much easier than actually putting the effort and implementing objective slashing

conditions and therefore I'm I'm I'm I'm split I I can see why certain use cases would need this design but I can also see how people would take this as a shortcut because they can't be bothered with designing a more complex system that actually works without introducing assumptions about human behavior Game Theory etc etc yep yep Fair points um cool one last thing here more on the technical side so each of these I each of these IG lay abss have to write their own slashing logic and their own slashing contracts

um in the future there's going to be more I mean things like alt layer has like this wizard ABS thing that is basically allowing you to kind of like spin up your own abs and uh eventually they'll they'll probably have like more uh custommade uh slashing contracts and I know that the IG layer team is working on them um but do you think that having indiv visualized slashing contracts for various types of abss which want to create their own set of slashing rules and kind of slashing logic uh do you foresee that as being problematic at all to the IG layer design or even like in the in the larger case like The

Operators and the uh the kind of ethereum based layer uh it undoubtedly is problematic for from the perspective of you having to trust each individual AVS uh be because they're not standardized or their slashing mechanics underneath are not standardized so it is from problematic from one perspective but I think I can Envision the end game for uh the way slashing is actually enforced on chain being similar to like for example how risk zero is is designed where you can compile anything into this

standardized API and it'll just prove it and I think you can obviously that that still involves human factor and that still involves uh us trusting or assuming that the people who are building those specific apss are actually implementing things correctly but it's much easier to audit let's say rust code than audit a bunch of solidity especially nowadays where certain people like to add assembly Etc to to optimize gas costs Etc it's not very readable and so I think if

if if such a design can be thought of then that that would be ideal because then one it makes the lives of people who are actually building those AVS is easier they don't have to write a bunch of solidity code audited etc etc they can just write in Rust for example or whatever and just compile it but yeah I I I I I don't know how that will work it's just like something that that I can think of that can minimize both the not minimize but reduce the the hassle both from the AVS operator side and also the risk from the the

side got it yeah I mean I I I keep coming up with things so um pardon me give another couple minutes I we were just nice we were talking previously before about how the idea of i l like the original like this this idea behind this uh Global coordination mechanism right and that we can kind of coordinate I mean mostly mostly anything offchain onchain with this kind of inter inter subjective system and that okay we can build these avss uh out and the big the big idea here similar to rollups is like okay we don't have to build a proof of stake token design that basically we have to inflate away via token emissions

to bootstrap validators to have a to basically solve the something or the the the nothing at stake problem to to create incentives that uh work and so we're now entering this era of a lot of abss I think there's maybe like 30 or 40 I think in the coming in coming months we'll see hundreds probably as as these kind of roll up as a service but AVS as a service platforms really start to hit their stride and we were kind of just previously uh previously discussing before we went live about how the Dynamics of aan ler enables teams to not need their own token because they can inherit the security of ethereum or

restate ethereum uh via operators and so they can basically run these services or these applications these microservices however you want to think about them uh without the need for token which means that Builders can focus on the product marketing Etc the actual use case rather than kind of like the token games that we see a lot today um so the full loop here is basically how are you thinking about this relationship between avss and Native AVS tokens um and what use cases in particular because I know that you had kind of just touched briefly on that before what what use cases are you seeing for like perhaps for for

businesses where something like an ABS makes sense where they don't necessarily need a token um and yeah I mean just curious like how you see this playing out like are these teams all going to launch tokens like how is that going to work with the ABS how are they gonna they do like dual staking or um yeah just kind of what's your vision and what are some of the the more like business you cases for abss that may not require a token yeah I'm actually skeptical about how you can do dual staking uh Within by combining let's say for roll up by combining their own token and I canay and I AVS I just unnecessary add its unnecessary

complexities so I I think I think I I'll put it this way so I think the use cases for for AVS as an ion layer in general are there are a few use cases so obviously da especially if we assume that there's a lot of data that is going to be published on chain that I think I and da makes sense because ethereum is unlikely to ever be able to handle the scenario in which we're posting hundreds of megabytes of data per second let's let's say that's one example and uh another example is a lot of longtail rollups I I think at some

point it'll be it'll be more or less accepted that trusting a centralized sequencer is not enough to to to basically have finality or what people call finality it's not actually finality but let's assume for this conversation sake it is finality and so you would need some form of Economic Security to have those confirmation guarantees and obviously for projects for l2s like arbitrum it doesn't really make sense to use I layer because their token has a large fdv they can easily attract billions of dollars of Economic Security through their own token and so there's no reason but a lot of smaller

projects or projects where the token doesn't have a large FTV for those projects it actually makes sense to use I layer one because it will probably be more economical than spinning up your own network and trying to attempt to to build your own proof of stake Network and two it it'll definitely provide more security than spinning up your own network because another thing to consider for that I forgot to mention for large rollups is ideally you would want to minimize third party dependency as much as possible if you're a large rollup and can afford to run your own proof of stake Network etc

etc because let's say if arbitrum runs their own proof of State Network then it's only relying on that nothing else whereas if arbitrum uses ion lay and AVS from ion lay to run the proof of stake Network then it's dependent on ION layer functioning as intended as well and therefore let's say if ion L suddenly disappears or it fails for one reason or another then essentially arbit maybe not longterm but at least shortterm midterm it's screwed because it doesn't have that security anymore and it either has to revert back to centralized sequencer or spin up some adhul design that allows them to basically have some temporary

security while they're building a more uh long-term approach and so so yeah and and and I think that's the second category and then third category as I mentioned before is apps that don't need fully fleshed blockchains or fully fleshed VMS I think for and and they just want to focus on the product that they that they're offering and they don't mind paying I lay a certain percentage of the value that they pull instead of uh dealing with all the infrastructure themselves it's like I think the same argument can be applied to something like AWS people can build their own Hardware in their offices and run their

websites from their own server but the majority of people don't want to deal with the the hassle of running your own infrastructure having essentially your own it Department that deals with that Etc it's much easier to just like deploy a server on AWS and run it from there and I think the same thing is true here even if it's it might not be as coste effective obviously if you're a massive website then at that point it makes sense has to invest in your own infrastructure because the money that you spend on AWS might not be very rational and the same thing is true like anything that is not like the largest up or the largest roll up I think or like the top five or whatever then it

actually makes sense to use something like I lir to handle the all all the pain and hassle of the infrastructure for you and you just focus on your corpor [Music] awesome um scroll ABS soon no maybe yeah I don't know about that um yeah thank you to for coming out it's been a great great time and I appreciate you answering those those questions in the end there I had a had a couple lined up and then you just brought a bunch more out as usual so um I appreciate your time thanks for having me always fun to chat about this

things cheers man