メインコンテンツまでスキップ

Aptosトークン標準

Aptosデジタル資産標準はAptosの公式の非代替トークンを定義します。Aptosは構成可能性を活用して 代替資産標準を介して代替可能性などの機能を備えたデジタル資産標準を拡張します。 構成可能性の概念は、これらの構成の基礎となるデータモデルMoveオブジェクトデータモデルに由来します。

Aptosトークン標準はEthereumやSolanaの標準と比較してどうなのか残りのドキュメントで解説します。

データモデル​

トークンを理解するには、まず異なるブロックチェーンのデータモデルと比較することから始めます。

イーサリアム​

Ethereumには2種類のアカウントがあります。

  • Etherの残高を保管する外部所有のアカウント。
  • 基礎となるスマートコントラクトを管理し、関連付けられたコントラクトによってのみ変更可能な永続的な状態のための関連ストレージを持つコントラクトアカウント。

新しいNFTコレクションを作成するには、作成者は独自のコントラクトをブロックチェーンにデプロイする必要があります。これでストレージ内へコレクションとNFTのセットが作成されます。

ソラナ​

データとコードが共存するEthereumやAptosとは異なり、Solanaはデータとプログラムを別々のアカウントに保存します。Solanaブロックチェーンには2種類のアカウントが有ります。

  • 実行可能アカウントにはコントラクトコードのみが保存されます
  • 実行不可アカウントには、実行可能アカウントに関連付けられ、実行可能アカウントが所有するデータが保存されます。

新しい NFT コレクションを作成するには、作成者は既存のデプロイ済みプログラムを呼び出して、新しいコレクションとNFTセットを作成します。

Aptos​

Aptosのアカウント は、スマートコントラクトとデータの両方を保存します。Ethereum とは異なり、スマート コントラクトの関連データは、アカウントまたはオブジェクト内のリソース内のすべてのアカウントのスペースに分散されます。例えば、コレクションとそのコレクション内のNFTは、スマートコントラクトが別のアドレスで定義している異なるアドレスの個別のオブジェクトへ保存されます。スマート コントラクト開発者は、NFTとコレクションへ関連付けられたデータをスマートコントラクトと同じアドレスまたは他のオブジェクトへ保存する事も出来ます。

AptosでNFTを作成するには2つの手段があります。

  • ノーコード標準で、作成者は新しいコントラクトをデプロイせず、コントラクトを呼び出して新しいコレクションとトークンを作成できます。
  • カスタムNFTコントラクトで、作成者はコレクションの全側面を管理出来るオブジェクトモデルを拡張して、NFTをカスタマイズ出来ます。

Aptos は、Ethereum が提供するカスタマイズ性と Solanaの様な新しいコレクションを作成するシンプルさの間でバランスをとっています。

Ethereumと同様、Aptosではアカウントが所有する全ての NFTのセットを決定するためindexingが必要ですが、Solanaでは必要ありません。

トークン標準の比較​

代替可能トークン(FT)は当初EIP-20で導入され、非代替可能トークン(NFT)はEIP-721で定義されました。その後、EIP-1155ではFTとNFT、あるいは半代替可能トークン (SFT)が1つの標準へ統合されました。

Ethereumトークン標準は、各トークンに個別のコントラクトコードをデプロイし、トークンのコレクションを区別する必要があります。Solanaアカウントモデルでは、コードを再利用して1つの汎用プログラムで様々なデータを操作出来る別のパターンが有効となります。新しいトークンを作成するには、トークンをミントできるアカウントと、トークンを受け取れるアカウントをいくつか作成します。コントラクトアカウントではなく、ミントアカウント自体がトークンの種類を一意に決定し、これらは全て、実行可能なアカウントへデプロイされた1つのコントラクトへ引数として渡されます。

Aptos トークン標準のコレクションはSolana といくつかの類似点があり、特にFT、NFT、SFT を共通のオンチェーン コードにカバーする方法が類似しています。新しいトークンごとに新しいスマートコントラクトをデプロイするかわりに、作成者は必要な引数を使用してコントラクト内の関数を呼び出します。呼び出す関数に応じて、トークン コントラクトはトークンをミント/転送/バーン/... します。

トークン識別​

AddressAptos は、グローバルストレージ内の場所であるAddressまたはObjectIdでトークンを識別します。コレクションは、作成者のアドレスとコレクションの名前によって決まる場所へ保存されます。

Ethereumでは、コントラクトはコントラクトをデプロイするアカウントが決定したアカウントへデプロイされます。その後、NFTは、契約内のデータテーブルへインデックスとして保存されます。

Solanaでは、NFTデータはプログラムアカウントとは独立したミントアカウントへ保存されます。

トークンメタデータ​

AptosトークンのTokenリソースには、トークンとやり取りするためdappsで最も一般的に必要なデータを含むメタデータが含まれています。例には以下が含まれます。

  • name: トークンの名前。コレクション内で一意である必要があります。
  • description: トークンの説明。
  • uri: トークンの詳細情報のためのフチェーンへのUR ポインター。アセットは、画像やビデオなどのメディア、またはJSONファイル内のその他のメタデータである可能性があります。
  • collection: コレクションのObjectIdへのポインター。

追加のフィールドは、作成者が定義したリソースまたは一般化可能なキー値のマップを定義するPropertyMapリソースへ保存出来ます。

Ethereumでは、そのようなプロパティのごく一部のみが、メソッドとして定義されています。(name()、symbol(),decimals()、ERC -20のtotalSupply()もしくはname()、symbol()、ERC-721のオプションのメタデータ拡張のtokenURI()、ERC-1155、独自のオプションのメタデータ拡張内のuri()類似メソッド、の様な)トークン メタデータは標準化されていないため、dappsはその時時で特別な処理をする必要があります。

Solanaでは、トークンメタデータプログラムは、メタデータアカウントを提供し、トークンへ関連付けられた多数のメタデータフィールドを定義します。これは、AptosのTokenDataIdで定義されている collectionを含みます。SolanaはAptosとは異なり、アセットの可変性を提供しません。Aptosと同様、トークンメタデータv1.1.0はカスタマイズされたプロパティ用のattributeコンテナーを提供します。