ZKV presents Privacy in Cosmos: DeFi Edition - MEV and front running with Osmosis

Transcript

thank you guys uh thank you guys for hosting this um yeah so this is part of a so this is like a talk i've given a couple of times before uh and it's much longer but i'm gonna try to keep this one a bit shorter so we can get to the panel because i think that's much more interesting so um also i'm feeling a little bit under the weather so my voice might be a little bit gone uh but we'll we'll work through this um so yeah okay so what we're going to talk about today is minimizing mev through privacy in the mempool and so you know in osmosis we're focused on actually a lot of privacy stuff part of the original reason we started working on osmosis was to build a privacy-focused dex and by when exploring like different use

cases of like what do people actually care about privacy like like the number one thing that we came across is like the biggest problem that people are facing right now was this mev problem and like front running so what we'll do is basically talk a little bit about what mev is and then some of the solutions that osmosis is working on on solving it so um you know let's just get one thing out of the way before we start which is you know we keep saying mev and it means like might stand for minor extractable value but what we really mean is proposer extractable value because of course we are using proof of stake tendermint and you know uh there's no miners uh but yeah so but still you know there's still someone proposing a block and they have

certain powers and so that's really how you have to think about mev our proposal attract we're going to stick with the mev term because it's just the standardized term at this point but what powers does a proposer uniquely have that gives them some sort of edge and how can they extract value by using it so what are things that proposers can singlehandedly do so one thing they can do is mess with the time stamps of a block proposal right but you know we have solutions for this we in tandem we have bfp time which takes the median of every ballot that is timestamp so you know while this might be an issue in many chains in tendermint this isn't really an issue because you know we already got to solve

this another thing you could do is do consensus vote censorship uh you know another in in proof of stake and tendermint this would come in the sense of me censoring other validators votes only accepting the minimum two thirds i need uh in proof of work it takes the form of something called selfish mining but this is sort of something a proposal can single-handedly do um you can uh you can read transactions from the mempool so currently today everyone can usually read transaction in the memphis because the traditional way of broadcasting transactions everything gets broadcast um but you know we see the rise of like private mempools today uh and things like ethereum where you know uh traction creators will go

ahead and directly send their transactions to uh mining pools who add them into blocks but at the end of the day the proposer kind of has to be able to see the transactions in their mempool before they can add them the other thing they can do is control inclusion transactions in the block proposal they should pick and choose from the mempool what they want to include um and they can choose the order of transactions in the block proposal so you know what we're going to do is go ahead and focus in on the um you know these the three that have to do with like transactions uh you know the you know there's there's solutions for other for you know some some of these things that all the other mav attacks have like simple solutions some of them have more complicated solutions but we're going to

focus in on the transaction uh based ones so and we'll call this transaction based manipulations so i you know broadly you can classify these into two different categories which is censorship manipulations and ordering manipulations um and within ordering manipulations you know we have what's called what we call front running so what is front running you know you've probably heard this term before it's it's a term that exists in traditional finance as well it's not like a crypto specific thing in traditional finance what would happen is imagine you know you wanted to buy a million shares of some company on like the new york stock exchange you send

this uh order to your broker and what they will do what they could do is basically front run you by like using knowledge of this information to you know purchase trades purchase the shares themselves before you giving you worse pricing and then execute your trade afterwards uh and getting a profit and this is how robin hood makes all of its money um and then in the blockchain it's it's not very different you know what will happen is alice will go ahead and send a the transaction to the block proposer and the block bob will go ahead and send it um and what will happen is the block proposal in this case it'll be looks like a validator they could see the propose they can see the transactions

and we and the block processor can choose to put their transaction in front of everyone else's so they can like uh profit off of this and the fact it's the fact that they can read what's in the mempool that gives them the ability to do this um you also have something called dark force attacks which is you know it the name comes from the blog post from dan and georges who will be on in a couple of minutes in the panel um but basically you know it's there it's not so much about reading someone else's transaction and front running it but rather just making sure you're always the uh or it's not about like being relatively ordered to their transactions so in normal front running you still need to

make sure that the person who you're front running they get their transaction on chain so you could be in front of them in a dark force attack it doesn't really matter whether they get their transaction on chain or not really what it is is that you're copying their transaction itself so for example if there's some sort of on-chain puzzle a puzzle could be you know more in-depth it could be like oh a arbitrage opportunity or something like that but you know some sort of puzzle that can earn you money what what could happen is um you know alice could be really smart and have like a lot of work and figuring out the solution to this puzzle and she can go ahead and send her a transaction uh

to the mempool but what will happen is the blog proposal could be like oh wow wait that's a cool solution they can add their own uh they can just copy the solution into their own transaction and create a transact create a block that would and make sure their solution goes before uh alice's so this is different where it's not you're not sort of front running but rather you're copying someone else's transaction and it the distinction is useful just because it you know you can it helps on different types of some solutions only work on dark force attacks and or only on front-running normal front-running uh but the solution that we're gonna present here actually works on both of these at the same time because both of these rely on the same

uh power which is the ability to read transactions from the mempool so how do we solve this problem how do we make it so people can't the block process can't read transactions from the mempool and this is where you know it all comes together where why privacy is important here what we have is the solution here is encrypted transactions so we want to make sure everything in the mem all the transactions in the mental are encrypted in a way that the block proposer cannot read them so you know at the high level what what what what is the ideal we want a world where alice sends her transaction to the block proposer the brock proposer has a mempool and they know that there's a transaction there but they just can't

read what the transaction is and so you know all the transactions should be encrypted and then the blockers will create a block with the encrypted transactions the validators will come to consensus and commit lock on a block with an ordering of encrypted transactions and then there'll be some sort of magic that happens that lets the transactions be decrypted and then they can be executed and the the beauty is because we're using a finality-based consensus protocol like tendermint there's no we don't run into any situation where the uh the block won't can't be reverted once the transactions are decrypted once the transactions are

decrypted the ordering is known and they will be executed in that order so cool so this is really nice but the question is you know there's many ways we can make this magic happen what what what is the magic that's happening here so essentially you know from our research we've basically identified three main feasible methods of doing this encrypt of this mat this encryption magic which which are trusted hardware time lock encryption and threshold encryption so what's up and what we'll do here is we'll i'll give a brief summary of all three of them and sort of uh uh some of the trade-offs between all of them so

starting off with trusted hardware so trusted hardware you know how it basically works is you have these uh encrypted transactions and you know you're committed and then the ceo of intel comes in and performs some sort of dark magic that decrypts the transactions and executes them because no one actually knows how intel sgx's work i don't think intel actually knows how until sgx's work but you know okay what it really means is that there it the intel sgx is a piece of trusted hardware where basically you're intel basically has a private key inside of a trusted enclave in the cpu that claims to be tamper resistant in such a

way that you can send messages and here what we would do is we'd have it so we would um all all validators would have a private decryption key that is sent to their sex enclave so it's encrypted to the key in their enclave so now all the validators will have the same private key decryption key in their sgx enclave that in theory they should not be able to access because of magic trusted hardware rules um and then what's nice then is so once the block is committed then the block will be sent to the validators trusted enclaves which will then use the

key to decrypt the transactions and then execute them i'll skip this because we're not you know we're all using henderman here because this is a cosmos event so i don't care about how it works in proof of work but what what are the pros here you know there's a lot of pros on using this one thing is it's nice is that can be used as an opt-in feature where you know individual block proposers or individual you know in the proof of work case individual mining pools can choose to offer this as an opt-in feature which is sort of from my understanding this is the long-term goal of the flashbots project is to provide this as an opt-in feature um but however the cons of this are there's not a really great security

trade-off because you know as i mentioned one for one you have that you have a built-in trust assumption on uh intel you know that they're not that they're producing this trusted hardware in a proper way and they're not like you know if you could if if you compromise intel as a company it's very easy to break this because you can always intel gets to the side and claim what is a valid sgx or not and so they can just make a fake sgx and then be say yes this is a real sdx and then being able to sort of break all the all the security model here um but not only do you have to trust in intel you also have to trust not you don't really have to trust their like

you know uh that they're not malicious we also have to trust their competency and so you know the sgx doesn't have a super great economic you know economic security trade-off right so every couple months at this point you basically see like new papers that show you like there's a new vulnerability in sgx's that are released every couple months and so if you wanted to break an sgx you could probably get a team of like 10 of the top-notch best researchers pay them for six months and you'll probably find some exploit in the stx that will allow you to break it and you know how much will that cost you know 10 million dollars 20 million dollars maybe but if the

the the value of breaking the sgx to extract mev the mev market on ethereum today is much bigger than 10 million dollars right and so it's economically rational for someone to break the sgx in order to be able to extract the meb so that's why this doesn't really act as a great solution for for what we're trying to do here so you know on the trade-offs okay the pros there's very little execution delay it doesn't have a big impact on it's pretty good across the board minus the actual like security guarantees it gives you okay the next solution we have is called time lock encryption

time lock encryption is a cool encryption technique where what it does is you can have an encrypted thing and there's basically some you you can it's parameterizable but you can basically say there's some fixed amount of it's not exact you know you we can call it for simplicity of understanding some amount of proof of work that needs to be done on this uh encrypted data and then once that amount of time has a lapse a certain amount of work has been done on it it then is able to open up the uh encrypted data and it is now readable so how you would use this to create a um mempool privacy solution is you'd go ahead and send alice would

send her transaction to the mempool of the validator the validators will create the encrypted uh transaction you know a block with all the encrypted transactions in it and what would happen here is even and then off on the side once the block is created the values will be begin decrypting alice's transaction the mean in the meanwhile they'll go ahead and keep making more blocks and then once the time has a lapse for the decryption process then the uh they'll be able to realize alice's decrypted data they'll include that in the next block and this is when alice's uh trend transaction will actually be executed so

there's a sort of a long delay multi-block delay between the time of a transaction being included and the time that it's actually able to be executed um and so this actually you know is one of the main cons of time locking uh crypto where it has this notable delay on transaction execution which isn't the greatest like you know ux experience um but you and the thing is you know like i mentioned this the time lock length is parameterizable but you there's only like certain you can't make it be too short because you know let's say we had the time lock period be only in the order of a few seconds um or like even under a minute what what's important to happen is that

the decryption process doesn't have to wait until the transaction is included in the block the decryption can actually start as soon as the validator has the transaction in their mempool and so if they can prevent a transaction from me if they can decrypt the transaction fast enough outside you know themselves before that encrypted version is actually included in a block they can actually then go ahead and put their own uh transaction in a block to front run it so you know you need to make sure that this um that the uh time lock is sufficiently long um such that there's high guarantees that all transactions will make it into

the blockchain before they can be decrypted uh out of band oh sorry one second sorry my friend left his phone in the room and it went off um okay um cool then another another con which you know i don't want i'm not going to go into due to time but you know they're they're out it's not an opt-in feature this has to be a built-in protocol thing and basically every single transaction needs to uh use this uh time lock feature you can't you can't be like oh some

transactions want to use it and some uh transactions don't because if you allowed some transactions to not use the time lock then you could still effectively uh front run um so every transaction all users have to be subject to this uh execution delay um and it does provide some uh you know it provides some protection against the dark force style transactions um yeah so this is the same thing about like you know if you can keep it out out of the blockchain for long enough and decrypt it then it doesn't work so okay here's the trade-off summaries you know it's you know medium uh security you know it's parameterizable the longer you make the ux delay the

higher security guarantees you'll get um high execution delay uh very little impact on consensus and you know it's not opt-in so that's where we are on the trade-offs there and then finally we'll talk about threshold encryption so threshold encryption um to understand it you know one of the things that makes it a little bit special is unlike the other two solutions which do work on nakamoto consensus or proofwork style chains um special encryption does sort of assume some sort of bft consensus protocol and here's why so what is normal bfd consensus like tendermint so what will happen is you'll have a bunch of validators they all have like you know their own mem they have a copy of the block uh of the block proposal and then

they all take their votes they send them to the next block composer and that block poser once they have enough transactions they can com you know that that turns it into a committed block what threshold decryption does is what we'll have is basically what threshold encryption is is the validators come together to create a shared decryption key and that decryption key will have some limit of like how many decryption shares you need to be able to decrypt the uh data that's encrypted to that to that key and so what you'd normally do is you parameterize it so it's the same as the consensus threshold so in

tendermint we have a two-thirds consensus threshold what we do is we make it so that you need two-thirds of decryption shares in order to decrypt the transactions in the block and what this does is this allows us to basically every validator along with their consensus vote they'll package their decryption shares um with their consensus vote and so when they send their uh consensus votes to the next block proposer they'll also go ahead and send their decryption share and this basically causes it so using the votes that allows them to lock on the on the block and then there's also have enough decryption shares that then they can go ahead and decrypt and then execute and what's nice is this means

that threshold encryption happens atomically with uh consensus with uh consensus itself so you don't get you can't get into a situation where a block can be committed and not decryptable and more importantly unlike time lock there's you know assuming you know the the consensus the uh incentive mechanisms are working correctly but you should you you'll never have a situation where a transaction is decryptable without being in a block because validators will only share decryption shares for a for a valid um you know a block will only transaction will only be decryptable if they're in a

valid block and so this prevents the time lock crypto situation where transactions are decryptable as soon as they're in the mempool so you know the benefits here are they have a basically close to equivalent security as consensus um you know there's some slight things that you have to deal with but you know for the most part you can treat it as essentially equivalent um there's very little execution delay uh basically what will happen is you can unlike ethereum which like executes in the same block that transactions are included execution will have to happen in the next block rather than in the same block but that's okay because we actually already do this in tendermint tendermint already has execution uh

off by one and so it actually has no no change so what we already do in tendermint um it does have a little bit higher impact on uh the bandwidth because those these decryption shares are lit the amount of data that's being shared is linear with the number of transactions in a block um and so that that's you know one con and um it does require a classical bfd consensus but you know once again that shouldn't be an issue because i assume everyone here is using tendermint already um and you know there's some like cool stuff that we we have to solve with like making it work you know there's edge cases that you have to deal with with around gas and you know we can talk about the

solution if you're interested you can talk to us out offline about it um i'm going to skip obviously you know i so given these trade-offs osmosis what we've been working on for the last almost a year at this point is basically working on this threshold encryption solution because we found we've come to the conclusion that this actually gives us the on the trade-offs this is probably the best you know gives us the best bang for our buck and so this is sort of what we're working on implementing uh as an extension to the tendermint core software and it'll be available uh on the small samosas chain um and then you know there's other all these other sort of meb stuff that you know it's not it's not really related to privacy

there's sort of other solutions for solving these which we're not going to go into today um and we'll just go ahead and jump into the panel cool yeah thanks so much i uh i'm so glad that we got a chance to hear this talk i'm just gonna ask giorgio's to jump on so that we can actually do a short conversation oh i think he's lied you'd like me to like keep on the screen i don't know maybe the uh where's georgios hey georges hello is this thing on you're on all right great how's it going oh good um i don't actually i think the trade-off summary might be interesting so yeah i want to basically kick off

this little discussion after the fact i know there's a lot of conversation happening in the chat dave sonny's co-founders in there so hopefully helping to field some of these questions i know with this chat what we wanted to do is kind of like explore after you know hearing sonny's talk explore a little bit more of the like larger context of mev and also in the context of cross-chain stuff in the context of cosmos itself um i had sort of a question well actually georgios do you want to maybe just introduce who you are because i know that maybe the audience isn't entirely familiar with you okay you should be sure so hi i'm georgios i work with paradigm partners a venture capital firm

i'm a research partner which means i do engineering on stuff that involves companies that we invest in research on open source stuff that i find interesting and i think is useful for the industry and on the investment process because you know we look at a lot of projects and it's important to have people that know their technical stuff when evaluating investment opportunities um before that i did engineering audits and other cool stuff on the ethereum ecosystem and before that i was a i started electrical engineering cool um so thank you for having me yeah so i wanted to as a first sort of kickoff question that i had is like

does mev does this topic even matter in the context of proof of stake and on tendermint because i always got the intent i always got the impression that this was very much like a proof-of-work problem so i'd like to hear maybe from either of you maybe i don't know georgios if you want to take this one yeah so mev is not uh dependent on the work or on the stake it's dependent on as sunny said what are the powers of the proposer and on the finality conditions of the chain so in tender means you have instant finality or in bft algorithms where once a block has been mined or confirmed it's final and there's no way to do any chain reorganizations but this

comes at the trade of of uh liveness in tournament when one third of the stake is dead the chain is also dead um whereas in proof of work or in like a motor consensus um you have this whole concept of reorgs which means that when a block is confirmed it's not final and if more blocks arrive that have an alternative history and they have more work uh maybe they can cause a re-org which means that the current blocks that you're following they get discarded and you change over to the other chain why this matters is that because firstly um mev that gets exposed basically is the same in both working proof stake

but in the proof of stake context typically uh you have more finality compared to proof of work which means that this sort of mev attacks that depend on reorgs uh are more unlikely to happen so in bitcoin if you are in ethereum you can reorder any amount of blocks if you have enough stake in if you have enough hash power in tendermint you cannot do any reorgs to extract mvv in ethereum two you can do reorgs up to 12 minutes or two epochs in the past so there is some mev which can be exposed via reorgs but it's more limited and the mvv exposed vr urgs we typically call it the time-bounded

attack yeah so like like tendermint i guess removes that as a proposal proposer power so in a proof of work one of the powers of a proposer is choose what block to build on top of that's not a power that you have something to add though is that while in tendermint you cannot extract any video as a blog proposal during the reorgs uh with three orgs what you can do is that you can cause timeouts in other parts of the protocol so you know in tendermint how the protocol works is that two-thirds of the stakes they like gossip around a bunch of messages and when they have all signed on two-thirds

of the messages a new block is produced but if mev exists potentially and somebody other than you is proposing you could maybe refuse to sign on the block maybe taking on some liveness slashing but that's plausibly fine because you prevent the other person from producing the block and then maybe you get elected as the follow-on block producer after that person and you can propose a blog that gives you more uh mvv than what you paid in slashing so in a way i i you know phil diane said this a few weeks ago but i wonder there might be some sort of like preserve perseverance of mev or like the that you cannot just remove any v m v

always exists and just moves around layers depending on the protocol uh that you're using okay like the theorem of conservation of mv similarly to how we say conservation of energy um sunny in your talk you are primarily looking at like different kinds of privacy techniques to minimize or like and maybe doesn't get rid of it completely but minimize as much as possible mev but i know that there's been strategies that are more to like democratize mev and i feel like may i don't know if you both agree on which strategy is best here but i thought that would be useful to talk about um sunny why don't you why don't you

kind of brief brief the audience on what that conflict really means yeah so i mean i think this does have to do with the whole like i mean okay let me let me just pull that up really quickly okay so i have this like you know taxonomy of like mev like manipulations you know i avoid the word attack because i use the word manipulation on purpose because like you know i i think there's a fair argument to be said which is like you know some of these i think are more malicious than others and the ones that i'm you know the the area that i'm most focused on is this like

things that are based on other people's transactions and like that is like i consider when you when you're like breach when you're front running someone it's basically you're like taking knowledge of their transaction and like using it to front run them and i i consider that like like an immoral breach of privacy that needs to be fixed now you know another source of mev could be like you know on-chain liquidations right you someone having someone doing on-chain liquidations is good and you want to make sure that whoever is doing them is like properly incentivized to do them and if that's a source of mev that's like not breaking anyone's like privacy because

it's not based off of anyone else's transactions right it's based off of on-chain state that is freely accessible to everyone in those cases i think democratization makes sense but when it when it comes to like things that are based off of other people's transactions and private intentions i think that's where you need to like focus on minimization i agree with that i also want to say that you know we start with minimizing wherever we can in without gutting the protocol so you know in sunny's case one block uh delay might be an acceptable ux trade-off uh if it was 10 blocks delayed to be secure maybe the protocol is

garbage and you know we cannot like minimize the mev so we need to figure out some other way so you know demographic minimize what you can and then just make extraction as open as possible don't yeah so minimize the end demographics got it i want to bring this to sort of the cross-chain world mev in a cross-chain world does it matter like and by and i'm obviously talking the cosmos sense so maybe like over ibc like what how do mev issues from various chains actually interact is this something you're thinking about yeah so this is something we've thought about briefly it's not like super well fleshed out yet but essentially what

we'd want to be able to do is okay so you know the solution that we presented here is how do we do you know mempool privacy on a single chain um but really what we'd want to do as well is actually have like cross-chain threshold encryption and what that means is having like wrapped threshold encryption where like you know imagine you essentially you know what i think the big focus of the cosmos ecosystem like in like for the next year you know what i created a couple of weeks ago was like everyone else is thinking about cross-chain communication now yeah we've been thinking about it for years we've already built it and shipped it and like we're thinking about cross-chain composability now and i

think like what we're gonna be focusing on a lot on is like how do you make seamless like user interactions that take place on multiple chains at the same time or like you know you know i want to go do a swap on this chain and then it'll automatically transform past my tokens on uh to another chain and it'll do some other interaction on that chain right well the question is like can how do you can you get you know once the entire transaction is decrypted on chain a you can front run the part that's about to happen on chain b right and so how do you prevent that well one solution is this wrapped threshold encryption where you know you

have uh you know only the part that needs to be executed the part of the data that needs to be execu available to execute the transaction on chain a that can be decrypted on chain a and the rest of it can remain encrypted until it hits chain b and once it's committed on chain b the ibc transaction is related to chain b then the rest of the transaction is decrypted and executed on chain b now this works except for the fact that like you know it works at a very pure level but you know if there's situations where you can infer the action that's about to happen on chain b by looking at what's happening on chain a then it's like you you know we don't really have a great

solution for that and what i mean by that as an example is like you know um imagine i was going to okay yeah so imagine i was like you know there's a leverage loop going on right where you have a borrowing protocol on one chain and then you have a amm protocol on another chain and you know that's a very common user action that like okay they'll the first thing they do is go borrow some assets and then they take them to the amm and trade them right so if you see that on chain a a bunch of this asset was just borrowed you can probably predict that and you know it has something going to chain b you don't know what that is yet because encrypted but you can probably assume it's going to go sell that asset

on chain b right and so you can still front run them there and so how do you solve these like i don't know i don't know if there's a good term for them yet maybe like side channel attacks on but like we don't i don't know if we have a really great solution for that yet leaking basically you're leaking information by just doing some action it doesn't matter what the action is you're just leaking information about what will happen because all the possible actions that can happen contingent on the first action are limited right right right so what you had on your previous slide the blind front running part uh it's a bit less blind effectively you're guided by what gets opened on the remote chain so yeah i

agree with that also it will be very important to find out like who is running the relays so in cosmos very specifically um basically what happens is that there's three layers that pass on hashes of the chain headers from one chain to another and that is free because we're in cosmos and like that's part of the protocol but there's also like the relayer entity which basically takes transactions from one place and proves that they happened on the other place and basically the relay could say you know i forgot to relay a transaction because i wanted to insert my transaction first so it will be important to figure out ways to mitigate or

democratize or figure out how to like you know combat re-layer extractable value um and obviously you know in a closer in world charlie noyes like my co-worker from paradigm had said you know mev suffers from the cares of dimensionality or rather it grows super linearly to how many chains you have so you know the more the chains the enemy grows even more than that so in a multichain world this is even more important and you know we've only talked about cross chain mev in tender in instant finality these chains imagine what happens when you want to reorg like uh this chain because you want to cancel an action that

happened on this other chain or something wow so you know it's uh yeah yeah do you do you think that there's going to be a standard solution for like the proposal that you made sunny do you do you see that as potentially becoming a standard for different zones like they would all adopt this technique of mev or do you think that we're going to see like a lot of different techniques and maybe just start a lot of different techniques but yeah i mean i i'm hoping that like the threshold encryption solution will become the standard i think like realistically with all the trade-offs that were presented i think the only reason you wouldn't use threshold encryption is if you didn't want to use

like a classical bfd consensus protocol with but like given that everyone in cosmos is already using tendermint uh i think like threshold encryption is a no-brainer and then then yeah having this like multi-chain wrapped threshold encryption i think that will have to become like an ics standard an interchange standard that like all these chains will adopt got it so i agree with that just to give an extra point uh to kind of push back on your slides from earlier on sgx um basically we cannot rely on sgx for safety related properties so you know avalanche for example uses anxiety just told me in the am so thank you for the info

avalanche for example uses sgx for the bridge security and that obviously can end up very badly um if the sgx enslave is compromised but in the case of for example of uh and maybe in a dex this is also tragic because you know trades just start yet uh getting frontrun uncontrollably but for example in the democratization or the concept uh flashbots has been using sgx on top of the my on top of the miner software that they've been building which effectively um restricts the miners spawn rates uh compared to what they already have so instead of submitting you know a

bunch of transactions which by default uh the miner can unbundle their order in whatever order they want and there's a social contract uh you just use um sgx to remove the need for the social contract for the reputation and the worst case fallback is his reputation and as kobe writes in the in the chat it's basically defense in depth it's not a requirement in your system is it not worse though if people think so so okay imagine like a minor or minor it's worth it to break the sjx they they have the solution to break the sgx isn't it worse for people to assume that the sgx is providing security but there is reparation but there's reputation so it

is observable the moment the miner tries to screw up with things just picked them off your system i'm i'm sorry to my places right when there was a fight so yeah i i'm sonny do you have like one last point to say maybe um and then we'll move on my point was just like you know i feel that when people start adding sgx's in they become less aware of like the reputation of the peop of their counterparties because they're like oh it's okay they have an sgx i don't have to worry about their like trustworthiness and then when that sgx breaks i think then a lot of the social relations like yeah if

people stop relying on on trustworthiness when they assume that there's a sgx in play and once the sjx breaks things can get messy cool thanks everybody that was a great panel