Jutta Steiner: Secure Smart Contract Development

1 Mar 2023 · 56:58

Jutta Steiner, CEO and co-founder of Parity Technologies, discusses the evolution of blockchain security at an a16z crypto Startup School session. Steiner, who joined the Ethereum team in 2014 as chief of security, explains how the open, composable nature of smart contracts introduced new attack surfaces, covering risks like privilege escalation, side-channel attacks, and insecure key storage. She argues that securing crypto applications requires an operational security culture, not just careful code, since deployed contracts are difficult to change once live.

Speakers

Topics

Transcript

[Music] thank you [Music] really excited um to be here with you today unfortunately in this remote capacity and it's a bit odd past midnight here in an empty office that's been empty now for two and a half weeks already but we do what we can so let's get started so I've been involved with crypto and security Now for more than seven years I think um joined the ethereum team in 2014 as the chief security

back then this was all a pretty new field like I joined to help sort out the security Auto try to launch and then also ensure operational and security um but there wasn't much at the time no audit firms um that were dedicated to this um I stayed on throughout ethereum's launch and was around for um when the dial hack happened although that was already after we founded parity before I joined ethereum I worked as a consultant for McKinsey in Berlin I was involved with various I.T transformation projects but also I.T security and larger corporates organizations so I have seen that angle as well um however although I'm a mathematician

I'm not trained in cryptography um so I would say I did study relevant stuff um so I was involved with understanding complex systems mathematical physics how structure forms but also how chaos forms and how small parameter changes can actually to severely different and dramatic changes and outcome which I think is very relevant in the space um I was always intrigued with how maths can solve um problems like mainly from University I knew how it can solve or help solve problems in the Sciences so I was very intrigued when I came across blockchain

and finally saw something where Mass can help solving societal problems and not just analyze them which I was used to as a as a from statistics at Uni so that was sort of how I got in through um seeing that this technology could help with a lot of privacy issues we've had online and so um I've always been um very intrigued from the security standpoint with their technology so yeah right now I'm the CEO of parity Technologies um London based company big team in Berlin I co-founded that together with Gavin wood in 2015 I guess um almost five years old um gav who was the CTO of the ethereum

foundation at the time and have developed the ethereum virtual machine I would guess the first instance sort of of smart contracts in the context of blockchains had taken that early idea of a of a blockchain scripting language that vitalik had developed and sort of very well matured into this comprehensive virtual machine framework and then the smart contracts at parity we do open source blockchain tools to enable other projects and developers to deliver on decentralization we've had a lot of learnings security related ourselves and I want to share a bunch of them with you um

in our company I guess we have our very own view on security um and last year and summer we sat down and um and broke down a bunch of principles um that that sort of are important in our organization and when you compare that to the uh the two other more prominent startups um I guess um we aim to move with enough caution and intention to not break things um and having an undo um is always a good thing um so with that in mind I guess many of the things that you might hear today might sound like a bit like dried remarks um but in hindsight a lot of the things in city of security seem to be always easy and super obvious

um however many of the things have been very hard and painful learning so um and none of us should repeat them unnecessarily I think so that's my main goal to help you not do the same mistakes that people have done before and like a normal life like these wisdoms often sound right but um in the end they do carry a lot of wisdom and uh and truth and so it's worth exploring them with curiosity um finally I think um we've been always deep believe as an open source and security is one obvious Dimension where open source I think wins against the closed Source models in the past um the this future decentralized web is not built by a single company and we've seen in many instances like the Dow hack

for example how projects came together and like collectively try to solve issues when they came up so um I think we've come a long way since the beginning um when Bitcoin was invented um Nakamoto consensus security has always been very much at the core of blockchain as a whole um so nobody I think really would have expected or maybe a few people but definitely not the majority that something like consensus Nakamoto consensus could work at all in fact I think there's um a bit of a thing where Satoshi even um urged Wikileaks to not use Bitcoin to receive contributions because they were fearing um it could harm

um and lead to irreparable irreparable harm to um in case things break so um but then things moved on so Bitcoin worked a bunch of hacks um but mainly on the fringes a few security issues directly um inherent to the blockchain network um but then with the advert of ethereum a whole new attack surface came and that was mainly due to that virtual machine that allowed for a lot of things to go wrong the Dow um being one of the most prominent things I guess in the space um now where we today a lot of things have happened like the the base layer

um the lowest level um things I've matured where we are trying to include standards from other Industries or other places like webassembly um but at the same time that app ecosystem is also maturing and it's becoming increasingly complex and um and while we do have more tooling compartmentalizations standardization um things will probably continue to go wrong um um in the future so I want to share some learnings in particular that are relevant for smart contract development in this presentation but then also give a bit of an Outlook of where I think things are heading and what people might want to

consider when they um when they start a project in the space um what are the security considerations you should make but first of all I think it's really important to keep in mind security is not just code this is a definition of the National Institutes of standard and Technology of nit vulnerability it's a weakness and an information system the system security procedures internal controls or the implementation that could be exploited or triggered by a threat source so it's it's various things it's the people in the organization it's the operational procedures it's the life cycle management of the application um but there's also a lot of things that

might be totally out of your control it's it's the devices that people use and and and witnesses that could come in from that side um but it's also important to keep in mind exploits don't have to be all deliberate and some of the Full impact of an exploit might not have been intentional at all so it's like a lot of things to consider um and as Bruce Naya who many of you probably know um said he's one of the forefathers of software security cryptography internet privacy security is a process it a product can never be secure like there'll always be weaknesses things move on and and you have to ensure that the entire system can be as secure as

possible and that requires um pulling levers in all sorts of level so um Friday night enough of preaching of like principles high level um let's dive into the um the smart contract um bit of this um presentation so when I use the term smart contract I mainly primarily refer to Smart contracts as they appear on on ethereum that's the space I'm mostly familiar with um but let's take a step back what can go wrong with code um just in general when you look at code what are the things that that typically could go wrong in order to learn from that and how that applies to Smart contracts many of you are probably aware

memory safety is always an issue not just from a security perspective if you're a web developer you're probably well aware of the disastrous effects of malicious input to your code and having to properly check for that systems administrators um probably seen how accidental access controls can be very detrimental to what you're doing one of the things we are um we're in particular trying to overcome with with blockchain like the dependencies that come from um very fundamental design decisions tossing attacks um very important issue on the web um so yeah that's just just a few things just to give you a sense of what what am

I talking about when I say say things can go wrong with code one thing that's important to see is that all of these issues don't have like a single answer there's various things and various approaches we have to take in order to mitigate them at the core to me um is the threat modeling so having a really thorough understanding of the uh the potential threats the actors their motivations um uh all the different vectors and how you can attack so that's that's a very fundamental thing you should always do and it's actually quite fun to do um when you start doing that um there's audits um so reviews both internally and externally

that you can do and which initially were quite difficult to come by with in the blockchain domain but these days there are a bunch of specialized companies some specialize in smart contracts some do more wider um work testing is important um obviously for obviously reasons um both manually um as well as fuzzing So Random approaches for finding the issues with your code so how does that translate into smart contracts that's issues that can go wrong just in general with code so first of all like the issues we find in smart contracts and there's for example a quite prominent security firm trail of

bits we also work with them on polkadot who have done analyzes of that and I think the reading material had some reference so they've looked at it and in principle you find the same issues with smart contracts that you find with normal code not so surprisingly in the end it's the same monkey sitting in front of the keyboard but um that that doesn't necessarily mean that it's in the end the same impact that it has right so a lot of the findings um almost um 50 were impossible to imagine detecting um with with testing and that's really problematic because when you once deploy smart contract code it's hard it's hard to change it unless you've you've implemented measures beforehand that let

you upgrade um your code or make changes in whatever um reasonable way there's really no way um to uh what's really hard to uh to mitigate issues that come up also when you look at what's been written about um you could get the impression that some of what we read about um uh shouldn't necessarily so so that shouldn't doesn't necessarily mean it's it's the relevant code of the relevant issues uh for your application like other things might be more important because your your system displays other complexities um but all in all I think the big learning from from um all the issues that have come up is

smart contract development is the opposite from agile it's the opposite from how software development happens um today um it's very costly um the only because the only way to get additional insurances is basically by Contracting external consultants in the form of audits and and they are really costly um which makes it a tough thing to do um you want to probably apply um a varied or approach for writing your formal specifications and whatnot um these are things you might want to take into account so I would say um as sad as it is and even though tools have been developed smart contract development is far from easy and far

from secure at this stage unfortunately still nonetheless there's things we can do um parity we have developed um like a 14 point checklist at some point um that goes beyond just the development it's a very comprehensive list starts with how you organize your GitHub and repos how you do the deployment the lifecycle management um and then in the end of course also like how how you deal with code quality and the and the production of the code so um maybe just a few examples so what you want to do is you really want to complementalize what you do and separate it from everything else that's happening

in your organization and you want to create a different GitHub repo to ensure you have the appropriate Access Control in place you want to have separate repos for each contract also again to manage that a lot more um a lot more granularly and better dependencies to ensure you're always in control of what you're doing on the deployment side um a lot can be learned from um from best practices in in other Industries make sure um that you that you always have a thorough understanding what is the actual life contract that you have deployed make sure that the readme is really comprehensive and gives you uh the relevant information that you need

when things go wrong like where's actually the deployment address things that might seem trivial um really really aren't trivial when things go wrong and uh and you are on a lot of pressure code quality you want might want to try and use a different language when you write the tests from what the code is actually written in to ensure you're not getting caught by language quirks and a dollar review even if you don't engage Auditors for whatever reason at least have the Oracle reviews within your organization so that's a few things um on the uh on the smart contracts um beyond that

um I think there's some interesting observations of how the entire ecosystem has evolved as an interdependent open ecosystem and things we've observed that are security relevant um so constrained by the design space and performance limitations a lot of projects have started to actually build their own chains I think one of the first examples although ethereum was maturing back then most protocol Labs with filecoin and they started to build their own chain but they won't want more examples um more recently and sort of a concerning thing when there is the old adage from crypto don't roll you on

crypto rolling you all chain is maybe something you don't want to do because it's really difficult um I mean we're we're a parity where we are focusing on that layer like building blockchains we've built an ethereum implementation Bitcoin Z cash all sorts of things these days polka dot um and there's a lot that you can apply learn from um when for when you're doing a new chain and we've and we've encapsulated and we have Consolidated that also in a framework that people can use but but if you start from scratch not only is that costly it's also from a security perspective not a good idea um other things um that play a role in that context is because of the limitations on the

scalability side when you when people start to launch new chains in order to be able to deploy what they want to deploy at some point chains will start to compete for security um so basically the mining resources validator resources being a scarce resource chains will eventually compete and we're seeing that like we're seeing such an era approaching with the 51 percent attacks that some of you might be familiar with on is classic last year and other things this is becoming more and more problematic as things progress on the other hand applications are getting more and more

complex um and in particular intertwined with the platform um as well we've seen that um the for the first time I think or that became clear in the context of the dial as well um where in the end um the reason why the tile got fixed and for those of you maybe not be too familiar with that that was a very the very first incident of a decentralized autonomous organization deployed with the help of smart contracts um that uh dramatically um failed there was an exploit and a malicious attacker was able to basically seize or or would have been able to seize the funds in the Dow if they

hadn't been a fix and since there was so much ether deployed in the dowel around 10 the eventual decision was basically through governance move to to fix the issue in the smart contract through a hard Fork so that was sort of the first time that it became clear there is an issue when um the economics of the application get too intertwined with the fundamental security of the platform and I think very similarly for those of you have followed that in the D5 space where is used as a collateral that creates problems um as well there isn't enough

compartmentalization I would say what can we do um I think that's not an easy question security isn't easy um but I do think um there's some stuff that we that we can do and that is happening um quite interestingly as the technology um is maturing um let's let's look at scaling um in particular so a very straightforward thing to do when you think about um a system or technology that's Limited in scalability is um you would employ some way of parallelizing um whatever computations have to happen in order to improve the scaling very straightforward approach however depending on how you do this this actually works

um better or worse a very naive approach um ties back to bitcoin already with the side chains is to basically just run copies of the chain and try to parallelize them and have Bridges between those chains um that allow for communication across the chain however the issue with this is if you do this in a very simple simplistic way um is that the security of the original ecosystem basically gets divided across the different chains um and so that is basically what's in the end um the problem um because

um all these chains are much easier to attack crypto economically um because of the security being divided across the chains but also um you're running into sort of a weakest link problem um if you think of interoperability between the chains and that's really something we want because otherwise we end up with the same walled Gardens we already have at the moment um but if the security is divided in this way you fundamentally rely on the weakest link in the sort of chain of chains because um you have to rely on the security assurance that you get from those chains and and that gives you only a very weak interoperability that might in the end lead to severe problems when you build a

complex application that tries to compose different things from different chains you don't have strong guarantees much better approaches to try and share the security amongst the different chains like sounds obvious but it's actually quite difficult to engineer it's very closely related to the early sharding ideas for ethereum so in such a multi-chain system um all the chains share the common mining or in more modern systems proof of stake resources the great thing about this is that um also when it comes to the interoperability between the chains you

get much stronger guarantees and you can actually rely on the messages transactions to receive from the different chains and thus gets strong strong assurances a wrong around what you're hearing from the other chains now we can also drive this um a level further and I explain later um in the following slides what this all has to do with security apart from the sort of first level security um when we drive this a little bit further an interesting thing to then come up with is to say well if we have such a framework why not allow for heterogeneous strains so in contrast to

the ethereum charting ideas where you have sort of the same copy of ethereum same virtual machine you allow for different application layer customization so different virtual machines or better set runtimes that allow for customization for your specific use case think of one of the chains as being a a payment chain for example or one of them being a um uh I don't know a supply chain specific chain or whatnot the the big Advantage is not only do you gain a much better much better economics because it's

customized to use case but also does it does it reduce the um the attack surface on your application station on the chain so again compartmentalization is one of the principles that is always has always been important in security and it's about like finding out how to do that in the right way in the context of blockchain so um that's been a like those principles that I that I tried to explain like a lot of this has been behind the thinking um uh for how we have designed polka dot substrate and how we think about these days about what what platforms need to actually provide in order to allow for

much more secure um usage for much more secure deployment of application not for applications and that's um not just relevant because it it reduces the cost but in particular for security reasons like very similar to to Security in in it as a whole where there isn't a single system or single mitigation strategy that helps you to close the holes also here like you'll need various layers to various layers of of um of tools that all have their own weaknesses their own holes but as a whole um hopefully we can cover um everything and and create systems that are really difficult to penetrate so um that customizable runtime model I think

is is a very powerful one um because it very much so mitigates um the um the attack surface on the Virtual Machine level and like the dial hack um we've seen the multi-sik hack on our side um for for for parity a few years ago many of those really really big attacks that have happened or issues on ethereum in particular I would argue have been related to the virtual machine being way too complex and and way too powerful um as a tool in some ways way too powerful in some ways therefore a way to expose and therefore actually way too

weak um so that's I think a big opportunity for making things a lot more secure um other things that you can do when you um Can leverage such a customizable framework is it's much easier for teams and projects to resort to standards like wasn't webassembly um and much safer languages like rust for the writing of smart contracts because you're operating in a framework and not um on a um with the one sort of one side so it's all and still like very um glued together solution um so [Music] um another thing I think that's um also a lot underestimated at the moment is the

issue of of governance um governance and how the open source ecosystem um the core team feeds into this by choosing a platform um you make yourself dependent on them to a certain extent depending on whether there exist governance structures and and what they look like and the problem is in the end on-chain governance might be the ultimate measure in case of a big failure we've seen that we've seen that work with the Dow and through that fix and and having a strong approach on that end is I think core going forward and will save um safe people when things go wrong so

still like a ton to figure out um we've come a long way [Music] um there is a lot that we can learn from other Industries I think um and with ethereum we've we've done that as well when we started one of the things that we did in contrast to um to bitcoin when we started Bitcoin you might be familiar with the fact that um there is no there's just the reference implementation there is no formal specification or at least there wasn't originally um with ethereum because we knew we would build something a lot more complex um it seemed to make sense to us to rather like an aerospace start from a formal specification and then develop

fully independently various implementations um to achieve redundancy and remove the Reliance on a single implementation because that that former specification is a lot easier to check than than trying to understand what a reference implementation really does um medicine again medical professions I think there are a lot of good procedures to be learned checklist is one of them I think they've created a lot more safety and and a lot of the things we see seem trivial um but um they should be written down in a in a checklist in in some format that can be easily accessed gone through when things go wrong we we used to run um we always had Frameworks in place for

how to do announcement like there's all sorts of things where clear checklists can really save you when when you're under pressure in many ways um I would say blockchains or like say the smart contracts that we deploy um uh are a lot more similar to Hardware than software um once deployed once shipped um very difficult to recall so I might want to have a look at things that people do there when you are active in the space um it's good to have the right procedures in the organization there's various things you can do um I think in general you want to establish a really strong security culture in your organizations

um but one of the specific things you want to make sure you have is Crisis communication um because when things go wrong you don't want to scramble and try to find a firm that can help you talk to the Press if that ever becomes necessarily and then um again um I think uh developing developing your code in um in an open source fashion has tremendous benefits um it is I think one of the key things that um that kept ethereum alive in the early days the fact that also in that ecosystem projects came together and um and helped each other and it's the same thing we're seeing now now for Pokemon

what was powerful to build ecosystems but it's um at least equally if not more required in order to create secure systems so [Music] um key takeaway from this um I mean I hope you did take away something um from the from the Practical things that that I talked about if anything I provide you with some crypto editors so it can sound like an expert um I think yeah one of the key things to keep in mind security is really much more than code and everybody in your organization should feel comfortable to speak up when they see an issue arising that's really the um the best way to ensure

um um that that that you are prepared if things go wrong or ideally that things don't even even go wrong like a strong security mindset in your organization is important um smart contracts at least for now because of the lack of tooling um aren't secure um or at least say it's not easy to develop them in a way that you should rely on them um it's not agile um costs a lot um and and more issues will probably happen until we have those tools be careful when you roll your own blockchain or better don't do it like um like rolling your own crypto you don't want to like not rolling your own crypto you don't want to roll your own

blockchain um uh that's um that's a big big undertaking um I think overall it's it's important to stay humble um when you're active in this in this field learn from other Industries learn wherever you can um there's a lot to be learned also from web 2 and stuff that went wrong and then I think um lastly um security is really really hard things will go wrong in the future and I think it's it's quite um crucial that we recognize um that we're in this together and that we should learn as fast as we can um from from each other to um to build a better better web thank you great thanks you too that was great

um so yeah I get a virtual round of requires a visual Round of Applause great okay so so great we got some questions in the Q a channel and I'm gonna just sort of read them out to you and again thank you so much for staying up super late on Friday night to take these questions um so the first one is from Paul and his question is would audits be more difficult for a feature involving multiple chains on polka dot when compared with a similar feature on ethereum since you need to consider the characteristics of every different VM that's involved and I guess it I guess it very much depends I think it's easier to analyze um

um in its um in its components um because um on that level things are a lot easier to understand like if you have a customizable um runtime it's a lot easier when it comes to the interdependencies I think um and and and like sort of what can go wrong on a systems level as emergent effects I think you'd end up with very similar things um because um or at least I wouldn't I wouldn't assume it's it's more difficult I would rather assume it's um it's at least it's it shouldn't be more difficult than on ethereum because the underlying components are easier to understand so that's that's my sense yeah okay cool I see Paul nodding so I

think we got it um Okay cool so the next one is from Eddie um on the Asics and Z team he's asking can you say more about how security guarantees can be made between shards of the same chain what example what are examples of projects that do this um and some differences between these efforts this is on I mean the only examples really um that that come to my mind um that that do have this strong interoperability I theorem and polka dot like all the other attempts with um with um uh with doing interoperability be that be the cosmos or POA like they all leave you just with

a weak interoperability because they don't overcome um uh they don't overcome the issue that you divide the security in the end and there's a big difference between sharing and dividing on that level um that's that's really the only examples um that that I can see okay cool next one is from Stefan Stefan um what attack vectors open up by adding support for wasm smart contracts instead of a smart contract specific virtual machine um I would actually say um take it from a different angle I think well yeah I mean it's a good I hear your question it's uh you're asking about what what comes up but I think

um when it comes on a higher level it's it's the better approach because you're taking something that has a lot more a lot more um eyes on it um than something um that um that is fairly Limited in it in its audience um that said I mean um it's not that you you couldn't and there's probably interesting approaches for developing a secure smart contract language but like say with solidity the one of the primary goals was um to make it very easy for people to develop that's why it's like borrows a lot of ideas from JavaScript and whatnot like security was in people's minds but people didn't know how they would be used it took ages for having a library approach

um in the language and whatnot I think it's just it's more about like is it really worth Reinventing the wheel um or or what's the trade-off and and doesn't it make more sense to have these standards because they're easier integrate you don't you don't create additional complexities through the integration people are familiar all these things um that's why I would strongly argue for standards as compared to um Reinventing and making it specialized yeah cool um okay great next question is from Jeff and he asks how should projects think about making contracts upgradable as a way to address unforeseen security issues I mean what you probably don't want or maybe you want it at least in

the initial stages um this is a kill switch because then you have a centralized control again but there are ways of thinking about like um how certain portions of the contract could be upgraded like having having places having things in place for that um maybe then a multi-sig around that so there isn't a single controller um that's ideas you could have um when thinking about how to fix issues um in hindsight inside great okay next one from Arya um what are some social attack vectors you're thinking about with regards to the non-technical side of dows and and things like on-chain governance how has misinformation thought about from a security perspective and what's to

mitigate that hmm um [Music] I mean the game theory of these things isn't easy um that said some of the game theory um it's not really clear how some of that um plays out in the in the real world I think that's in general something um to be aware of in crypto and that started with Bitcoin already like not many people people would have thought that it that it that it does work but then it's the real world that makes or breaks and only then you become aware of like what the actual um assumptions or modeling threat models the really real parameters should be so um yeah I mean that's a hard question I

think um with with governance in particular um we'll have to we'll have to see what things um work and and won't um as we're bringing in um humans again and so they are really hard to model in their behavior and I think there's more more unexpected things than sort of um formal weaknesses that will come um come to be problematic be that like voting participation and actually planning for that which is one of the things that we're doing like if there's low voting participation you need a bigger Quorum um for things a small a big according for things to go through so like I think it's it's those things that are related to some of the Practical considerations that will

become important yeah one I actually have a follow-up to that which is I guess how do you how do you think about the the role of sort of traditional management structures in in the context of governance versus like some of the new things you can you can do with smart contracts like quadratic voting for example [Music] um like I I don't believe all of what we've done so far uh should be thrown away like I do think like a lot of the things that we've developed in the past there's governance mechanism mechanisms or like good governance um in particular checks and balances and whatnot like should really think hard about like how how to do that um to me it's like the power lies really in making things more liquid and being

able to play with voting mechanisms that um we haven't they have been so far really difficult to be implemented and used because of the cost involved and whatnot like to me um if we can do it right like it's a big field for experientation I'm trying out what what things actually work because on paper that they they might what they might look like they work and then they don't or the other way around because we haven't considered um a lot of the issues yeah but always do it in a way where you have an undo or you can go back ideally okay great so next one from ghee or guys sorry how would you how would you uh try to defend against supposedly trusted

contributors introducing obscure flaws for the sake of attacking a network for example if a core Dev introduced a vulnerability with the intent of exploiting it for profit hmm I mean I guess even with open source um like shorting is always something that people can do um when they introduce something but I do think open source already um mitigates against a lot of these risks I mean uh in your organization again um when when it's an organization that does this um It's relatively easy to implement relatively strict um review processes to still ensure there is uh the there is redundancy not

the Reliance on on a single um on a single contributor mm-hmm but um okay next one is from Mark and he says the advice I mean again time like some of the threats that your sister might be exposed to might not even be deliberate right like you want to do all these things um even because people just make mistakes like regardless of whether they're malicious I mean with their militias they might might make like sort of sophisticated mistakes deliberately and and they're hard to combine with but like a lot of the things you want to have in place in any case if you're dealing with um such um such core essential Services because um because things can just can just go

wrong accidentally right so yeah it's to your point like you need to you need to have multiple processes in place so if a vulnerability gets introduced in that way hopefully the process catches it right yeah yeah and reviewed it I mean take take all sorts of approaches for for coming up with that like um um and and be and be creative for not um falling into group think like when you when you sort of request maybe feedback from the organization on what they think um uh vulnerabilities are in your system then then ask for anonymous feedback so people don't fall into the group thing um way like there's a lot of smart things you can do that help you deal also with the witnesses uh in terms of

psychology of people right okay so back to Mark's question so you advise not to roll your own chain and there are options for for not doing so so there's um polka dot substrate and and Cosmos SDK and his question is which projects have been successful using these um and which have done well rolling their own chain so um projects are starting to deploy I mean it's still um early days a lot of projects will come out with their chains um or with their with their power chains for polka dot once once polka dot is live um it might be easiest if I send some

examples if that's helpful or also happy they're particular things you're interested in that I can send around yeah yeah that'd be great I guess maybe um you know I think we're still sort of the dawn of this era of building your own chain within sort of SDK like the ones that we mentioned um but yeah it'd be cool to see some of the early examples of that and if yeah if you have um any that are top of mind would love to show share them in the side cool so next one is from uh Stefan again so how do we align incentives between those who write the code and review the code with those who actually lose from hacks well

I guess that depends I mean to so when it comes to there's I think barriers about various aspects here like there's a dealing with um uh dealing with a malicious um malicious developer that wants to short um maybe that's a that's I think a specific um case I think there's um there's interesting ideas um around um uh not necessarily Bounty programs more like um also uh treasury dials that could help um Finance the development of Open Source just in general that's one of the things um that we and that we're also doing

with with polka dot like think about like how long term in general your ecosystem is supposed to run in particular on open source I think it's not so um although like security is again like a a key aspect um in general you want to make sure that you incentivize the contribution um in the right way so that's that's one of the things um otherwise I think it heavily depends on on the application like if there's a if you're if this is now about open source in general or if this about like how do you do that in your in your in your organization I think that's that's two very different um uh issues right that actually that gets to another question that I had

which is is um this is from me personally and it's it's how do you think about hiring for security in an organization like who are the key hires that you need to make and how do you build an organization around it such that you you can ensure the processes are being carried out across your org hmm I think that I think it it again like that depends on what you're doing I mean you want to have experts um for for like what you're what you're delivering in in the at the core um like you certainly want to to hire people for that but if that's like very Cutting Edge like say you're using substrate to build I don't know um a uh

um uh zero knowledge proof chain or that that includes your knowledge capacities like you'll have a hard time finding an expert then you want people who really can think outside of the box who are like really happy to to um to think first principles sit down um you will need to work with all sorts of um people across the um uh the system like um with the early audits um back in ethereum when you're doing the same for polka dot like we work with academics that look at certain theoretical aspects of of what we're doing then there's the Commercial Code Auditors that that depending on their Specialties um look at um relatively straight straightforward

things where they can do um like standard approaches like fuzzing that they know from other systems but then for some stuff you really need somebody who just sits down and things really really hard about um things you're doing and and it depends um it's good to have I mean if you can't find someone but they're really hard to combine with like experienced people who've seen things go wrong in this ecosystem um that's that's always always very useful but I wouldn't underestimate also um it's not enough to have Maybe he won't make things secure just because you have one expert right if you're if you're building a culture of like move fast and break things then even that person can't help you um with issues

that will come up yeah so do you maybe do you think there's some something to be gained maybe from hiring sort of security officers Chief security officers from other more established other software companies or other some of the other domains that you mentioned in your talk who um foreign I mean probably I mean like we I think we are we're in a relatively special situation where we're um developing like technology at The Cutting Edge I mean even there I think like well we we did look at at Aerospace which has similar issues or like which just it's some like when you build a new airplane like this is a totally new

thing and there's a lot of um a lot of considerations you need to make there's a lot of rules you have to comply with like all these things and and and and learning from that I think makes uh makes total sense some of that is not easily accessible like not it's not because open source is not so core to those Industries you don't necessarily find a lot of the information but it's certainly worth um talking to people from these domains and learning from them all right cool okay so moving on to the next one do you have any examples of exploits um that weren't at the code level um yeah sorry any any examples of Excellence that weren't at the code level that come to mind from from your experience with existing blockchains the statement that I met like uh

security is not just code like um like issues originate often in in in code I mean typically they do that's what we're building but then um the the mitigation and um and how you how you deal with them like that goes goes far beyond the code like even if there is an issue in your code like you want to make sure you have the procedures in place to catch those issues um on various levels like that's the main point like in the end like we're developing code so things that break uh are typically on that level I mean apart from like all the social engineering attacks when people try to steal crypto right like that's that's a bit of a special um a special set of

um of issues that have come up in blockchain um yeah yeah but yeah as you mentioned in your talk like you know 51 attacks where miners of one network are attacking another that's that's a you know that there's that's happened many times and that's a that's an example it's not at the code level it's at the sort of interdependent level of the ecosystem I mean yeah sure like those vulnerabilities yeah exactly so there's the there's there's all the things that come in because we're dealing with crypto economic systems here like 51 attacks um everything we've seen in D5 in the last few weeks like um the way how we how we expose how we get exposure because of market dependencies and whatnot like that's a

huge um thing to keep in mind and I think it's not very well understood um it's one of the things that um we also try to address with um the way how we designed um substrate and polka Road in particular so that you can have independent economics of the application totally independent of the economics of the platform so um one thing in ethereum is you price you price all the transactions in ether in the end because this is how the virtual machine works but if you design things a bit differently which we do in polka dot like that's that's not that's not required like you can have independent economics of the runtime um and so um first of all you don't expose your

users to um to the underlying cryptographic token in that way but then also from a security and and um and and and capex um uh and Opex perspective like that's a way better way of dealing with um the deployment of the application okay yeah that's great and that actually that gets right into a question from Mark um which is do you think it makes sense to divide the security in a case where not all the transactions need the same amount of security so and if security cannot be divided then low value transactions may have to overpay for security and compete against high value transactions totally totally um I mean I

uh not sure I can come up with a good example but a different way of thinking about this um uh or where like sort of similar considerations play a role if you think of um you wanted to build um I don't know a a platform um for um for gaming um people that Acquire um Assets in a game over time and that that's like on the Chain Unchained because people really want to own this like initially it's probably fine if such assets live in sort of a private chain setting um because they're not worth much but then once such an asset becomes worth a lot like there should be an easy transition for that asset to exist like on a public chain like I think that's that's very similar things

like there Security in the end is always a trade-off like really strong security is really expensive and always will be and sometimes it's also too so practically not feasible so yeah totally um there's there's probably ways to think about it in that way but begin to hear any any further thoughts you have on that end yeah um I mean it's it's a it's a complicated I I don't have deep thoughts on this but it's very it's a very complicated subject right and and I think it sort of gets into as you talked about sort of the interdependencies between chains if you have a chain of like high throughput but very low value transactions that could be fine for that Community but

also easy to attack if someone was motivated to do it yeah yeah and I think there's a whole range I mean because we're just starting to see sort of more real world applications being deployed or like actual use cases being deployed like that we have have not understood at all and where there where we will have to deal with new issues coming up um I think it's also an interesting moment as I mean the like the hype has gone down but I think also more and more people do recognize the um the actual relevance of blockchain like I think it's totally worth um making um efforts at educating sort of the more um the more original cryptography crypto Community I think many of them still

think like uh blockchain's like or maybe not many but but I think there's still some skepticism and and talking to them because they have done a lot of good work where we we all can learn from okay so next one is is from Eddie and Jeff um what kind of tools formal verification crypto economic simulation for example do we need in order to make smart contracts more secure in the long term and how should projects think about the trade-off between the time and the cost of doing these very notifications versus shipping hmm that that's a that's a that's a really um really hot one I mean it depends on the skill level you have like in the organization um but then again even that like won't

necessarily save you like there's there's a lot of considerations um I don't think that shipping I mean yeah as much as you can compartmentalize and and like minimize the the value at risk like all these things like um like take all these these principles and and try to think how you can mitigate um the uh the uh the worst case impact outcome and and like yeah and I'm not sure there's like a again there is like no single answer there's like all sorts of things you need you need to consider and I have a hard time uh making a strong recommendation as I don't know

what the considerations are that you're taking yeah so swiss cheese right like many layers of squishies um Okay cool so I mean in the end like still I mean as much as you can like try I mean do do try to think about like how could you how could you mitigate if if certain things can come up like um definitely um even if you decide to ship fast make sure you're prepared for things to go wrong like because if things go wrong like they can go awfully wrong and you do want to prepare for that for that case um so um yeah another another one from Ryan is what security considerations uh should be kept in mind when evaluating relatively newer blockchains to build on um the way how you can how you can in

that framework actually understand um the the attack surface and and how you can um the threat modeling and how you can mitigate against those like what are the tools that the that the application that the framework actually gives you in order to minimize um the attack Surfers that that you have I think that's that's a that's an important thing to keep in mind um when you do this yeah Okay cool so I know it's super late it's past 1 am I think for you so I think we can we can pause it there and again thank you so much for the presentation and for answering all the questions foreign [Music]