Initial proposal for ERC2135 and Ticket721 Draft.

[xinbenlv]

Hi Open Zeppelin Community, I'd like to add the ERC2135 and one of its reference implementation to Open Zeppelin repository from https://github.com/xinbenlv/eip-2135/tree/master/impl.

Presubmit CheckList

• reviewed the OpenZeppelin Contributor Guidelines
  (https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/CONTRIBUTING.md),

• added tests where applicable to test new functionality,

• made sure that your contracts are well-documented,

• run the Solidity linter (npm run lint:sol) and fixed any issues,

• run the JS linter and fixed any issues (npm run lint:fix), and

• updated the changelog, if applicable.

Note: I don't know how to update the changelog or whether it applies - @xinbenlv

[xinbenlv]

Give the newly added contract /consumption coverage is 100% https://coveralls.io/jobs/51165007, I believe the coveralls failure is a false positive.

Update: I take this comment back, it's caused by: https://coveralls.io/jobs/51165007/source_files/1550379330#L16

[xinbenlv]

Can anyone kindly help conduct the first review?

[nventuro]

Hello @xinbenlv, thanks for contributing to OpenZeppelin! I'm sorry we took so long to review this.

When adding new features (specially new standard interfaces) we usually look for potential use cases that call for them, or demand from the community. Could you share a bit more about projects you're working on where this need came up?

I can see how burning tokens might be useful (which is why we provide _burn), but am unsure as to whether a full-fledged standard interface for doing so is the way to go.

[xinbenlv]

Hi @nventuro yes, thank you for a review and suggestion, and being both very encouraging and frank for discussion.

Allow me to defend the necessity of the ERC and an standard implementation. I am open to be convinced too.

I think it makes sense to have a burn or consume like ERC to standardize this behavior. The fact that our OpenZapellin version implementation of ERC20 and ERC721 both have found the need of implementing a burn function speaks for a need. This address the "need/use-case" question of a such behavior.

I believe other kinds of Tokens and virtual asset standards are currently being actively proposed among the EIPs community as well as other future interfaces, they will find use-case of consume and the consume activity be recorded.

And the next question whether it needs a ( full fledge) ERC to help standardize such behavior.
I believe if consume behavior potentially have many usages, it's better to have a standard so different implementations or applications can inter-operate.

If the only concern is that is too trivial, I would compare it with ERC-173 Ownership which is also very simple. Such standard, despite having only a few seemingly trivial methods, help people form consensus to how an ownership is defined, what name of function and events should be and what kind of parameters they should have, in what order. These are the value of standardization.

One other thing: actually, you reminded me, that for backward compatibility purpose, whether we should rename the ERC-2135 main function consume to burn, I would like to have your advice.

• burn make it immediately compatible to what is already in OpenZapellin implementation, which already have usage.
• consume is probably more generic to represent its meaning.

Thank you!

[xinbenlv]

Friendly ping for another round of review / response from reviewers

[xinbenlv]

Friendly ping again~

[nventuro]

Hello @xinbenlv! Sorry again for taking so long to look at this, the last couple weeks where a bit hectic with Berlin blockchain week.

I think it makes sense to have a burn or consume like ERC to standardize this behavior. The fact that our OpenZapellin version implementation of ERC20 and ERC721 both have found the need of implementing a burn function speaks for a need. This address the "need/use-case" question of a such behavior.

Your points make a lot of sense, I think this is just me being generally disillusioned with EIPs 😅 My belief is whatever big application comes forward will be the de-facto standard, but I do see the value in thought-out and written-down specs. That said, it'd be great to have the EIP finalized: we avoid merging stuff in draft state, to prevent having to change them in the future.

One other thing: actually, you reminded me, that for backward compatibility purpose, whether we should rename the ERC-2135 main function consume to burn, I would like to have your advice.
burn make it immediately compatible to what is already in OpenZapellin implementation, which already have usage.
consume is probably more generic to represent its meaning.

API stability is very important to us, and I wouldn't want to have both burn and consume methods. In this case it may be best to, like EIP173 did, simply write down a spec for the behavior currently out there. I'd suggest taking a look at how ERC777 does burning, and see if you can imitate that.

[frangio]

I think there is value in stuff like ERC173 and the ERC2135 proposed in this PR. However, IMO it would be best for the ERC to standardize the behavior and names that are already in use, instead of introducing new ones. So I would go for burn instead of consume, etcetera.

[frangio]

I don't really understand the role of Ticket721 in this. Would you mind explaining?

[xinbenlv]

@nventuro

I'd suggest taking a look at how ERC777 does burning, and see if you can imitate that.

@frangio

So I would go for burn instead of consume, etcetera.

Agreed to both, compatibility is probably the most important when it comes to adoptions. I lean towards using "burn" as well now.

I don't really understand the role of Ticket721 in this. Would you mind explaining?

The role of Ticket721 is to demonstrate what will a typical "ticket" like in EventBrite (being both transferable and consumable) look like, under the ERC2135 contract standard. Does this explanation answers your question?

[frangio]

Yes, I think I understand. I was asking to understand whether it's something that should be included in the OpenZeppelin Contracts or if it's more like a special-purpose example application. I'm leaning towards the second.

[xinbenlv]

@frangio thanks for clarifying. I humbly argue that it is the first case: it is more of a general case possible being referenced / used by many applications as part of their set of contracts.

[stale]

Hi all!
This Pull Request has not had any recent activity, is it still relevant? If so, what is blocking it? Is there anything we can do to help move it forward?
Thanks!

[xinbenlv]

Hah, thank you Stalebot. I am working on communicating the preferred interface and waiting for community members input to further revise

[stale]

Hi all!
This Pull Request has not had any recent activity, is it still relevant? If so, what is blocking it? Is there anything we can do to help move it forward?
Thanks!

[xinbenlv]

It's still waiting for review.

[xinbenlv]

Actually, hold on, I will update the interface to reflect another conversation's suggestion

[frangio]

We've decided not to merge this because there doesn't seem to be a lot of interest in the ERC, and moreover it's still a Draft, which we usually don't include because the API may change and we need to keep a stable API.

Sorry for taking a while to come to a definitive answer. Thank you @xinbenlv!