# DigixGlobal’s security robustness and the Stablecoin, DGX

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2017-10-09
- Duration: 18:45
- Topics: blockchain, smart contracts, distributed ledger
- Watch: https://streameth.org/watch/yt-lOn1Blb0Q6o
- YouTube: https://www.youtube.com/watch?v=lOn1Blb0Q6o

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more.
https://archive.devcon.org/archive/watch/2/digixglobals-security-robustness-and-the-stablecoin-dgx

Talk on Contract Patterns and Security.

Speaker(s): Anthony Eufemio, Chris Hitchcott
Skill level: Intermediate
Track: Security
Keywords: patterns, solidity, architecture, readability, audits, attack, vectors, ics, storage, access, directory

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 2 was held in Shanghai, China on Sep 19 - 21, 2016.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] so I'm the CTO of digits global and I am famous for basically doing the first-ever athyrium transaction on block number 46 147 and I'm here going to talk about contract patterns in security so so the key points is first solidity is not broken okay so a lot of people there is some plot posts in the past saying that solidity because it is a an imperative language that it's a poor choice for writing contracts that has like state transitions so i'm going to show you guys that just with proper tooling and architecture we can actually write secure and easy to manage contracts so we're going to use i'm going to show you guys code patterns that allow us to minimize attack surface and i'm going to show you guys that the contract execution flow and figure out how you guys can identify attack surface in your contracts and also i'm going to show you the the case study of the digits core contract architecture right so both right so the bold claims quote good software design requires basically gives us secure good security so if you're right if you have good architecture you'll be able to actually create easy to secure and easy to audit code the first point is that good readable code and good architecture which is what that can easily be reason to can can be read by an external auditor so if you send your code your code base to a third-party auditing company they can actually easily read your code without having to deal with spaghetti code right so we know that if like this type of code well if you send this to somebody it's going to take a while for them to parse through this and that makes a deters lives so much harder and to like good software architecture will also allow us to actually have reusable battle-tested code so basically we can we can take components and build them out individually and we can reuse those those components for other parts of our contracts and since we know that these are battle tested and the security you know that there are the security is good so good software architecture also allows us to have separation concerns which actually enables the second point as well so if you separate your your code logic into separate contracts in the case of etherium then it's easier for you to audit it and it's also easier for you to control the attack surface the potential attack surfaces on your contracts all right so I sort of want to make the analogy of an electronic circuit versus software so in like an electronic hardware for example a computer motherboard or a CPU once that's created and fabricated it's it's very difficult for the manufacturer to recall those products so basically in essence like if they're iam contracts when you deploy them to the to the blockchain you can ever change them so so in that sense like we're expected to become electronics engineers when you write contracts on the cerium right so here we have a Commodore 64 motherboard I don't know if maybe you guys are familiar with this old school computer motherboard we have the series of memory chips and the moss sound chip the interfaces so when you design hardware you have different components that are known known to work well and and and they've been tested and you just basically put these things together and you have you know a device so basically that that sort of falls into the same concept as a software development paradigm called design by contract and i'm not talking about sylheti contracts here but basically creating your your your software based on small components that multiple people can work on or multiple organizations can work on and you have basically a set of preconditions that you can take in and and that will you know either produce a side effect or an output value fairly simple right so basically if you can make an analogy this sort of like your sound chip or your CPU you can put in put in it and you have expected output from it next one am I supposed to point this I think battery ednas is dead or dying yeah guys have another controller yeah the top button is not working served by that technical difficulties thank you alright back here alright alright so the third point is separation of concerns you basically separate your contracts into small pieces that can be easily audited and you basically can define the entry points and exit points to your contracts and number four good architecture will allow us to actually write better tools such as static analysis tools and generators to create basically help you create boilerplate code to implement this this approach so so what are attacked vectors right so attack vectors are basically code paths that allow malicious user such as a hacker or somebody a user that sends unintentional unintentional code tier software that either gives them unauthorized access and these can in traditional software you have command line arguments where you can pass well you can pass like some some a hacker can pass a carefully crafted carefully crafted code such as a shellcode with with some buffer overflow exploit and basically give them access to that machine environment variables as well and URL parameters which is common in web application hacking where you can basically have a hacker send sequel injection commands into your application by basically sending a quick carefully crafted post data or URL parameter and also data storage which falls in the same concept as the the the previous post of URL parameters in this case somebody has access to the database and your application reads some data from that data and and it costs us your application behave in a way that you are not expecting to and in the case of solidity and etherium contracts these are function parameters third-party contracts that can access your contracts so let's look at the cerium transaction flow so we know that all athyrium transactions must happen from an externally own account that means your private key so in the first four examples you have an externally own account calling a cerium contract and and that can go with an ATM contract paste out to another externally own account and the third example is an externally own account that sends transaction to an atrium contract and that also calls another a theorem contract and that is basically where you see things such as recursion and reaction see problems right so and in the the third act the fourth one is just basically somebody sending either to another external you own account and the last two can't happen right because like contracts cannot basically start their own execution maybe in the future so let's look at the example erc 20 token here this is actually on the dot bin I just cut and pasted this and this is basically the that to the standard token format standard token code with the standard interface for it so here we have the contract and then you have sent coin function which takes some values coin balance which shows you like the balance of the account from from the mapping and you have the balance off and approve so obvious all these functions and the arrow reside in the same contract right so in the same it's in the same binary that once deployed on the blockchain it's immutable you can't change it and it's very difficult to have people point to a different contract address so what we're going to do is we're going to break down the contracts into pieces basically these are components that behave in a certain way and and you can basically describe your software just based on these contracts so we have interface controllers storage and the last two are basically what glue everything together now we have the access control and the directory services and resolver right so interface contracts contracts that be called directly by an end user or external contracts this is the main entry point right so basically this is the contract that when you compile it and you produce the jason ABI this is the the con the ABI that you put onto your misc wallet or you give to your users or to other people that will be using your contracts so this is the main entry point so for our design this is the only attack surface so this simplifies a lot of the security audits and making sure that your code is secure yes this is the only entry point and we can control this a lot better than having a file that has all the logic in one file and then this can get overwhelming when you read it right so if you're dealing with with four hundred lines of code or five hundred or a thousand it's overwhelming to read one file and you can't really you know it's hard to reason about like large pieces of information so if you break it down to smaller pieces it's a lot easier to reason about it and figure out what's going on wyd again am I just having the worst luck for this you rewind right so interface contracts talk about it control contracts basically this is where most of the code logic goes and this is where you basically have your you're the interface contracts calls this basically and and all the functions that are needed to be called that basically either change storage state the state storage or the some calculations are all in here so most of your lodgings gonna be here and if you wanted to look for logic errors this is where you would look for right storage contracts yeah this is basically your database right so in traditional MVC this is your model this is where you put all your data and you put basically this is where all the information is about your contract under the state of your ear DAP other components access control this is actually a very important piece that actually puts everything up basically this is the biggest piece that puts everything together and there's basically set of your reusable code that we can use to describe how a resource can be accessed and at the jaques we sort of identified several access control patterns basically these are how you describe how a resource can be accessed by an external an account or another contract and so that would be an example here is the AC owned contract that we have and is very straightforward there's a contract that has an owner and if the sender of that that transaction is the owner then let it through and if not then you throw an error and eat up every the gas that they sent right and then here we have a it's very small the groups so basically this is the same as the owner but you can basically define multiple users to use to basically say that like this this this resource can be accessed by these addresses and it's basically simple mapping that says if you're if you're in a group you're you can access it and then there's like some functions to add and register users or ad groups to the system and the directory service this is what puts everything together it's basically a key value store its own contract storage and it tells the other contracts not because now we have split the contracts into multiple pieces then you have a directory services tells you basically where those contracts reside so in our directory service is pretty straightforward just a mapping of some byte string and the address and we can resolve it we can register and get the values right and we have if you can look at this second function here or the first function i guess if group NS admins it allow you to do that call that function and then we have a resolver client here which is basically a this is your your name server resolution client allows you to figure out where the contract what what the contract you need to call is and if there's also a modifier check basically to say that if if I'm being called by this contract based on its light address or is but it's byte string then allow me to go and do what I want to do right so sorry so directory service so here's a resolver so here's the the meat of this this whole talk really is the ICS pattern at dicks so here we have the TX origin this is the entry point this is your attack surface and this is where you would look at where a malicious person would would attack your your application right so you have your group access control and you have you have your int injects we have like different interfaces for different roles on the system and the directory service boss tells those contracts where to go next and you have the storage at the bottom so the storage basically if you look at this this design you can basically easily change these contracts and update them and add new functionality or fix a bug by just actually changing the value on the resolver so the only thing that's really difficult to change our the the storage contracts because that's where all your state and previous state is on there so if you have a token contract and you have your ledger information on there then that's kind of difficult to change but there's ways and thank you I think it kind of information for where people can find more information so um yeah so this is basically a call to action for people to contribute more to like these ideas so you can reach me at last that's my contact information slack reddit Twitter take a screenshot Thank You standing thank you very much [Music]