DFINITYでトークンを作成する方法は？Token Standardsに関する議論

NFTStudio

6月10日、ICPリーグは3回目の開発者コミュニティコールを開催しました。DFinance（現在はSonicにリブランディング）の開発者を招待して、DFINITYでトークンを発行する方法とERC-20Token Standardsに類似したアイデアについて話し合いました。


ICPはDFINITYの最初のネイティブトークンであり、スマートコントラクトとしてDFINITYの上にデプロイされるため、Token Standardsを実装するための参照として使用できます。



イーサリアムとは異なり、DFINITYにERC-20Standardsを実装する場合、トランザクションのマッサージはDFINITYnに保存されないため、Token Standardsの下でトランザクションの記録が必要になります。



コンテナのスペースはトランザクションレコードを格納するのに十分な大きさではないため、トークンコントラクトにはスケーリングの問題がいくつかあります。



DFINITYは逆ガスモデルを使用しているため、ユーザーは使用時にガスを消費する必要がありません。スパム攻撃を回避するために、Token Standardsに転送チャージバックまたは料金を追加する必要があります。



ICPトークン



イーサリアムでは、イーサリアムはネイティブトークンであり、マイニング、転送、契約とのやり取り、ガスの支払いなどのトランザクションはブロックにパッケージ化され、ブロックチェーンと結合されます。


DFINITYでは、ICPトークンは実際にはネットワーク上の「元帳」と呼ばれるスマートコントラクトに組み込まれ、クエリ、転送、トランザクション管理、誓約などのICPトークンの機能の実装はスマートコントラクト（archive_node.rs）にあります。



DFINITYのスマートコントラクトはインターネットマイクロサービスのコンテナーに似ているため、スマートコントラクトの状態は元帳コンテナー内に保存されます。実際、ICPのトランザクションレコードはスマートコントラクト内に保存されており、コントラクトの機能を使用してクエリを実行する必要があります。



実際、DFINITYのガストークンサイクルのみがチェーン上の唯一の基礎となるネイティブトークンであり、サイクルはICPを書き込むことによってのみ取得できます。



すべての操作は元帳コンテナにトランザクションとして記録され、DFINITYはブロックチェーンスタイルのデータ構造を使用して元帳コンテナに元帳を同時に記録します。ここでのブロックチェーンは、コンセンサスブロックチェーンではなく、元帳データを格納するための単なる形式であることに注意してください。実装の状態は次のとおりです。

画像1

したがって、ICPはDFINITYの最初のToken Standardsと見なすことができ、そのコードはすでにオープンソースです。ERC-20Standardsと同様のStandardsを実装する場合は、ICPトークンの設計に従うことをお勧めします。


オープンソースのリンクは次のとおりです：https：//github.com/dfinity/ic/tree/master/rs/rosetta-api / ledger_canister.



ERC-20Token Standardsに従う



https://github.com/dfinance-tech/ic-token/blob/main/simple-erc20/src/token.mo


にアクセスして、Motoko言語を使用したERC-20のDFINITY Token Standardsに従ったDFinanceのソースコードを確認してください。

画像2

Owner_はトークンの作成者、通常はコンテナーのデプロイヤーを意味し、name_は名前を意味します。decimals_はトークンの正確なビット数を示し、symbol_はトークンのシンボル、totalSupply_はトークンの合計供給量を示します。これらはいくつかの基本です。



しかし実際には、トークンの数を示すdecimals_は削除できます。solidyは浮動小数点計算をサポートできないため、このパラメーターはイーサリアムコントラクトで必要ですが、DFINITYの言語は浮動小数点演算をサポートできます。



残高は、アカウントの残高を表すデータベースの下のタイプです。ここでは、DFINITYの永続データベースHashMapを使用して、アカウントと残高の間のリンクを確立します。アローワンスレコード承認。これは、アカウントまたはスマートコントラクトが残高を使用できるようにするためにイーサリアムでよく使用されます。



この実装は、transfer、transferFrom、balanceOf、allowance、approveなどのイーサリアムの操作に従います。トークンのミンティングとバンニングに関して、一部のイーサリアムプロジェクトは、トークンを書き込むためにトークンを0x0アドレスに直接転送することを選択します。これは、0x0アドレスの秘密鍵の計算を逆にすることができないため、再度転送することができないためです。ただし、DFINITYにはまだパブリック書き込みアドレスがないため、DFinanceはそのようなことを行いません。そのため、データベース内の残高を直接減算する書き込みメソッドを実装します。



より良いDFINITYToken Standards



DFINITYの公式オープンソースICPコードは彼らの実践に近く、コードはERC-20Standardsに準拠し、互換性を実現しようとしますが、さらに複雑になります。オープンソースコードは次のとおりです


：https：//github.com/dfinance-tech/ ic-token / tree / ledger / src.



ICPの実装では、アカウントはアカウントIDを使用しますが、この実装では、アカウントはプリンシパルIDを使用します。コミュニティは、2つの選択肢について異なる意見を持っています。



最大の違いは、転送履歴メッセージを記録するためのデータベースの追加です。トークンはDFINITYでのスマートコントラクトの実装でもあるため、ICPと同じ問題があります。つまり、データの最終的な整合性が最初になり、トランザクション情報が最初になります。


ブロックでは利用できません。したがって、メッセージを保存するには、コンテナ内にデータ構造を作成する必要があります。コアコードの下にOpRecord.moがあり、転送、キャスト、破棄、承認のすべての操作がOpRecordに記録され、OpRecordの下に詳細情報があり、ユーザーが後で確認するのに便利です。


スケーリングについて



スケーリングについてはこれまで何度も話しましたが、Token Standardsで再び登場します。スマートコントラクトでトークン転送の記録を保持するには非常に大量のデータを保存する必要があり、DFINITYは現在最大4GBの容量しかサポートしていないためです。



実際、すべてのDFINITY dappはコンテナー容量制限の問題に直面し、最終的な解決策は、コンテナー容量がなくなる前にデータを新しいコンテナーに分割する一連の自動スケーリングデータベースインフラストラクチャを実装することです。



このインフラストラクチャは、標準化されたデータベース中間層のようなものであり、上位層のDAppはデータベースの中間層のAPIを直接呼び出すことができ、スケーリングの問題は中間層によって処理されます。Sudographはデータベースエンジンを開発しようとしていますが、開発者がデータ型を自己定義するのは非常に便利ですが、容量を自動的にスケーリングしようとはしていません。



短期的には、トランザクション履歴を定期的に外部静的ストレージにパックしてから、DFINITYコンテナー内の履歴を削除して、一定期間だけ保持することもできます。DFINITYのWASMは64ビットをサポートしている可能性があるため、単一のコンテナのメモリを拡張できます。



ガス料金はスパム取引攻撃に抵抗する



FINITYは逆ガスモデルを使用します。イーサリアムのユーザーは取引にガスを支払います。DFINITYではガスはdappsによって支払われるため、ユーザーはガス料金を支払うことなくサービスを楽しむことができます。



ただし、誰かが悪意を持って大量のジャンクトランザクションを送信したり、コントラクトを呼び出し続けたり、コントラクトにジャンクデータを詰め込んだりして、コントラクトのストレージスペースとガスを消費した場合、潜在的な攻撃を受ける可能性があります。直接的な影響は、取引ができないことです。攻撃者はDDOS攻撃を使用して、誰もが取引できないようにし、市場を制御することができます。



DFINITYのICPトークンは、この問題を考慮に入れました。転送が呼び出されるたびに、一部の料金が差し引かれます。攻撃を防ぐために、通話では0.0001ICPが差し引かれます。契約はそのようないくつかの方法で設計することができます



1.転送されたトークンをガスとして使用します。トークン契約のすべての転送、ミンティング、およびその他の操作は、特定の量またはパーセンテージのトークンを差し引くか、破棄します。このスキームは非常に単純で、イーサリアムのデフレトークンデザインのように聞こえます。



2. ICPの実装と同様に、ガス料金としてICPを使用します。



3.イーサリアムでのすべてのトランザクションには一定量のガスがあるため、開発者はガスの量を見積もることができます。DFINITYにはそのようなインターフェースはありませんが、実装することは可能です。また、DFINITYガスは安定した価格でサイクルを使用するために支払われます。


したがって、操作に必要なサイクル数を見積もることで操作の単価を計算し、交換でのサイクルとトークンのトランザクションペアに従って、対応するトークンの量を差し引くことができます。これにより、処理料金でトランザクション処理コスト。



さらなる最適化



承認を削除



イーサリアムのETHStandardsとERC-20Standardsの違い、および再突入攻撃を回避するために、開発者は承認と呼ばれる追加の操作を追加しました。ただし、DFINITYでは、承認機能を削除してエクスペリエンスを向上させ、「サブスクリプション」の代替案を提案することが提案されています。


また、これにより攻撃も防止されます。これは、DFINITYモデルで承認すると、攻撃者が一連の承認を送信してコンテナのメモリをいっぱいにし、コンテナを停止する可能性があるためです。


これにはいくつかの反対意見があります。コミュニティの議論については、https：//forum.dfinity.org/t/thoughts-on-the-token-standard/4694/4を参照してください。



プリンシパルIDを使用してスペースを節約する



「DFINITYの分散型ID、アカウント、ウォレットの概要と、開発者がそれをどのように活用できるか？DFINITYのプリンシパルIDとアカウントIDを2つの類似したIDとして導入しました。


プリンシパルIDはコンテナーの使用に使用され、アカウントIDは元帳に使用されます。どちらも同種です。現在、アカウントIDはDFINITYのICP実装で使用されていますが、プリンシパルIDは短く、スペースを25％節約できるため、コミュニティの一部の人々はトークンコントラクトでプリンシパルIDを使用することを提案しています。



言語



DFINITYのAMAによると、トークンコントラクトなど、セキュリティ要件の高いものをプログラミングする場合は、開発者がRustを使用することをお勧めします。



契約管理者の管理



DFINITYコントラクトはアップグレードを許可するため、コントラクトのコントローラーはより強力であり、追加のトークンを発行して操作をロールバックすることもできます。


したがって、コントローラーをより適切に管理する必要があります。開発者は、コントローラーをゼロアドレスに割り当てて、コントラクトをアップグレードできないようにするか、コントローラーをコミュニティによって管理されるDAOに置き換えることができます。




いいなと思ったら応援しよう！