• Recordings
• Notes
• Nick Mudge
• Diamond standard intro
• Why Beanstalk uses the Diamond standard
• Other Diamond features
• Transcript

Recordings

Notes

Nick Mudge

• Background in software development. Got into Solidity, smart contract development, DeFi and NFTs in 2018.

Diamond standard intro

• Allows you to use a single contract for interfaces or other systems to interact with, instead of multiple contract addresses.
• Provides a way to upgrade a smart contract system over time, to add or improve features after the initial launch.
• Lets you work around the size limit of smart contracts.
• Introduces transparency via an event that is emitted so that third parties can track upgrades.

Why Beanstalk uses the Diamond standard

• Using many different contracts with a lot of cross-contract calls costs a lot of gas, and with the Diamond standard all the various parts of Beanstalk can be moved into facets and eliminate those calls.
• Users only have to interact with a single contract address to access all of its functionality.
• Upgrades are easy and straightforward.

Other Diamond features

• Introduces a common architecture that can be used by many different projects, which would make smart contract systems more approachable and easier to get up to speed with. Documentation helps a lot.
• Facets can be reused across projects, so a project can use functions from an on chain facet that’s already been deployed in another Diamond.
• Looking forward to people using deployed facets as libraries, similar to OpenZeppelin contracts now.
• Could be a plug-in system of already audited and battle tested facets for often used functionality, like governance or erc-20s.
• Standard contracts can’t list their available functions, but with Diamonds you can query their functions.

Transcript

welcome to the beanpod a podcast about decentralized finance and the beanstalk protocol i'm your host rex before we get started we always want to remind everyone that on this podcast we are very optimistic about decentralized finance in general and beanstalk in particular with that being said three things first always do your own research before you invest in anything especially what we talk about here on the show second while you're doing that research try to find as many well-developed opposing viewpoints as possible to get the best overall picture and third never ever invest money that you can't afford to lose or at least be without for a while and with that on with the show [Music] the development of smart contracts has opened up an entirely new universe functionality on blockchains these smart contracts are really the reason that decentralized finance can take place at all they allow for automatic executions that don't require outside parties or human validators making the process efficient and trustless developing and working on smart contracts however isn't without challenge as contracts become larger and more complex staying within technical constraints like contract size limit is more difficult additionally fixing problems and making improvements to large contracts is challenging a process that could be improved by modularizing the contracts and being able to make adjustments to individual components in 2018 a solidity developer named nick mudge was facing just such difficulties in response he developed eip 2535 or what's now known as the diamond standard processes written using the diamond standard externally appear to be a single smart contract however beneath that single address can lie a number of other contracts called facets each of which can have their own requirements and functionality now a week before the governance exploit in april publius and i had the opportunity to interview nick for the podcast because of the attack that happened just a few days later this episode was set aside but we loved talking with nick and are excited to release that interview now also one more quick item of node during this episode you'll hear multiple publius and because it was recorded before the exploit and their subsequent self-doxxing you'll be hearing them using their voice modulators so for those of you who miss their old school robot voices you're in for a treat and we hope you enjoy it publius welcome as always thank you rex really looking forward to having a conversation with nick today and um exploring the eip2535 standard and nick thank you so much for joining us welcome to the pod thank you glad to be here to start us off you want to just tell us a little bit about yourself and the work that you do yeah sure so my background is in software development i did that for many years and then in 2018 i got into solidity development and smart contract development and nfts and d5 stuff and and uh just you know made stuff i have worked on projects and then worked on the diamond standard sounds great and so for what it's worth could you explain the diamond standard to me could you give me that eli 5 explanation or eli 5 explanation of the diamond standard sure i'll try to do that uh you know it can be sort of used for different things but so i'll sort of talk about the common case that that i see the common k the common cases for it essentially it's um it's a way it's a smart contract pattern or architecture that is used to solve certain problems and make certain things easier so specifically when you deploy a smart contract there's a limit of how much functionality that contract can have so if you deploy an nft okay you can do a bunch of stuff but then that's it and then you deploy another contract which is fine but in some cases you may want to deploy something and then or you might want to deploy something large but it's that one contract and so the diamond enables you to do that so you can you can essentially have one contract with unlimited amount of functionality in that one contract and then so that that provides some benefits like if you're going to make a user interface you know it's easier for you to use your interface to connect to one contract rather than five different ones for example or you know you're going to be interacting with having other systems interact with you if you can provide them one contract address that's easier than more so that's an example it provides um another aspect that's that's used in some projects they might want to launch their project and get it in production and get going and however they don't they they want to initially build something useful but it's not everything that they want to do like they maybe they want to launch and get user feedback and experience what their project is like and then you know then later they realize they want to expand their system there's features that their users are asking for etc so the diamond provides a a standard way to uh upgrade a smart contract system uh over time that and it can grow um it is large as as needed so whereas you know if you just there are upgradable contracts but typically other upgradable contracts again they run into a size limit you can have one contract you can upgrade it add more functionality but then there's a limit of of how big it can get and so those are a couple of things it also adds some transparency into it so that you know if there if you do make a diamond that's upgradable there's an event that gets emitted a standard event that keeps track of what um what's been changed and and so then external people can can look have that that that chance to look at to see what's that you know it's transparent you can see what how it's upgraded over time so nick it sounds like you know based on the functionality and you know the kind of dynamic nature of the diamond standard sounds like you were trying to to solve a specific problem was there a a specific instance or something that you were working on at the time that kind of presented itself and showed the need for this this greater flexibility in terms of updates and this this ability to manage contract size yeah so in uh 2018 i was working on another standard called erc998 and this is the idea of an nft owning another nft or owning erc20 tokens and being able to control it so and developing that standard i implemented a reference reference implementation and uh and i made my own project it's called mokins.io and it's um still out there on the internet but uh these mokins were nfts that could uh own other nfts other erc721s and you can own erc20s you can transfer these things in you know into mokins and out of them and and things like that so anyways when i was when i was implementing that i ran into the maximum contract size limit of a contract i had the smokins and this nft contract i was implementing you know the standard uh for nfts at the time seven uh seven two one i was um doing the um uh the composable stuff the the erc998 and i was also adding some custom functionality and it just got too big and so then at that time i started looking for solutions to you know in this case having an nft it didn't make sense to have multiple contracts for an nft i wanted my nft to exist in one contract and its functionality exist in one contract um so that's really when the problem presented itself when i looked around and um looked for solutions and and um and then i started working on that problem and uh yeah so and then so then also in 2018 i um released an early version of the diamond standard it was a it was um had a different name it was an earlier iteration of it and uh later got replaced by what we have now the diamond standard but uh so i started working the problem in 2018 and got feedback from people in the space and got um experience with it and so really when when the diamond standard um was that that stand was first released in uh in 2020 um there's already been you know i'd already been thinking about it for two years and working with it and dealing with it uh there's some couple projects at least that had it that had um the earlier standard in production um so but but also you know so that originally was to solve that max contract size limit so you have a contract with unlimited functionality but then then but then there were other use cases that i found out about that were useful like for example it provided a a code structure a way to strike if you have a lot of smart contract functionality it provides a structure that's um that that's pretty applicable to a lot of domains you know you could create deficits a way to organize your code with how the the smart contracts work and how the evm works and things like that it just so it provides that that as well which is i which is what i find useful so it sounds like you're originally looking at contract size managing contract size adding functionality and it almost sounds like that ability to work in multiple facets was kind of an incidental or unexpected opportunity that you discovered is that is that correct yeah yeah yeah we found that you know you could put common functionality into a single faucet and really organize your or your code base uh that way where you know common functionality goes together and so yeah you have this nice separation of things and then a way to share data between them um is part of that is there anything else that like through that process that you either you know kind of change your approach about the problem you're trying to solve or on the other hand change your understanding of like the ethereum source code through the development process well i'd say that before the diamond standard i i really didn't use solidity libraries um i just didn't really have that much need for them but i found that solidity libraries work very well with with a diamond um specifically internal functions of solidity libraries this was because you can write absolutely library you know with bunch of functionality once and then for different thoughts of the deposits of the diamond you can import that library and re you know reuse it so that was found to be pretty pretty useful as a sharing mechanism also you know i think it's um around sometime in 2020 or or so um there was a change to the solidity compiler which made a new way to store data and contracts possible which is you know now commonly called the diamond storage where you can enable you to choose where to store data in a contract anyways it turned out to be very useful for these proxy contracts and for the diamond um and the anyways that helped with the code organization and and things like that um so so using silly libraries and the diamond storage were both very useful for diamonds and i think for proxy contracts in general it's really interesting so next question i have really is i'm going to throw it to publius first and then nick we'll see if you have any additional thoughts so when we think about beanstalk protocol publius why does it matter that beanstalk uses the diamond standard how does that affect user experience improve functionality etc great question so you know a lot of it kind of stems from things nick said earlier specifically you know things like the fact that facets can share functionality through libraries and the fact that you know beanstalk truly is just one contract in earlier iterations of beanstalk before we were fortunate enough to kind of discover and use the diamond standard beanstalk was a collection of separate contracts which is fairly standard for large protocols and all of these cross-contract calls between these different contracts costs um you know amount of gas and that amount of gas is non-significant and beanstalk with all its different interoperable parts has a lot of cross-contract functionality so with the diamond standard we can move that cross-contract functionality to these libraries such that each facet can individually include all the functionality while being able to code it in a clean and readable manner instead of having to make these cross-contract calls which you know add significant gas to overhead secondly the beanstalk contract has just one address for any user that's trying to interact with bean stock or build some kind of protocol on top of beanstalk it's very easy for them to just attach the beanstalk avi which is the interface to which you interact with beanstalk to the beanstalk contract address and then instantly be able to access all of beanstalk's functionality if beanstalk was say five six different contracts users would have to independently attach the abi of each specific contract to each address and you know that can kind of become a mess and get very confusing thirdly from a development perspective upgradeability with the diamond standard is incredibly easy and straightforward this has allowed us to kind of develop faster and be able to be confident with bips and anytime we deploy upgrades you know kind of really understand and feel comfortable that all the functionality is going to change as we expected upgradability across multiple contracts becomes kind of you know a bigger more challenging problem to make sure all the contracts references to each other are updated and with the diamond standard this problem is completely alleviated there's also the thing where if you have an upgradeable contract and it's large and you want to make one small change to it then with you know with the nor typical upgrade you have to redeploy the whole thing which can you know well with a with a diamond you can just deploy just that function or just that set of functionality um and not everything so that's a nice thing yeah as a non-technical expert what i hear is that ability to utilize kind of this modular setup to make changes or improvements bug fixes etc in a way that a gives the developers kind of a smaller package to work inside of and b sounds like it can be managed somewhat separate from the core functionality you know you're not necessarily putting other components at risk or uh potentially adding complexity where you you don't need to in terms of having to redeploy you know an entire protocol yes yes and you know every case is sort of uh in you know it's case by case uh in that like i think in some cases some upgrades you might upgrade something in it and that upgrade just touches a very small amount and so it's easy to think with and other great you know it barely depends on case by case like some upgrades might be you know touching different data that's used different places so but it it is true that the the diamond on the upgrade thing it does help separate different parts that are going on so you can kind of you can think on smaller basis to some degree when you're doing upgrades which is helpful so we talked through kind of a couple of really key functions of the diamond standard if nick if you were pitching this idea to a developer besides the contract size management and the the modular capability of the faucets are there any other features or components that you would want to say hey don't forget about this you know this this standard can do this other thing too yeah so there's a lot of aspects to it and i sometimes forget about parts of it and wish i said hey what about that you know uh so like i might do that here i mean one other aspect is that um you know with a diamond it's really an architecture that's pretty general purpose to solve i wouldn't say any problem but a lot of problems a lot of things you can implement d5 protocols nft systems integrations with things and so it provides but as i said it provides this this common structure this common way of thinking that's workable and so what what's what's useful about that is that you know you may develop the system have a couple of developers and it's good for if you're going to hire future developers you know now they have to get familiar with their system if it's a diamond there's what there's a already lots of documentation about how diamonds work so there's material they can study and then if they're already familiar with with you know the diamond architecture that pattern and so on it'll it'll bring them it'll be a lot faster for them to come up to speed with your system because there's a problem if you know if there's a um a project and they do a completely custom system and it's like completely done their own way they hire anybody that they have this this this time where that where they have to come up to speed with it become familiar so um the diamond sort of documents if you do a diamond your system is already halfway documented for you with with how the diamond works so there's that there's that kind of benefit there um and then let's let's see i'm sure there's other things there's um tooling is a thing where um there's um there's a website called looper.dev which if you put in a diamond address it will show you all the faucets and all the functions and of of any diamond and then you can call the functions on on there um there's i i just there there's already some tooling like people have made tools specifically for diamonds um and i see that it's coming more in the future where they'll just be like integrations and things that work with diamonds because it's a standard nice so next question is more directed at publius beyond the the functionality that we've already talked about a little bit up to this point was there anything else that drew you to implement beanstalk as a diamond and right along with that like let's say that we were able to you know hop in our time machine and head back to you know let's say thanksgiving two thanksgivings ago would you approach that implementation differently so you know nick it's funny to hear about your experience with you know kind of the contract slides limit and it seems like you know every solid solidity developer has that experience where you know they're building their first large protocol and they're just developing developing developing and then suddenly they're like you know see that error contract size limit reached contract too big and you know you're a little bit like what's going on here like it's not a problem that you run into very much and you know other disciplines of computer science but it is one that you know you don't really realize the thing but it's really influential and how it has kind of shaped the direction in which smart contracts have headed um and you know kind of got to the point where you know we were you know working on dividing beanstalk figuring out how we architect it while also figuring out how to you know make it fully upgradeable from a governance perspective and you know was reading a number of articles and landed upon you know one of nick's uh blog posts about eip2535 you know very soon dove into it and you know read up more about how it allowed you to you know divide up functionality by faucets while kind of maintaining the same contract and to nick's kind of point about how it's kind of one generalist generalized purpose solution to all kinds of protocols you know the more we kind of said oh well can you do this for instance you know state management um you know within contracts obviously they need to manage states you know the balances of users the state of the system you know bean stock the season number the weather the pods the number of stock et cetera and you know the diamond storage makes it very easy to share that state across different facets where if beanstalk were broken up you know the fields facet would have to call the season facet to get the season number which is a cross-contract call just to access a state variable but within the diamond architecture you can just define one state add that state to all the facets and then boom all of the facets are sharing state variables and can share functionality through libraries and kind of once you get over that initial kind of learning curve of you know okay this is what a diamond is how do we use it and to which you know nick just have to say your documentation is impeccable it's truly world class and you know it's funny because the deeper we dove into diamonds the more it was like okay is this possible with diamonds and it's like oh just look on nick's block he's got a whole article about it so you know kudos to you for really firing away on that and you know making it very easy for us to use and you know kind of once you wrap your head around the diamond you're like i don't even want to go back i don't ever want to have to try to you know break apart a smart contract into multiple contracts and you know kind of over the course of the last few months we've onboarded a number of developers onto the beanstalk farms back end dev team and you know at first glance they're kind of always like what is happening here and then you know we always check in with them you know a week or two later and we're like you know just curious what are your thoughts on the diamond and you know they all kind of have nothing but you know astounding good things to say so you know it truly is a better development experience it helps us stay more organized it makes it easier to play upgrades like we said and you know how easy it is to deploy upgrades you know allowed us to facilitate you know upgrades via governance in the base functionality of beanstalk you know upgradeability completely decentralized fashion is something some protocols struggle a lot with but we were fortunate enough to just have the ability to just call these diamond cuts and you know to next point earlier the tooling around it is incredible you know in this diamond repo there's just a deploy script and you just enter the facets you want to add and boom it deploys the facets you know submits the the upgrade request and you know that's that so you know truly from an efficient development perspective and providing our users the best user experience and cheapest user experience from a gas perspective we believe that you know the diamond is at the forefront and you know never want to go back that's really awesome and i really appreciate you saying i'm really glad to hear that i always really like it when you know when i when i put out some stuff out there and then you know there's some people that really get it and they run with it and and so and i'm always very happy to see that and so thank you if there's one thing that i never get sick of it is listening to publius absolutely geek out like in in for for both publius i can hear that in both of your voices and it always makes me smile i always get to hear that um so i'm sure they will edit that out that's just fine um so nick when you look at the broader ethereum ecosystem what are some of the projects or integrations of the diamond standard that you've seen since implementation that you look at you're like wow that is so clever or well i hadn't even thought of you know that particular use case can you walk us through a couple examples that have really caught your eye i'll just say that one of the things i'm looking forward to is um is there's another aspect of this diamond thing is this idea of reusable deployed faucets where you know you you deploy a faucet and it can be done such a way where the faucet is reusable that means that you know someone can have a diamond and they can add functions from the faucet to the diamond and someone else can have another diamond and they can use that same on-chain faucet that's already been deployed in their in their diamond and so i i'm seeing this a little bit already where some projects internally where they they want to be able to deploy different diamonds and they're just reusing already deployed faucets that they've created and they're just doing this internally for their project but i see a future where you basically have a deployed faucet library um and um you know where you know words this is because right now we're used to solidity libraries or you know smart contract libraries like open zeppelin where it's you know we have the code and we just reusing the code but i'm excited about this idea of projects starting to deploy their faucets um on chain and offering them as an on-chain library for people's diamonds and this is kind of i heard someone well i guess this is an example i heard someone call it plug-ins for smart contracts um recently and i thought oh yeah it's a plug-in systems for for smart contract you know you have a diamond and then you can you can plug in different contracts into your diamond to provide functionality so i'm looking forward to that that's some that's something that i see a little bit of and i i i'm not surprised i'll see more up but it'll be a good use case for diamonds as well i don't know any other um architecture really where you can do that other than i guess so with external functions with solidity libraries but anyway so that's something i do see people doing things um i i mostly i really tend to more respect and admire the projects that have taken the diamond and have done a good job with it um and you know um like uh like beanstalk and there's some others and you know as far as helping the diamond standard that's one of the best things that a project can do is just is use it and be successful and i love and i'd love to see that that uh you know notion you mentioned nick of kind of you know on chain facet composability is is super awesome can totally see a future in which you know it's like you deploy a diamond oh you want a governance system implement this governing facet you want erc 20 function you know token functionality implement this default eoc 20 token facet you want staking functionality add the staking facet and you know that way contracts can compose themselves of you know even already audited on chain code which will make it a lot easier for you know contracts to guarantee security and you know hopefully will lead to a lot less bugs and you know just general optimized contracts across all of aetherium so love that idea yeah that's fantastic bubbly so you kind of took the words right out of my mouth i mean i was thinking as nick was talking first of all the the thought the term that ran through my head was plug and play so plugins right along with it and then yeah publish you just hit it you know that idea that in the future you'll be able to move past concerns about code or technical components and you know developers or teams will be able to think much more dynamically about like what are they actually trying to do and not get as hung up or concerned about well is there you know are are we gonna do some type of of code implementation that's gonna have some nascent issue that we're not expecting you can focus much more on what the functionality what the the overall project goal is so kind of right along with that nick is there anything else that you see as you kind of look out on the horizon when it comes to potential uses for the standard anything besides the the examples you just mentioned that you think you know theoretically somebody could do x y or z i think that there could be uh new which are extensions to the uh eip2535 diamond standard like uh you know like uh like people might have ideas to do you know sometimes people have other ideas of what could be done with it and i think those are all great and some of those might make sense to be a standard uh like uh and i don't really have that much in my mind right now i just think that there's possibility for standards that build on top of the diamond standard even this we're talking about this plug-ins uh there could be standards there um as far as you know um a standard for module faucets uh is you know like how you the standards for how's the data going to be stored uh in these modular in these yeah these reusable faucets so i think there could be more standards um another area is in upgrades like the standard is pretty flexible and upgrades it provides a standard function but it's optional and it also says that you that projects can create their own uh upgrade functions to better suit them so you don't just have to use the one in the standard you know so like maybe um there could be you know more creative upgrade it also doesn't the standard doesn't limit like who can do upgrades like the reference implementation has like a contract owner only the contract owner can do upgrades but um you know that the standard doesn't limit that you know you could make it so that you know people can vote and the upgrades only happen based on on-chain voting or um something like that or um some you know government systems could be built on top on top of the diamond very cool and uh you know it's it still feels very early days to the point where you know we're still trying to learn every way we can take advantage of this wonderful standard that you know you've created nick and uh you know think we got to figure out how we can most effectively use the existing diamond standard and you know once we figure that out i'm sure we'll come up with ways in which we can improve upon it but there really is just so much you know it's just such a generalized model that you know there are so many possibilities that suddenly just become so simple through this you know simple interface and you know kind of the whole the whole diamond cut structure you know the ability to just have a general uh you know agreed upon way to upgrade contracts with a rule set is just you know truly incredible and i find it useful to you know exactly what you're kind of saying a general like a general rules or approach to the upgrade and the organization that then can be applied to many different projects just you know and then you know people are kind of agreeing to that approach then just makes it easier for communication about projects to getting started on projects and uh understanding them because you know there's some some someone else starts a diamond based project and you have to learn that project you already know diamonds then you already understand it's architecture and you understand how it's organized and now you just need to know the the nuances of its domain of like how is it what's it doing for its specific domain so anyway so that's all useful yeah and i i thought about that too because like you know there's some l2 so evm solutions that don't have a max contract size and so you know that's a question should you use uh the diamond in a in an evm environment that doesn't have a map and i'd still use it i'd use it for its um it's it provides this net it's easy this organizational strategy that can grow like and so i would still use it without max contracts even though that was initially why it was created and solves that problem i think the organize organization that it provides its approach um is is valuable just by itself so i would still use it for that oh another another thing and this is not this hasn't been explored that i've seen typically well contracts that you deploy you can't query you cannot query a smart contract for all the functions it has like you can't like i can't you know i can't have one contract on chain ask another contract what functions do you have or do you have this function there there is a standard for there's a standard for like interfaces like do you support this contract interface or not which which is useful but you don't you can't ask a contract what are all the functions you have and do you have this specific function you have this specific function but with the diamond you can actually you can do that where you know you can query a doc one contract can ask another diamond give me all your functions and then you can do something and so i haven't so that's possible to process the functions of a diamond on chain and i've never seen anybody do that i don't you know it just hasn't been explored maybe there's something useful there i don't know but that's something to to people someone can explore possibly you can create maybe more kind of systems that manage systems like diamonds kind of help could could create more of this automation of smart contracts which you know like one thing i've i've thought about ethereum limits what you can do because of gas costs but in the future there's going to be there there's environments where gas costs are not such a problem we've seen that on some of these other blockchains like polygon where it's a lot cheaper you can do more on chain and i think with some of the l2 solutions and future options you'll be able to create even larger systems that do processing on chain that you couldn't otherwise do so in diamonds again may have some interesting use cases there so to turn that question on its ear just a little bit is there anything that the beanstalk community could be doing uh to help support the diamond standard or you know anything else that you're that you're that you're working on oh um i think uh maybe i i'm not really sure we talked about uh creating a foundation that supports projects that are using the diamond and support more tooling and that sort of thing um maybe but i think um you know i think just uh growing and expanding you know building a system with eip 25 35 diamonds and you know building a good system that grows and it's successful that helps this that helps it a lot you know that's adopts that successful adoption helps that helps the standard um so of course that helps and potentially other things i think you know inviting me on this podcast i appreciate that and that that helps too it's definitely a pleasure speaking of so what else are you working on what what are the projects that you're spending time on right now and you know developing you know things that you feel comfortable sharing publicly of course yeah so uh recently i i've been involved in um the um smart contract uh uh security auditing where just people have asked me to to to do that and so i've done that some code reviews i'm i'm an advisor for for some projects just just strictly on smart contract technical advisor so um so i've been helping some projects on on smart contract technical stuff and then um you know i'm in the discord for diamonds uh answering people's questions sometimes and um you know just uh just around and yeah sure so so again as you look more broadly you know we've talked about things that might be happening in the future in terms of diamond usage itself take a step further back are there any particular uh new technologies that you see you know in the crypto space or in blockchain more broadly that you look at and think wow that's that's really interesting that's something that you know could really change how how certain environments work or how certain problems are solved um i'd say um with the evm stuff not not so much i mean just just working with it but uh i've been looking into virtual reality stuff recently and so i mean this is kind of a higher level thing i really do see how uh blockchain which secures ownership of things really seems to work really well with virtual reality type metaverses where people will want to own objects and things in virtual reality and how blockchain can secure that so i think that's that's going to be an exciting uh thing in the future um i'm really into since 2017 2018 really interested in the idea of blockchain securing and transferring ownership of digital things physical things um and and so on um there's uh i've been involved to some degree with a project called bozen protocol which allows you to um buy and trade things with crypto but are physical um and like go into metaverses where you can like buy and trade physical things inside metaverses so anyways i think but so just in general i'm interested in all these different ways ownership is secured with with blockchain this i guess is my main interest um and then there's all these l2s i probably should um explore more of the different l2 solutions i have some but i think it's good very cool so how can our listeners learn more about the diamond standard and and follow your work yeah sure so there is a a blog um or a website that i wrote a bunch of stuff it's eip2535dimes.substack.com or you can just probably find it by searching eip 2535 diamonds so there's some blog posts that i've written because what's happened is you know people ask me someone ask me questions and or they say things and if i see it two or three times then i go this is important enough to write a blog post about it um that kind of thing um or just i just keep writing things that i feel will help people um so let's see there's the standard itself which has a lot of useful information in it and also has links in the reference section to learn more um and then there's i then there's like the um projects like like like um well just different projects that are implementing the the diamonds i think they they tend to create their own material about about the diamond and how they're using it and provide examples of of how things are done which i think is useful good stuff all right to kind of finish this out we'll just ask if anybody has any closing thoughts and actually i'll start with you nick and then i'll turn it over to publius to let them round us out yeah sure um one one of the common problems uh with the dime we're not problems the things that comes up is people like they they're they're used to open zeppelin uh smart contracts and open zeppelins like their solidly library stuff in open zeppelin works with with their diamonds because because it doesn't have to do with modifying state variables but open zeppelin's smart contract implementations like erc721 erc20 they those opens up those implementations they don't work with diamonds like you can't take open zeppelins erc721 nft contract and use it with diamond because um with diamonds you have to organize your state variables a certain way to make it all work well and that that way is commonly called diamonds diamond storage there's another way called app storage which is uh similar and uh so anyway so so that problems come up with open zeppelin um open zeppelin they have an upgradeable version of their of their contracts and they also because upgradable contracts in general need a way to manage state across upgrades and uh so open zeppelin has a way of doing that for the upgradeable contracts it's called it's called their gap they use these these gaps in in storage space to have future room for new state variables and but one of the lead developers says is that for their next major release of open zeppelin they're looking to use diamond storage for for the upgradeable versions of uh open zeppelin which is because they you know they they see that it's a better than what they're doing but but that's exciting too because that means that if they do that which i hope they do that in their next major release then the um their implementations of thing of smart contracts will be able to work in in diamonds so that's something hopefully happens oh but i should say there is someone who has ported or opened zeppelin's smart contracts to use diamond storage so they can use so that they can be used in diamonds there's also another smart contract uh library out there that has implementations of like erc721 and erc20 and other things so in other words there's already solutions for um for common things to work in diamonds but i think it'll just get better nice publicly is anything to add as we finish out just wanna you know first off say congratulations nick that's a real accomplishment to you know be able to get on opens up on this radar and then yeah just want to overall say thank you so much for taking the time to come on this podcast you know we've spent so much time working with you know the ears the eip2535 standard which you created and you know i've spent so long you know working with your work and i've never really got a chance to have a conversation with you um so yeah i'm truly honored to be able to have this chat also you know thank you for all of the great things you said today um you know really opening up kind of and explaining what the possibilities are for eip2535 going forward and you know just if anything comes up any way we can help support you know the the effort to you know get uh eip2535 out there please let us know and you know um as our big fans so thank you awesome thank you i'm grateful for for you too i've been watching the project and looks like it's going really going really well and i'm really happy to see it go along and thank you for it for you know looking at the the standard and giving it a try and i appreciate that