Protocols Discussion, Session 1

Transcript

so first let me repeat the question so he's asking about uh the use of create two and the dark spell mechanism that I mentioned so that was specifically for a case where you can't actually reveal what the fix is because it would reveal the bug and someone would exploit it um and so with create two you can announce look you know it's going to be deployed at this address and once you have an address then a governance proposal can be entered that gives that address permissions to do things with the system but you know there's no code yet there so you know the bad guys don't yet know what that code is going to do and so so create two is just the technical mechanism that allows you to know that when when you deploy a contract it'll have this deterministic address and the second question for unit squat

I thought under proof of stake censoring transactions would actually slash your state oh and there has been a major discussion with the the current tornado cash Fiasco where like people were saying of coinbase for instance sanctioned transactions related to tornado cash that their stake would be actually slashed and most of the community actually agreed to that yeah good question thanks I don't think I don't think it's actually risk risk-free uh to to carry this under proof of stake oh sure can you guys hear me through the mic now yeah

um so his question was uh there's some talk about like a slashing mechanism for censoring transactions under proof of stake um not my area of expertise by any means but my understanding was that this kind of like one time um uh one-time walk production where you can include your you know swap back attack and demanipulation without including other swaps wouldn't be detectable as that kind of censoring um not entirely sure on this maybe I can get back to you a few DM me on Twitter or something later um yeah yeah I can speak to that quickly uh like the censorship you're talking about is someone proposed a block and then uh uh like other validators refused to like

vote on that fork then there's potentially for like State leakage and like slashing for for likes not selecting that fork but like if no one is willing to propose the transaction or if you've bought all the proposal slots then you can yeah what I'm saying is someone has to this is the current ethereum proof of stake system can only detect censorship on a branch not like no one was willing to propose a block with that transaction in it correct but my discussion the community will actually vote for slashing I I think the attack would have succeeded and the money would be gone by the time like anything like that

happened so all right cool yeah caught a question for Kurt and Jared can you two give the talk will you I'll give the talk you mentioned a term like called a security uh versus safety you also say safety is larger than security and I think the Jared also used the term safety so I just want to you know clarify other are we referring anything more than just a code you know bugs when you mentioned safety I just want to see if there's a concept we try to deliver because you're tied to also management safety yeah well I'll just give my definitions for how I

think about the the term security and safety you know for me security means that some malicious entity cannot cause harm safety means that harm does not occur to you know any entities associated with the protocol like end users token holders Etc so and and harm in a D5 sense is usually a financial loss but you know the more general definition would be yeah just the harm occurs you can think of that there's actually maybe a higher level than safety which would be correctness um right because you know you'd never design something that would be unsafe but correctness tends to be like a moving goal post right because you're always changing your protocol it's very hard to Define and very even harder to prove so I think safety is the most useful one in practice because the loss

is a loss to a user whether a hacker caused it or not I totally agree that it's about protecting users it doesn't matter how you get there but that's like the other terms right but this is like as you mentioned way more than we had two people can you explain why you use it much better sure sure yeah and and

keep in mind that those numbers were for the East usdc pool which is highly liquid um so the reason the number was so ridiculously high uh was that you needed to move the price in a single block in in my simulations there in a single block such that the entire 144 block t-wop was a 30 price increase so you weren't moving the price 30 percent if I had the simulation with me I could tell you the exact but you're like making it so eth looks like it's worth a hundred thousand dollars or something like that so that the average T WAP is a 30 increase if that makes sense so it's also like in that case I'm not sure that you actually needed much better as well because I mean there is a inspirational right

once you escape to the area of this low actually yeah yeah exactly so these simulations were running on the actual unit swap V3 ethusdc pool with the liquidity distribution at the time that I simulated it um you're totally right though if there happened to be some other pool that had discontinuous liquidity or some like different liquidity Spectrum the cost may have been different um to be honest I used that pool because I thought the number was uh it made the point better surely there's other pools with less liquidity that would require a more reasonable amount of of funds to actually move the price but these are longer tailed or liquidity assets right yeah 100 000 eat this fud yeah um so you mentioned like about the tiwap

median uh using a median instead of QR but like if let's say like the price is stable for a while and then there's a big volatility change doesn't that mean it'll take like a long time for the price to update isn't that an issue at least with the T wobble slowly like update right yeah yeah sure uh so there are definitely some trade-offs with the midi and t-wop approach um so yeah exactly if you if the price were to truly move like globally a certain amount it would take half the window size for that to register on the median two up as well um similar problem exists with the mean two up as you mentioned but it's sort of a slow increase as opposed to uh discontinued or you know a sharp increase when it hits the half window size um sort of the Counterpoint to this is

that with the median t-wap as I mentioned in my talk you can use a smaller window because it filters out the outliers better so you can make the trade-off such that it's not so bad all right thank you uh so I would like to ask a similar question about like what are the trade-offs of median because it seems like a pretty elegant solution overall but you can basically answered that question so I guess I'll just ask in general um like for those of you who are taking a lot of either third-party contributions or you're basically having to figure out how to create good processes but potentially involve larger communities outside of a single team uh are there any like challenges and then ways that you've mitigated the problem of just coordinating larger groups of people but still having good security process

as I opened yeah um yeah thanks Michael I have a definitely have thoughts on that also related to the the um the the case that Amelia brought up about for compound that that was uh you know the one of the first Community contributions for compound um that led to that issue is actually you know very easily preventable but also inevitable because there wasn't processes um and you know this predates the time where um open Zeppelin was actually working for for the the Dow um and kind of led to that uh you know

actually as the outcome but um yeah I mean I think this is a very important part of uh safe security and safety for for protocols um that are that have decentralized governance um this is one of the reasons that I actually wanted to to share um my thoughts with with everybody and and larger communities because I think there just needs to be a norm of how how you go about making changes and ensuring that they're safe because I think it doesn't matter how how great the processes are at compound Labs or at any company if changes can come from outside of of that and that then people don't necessarily follow those processes so it just needs to be more of a norm I think yeah I'll say a few things about this you know maker we're starting to have

some other teams starting to do a little bit of smart contract code and so what we try to do is have the sort of core protocol engineering team work very closely with those teams and try to impart the engineering culture and lessons to them I think like the more sci-fi longer term thing is that we'd just like to have very powerful automated testing so that when a change is proposed you know it can sort of be simulated and various Properties or economic scenarios can be thrown at it and see how it behaves although that's you know still in progress we've got we've got some big integration tests just finishing up so I think yeah that's the future yeah I have some comments as well I mean I think like we should what we should try to uh strive for as well especially in com more complex protocols like uh

compound like uh maker like Ave uh where there are multiple risk parameters like features and interactions like there is a difference that I always make between uh protocols like uniswap for example um in which the use case are usually um very simple like the way the user interaction uh happens with the protocol is super simple and usually immediate so you do your swap that's it and protocols like Ave like compound maker where a user actually users actually keep position open for an undetermined amount of time uh where

the protocol needs to properly manage liquidity risk Oracle risks and and so on and so forth so protocols like uniswap where the use case is very small it's very limited are easily more easy to make immutable uh because um uh they require a little maintenance right you create during swap pool uh pretty much that's it then maintaining the the usefulness of the units were pulled and is up to liquidity providers right in other compound maker that's much more complicated because the users liquidity providers are continuously exposed to a different um set of risks that need to be managed

over time so other compound maker might require a risk parameter change smart contract fixes because of I don't know like some underlying protocol that maker or Ave rely on that they change their for example their business definitions and so on and so forth so I think long term to prevent this kind of issues what we should aim to what we should aim for is trying to reduce as much as possible like governance participation as well like I hope at some point we arrive to I mean I hope we are up to a point where the technology is mature enough where we can

actually limit the amount of code that we push to production smart contracts in a way that this also helps of course with limiting the surface the possible surface of mistakes if you need to push less code to to production then of course there is less risk of introducing introducing bar so I think that is also a very important aspect of security and safe T that is like reducing governance participation to the bare minimum this can be controversial it can be difficult especially right now where the technology is evolving very quickly and these protocols need to evolve with the technology because of the complexity of

these protocols but hopefully hopefully the technology will be mature enough at some point that we can reduce the actual impact of governance proposals on the technology itself and they've become more autonomous running software essentially my question is for any speaker who has an opinion on this uh what are your thoughts on test driven development okay I can go quickly because I mentioned it in the I think uh that's an amazing tool for um uh testing um Mission critical software like smart contracts I think it's particularly well suited for smart contracts uh because

they are and usually not particularly complex um uh uh architecturally speaking I mean they are compared to for example front ends or API or backends that you need to build on top of other Technologies where like the integration with other Technologies also fundamental and those particular you know in those particular layers of the stock applying test driven development can could be trickier in smart contracts I think they are very well suited for test driven development like tools like Foundry it's amazing for

example for a smart contract for a test driven development because you can write your tests and the call of the contract in solidity so that's that's driven development means you write the test first and then based on the on the outcome of the test you write the actual code that make the test first fail and then pass and then there is the loop of a red green refactor right so I think it's an amazing tool it cannot in my opinion it's very hard to apply all the time because then when you start building on top of test driven development like it becomes very very complex to handle at some point like the tasks can become very overwhelming compared to the code that you need to write but in general when you write very contain a small unit of uh software I

think is pretty useful and I think it should be one of the key component of safe and secure as Mark under development yeah I don't have much to add to that I'll I'll say I've only used test driven development myself a few times but you know every time I did it it actually worked pretty well yeah and so you know maybe we should use it more um hi uh Rex from D5 safety you've talked a lot about um spec Code test do you think you're getting close to traceability where you document from code from spec to code to test to test results so the question is are we getting close

to traceability from spec to test to code to test um well certainly everything is traceable I'm not sure exactly what you mean by traceability I mean certainly everything you know is that a specific term that you're referring to like everything uh yeah this might be uh outside of my my knowledge I guess but yeah I mean I think we try to do everything in a uh fully documented way and um you know uh keep this back together with the code and keep that

um you know if you make a change to the code then that should that should be reflected back in the spec and um yeah I don't know I think it's difficult to I don't know if there's specific tools that people have for enforcing that um which are which I don't know about but yeah I think I think um to the extent you know you should be as formal as possible um you know between those steps but it's always gonna as in my experience it's always been uh uh somewhat human driven and error prone because of that occurred may have more to say about this yeah I mean you know I I don't know if we're like at an aerospace level of rigor um yet in D5 maybe we'll get there eventually but generally a lot of things are recorded now right like you know

I've often gone back to you know like mine past GitHub discussions and see like okay I know we were talking about this this thing back then you know what did we say and you can really like there have been cases where I've you know very you know in great detail Trace to like where the design decision happened I mean we're in the process that occurred you know I still think there's maybe a ways to go in improving you know like the formal like okay we have a spec and then we had the you know the design and implementation and the testing and like here's where things got wrong but I'd say in practice we can usually pinpoint things pretty well hi I'm kanoshka de Silva I wanted to ask you've mentioned that uh smart contracts

should be treated as Mission critical application are there any uh standardization or mythologies that are in place right now like the owas security principle that I possibly don't know about as it relates to Smart contract or blockchain application security uh well um I guess every team like I should I repeat the question have you everyone asked her the question like the question is in general like are there some standard uh practices and procedures for for um writing uh smart contracts like uh Mission critical software I don't think there are standards there are industry

in industry-wide in the sense that uh for sure between us like essentially here I think we have the top four D5 protocols so I think between us more or less in different ways we follow uh like uh the same developments the same the development flow and development strategies um the reason nothing really standardized in the sense there is not um a standard development development flow that all of us follow at this in the same way everyone has actually their own internal uh development and security practices but like eventually we will converge in doing uh more or less the

same things because we are not really Reinventing anything like it was mentioned right before like Aerospace industry I mentioned NASA like um Mission critical software is all around us like everywhere like people lives is impact and potentially disrupt that's Mission critical software it could be microcontrollers it could be a Aerospace software uh space like Mission software it could be I don't know your oven can be whatever anything that could impact your uh your life so we are not really rementing anything we are just essentially adapting what already we

already know to a technology that is somewhat different because of the nature of the technology itself But ultimately like the goal is to bring you know as much safety as possible and Security in our industry which because it impacts people's life essentially one thing I have seen out there there's like a registry of common smart contract like bugs and vulnerabilities swc or something like that they I don't know I've run across it a couple times and so you know that sort of parallels you know Registries of vulnerabilities from traditional software and I think you'll see more of those things you know arise and become sort of Industry

standards as time goes on yeah the only thing I would add is maybe that um it is it's just the challenge I think is you can have I'm sure I don't think there's any like the best practices already exist um probably not you know coming from different Industries it's like how do you know about all these things um how do you force people to follow these processes especially in a decentralized environment um where you know changes can come from anywhere and people can launch new protocols um there's really no way to to enforce it except through um through the governance processes through the Norms um so and you know having conferences like these so um but yeah I think I feel like the the processes all exist but but getting you know getting the collection of what is the best practice and and documenting

that and getting agreement is the hard part so maybe that's what we're doing here quick question um so Kurt you talked to you know the whole security mindset culture procedures um but it's easy for those to drain away over time you know teams change and you know people don't have the same philosophy or you just you know you're not into it how do you keep that you know paranoia level you know following the checklist kind of culture and actually happening you know two years from now or three years from now yeah well reading reading wrecked news is a good way to I just scare yourself periodically

um you know you know I I think with the frequency of deflate exploits that actually has you know helped keep everyone you know nose to the grindstone on Safety and Security but you're right that's you know culture creep you know is something you have to watch out for and it you know it comes down to having strong enough transmission mechanisms within your Team Dynamics so you know not just everybody working alone independently you know if you're remote you've got to have those video calls and you know really make it clear that it's important I mean if and if it does come up that maybe someone on the team is not following the practices and procedures you know you've got to have a way to kind of talk to them and be like this is what matters

um and so it's you know I I think so long as you don't like snap your fingers and drain all the people who have that culture within them out of the team all of a sudden they can transmit it to other members but does have to be a you know a conscious mechanism of bringing people you know along for the ride like okay you're new well come sit in this review session and just get used to you know this is how we do things that I don't know yeah I have a comment on that because like when you mentioned of like a passing down like the the culture to every contributor kind of makes it's even more complicated like with the Technologies you're working on and with the decentralized approach not only to the software itself but to the development because like for example

right now I work with uh collaborate with Ave I work with bgd but ultimately I'm a community contributor right so I work as a community contributor I try to keep doing what I was doing before but in with a different approach like trying to involve more people that is not necessarily my employee but just people that wants to participate in the development of a technology that is for everyone because it's decentralized so this brings um further complexities because like you could have contributors in a newer um you know protocol only in your decentralized application that

they were not even part of part of your team you know someone sees a part of code they want to contribute somehow they create a a PR for your code right and how do you ensure that that PR is actually following your best practice you usually reject it the first time I'm just kidding like you you review essentially first of all you we must strive to have everything as public and as documented as possible so that people can read the documentation and understand why of certain choices and why of certain processes and hopefully like um even if like the first contribution

would not actually follow what you are trying to um you know what you define for uh your as your practices like hopefully like the ideas try to involve and bring these people and contributing in the Techno to the technology the way you want so it's a bit like it was mentioning like creating um like a strong culture and a um integrating like whoever is contributing in the fastest and the most reliable way possible but it's also usually even more complicated than in normal traditional software development because of the decentralized nature of what we are trying to to build all right I think that was the last question right now

cheers [Applause]