Real-World Smart Contract Development Lessons

my name is reine Revere and I'm a smart contract developer I am the lead architect at shape-shift prism and I'm also the co-founder of Maiden I've been doing smart contract development for a couple years and our team has learned so much along the way and it's really an honor to be here and to be able to share some of those lessons with you and it's especially an honor to be one of the few women up on stage I'm a trans woman and I love this work and and the community is so amazing and so it's such an honor to be able to share some of this expertise and really dig into the details so when I was thinking about what I could possibly share I wanted to give something that was really practical and so this talk is gonna be pretty straightforward we've got lots of things that we learn doing smart contract development in the real world so that means production level handling lots of ether on the live Network which as you can imagine has a lot of responsibility that comes with that so what you can expect from this talk is that I'm going to go from low level to high level so all of these are pretty practical tips for all the smart contract developers in here and I'm gonna start with the code and we're gonna go over some details and patterns that I've learned and our team has learned from and then we're gonna end on some higher level patterns especially when it comes to being a lead a leader on your team how do you lead as a smart contract development engineer so first the low level patterns central logging is something that took me a little while to find my way to and when you design your smart contracts you want to modular eyes things right we all know that as software developers but there's some quirks in the EVM at least at this time that you may not think about ahead of time but actually lead to a system that is more maintainable and is able to respond and communicate with your server or whatever other architecture you have and one of those is what I call central logging in a multi contract system logs or events that are fired are really an important way to track what's happening on chain all of your off chain activity is going to be based on different events that are firing and when you are firing events from different contracts you generally have to monitor those events separately so each contract you're going to be watching those events and so if you have a multi contract system there's actually a lot of benefits to using a single logger contract and so when you have a single logger contract all of those events will fire from the same contract and are easier to monitor so let me just show you how that looks so here's an example of the logger contract and what we have here is a white list that map's addresses of contracts to a simple boolean that says whether it's been approved or not so this is where it handles multiple contracts so this addresses our of contracts and you have a modifier that's a simple requirement that the sender is indeed in that whitelist and so the modifier whitelisted is provided here and then you can have any event here the event is called registered so that's the red text with the two superscript and the registered event is simply forwarded from the log registered function so if you have the owner which is provided with the owner super contract and then the only owner modifier pretty standard you can have an owner contract that is able to register all the contracts in the system so contract a contract B contract C all of those would be an authorized contract to be able to register those and if that authorized address was set in creation then you know exactly who has the ability to register new contracts and then those contracts have the ability to call log registered or any event so that's an example of central logging and that's been super helpful for us to be able to handle large numbers of events from lots of different contracts in a multi contract system the next one I want to show you is the idea of modular libraries so libraries in solidity if you're not aware already are a way of deploying code once that other contracts can use over and over and when you have a multi contract system or you're deploying a new contract for every iteration of something there's a lot of gas costs in that and if you can reference if you can link a library that's gonna save a lot of gas compared to implementing and compared to deploying all the contracts again so libraries are known as well-known to be to provide that gas saving mechanism and the idea of modular libraries is the idea that you can link multiple libraries together in order to provide some abstraction layers so these are all like architectural patterns for you to have more maintainable smart contract code so what does this look like the modular library is one in which the contract itself doesn't have to know about all of the different modules and so it's a way to encapsulate functionality within a library in order to have some separation now libraries are linked and all of the calls end up appearing internal so this doesn't actually provide is more of an organizational strategy and architectural strategy than changing the actual access levels so here's an example for the prism project we have a library called prism Lib and there's a lot of different pieces of data and libraries that have functions that operate on that data and as a way to break it into smaller pieces one good method is to have data instruct in each of the libraries that's defined in each of the libraries and then that can be included in the contract and so you have nested levels of data so the struct is defined you can see in the blue with the number one is the data struck and then that's being expected to pass into each of the functions so the rebalance function on the prism Lib is going to ask for the prism Lib dot data and then the nested nature is comes from the fact that portfolio Lib has its own portfolio Lib we can assume is that lit B it's being imported somewhere else so portfolio Lipp we can assume has its own data struct so portfolio Lib can be accessed the functions can be called in portfolio Lib and the data is contained within that Lib and so there's an abstraction there if you notice we're not passing the entire prism Lib data to the Reap to the rebalance portfolio Lib dot rebalance function we're only passing self dot portfolio Lib so the second red instance number two and so that way portfolio Lib dot rebalance or any other functions in portfolio Lib don't have to know about anything else in the data so this ends up being a pretty standard abstraction in hiding mechanism but something that we haven't seen a lot about in the wilds with library development but we found it to be really great really great architectural pattern for prism so now we get to the last of the low-level patterns and I want to share with you and this is a higher lower-level pattern and this is an idea that has been shared in other talks here the idea of the blockchain as a court system and this didn't come to me until much later in the development of but the opportunity to save a massive amount of on chain computation exists when you treat the blockchain as a court system or an arbiter which means that you assume that parties are acting in best best in good with good will and best interest but you have a mechanism that if something goes wrong if one party says the other is not doing they're not fulfilling their obligation then you can run an actual smart contract as if you're bringing it to court and when you run that when you execute that smart contract then you're using the blockchain to orbit to arm it that to be the arbiter of that transaction so what does that look like so here we have a contract this is just a general you have some users and there's going to be a counterparty the other end of the deal and they're using you're using the smart contract the naive approach would be to execute everything on the smart contract when you have arbitration built in then instead as AI describes you assume that both parties are acting cooperatively and correctly but you have the mechanism in place for a dispute resolution process so the top interaction here is where the user through the smart contract interacts with the counterparty there's not any execution there's really nothing happening there there's not code that's being executed on chain maybe just a hash that's stored that both parties can can use to evaluate off chain what's happening so user a maybe send some ether to the contract after a certain amount of time the counterparty is expected to send ether back or some transaction occurs and at this level it's really up to the counterparty whether they want to do that or not now if the counterparty doesn't do their part you have a time window a week a month whatever the time window is where the user can file a dispute and that's all on chain so there's a time window the funds are locked up and so imagine user B has a problem and says yeah the counterparty didn't do their job so they send a dispute resolution transaction and this time the whatever business logic needed to be executed which could be quite expensive is going to be fully executed and because it is deterministic the winner of the dispute will always win so the beauty of this is that the incentivization is such that if you know you're going to lose you you would never you would never do the wrong thing so the counterparty has zero interest and the reason you you force that incentivization to be aligned so strictly is that you say if if you lose the dispute you basically lose all of your money right so you punish the person for behaving against the expected the expected behavior and so when done right there's really no incentive to go against the expected behavior you have user a acting expecting a certain thing back from the counterparty of the counterparty doing their job the threat of the dispute resolution process incentivizes the counterparty to do their part and the beauty here is that you're not actually executing the full contract logic on chain it's just user a doing their thing and the counterparty doing their thing so I see this as a potentially huge pattern that can be used across smart contracts in order to optimize reduce execution time and this is something that could be put to good effect on a lot of projects okay how's everybody doing you still with me the developers are the developers are like yeah this is cool okay so we have some higher-level patterns and these are for you as well these are also for developers if you spend more than a couple years working in the software industry I hate to break it to you but you're gonna have to do some things other than coding you're gonna have to learn some other skills and some of those are going to be technical skills and some of those are less technical but what are the higher-level patterns that allow you to be successful as a smart contract developer not just when you're in solidity land but when you're working with your team when you're making judgment calls when you're making important decisions about the direction of your product that the rest of your team is looking to you for so one is something that I call role analysis this isn't a technical term but role analysis how do you analyze the roles in the smart contract and this is something that you can use this this is simply an approach to smart contract development and design and you can use it at any stage of the process so if you're designing a smart contract from scratch who is interacting with the system that's the main question you're asking here who is interacting with the system and what are their incentives and how does the behavior how are their behaviors going to derive from the functions that you exposed to these different roles so I use this both in the design process but I also use this throughout the entire career of the smart contract system when you're iterating and you're adding new features there's always going to be adjustments to the behaviors of the different users and the different roles that are interacting with your system so to be a really good smart contract developer you have to understand all of the roles of individuals interacting with your contract what their different incentives are and how that affects the overall functioning of the system right this is like the essence of the game theoretic nature of decentralized smart contracts so just some examples the prism contract for shapeshift prism has a few simple roles it has a buyer a seller and an Oracle and with prism the buyer purchases a contract a portfolio of different digital sets the seller is putting up collateral to ensure that those assets can be paid off depending on whether the portfolio goes up or down and then the Oracle is another entity that's providing the prices that determines the value of the portfolio so different roles and even these simple three roles have involved a high level a high degree of analysis on ongoing analysis to make sure that the trust implications are well understood as the contract develops and becomes more sophisticated another example is a salt loan let's say you were doing a loan that was backed by by digital assets that was collateralized by digital assets in this case you have a borrower someone who's borrowing cash and then you have a lender who's offering that cash but then locking up the collateral and in this case you have salt as a kind of multi-sig arbiter to make sure that if anything funky happens with the other two salt is in there and can have the last word this is an example from a talk yesterday the liquid pledging contract was really I thought really a brilliant idea to combine fund management with liquid democracy and here there could be many arrangements but a simple arrangement is to have a giver who's providing some ether and they want that to go to a to a good cause or a good project they don't have time to do that themselves or they want to trust someone else so they delegate that to another role and that delegate is gonna choose the project and eventually a reviewer is going to say yes these milestones have been accomplished and that goes through so this is seeming a simple concept but it goes really far and it really is what can separate someone who just knows solidity from someone who can design maintain and scale smart contracts on a live network context dependence is another skill that comes with experience and is something that is really valued on a team and by this I mean in analyzing when one action is true in one situation and the same action might not be true in another situation I know this is really scary for a lot of you I didn't get into development to deal with fuzziness and ambiguity either I love really straightforward and deterministic systems but the truth is any complicated problem is going to depend on a lot of context so one example in this space is that you hear a lot of best practices best practices are great but when they turn into hard and fast rules you can really miss out on the nuances of the situation so one I see a lot is sand versus withdraw patterns and and the advice out there is to always have the user withdraw never do a sand so there's like push versus pull never do a send and I actually don't like this advice because it's often just taken without much thought why don't we do a send well we don't do a send because there's vulnerabilities if you're trying to send to multiple people you have to be aware that any one person their fallback function could throw they could use up all the gas they could use up most of the gas so there's risks to sending to multiple parties okay I understand that there are also situations where maybe you don't want for the user experience they don't have another transaction you don't want them to have to do that transaction so maybe the send would be appropriate in those cases keeping in mind this dictum of it depends I had a professor in grad school who this was in my counseling program and it was beautiful every time anybody asked well what if you're working with this client and they do this what should I do she always answered she thought about it and then she said well it depends and that would be her answer every time so with skill and experience comes an incredible awareness of context so I encourage you to think about context dependence and lastly I want to say leadership in blockchain at the developer level because contracts are immutable technical debt is much costlier so when you're making decisions as a lead engineer you have to make a lot of judgment calls because that code might be on chain for a long time and that's something to keep in mind thank you so much I'm gonna share it go over the patterns just to name them we talked about central logging modular libraries and arbitration as architectural patterns at a lower level and then at the higher level I hope you can take some of these concepts away about leading your team being more dependent on context and then bringing role analysis to everything you do thank you very much [Music]