EthCC 2: Adrian Brink

be good perfect I think we're ready to start so welcome guys thank you very much for attending my talk on Technical and social attacks against validators and proof of stake Networks it is sort of um an overview of some of the things you can do when you deal with proof of stake networks and values and how either you can attack the entire networks or you can attack individual values in order to eventually get to a network-wide attack so I'll give you a quick intro so you know where I'm coming from inside of the context that I'm speaking from so this is oh there yeah perfect so I'm one of the founders of cryptium labs cryptium labs was uh actually yeah I'll come back to this so I'm one of the founders of cryptium apps I used to be a technologist of three Foundation working on polka dot and before that I was a core developer and head of Partnerships at Cosmos tenement uh so cryptium Maps is actually born out of the experience at Cosmos so in around December 2017 we had a software piece that was sort of in a state where we could start deploying this to test Nets and so what I did in December I jumped on a zoom call with four other values at the time and we set up the first decent first test net for Cosmos back then and so this sort of developed and over time by early 2018 it became clear that running Valdez is actually something extremely interesting and something that's sort of an interesting technical challenge to do and so that's why we set up cryptium labs in order to run secure validation services and yeah so I'll give you a little bit of background of what Kryptonite actually does it's technically very simple so we are proof of stake validation company we run secure networks sort of any reasonable proof of stake Network we would validate currently we're live on tezos which went live in June 2018 roughly we also live on Iris net as of like three days ago Cosmos will launch next week I think and then there's edger and polkadot and sort of any future reasonable proof of stake networks and so this is really the main thing but the thing is while we do validation one of the problems we discovered is that we didn't want to run protocols that we didn't understand so like every Network they're launching we spend a ton of time trying to understand and diving into the code on how these protocols actually Implement how the client implementations work how the networking Stacks work which is why we also ended up doing a lot of protocol development because we are sort of in a position where we like where we learn how the protocols work anyway so we are perfectly positioned to also then contribute back to them and so the last point is Community Development Community Education as a validator you're sort of this interesting intersection where you interact at a very technical level with a protocol and at a very high level with the users of the protocol so you had a very very nice sweet spot where you can sort of take the technical learnings and explain them to the average user and yeah so we're based in Switzerland this is also not by accident so we picked Switzerland for very specific reasons which was mostly it's political stability um the very nice feature that it's like not on any geological fault line so we aren't in like a hurricane Zone we don't have to expect earthquakes which makes running secure High Assurance validator much easier if you don't have to sort of plan around earthquake sitting San Francisco um and the other cool thing is Switzerland historically has been a very safe place um and the government is extremely friendly towards crypto regulations which sort of means that instead of having to deal with the regulation that comes top down we can help the government understand how proof of stake actually works what validation is and help them shape regulations around this so yeah this is sort of just quick background on where I'm coming from So today we're going to talk about Technical and social attacks against proof of stake networks and its validators I'll start with a brief primer on proof of seek and how it works just so that everyone's on the same page so in the past and also currently we have proof of work which is generally speaking extremely wasteful right like the scarce resource you're burning is electricity and so in order to compete in Bitcoin mining you have to burn a ton of electricity proof of stake is this neat alternative in order that can provide a similar security guarantee as proof of work while wasting a lot less resources so the scarce resource improve of stake is capital so instead of locking instead of burning electricity in order to gain hash power you lock up capital and that's sort of the opportunity cost there the other interesting aspect that's like rarely talked about with proof of stake is that it allows us to build more interesting economic models right and proof of work the protocol itself does not have control of the asset that is securing the chain itself so in proof of work you sort of have A6 but the protocol itself has no notion on how these Asics work or how these like I can't do anything with these Asics in proof of stake the nice part is that the protocols actually have a notion of what the underlying asset is so we can design a much more complex Economic Security models around proof of stick this is also one of the downsides because there's also complexity but sort of an interesting area that you can look into generally speaking in proof of stake the networks are only as secure as their value set right if you can compromise a majority or not even majority like a third of the value sort of any proof of stake Network you can mostly compromise the entire network which is why this talk is a blend of sort of attacks against single values as well as attacks against entire networks because an attack against an entire network often starts with an attack against a single validator um again so the way this works improve stake is you have usually delegates and validators which lock up some capital in order to participate in consensus there are two main classes of faults you have safety faults and lightness faults so safety faults happen when someone equivocates so if a validator that is allowed to participate in consensus provides a signature for this same block height but two on two different blocks that's what equivocation means in this sense and this is a real security risk and extremely dangerous improve of stake because in proof of work you have to pick which Fork you're building on right like I have to either decide that I'm going with block a or Block B when I decide where to put my hash power in proof of stake I don't have this inherent physical limitation I can theoretically build on all possible Forks that I see and due to that you can sort of create any history if you didn't have anything at stake so by having by making safety faults so signing two blocks at the same height slashable you we introduce an opportunity cost there so that it is not in your best interest anymore to sign every single Fork but rather you have to alter pick which Fork you're going to build on top um then the second class of false is life as faults which effectively just means that a vowel data said he would want to participate in consensus and when it is his time to participate that could be in protocols such as tenement consensus in every single block um that the validate is not online not participating in that consensus round or in protocols like tezos where you have like assigned slots where you're allowed to produce blocks as a vowel data and so you're offline for that slot liveness faults generally speaking aren't huge security risks unless a lot of validators go offline at the same time so if a single Valdez offline there's like not a huge problem um this the protocols will do fine it start off in tenement consensus of more than a third goal of line that becomes a huge problem because the change starts halting if the same thing happens in teslos the change slows down a lot so but generally safe defaults extremely dangerous to the protocol life is faults only in large numbers and so previous stake is this very general term and there are sort of different instantiations of proof of stake and Allah is going to talk about them tomorrow in her talk um but sort of just to give you an overview there is liquid proof of steak which is tethers there's not many proof of steak which is polka dot and there's bonding proof of steak which is uh Cosmos they all sound very different uh the basic goals are the same though all right technical attacks against validators and proof of sign Networks so generally speaking when I say technical texts I mean attacks that require an in-depth understanding of the underlying client implementations and the underlying protocol implementations in order to execute they may require an attacker to modify the so instead of just running the default code they will require that an attacker sort of implemented their own node or guts an existing client implementations to just do what they wanted to do um and I'll talk about a couple of different classes in the beginning when I did my slides I didn't have any sort of sub points so we'll run through I think four or five different attacks or like attack areas so the first very simple attack area is actually um implementation attacks and under implementation attacks I also have volumetric DOS attacks right and volumetric dos attacks are extremely easy to defend against they are sort of simple to pull off you just need to start a flooding a server with requests or IP packets but the extremely simple to defend against sort of we have 10 years of experience defending normal web services against dos attacks and right now you can effectively just pick cloudflare two thousand dollars a month and cloudflare will defend against every possible dos attack on any possible Port if you're only running over HTTP then cloudflare doesn't cost any money but if you start one custom pods then you have to pay them like one and a half thousand dollars I think um as well on sort of the implementation side so this is a lot thinking about what is vulnerable in the client um so we had examples of RPC vulnerabilities where you cannot only extract extra information but you can also cause resource exhaustion on the client and some clients launched sort of with open to the public RPC endpoints which took down a bunch of nodes in the cosmos test Nets on ethereum we had this as an even worse case that nodes launched with RPC endpoints opened that if you unlocked your wallet and anyone that could connect to the RPC endpoints could all of a sudden steal the funds out of your wallet um then there's also the P2P layer we've seen and some of those attacks are about the fact that can you figure out whether you can send specific requests on the P2P layer that aren't sort of rate Limited in order to start crashing nodes or to start getting nodes into a state where they can't make progress anymore like a good example of this could be can I send unlimited requests to your node on the P2P layer to ask for other peers and so if I do this too much is the file descriptor League that after some time crashes your note we've also seen this um then the next sort of area of attack is mempools generally speaking mempools are quite vulnerable because when when a new transaction unseen transaction first hits the mempool the state machine that sort of runs the protocol has to somehow validate this transaction right is this complete garbage or is this something that looks reasonable and can potentially actually succeed when executing um on the actual Network and so in tenement call and this is called sort of the check Jack step so when a transaction comes in tenement core runs check TX to check basic validity rules um and sort of a lot of attacks there evolve around are there transactions which never get committed into the state but still cause a high computation overhead because nodes generally have a really hard time defending against this um and sort of this also goes hand in hand with vulnerabilities around the state machines where can I send transactions that that exhaust sort of that don't pay as much gas as the computation as or like that exhausts the computational resources without paying much for it um sort of early on actually one of the interesting things we did at Cosmos was um in sort of early 2018 we came up with this architecture for Sentry nodes which is effectively you have a sort of a firewall around your validators so that you're signing the node that actually signs blocks and participates in consensus never goes down but rather because it's never connected to any untrusted input in the first place but is rather connected to a bunch of notes that you control that you expose to the public and if there's a malicious attack against you those nodes will crash first but you're actually signing Server doesn't crash and so you could sort of construct this in hierarchical tears where you feel like public Center nodes that everyone can hit and then you have like private center nodes that only a few select people can hit so that even if all you public notes get taken down I will actually talk later about this why this isn't super necessary at launch unless you're getting attacked the next interesting area is answer network analysis this isn't necessarily um an attack in itself but it's rather an intelligence gathering tool it allows you to very accurately map how the underlying networking graph of the connection between the nodes and the network looks like uh yeah so the goal of the network analysis is effectively to map the entire network of nodes and how they're connected to each other and it is sort of uh there are many different ways to do this and sort of some are more sophisticated than others so the simplest one is that you build um a custom client implementation that only implements a peer-to-peer stack and just very aggressively queries other nodes for the peers they know about and then you try to connect to those peers and then query them again so you start establishing a list of all the PSL Network and moreover you can sort of if node a tells me about these peers I can make the assumption that node a is actually connected to them so I can sort of weekly draw links between notes um but it doesn't give me full assurance uh sort of a secondary a second type of this that you can use in order to achieve network analysis is to run something like math scan and try to sort of ping everything and this is totally possible by the way like you can ping every single IP address on the global internet in the ipv4 space in I think about 24 hours if you saw around 10 gigabit Ethernet card so you can effectively try to connect to every single IP address in the global ipv for space on the specific part that your default client implementation uses uh by the way don't do this without talking to your ISP they get very angry because they get a lot of like some parts of the address space on the internet do not like getting scanned so talk to your ISP before you do this they should be aware because they will get a lot of abuse um and so but the third level a third way to do this is actually um slightly more sophisticated it involves use heavily connected node to send transactions and sort of the basic idea is that this heavily connected node can send a transaction can send a unique transaction to one of its peers then on that peer it will first enter the sort of check TX phase before it goes into the mempool which means it maybe spends like a second trying to verify that transaction and only after a second does get relayed to other connected peers so all of a sudden you see these very clear step functions when I send a transaction to node a and that transaction then takes a second then sends it onto its peer so to node B and then node B takes another second so after two seconds if I'm also connected to node B node B will gossip that transaction to me and this is sort of an extremely reliable way to map most of the networking Network graph and this comes in handy for other kinds of attacks where you sort of want to Cluster um IP addresses to validators so you can say sort of validator a is behind these five IP addresses the second type of again this isn't in itself an attack this is a tool that you can build up that you can then leverage into an attack it's Network partitions so with modern cloud computing environments it's extremely cheap to sort of spin up hundreds of thousands of nodes so if you imagine that you are in maybe at launch there are a hundred actual full nodes in the network I can with like three clicks on Google cloud or AWS launch 900 other full nodes and all of a sudden I represent like my peers represent a massive majority of the nodes in the network so the I can also then start modifying the client implementation so that my peers will only gossip my my own peers to other nodes so if a new node joins the network and asks and it only at the beginning of the network of that yeah when the node comes up it only connects to one of my nodes minor will only tell it other notes that I also control so generally speaking when you start your clients be very careful on the first couple of nodes you choose because it's a very easy way to get eclipsed the cool thing here is you don't actually need to be fully eclipsed you can be partially eclipsed because even if you partially eclipsed it increases the latency for block block propagation or message propagation so for example in tezos if you're not very well connected message propagation may take a long enough time that people will assume that you're offline even though your message eventually gets there all right so the most technical of the attacks is probably is in hijacking so this sort of goes back to how the internet was constructed and so the 70s 80s we had a few large institutions that almost had Direct connectivity with each other but as the network expanded direct connectivity really doesn't work so we need these multi-hop message routing systems where I can be at my server like in Switzerland can send a message to server in the US but it doesn't there doesn't need to be a direct connectivity it can sort of hop between routers um across the global internet and this requires sort of people that are allowed to have IP addresses and own IP addresses are called autonomous systems and they each get an autonomous systems number but because it was built at a time where no one thought about sort of malicious activity this is fully unauthenticated so if I'm an autonomous system I literally just broadcast which IPS I route so if I know that validator a sits behind ipx and Y and iPhone as I can just start broadcasting that I now route for those IPS and uh the Glo routers will just accept these is like unless you're trying to attack like large organizations that have do have some protections around this but if you start just trying to attack a small provider other routers on the global internet will start routing the packets destined for uh validator a to you and now you have the choice do you either drop those packets do you delay them sort of you can't change them but you can sort of almost arbitrary race it's almost like a remote man in the middle attack without ever having to like plug into that network connection this is a really cool attack and we've seen this sort of happen on Bitcoin mining pools where people hijack the IP addresses where the local miners would connect to so that I could hijack their IP addresses and then point all the hashing power of that mining pool to my own nodes so that I would start getting the rewards instead of the mining pool operators and we'll sort of see this as well I think improve our stake at some point the next technical attacks evolve a lot around censorship and they get in they get easier if you use sort of the previous tools uh so the idea with censorship attacks is to cause Valor layers likeness issues so I if I have sort of a full eclipse of a valid I can just decide to turn it off and all of a sudden that valder isn't online anymore and no one else receives messages I can start delaying the messages so it just seems that he's like temporarily eclipsed in protocols so this also depends then on the exact protocol implementations and I'll give two examples in Cosmos and tezos so in tezos this can be used to if I start censoring people like how people's newly created blocks get propagated this can be used to decrease their efficiency because getting rewards and Teslas is directly linked to you signing a block so if you miss and you assign slots and if you you miss your slots your slot you don't get a reward for that slot and you also have the concept of stealing so if I'm if I have the second priority to bake the same block and I then delay your block I will get less of a reward but your reward goes down and my reward goes up and it's sort of you can do this very targetedly where you just Target specific validators that you want to with and you can maybe like get a 10 drop in the efficiency in their Rewards on Cosmos this works slightly differently because in Cosmos rewards are socialized meaning that you sort of have to participate in more than half of the last 40 000 blocks but if I can get you to miss 21 000 blocks of the last 40 000 blocks the consensus assumes that you're not online anymore and unbonds you and sort of places you in this jail where you can't participate in consensus for two days um we'll come back to this later in the social attacks but this is a quite interesting feature that you can use to take over an entire network by dropping people from consensus and yeah so the last thing I want to talk about on the technical side is host compromise um and this effectively just means that as a proof of stake validator you have some cryptographic keys on some machine and that machine has to be somewhat connected to the internet in order to in order for that key to produce signatures that can be relayed to everyone else the problem is most people will just run with file based keys so if I ever just get access to the machine I can X fill the key and now I can cause a safe default for that value so I can get that validator slashed but from a whole network perspective this is actually a terrible thing because if I sort of in secret or mass enough of these keys I can Excel them or gain permanent access to them I can start tricking full notes and light lines right like imagine if I sort of got more than two-thirds of the keys used in the cosmos Hub I could start lying to full notes about the history um or like about whether transactions happen I can almost create arbitrary in arbitrary history and yes there will be slashing involved but still this is like not a great idea especially if you have light lines and hopefully uh most of our mobile most of our mobile phones will actually be running light lines for these blockchains because it's like one of the very nice features of proof of stake like time verification is extremely cheap and efficient and like times are even easier to trick so there are two things you can do against this and both involve HSM so one is sort of a standard HSM such as the ubhsm that does protect you against key ax fill but it doesn't protect you against someone maliciously accessing host and causing a double signature the cool thing though is that we have Ledger Nano Ledger assets which are extremely cheap hsms but which are programmable and so I can write and this exists at both Teslas and Cosmos um we can build Ledger applications which verify the slashing conditions so in Tesla's I have a ledger application that verifies that I never signed a lower block height than I previously signed which means that even if all my servers get compromised unless someone at the same time also manages this to break into The Ledger over the USB connectivity that attacker can't physically cause me to double sign which is something magical when you think about right I can give an attacker full access to every server in my infrastructure and that attacker can still not cause a safety fall on my valve data so this also exists for Cosmos and there we track three integers instead of one because sort of the consensus is different it's using tenement core um one interesting extension for hsms in the future is to include time crystals in them so most hsms are really designed to to sign as many things as fast as possible this isn't like super useful in the blockchain context I know like I have to provide a signature every 30 seconds why would my HSN be ever capable of producing a signature more than 20 seconds because if I have a Time Crystal it ensures that an attacker can't sort of connect to my machine create a hundred thousand signatures for my entire history and get me slashed into this they can only create um signatures at a rate limit at some rate limit um okay this was technical side and I'm sort of going to speed this slightly up because so yeah I'm starting to run out of time so social tax against validates improved stake Networks these may involve some modifications but usually they're more heavy on sort of the coordination side of large amounts of the network assets rather than large modifications of the code basis so probably the easiest social attack is formica tells and cartels improve of stake are terrifying um and I will say this now there is a there may be an argument for why it makes absolute sense to form a one-third defensive cartel um at large like if you're a rational violator there may be a very good argument where you should immediately form a cartel you know because the only way to defend against the one third cartel is another one tell cartel and I'll sort of highlight why this is um so in Cosmos if you have more than a third of the network you can start to arbitrarily and by the way I'm not highlighting cosmosy as a specific I'm handling a specific example but other networks are susceptible in the same way I've just worked a lot with tenement consensus before so that's why I know the specific example quite well so if you have more than a third of the voting power in the consensus you can start to arbitrarily censor people and I mean if I have 34 of the voting power within the network I can say that I never let any pre-commit of bowel data a into the chain I never let any transaction that increases the globally bonded stake into the chain and so this gives me the ability that once I have a third I can start to targetly drop other values from consensus and so if this allows me to go from a third to two thirds at which point I control the entire governance process and I control sort of what everyone in the network sees and depending on your session conditions this may actually happen quite fast sort of in Game of stakes which we ran uh this hap could happen in less than I think 40 hours so if you have have like one third it's less than 40 hours to get to two thirds at which point you own the network and the only defense against this is to at that point hard Fork this is what I'm saying that you may want to form defensive cartels because the only effective way to defend against one tell cartel is another one third can tell sadly uh even if you don't get to a third that's fine because you can start leveraging the technical attacks from before to sort of let's say you have ten percent and then you start dosing specific value so they start dropping from consensus you're starting to Clips them you starting to Target them in any other way and you sort of slowly grind your way until you have more than a third um if you decide don't want to go that extreme you can also just form soft cutouts which offer priority transaction inclusion so that effectively if you pay this cartel out of band they will include the transaction a high priority than would normally be the fact yes there's also this concept of information symmetry which we've seen a lot again on the public test Nets because most validators spend very little time actually understanding the code base that they're running and most people will just run whatever command there like any reasonable person tells them in a riot chat I will give you the specific example from Game of stakes and Cosmos a bunch of people who are running with UB hsms and which at the time seemed like a cool idea because it was like first HSM that was available but I sort of ordered the code base there and I knew that if you ran with the ubh system with the current software version you didn't have any double sound protection not even accidental one um and so at some point there was dos attack the chain halted and to restart people started recommending to just delete consensus-state.wall files which a bunch of people did and it's a miracle that no one double assigned you to this because the contents of state of the Wall Files track the latest so the consensus State the tenement core knew about and if you just like randomly deleted it there was um at least a chance that you double signed because the HSM itself provided no protection against this um the other thing which I think a lot of people underestimate is do validates actually validate secure like patches to the software um do you actually ordered the code you're running because if not you're um only as far as like if the core team ever decides to if you just don't know the code from the core team if there's ever a malicious commit that goes in there which is like not totally unreasonable to assume that it will happen at some point even just by accident you're sort of opening yourself up to whole class of tax there because you're effectively just running untrusted code even though it's open source um another interesting information tag is uh what happens if you start posting a legal content into the chain that is specifically illegal more so in some values jurisdictions than others right you could ostensibly imagine that pornography is very much frowned upon and illegal in some parts of the world what happens if sort of users even users of the chain start upload loading links to pornography into the chain can validate Us in those jurisdictions to continue or do they have to take down the note take down the notes will they be liable for Distributing pornography who knows generally speaking it is much easier to Target proof of stake validates and proof of work miners because generally proof of stake validation solve this reputation-based game where you have to um where most validators are fairly public about what they're doing so they're slightly easier to Target and this is not necessarily a bad thing this is also a good thing from a sort of like Assurance perspective that you know who's securing your network but it's something that people need to design the protocols around and some of the last point on social attacks is governance I mean at the very simple level you can start purchasing votes through smart contracts in governance but sort of the more interesting attack is you can actually crowdfund attacks right so given that that individual chains understand how to slash or safety faults right like tezos understands what a double signature is on tesos and Cosmos stands for double signatures and Cosmos and Paul Cardinals stands for double signatures on polka dot other chains can do the same so as tezos or as ethereum as cosmos we can start like that governance system can start offering inflationary rewards to people that with other chains right like I can say that we will print 0.1 inflationary tokens for you if you manage to compromise more than a third of the customer's validators this is totally feasible if you have Smart contracts or if you just want to build this protocol the other cool thing is we can suffer crowdfund attacks we can start issuing tokens that only get their value once an attack is executed successfully so an attacking team can issue this token saying we will compromise more than a third of the cosmos validators if you buy this token now you fund us and once we successfully compromise it the protocol pays your reward and that reward goes to the Token holders and you can even make this tradable um so the other cool thing is you can do this for protocol upgrades so you can incentivize people to build new software for you by issuing the same kind of token strategy but you can also use the projects and yeah I think generally we should just be very aware that um in proof of stake we can heavily incentivize like chains can attack other chains and this is mostly a social game where you try to convince uh some of the governance mechanism of your chain to pay for attacking another chain this may be quite controversial but that's why you have Unchained governance um that's the last thing I want to talk about is just safety versus lifeless trade-off um this is sort of on the side a lot of um a lot of tested communities and sort of project communities there are layers care very much about liveness so they sort of have these fancy diagrams that explain the essential node architectures and like how they have fully redundant setup they have their keys in the US and the UK and if one of them goes down the other one automatically comes up um let me tell you that from experience this is a terrible security model um mostly so as a story on tezus this is how all the slashing has happened there were 130 slashing incidents so far and effectively all of them came from Valdez that had automatic failover Solutions so they replicated the same key on two servers and then sort of the Haku once had a shell script that's self-determined is the first note still online if not spin up the second node the shell script failed and all of a sudden you had two nodes signing at the same time um fancier value as we'll call this the coordinating coordinating server it's still effectively the same thing it's a single point of failure where if that calling server fails or a child script fails you're double signing the other thing is now you all of a sudden have this toxic key material in multiple jurisdictions you have to sort of travel with key material you have now the an increased physical attack surface against duplicated key material so um generally speaking not a huge fan of people that replicate keys for redundancy because in most protocols safety for good reasons is punished much harsher than likeness so it's much more acceptable to go down for a day than to double sign like going down for they cost you maybe 500 double signing May cost you thirty thousand dollars like those two standard no relation to each other in my mind um yeah anyone that claims that they have the perfect system that is as safe as possible while also being as live as possible most likely doesn't understand that there are inherent trade-offs between those two you can't have perfect likeness and perfect safety and I think the reason why a lot of people focus on this lightness aspect is because that's what we used to right like this is how we build web service architectures for years so always about automatic failover if one of your microservices die you spin up the second one let's put everything in kubernetes and this is going to be awesome it will never be down in blockchains and especially proof of stake validation this is really not the model that we're building that these systems are built from at the same time sort of having for example the center node architecture actually induces extra latency right so I think that's fundamentally a story around you should La you should run validators with what you like with security features that cannot be retrofitted so once your server is compromised and you have a file based key and that key is X filled you cannot then upgrade to ubhsm to prevent this once your service compromised in the ubhsm created a fake signature you cannot then upgrade to The Ledger s to validate this on chain to validate before you get a signature so there are some things that you cannot retrofit things like Sentry notes and liveness features you can always retrofit them it like it takes three seconds on Google Cloud to set up 50 Sentry nodes so if you're actually being hit by a DOT by dos just like spin them up then there's no point in sort of trying to isolate yourself behind this massive firewall as because it really doesn't buy you anything for um for most for the usual network operations yeah so generally focus on those protections that you cannot retrofit and sort of just be ready on standby with those things that you can easily retrofit such as selfie notes um yes so in conclusion validators are the security background of all proof of stake networks and don't design protocols without thinking about how they will be secured right like if you do if you're building your own blockchain and you're building your own proof of stake implementation um make sure that you give people the ability at least to run secure value so you don't have to tell them exactly what to do but provide the tools in order to enable this and yeah if you don't then no one run them safely and overall your network isn't going to be secure more so you need to incentivize people to run safely right like there needs to be some slashing and things like EOS I call unreasonable because there's no slashing like in EOS the best strategy is an individual validator is to run on a cloud instance somewhere to replicate the keys across 500 instances because there's no punishment for if you double sign there's only punishment for if you go down so builds if you care about security of these systems build systems that incentivize people to be secure not to be like instead of focusing fully on liveness um yeah generally speaking most successful attacks like the intersection of the technical and the social attacks and so like pulling off a purely social attack is difficult pulling a pure technical attack is difficult if you can figure out how to combine both you're very good like there's like very interesting things you can all of a sudden do and generally speaking don't like think that someone will somehow figure out how to secure your network like securing a network isn't a trivial task it's a really complex operation that requires dedicated resources um so when you build these systems really think about how you want them secured and designed for it and sort of as the last thing as a community I think across networks we need to be way more adversarial right like we want to test how these systems work before a malicious external actor is trying to attack us right like if we are on this adversarial to ourselves the first real Attack that hits any of these networks will take them down because we never tested the security assumptions or how we secure these Networks thank you very much and if you have any questions I'll be around later or maybe I have one time for one question I think cool foreign