Crypto Composables ERC-998 — Update 4: “The Namening”

Recap of the 2nd Composables call: tons of discussion, work in progress repo, organizational mastery and moreWhat’s in a name? Corny enough for you? 🤣 PexelsBackground and Recap (skip if u hip in a 998 whip):

• Introducing Crypto Composables
• Crypto Composables ERC-998 Update 😊
• Crypto Composables ERC-998 Update #2
• Crypto Composables ERC-998 — Update 3: First Contact

The Namening

Why the “Namening”? 🤔 As we get closer to a standard interface for ERC-998 Composable Non-Fungible Tokens (CNFTs) it’s important to keep in mind the abstract and general purpose a standard extension to Non-Fungible Tokens (NFTs) will serve.

Several projects are already attempting some form of composition on Ethereum as I’ve mentioned in past updates. Our intention as a community is to converge on an interface serving most projects and use cases and stay open for extension. Naming functions, variables, comments and sample implementation code is a huge part of this. We’re hoping to settle on our nomenclature soon and reach consensus, however this could take time.

I will recap the broad strokes of the call below, but first would like to thank everyone on the call for their ideas, energy and enthusiasm. We will develop a fantastic and flexible interface that will suit the needs of a majority of projects on Ethereum (and perhaps even other chains). I’m confident in our ability to work together to achieve this goal and increase the pace of decentralized application development. 🤗

🧙 NFTy Magicians Rock!

Special thanks to Nick “solidity / gas” Mudge aka Mokens who’s been helping with the WIP repo and Nathalie-CKC who’s been guiding the project management with her experience in OSS PMing. And of course, can’t forget Maciej Górski who’s working on Composable Registries.

Join us on Discord

Attendees

• Abhi
• Chentschel
• Dan
• Jomessin
• Jwaup (joined pretty late)
• Maeste
• Matt Lockyer
• Maciej
• Moskalyk (was having mic issues & could not speak — I think pasted a question to #composables)
• Nathalie-ckc
• Nick Mudge
• Trung | Axie Infinity (joined pretty late)

Agenda

• Nick Mudge generic function such as tokenTransaction on a composable to call any available function in a child contract;
• Matt: I would like Nick Mudge to present his proposal for deeply nested tokens, I think there’s a possibility of a solution, Sub-tree operations in CNFT?;
• Nomenclature: NFTs -> parent / child; FTs -> balances; Consensus?;
• Nick Mudge and I think that nomenclature for ERC-20 balances and child tokens needs further discussion;
• Nick Mudge and I think that nomenclature for ERC-20 balances and child tokens needs further discussion;
• Nathalie: Where to keep track of to-do/backlog of ERC-998 code tasks & who’s working on them & discussion around each? In Github issues?;
• Recap: Fire callback or event when NFT is removed from CNFT? Callback;
• Recap: Approval needed for other contracts to add / remove, to / from CNFT;
• Recap: Standard events needed? Yes. Any takers?;
• Recap: Continue to explore ways to interop with Composable Registries;

The “Unpackening”

Off the bat, Nick introduced 2 new possibilities for dealing with sub-tree composable child functions and management.

1. A tokenTransaction function that would serve as a replacement “call” function for calling any functions on the child contract
2. A recursive lookup function to determine if the sender of the composable function call transaction is in fact the root ower.

🚨 After hours Nick had explained that tokenTransaction required a lot more research and it would be potentially unsafe. He’s decided to scrap that direction for now, but it’s still open to the community if someone can develop this proxy like behavior while keeping things secure.

Nick’s recursive lookup function has been implemented in a rough draft and looks like this:

function isApprovedOrOwnerOf(address _sender, address childContract, uint256 _childTokenId) public view returns (bool) {

uint256 tokenId = ownerOfChild(childContract,_childTokenId);    if(super.isApprovedOrOwner(_sender, tokenId)) {      return true;    }    address ownerUpOneLevel = ownerOf(tokenId);    return ERC998PossessERC721(ownerUpOneLevel).isApprovedOrOwnerOf(_sender, this, tokenId);  }

What we’re doing here is basically checking if the _sender is the owner of the parent token needed in order to transfer or call a function on the child token. If not, then we will call this very same function from the contract that is the parent token owner, asking again isApprovedOrOwnerOf. Recursion is no easy task in regular programming and least of all when you’re concerned about storage and gas costs. Thankfully, function calls like this only cost 2,000 gas units. Nick’s managed to pull this off for now and I’m excited to support his efforts.

Would You Care for a Diagram?

I started to see a pattern when discussing all the complicated ways tokens can be transferred to other tokens, different sub trees etc. We need some guiding diagrams we can all agree on to inform these calls. I’ve decided to take that on and hopefully will finish soon. This will probably form a more detailed post covering on-chain composite design patterns. While keeping the nature of the problem abstract, diagrams will help guide a lot of the discussions as they visually remove ambiguity and allow everyone to see the same concept more clearly.

This helped tremendously on call 1:

The Composite Pattern from Java design patterns and WikipediaNomenclature aka the Namening

Gotcha! 😁 If you were expecting big news, there isn’t any.

We didn’t reach consensus on anything exciting related to naming on this call. However, there are some strong ideas that were put forward. Namely using the names of standards in our standard. That would look something like this:

function transferERCOf(address to, string ERCStandard) public;

As a recap from the last call, we’re all on board with using parent, child as the naming convention for NFTs owning other NFTs, however this breaks down when an NFT owns a balance of an ERC-20 contract. We also run into a name collision due to the multiple inheritance of ERC-998 as both the NFT and FT extensions can be inherited at the same time. This creates even more headaches as naming should be consistent but cannot clash. Nuances for sure, but it can be particularly frustrating down the road if we don’t get these name right.

Events

Maciej Górski had a great summary of all the unique events that could possibly be fired with Composables. It goes something like this:

• NFT transferred to CNFT
• NFT transferred from CNFT to EOA (wallet)
• NFT transferred from CNFT to CNFT
• …

I believe there were 3 in one case and 7 in another. He hit a wall with some restrictions in ERC-721 and needed some more time. I will back-channel with him on this and update the post.

Callback or Callblock?

Callback functions that return a true or false (boolean) based on certain conditions, can be used to restrict the transfer of child NFTs. This allows for behavior of casting a spell onto a game avatar that cannot be removed by transferring out the spell NFT.

We are all in favor of supporting callbacks that limit the transferability of tokens. Now the responsibility falls on decentralized app makers of “sticky” tokens to design them well. Let’s see how that plays out 😂

Proxy Composable Token? Upgradable Contracts?

The last idea suggested was my own and I wanted the community to mull it over and see if this was something worth exploring. Given there are so many NFTs already in existence and ERC-998 is intended to be an extension to the ERC-721 standard; complementing it with new functionality that is also standard... Why not make the “root” CNFT a proxy for an existing NFT. There is the question of the added mapping, however is 1 storage operation per upgraded NFT token worth it for all this new functionality?

The response was fairly positive. While there is some concern over loss of functionality with the older token, I feel that this may be able to work. Related work can be found here in the form of upgradable contracts by the Bitclave team.

WIP Implementation

We’ve got a working repo… for now 😆

mattlockyer/composables-998

Be gentle, it’s a WIP. There’s times when the tests may be failing due to some massive overhauls of the interface. This is normal growing pains for an early stage project.

😉WINK WINK😉

A great way to wrap your head around a new project and repo you’re considering contributing to is to help fix small things like test cases that may be broken, writing new tests and increasing coverage. We’d appreciate the support a lot! 🤗

Organizational Mastery

Once again, I would like to thank Nathalie for her suggestion of discussing how we work on the WIP and tackle things like Todos. We’ve decided for now to continue using the Discord for chat and GitHub Issues for our “close to code” tasks. Thank you Nathalie!

😃 Bonus, she also took amazingly detailed notes from the call that can be found here.

Wrapping Up

Wow that’s a lot of updates! Thank you for keeping up to date on ERC-998. The community is growing and work is underway. We’re hopeful to provide a valuable resource to the Ethereum community in the near future. A standard interface for composing tokens.

My name is Matt Lockyer. I have no job, no affiliations and no tokens to sell 🤣 I love saying that. I started ERC-998 because I saw the wave of projects coming that would need to support this functionality and wanted the community to work together to do it right. I am not Mr. Composable or Mr. ERC-998. I am not the leader; only the facilitator. I’m here to work for the community and synthesize the ideas, design and knowledge of my brilliant colleagues.

We are the NFTy Magicians 🧙 Join us on Discord

Thanks for supporting OSS and open standards!

medium.com/@mattdlockyertwitter.com/mattdlockyerlinkedin.com/in/mattlockyer

Crypto Composables ERC-998 — Update 4: “The Namening” was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.