A Better Paradigm for Smart Contracts - Dete Shirley

foreign [Music] I'm dear Shirley and I'm going to talk about smart contract development um which I know a little bit about so I'm the Chief Architect of the flow blockchain I was also the creator of cryptokitties which you might have just heard us talking about a second ago um I also was the original author of ERC 721 that introduced the term nft to everyone and and defined how nfts work on ethereum as a co-founder of dapper labs and I helped design a language called Cadence um and Cadence uses a new programming Paradigm that makes owner ownership a language primitive and that's what I want to talk about today so I want to start by making the argument that whenever we have a new domain for software development that we it makes sense for us to come up with new programming language paradigms so I'll give some concrete examples here so in the early days of computers computers cost millions of dollars and whenever a new computer was purchased at that time they would write all the software up from scratch because the cost of researchers rewriting the software was cheaper than the cost of the hardware and so it seemed like a rounding error next to that but as computers got more common as they got cheaper suddenly rewriting and as the software got more complex suddenly rewriting the software every time you got a new computer started to seem very wasteful and so the whole notion of portable code came around that's the most popular uh version of that and maybe the most long-lived version of that is the C language itself which was created so that the portable operating system Unix which is probably the most successful software architecture of all time I think there's probably you know in this room there's probably I guarantee you there's more Unix computers in this room than there are people in this room um then when we introduced relational databases we had a new concept of atomic transactions um and so we had this new paradigm this new tool that developers needed to um to leverage in order to use uh this this new software domain and when we had graphical user experience we started to use object-oriented programming um and when we uh started to create web applications pervasive web applications we needed some sort of client side execution environment for Scripts and whenever we have these new paradigms what we see is people developing new languages to express these paradigms natively in the language and so portable code led to Fortran and C Atomic transactions led to the language SQL which we all still use today with object-oriented programming we had small talk and then later Java and for client-side scripting we had a whole new language JavaScript which um you know is probably one of the most used computer languages in the world right now and so you got to ask yourself is there anything in the blockchain world that we use all the time um uh Concepts that we use all the time that aren't well represented in programming languages and I would argue that there are two things one is managing ownership of scarce resources whether that's fungible tokens or non-fungible tokens whether that's your um uh your usdc or your cryptokitties um the fundamental aspect of those is who owns them and we need to keep track of that in our smart contracts the other most important thing we need to do is control access who is allowed to do what on the blockchain it's a shared Computing environment and if we don't have solid control over who can do what then the ownership doesn't matter if you can breed my cryptokitties together um then it doesn't matter that I own them if that ownership doesn't in part control then um the ownership is is perhaps somewhat meaningless so what tool do we have to represent scarce assets well the hammer um for every software programmer is a data structure a basic data structure in um where you bundle a bunch of data together and and move it around together and almost every programming language prior to blockchain has worked hard to make data structures more convenient they make them very easy to create it makes it very easy to copy them you want them to be easy to delete and Destroy when you're done with them the whole notion of garbage collection which is you know an entire research topic in computer science is about what do you do with data structures when you're done with them but think about your tokens whether they're fungible or non-fungible you don't want those to be easy to create the whole point of these things is that they have value and the creation of them is carefully controlled they shouldn't be easy to copy in the context of money when we copy things that's called forgery and we don't want that and we also don't want it to be easily destroyable you don't want a simple programming error to allow some sort of asset to just be deleted and destroyed so data structures aren't actually really good fit for managing the ownership of scarce assets but in solidity and even in wasm the only tool we have are basic data structures it is a pain the good news is is that there are lots of smart people thinking about this problem and here you see uh three papers there there are more but there are three papers where they introduce the notion of um of resources um in smart contracts so what are resources they're like objects you know if you're familiar with Java with the whole notion of encapsulation and um you know the programmer having the ability to to hide implementation implementation details and to have capabilities that don't necessarily expose to the users of those objects and they combine that with the notion of linear types which is a concept that was popularized by rust which is that an object can only live in one place at one time now the reason Russ did this was for memory management purposes um if you've ever used so most languages use garbage collection that works very well something like JavaScript it uses garbage collection go uses garbage collection but the rest developers said hey for certain kinds of programming problems garbage collection is very expensive its cost is very unpredictable and I've seen estimates as high as three or four times the memory put print of garbage collected languages rather than languages that do directly manage memory but directly managing memory is a pain in the butt that's why most languages don't bother making you do it and so what Ross did is it said look we're going to make sure that each object that has been allocated on the Heap that it only has one reference to it at any given time and so when that reference goes out of scope we know that they're done with that object and we can free it up and we can save a ton of complexity now it's funny because when they talk about memory management they talk about who owns the object right in in smart contracts when we talk about who owns it we mean something of value in the beneficial owner of that thing and when you're Pro most programming languages when you talk about ownership it's who has the responsibility of freeing up the memory but it turns out that learning your types that solve that ownership problem of who's supposed to free up the memory can actually also solve the problem of who is the beneficial owner of a scarce asset and so if you take these concepts of object-oriented programming and linear types and you combine them into resource-oriented programming you get something that has carefully controlled creation um In Cadence to only create way to create a resource object is actually in the smart contract that defines that type that smart contract can of course have other functions to allow the creation of instances of that new type but it's not you can't just go along and say you know new cryptokitty it's not a data structure in that sense resource objects are uncopyable that's the fundamental essence of linear types and destruction is very significantly deliberate um if you have a resource on the stack if you're passing it as an argument to a function and that reference to that just goes out of scope that's a static error and that the the um that code won't even compile you can't even upload that code to the blockchain it makes you either explicitly destroy that object or put that object into storage somewhere or pass it to a function that consumes it so we've solved the problem of how you track ownership of scarce resources we make a scarce assets you make these resource types they have direct ownership tracking built in the language itself and now we have this notion of ownership as a language primitive in our smart contracts but what about controlling control what about giving controlling access to those assets well that's where you get this idea called capability-based security anyone who's looked at agoric and the work of Mark Miller may have heard this term it's also called the object capability model the basic idea is is that you have your access is based on what capability you have and capabilities are they're kind of like secure channels right so if you connect to a website you might go through an authentication process and from then on that connection allows you to do things as you you don't have to keep re-authenticating it doesn't keep checking who you are you just keep reusing that same connection um it's often talked about security by what you have rather than who you are and it is an alternative to access control lists but when people think of security by what you have they often think of like a key card right like I go up to a door and I I slide the the key card in and that's what gives me access capabilities when properly implemented actually are more like a remote control it is the very thing that you hold that lets you do the thing and by not holding it you can't do the thing and so that's a really powerful way of doing security because if you don't have it you you can't even call the function it's not like you call the function and it rejects your call um because you're not the right person or you're not on the right Access Control list you literally can't call the function because you don't have a reference to the object that implements it and this allows for really powerful separation of concerns it means that you can have a single object or multiple or um you can have multiple objects each which have are within the same scope right um but um which have more which have different abilities different capabilities on them so give a concrete example of that I my account might have the ability to Mint an nft and it might also have the ability to draw money out of the smart contract that sells those nfts but those two capabilities you know and if you were to do it in Access Control this way you'd put my my account on a list and you'd say Hey you know Dieter has the ability to Mint and Dieter has the ability to pull the money out you know what I'm talking about Sorry by the way everyone this is can you stand up this is Fabiano Fabiano was one of the other developers on cryptokitties there were three of us um and um yeah he's he's royalty um uh he he uh he wrote the code before I even started working on cryptokitties so um uh anyway the so if you do that through an access control list I now can't delegate the ability to do one of those things without delegating the ability to do both of those things because as far as the smart contractor is concerned there is one address which is allowed to Mint and also that same address is allowed to take the money out but if I have a capability based system I can actually take the object that lets me mint and I can hand it to another person I can hand it to another account I can hand it to another object and I know with certainty that it won't be able to withdraw the money because I'm only giving it that capability to Mint it further allows greater flexibility giving examples of like what I just said and it's much much easier to audit because you know that no one can call this function unless they have the object and if you don't give them the object they couldn't possibly call that function by the way that's not just an assertion um I actually should ask the Quant stamp people to come uh to to these things we've talked to people who do Audits and we've had them talk to them about capability-based Security in particular and they really find it makes their jobs much easier so this one construct these resource types they seem to solve these two problems that are introduced in um The blockchain Domain very neatly and so that's one of the reasons why in our flow blockchain we implemented a new language called Cadence that is resource oriented and so we have this new domain smart contracts we think the new paradigm for implementing these things is resource oriented programming and we've introduced a language called Cadence that has thousands of users that implements all of this natively into the language it's got beautiful syntax Empire inspired by Swift and it's intended to allow much more powerful and complex smart contracts with fewer bugs fewer complexity and fewer security problems but wait there's more because resources are data structures that have all of these limitations on them and their objects you can attach objects to objects and so resources can own other resources and in particular nfts can own other nfts now this is close to my own heart as the developer of crypto kitties because there was a project called Kitty hats that came out soon after cryptokitty's launched where you could dress up your cats and it did that by assigning to using ledger-based ownership where it would say hey this hat belongs to this cat and so if someone sold that cap the the Hat ownership would would stay associated with the um with the cat but we can do one better in this resource-oriented model we can actually have it so that the nft that represents the cryptokitty could have a list of other objects associated with it and as those elements move then that the ownership moves through transfers that data that's attached to it moves with it and if I can add more I can add a resource to your resource if uh let me let me put it this way the control of adding new attachments we call them attachments the control of adding attachments to existing resources is in the hands of the owner of the resource not the author of the smart contract that Define the resource so as the creator of cryptokitties we don't get to tell you whether or not you can put a hat on it as the owner of the cryptokitty you can decide whether you want to put a hat on it and so the author that creates the Hat smart contract says this thing is a hat it can attach to a cat and then the owner of the cat can decide whether or not they want to attach the hat but once it's attached it those things move together as a unit and it doesn't have to be a habit it could be state it could be here are your cat stats in this RBG here is a list of win loss records in of your cat in this battle game and it allows for a level of composability and extensibility that is very hard to do in other contexts so you can see this happening today on the flow blockchain at developers.flow.com there's a link there to let you try Cadence we have a playground that runs in the browser so you can play with the Cadence language and see what resource-oriented programming looks like and see how it makes a smart contract code much more intuitive and easy to uh Implement and understand so I have time for questions does anyone want to ask questions yes um so so we have a construct built into the language called capabilities um and um the way that we originally implemented capabilities was this is it's going to get a little in the weeds but let me try this okay so um when I give you a capability right the simplest version of that is just to give you a pointer a reference to the object the problem is is that that is that's very dangerous so imagine I decide that um I'm gonna sell you my crypto Kitty um so what do I do I take a reference to it I take a pointer to that object then I transfer that object to you so what we can't have is is that the reference follows the object as it moves around the other problem is is that what we didn't want to do was have the references be non-revocable by default right so you can always wrap it in another object to make that you know have a forwarder and you could disable the forwarder and if you read Mark Miller's work that's what He suggests right you create this um this intermediate object instead of me giving you a reference to let's say I want you to have the ability to withdraw some money uh from my account I don't give you a reference to the vault in my account I give you a reference to an object that has an access to the vault in my account and then I can disable that interim object um but if I forget to do that I'm really screwed right um and so what we wanted to do was sort of force people to have the this interim object and so we would have them create this thing called a link um and it was very confusing they're trying to understand capabilities they're trying to understand what they are and then the first thing you have to do is create something called a link and you don't even know why you need a link right because we want to be able to unlink it um and so we're actually rolling out a new feature now uh called capability controllers where when you get a capability under the hood it creates this thing called a controller and that controller lets you disable the capability after the fact and so you don't have to explicitly create the link but that was a that was a huge area of confusion and it was because we had to introduce these two concepts together and when you're first learning it you don't necessarily think oh it's critical this thing is can be disabled at some point in time and how do you even get a reference to it to disable it if you've handed it off to somebody else great question anybody else go ahead uh as a Developers um yeah I mean the I mean the costs on Flow are very low right now um because uh like any network that's underutilized you know the the rational fee is very low um and at some point in time those those costs are going to go up we've done our best to make sure that we're providing a fair cost right where the the cost of executing code is the same as the computation cost of executing the code in like in terms of the transaction fees um and so then then onus falls on us as developers to make sure that the execution effort um is low for the kinds of constructs that we want to see um and so um I think that in terms of well in terms of load on the execution node that's actually executing the transactions um I think that um there's a lot of stuff in flow that is would be cheaper comparably um than than things that are happening on other blockchains especially things that are um uh computation based um certainly querying the contents of an account like on ethereum if you want to know what you own you have to go look at every single smart contract and see if your name's in it or your account address is in there on Flow what you own is literally in your account um I guess it's more of an off chain query anyway but um it certainly means that you can write code that does things like iterate over your like the like transactions that actually iterate over the contents of your account which would be kind of infeasible um on ethereum but um the one thing that is not that has a little bit of an extra cost is that if your resources are um uh large like in terms of their bite size actually transferring ownership can start to get expensive because you're literally copying data from one account to another account um now that does have the advantage that the cost of storage is borne by the person who owns the object uh which which is very nice um but I think that um being thoughtful about how big those data structures are really important and doing things like in topshot what we do is um for every what we call addition right which is um a particular play in a particular game that data is all stored once and then referenced from the individual nft so the nfts have some of that data right like the I you know the serial number and the mint data and all that stuff is in the nft but the share data like what's the player's name and what was the game and the score of the game Etc that can be shared in in a central smart contract anybody else who had time for one more security practices are low yeah that's a tough one because what what we did was we learned from an another project that I worked on Fabiano with is a project called cheese wizards um cheese wizards was um it was a game it was literally a game that ran entirely on chain um it was the simplest possible game because it was literally rock paper scissors and and it just about killed us because solidity is um it's a very arduous language to do that kind of logic in um and so unfortunately my answer is mostly we learned a bunch of stuff about solidity that had us improve both the language Cadence that I was talking about here but also flow like the um the whole account model um and this notion of capability-based security where um you know the you know I think one of the the biggest problems that comes up in um in the ethereum context is people sort of granting access to um people or smart contracts um and not knowing what that smart contract is going to do and not understanding the limits of what that smart contract can do with that access um and that's something that we've really explicitly tried to make easier In Cadence unfortunately I don't really know how to how to make those those lessons go the other way because um at the end of the day we decided to build a whole new language because of them so yes absolutely but of course of course and and you know one of the things we'd like to see is other uh projects take on Cadence so Cadence is yes it is written as part of the flow blockchain but it is as a language can be executed in other environments um in fact the team was very careful to build the Cadence execution layer as an independent entity and can be run independently a flow so I you know it's quite possible we'd see someone maybe the lesson should be that there should be a roll up on uh on ethereum that runs Cadence laughs all right uh well thank you everyone I appreciate you uh coming and listening to my talk