CBP-2: fungible token standard #2

witterlee · 2022-02-12T12:29:47Z

The IC developer community is welcome to participate in the discussion of Token standards and build a community consensus Token standard

Signed-off-by: Witter <[email protected]>

lurenyi558 · 2022-02-24T13:03:44Z

加入

lurenyi558 · 2022-02-24T13:04:01Z

加入学习

witterlee · 2022-03-05T12:35:18Z

Feasible consensus path:

Major Features consensus
Secondary Features consensus
Optional Features consensus
Definition consensus of key elements
Candid interface consensus

For each consensus, we will hold a community meeting to form a consensus. When the consensus of the community meeting is reached, an on-chain consensus will be formed through NNS proposal to solidify the consensus result.

lshoo · 2022-03-16T00:17:01Z

Great!

neeboo · 2022-03-16T02:12:27Z

Feasible consensus path:

Major Features consensus

Secondary Features consensus

Optional Features consensus

Definition consensus of key elements

Candid interface consensus

For each consensus, we will hold a community meeting to form a consensus. When the consensus of the community meeting is reached, an on-chain consensus will be formed through NNS proposal to solidify the consensus result.

LGTM

8X8X · 2022-03-17T23:37:46Z

申请加入,我们是RGstudio, 现在在做一个thanat0s-Dao的nft项目

DavidM-D · 2022-03-30T10:20:58Z

I'd like to get a feeling about what you think this solves that DIP20 doesn't solve. They seem pretty similar.

DavidM-D · 2022-03-30T10:21:49Z

CBPs/cbp-0002.md

+
+- Question: Which identity to use as a token standard user？
+
+- Consideration: Dfinity's II is an implementation of DID, and II is based on Principal ID


Doesn't II look like a Principal ID to canisters?
Should a token standard care too much about what kind of client is communicating with it?

Principal & AccountId somehow makes sense can be confusing, but as a token standard, choosing to support only Principal is the easiest, but being AccountID compatible will keep users from passively choosing

Oh yeah, AccountIDs aren't great. Hash(PrincipalID, SubAccount) is equivalent to AccountID.
I think (PrincipalID, SubAccount) may make more sense, or just drop the SubAccounts

Here my idea is different, I think IC official team design AccountID is in privacy protection considerations; (PrincipalID, SubAccount) lead to different sub-accounts, will expose Principal. but AccountID, can play a privacy protection role, so the token standard should not choose to reduce in privacy protection level, which is why I think it is necessary to support AccountID

Yup, it's mainly to allow privacy for canisters holding balances because obviously an individual can generate an unlimited number of private keys trivially for privacy.

You are right, but I think most people are lazy, and also creating more private keys can be prone to loss or forgetting, if a Principal can serve the purpose of protecting privacy is a better and simpler way

DavidM-D · 2022-03-30T10:23:06Z

CBPs/cbp-0002.md

+
+6. No black hole address
+
+- Question: If there is a need to destroy Token, how to deal with it?


Something I liked about the ICP design was there was a constant finite number of tokens.
This meant we could use fixed length numbers since overflow was impossible and we could test this invariant.
Having a mint/black hole address solves this.

Supporting mint/burn is clear and straightforward for meeting such a need, but not every token needs an interface like mint/burn, so mint/burn should not be in the standard. Tokens that need them implement them themselves

ICP is a specific token and therefore can be defined in a targeted manner. However, as a token standard, different token issuers need to be considered, with different requirements for the numbers

Something I liked about the ICP design was there was a constant finite number of tokens.

DavidM-D · 2022-03-30T10:25:47Z

CBPs/cbp-0002.md

+
+- Question: What Is Nonce In Ethereum? every transaction has a nonce. The nonce is the number of transactions sent from a given address. Each time you send a transaction, the nonce increases by 1. There are rules about what transactions are valid, and the nonce is used to enforce some of these rules. Does Dfinity's token standard need to incorporate a nonce mechanism?
+
+- Consideration:If the nonce mechanism is supported, it can prevent users from repeatedly submitting transactions


The IC already prevents the same message being sent twice, using a nonce in the message.
This nonce is there to allow stable transaction IDs to be generated offline for the benefit of exchanges.

If you want these tokens to be one day tradable on an exchange you probably want to keep the nonce.

IC's nonce does not give developers a way to use the nonce in order for developers to avoid sending the same transaction, which is important. Of course, if IC had a clear way to support developers using nonce, there would be no need for nonce to be in the token standard

Ah sorry I should be more clear.
Every ingress message sent to the IC has a nonce generated to ensure that a transaction can't be resent.
In addition there is a second nonce which is included in the block.
The exchanges enforce an invariant that each transaction must have a statically derivable globally unique request ID. This second nonce helps ensure that each transaction is globally unique.
This is also why we have the created_at field in ICP.

Thank you very much for your patience, I think this approach makes sense, using create_at as the second nonce would be simpler and I believe developers would like this approach more. I will adjust the proposal according to your suggestion

DavidM-D · 2022-03-30T10:26:46Z

CBPs/cbp-0002.md

+
+**Information self-describing**
+
+Etherscan, MyEthereumWallet, Imtoken, TokenPocket, Dapp all have more information requirements for ERC20, such as Logo, introduction, white paper, social media, official website, contact information, etc. Each of them that needs this information needs to be maintained independently, so information appears Inconsistent. It is necessary to solve this problem through the design of <strong>[Dfinity Fungible Token Standard]</strong>


So if you match the Rosetta block fetching interface, you should get the ic.rocks token explorer working for you for free.

This is something I am not in a hurry to implement. Because I think the token standard is more important community consensus, when the community consensus is reached, support resetta is easy

So I'm not suggesting supporting Rosetta in the standard. But having a block fetching interface like ICP allows CEXes to use the token and more importantly allows you to have backups of the transaction logs.

Sounds good, and I think this issue can be put to the interface consensus stage to discuss and make the decision, which does make sense.

witterlee · 2022-03-30T10:51:29Z

It's great to see that you're reading this proposal carefully, and I appreciate your comments.
I think the community consensus on the token standard is more important than a specific code implementation. So I hope that when talking about these consensuses, we should try to avoid talking about a particular code implementation so that we can focus on [whether the top-level design of the standard makes sense].

I'd like to get a feeling about what you think this solves that DIP20 doesn't solve. They seem pretty similar.

DavidM-D · 2022-03-30T11:03:48Z

But DIP20 is a token standard rather than a specific implementation?

witterlee · 2022-03-30T11:09:42Z

If we think of it that way, then DFT, IS20,DRC20, and EXT are all token standards. So let's talk about what the standard itself should look like, it will make us more focused

1. Improvement content 2. Removing notify support 3. Replace nonce with timestamp

witterlee · 2022-03-31T04:19:38Z

Hi, @DavidM-D, thank you for participating in the discussion, your discussion has provided meaningful suggestions for Token standard evolution. I have improved the proposal content

witterlee added 3 commits February 12, 2022 20:26

CBP-2: fungible token standard

9e9792c

Signed-off-by: Witter <[email protected]>

Improve: update flow chart

9c7dede

Improve: improve content

e11d904

DavidM-D reviewed Mar 30, 2022

View reviewed changes

Improve proposal

6d3c238

1. Improvement content 2. Removing notify support 3. Replace nonce with timestamp

witterlee added 2 commits April 4, 2022 19:09

Merge branch 'CBD-Group:main' into main

6916af9

Merge branch 'CBD-Group:main' into main

73e70d2


		- Question: Which identity to use as a token standard user？

		- Consideration: Dfinity's II is an implementation of DID, and II is based on Principal ID


		6. No black hole address

		- Question: If there is a need to destroy Token, how to deal with it?


		- Question: What Is Nonce In Ethereum? every transaction has a nonce. The nonce is the number of transactions sent from a given address. Each time you send a transaction, the nonce increases by 1. There are rules about what transactions are valid, and the nonce is used to enforce some of these rules. Does Dfinity's token standard need to incorporate a nonce mechanism?

		- Consideration:If the nonce mechanism is supported, it can prevent users from repeatedly submitting transactions


		Information self-describing

		Etherscan, MyEthereumWallet, Imtoken, TokenPocket, Dapp all have more information requirements for ERC20, such as Logo, introduction, white paper, social media, official website, contact information, etc. Each of them that needs this information needs to be maintained independently, so information appears Inconsistent. It is necessary to solve this problem through the design of <strong>[Dfinity Fungible Token Standard]</strong>

CBP-2: fungible token standard #2

Are you sure you want to change the base?

CBP-2: fungible token standard #2

Uh oh!

Conversation

witterlee commented Feb 12, 2022

Uh oh!

lurenyi558 commented Feb 24, 2022

Uh oh!

lurenyi558 commented Feb 24, 2022

Uh oh!

witterlee commented Mar 5, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lshoo commented Mar 16, 2022

Uh oh!

neeboo commented Mar 16, 2022

Uh oh!

8X8X commented Mar 17, 2022

Uh oh!

DavidM-D commented Mar 30, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

witterlee Mar 30, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DavidM-D Mar 30, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DavidM-D Mar 30, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

witterlee commented Mar 30, 2022

Uh oh!

DavidM-D commented Mar 30, 2022

Uh oh!

witterlee commented Mar 30, 2022

Uh oh!

witterlee commented Mar 31, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

witterlee commented Mar 5, 2022 •

edited

Loading

witterlee Mar 30, 2022 •

edited

Loading

DavidM-D Mar 30, 2022 •

edited

Loading

DavidM-D Mar 30, 2022 •

edited

Loading