EOSIOガイド(ABIファイルを理解)
13507 ワード
ABIファイルについて
紹介する
前に、提供されたABIファイルを使用して
ABIとは?
アプリケーションバイナリインタフェース(ABI)は、JSONに基づく記述で、JSONとバイナリ表現の間でユーザー操作を変換する方法を紹介し、ABIはデータベースの状態をJSONまたはJSONから変換する方法を説明し、ABIで契約を記述すると、開発者とユーザーはJSONを通じてシームレスにあなたの契約と対話することができます.
セキュリティの説明
取引を実行するときはABIを迂回することができ、契約に伝達されたメッセージと操作はABIに合致する必要はありません.ABIはドアマンではなくガイドです.
ABIファイルを作成
空のABIから
types
ABIは、任意のクライアントまたはインタフェースが契約のGUIを生成することを説明し、一貫した方法で動作させるために、ABIで説明する必要がある任意の共通操作または構造でパラメータとして使用されるカスタムタイプを説明します.
組み込みタイプ
EOSIOは、ABIファイルに組み込みタイプを記述する必要がなく、多くのカスタム組み込みタイプを実現しています.EOSIOの組み込みタイプを熟知したい場合は、ここで定義します.
ABIは今このように見えます.
structs
ABIに曝された構造も記述する必要があり、
JSONの構造オブジェクト定義は以下の通りです.
fields
暗黙構造
以下の構造は暗黙的です.構造は契約で明示的に定義されていないため、create操作を表示すると、
create
issue
retire
transfer
close
明示的な構造
これらの構造は、インスタンス化されたマルチインデックステーブルの条件であるため、上記のような暗黙的な構造を定義するのと何の違いもないことを記述するため、明示的に定義されています.
account
currency_stats
actions
操作のJSONオブジェクト定義は以下の通りです.
次に、前に説明した構造に基づいて各操作のタイプを説明します.ほとんどの場合、関数名と構造名は等しくなりますが、等しくする必要はありません.
次に、ソースコードにリンクされたアクションのリストを示します.ここでは、各アクションの説明方法を理解するために、JSONの例を示します.
create
issue
retire
transfer
close
tables
説明表、これは表のJSONオブジェクト定義です.
eosio.token契約は、2つのテーブル、accounts、statsをインスタンス化します.
Accountsテーブルはi 64インデックスであり、account structに基づいてuint 64がプライマリ・キーとして使用されます.
ABIでaccountsテーブルを説明する方法を以下に示します.
statテーブルはcurrenct_に基づくi 64インデックスです.stats structには、uint 64がプライマリキーとしてあります.
以下に、ABIでstatテーブルを記述する方法を示す.
上の表は同じ「key name」を持っていることに気づきます.キーを似た名前に命名するのは象徴的です.これは、主観的な関係を示す可能性があるためです.この実装と同様に、任意の与えられた値を使用して異なる表をクエリーできることを意味します.
一緒に置いて
最後に、
コイン契約がカバーされていない場合
ベクトル(Vector)
ABIファイルでベクトルを記述する場合は、
こうぞうきそ
これはあまり使われていない属性で、base ABI構造属性を使用して別の継承構造を参照することができます.この構造も同じABIファイルで記述されている限り、スマート契約ロジックが継承をサポートしていない場合、Baseは操作を実行しないか、エラーを投げ出す可能性があります.
システム契約のソースコードとABIで使用しているbaseの例を見ることができます.
ここでは追加のABI属性は含まれていません
簡潔化のため、ここではABI仕様のいくつかの属性を省略するが、ABIの各属性を完全に概説する所定のABI仕様がある.
李嘉図条項
李嘉図条項は、特定の行為の予想結果を説明し、送信者と契約の間で条項を確立するためにも使用できます.
ABI拡張
古いクライアントが拡張データを解析する「ブロック」をスキップできる汎用の「未来向け」レイヤです.現在、このプロパティはまだ使用されていません.将来、各拡張はベクトルに独自の「ブロック」があり、古いクライアントがスキップし、新しいクライアントを説明する方法を理解します.
メンテナンス
構造を変更したり、テーブルを追加したり、操作を追加したり、操作にパラメータを追加したり、新しいタイプを使用するたびに、ABIファイルの更新を覚えておく必要があります.多くの場合、ABIファイルの更新に失敗してもエラーは発生しません.
トラブルシューティング
テーブルはローを返さない
テーブルがGLOSSARY:ABIファイルに正確に記述されているかどうかを確認します.たとえば、フォーマットが間違っているGLOSSARY:ABI定義の契約に
下一篇:配置、発行と移転コイン
紹介する
前に、提供されたABIファイルを使用して
eosio.token
契約を配置しました.このチュートリアルでは、ABIファイルがeosio.token
契約にどのように関連しているかを概説します.eosio.cdt
が提供するeosio-cpp
ユーティリティを使用してABIファイルを生成できますが、ABIの生成に障害が発生したり、完全に失敗したりする可能性があります.高度なC++モードでアップグレードできます.カスタムタイプはABI生成の問題を引き起こすことがあります.そのため、必要に応じてデバッグと修復を行うために、ABIファイルの動作原理を理解する必要があります.ABIとは?
アプリケーションバイナリインタフェース(ABI)は、JSONに基づく記述で、JSONとバイナリ表現の間でユーザー操作を変換する方法を紹介し、ABIはデータベースの状態をJSONまたはJSONから変換する方法を説明し、ABIで契約を記述すると、開発者とユーザーはJSONを通じてシームレスにあなたの契約と対話することができます.
セキュリティの説明
取引を実行するときはABIを迂回することができ、契約に伝達されたメッセージと操作はABIに合致する必要はありません.ABIはドアマンではなくガイドです.
ABIファイルを作成
空のABIから
eosio.token.abi
と名付けられました
{
"version": "eosio::abi/1.0",
"types": [],
"structs": [],
"actions": [],
"tables": [],
"ricardian_clauses": [],
"abi_extensions": [],
"___comment" : ""
}
types
ABIは、任意のクライアントまたはインタフェースが契約のGUIを生成することを説明し、一貫した方法で動作させるために、ABIで説明する必要がある任意の共通操作または構造でパラメータとして使用されるカスタムタイプを説明します.
組み込みタイプ
EOSIOは、ABIファイルに組み込みタイプを記述する必要がなく、多くのカスタム組み込みタイプを実現しています.EOSIOの組み込みタイプを熟知したい場合は、ここで定義します.
{
"new_type_name": "name",
"type": "name"
}
ABIは今このように見えます.
{
"version": "eosio::abi/1.0",
"types": [{
"new_type_name": "name",
"type": "name"
}],
"structs": [],
"actions": [],
"tables": [],
"ricardian_clauses": [],
"abi_extensions": []
}
structs
ABIに曝された構造も記述する必要があり、
eosio.token.hpp
を参照することによって、共通動作がどのような構造を使用しているかを迅速に決定することができ、これは次のステップにとって特に重要である.JSONの構造オブジェクト定義は以下の通りです.
{
"name": "issue", //The name
"base": "", //Inheritance, parent struct
"fields": [] //Array of field objects describing the struct's fields.
}
fields
{
"name":"", // The field's name
"type":"" // The field's type
}
eosio.token
契約では、多くの構造を定義する必要があります.すべての構造が明示的に定義されているわけではありません.いくつかの構造は、動作のパラメータに対応しています.以下は、eosio.token
契約のABI記述が必要な構造のリストです.暗黙構造
以下の構造は暗黙的です.構造は契約で明示的に定義されていないため、create操作を表示すると、
name
のissuer
とasset
のmaximum_supply
の2つのパラメータが見つかります.簡潔化のため、このチュートリアルでは各構造を分解しませんが、同じ論理を適用すると、以下の結果が得られます.create
{
"name": "create",
"base": "",
"fields": [
{
"name":"issuer",
"type":"name"
},
{
"name":"maximum_supply",
"type":"asset"
}
]
}
issue
{
"name": "issue",
"base": "",
"fields": [
{
"name":"to",
"type":"name"
},
{
"name":"quantity",
"type":"asset"
},
{
"name":"memo",
"type":"string"
}
]
}
retire
{
"name": "retire",
"base": "",
"fields": [
{
"name":"quantity",
"type":"asset"
},
{
"name":"memo",
"type":"string"
}
]
}
transfer
{
"name": "transfer",
"base": "",
"fields": [
{
"name":"from",
"type":"name"
},
{
"name":"to",
"type":"name"
},
{
"name":"quantity",
"type":"asset"
},
{
"name":"memo",
"type":"string"
}
]
}
close
{
"name": "close",
"base": "",
"fields": [
{
"name":"owner",
"type":"name"
},
{
"name":"symbol",
"type":"symbol"
}
]
}
明示的な構造
これらの構造は、インスタンス化されたマルチインデックステーブルの条件であるため、上記のような暗黙的な構造を定義するのと何の違いもないことを記述するため、明示的に定義されています.
account
{
"name": "account",
"base": "",
"fields": [
{
"name":"balance",
"type":"asset"
}
]
}
currency_stats
{
"name": "currency_stats",
"base": "",
"fields": [
{
"name":"supply",
"type":"asset"
},
{
"name":"max_supply",
"type":"asset"
},
{
"name":"issuer",
"type":"account_name"
}
]
}
actions
操作のJSONオブジェクト定義は以下の通りです.
{
"name": "transfer", //The name of the action as defined in the contract
"type": "transfer", //The name of the implicit struct as described in the ABI
"ricardian_contract": "" //An optional ricardian clause to associate to this action describing its intended functionality.
}
eosio.token
契約の動作は、eosio.token
契約ヘッダファイルに記述されたすべての共通関数を集約することによって記述される.次に、前に説明した構造に基づいて各操作のタイプを説明します.ほとんどの場合、関数名と構造名は等しくなりますが、等しくする必要はありません.
次に、ソースコードにリンクされたアクションのリストを示します.ここでは、各アクションの説明方法を理解するために、JSONの例を示します.
create
{
"name": "create",
"type": "create",
"ricardian_contract": ""
}
issue
{
"name": "issue",
"type": "issue",
"ricardian_contract": ""
}
retire
{
"name": "retire",
"type": "retire",
"ricardian_contract": ""
}
transfer
{
"name": "transfer",
"type": "transfer",
"ricardian_contract": ""
}
close
{
"name": "close",
"type": "close",
"ricardian_contract": ""
}
tables
説明表、これは表のJSONオブジェクト定義です.
{
"name": "", //The name of the table, determined during instantiation.
"type": "", //The table's corresponding struct
"index_type": "", //The type of primary index of this table
"key_names" : [], //An array of key names, length must equal length of key_types member
"key_types" : [] //An array of key types that correspond to key names array member, length of array must equal length of key names array.
}
eosio.token契約は、2つのテーブル、accounts、statsをインスタンス化します.
Accountsテーブルはi 64インデックスであり、account structに基づいてuint 64がプライマリ・キーとして使用されます.
ABIでaccountsテーブルを説明する方法を以下に示します.
{
"name": "accounts",
"type": "account", // Corresponds to previously defined struct
"index_type": "i64",
"key_names" : ["primary_key"],
"key_types" : ["uint64"]
}
statテーブルはcurrenct_に基づくi 64インデックスです.stats structには、uint 64がプライマリキーとしてあります.
以下に、ABIでstatテーブルを記述する方法を示す.
{
"name": "stat",
"type": "currency_stats",
"index_type": "i64",
"key_names" : ["primary_key"],
"key_types" : ["uint64"]
}
上の表は同じ「key name」を持っていることに気づきます.キーを似た名前に命名するのは象徴的です.これは、主観的な関係を示す可能性があるためです.この実装と同様に、任意の与えられた値を使用して異なる表をクエリーできることを意味します.
一緒に置いて
最後に、
eosio.token
契約を正確に記述するABIファイル.{
"version": "eosio::abi/1.0",
"types": [
{
"new_type_name": "name",
"type": "name"
}
],
"structs": [
{
"name": "create",
"base": "",
"fields": [
{
"name":"issuer",
"type":"name"
},
{
"name":"maximum_supply",
"type":"asset"
}
]
},
{
"name": "issue",
"base": "",
"fields": [
{
"name":"to",
"type":"name"
},
{
"name":"quantity",
"type":"asset"
},
{
"name":"memo",
"type":"string"
}
]
},
{
"name": "retire",
"base": "",
"fields": [
{
"name":"quantity",
"type":"asset"
},
{
"name":"memo",
"type":"string"
}
]
},
{
"name": "close",
"base": "",
"fields": [
{
"name":"owner",
"type":"name"
},
{
"name":"symbol",
"type":"symbol"
}
]
},
{
"name": "transfer",
"base": "",
"fields": [
{
"name":"from",
"type":"name"
},
{
"name":"to",
"type":"name"
},
{
"name":"quantity",
"type":"asset"
},
{
"name":"memo",
"type":"string"
}
]
},
{
"name": "account",
"base": "",
"fields": [
{
"name":"balance",
"type":"asset"
}
]
},
{
"name": "currency_stats",
"base": "",
"fields": [
{
"name":"supply",
"type":"asset"
},
{
"name":"max_supply",
"type":"asset"
},
{
"name":"issuer",
"type":"name"
}
]
}
],
"actions": [
{
"name": "transfer",
"type": "transfer",
"ricardian_contract": ""
},
{
"name": "issue",
"type": "issue",
"ricardian_contract": ""
},
{
"name": "retire",
"type": "retire",
"ricardian_contract": ""
},
{
"name": "create",
"type": "create",
"ricardian_contract": ""
},
{
"name": "close",
"type": "close",
"ricardian_contract": ""
}
],
"tables": [
{
"name": "accounts",
"type": "account",
"index_type": "i64",
"key_names" : ["currency"],
"key_types" : ["uint64"]
},
{
"name": "stat",
"type": "currency_stats",
"index_type": "i64",
"key_names" : ["currency"],
"key_types" : ["uint64"]
}
],
"ricardian_clauses": [],
"abi_extensions": []
}
コイン契約がカバーされていない場合
ベクトル(Vector)
ABIファイルでベクトルを記述する場合は、
[]
の追加タイプを使用するだけです.したがって、パーミッションレベルのベクトルを記述する必要がある場合は、permission_level[]
と記述できます.こうぞうきそ
これはあまり使われていない属性で、base ABI構造属性を使用して別の継承構造を参照することができます.この構造も同じABIファイルで記述されている限り、スマート契約ロジックが継承をサポートしていない場合、Baseは操作を実行しないか、エラーを投げ出す可能性があります.
システム契約のソースコードとABIで使用しているbaseの例を見ることができます.
ここでは追加のABI属性は含まれていません
簡潔化のため、ここではABI仕様のいくつかの属性を省略するが、ABIの各属性を完全に概説する所定のABI仕様がある.
李嘉図条項
李嘉図条項は、特定の行為の予想結果を説明し、送信者と契約の間で条項を確立するためにも使用できます.
ABI拡張
古いクライアントが拡張データを解析する「ブロック」をスキップできる汎用の「未来向け」レイヤです.現在、このプロパティはまだ使用されていません.将来、各拡張はベクトルに独自の「ブロック」があり、古いクライアントがスキップし、新しいクライアントを説明する方法を理解します.
メンテナンス
構造を変更したり、テーブルを追加したり、操作を追加したり、操作にパラメータを追加したり、新しいタイプを使用するたびに、ABIファイルの更新を覚えておく必要があります.多くの場合、ABIファイルの更新に失敗してもエラーは発生しません.
トラブルシューティング
テーブルはローを返さない
テーブルがGLOSSARY:ABIファイルに正確に記述されているかどうかを確認します.たとえば、フォーマットが間違っているGLOSSARY:ABI定義の契約に
cleos
を使用してテーブルを追加し、テーブルからローを取得すると、空の結果が表示されます.契約がGLOSSARY:ABIファイルでテーブルを正しく記述できなかった場合、cleos
はローの追加またはリード時にエラーを発生しません.下一篇:配置、発行と移転コイン