Ethereum Cat Herders PEEPanEIP, 29 May 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: PEEPanEIP #109: ERC-6059: Parent-Governed #Nestable #NFT with Steven P & Jan T #erc #ethereum #rmrk

Description

Topics covered
-------------------------
1:37 - Jan Turk introduction
1:58 - Steven Pineda introduction
2:34 - Presentation
2:44 - Pusing NFTs further
3:48 - ERC6059
5:54 - Use cases - Bundling, Collecting, Soulbound, Membership, Delegation, Security & Multiuse prevention
13:14 - project implementation (NPM package)
14:54 - Tools for Dapp developers
16:20 - How is this EIP unique?
21:40 - Child management
24:30 - EIP Process for ERC6059
32:22 - Resources
33:10 - How to reach out
33:40 - Q&A
35:12 - Compromise of nesting NFT, if any?
37:15 - If targetted to a specific level, how vulnerable is the NFT?
39:37 - Expecting feature change with multiverse
41:40 - How is this different from hierarchical NFT?
42:42 - Thoughts on this proposal not being backward compatible?
46:50 - Thoughts on PEEPanEIP
49:30 - Message to the community

Follow at Twitter
---------------------------
Steven @stoicdev0 | Jan Turk @JA_JanTurk | Pooja Ranjan @poojaranjan19

Support us
-------------------
Wallet: EthCatHerders.eth

Resources
-----------------
Slides:

EIP: https://eips.ethereum.org/EIPS/eip-6059
Discussion: https://ethereum-magicians.org/t/eip-6059-parent-governed-nestable-non-fungible-tokens/11914
PEEPanEIP Playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
ERC Playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqXee9EMQDIEz2CslTnsW0K
NFT Playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxpUmj2UjD4BtfgC1nAAyv3p

Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/ethereumcatherders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
Website: https://www.ethereumcatherders.com/

A

Yeah I just want to do the same invitation to builders to to go and check uh all these amazing tools that we are building and that other people are building to make nfts much more powerful and for holders and Legions uh to ask for their collections to look for innovation in in what that they are buying and, to literally ask the owners of the collections to to move forward to not stick to 721, which yeah it's great. But it can be a lot more than that.

B

Nfts is the most popular blockchain applications. Building standards around nfts will facilitate many data developers to come up with mind-blowing projects. If you are into learning new ethereum standards continue listening foreign.

B

Episode 109 I'm Pooja ranjan back with another interesting ethereum standard for nft projects, ERC 1659 parent governed nft was documented in November 2022.. The CIP has been added as an ethereum standard in April. 2023. I'm excited to welcome back Stephen, Pineda and Ian Turk from Team remark to talk about ERC 6059. Thanks for joining us hi.

C

Thanks for having us.

A

Thank you very.

B

Well for people who missed, we have recorded an interesting conversation with the team on ERC 5773 context, dependent multi-asset tokens, don't forget to check out the recording on ERC playlist at eat, Caterers YouTube. Moving on to today's topic, I can't wait to learn about this nft standard. But before that, may you briefly introduce yourself to our new listeners hi.

C

I'm Jan Turk I am one of the co-authors of ERC. 6059 I've been building solidity, smart contracts and researching blockchain and possible implementations since 2016 and I really just do blockchain for fun and for my job. So it's really my life.

A

Hey there I'm Steven I, don't have as much as experience as yet but I've been doing specifically nfts for the last almost two years and I've been looking for ways to expand the technology with these particles and to find new new use cases and basically to expand the knowledge and to expand the possibilities of nfts I hope you enjoyed this and the other ercs that we've proposed.

B

Thank you so much for your introduction and without further Ado, let's peep in.

C

Hello, so first off your c6059 parent governed, nestable non-fungible tokens, uh it's a mouthful, but it really sheds the light on what this proposal is so about us. So we are tackling nfts 2.0, the next generation of nfts, because currently the nfts are images, videos, music or.

B

C

Know a lot of other things which ownership is secured on blockchain and they can be a uniquely identified and traded frictionlessly throughout the ecosystem. So the the problem that we are tackling is that most nfts today are static, so not in the sense that the content that they're holding is not moving or is not changing, because there are animations and videos and music attached to them, but that they are not changing or they are not adapting to where they're being loaded and how they are being used.

C

So they cannot evolve any further than at its current state. And what we at remark did was take a look at how we can improve nfts, what utility we can add them and we broke that down into multiple different Lego blocks that we're putting together to create the next generation of nft solutions and nestable, Lego or ERC. 6059 is one of them, so in essence it's nfts owning nfts, and we could just wrap here and call it today, but it's so much more.

C

So the standard defines parent child token relationship where tokens Can own other tokens and be owned by other tokens. This means that a token can be a parent, NST owning other nfts, their child entities, but it in turn can be also owned by another nft and all of those nested tokens are then governed by the owner, so be it an externally owned account or this smart contract owning them.

C

So the standard itself extends the utility exactly by this, by defining how tokens Can own each other, how these interaction and management of these interaction happen and yeah how they're transferred how they're nested, um whatever can happen between those token, is defined in the standard.

C

So this really provides some kind of Limitless potential, because even if currently you can Nest tokens, tokens can really be expanded even further if they can be expanded to abstracted account or accounts or smart contract ownerships, or if you have the given token, you gain certain Access Control rows for the smart contract or decentralized organization, or what have you and we designed owner, focused patterns in order to guard against spam, unwanted and malicious tokens.

C

So we always kept in mind that if you meant a token or if you buy a token, you usually end up with several other malicious tokens in your wallet that you have to ignore all the time. So we didn't want you to once you Nest a certain token into your own token, to have five more malicious tokens nested into it. So we designed the whole process of nesting with this in mind.

C

So let's take a look at some of the use cases that we envisioned for this ERC one is bundling, so you can disseminate related tokens as a single unit, and this is quite important because you can either create nft collections. So this would perhaps be an art collection that you auction off as a whole. So you don't auction each individual token or you don't need to do some custom, mechanics where you then transfer 10 tokens one at a time.

C

Rather, you can Nest all 10 of those tokens that belong to the same collections into one token that you auction off and all of all of the 10 tokens will also be auctioned off with it. So when the token is nice that it actually moves with the parent token, whatever happens to the parent happens to the child token as well, so this can also be then used in music.

C

For example, if you have a music album, your top parent nft would be the album, and your child nfts would be each song individually, and this works really well with multi-assets, so ERC 5773, where you can have multiple assets to the token, and so the album itself has a cover and metadata, and then it has song nested, which in turn has audio file and lyrics and metadata as well Stephen. Do you want to take the next one? Okay,.

A

Okay, so another thing you could use it for is for collecting. So, for instance, you have well, you may have different collections which are different type of assets. For instance, I, don't know, I mean I'm imagining.

A

There are collections for, let's say different kinds of animals, so I have a collections for for dogs and one for cats, and so on and I could uh send them all into a zoo, NFTA or a house nft which will contain the pets or something like that. So also, for instance, if you have an album uh like Panini albums for the FIFA World soccer Cup, this album could be an nft which would receive the single cards as an ft2. So it also opens this possibility of collecting one of uh the next.

B

One is one.

A

Of our favorite I think it's Soul Bond nfts, so we so sold on nested nfts. So when we combine this EIP together with 6454, which is in last call and should be final in the next couple of weeks, we get this.

A

A very powerful concept of reputational nfts, for instance, is one of the most obvious use cases, so each user may have an nft which is uh like the place will where he or she would hold all its medals or or the reputation he or she has gained on his contributions to the web, 3 or games or whatever. So all these can be kept together under a single token, which is not transferable. So this opens this opportunity to for a potential nfts, which is something we are seeing growing in interest and in general, under different conditions.

A

You may want to have an nft bundled to another, for instance in game and development. There is this concept of a salbon gem which is attached to the character, and it's there for good. It cannot be removed or the character will have to die, for instance, so it opens a possibilities for gaming, mechanics as well. The next yeah.

C

Yeah, so one one of the more important thing that we might might not have mentioned yet is that nesting can be done inter collection, so the collections themselves cannot do not need to be related. You don't need to specify that collection, a can be nested in collection B. If you implement 60 59, it already works.

C

So let's jump into the next use case, which is membership, so those oftentimes use nfts to denote membership, and if you have it, you are allowed to do something within the down and if you have a doubt that grows and maybe splits itself into multiple subgroups that are in charge of multiple different things, then you can Nest specific access to the subgroup to the original dial membership and this could work well with soulbound. But there is also another possibility that kind of ties into unrelated collections.

C

That is that you might want to create a new dial, because a subgroup grew big enough to kind of Splinter off from the original dial, and now they have their own membership nfts. But you can still kind of Nest that one into the original dial membership, because that's where it originated from and yeah delegation kind of ties into into the membership use case. So currently most of the votes within Dallas are tokenized with ears is 20 voting tokens so the way to kind of delegate your voting power is to transfer your tokens.

C

But if you were voting through nfts and these nfts can actually be a reputational line of these, where the more reputation you have within Ada the higher your voting power, you could also Nest your voting nft within the person that you're delegating to so they can vote for you and with custom mechanics. Then you can get your token back without much hassle.

A

Okay and lastly, there is a scarcity and multi-use prevention, so one of the common use cases we've seen in fds is that they are used as login keys, for instance, for a game, uh but if a collection is used for several things, for instance, let's take the example of the board Apex, which are very popular.

A

So if several people decide that owners or holders of these nfts will be able to to access some web patient platform or some game, then you, as the holder, can use it for at the same time, for several things, so you could be using the same token, to do a lot of things which may sound interesting, but it may also not be the purpose of the issuers of the collections or the creator of the platforms.

A

So with this one, simple mechanic that you could Implement is that, for instance, if you have a game which has lands on it like a metaverse, then you may require the characters, the nfts to be nested into the land in order to use it in your game. So this forces the holders to use them only once at a time as a real world as it would would have and uh yeah.

A

Basically, it creates that also scarcity because, for instance, let's say I have a collection of weapons which is also very famous and can be compatible with multiple collections, for instance using 5773. So if I can just use it at the same time on several characters, it makes it less cars right.

A

So, if I add this restriction, that I need the weapon to be nested into my character in order to use it, then the scarcity multiplies because now it's you, you really need to have more of them if you want to to use them multiple times, okay, so, as with the for the other earps we have presented, we provide an npm package which you can just simply install with npm on yarn and have all these contracts available.

A

So in this package you will find the interfaces core implementations which are non-opinionated so things as minting, for instance, are not implemented. We have internal functions for them, but not external, because it's up to your project. How will the minting work? This is very common, also on erc721, so we are following the lead here of open Zeppelin, which provides all these different levels of the interface, a core implementation and then an opinionated ready to use implementation.

A

We also have this for nestable eaps inside our package, so on the opinionated implementations, for instance, we have three different ways. You can do anything either Lazy minting by a native token or a custom erc20, so tokens are Minted as the users buy them or you could also have pre-mint where the or the owner, and only the owner will mean for free all the nfts first and then put them into cell in the marketplace. So all this is in this package.

A

There are very multiple projects, working with this nestable VIP and the others, for instance, next holders, which is one of my projects, I, never loot. They are both games, which use these nesting mechanics to Nest, either Gems or weapons or armor into the characters, and there is also a short terms: rental tap, which is called bomba, which is using nestable AIP, together with a 6454 for sold on nfts.

A

To use to create reputational badges well, we have a ton of two tools for dub developers, so we have all the documentation, for we will share the links for all this slide. After that we have a link tree with all these, but basically we have a extensive documentation for each of these Legos. We have video tutorials, where we follow the creation of a project using all these eips, and we explain and share all the code that we use it's an open GitHub.

A

So anyone can access and see the code we'll have some sample Journeys, where we take very specific and simpler use cases, for instance us having, for instance, I, don't know if you have it, but we will probably add it soon. The sample that the example that Yang gave with the album and then the nested songs into it. So we take this kind of samples like very small ones and specific ones, and we go step by step, how you would create the contracts using this package and how you would interact with them using typescript and editors.

A

B

Also have a GitHub template.

A

Which you can Fork and has all you need to start working on your project. It uses hard hat in the future. We plan to add also one for Foundry, which is very it's getting more traction, and basically the thing we offer for dapps developers by using these VIPs is that they get forward compatibility. They don't need to know in advance everything they want to use because they can be compatible with any collection in the future by following these standards.

A

Okay, so one of the things that we want to see in this course is how this app is defer to two other ones. So actually there is no other VIP in final or even close to I. Think that has these capabilities. We have seen some in the past and there are other in draft or or staying in. So why is this EIP 60 59 unique first, because it's fully focused on nfd's owning nfds, so we have seen others which try to solve multiple problems at the time.

A

For instance, there's one I think it's 998, which actually I tried to do like four things. It was four different interfaces, so tokens that could own other tokens and then token does could be owned by other tokens and also erc20s uh nfts. That could hold fungible tokens. So we are focused specifically on nfts and due to this, and to the other thing, six, seven months that we played with this on evm testing, for security and for holes and for limitations, we really have come up with a really good product.

A

We are really a minimal but powerful interface that can be extended into several use. Cases and I just want to remind you that, even before these seven months of development and then like four or five months of review in the Forum, this concept of nft is necessary into nfts was that was assisted by our company in a kusama network with another implementation non-evm. But we really see it worked really well. Hundreds of projects, I didn't use them, so the next step was going to evm.

A

So I extended a lot in this first point, but then other features that makes us unique is that we have virtually unlimited nesting. So you can really easily create multiple levels of nfts owning other nfts and you can get a clear direct ownership, so you don't have to do extra calls account abstracts that account or something which the nft owns. And then this owns the nft. No, it's the nft directly owning the nft, so you can really go through the tree uh very easily. uh We can in deployment detection, we provide it's a loop safe.

A

So one thing that you could have is that you by mistake send an nft to its sparring or to some grandfather or grand grandfather. So we we actually check for this, which makes us go a bit against the second point of virtually unlimited nesting, because we cannot check unlimitedly. So we went for uh in the implementation.

A

We went for I, think 100 Levels, so we will check up to 100 levels to make sure you are not nesting an nft into one of its ancestors and if we don't, if it still goes- and there are more owners before we reach to an AOA, then we will revert so the implementation it's Loop, safe and something very important with which Jan already mentioned is the anti-span mechanism. So this is something that was I think a bit, uh so some people are having doubts about it. It was a bit controversial.

A

Controversial is to what I was looking for, because in many cases uh people will want to just have collections that can directly receive nfts without having to go to the proposed accept mechanism that we, that is part of this nft. So our reason to do that well, Jan already explained we want to prevent spam and we want to prevent especially security attacks, because maybe yours you receive an nft in two years and when you're trying to transfer it out you're interacting with the other contracts.

A

So we have this in mind, so we have ways to abandon or reject an nft. That was sent to you without interacting to it. So basically the parent will forget that this exist uh for the child.

A

It will still be owned by the parent, but it's no longer an issue, and you will not see it in your in your wallet so and in the case, because we we are, we have seen these cases, obviously where you want to Auto, accept some collections, because it's usually like that you can easily uh use the hooks that we provide in the implementation to check.

A

For instance, if it's from a custom white list of collections, you will directly accept it into the active children, bypassing the dependent children, so it makes the flow easier for the users for the folders, which are using these nfts uh and it's suitable, but by default we went for safety first. So if, unless you do a custom implementation, the the nft is proposed and then the owner has to accept it or not, and one of the really important things were also different to others. Is that this is power and govern.

A

So we try different approaches where it was the we. We tried also like doing it from child perspective, that it was the child who had power over the parent and we tried multiple combinations, but in the end, after amounts of testing and looking for Flaws, we came with the conclusion that it needs to be powering govern. It needs to be only the power in the direct powering of an nft, the one who can manage it. Otherwise there can be yeah sneaky ways of using it. So so this is an important concept for us too.

A

One thing I I want to. We wanted to make a bit of clarification. Isn't this transfer child method? These are very powerful and it's cultural or implementation, because it allows you to do all different operations. This is how apparent nft can manage its children. Okay, so among the things it can do, it can reject a child. So remember we have this proposed. Accept mechanism, so uh nft is proposed into mine, and I can either decide to accept it or reject it.

A

If I reject it, it's this for operation, so the child was spending and I will send it to no address to address zero and to destination ID 0, because it's not is going 250. You can also abandon a child which is basically the same, but when this second child was already accepted. So the difference is that you will call this function with spending equals to false, because child is on the active set, but it has the same effect. The child is forgotten, but these two methods have in common that they have.

A

No, they do not interact, they don't try to interact with the child nft. They just remove it from the pending or active list of children. This is important for security.

A

You can also unnecess a child token, which would be the third case where you would send towards the root owner and with a destination ID of zero, because the destination is not an nft. You can also transfer it to another address or an ERC 721 receiver by specifying the address and no token ID no destination ID.

A

And finally, you can directly transfer a child token to another parent to another nft by setting the destination collection as the two and the destination I did to the ID of the destination token, and on the other side, it probably will need to be accepted manually by the holder, unless it has. This Auto accept mechanism that we discussed yeah.

C

Another cool thing is that we can use this to transfer the token normally so in a sense, if you use destination, ID 0 and you send it to and user address, it behaves similarly to a near C720. One transfer- and this is this- is something that was also really important to us when we were designing the proposal. So basically that if you are able to interact with a ERC 721 nft, then you can interact with this.

C

You might not be able to transfer child so to do nesting operations if you don't implement 6059, but you can still transfer and receive and sell it on the marketplace if you want to so. This is something that's really cool it. The nastable tokens Can already be sold on the marketplaces. So that's what I I think is cool as well, so the EIP process for ERC 6059 was a bit different from uh 5773, because this time around, we already seen the differences in the EAP process, but we're still needed to try new things.

C

So one was the the mermaid diagrams that Steve Steven actually showed on the previous slide. So when you write them in markdown, they render just as on the previous slide and they show up on GitHub. So when we open the pr everything looked okay well, once it got merged and it got added to the site, only the markdown code was shown and it wasn't rendered. So we needed to fix that and then uh so one of the things that we usually do I mean I. Think we actually always do it on our proposals.

C

Is that in rationale, we kind of do a number list of things that we considered while designing this proposal. So the issue here was that again, while it looked okay on GitHub, when published, all of the items in the number list in the number lists were numbered as one so we needed to kind of did a hacky solution for that.

C

I think that the only thing they didn't end up looking the way we want wanted it to was the spacing between the spacing between the the entries, but all in all I think it we're still happy with the result. So that was that was nice and one of the things that we noticed.

C

Also is that it took so long for for us to get from the pr to the draft stage that we already got questions on the discussion Thread about why people cannot find our proposal because I actually remember so, we published we opened the pr on the 22nd of November and the question got asked on 22nd of December, so there was a month Gap that our proposal was still in limbo, but yeah once it got merged. There were no more issues and it was a learning process.

C

So right now we we usually managed to get it merged into drafts in less than a week. So we're learning before.

A

We go to this Thursday things. That I would like to mention to caveat that I just realized we didn't put into into this presentation. The first one is that it's included in the security considerations and all these I'm saying it's part of the ERC document.

A

But it's important to to highlight first, is that you need to be careful if you're implemented, for instance, a Marketplace which has uh support for this kind of tokens, because it could be that I I put into sale an nft which holds two very valuable nfts, for instance, and just before selling it just before the buyer accepts the deal or hits buy. I could remove one of the child or the of both children and make it less a lot less valuable, so the other party would be getting less than they expected.

A

So it's important to to keep that in mind, for instance in our Marketplace we do it. But what we do is that when we hit buy, we send a list of expected children to be there and if it doesn't match it will revert just an important security consideration for your users and the second one is that we had to forbid the use of token ID 0. this. We also got some complaints by this, but it really made everything much simpler and cheaper. So one of the things that drove this implementation was also gas savings.

A

If you see in some of the, for instance, in the accept children, accept child methylating and the reject child, we not only request the contract, the address of the child in the ID of the child, but we also requested the index from the active or pending list.

A

So this might seem redundant, and it is indeed, but the thing is we couldn't live with just one I think initially, we just had the index because it's the cheapest thing we, the the easiest way to implement this proposal, is to keep a list of active and a list of pending children per token. So the easiest way to do lead.

A

One is if you're familiar with evm is, is not to look for it and match the address and token ID combination, but to just go directly to the index where it is and swap it with the last element, because it's just two operations, you swap one and delete the the last one. This is how you would handle this usually on evm, because otherwise it's very expensive. So the thing that could happen is that this list could change in the middle.

A

So before doing operations like accepting or rejecting or transferring a child, it could happen that something else goes before. So you would be transferring or accepting the wrong nft. So we also needed to include the contract, the expected child contract and token ID, to be sure that we are we're transferring or doing whatever operation with the right token and the reason we can not just do that and omit the ID is because otherwise we would have to Loop through the entire list to search which would again be super expensive.

A

So this was something very valuable from the from The Forum and it might seem redundant. But this is, this is the reason.

C

A

Something similar happened with token ID. We discovered that it made things much simpler to assume that when you got the direct owner of an nft had a token ID of zero, it meant it was not owned by an nft, and this is simpler on evm also a bit technical here, but if you're familiar, if you get, for instance, if you have a mapping where the value is a an integer, uh if you try to get for the value for a kid that doesn't exist, it will default to zero.

A

It will not revert but give you zero. So this could, unless you were very careful and all implementers were very careful. This could lead you to believe that this token was owned by a token with ID 0, which exists on some collections, but we we saw this as very dangerous and the way to prevent it was very expensive. So we just decided to do this also point controversial requirement of not allowing token zero in our collections.

A

We also were asked like, for instance, in case that someone wants to make great a collection into this standard, what they can do in the solution. We are creating is that you can wrap the collection and then Rob tokens individually. So you get all these functionality and, in the case of token zero, since we cannot have it, uh what we will do is we will map it to the max Supply, because it's the last token that if you start on zero base index that wouldn't exist.

A

So it's like a trick that we would suggest there if you want to upgrade an existing collection which uses token id0 into any of our erc's.

C

So uh another thing that we also consider is is contract check, but that is at the same time not secure because it can be manipulated, so the smart contract can return the false for that as well. So this also kind of falls into why we picked id0 and another thing for marketplaces or anyone.

C

Transferring the token to consider is that once you get the parent token and it's child tokens reported by the battery token, it's good practice to validate from the child as well to validate the the parent token owes it, because if you have a malicious token, it can report all child tokens as well. So another thing to consider so this time around, we also prepared the link tree, which is the same with additional resources. So it's link three dot, slash erc.remark rmrk, and it includes all of our proposals ercs as well as eaps.

C

It includes links to our additional resources, so learning resources, development resources. So these are documentation of our evm package, page and subsequently of our ercs and eips. Our.

A

Templates template yeah.

C

And Steven's video tutorials, uh where he used all of them and I I, think a bit more goodies, but really just a lot of information and yeah. That's it from us. uh Thank you again for having the opportunity to talk about 6059 and if anyone wants to reach out to us, we are J.A, underscore Yan Turk and stoic Dev zero on Twitter. So we're also available there to to answer any questions that anyone might have.

A

And I'm sure polia will have some interesting questions for us.

C

Looking forward to them as well, thank.

B

You thank you so much for the best presentation. I mean it was really really great I, really like the the way that you guys have explained. Nestable nft, like nft in a tree, people, love, trees, I, guess and uh cryptography. We have mercury Patricia tree worker tree and now we are going to have nft trees. So.

C

B

Quite interesting, well uh learning about the thorough testing that the team went through uh testing up till 100 levels. That was incredible and this resources shared I'm sure they are gonna, be valuable. uh The first time when I learned about the npm package that you created for the earlier proposal, that was great I'm hoping uh the package shared for this proposal will also be helpful for obviously the hackathon participants and students who are looking forward to learn these proposals.

B

So thank you so much for putting all the effort into it and yeah I really appreciate the EIP process. Feedback we'll take it with some grain of salt. I understand the process wasn't perfect and it is still not. We are trying to improve it.

B

Every day we have recently added ERC, editor and EIP editors as well, so we hope the process will be smoother in future, but thank you for bearing with us, um I I do have a few questions for you, um while going through the presentation, some of them were already answered, but a few, more probably to add some clarification nesting, as we can see with this presentation that has a lot of advantages. I wonder if there are any compromises or concerns with the proposal that people should be aware of.

B

Do you think it is gonna increase the cost of nft, maybe because it's making the contract a little heavier or maybe because of the high gas one.

C

Is definitely the ID 0 that we already mentioned, and we also mentioned a kind of small list of security considerations that you need to keep in mind.

B

C

Another thing is that we are extending a 721 which means that your smart contract will be bigger. If you implement it, so deployment costs will be higher as well.

A

Yeah about gas, we were actually very careful about this in our custom, implementations.

A

Well, actually, in the core non-opinionated implementations and also on the right to use implementations, we really did spend several I, don't I, think tens of hours uh in reducing gas and reducing size, because when you, when you start adding and stacking up all these Lego erps you, you start getting uncomfort uncomfortably close to the 24 kilobytes limit for magnet, but for gas we have checked these operations like when we run our test Suite or we get a report of the average gas like mean Max and average gas used by each of the operations, and we found that in all cases, this new operations, 201659 ads, are very close or like very similar to the cost of transfer, transferring or minting an nft.

A

So, of course, there are more operations. So if you want to do more things, uh well, you you need to pay a price of course, uh but it's not like uh like it won't be an order of magnitude higher at least we are sure of that they are at most twice as expensive. They're, like the most expensive operation, could be at most twice as expensive as a transfer I mean. So we we don't expect this to be a problem. That's.

B

Good to know very well um so another question which is slightly related with it when we are getting into this nested nfts. um You did mention about parent governed security feature that is added to this proposal. Do you think, uh generally speaking, nesting increase the vulnerability, I understand that nft can be patent and it can also be child. So if it is a parent that means it will have the governed security. But what would be the level of vulnerability that it will be exposing to hackers if they are trying to Target one level I.

A

Think, besides the the possible issue of removing children before you sell them, or something like that, there is nothing new that we add, because that that's the actual reason why I will pick this model of it's the owner or the parent nft, the only one who can do operations on this one, even if like, if you approve this token, to be managed by some Marketplace.

A

But then you send it to another token, then that there's no approval valid here only this one can interact with the child and transfer it and do approvals and anything so and yeah. This token can be transferred to another one and it becomes a child in a partner. At the same time- and in that case, it's the new parent who has the full ownership and the only one who can handle it.

A

So as long as you don't send your nft into a vulnerable vulnerable collection or a malicious collection, you should be fine, but that is important one to try to clarify. If you send an nft to another, you are effectively giving away ownership. It's not that other nft who is the owner and if you send it to an nft from a collection that is malicious. That, for instance, has a back door to transfer children to another address.

A

Then it's your responsibility, just as if you interact with a Marketplace, and you approve a Marketplace, a malicious Marketplace to sell your contracts, you can just steal them or if you approve your erc20 tokens on a malicious swap site, it can also steal your targets. So I, don't think there's nothing besides that, besides make sure you don't send your your valuable nfts into a collection, you don't trust and.

C

Don't accept uh tokens that you didn't Nest or didn't expect to receive yeah totally right.

B

That's very important, while talking about.

B

A proposal being useful for inter collection, right, I, remember a proposal which was there for Multiverse nfts, and the number is 5606.

B

so I'm trying to understand here like when we are getting into this nested nft concept and we are trying to send the entire set to a different Multiverse. Will it act exactly the same way or uh will there be any feature, change or properties change? We are expecting.

A

But it's about bundling so I think what this does is like you can uh create, like you, merge or bundle multiple tokens into a new instance. So that's a huge difference there, because you create a new concept, which is the bundle, whereas in our case there's not new things, there's just a new relationship. So this you don't need to have a special handling of bundles, because if you know if, if a Marketplace or adapt already works with uh 721s, it will work with 60 59..

A

It may not show the children if it doesn't implement this uh EIP yet, but all the other operations are transparent, I, don't think it's the case for 5606, sorry to Interruption, but I was just looking at it. Yeah.

C

No, no, that that's okay, so from from what you described, the comparing the proposals, hours as like putting brakes on top of one another and they're they're nested in a sense that they they create a hole and the other one is adding mortar to them. So you cannot really pull them apart anymore or.

A

Actually, maybe you can because I think they they have an unbundle, but but still it's it's a different concept. It's a it's an it's a new thing on its own, whereas here it's the same two parts, they're just nfts with a special ration right.

B

I believe, like whatever suits the most for an application, people have standards to pick up with so yeah that that's there uh talking about this uh nft, like um nested, we learned about a proposal which was hierarchical, nft I'm, trying to look at the number yeah. The number is six one, five zero. So how would you say this proposal? 60 59 is different from hierarchical nfts, which is I guess in the final Style uh status. Right now,.

A

Yeah I I remember this one, so if well, if I remember correctly, this is specifically for nfts, which can be nested into the same collection. So this is a huge limitation. It may work for some years cases if, for instance, if, if you create nfts or folders, then it makes sense that they can only be nested into folders. But if you.

B

Want to send this NFTA.

A

To another collection, it won't be possible so yeah, it's a huge difference. There.

B

I have a question um from The Fellowship of ethereum magician page a few days. After being final The Proposal received a comment by a user midnight lightning. Apparently this proposal doesn't fit the definition of what is Backward Compatible I'm wondering what are your thoughts on it. Yeah.

C

We we also saw the comment and uh we we realized what it's about. So, if you have an ERC 721 token, you cannot Nest it into a 6059, because ERC 721 doesn't have the required tools to be nested into a token. It's meant to be owned by.

B

C

Owner, that's what we call the the top level owner that can manage all of the tokens, but what we were referring to is that everything that exists out there, so the two links from packages to development Frameworks from chain explorers that can now or now present nfts to marketplaces everything that's compatible with 721 will work with 6059, but the tokens themselves phone.

C

So this is where we kind of stepped apart from the backwards compatibility, but we really put much salt into how we can be as close to 721 as possible and send conventions even are reflected in this way, so minting, for example, isn't specified in 721 either. Neither is burning, so we omitted those from our proposal as well. We really made sure to kind of follow it in a sense that we don't modify it or override anything that it there is to just add new functionality, but yeah I mean it's not 100 percent, better backwards compatible.

C

If you consider the implementations, but if you consider everything else that comes within with 721, then I'd say we're 90 95 percent there yeah.

A

But it was a actually this, the this guy you're you're, mentioning he. He did really interesting comments in this and other of our erps. uh He has been a great contributor and he has pushed us to improve, for instance, the immortal CIP, which is 63.81 so to to be much better and and to make sure that it will be used for the I know a hundred years, uh but here uh actually we intend to to do a minor update to reflect this, because it's it's a I, don't know it comes down to semantics.

A

I think uh the way we we envision it as more compatible, but we understand his point uh in that. In that aspect it is not for work, it is a power compatible. So we will uh update to to make sure it's clear. uh We just haven't had the time.

C

Yeah I mean when you get someone like this uh commenting uh on your proposals, you're, not even mad- that uh your proposal is not finalized for another month, because the Improvement is so great speaking of it's uh evotable, so 63.81.

B

Absolutely I totally agree and that's the benefit of having this one central place for discussion where we let people know that this is a place where you can share your feedback, where authors will read them and probably will Implement them. So it will be better for us for other project implementers to get the better version of The Proposal that we were expecting earlier and keeping the proposal close to seven to one I think that is a good thing to have because most of the project developers they start from.

B

If the proposal is about nft, they start from seven to one so closer. The extension is it will be easier for newer developers to follow through so yeah thanks for that, the other day you talked about the EAP editing office. Are that was very good feedback while I have you here today may I get your thoughts on Peep and eat CDs. When and how did you hear about it? And will you recommend this to other authors? What are the kind of topics that you would like to be included in this yeah.

C

I I mean I. I, really think this is a great Forum on how to present your EIP I. Guess it. It is shaping you up to be or I mean it already is. It has more than 100 episodes to be the place where, if you want to know what's going on with the standards and in the ethereum ecosystem, that's where you can come and hear all about the new developments, because beforehand, I I mean I.

C

Remember my first proposal, that's now, sadly stagnant, but back then there there was no other way than the page, the repository for eips and ethereum magicians, but that that can get overwhelming.

C

If you try AI to keep up with everything, that's going on there, it's kind of hard, and you need to read through everything that this way everyone cares everyone, meaning the authors, can showcase what they think is the most important part of their proposals and I think that's really beneficial, and as for sharing uh sharing this I know, I I will I actually talk to my Master's thesis mentor and he asked for it to be shared, so he can share it onwards as well and to anyone. That's writing the proposal.

C

I I really suggest that once you reach last call final, and he starts thinking about us to start presenting your proposal because there are a lot of finalized proposals.

B

C

Some of them are really good and way underutilized because you just cannot find it find it. So everyone will really appreciate, appreciate you coming here and talking about your proposal. Well,.

B

That was the initial idea of starting this series. We wanted to provide a platform for authors to be able to share their proposal and Implement us to get to know the proposal even better in a simpler way. I understand to implement this proposal. Implementers has to go through the entire documentation, the aspects but to have an easy to understand version. A video version is helpful in my mind, so yeah. Thank you so much for the feedback and I hope we continue creating these resources to help users of ethereum community.

B

Well, we are at times, and we should wrap up now any final thought or message to the community that you would like to share yeah.

C

It's like I just like to thank you again for having us for giving us this opportunity and to all of the ethereum Caterers, because throughout the process we we've had help from several several members of your team and I'll wrap it up here, because we'll talk again in two weeks, so I'll prepare something longer. Then yeah.

A

If you want to do the same invitation to builders to to go and check uh all these amazing tools that we are building and that other people are building to make nfts much more powerful uh and for holders and Visions to to ask for their collections to look for innovation in in what that they are buying and to literally ask the owners of the collections to to move forward to not stick to 721, which yeah it's great. But it can be a lot more than that. And thank you of course thank.

B

You so much thank you, Stephen Ian, for um we really appreciate you taking out time to provide an overview of proposal 6059. We look forward to see the standard being adopted by NFC projects. On this note, thank you to all our YouTube viewers for watching and ech podcast listeners. For following this talk. Should you have any.

B

Don't forget to like And subscribe to this channel for more talks on eips and protocol upgrade cheers foreign.

B