NFTy Magicians Update November 2018
ERC721 Non-Fungibles, ERC998 Composables, ERC1538 Transparent Contracts
Summary of the November Call
The call got started with introductions, sharing what we are working on, and where we based our work out of. Haley gave a brief recap from the October call before the fantastic conversations surrounding ERC1538 transparent contracts and ERC998 ownership loops began. Mintable announced their alpha release date, December 1st, 2018. Natalie shared the results from the NFTy Magicians Call Survey. There were several requests for collaborations and MeetUp opportunities. Please be sure to reach out and join the party!
Be sure to add the NFTy Magicians Call to your calendar!
Introductions by NFTy Magicians:
Discord Handle given first, followed by a brief introduction.
- Abhi (Abhi, CryptoKitties) — Vancouver, British Columbia, CA. Helped make Kitty Hats and has an interest in ERC998.
- ChristianHentschel — (Chris Hentschel, TradeStars) Buenos Aires, Argentina.: Trade Stars in a fantasy sports DApp using composable NFTs. Chris the joined NFTy community early on.
- Impact — (Eric Muyser, HyperBridge) — Vancouver, British Columbia, CA. Heard about the community from Alexandra Moxin. Eric wants to see more widespread adoption and would like to collaborate. Looking at ERC998 and Dr. SES.
- Flockonus (Fabiano, CryptoKitties) — Vancouver, British Columbia, CA. Learned about NFTy Magicians community from Matt Lockyer. ERC998 bottom-up interest.
- Hsummers (Haley, Mokens) — Reno, Nevada, US. First heard about ERC998 and NFTy Magicians from one of the early updates Matt Lockey wrote. Joined Nick on mokens when it was in beta.
- Jomessin | OpenSea (Jordan Messina, OpenSea) — Syracuse, New York, USA. Did Kitty Hats w/ Abhi, interested in NFT space, especially Marketplaces.
- Missingno. — Mic issues :(
- Mudgen (Nick Mudge, Mokens) — Sacramento, California, USA Co-Author of ERC998, Author of ERC1538, Founder of Mokens.
- Nathalie-ckc (Nathalie Chan King Choy)- Vancouver, British Columbia, CA — Met Matt Lockyer, the NFTy Magicians, and ERC998 founder, at a conference in Vancouver in May and joined after that.
- Scottrepreneur (Scott, Website) — Austin, Texas, USA. Tried to put some stable coins into a Moken and trying to see how to get NFTs mainstream.
- Spaded (Zach, Mintable) — Bangkok, Thailand (originally California)- Been working in ERC721 since CryptoKitties came out at the hackathon and did beta testing. Working on Mintable.
- Zoup | Nonfungible.com (Zoup) — Paris, France. Co-founder of NonFungible.com with Dan (Dafky2000). I would like to bring transparency to NFT markets and awareness to upcoming NFT projects.
ERC1538: Discussion Lead by Nick Mudge
Use of the new ERC1538 as a contract architecture for NFT contracts.
ERC1538 is a way to upgrade smart contracts over time, add functionality, and evolve. Nick came upon this when making Mokens. Mokens is ERC998 (Composables) and wanted the contract to be able to grow in size but a contract can only be so big. After doing research, the closest thing found related to this was OpenZeppelin VTables. Nick decided to propose the ERC1538 standard since the existing upgrade standard does not address growth in size. ERC1538 is also transparent by nature. This is to address the issue of trust related to upgradeable smart contracts and security implications. Making them transparent make upgradeable contracts more trustworthy by publishing changes in a visible and provable way. The idea similar to open source software and source code version control.
Question from Fabiano:
What will users think since smart contracts are supposed to be immutable?
Answer from Nick:
I would like the UI to show very nicely how a contract has changed over time. I would also like to see security and domain experts vouch for contract history, that the changes are really improvements and not shady. I could also see a smart contract having multiple owners instead, of just one owner who can make the upgrade. This would reduce the likelihood of a single point of failure, like an owner’s private key got hacked. You could then have multiple owners send a transaction in order for the upgrade to proceed.
Commentary from Missingno:
At Eth SF, the Aragon team was creating something like a Github repo for the hackathon.
Commentary from Fabiano:
Maybe some governance could help. For example, add to the contract that after some number of blocks make the change go into effect. That way people have heads up and can see the changes that will be coming. Adding functions may be trivial, updating an existing function is more likely to be contentious.
Commentary from Abhi:
Agree that folks need a warning that a function will be changing, especially if it is an actively used contract. Could have bad user experience if someone is in the middle of using a contract when it is changing.
Commentary from Eric:
Upgrade/change question is important not just for this proposal, but for a lot of systems. Maybe trial running the results of an upgrade would be helpful. Want to make sure ownership of assets of the user will not get affected.
Commentary from Nick:
Would like to see best practices develop. One possible strategy, if you have a function that works well, do not change it. But instead, if you want to add functionality, could make a new function that adds functionality, instead of replacing the original function.
Commentary from Nathalie:
In traditional software engineering products, when a new feature comes out to replace an old one, often times there is a deprecation period of the old code after the new code comes out. This gives users time to transition from the old code to the new code.
ERC998: Discussion Lead by Flockonus (Fabiano)
Bottom-up rootOwnerOf method, ownership loops.
CryptoKitties have been looking into rootOwnerOf, mainly looking at bottom-up use cases of Composables. The rootOwnerOf can follow a chain of ownership in 998s or 721s. They have had some thoughts on what might not be ideal. For example, if you own item A and B and in an extreme case set A to be owned by B and B to be owned by A. This creates a loop that would run out of gas. The long chain of ownership could become unpredictable for gas. Has anyone considered whitelisting/blacklisting some tokens or a certain number of hops?
Question from Zach:
Can you check for ownership before doing the transfer?
Answer from Nick:
I tried but did not work. Alternate approach: Users will probably use a web UI. The UI could check for the loop more easily before doing the transfer.
Question from Zach:
Could you have a mapping?
Answer from Nick:
You would have a record of what children are owned by an NFT.
Commentary from Zach: Mapping or array of children could be checked before transfer, or if a token has code
Commentary from Nick:
Works for A-B case. When you introduce a deeper chain of ownership, it gets more complex with composables when A owns B owns C … owns A. Interested in hearing more about the potential better way to do it — probably best to discuss with code. The ERC998 reference implementation is posted in GitHub. Happy to discuss and/or get Pull Request.
Commentary from Fabiano:
If you have 998s that attach themselves to other 998s, that’s when you get the possibility of a long loop in the graph. If you have 998s that attach themselves to 721, it is more straightforward. Solidity does not have mappings in memory, so hard to do detect loops at runtime with reasonable gas usage.
Commentary from Nick:
Gas problem with loops. If no loops, it does take some gas to recurse but not too much gas in most cases.
Question from Abhi:
Does anyone on the call have a use case with a long chain of ownership? 998 could do a lot but should focus on the real use cases first.
Commentary from Haley:
Trying to figure out cases why you would intentionally have a loop. Analogy: Pack of NFT wolves attached to a single head — easy to decompose. If chained to one another, harder to decompose.
Commentary from Nick:
Yes, could see that loop could have some functionality in a game and people add their own custom functions on top of the standard.
Updates from the NFT Alliance: Discussion Lead By, Hsummers (Haley)
0xCert reached out to various organizations working on NFT projects to joined the NFT Alliance. The NFT Alliance formed to close the communication gap between different project’s needs and create a platform for partnerships. If you are interested, reach out to Haley or Urban:
- Haley Summers: haleyrebeccasummers@gmail.com
- Urban Osvald: urban@0xcert.org
Updates from Haley on Crypto Invest Summit in Los Angeles and World Crypto Con in Las Vegas.
People are finally starting to catch on to NFTs. Two different people got goosebumps I told them about composables, tokens owning other tokens. One of the best conversations I had was with Sky Minert from the POA Network.
POA Network is a sidechain to Ethereum utilizing Proof of Authority as its consensus mechanism. POA provides developers with the flexibility to code in Ethereum standards with the added benefits of POA Network’s solutions to scalability and interoperability in blockchain networks.
POA Network has a bridge for Ethereum ERC20s and ERC721s. There are two NFT games on POA already, Everdragons and DopeRaider. Sky is interested in talking to other DApps who would like to deploy their smart contract on POA Network or migrate their tokens over the POA bridge.
Summarized feedback from NFTy Magicians Call Survey: Discussion Lead By Nathalie-ckc (Nathalie)
Infographic of results.
Community Updates from Natalie
Nathalie and Zach (Spaded) were able to connected in-person in Vancouver in early November at DCTRL in Vancouver.
DApp Update from Mintable: Discussion Lead by Spaded (Zach)
Mintable alpha release will be December 1st, 2018. Anyone will be able to browse ERC721s like BlockExplorer. Pictures are in the NFTy Magicians General Channel. Anyone interested in testing Mintable or participating in the alpha release, please contact Spaded (Zach) on Discord.
Requests for Collaboration from Eric Muyser
Eric would like to achieve for NFT assets to allow then another game developer to add functionality to the NFT, use the upgraded functionality in another game, and then have that same NFT propagate properties upward to the original game. However, game directors will not do this until it works fluidly, the economics are sound, there is trust, and high usability.
There is a Chicken and egg conunrum here— they won’t do it until we make it easy.
Dr. SES is a project by Google researcher Mark S Miller. Miller is creating Agoric, a javascript smart contract system. SES containerizes permissions and actions in a way that allows interfaces to share data in a secure way. Everyone is all building these cool interfaces and SES creates a secure promise for data to be shared. That way everyone is not reinventing the wheel.
Hyperbridge is going to build a 998 marketplace into BlockHub. But BlockHub is being designed to be a DAO driven environment for blockchain solutions to collaborate. Hyperbridge does not want to redo everything that is already being done, just to add 5% effort on top as a 1up. It would be better if the interfaces were sort of plug n play. That is a win-win for both sides and is huge a win for blockchain. Please ping Eric for further conversation on this topic.
Upcoming NFT MeetUp
NFT Miami Meetup will be happening on November 28th, 2018 hosted by Giani D’Alerta.
Be sure to add the NFTy Magicians Call to your calendar so that you can join future calls!
The NFTy Magicians Monthly Call takes place on the 2nd Tuesday of the month at 16:00 UTC in the General Voice channel of the NFTy Magicians Discord.
We accept suggestions for the agenda in advance of the calls. If you’d like to add a Non-Fungible Token-related topic, post it on our Discord and @-mention nathalie-ckc to make sure it gets recorded.
The NFTy Magicians hold monthly meetings! We invite you to join the Discord Group to be part of the NFT movement.
Author:
Haley Summers
Edited and Co-Written By:
Nathalie Chan King Choy
Nick Mudge