DappCon 2023: Hashi - Securing bridges by distributing trust - Georgios

Transcript

hi everyone uh so today I'm going to talk to you about Hashi uh it's a framework we we're developing uh with a goal for secure Bridges by Distributing trust so let's look a bit uh the state of of the bridge ecosystem there are around or more than 30 Bridges currently live on evm ecosystems that secure uh around 4.5 billions in TBL um and from a security perspective vast majority uh is based on externally verified so multi NPCs and such variations there have been yeah of course security issues favorite topic uh when we discuss Bridges um the last

couple of years two three years there's uh 2.5 billion uh lost in token Bridge exploits um and in general uh in the top five biggest hacks of crypto four out of the top five are bridges um out of the 30 plus bridges that are around right now um the vast majority are yeah multi or variations of externally trusted uh parties and there's only a handful of optimistic or light client based ones so one could assume that maybe that's the issue right um so let's let's look at some numbers um and this is a statement that yeah

many uh can would say the last year especially that trustless Bridges and l2s would actually solve this issue um will they so this is a list of uh I believe yeah if not all the vast majority of bridge hacks that happened last couple of years um and we can see highlighted um are the 20% of them so three out of 15 um related to compromise Keys uh so comprom Keys yes it's it's an issue related to trusted external assumptions so multi and MPC and several variations but the vast majority of the hacks were not due to the the multis

right so due to um they were due to Smart contract bugs um Sim such bugs are very common in Cutting Edge technology so we should expect and prepare uh for such issues on both new trustless Bridges and also for l2s so uh the users so this is what users are doing um the we see clearly uh here that the l2s tbll so the user adoption there is growing and there is a down trade on the bridges and of course there's there's a an argument there is a reason to do so um but we need to keep a couple of uh

couple of points here in mind so first of all smart contract bugs uh on this um new tech uh were not found but yet right so the same was with Bridges by the way till the first big uh hack happened uh there is a still single point of failure on this Tech so if there is uh one bug found in one um critical smart contract the whole bridge and not only the bridge but the whole ecosystem will fail um so one could say that in general Reliance on on bleeding and Tech um is not battle tested enough um let's look at also some learnings from theory protocal development

um it's it's stated uh quite often that client diversity is not optional right so here are the the exec so consensus and execution clients there are different implementations right um in different programming languages uh why do we do that why do we need multiple implementations of the same protocol and are they If this just one is this not dozens times audited is not enough U here the main the answer is essentially that um if there is an issue found in one of these implementations uh in the compiler of specific language for example the goang uh then there would be a critical systemic risk for the whole uh ecosystem

and ethereum has grown so much as a settlement layer that we take this little possibility very seriously so uh one point here is that we we want to start taking Bridges as well with the same seriousness so we need to look at the client diversity and um a key takeway question here maybe a rhetorical question is is it a higher probability of a bug in the go compiler or in a highly complex math basic circuit some conclusions uh and observations from what what we discussed so far um all Bridge designs have tradeoffs there's no like good design

and bad design or good bridge and bad Bridge actually there are bad designs yeah but uh there's there's always a trade-off so every every design uh tries to optimize for something for security for uh speed for cost um second point is trus in just one mechanism in one implementation is not secure enough even if dozens of audits are done so we need a more robust and resilience resilient approach to securing Bridges um and if we summarize all of this in a couple of uh words is yeah 100% Bridge secure Bridge does not exist so this is why this is why Hashi this is where Hashi comes in um and we

build this framework with the following design principles so Security First and defense in depth so we optimize for security um we focus focus on client and in this context is security layer uh diversification um and we want to offer redundancy and protection against multiple issues so compromise Keys M malicious behavior including governance um erroneous message passing and of course smart contract bugs and we'll see how we we'll do that um we call Hashi like the additive security approach um that essentially means that we um we base the cross-chain

communication on yeah simple set like multiple inputs multiple we call them oracles adapters multiple sources um the main goal is to distribute the trust not to trust just one specific implementation um of of the Cross chain protocol but multiple ones and a third Point standardization um we want to offer standardization at the lowest possible level which is the block hash um we want to do that because this is the only level where multiple cross chain implementations not only messaging Bridges but also light clients or oracles can um basically work together a couple of key features so the

framework is uh modular and agnostic to any kind of underlying mechanism that allow us to to plug there in uh General message passing Bridges um yeah by what is General message passing breeds is you can think about like uh Wormhole uh diagnosis amb uh layer zero cell and um connect like all of these are message passing uh based uh but also we want to use an integrate with light clients and oracles even like chaining for example um and allows communication at two different levels so the blockheaded approach as we mentioned before which is

kind of a low level but allows all all these uh to to work together so like a light client can work together with a messaging protocol but there is also a more simplified version um where you can just use generic message aggregation so get a couple of um messaging Bridges don't not work with li clients and just aggregate them and make sure that they give you the same answer um so here there's a clear trade of um security and robustness over latency and cost so clearly this approach is more expensive is slower but is far more secure and last feature is like the to governance uh models that we offer and I'll go into

details um yeah in in one more slide um the the approach to defense in depth how what are the our weapons um to offer multiple times of defense and the security so many different uh General message passing implementation any kind of bridge that offers um message passing mechanism can be integrated uh due to the modularity of the framework multiple uh light client implementations M of n threshold so imagine like something like a safe like a multisig right so um you can you can have a I mean if you want to optimize for security you can have like a four out of four so you expect forces

of input to to agree on something if you want to optimize for resilience you can go two out the four and so forth so you have this flexibility and last one is minimize the governance attacks uh by limiting the governance powers and here I'll explain with a simple uh simple uh State machine uh what I mean so this is not a yeah topic not not analyzed enough but every L2 every bridge I mean essentially every system has a governance mechanism for upgradeability right so no matter how stral it is most of the system they have a multis that can go upgrade the whole thing change the configuration kind of a admin thing right and the the current best measures around in the market are

delay on upgrades like couple of days or something uh we took so of course we offer this approach this is quite quite simple uh but we we took it a step further um we thought how like if we prioritize Security First we need to yeah look at this um attack Vector as well and we want to minimize the governance Powers um so what this uh State machine shows is you you have governance multisig and you have initialization State like you have to initialize the system you have to give the initial parameters what kind of bridges oracles I want to use with kind thresholds and all this kind of stuff then you have two states two operational States one is the green one so like normal operation and we call it cartine state which is something is wrong

something go wrong so a multis can of course initialize the system and in a normal operation State the governance cannot do anything right you cannot just go there and upgrade any kind of implementation or change an oracle or um or a threshold but there are scenarios um and yeah one can imagine a bunch of those an oracle uh specific Bridge does not um uh provide any information so it's like dead is down is hacked whatever or provides erroneous information or a light client needs to be upgraded and so forth so if such a scenario is triggered then the system goes into quantin State and then the governance can or the multic can just again jump in um fix the system essentially so um

change any oracles adjust the uh um the thresholds and bring the system back to to the normal state where it has essentially no no power um yeah and here I want to show you like yeah now kind of an end to endend uh example of a token Bridge how it would work on top of Hashi so we have two two change to yeah this here in this case is a theum osis chain it can be any kind of VM um how would you bridge tokens right so here we have on the ethereum side in this example uh we have two uh message passing Bridges one is Wormhole one is our own canonical agnosis message passing bridge and we have also two light client

implementation so what we're doing is we're not trusting just one of them so right now we just trust A and B in agnosis polygons the same and you know and so forth they trust their own uh implementation so here what we do is we we send essentially the same message through all of these um oracles um which is the block hash in this case because we work with the light clients all of these methodes go with different kind of security infrastructure and different models on the other side and there is where we have Hashi and it's governance module where we have all this configuration we mentioned before and if everything go goes well according to our configuration for example three out of four of these oracles agree on this specific

specificat then I can consider this header or this message canonical therefore it's safe to Mint tokens so we think this model offers a far more um Superior in terms of security model uh for bridging tokens um this is a more simplified version how to imagine Hashi so um it's it's based like there's an analogy right with a ride model so in Hardware driv so you had two Hardware drives that you store the same things and if something happens to one hard drive you you you can rely on the other one so same concept here so you can say that hash is like a randant array of hash oracles so um you you essentially

have the same you ask for the same information for the same input from different sources different implementations of cross chain protocols and uh yeah if one is compromised is down you can rely on the other what's hass's current state uh so we have a test NET LIVE and five integrated oracles from the ones I mentioned before so if you're interested you can uh go check it out play around uh it's a girly osis chain um and and of course if you're developing something or you have ideas feel free to reach out so and in progress we we have several interesting um applications some of them are in early stage some of the in later stage such as cross-chain saves uh

governance use cases cross chain uh swaps and of course the token bridging I mentioned before and I want to show you a little bit the I mean from the examples I mentioned before I think they are quite vanilla and this is a bit more exotic um so what are the cross chain saves so you have uh so here you have ethereum and you have gnosis chain and you have the main save on ethereum Main net and you have a secondary safe agnosis chain or anywhere else in any other kind of evm chain uh using Hashi um you can essentially control the secondary uh safe onsis chain without doing any transactions on mayet we know

like mayet uh is expensive for example you don't want to do a lot of transactions there so how is this done you use Hashi to bridge the state of the chain of ethereum to gnosis chain uh in the most secure way possible and over there you can perform some proofs and essentially control uh your secondary SA using this proofs um yeah just by transacting on on the secondary chain um and yeah what's next um so apparently yeah it's it's main at deployment so it's we are quite ready to deploy a mayet uh we're also growing the team uh and working further on that um in terms

of diversification as I mentioned multiple times this is the um the main value position here so we're going to keep integrating more oracles more bridges more more implementations uh also not only on the security level but also on the execution uh so on the message passing so before we we focus most mostly about how do you bridge State uh but there is also [Music] um there's also the message passing mechanis like what do you do with the state how do you execute messages and there can be issues also on that level so we want to have multiple implementations on that level as well um one of the biggest Milestones is to uh get the gnosis Omni Bridge as is right

now and upgrade it and secure it with this model which will upgrade the security of the whole chain essentially not only the bridge um expansion to Major evm ecosystems and also not um not evm but is is quite quite easy to do um eventually offering secure assets with the example I mentioned before and also cross chain governance use cases which is something that we've we've seen yeah many Dows have been exploring this uh especially last year um yeah and that's it I mean I want to mention here that we're hiring we if you guys are interested to work on that feel free to

reach out either onsis side directly or to me um yeah and also we can if you are any questions thank you georgeos and we we have about five minutes for questions here any questions for George right here and down in front we have a microphone for you I was just curious uh if it makes uh given the additional verifications on the bridging if it makes the bridging more uh gas intensive or if it has any impact on like uh the cost for the user

to bridge yeah yeah very good point uh totally uh so again there is a clear trade off here so um it's a part yeah it can be in theory four times more expensive if you use four oracles and yeah one challenge that we we see is okay bridging outs from ethereum to any other chain it's kind of manageable but then anything that goes back to eum mayet especially updating Z Light client and stuff is extremely expensive so yeah we're working towards improving that and finding Solutions because yes it's it's quite expensive over here on the right hand side um thanks for the talk how will you

deal with uh varying bridging times will the slowest Bridge determine when this Oracle can give an answer can you elaborate on this yeah that's that's a very good point so hash is essentially as fast as it's slowest Oracle And if uh in our test net we we're looking exactly this this problem uh that you have message passing Bridges which are super fast uh like Wormhole for example is super fast or our own A and B and then you have light clients which are a lot slower so a light client I mean in the current test that we have it takes 30 minutes so like Bridging the state Computing the proof submitting the proof verifying the proof um so yeah it's uh there are Implement there are

improvements being done by the zik Light client teams implementation this is a super early early stage technology we expect honestly that there will be improvements by by the Light clients themselves because this is what slows the whole system down um other than that the the system is so modular so you can also customize it and if you uh if you because light clients is like an again additive security but if you cannot afford at the moment uh that they are that slow you can can focus on multiple message passing Bridges and get rid of the problem there was another question over there hi thanks okay sorry I'm a bit quiet so um Your solution uh is it not

moving the risk from multiple Bridges like okay each of them has their own risk but then you somehow aggregate them won't the risk be there or are there multiple like are those the different mentations you were talking about yeah that's a a very good point uh so you're right I mean what we're doing is like we're aggregating so we have different kind of implementations of by implementations I meant by the way different General meth spaning protocols different Oracles right uh different like clients and stuff uh so yeah essentially the the risk is transferred to to the to Hashi uh what we do to to minimize this risk uh number one hash if

you look at the code base is is a very thin layer so yes uh it's it's not like the the most complex code Bas at least at the current state so it's super modular so if you if you want to strip it down and just focus on on something that is super well um again audited understanded and secure you can do that there is there is indeed risk uh there um but I believe also the governance is to in my opinion governance was um was worse than that so even if you say Okay I I can trust I can trust yeah there a bit oximoron here since of the the topic of the talk but if I can say

okay the hash layer is super thin and I can work with that if you have a governance that is a multis that essentially can go any time and replace oracles or change thresholds uh this is your single point of failure this is why we we started working on this alternative uh governance system we have time for one more question if not then I think we'll wrap it up there thank you so much Georgio thank you everyone