Dfinity FungibleToken（DFT）について

DFTは、Dfinity FungibleTokenを意味します。

概要

トークン標準は、Dfinityエコシステム開発者が同じ標準を採用し、Dfinityエコシステムの繁栄を促進するのに役立ちます

トークンスタンダードデザインのルール

ERC20は、ブロックチェーンの世界で最初の代替可能なトークン標準であり、完全に検証および認識されています。[Dfinity Fungible Token Standard]を設計する際には、既存のERC20標準を参照する必要があります。

[Dfinity Fungible Token Standard]の設計は、次のルールに従います。

1 ERC20規格の改善

2 Dfinityへの適合

ERC20を改善する方法

ERC20はイーサリアムの初期に作成されました。Ethエコシステムの開発中に、開発者はERC20が完全ではないことに気づいたため、開発者はERC20を改善するためにERC223 \ ERC667 \ ERC777標準を設計しました。これらの標準の利点を組み合わせた、より優れた標準を設計します。

ERC223

ERC20転送受信者（契約）がトークンの転送をサポートしておらず、転送されたトークンが失われるという問題を解決しようとします（ブラックホールアドレスへのトークンの送信と同様）

ERC667

伝達関数と呼び出し関数を組み合わせたtransferAndCallを追加し、ERC223によって解決された問題を解決します

ERC777

送信機能を使用して伝達関数を交換します
フック機能を使用して、転送を受け入れるかどうかを制御します
オペレーター許可機能を使用して、プロキシ転送ソリューションとしての承認機能を置き換えます

改善された基準

service: {
name: () -> (text) query;
symbol: () -> (text) query;
decimals: () -> (nat8) query;
totalSupply: () -> (nat) query;

balanceOf: (owner: principal) -> (nat) query;
allowance: (owner: principal, spender: principal) -> (nat) query;
approve: (spender: principal, value: nat) -> (bool);
transferFrom: (sender: principal, receiver: principal, value: nat) -> (bool);
transfer: (receiver: principal, value: nat, args:opt vec nat8) -> (bool);
}

Dfinityへの適合：解決すべき問題点

Token Standardの設計では、DfinityとEthereumの違いを十分に考慮し、解決すべき問題を明確にします。

1 EVMのクロスコントラクトコールに似たアトミック性はありません

解決策：sagasは良い解決策です

2 EVMと同様の組み込みのイベントエミットサポートはありません

・質問：

トランザクションが発生したことを他の人はどうやって知るのですか？
取引履歴の確認方法は？

・考慮事項：フォーラムの質問1には2つのアイデア（Pubsub / Notify）があります

トークンが転送されると、Notifyは受信者に通知します。受信者は不足しているEVENTを埋めることができます。ただし、トークンの受信者がキャニスターではない場合、つまり通知できない場合は、クエリトランザクション履歴をサポートする必要があります。

トークンには、受信者ではないサードパーティにトランザクション情報をリリースするためにPub / Subを実装する十分な理由がありません

・解決：

通知はより良い方法です。
クエリトランザクション履歴をサポートする必要があります。

3 ビルトインストレージサポート

・質問：現在のストレージは8Gに増加しますが、メモリストレージはまだ4Gです

・考慮：

Tx履歴はクエリをサポートする必要があります

内蔵ストレージはトークンをサポートして、より多くの自己記述情報を保存できます

・解決：

自動スケーリングストレージソリューション
トークンは自己記述を実装します

4 リバースガスモデル

質問：ddos攻撃を防ぐ方法

考慮事項：キャニスターの呼び出しでは、発信者がガス料金を支払う必要はありません（キャニスターはガス料金を支払います）

解決策：キャニスターへの更新呼び出しは、呼び出し元に請求する必要があります

5 Dfinityには、インターネットID（略してII）とプリンシパルIDの2つの異なるIDがあります。

質問：トークンの標準ユーザーとして使用するIDはどれですか？

考慮事項：DfinityのIIはDIDの実装であり、IIはプリンシパルIDに基づいています

解決策：さまざまなIDシナリオのニーズを満たすために、トークン標準が両方のIDと互換性がある必要があります

6 ブラックホールアドレスなし

質問：トークンを破棄する必要がある場合、どのように対処しますか？

考慮事項：書き込みインターフェイスを実装するかどうかは、トークン標準で考慮する必要があります

解決策：書き込みインターフェイスを標準にする必要はありません。拡張インターフェイスで設計できます。

7 approve / transferFrom（ApproveはTransferFromのペアリング関数です）

質問：フォーラムでの議論で承認/譲渡を削除すべきかどうかについて意見の相違がありました

考慮：

approve / transferFromは、主に次の理由でERC20に表示されます。

イーサリアムのネイティブETHトークンを使用すると、スマートコントラクト関数を呼び出し、同時にETHをコントラクトに送信できます。これは、payableを使用して行われます。ただし、ERC20トークン自体はスマートコントラクトであるため、その関数の1つを呼び出しているときにトークンをスマートコントラクトに直接送信することはできません。したがって、ERC20標準では、スマートコントラクトがユーザーに代わってトークンを転送することを許可しています-transferFrom（）関数を使用します。このため、ユーザーはスマートコントラクトが自分に代わってこれらのトークンを転送することを許可する必要があります

ただし、イーサリアムのDexおよび貸出シナリオでは、承認には2つのトークンの同時操作の可能性が伴うことがよくあります。承認は、トランザクションによって引き起こされた繰り返しの支払いの問題を回避することができ、転送のための優れた補足的な使用シナリオを持っています。

解決策：Approve / transferFromを保持する必要があります

8 TransferAndCallとReceiverNotify

質問：どのオプションがより適切か

考慮：
Notifyは、基本的な通知のニーズを満たすことができます。これ以上の柔軟性をサポートすることはできませんが、転送シナリオを満たすには十分です。
TransferAndCallはより優れた柔軟性を提供しますが、呼び出しに対応するメソッドとパラメーターを完全に理解するかどうかは転送呼び出し元に依存します。これはほとんどの転送シナリオでは必要ありません。

解決：
両方がサポートされ、伝達関数に統合されています
トークン標準は、最初に通知を実行してから、呼び出しを実行する必要があります

9 ApproveAndCall VS TransferAndCall

質問：transferAndCallとTransferAndCallを比較します。ApproveAndCallとtransferAndCallは、非アトミック操作の2つのセットであり、本質的に違いはありません。どちらを保持する必要がありますか？

考慮事項：一部のシナリオでは、複数のトークンを同時に転送する必要がある場合、TransferAndCallはそのようなニーズを満たすことができません。承認後、最後の呼び出しでtransferFromを実行して、一度に複数のトークンを支払います

解決策：どちらもapproveAndCallとtransferAndCallをサポートして、より多くのシナリオの柔軟なニーズに対応します。

他にどのような機能が実装するDfinity代替可能なトークンの標準的な必要性のでしょうか？

自己記述的な情報

Etherscan、MyEthereumWallet、Imtoken、TokenPocket、Dappにはすべて、ロゴ、紹介、ホワイトペーパー、ソーシャルメディア、公式Webサイト、連絡先情報など、ERC20に関するより多くの情報要件があります。この情報を必要とするそれぞれを個別に維持する必要があります。そのため、情報に一貫性がないように見えます。[Dfinity Fungible Token Standard]の設計を通じて、この問題を解決する必要があります。

上記の問題と要件に基づいて、次のドラフト標準が策定されます。

DFT standard

Introduction | Dfinity Fungible Token Standard Documentation

リファレンス

[1] [Dfinity開発者センター：キャニスターインターフェイス] （https://sdk.dfinity.org/docs/interface-spec/index.html#system-api-imports）

[2] [Dfinityフォーラム：thoughts-on-the-token-standard] （https://forum.dfinity.org/t/thoughts-on-the-token-standard/4694）

[3] [Toniq-Labs：ic-fungible-token] （https://github.com/Toniq-Labs/ic-fungible-token）

[4] [SuddenlyHazel：Token-Standard] （https://github.com/SuddenlyHazel/token-standard/pull/1）

[5] [Dfinance-tech：ic-token] （https://github.com/dfinance-tech/ic-token）

[6] [プラグ：トークン-標準] （https://github.com/Psychedelic/standards）

[7] [イーサリアム：EIPS-EIP20＆EIP667＆EIP777＆EIP1820] （https://github.com/ethereum/EIPs）

[8] [率直] （https://github.com/dfinity/candid/）

[9] [ERC20の手当が必要なのはなぜですか？] （https://kalis.me/unlimited-erc20-allowances/）

[10] [sudograph] （https://github.com/sudograph/sudograph）

[11] [Dfinity Self Describing Standard] （https://github.com/Deland-Labs/dfinity-self-describing-standard）

Introduction | Dfinity Fungible Token Standard Documentation