The Paranoid Developer’s Guide to Safer Smart Contracts

Transcript

[Music] hello everyone and welcome to the paranoid developers guide to safer smart contracts my name is Baran I am a former security auditor and I currently work as a smart contract developer at mentals so this talk is about paranoid development this is not an official concept but it is just the name that I came up with to my approach to Smart contract

development and over next 20 minutes uh I will explain this concept and I will start with the mindset of the paranoid developer and then continue with the practice and the mindset can be summarized as trust no one nothing and verify everything so before going into this approach let's discuss the need for another approach so how many of you are smart contract developers here okay it's almost half so I believe that we share the same

Challenge and that is crafting robust Cote it's is a fun challenge to have but I mean it's not that unique right all the developers out there wants to do the same thing but I believe we are separated from the rest of the group because of a very important problem and that problem is a symmetry of resources and the incentives between us developers and our adversaries so let's start with the good guys and we have the protocols on on the side and protocols usually operate under

tight deadlines and strong product pressure and protocols hire developers and the primary incentive of the developers comes from their salaries and occasionally from tokens which are weakly aligned with with the success of the protocol once the features are done and you pushed your code to repo you hand off your project to an audit company or in some cases independent Auditors and you need to find a good audit company and this is a really hard

problem because the only metric that we have is the track record of the audit companies and obviously past success doesn't guarantee future success audits are usually brief and time box engagements and the payment is usually independent of the result again we have an incentive problem here and another problem here that we should think about is it usually takes months and in some cases years to correctly assess the quality of an

audit uh the next group of people is the bounty hunters and bounty hunters usually have countless of projects to choose from and they usually don't have any guaranteed payments so you should be incentivizing them really well if you want them to look into your code okay next let's talk about the bad guys and by bad guys I mean the black attackers and maybe even nation state actors like lazer's group they are heavily incentivized by the hundreds of millions of dollars and

in some cases billions of dollars and their success means d direct monetary game for them they have unlimited resources and they have unlimited time and they have freedom to employ any tactic as you can see there is an enormous imbalance here on the one side we have nation state actors and army of Highly incentivized hackers and on the other side we have small teams of mly ins cised developers this asymmetry Demands a shift in our

approach we are like that guy over there armed with a small weapon and we are trying to fight a Golight and if we want to have a better chance in this fight we need to be very well prepared and we need to master our weapons so our approach can be summarized as we test retest and verify everything under various conditions using different techniques and on every possible environment this test also ideally should be conducted by different

people we do not take security for granted we do not assume it is just going to work we do not assume what we missed is going to be catched by an auditor or one of our friends our security depends on diligence at every step and we need to establish a culture of proactive security okay if you are going to remember oops if you are going to remember a single thing from the stock it should be probably the slide so practically you need to question every

aspect of your system you need to assume every component could fail you need to cover all your bases extensively and repid and you need to help external parties to do their job so we were focusing on on the theory and the mindset so far and let's start talking about the practice so just like any other blockchain team out there the foundation of our testing framework is unit and integration tests so we test basic functionality we

test each edge cases that we can think of and we write positive and negative tests also we check each storage right and each reverting condition it's also important to ensure that your events are fired properly and it's useful to integrate all of this into your cicd pipeline to protect yourself from regression box so the next technique that we daily use is fast testing so it basically means providing random inputs to your

functions and try to break them with them it's a very useful technique especially to catch edge cases so I can give you an example here uh we have an emission contract in our core repo and I'm not sure if you can read it but we have a function here called calculate emission this function is responsible for emitting mental tokens and we use an exponentially decaying formula to calculate the amount that is going to be emitted at any given time but as you guys know solity is not the best when it comes to work with

exponents and in order to work around that we came up with an approximation of the original formula but we had a sub bug in this approximation that bug was missed in unit and integration tests but luckily our first test was able to catch this and the next is Fork testing so when you run a test on the background your development environment spins up a fresh new blockchain and deploys your freshh contracts on top of that it is usually good enough but as

you can guess the environment the environment you are running your tests on is quite different than the environment that your contract is going to be run so you can use Fork testing to simulate real world blockchain conditions with live blockchain replicas we have a dedic cater repo for this purpose it is open source you can check it out and in that repo uh we have some Fork tests that simulate user actions against our live deployed contracts we run those tests automatically and periodically and if

something breaks because of the evolving blockchain state or maybe an update to third party we will get notified okay now let's talk about less common and more sophisticated strategies that we use and I will start with formal verification so unlike traditional testing methods we discussed which effectively you run you you execute your code with formication you use mathematical models to prove the correctness of your code so it is very useful because it can give

guarantees that no other technique cannot and it is a time consuming process by its nature and because of that we use it selectively at mental Labs but a prime example to this is we have a contract called stable token V2 and we are a token protocol and we use this contract for all our stable tokens since we are on sell blockchain where you can pay for guas using arc2 tokens you need to have this function I'm not sure if it is readable but it's called credited gas fees and you need to have this function in your token

contract and then as you can guess this is a very critical function because a failure in this function might mean A disruption of whole blockchain so we had a recent update on this function and we formally verified this function using Sora basically to deploy with more confidence okay one other thing that we like to do a lot is onchain monitoring and it basically means continuously observing the state and activities on your protocol we mainly use two tools for this and the first one is like a very popular one called dun analytics you can

create analytical dashboards with them and the second one is our in-house develop tool called ages ages is designed to expose onchain view calls as promus metrix and you can Ino ingest that metrix into your graph dashboard and you can create very customized very nice looking dashboards using that you can also use that Matrix as pritus alerts so if one of your invariance broke or if there is something weird happening on chain you will get notified in real

time this is a open- source project and it is business logic agnostic so go to our repo Fork it and start using it in no time and the last technique that I will mention here is the circuit breakers and circuit breakers like we are talking about onchain circuit breakers here and onchain circuit breakers are modeled after their uh traditional Finance counterparts so we use them to temporarily halt or limit trading under abnormal conditions

so we are a stable token platform and protocol and we heavily depend on Oracles in order to protect us from Price manipulation attacks or abnormal market conditions we developed onchain circuit breakers and our circuit breakers are autonomous and decentralized it is a little complex to fully explain the design of it but but it is a really cool piece of tag so if you want to learn more about it please go to our blog we have two amazing blog posts about it one is about the theory behind it and the other one explains more like the how we use it in practice

but yeah there are quite good post so please be to uh look for them and yeah okay so one of the one of the most beneficial things that you can do to support your protocol is to enable external Security Professionals and that starts with a proper documentation so you I'm sure you all write comments for your code but it's important to have very detailed documentation of your whole project so by documentation I mean you

should be explaining the intent of your project and you should be explaining the decisions that you made and maybe even explain each component and your design in detail and the next is a Readiness checklist so I recommend this to everybody who's going to work with an external professional so it is basically a list of your internal efforts and you basically go through that list before each external engagement and you basically remind yourself that what you have to do before engaging with an external

party and maybe the most important piece of your documentation is a handoff document so before starting an engagement you should be in code free and this document should include the details of your code pre your final commit hash information about your repo the detailed scope of the engagement of the audit uh maybe your trust models and assumptions and also you should be explaining the complex and novel parts of your system so that external professionals can spend more time on those parts

okay uh when you are done with your code and you prepared the detailed documentation and you did your best with your tests and form of verication and everything it is time to reach out to external professionals what I usually recommend is every team should have one dedicated security person that can be someone in your team who is security aware or maybe someone external like an external consultant or a friend and that person uh should be responsible for doing the initial review and in that initial review they should check your project they should

check your code and they should check your documentation and they should basically be sure that you are ready for an external engagement audits are expensive and you should do your best beforehand to extract the maximum value out of that engagement when your dedicated security person give you a goal uh now you go out and find an audit company hopefully a trusted partner that you work a lot and you should start building a relationship with them and you should also get to know the

researchers who is actually looking into your code because in most cases you don't know who is looking into your code but I think it's a mistake you should also form a certain type of relationship with the specific people who is looking at your code okay once your traditional audit is done and you fixed all your issues and your fixes are reviewed it's time to go for a contest so with a traditional audit you only have two or three sets of eyes looking into your code and it is insu insufficient with a contest you

potentially have hundreds of people looking into your code and they will do their best to secure your protocol so how I see this is once we deploy our protocols and once we are live with some tvl there will be hundreds of malici eyes directed at our protocol so why we are not doing that before the deployment for our own good so there are different options here and they are more or less the same with some small differences you should compare the options so we have C4 charlock hats and bunch of others so you should compare them and choose the one that fits to your

needs and the last group of people you are going to be engaging with is the bounty hunters and I I strongly believe that you should have a bounty program ready before the deployment I already mentioned this but you should do your best to incentivize Bounty bounty hunters to help you with your security and the program that you create for bounties should be transparent and clear with the rules and you should be as Fair as possible to the submissions that are sent to those

program so you can use a platform like unify for this or you can host your own Bounty program okay so remember security might be a part-time thing for you but your enemies do over time every day but don't be afraid we are a community of very capable people and we have similar goals and we share the same enemy so we should work hard we should

do our best to outsmart our enemies so a very smart guy said this his name is and grow only the paranoid survive uh thank you very much for listening me if you want to discuss anything further just send me a message or email at hi. or just scan this C code to join our community at mental apps and if you have any questions uh I think it's a good time to ask because we still have two more minutes thank you so much for the

presentation um what do you see in the AI space to kind of automate some of the steps that you uh presented I think we are quite early at that because we all share the same tools and I mean and not all those tools work really well at least for now I tried bunch of tools I don't want to name any of them but they are all way on the surface level and they produce a lot of false positives so I think they are not good enough for now thank you thank you for your question

all right uh thank you everyone and I will be right over there if you have any questions thanks a lot