Ethereum Cat Herders PEEPanEIP, 21 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Peep an EIP #7: EIP-2535: Diamond Standard with Nick Mudge

Description

EIP-2535: https://eips.ethereum.org/EIPS/eip-2535
The episode on EIP-173 - https://youtu.be/64VfajtPGJ4

Follow at Twitter:
Nick Mudge @mudgen | Pooja Ranjan @poojaranjan19 | William Schwab @William94029369 | Alita Moore @alitamoore85

Contact Ethereum Cat Herders
Discord: https://discord.gg/sgdnxZe
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders/PM
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/

A

Hello and welcome to another episode of peep and eep and eip dedicated video series, where we consider one proposal to understand why and housed by the author itself.

A

Today we have got a very special guest who has been here on the show earlier to talk about another proposal: eip173 the contract ownership standard uh that is already implemented in open zeppelin and some of the other projects. So if you are working on something similar must watch that episode. I will add the link below welcome back nick, very happy to have you here uh today. We are going to talk about another proposal that is eip2535 diamond standard, but before that please introduce yourself to our new viewers.

B

Hi there yeah, so I'm nick and I'm a solidity developer. uh A standards author, yeah so and I've worked on various projects been working with solidity and ethereum for a couple years: yeah. Okay, so let me share my screen.

B

All right, so I thought I'd start off with some benefits of of a diamond, so a diamond is a contract that implements the diamond standard, and so let's look at some reasons why someone might want to have a diamond okay. So uh the first reason here is a stable contract address that provides needed functionality.

C

B

C

Is really for upgradability.

B

So that, if you want to diamonds, can be upgraded and they they keep their uh their address, just like a like, if you're familiar with other upgradeable contracts like uh open, zeppelin's proxy contracts it. This provides the same benefit here of when you can upgrade your diamond to add additional functionality to your diamond to do different things and you have a stable address. It's not going to change okay and then so so the second benefit here single address with functionality of multiple contracts.

B

So one thing: that's different from diamonds versus proxy contracts like open, zeppelin's, proxy contract. Is that a diamond utilizes multiple contracts, whereas uh open zeppelin's proxy contract it uh it just has one implementation contract and only proxy contract only pulls functions from one contract where the diamond can pull, pull and use functions for multiple contracts.

B

B

Okay, good, so why so? The question might be asked: why would you want to have a diamond that can use multiple contracts? Why not just use one contract for its implementation? You know like, like a regular proxy that just uses one implementation contract. Why use multiple so there's different reasons that that you might want to do this?

B

uh One reason is for is for uh fine-grained upgrades, which means that if you have a diamond and it provides some functionality- and you realize that you want to change something in the contract- you want to upgrade it uh or you, then maybe you just want to change one small thing, or maybe you just want to add one function or replace one function and with a diamond you can do that.

B

You can upgrade your diamond just replacing that one function and or just adding that function or just removing a function, whereas in a a proxy contract you have to deploy your entire implementation contract with all its functions, you basically have to redeploy the entire implement the entire functionality over again with your small change.

B

So that's uh that's one benefit of a diamond. Is that you can you can change just the parts of the diamond that you want to change and nothing else all right, so there's uh I have on this list another a number of benefits, I'm not going to discuss them all, because this is more of an introduction.

B

Oh yeah, so one other big use case for diamonds. Is it solves the 24 kilobyte maximum contract size limitation? So uh this this happens uh with upgradable contracts. Where you you have your upgradeable contract, it's great! It's you know, implementing your your non-fungible tokens or or your d5 protocol. Whatever your um your system is your diamond, your excuse me, your upgradable contract is doing it and then you, you realize that you need to upgrade it to add some more functionality.

B

So you do and then you realize you need to upgrade it again with some more functionality. So you do. You know you find more use cases. You get feedback from users, there's all kinds of reasons why you might want to add additional functionality.

B

One of the things can happen is you'll hit. The max contract size limit so like contracts on ethereum can only be get so big and then they can't be deployed anymore and that max is 24. Kilobytes and the diamond doesn't have that problem and it doesn't have that problem because it uses multiple, uh multiple contracts or implementations and for the diamond standard we call it faucets, so diamond uses multiple faucets.

B

So you really can have as much functionality as you want in a diamond. It's not limit, there's no size limitation on it. So that's that's nice! If you're, upgrading and improving functionality, you don't have to run into this limitation that stops. You.

A

Yeah, I may have a question here, so uh this contract size limit. uh I understand that this is something added in like a later version of diamond protocol, right diamond proposal that you had initially. So why not to come up with a separate proposal for that or why to add it in the existing one? Does it add value to your existing proposal.

C

uh No, it's always been there. I'm sorry. I got confused with the diamond storage version, yeah, no problem, it's okay! Oh.

B

Maybe you're thinking about diamond storage yeah. That was something that was added. That's yeah. We can cover that. That's that's right! There's diamond standard uses something called diamond storage which was added later to the standard.

A

B

Yeah, so uh we could cover, we could cover that a little bit or recover it now.

D

I'd say when we, when we try and make it through the benefits like if you've got like another one or two benefits that you want to highlight, and then maybe we will start driving into like sort of the technicals of how it works and how it does all this. If that's, okay,.

B

Yeah sure so I mean another benefit: is this and I've kind of already gone over this this develop incrementally and let your diamond grow with your application. So you.

C

B

That that you can, you know, deploy your diamond to a test net and have you know, people start using it and then get feedback and then go ahead and upgrade your your diamond um and then there's another thing about a diamond is: is it's upgradable, but you have the option of making it no longer upgradable anymore, so that can help with development.

B

If that, if you know during testing or you know, you're letting users try out the application on a test network and you can upgrade as much as you want, but for this particular application you want to be immutable when you deploy it on ethereum main net. uh You have that option with a diamond where you can, you can just make it so that it can no longer be upgraded and.

D

But that also means that you can pick some of your benefits. It sounds like like, if you want to be able to split a very, very large contract into a few smaller diamonds you're able to do that, but without necessarily having the proxy contract pattern of upgradeability. Is that correct.

B

um Yeah yeah, that's that's right. I mean one of the one of the nice things about a diamond is, is that you you it's using these different faucets? So so you can split your functionality among these different faucets and that helps you organize your code. So related code is its own in its own faucet.

B

Is that kind of what you're talking about or or just breaking up your diamond to get into different diamonds.

D

um I'm more just picking and choosing what you like, what what parts of the of these benefits you want like you could get the split code, so you don't run into the 24kb um limit but still choose to make it immutable like you, don't have to necessarily take all the options that you're offering here you can sort of customize how you want to use your own diamond. Oh.

B

Yeah, that's that's very true. I mean the the diamond standard and making a diamond is is very flexible, so you can design it and get the benefits that you want and not knock it. You know and ignore the things you don't need. It's very true.

B

Yeah so I'd say: that's some of the uh the good benefits there I mean. Another benefit is that there can be some in some applications. There can be some gas savings using a diamond uh because, because a diamond can be unlimited in size, uh you can uh it enables you to access contract storage within a diamond. Without you know, without having to do uh calls external function, calls to other contracts.

B

So because things are all in one diamond it can, it can reduce the amount of function, calls that are going on that which reduces gas costs for some systems.

D

Great, I have actually a bunch of questions about gas, so I'll be interested in getting into that once we get into the more technical part, this might even be a good segue into that about how how you managed to pull it off so like what's the magic what's going on under the hood here, okay,.

B

Good yeah, so let's look at that all right. So what is a diamond how's it implemented. So, as has been discussed, the diamond is a contract that gets its external functions from other contracts and inside of diamond. It has a mapping which maps functions to other contracts and these other contracts, I'm calling faucets.

B

You know like faucets from a diamond different sides of a diamond. So what happens? When you call a function on a diamond, then the diamond looks uses that mapping and goes. Oh. This function is being called and that that function comes from this other faucet and it is able to pull the the code. The function from that other faucet and execute it within the diamond. So the diamond really uses other contracts as its as its library of functions.

B

So, that's that in a nutshell, that's how a diamond works.

D

So you're starting basically you're taking a contract more or less charting parts of it into libraries, so that the contract can then import all of its functions using the library techniques. That solidity reveals.

B

uh Yeah I mean it's, I mean I'm saying the word library more conceptually. The solidity has a library functionality, I'm not you know not using library functionality here, um solidity, library, functionality, I'm just more conceptually saying that you know a diamond uses other con other other faucets as its library of functions, but I'm not talking about solidity's library.

D

Okay, I got it.

B

Yeah, but that's good to distinguish that because then yeah, what I'm talking about? What I mean by that uh li uh solidity's library uh functionality does work within diamonds for things and it's very useful with diamonds. I found.

B

Which I can discuss in a bit later, but so the the three like main parts of a diamond are one. It has a diamond, has a diamond cut function, which is a standardized function that diamonds have that's, this function is used to add or replace or remove functions on the diamond.

B

So every diamond has this function, that's how you add, add stuff and change it. That's the upgrade function and then a diamond has four standard functions that are used to tell you what's in the diamond. Like you know, if you have a diamond, you want to know what functions does it have and where do those functions come from, and so these four standard functions give you that information. So at any time you can look into a diamond, it makes it transparent.

B

And then a diamond has a standard event and this event emits anytime there's a change to a diamond, and this gives you a full historical record of all the upgrades of a diamond uh everything. That's changed over time.

D

So maybe you could detail how this, how this differs from normal importing like let's say that I'm using safe math from opencephalon, or something like that, so usually I can just import the contract. I have all those functions available. It sounds like there's something much more modular happening here. So how exactly does this differ from a normal import.

B

Okay, so it's it's different from a normal import, because in solidity code, you're, you're, importing a library or or another contract into your code and then you're using that in your contract.

B

um So in this case a diamond is, is a contract, that's been deployed uh to the network, it's like and it doesn't have when you first make a diamond, the diamond can be deployed to a network and it and it doesn't do anything you have to add functionality to it.

B

And so that's where this diamond cut function comes on where the diamond cup function allows you to add functionality from other already deployed contracts, so you know versus where you're importing, if you're importing something you're, creating a contract that that's going to be deployed and you're importing all the things and you it's all going to be added to one contract. That's going to be deployed with a diamond.

B

It's the diamonds deployed you're, adding things to a diamond after it's deployed.

D

So for a normal import, you're saying that we're putting all of that code inside the contract before deploy and then that contract itself contains sort of all the imported code. Inside of it also, and then it gets sent to the then it gets sent to the chain, whereas over here what you're dealing with is you're actually connecting components from different blocks from different parts of the blockchain and sort of creating a cross functionality between contracts that are already deployed.

B

Yeah, that's correct great yeah, which, which brings up an interesting factor. Another benefit is, is that you know you can deploy contracts onto the the network. Faucets these these these contracts that get used by diamonds. You can deploy them to the network, and then you can deploy your your diamonds and then you can connect the two. But the cool thing is that these faucets you deploy, can be used by any number of diamonds. So you have this.

B

This reuse of deployed contracts on ethereum, because you know you have one diamond or you have five diamonds that are using the same faucets.

D

So essentially, you've created a kind of on-chain reusable component. No, as in we could, there could even be some kind of service where various various different high use functions have been deployed and now can get pulled in on chain using uh using the standards that correct.

B

That's correct yeah, and that is a bit like solidity's libraries, because you can deploy. You know, contracts the network and then use solidity's library functionality to use those deployed. So in that way it's similar.

D

B

D

B

And then uh yeah so then I think the the three main components.

D

It looks like that is close to the end of your list. I've got a bunch of technical questions. I'd like to ask you about this. Would this be a good time for me to sort of move into that? Absolutely okay, great, um so, first just actually sort of in the coding style. I'm curious about the way that you put this together um the actual standard itself. I have not made it through through the implementations and the examples that you've given.

D

Would you say that it follows more of a object-oriented or more of a functional standard, as in when we're looking at a diamond working is or is there some kind of object, that's getting mutated or is there like? I mean? Maybe you could describe that that process about exactly how the data is getting passed around or how the contracts are connecting to each other and bringing in data from each other yeah sure.

B

So uh the diamond uses uh an operation code from the from ebm, which is delegate call and so and delegate call allows a contract to borrow the code from another contract and execute it as its own and that's really what a diamond does when a function external function call is called on a diamond. The diamond goes okay, I got this. I got this function call and it finds out.

B

Well, you know what faucet that function call belong, that function where that function exists, and then it uses the delegate call operation code opcode to get that function from that faucet and once it's got that function, it executes it as its own code and that's that's what it does.

E

So I'm just going to chime in really quickly um when you say it calls a function, does it return the function or is it like an op code in the sense that it only sends out like the parameters and then receives uh the result.

B

Oh, so that's a good question, uh and this goes uh so yeah. I can be more specific when an external function is called on a diamond, a diamond. It's a contract, ethereum contract and you can have a fallback function and that's how it works is a diamond has a fallback function. The fallback function is when you call a function on a contract and that contract doesn't have that function. What happens? Is it executes its fallback function?

B

If it doesn't have that function, and so a diamond really in in in some cases or most cases, a diamond hat doesn't have any of its own functions.

B

So when you call a function on a diamond it just it goes that that call goes to the fallback function and then the fallback function then uses delegate call to call the function on the on the faucet now about return and once it once it calls that um that function on the faucet that that function might have return values, and so the diamond gets those return, values and also and returns those return values to the caller. Whoever called the diamond gets the return values.

B

Does that answer your question so like a guy like when you call a function and that function has parameters? Okay, the diamond gets that forwards it to a faucet pause. It executes it lots, it has return values. Faucet gives it to the the diamond diamond then go ahead and also returns the return values yeah.

E

That makes sense it's just it sounds. uh uh That's really cool actually, um so it kind of sounds like you're sort of um separating the actual computation from this from the contract. So that's cool yeah that answers.

D

My question: thank you, yeah. I am curious about the gas overhead um now this might be a good time to even segue a bit into proxy contracts. Proxy contracts have been a pattern for a while um and used for upgradability, but um proxy contracts. The best man, knowledge also make uh judicious use of use of delegate call. Am I correct about that? That's.

B

Totally correct, yes,.

D

How would you differentiate between diamonds and the regular, I so to speak proxy contract patterns that we've seen up until now? I I'm seeing with the diamonds that you can pull in specific functions and also that there's much more granular control of those functions inside the contract. But maybe you could compare and contrast proxy contracts and titans.

B

Yeah sure so the main differences between them are well. One of them is that, I won't say all proxy implementations, but a lot of proxy implementations and open zeppelins popular proxy contract implementation.

B

They have, they only have only one implementation contract, so so they work the same way. A proxy contract has a fallback function. You call you call external function on the proxy contract the fallback gets executed, which then does delegate call to to call on the implementation contract. So the proxy contract works similarly to a diamond.

B

In that way, um different big differences, as I said diamond, can, is mapped to lock, potentially mapped to lots of different faucets, not just one, and so um so that that also solves the max contract size problem I talked about earlier. A proxy contract will run into the max contract size if it gets too big, because it only has one implementation contract and that implementation contract can get too big, but a diamond could have tons of faucets and they could all be small faucets, so they never get the max contract size.

D

Would you would you need to make more delegate calls using a proxy or using a diamond, or would it all come out the same? If we would compare like you know, a specific flow of calling a function using using the two different patterns.

B

Yeah, so that that flow is uh is very, very similar, so with a proxy contract, you know the external call happens or the fallback function executes and then there's a lookup in state in in contract state to find out. What's the implementation contract address and it uses that to execute the function and the diamond is the same thing um yeah. So it's like the flow is the is this.

B

The only difference is that um I think a proxy doesn't really need a mapping, a map to map the function call to the implementation, because the implementation contract is the same for all function calls, whereas a diamond you have, you have to have a map, an actual mapping, that maps function calls to two faucets, but basically the flow is the same. There.

D

So gas gas cost between the two should be roughly like. Roughly analogous, it should be roughly the same gas for either a proxy or for uh or for a diamond, that's correct. They're the same I would actually like to to segue from that into the topic of gas. um So this it's by pushing storage off to the different facets on the diamond. So it seems like you so you've solved a lot of storage issues, but by pushing it to delegate call we'll make calling these functions slightly more expensive.

D

Do you see that, as being prohibitive, the level of gas spending that's going to have to happen.

B

uh Right now, I I don't see it as prohibitive. uh It's you know the with the diamond. It's sort of um it has has qualities that mitigates itself for gas, uh so that it, you know, because you're, where you're calling delegate callers, there's a little bit more uh gas to call a diamond or a proxy contract than calling a regular contract, but it makes up for it in a few ways.

B

One of the ways, for example, is that when you, when you compile a a a contract, you can solidity, has an optimizer and the optimizer can has. This has a basically a setting and the higher you make that setting the more uh the more gas efficient the the contract becomes when you call functions on it, but also the higher that setting it kind of more gas efficient when you call functions, but it also increases the by code, the size of your contract.

B

So so what happens? If you don't, if you just have a single contract or using a proxy contract, and your and your your contract is getting large, but it's not hitting the max contract size limit. You can't you can't have.

B

If you can't have a very high setting, I mean in some cases it depends how big your contract is. But if your contract is getting close to the limit, then you can't have a high a high setting for your opt for the optimizer so but with with so that so that so then you have to have it lower, which means the gas cost to call. Your functions is more because that setting is lower, but with a faucet.

B

Your faucets can now be small and you can put that setting as high as as high as it can go, and so that your so your faucets will be really gas optimized when they're called because because you're able to use this high setting that you know you're, that's that's that's one another one is because again because a diamond doesn't hit a max contract size limit, you can add, um you can add use case.

B

Special use case functions to your diamond for gas, for gas cost reasons, for an example is like, let's say, you're implementing a non-fungible token a contract, and you realize that you know you might want to have batch functions for transferring a whole bunch of your non-fungible tokens at once. uh You can do that in a diamond. You can implement those those functions and you can implement other functions that give you gas savings, possibility again you're not going to hit the max contract size limit.

B

So those are just a couple examples where um you know with a diamond. You can do these extra things for gas.

D

As in you're saying that you've definitely got a balance here, even if you do end up spending more on delegate calls versus regular function, calls the fact that you can optimize a number of smaller contracts much more easily than one large contract already should offset gas costs to a certain degree, and certainly also, if you're talking about people who are running up against one of 24 kilobytes. So it's not like. They really have another option in the cards. Anyway, I mean so yeah.

B

And then here's another another case for gas optimization is that if you're using regular contracts or proxy contract and the contract gets too big okay, now you break your contract up into two smaller contracts?

B

Okay, and so for these two smaller contracts to work, they have to call each other and those function calls between each other cost gas. But if you use the diamond all that functionality is within itself and there's no there's just no there's not this function. Call between contracts is not there, so you save gas there, because you don't have to make an extra function. Call does that make sense.

D

I didn't actually foil, understand, fully understand that. So if you could say that over again I'd appreciate it.

B

Yeah sure so if you have a contract that gets big too big, and so you you decide.

A

B

That contract into two contracts and.

D

uh But without using proxy, you actually just literally split it into two contracts and have the contracts call each other yeah. You.

B

Have them call each other.

D

Okay, now I got you.

B

Yeah, but that column between each other costs gas, and you won't have that gas. If you just use the diamond.

D

uh I understand what you're saying uh-huh um I did want to ask you. I saw that um trails bits should be auditing. The standard um I wanted to ask about. Are there potential dangers with especially with using the fallback functions this way as or maybe I'll put that in a more general sense um in general people, a lot of times are loath to put extra functionality inside fallback functions.

D

What are what are you doing to make sure that that's that that is secured, and what are your views on the security audit and why why we should need a security audit for audit for this.

B

Yeah, so I don't see any problem security problem with.

A

B

Function um as long as the fallback function is written right, then it's fine. I guess one thing uh one one thing is: is that uh the fallback function like you don't want to?

B

You don't want to add a faucet that you don't want to add a function to a diamond that calls self-destruct.

B

um If that makes sense, if you do an external call on on a diamond and a diamond, you know.

A

B

That function on a faucet and that faucet calls just self-destruct that deletes the entire diamond, so I mean, but that that's like a stupid error and, like you know, any any functions that you add to a diamond.

B

You should know what you're adding and it's very easy to look in the source code of a function and go look because I myself, I don't think I've ever used um uh self-destruct uh yet so, like I mean, but so like you don't want to call self-destruct, uh you know and have a faucet and a function that calls unless, like you, you really want to do that.

B

You want to delete your diamond for some reason in some particular case um so like I would say that the fallback function is secure and good, but like as a solidity programmer, there's you can you know you can of course mess things up um so, um but you know some of these ways to mess things up are so stupid that you know and.

D

That you know that.

B

You don't see them.

D

As a security threat, so much as not knowing solidity well itself is, this is, is a security threat.

B

Yeah yeah, not knowing solidity or yeah, I mean I, I don't know what else exactly um so. There's that um let's see there's another case. This is another like another security thing, and I another security thing is that you have a faucet, that's deployed, and then you can add this faucet to a diamond and then and then maybe that faucet again has self-destruct in it somewhere. So you, don't you don't call the faucet through the diamond. You just call a function directly on the faucet itself and that that hat and that function has self-destruct.

B

And so basically, if you delete a faucet, that's been added to a diamond. Now the diamond is going to try to help use that faucet when it doesn't exist anymore.

D

And what would happen there? I'm assuming just all the delegate calls for fail.

B

Yeah, so that will.

D

Burn gas, but you know.

B

Right it'll fail uh or or like the calls, will succeed. Well, the calls will succeed, but they won't do any like uh okay.

D

But it won't do.

B

Anything so uh is possible to uh in in in that fallback function, it's possible to add a check to see that that your faucet actually has code in it or not, so that you know to prevent this case where you know before you call your del your faucet function, you check, is there contract code there and if there is, then you go ahead and call it, and then that prevents you from from you know thinking you ran a function on a faucet when you didn't.

D

B

But I don't put that in the fallback, because I don't put that check in the fallback, because it costs gas and uh right, and I just think that people should uh not use self. They shouldn't be self. If they don't want self destruct, they shouldn't use it. It's just for them to use it when they don't when they, when they don't want to um open zeppelin's proxies, does the same thing: they don't they don't do a a code, a check for code um before you know calling the implement they don't do either for gas reasons.

B

They also think that you know people shouldn't add implementation contracts to their proxy. That call self-destruct.

D

B

But, for example, trail bits- I don't think agrees with that. They think that should always uh check that a contract has code before calling delegate calling it uh that's how they feel.

D

Okay, I mean that probably does get into the internals of how audits work and, if everything that an audit turns up needs to be fixed and like you know all of that but yeah, I understand the stylistic differences that you're talking about um yeah.

A

Yeah so after all these technical details, uh now, let's just come out about the usage, I have heard that many of the projects have already started using this proposal in their project. They have started implementing it. So uh would you be able to help us understand the proposal being used as decentralized on-chain governance and which are the projects that they are already using? It.

B

Yeah yeah sounds good, so um there's a company called derivadex, which is they're building a decentralized exchange on ethereum, that is for uh derivative tokens. uh So you know buying selling exchange stuff, so they're using the uh the diamond diamond standard and they're using it for their governance. And so the idea is that and they have a governance token as well. So the idea is that people who have their governance token.

B

They can vote on proposals that um or that changes how their exchange works, how their their and uh so so they people can can submit executable proposals that can get be executed on chain and people vote for it.

B

Then it gets executed and they use the diamond because it allows proposals to add, remove or replace functionality to their protocol, because yeah yeah, because they're because dura derivadex is you know, built basically as a diamond with a bunch of one big diamond with a bunch of functionality and and now now the community can have, has the ability to add, remove or replace functions to that, and uh so that that's the idea that there's you know, there's some security things that that duradex is handling like they have to make sure that any proposals that get executed are uh are good.

B

You know and that they're not they're, not you know bad, they don't do bad stuff. So so that's that's what they're doing and then there's another uh d5 protocol, which is called barnbridge. That wants to do something similar where they they use the diamond again as a way for their community to create, do cause changes to their protocol.

A

Right uh so when we talk about the governance token, this proposal does it has to do anything related to you know how much share a person should be getting because that's very important in governance and when it comes to tao and other stuff, it becomes sometimes challenging like how much voting rights should be assigned for a particular thing. So does that also like answer those kind of queries, it helped the proposal.

B

uh Yeah like um well, I know that uh drove decks. They they have. You know you have to, I think, they're going to release their their uh source code sometime for their their thing, but it's the token and based on how much token you have you have more voting rights and things like that, and I don't know if that answers your question about it.

A

Right so, if I understand correct, uh that is the project that has asked for audit right, that's correct.

D

Okay, is that a fully unchained uh procedure, I'm just curious, like I mean the voting, does the voting trigger everything on chain, or is there still some off-chain coordination involved with that sound chain? Yeah.

A

Yeah, I'm I mean I was uh reading about uh this proposal somewhere, and I found that the bond bridge, as you mentioned, the upcoming project that has actually written some good words about this particular proposal. If I may read out for the uh people here, bandwidth will be a dow that is controlled by the bond community. The barn bridge tower will have full control over the protocols and the feature that are built into it.

A

We are doing this through the use of the diamond standard 2535, which allows us to upgrade to the protocol without having all the members removed from their token and to switch to a version 2 of the protocol that time arises and the bond bridge dow will have full control over the diamonds, which provides amazing flexibility in the web 3 space. I have seen this kind this challenge when, when a java is moving from one version to another version, upgrading they have lot of issues related to you know their voters their their members stuff.

A

So it's really interesting to know that this proposal is going to solve answer those questions and is very helpful.

A

I must congratulate you for that. Before this proposal become finalized, it is actually being used by some of the projects.

B

Well, thank you yeah, there's, there's more too, like uh there's, there's a game. It's like called uh either real. I I can't I kind of forget the moment, but there's a game. That's uh that has non-fungible tokens um and nfts and that that's uh using the diamond standard by using a diamond avocachi um is a project. That's using the time standard.

A

Yeah, I meant to ask more about abagachi like how is it being implemented there, like I mean like if you can given give us an overview of it,.

B

Okay, sure yeah I mean I can tell you that avogadro, it has a lot of interesting functionality. It'll have a lot of on-chain interesting functionality. It has a composable parts where you have a like. A navigation. Is this this creature, this ghost and it can have wearables. So you can, you can hold a wand or a sword and so and that's going to be on chain. So so you'll have this.

B

This non-fungible token, which is which is in avogadro, available to the token, will actually be able to own these other tokens, he's either fungible or non-fungible.

B

So um so you'll have these this composability or where tokens are owning other ones, as avagachis can also hold um erc20 tokens and stuff like that, so that so this so it it's, um I've started that implementation and- and it's the composability part so far- has been based on another standard, which is erc 998, which allows this non-fungible token to own other non-functional tokens and other composable functionality.

A

That's great, so I have been seeing that there has been a lot of stress towards the educational resources about this proposal. You think that more educational resources are required here.

B

Oh totally totally I I've been promoting like people who make videos and and tutorials about solidity uh to to also start writing more about this. It's more of an advanced um thing. I think a diamond like someone, just learning solidity and learning a diamond is too much, but after someone gets comfortable with solidity, uh then they're learning a diamond is as a good thing uh and uh I I education would definitely help on it.

A

Yeah, I see this proposal is still it's in the draft status right and the next state would be like to like move it to the last call right. So how? How ready is this proposal to move into the next state.

B

That's a good question, so, let's see, I think I think it was uh released in like march of this year, uh the diamond standard. So it's it's still pretty new and it's it's it's. It's really. I feel like it's really improved and gotten better over times, um and uh so you know I. I always think that that the standard is like. Oh, it's not going to change much. It's probably pretty much done, but then but then something happens and you know something gets discovered or we find we learn.

B

I learned something or someone else learned something and then there's more to add to the standard or or and take things away. I I've taken things away and then I've added stuff. So I I don't know when when I'll move it, you know, I guess when things stop improving, but um you know right now: it's it's! You know again. I feel pretty confident right now that it's not gonna it's. You know that it's not going to change.

B

I think right now the only thing that's going to change in the standard is that I'll add more like um information like more security considerations like we talked about, don't call self-destruct with dealt with uh with delegate call. You know, that's a security consideration. I could add that to the standard, uh and uh so just like more information, but for as far as like changing the implement. Like uh the specifics of the specification, like you know, it's uh I don't know like right now. I don't know of any changes to add to it.

B

I don't I feel, like I probably won't change it, but but it could change um yeah. I mean the standard's really flexible and people and that's the thing is: I'm excited to see what people do with it and create and.

A

That's interesting, so I mean like it's safe to assume that it may take a couple of more months to get into the next state, because that's author's choice, right when author is ready, he can move it to the next state and move it to the last call, and then editors will review it again and further. It will proceed.

B

Yeah, yeah and- and I want to I want to mention so uh as I see as we talked about earlier- the diamond standard came out in march and uh it was written a certain way and it was fine and then I had some months later. I did a pretty big rewrite on it, because uh this new thing was made possible, which is diamond storage, which is this which solves a problem with um with this.

B

This pattern of having a fallback that calls other contracts um and the problem is is, is how to handle state variables, like so with a proxy contract.

B

You know you have an implementation that has state variables and then you upgrade with a new implementation that new implementation might have different state variables into the alignment and coordination of state variables between upgrades has been a problem in the past, and so diamond storage really um really helps solve the the problems with that by and basically what diamond storage does is it allows developers to create a namespace section of contract storage like that you can specify a place in contract storage for functionality and uh that's part of it, so that, then you can have you know multi different faucets can have their own places for their state variables and it's also possible for faucets to share their data uh in a diamond, and so the diamond store makes that possible, but that that only um you know this diamond storage capability was only made possible um on this earlier this year, when uh solidity language uh changed and there's this new feature that that was added that made it possible so that that's what happened with her and that's always a really really great uh benefit an addition to the diamond standard which didn't have that before.

A

That's great so with that. I think that we have learned more about this new proposal I was reading like there are a lot of, as you mentioned, that you have been writing blogs about it, and I've read it in so many places. It's a good proposal for decentralized, on-chain governance.

A

um I hope that it becomes standard really soon like whenever you are ready to move it to the next stage, because that's already been implemented in some of the projects with. That being said, I hope to see you again nick because I see that there are some more proposals coming up from your end for people who are watching us on youtube contact details. So the account where you can follow would be provided in the description section below and uh leave your questions comments.

A

We will we'll bring it to the authors if you have any further and if you are implementing it, let us know more about it so that we can support every proposal that is coming into this uh series. Hope to see you guys soon again, with another episode of p penny till then goodbye, it's pooja, ranjan signing off. Thank you. Everyone.

A

D

E

Yeah, okay, hi! This is really great. Speaking to you.

B

Thank you. You.