5 Smart Contract Patterns I Wish More Devs Would Use

foreign [Music] and this talks talks about like five smart contract pattern but that's actually a lie the real thing I want to discuss is what I think are it's a good mindset when writing solidity contract and basically the pattern I'm going to show you are more of like examples of what I think can be a fun development and solidity and how I think it aligns with the good good development practices wait distance okay yeah so I think one of the two main points I want to make today is that a lot of the ecosystems value is a result of smart contract composability uh that's particularly true of defy and the first thing you should do when writing a smart contract is make sure that you are leveraging as much composability as possible and trying to make sure that your contract can interface with all the existing tooling that would be relevant an example is people always ask us like hey can we make an honorable contract payable like someone could buy it and this makes really no sense because there is already a lot of tooling for buying assets and that's the nft space in the nft space you can just buy anything from openc or variable or any other marketplaces and we don't want to redeploy that for for the NF for the ownable contracts that that exists so the idea is that when own ability is just like the ownership of of a contract in order to to have access to it to some admin functions well you could just turn that into an erc721 and and this is how you would do it basically you can very simply say like hey my owner is just the owner of a specific token on an ownership registry and I can have a normal owner modifier for that and when I want to transfer ownership the only thing I will have to do is go to this ownership registry and try to transfer as a corresponding token no on the ownership registry you would have to override the either approval order function to allow that but that's very easy to do and so here in this example you have a basic Factory this is actually live on mainnet and when you want to deploy a new vesting wallet with a beneficiary for it well here's the beneficiary it's just the owner of the nft on this Factory and when I deploy a new contractor just create a new clone I initialize it and I mean the token and that's the equivalent of my owner if the contracts were ownable the difference is here my contract show up on openc and I can basically sell it or transfer it very easily uh if you want to go a bit further you can even have like a universal address ownership registry which I think is pretty fun because it allows you to get rid of the minting part uh by just saying that hey by default all the tokens are already minted and they are owned by the address that corresponds to the Token ID I mean all the token ID that matches an address in exactly smart form and then you can just say that hey it's not possible to burn them you would just send them back to the original owner and there is this is approval ownership that I'm doing some fancy stuff with codes but you don't need to care about that and and this can just be another approach I think it's nice and it it shows creative use of your season 21s um and another thing we use is that ownable obviously is something that a lot of people are familiar with but the granularity is really bad uh sometimes you have different admin functions in your contract that you want to have different access for and access control does that pretty well access control is provided by open Zeppelin the thing is that access control is maybe a bit more difficult to work with because you cannot transfer a world you need to Grant it to someone else and then either get it revoked or renounce it and so it's very nice for some users but at the same time own ability has some advantages so let's just combine both let's just make a contract that as an owner and the owner is basically the default adminual and then you just cannot Grant or revoke this default admin order because that's controlled by the ownership part but the owner still is the admin so it can grant any other one and this here it's ownable but it could be the ownable registry official just before so you could have a contract whereas the owner is the nft orders and then you have all these access controls that are managed in that way or you could be creative and use ERC 1155s here and so yeah that's that's just some small ideas but it's not very complex good I think everybody can understand that but the point I really want to make is that you can combine tooling together and combine contracts to make sure that everything is as basically as seamless as possible the second thing I want to to present quickly is that the ecosystem is constantly changing and and basically when you write a contract I mean you can make your contract upgradable but even without the upgradability part you really need to care about what is going to be the life cycle of my contract and are there Small Tricks that I could use that will make my users life better in the long run and that's for the users but also for like the UI designers or and basically anybody in this space so these are just two small pieces of code like 0.4s and five that I came up with very recently and I think that's that's things that are are interesting because we never expect a hard Fork to happen until it actually does and people start trying to do a proof of work blockchain and then the bridges that are on this proof of work chain starts breaking and that's a pain so you could imagine having this very small piece of code here that basically takes no size on on chain that just gives you two modifier that verifies that the chain ID that you're currently using is the one that was registered in immutable storage when the contract was deployed and then you could do that to create some kind of bridge where actually most of the function remains completely trustless with this only initial chain modifier but if for any reason uh there were to be hard Fork the version of the bridge that is on the chain that changes the chain ID then all those would be automatically disabled and you get into recovery mode when some like multisig would be able to take over and this multi-seek is not a threat for the user on the legitimate chain because because of this only fork chain like this admin cannot do anything nasty to your users but that's that's a mixing point that would have saved some pain I mean it wasn't the proof of work chain so maybe we don't care a lot but who knows maybe there will be more legitimate Forks at some point in ethereum's life cycle and another one is that that's something we provide as open the screen and that's what we call the multi-code contract and that's very simple it's just one endpoint one small functions that allows you to delegate to yourself with an area of data and that's very easy for you to integrate into any of your contract and I don't think there is there is any reason not to do it and the way it's being done is earlier we saw this example here and here you have this multiple that maybe you didn't see because it's red on black so it's not really visible but what it allows you to do is when you went to create a new vesting for one of your investors or someone when if you have 10 or 20 investors maybe you don't want to do 20 transaction that do 20 calls to this new wasting function so what you do is just that you encode like you have a map of entry and you record the function using like e server.js or F3 of whatever you like and then you just have to do a single call so there is a single transaction here that you have to wait for in order to do it will basically run like all these these operations so deploy Trend investing at a time or you could do an approve and some something else or you could batch transactions together like you don't need to wait for Icon abstraction to batch transaction you can already do it at the contract level I mean providing that the target is the same contract for all the subcodes and that's as simple as including that so yeah it keep in mind that there are always this nice tricks that could possibly help your users down the line and I think it's it's important to have that in mind when building contracts and try to be creative that's it [Applause] yeah so I'm going to repeat the question for for the stream and the live and uh the question was about like can access control be used for smart toilets is that that's it basically I think uh well uh it really depends what's kind of Smartwatch you want to build um there are different kind of smart wallets if it's just something that QRS sole owner of I'm not sure it brings anything new to the table uh but if you are doing a multi-sig maybe it will be relevant I mean my opinion is that a time lock for example is a kind of North wallet because it's just someone that will manage asset and do operation with three specific rules and in the open zip time lock we use Access Control to separate the role of the proposers from the executors from the admin that may have the right to cancel potentially so yes if you are building a multi-cig and you want to have different privileged access maybe I think an overseer that is able to recover in case of of issue having signers having proposers that basically you're turning your emergency into some governance mechanism which which it basically is what time will see is a governance mechanism so yes you could use Access Control uh hey uh in an example with a multico that you've shown we are deploying the same method like a byte code for this method in every contract wouldn't it be better if we have it deployed separately yes it would but it's not possible right now so like if we had a EIP 3074 live we could just have this make use this OS and oscore mechanism to do batching transaction and and you would not have to include that in your contract the thing is that this is not available now it will not be available until at least Shanghai and maybe later so I think the bytecode increase is is really small compared to the the value that is added to your contract right now but yeah in the long run hopefully we would have already supported at the at the execution level later hey uh great talk by the way uh in the ownable ERC 721 part you were talking about how you could basically ditch the ownable the ownable library right what what advantage I I kind of missed the point of like what's the advantage of implementing the ownership inside the erc721 logic instead of just bringing ownable is it just like byte code size or is there any other advantage that I'm missing no the weird advantages in in composability so examples for example your your own Apple contract it could be tied to assets maybe you would want to consider that as a class of its own that you would be able to land against collateral or maybe it's uh maybe it's like a vessing wallet that is basically a future uh financial future that you want to sell on unisa on openc uh right now you cannot sell a non-able contract on openc but you can sell an nft so the way here is to make sure that your contract is compatible with all the tooling that exists out there openc and others also just being able to see the ownership in your zirion or any palette you'll use that's also something nice thanks thank you