スマートコントラクトABI（Application Binary Interface）

スマートコントラクトABIとは？

スマートコントラクトABI（Application Binary Interface）は、ウォレット、アプリケーション、スクリプト、その他のソフトウェアがスマートコントラクトへの呼び出しをエンコードし、返されたデータをデコードする方法を定める構造化インターフェースです。

公式のSolidity Contract ABI Specificationでは、ABIはEthereumエコシステムのコントラクトとやり取りする標準的な方法と説明されています。

暗号資産分野でABIは、人が読めるスマートコントラクトの関数と、Ethereum Virtual Machineが理解できる低レベルのバイナリデータをつなぐ変換レイヤーとして機能します。開発者は、入力としてアドレスと数量を受け取るtransferというSolidity関数を記述できますが、トランザクションではその要求をエンコード済みの16進数calldataとして送信する必要があります。ABIは、関数名、入力型、出力型、イベント、エラー、コンストラクターの入力、receive関数、fallback関数をソフトウェアでどのように表現するかを定義します。ABIがなければ、どの関数が存在し、どのパラメーターが必要で、結果をどうデコードすればよいかをユーザーやアプリケーションが把握するのははるかに難しくなります。スマートコントラクトABIは、資金を保管したり、コードを実行したり、コントラクトの安全性を証明したりするものではありません。既存またはデプロイ中のコントラクトとの通信方法を説明するものです。簡単に言うと、スマートコントラクトABIは、ソフトウェアがスマートコントラクトの関数を呼び出し、その内容を理解するための説明書です。

暗号資産分野でスマートコントラクトABIが重要な理由

ほとんどのユーザーは、生のcalldataを手入力してスマートコントラクトを操作するわけではないため、スマートコントラクトABIは重要です。ウォレット、分散型アプリケーション、ブロックチェーンエクスプローラー、スクリプト、ボット、分析プラットフォーム、開発者ツールは、ABIを使って読みやすい操作を有効なブロックチェーン呼び出しに変換します。

公式のEthereumのスマートコントラクトコンパイルに関するドキュメントでは、コンパイラーがABIを生成し、アプリケーションがコントラクトを理解して関数を呼び出せるようにすると説明されています。

これは、トークン転送、DeFiへの入金、NFTのミント、ステーキング、ガバナンス投票、ブリッジの操作、ボールトからの出金、その他のスマートコントラクト操作で重要です。たとえばウォレットは、長い16進数の入力欄だけを表示する代わりに、ABIを使ってトランザクションがapproveを呼び出していると示せます。ブロックチェーンエクスプローラーは、ABIを使ってトランザクションの入力データをデコードし、読みやすいパラメーターとして表示できます。開発者のスクリプトは、ABIを使うことでcalldataの全バイトを手作業で組み立てずに関数を呼び出せます。ABIはイベントの理解にも役立ちます。ソフトウェアがイベント名やインデックス付きの値をデコードできると、ログがより有用になります。ABIがなければ、スマートコントラクトとのやり取りは読みづらく、使いにくく、エラーが発生しやすくなります。そのためABIは、EVMベースの暗号資産アプリケーションにおける最も重要なユーザビリティ層の一つです。

スマートコントラクトABIの仕組み

スマートコントラクトABIは、スマートコントラクトのデータをエンコード・デコードするスキーマを定義します。ABIには呼び出し可能な関数が列挙され、関数名、入力型、出力型、状態変更性、その他のインターフェース情報が記載されます。ユーザーが関数を呼び出すと、ウォレットやアプリケーションのソフトウェアはABIを読み取り、関数セレクターと入力引数をcalldataにエンコードします。そのcalldataはトランザクションのdataフィールドに入れられるか、読み取り専用の呼び出しに使われます。コントラクトはcalldataを受け取り、バイトコードが対応するセレクターと一致すれば、EVMが関数を実行します。関数がデータを返す場合、ABIに従ってソフトウェアが返されたバイトを読みやすい値にデコードします。呼び出しによってイベントが発生した場合、ABIを使ってログをイベント名やフィールドにデコードできます。呼び出しがカスタムエラーを返してrevertした場合、ABIはエラーの種類や引数のデコードに役立ちます。トランザクションが成功するかどうかをABIが決めるわけではありません。成否はコントラクトコード、ブロックチェーンの状態、ガス、権限、入力値によって決まります。ABIが定めるのは、そのコントラクトとの通信をどのようにエンコード・デコードするかだけです。

ABIのJSON形式

スマートコントラクトABIは通常、JSON配列で表されます。Solidity ABI仕様では、コントラクトインターフェースのJSON形式は関数、イベント、エラーの説明を含む配列とされています。ABI形式やコンパイラのバージョンによって異なりますが、関数項目にはtype、name、inputs、outputs、stateMutability、payable関連情報などが含まれます。入出力にはaddress、uint256、bool、bytes、string、配列、タプルなどの型情報が含まれます。イベント項目には、イベント名、インデックス付きパラメーター、インデックスなしのパラメーターが記載されます。エラー項目には、カスタムエラーとその入力パラメーターが記載されます。コンストラクター項目には、デプロイ時のパラメーターが記載されます。receiveとfallbackの項目には、ネイティブ資産の単純な転送や、関数に一致しない呼び出しに対する特殊な動作が記載されます。ABIは構造化されたJSONであるため、開発者ツールはこれを解析して利用可能なコントラクトオブジェクトを作成できます。このため多くのアプリケーションでは、ABIから読みやすいボタン、フォーム、トランザクションプレビュー、イベントデコーダーを生成できます。

関数セレクター

関数セレクターとは、どのコントラクト関数を呼び出すか識別するために使われる最初の4バイトです。Solidity ABI仕様では、関数呼び出しのcalldataの最初の4バイトが呼び出す関数を指定すると説明されています。セレクターは、関数名と正確な入力型を含む正規化された関数シグネチャから計算されます。たとえば、関数シグネチャはtransfer(address,uint256)のようになります。ソフトウェアはシグネチャをハッシュ化し、先頭4バイトを関数セレクターとして使用します。calldataには人が読める関数名がそのまま含まれないため、セレクターは重要です。コントラクトはセレクターを読み取り、バイトコードが対応していれば一致する関数へ呼び出しを振り分けます。同じ名称でも入力型が異なる関数は、正規化されたシグネチャが異なるためオーバーロードできます。オーバーロードされた関数は、インターフェースが不明確だとユーザーやツールが混同することがあるため、開発者は注意が必要です。関数セレクターは小さく効率的であり、ABIベースのスマートコントラクト呼び出しの中心的な要素です。

Calldata

Calldataとは、スマートコントラクトの呼び出しとともに送信されるエンコード済み入力データです。

公式のEthereumトランザクションのドキュメントでは、アプリケーションがコントラクトへ情報を送信する方法の一部としてトランザクションデータが説明されています。

通常のコントラクト関数呼び出しでは、calldataは4バイトの関数セレクターで始まり、その後にABIでエンコードされた引数が続きます。ユーザーがトークンのtransfer関数を呼び出すと、calldataにはその関数のセレクターと、エンコードされた受取人アドレスおよびトークン数量が含まれます。ユーザーがswap関数を呼び出す場合、コントラクトの設計に応じて、経路、数量、受取人、期限、その他のエンコード済みパラメーターがcalldataに含まれることがあります。トランザクションの入力データは公開されたトランザクション記録の一部であるため、calldataはパブリックブロックチェーン上で閲覧できます。コントラクトに対応するABIがあれば、ブロックチェーンエクスプローラーはcalldataをデコードできます。ABIが欠落または誤っていると、同じcalldataが読めない16進数データとして表示されたり、誤ってデコードされたりする場合があります。トランザクション内で署名すると、calldataによって強力な操作が許可されることがある点に注意してください。ABIとcalldataを理解すると、スマートコントラクトのトランザクションが実際に何をしようとしているのか把握しやすくなります。

戻り値データ

戻り値データとは、関数実行後にコントラクトが返すエンコード済みの出力です。読み取り専用の呼び出しでは、残高、利用許可、トークン名、所有者アドレス、総供給量、プール準備金、ガバナンス提案の状態、ボールトのシェア価格などが返されることがあります。ABIは、クライアントソフトウェアが返されたバイトを意味のある値にデコードする方法を定めます。関数がuint256を返す場合、ABIに従ってソフトウェアは戻り値データを符号なし整数としてデコードします。関数が複数の値を返す場合、ABIは各値の順序と型を定めます。関数がタプルや配列を返す場合、ABIは正しくデコードするために必要な入れ子構造を定めます。誤ったABIを使うと、バイトが別の型として解釈され、戻り値データが分かりにくくなることがあります。誤った解釈は、アプリケーションの表示不良、スクリプトの失敗、分析の誤りにつながる可能性があります。開発者は、フロントエンドやスクリプトがデプロイ済みコントラクトのバージョンに一致するABIを使っていることを確認してください。ダッシュボード、DeFiインターフェース、ウォレット表示の信頼性には、戻り値データの適切なデコードが欠かせません。

イベントとログ

イベントは、トランザクションの実行中にスマートコントラクトが出力する構造化ログです。ABIにはイベント名、パラメーター型、パラメーターがインデックス化されているかどうかが記載されます。インデックス付きイベントパラメーターは、ノードやインデクサーが効率的に検索できます。インデックスなしのパラメーターはイベントデータに保存され、ABIに従ってデコードされます。イベントは、トークン転送、承認、入金、出金、スワップ、強制決済、NFTミント、ガバナンス投票、設定変更などで広く使われます。ブロックチェーンエクスプローラーや分析ツールは、ABIを使ってイベントログを読みやすく表示します。トークンのTransferイベントは、送信者、受取人、数量にデコードされると理解しやすくなります。アプリケーションはイベントをインデックス化し、履歴、チャート、通知、ポートフォリオ表示を作成することが多いため、イベントはオフチェーンシステムにとって重要です。ただし、イベントはコントラクトの状態そのものではなく、実行によって生成されたログです。開発者とユーザーは、実際の状態変化やコントラクトのロジックと合わせてイベントを解釈してください。

エラーとrevertデータ

条件を満たさない場合、スマートコントラクトはrevertすることがあり、最新のSolidityコントラクトではカスタムエラーを使えます。ツールがrevertデータを分かりやすくデコードできるよう、ABIにエラーの説明を含められます。デコードされたカスタムエラーから、残高不足、権限の欠如、期限切れ、無効な署名、その他コントラクトが定義した条件により呼び出しが失敗したことが分かる場合があります。ABIに基づくエラーデコードがなければ、ユーザーには曖昧な失敗メッセージや生の16進数のrevert値しか表示されないことがあります。場合によっては、長いrevert文字列よりカスタムエラーのほうがガスを削減できます。開発者にとって明確なエラー定義は、デバッグを容易にします。ユーザーにとって読みやすいエラーは、トランザクションのシミュレーション失敗による混乱を減らせます。ただし、デコードされたエラーだけでトランザクションが失敗した経済的な理由まで分かるとは限りません。スワップがスリッページで失敗した場合でも、根本的な原因は市場変動、流動性制限、期限設定かもしれません。ABIによるエラーデコードは便利ですが、トランザクションの全体的な状況も確認してください。

コンストラクター

コンストラクターは、コントラクトのデプロイ時に実行される特殊な関数です。ABIにはコンストラクターの入力を含めることができ、デプロイツールはそれを基にデプロイ引数をエンコードします。コンストラクターの引数には、トークン名、シンボル、初期所有者、オラクルアドレス、資金管理用アドレス、ガバナンスパラメーター、初期設定値などが含まれる場合があります。デプロイ用バイトコードとコンストラクターの引数が組み合わさって、最終的にデプロイされたコントラクトが作られます。ソースコードの検証では、ソースファイルやコンパイラー設定に加えて、コンストラクターの引数との一致が求められることがあります。

公式のEthereumスマートコントラクト検証のドキュメントでは、検証によってコントラクト作成時に使われたソースコードとコンパイル済みバイトコードを照合すると説明されています。

コンストラクターの引数を誤ると、デプロイされたコントラクトが意図と異なる動作をする可能性があります。アップグレード可能なプロキシシステムでは、プロキシのストレージを初期化するため、コンストラクター形式の設定の代わりにinitializerが使われることがよくあります。コントラクトを確認するユーザーは、重要な初期設定がコンストラクターで行われたのか、別のinitializerで行われたのかを理解する必要があります。コンストラクターのABI情報は、デプロイの透明性と再現性を高めます。

Receive関数とfallback関数

Receive関数とfallback関数は、ネイティブ資産の単純な転送や、ほかの関数セレクターに一致しない呼び出しを処理する特殊なコントラクトのエントリーポイントです。SolidityのABI JSON形式には、receiveやfallbackの説明を含めることができます。コントラクトが空のcalldataとともにネイティブ資産を受け取ると、receive関数が実行されることがあります。calldataが既存の関数に一致しない場合や、特定の転送に対してreceive関数が用意されていない場合、fallback関数が実行されることがあります。これらの関数は、決済コントラクト、プロキシコントラクト、ラッパー、オークション、緊急時の処理で重要になる場合があります。一方、開発者がコントラクトに予期しない呼び出しや資金が届く可能性を忘れると、セキュリティリスクになることがあります。receiveやfallbackの動作を利用する際、ユーザーに分かりやすい関数名が常に表示されるとは限りません。ウォレットやエクスプローラーでは、通常のABI関数呼び出しとは異なる方法で表示されることがあります。隠れたfallbackロジックがユーザーを驚かせないよう、開発者はその動作を明確に説明する必要があります。fallback関数とreceive関数は、ABIが通常の名称付き関数以外も記述できることを示しています。

静的型と動的型

ABIは静的型と動的型のエンコード方法を定義します。address、bool、bytes32、uint256などの静的型は、サイズが固定されています。string、bytes、動的配列、一部の入れ子になったタプル構造などの動的型は、サイズが変わります。Solidity ABI仕様では、静的値と動的値のエンコード規則が説明されています。動的値では、実データの位置を示すオフセットが必要になることがよくあります。このhead-and-tail形式のエンコードにより、複雑な関数引数を決定的なcalldataにまとめられます。通常、ライブラリやツールが処理するため、開発者が手動でエンコードする必要はありません。ただし、静的・動的エンコードを理解していると、生のcalldataや失敗したトランザクションのデバッグに役立ちます。セキュリティ研究者は、エクスプロイト、不正なcalldata、特殊なコントラクト操作を分析する際にABIエンコードを調べることがあります。静的型と動的型は、信頼できるコントラクト通信の基礎です。

配列とタプル

スマートコントラクトABIでは配列やタプルを記述できます。配列には、アドレスや数量のリストなど、同じ型の複数の値を格納できます。タプルは、複数の異なるフィールドを1つの構造化された値にまとめられます。タプルは、複雑なDeFiポジション、注文構造、ガバナンス提案データ、入れ子になった設定値に便利です。ABIエンコードでは、すべてのフィールドの正確な順序と型を維持する必要があります。タプルのフィールド順が誤っていると、トランザクションが失敗したり、意図しない結果になったりする場合があります。配列の長さが誤っていると、コントラクトが呼び出しを拒否したり、データを誤って解釈したりする可能性があります。ウォレットやフロントエンドは、ユーザーが署名内容を理解できるよう、複雑なABI入力を明確に表示する必要があります。より単純な構造で実現できる場合、開発者は公開インターフェースを不必要に複雑にしないようにしてください。複雑なABI型は強力ですが、ユーザーインターフェースの設計とテストをより慎重に行う必要があります。

ABIとスマートコントラクトのバイトコード

ABIはスマートコントラクトのバイトコードとは異なります。バイトコードは、EVMが実行する低レベルのコードです。ABIは、外部ソフトウェアが呼び出しをエンコードし、データをデコードするためのインターフェース説明です。デプロイされたコントラクトはランタイムバイトコードをオンチェーンに保存しますが、人が読める完全なABIが通常、実行ロジックとしてコントラクトに保存されることはありません。アプリケーションは、コンパイル済み成果物、検証済みソースコード、メタデータ、パッケージファイル、開発者のリポジトリ、ブロックチェーンエクスプローラーのデータベースなどからABIを取得することがよくあります。公開ABIを見つけにくくても、コントラクトはオンチェーンに存在できるため、この違いは重要です。ABIがなくても、エンコード方法が分かれば生のcalldataを送信できますが、多くのユーザーには難しく、リスクもあります。ABIが誤っていると、ツールが誤解を招く関数名やパラメーターを表示する可能性があります。実行されるのはバイトコードであり、ABIは実行中のコードとソフトウェアがどのように通信するかを示します。どちらも重要ですが、役割は異なります。

ABIとソースコード検証

ソースコードの検証によって、ツールがコントラクトABIを取得または確認しやすくなることがあります。コントラクトのソースコードとコンパイラー設定が検証されると、ブロックチェーンエクスプローラーで関数、イベント、コントラクト操作画面をより明確に表示できます。Ethereumの検証に関するドキュメントでは、検証は公開されたコントラクトコードとオンチェーンで実行されるコードに違いがないか確認するのに役立つと説明されています。検証済みコントラクトは、ユーザーが読みやすい関数やイベントを確認できるため、ABIを使った操作が容易になることがよくあります。ただし、検証によってコントラクトの安全性が保証されるわけではありません。検証済みABIは、コントラクトとのやり取りの方法を把握する助けにすぎません。コントラクトには、バグ、安全でない管理者権限、アップグレードリスク、悪意のあるロジック、欠陥のある経済設計が残っている可能性があります。検証済みABIは透明性を示す情報として扱い、安全性の保証とみなさないでください。開発者はソースコードを検証し、ABIデータを公開して、ユーザーやツールが安全に操作できるようにする必要があります。承認や入金を求める、未検証でABIが不明なコントラクトには特に注意が必要です。

ABIとコントラクトメタデータ

Solidityのコントラクトメタデータには、ABI情報、コンパイラー設定、ソース参照、その他のビルド情報が含まれる場合があります。

公式のSolidityコントラクトメタデータのドキュメントによると、メタデータには現在のコントラクトに関する情報が含まれ、コンパイラーのバージョン、ソース、ABI、NatSpecドキュメントの照会に使えます。

メタデータは、デプロイされたバイトコードをソースファイルやコンパイル時の情報に結び付けるのに役立ちます。ソースファイル、コンパイラーオプション、メタデータのわずかな違いでも最終的なバイトコードが変わることがあるため、これは重要です。開発者は、後からコントラクトを検証しデプロイを再現できるよう、ビルド成果物を保管してください。アプリケーションは、コントラクトのアップグレードや再デプロイ後に古いABIファイルを使わないようにする必要があります。メタデータは透明性を高めますが、ユーザーは通常、ブロックチェーンエクスプローラーや開発者ツールを通じて確認します。メタデータとABIデータが利用可能であれば、コントラクトの操作を確認・自動化しやすくなります。メタデータがない場合、ユーザーはプロジェクト提供のABIや手動のリバースエンジニアリングに頼る必要があるかもしれません。適切なメタデータ管理は、専門的なスマートコントラクト開発の一部です。

ABIとウォレット

ウォレットはABI情報を使って、スマートコントラクトとのやり取りを読みやすくします。正しいABIまたは関連するデコード情報があれば、ウォレットはトランザクションをapprove、transfer、swap、stake、mint、claim、vote、withdrawなどとして表示できる場合があります。デコードされていない場合、ウォレットには生の16進数データだけが表示されることがあります。読みやすいトランザクション確認画面は、危険な署名を避ける助けになります。ただし、ウォレットのデコードは利用可能なABIデータ、コントラクトの識別、トランザクションシミュレーション、インターフェースの品質に依存するため、常に正確とは限りません。悪意のあるウェブサイトが、分かりにくい、または不完全に見える有害なトランザクションへの署名をウォレットに求めることもあります。署名する前に、コントラクトアドレス、トークン数量、spenderアドレス、権限変更を確認してください。可能な限り、ウォレットはABIでデコードした詳細を平易な言葉で表示する必要があります。開発者は、ウォレットがトランザクションの意味を明確に伝えられるよう、関数やイベントを設計してください。ABIによってウォレットの表示は改善しますが、ユーザーの注意は依然として不可欠です。

ABIと分散型アプリケーション

分散型アプリケーションはABIを使って、フロントエンドのボタンやフォームをスマートコントラクトの関数に接続します。ユーザーが入金ボタンをクリックすると、アプリケーションはABIを使ってdeposit関数の呼び出しをエンコードします。ダッシュボードにユーザーの残高を表示するとき、アプリケーションはABIを使って読み取り専用のbalance関数を呼び出すことがあります。イベントを監視するアプリケーションは、ABIを使ってコントラクトが出力したログをデコードします。このようにABIは、ウェブインターフェースとオンチェーンコントラクトをつなぎます。コントラクトが正常でも、ABIが誤っていればアプリケーションが機能しないことがあります。コントラクトのアップグレード後に古いABIを使うと、フロントエンドの呼び出しが失敗する可能性があります。不完全なABIでは、アプリケーションに必要な関数やイベントが利用できないことがあります。開発者は、ABIの成果物をデプロイ済みコントラクトのバージョンと同期させる必要があります。ウェブサイトがインターフェースに表示した操作と一致しないトランザクションへの署名を求める場合は注意してください。

ABIと読み取り専用の呼び出し

読み取り専用の呼び出しは、ブロックチェーンの状態を変更せずにコントラクトデータを照会するため、ABIエンコードを利用します。

公式のEthereum JSON-RPC APIのドキュメントでは、通常の状態変更トランザクションを作成せずにメッセージ呼び出しを実行できるeth_callなどのメソッドが説明されています。

読み取り専用の呼び出しは、残高、利用許可、準備金、レート、提案の状態、所有者アドレス、トークンメタデータ、ユーザーポジションの確認に使われます。ソフトウェアが関数要求をエンコードし、返されたデータをデコードするには、こうした呼び出しでもABI情報が必要です。状態を変更しないため、読み取り専用の呼び出しでは通常ユーザーの署名は必要ありません。ただし、フロントエンドは表示データの内容と取得元を正確に示す必要があります。RPCエンドポイントの遅延や古いデータのキャッシュにより、読み取り結果が最新でないことがあります。現在の状態で関数がrevertする場合、読み取り専用の呼び出しが失敗することもあります。ABIはコントラクトの読み取り専用データをユーザーやアプリケーションが利用できるようにします。このため、ABIはダッシュボードやポートフォリオツールの中核を担います。

ABIと状態変更トランザクション

状態変更トランザクションは、コントラクトの状態を変更する要求をABIでエンコードします。例として、トークンの転送、spenderの承認、担保の入金、借入、返済、ステーキング、投票、ミント、NFTの出品、報酬の請求などがあります。これらのトランザクションでは通常、ウォレット署名とネットワーク手数料が必要です。ABIはウォレットやアプリが呼び出しをエンコードする方法を定めますが、実際のトランザクションを承認するのはユーザーの署名です。正しいABIを使っても、呼び出し先のコントラクトが悪意のあるものだったり、パラメーターが危険だったりすれば、トランザクションは安全になりません。ユーザーは、悪意のあるspenderを承認したり、誤ったアドレスへ資産を送ったり、ABIでエンコードされたcalldataを通じて偽コントラクトを操作したりする可能性があります。デコードされた操作が意図した操作と一致するか確認してください。開発者は、ユーザーの混乱を減らすため、明確な関数名、イベント、型付き入力を使ってください。状態変更を伴うABI呼び出しは、金融上の指示として扱う必要があります。トランザクションが承認されると、ブロックチェーン上で簡単に取り消せない場合があります。

ABIとERC-20トークン

ERC-20トークンは、多くのウォレットやアプリケーションが理解できる共通インターフェースを使います。

公式のERC-20トークン規格では、totalSupply、balanceOf、transfer、allowance、approve、transferFrom、Transfer、Approvalなどの関数やイベントが定義されています。

ERC-20形式のトークンABIを使うと、ソフトウェアでこれらの関数を呼び出し、イベントをデコードできます。このため、多くのウォレットはトークンごとに個別の連携を行わなくても残高や承認を表示できます。ただし、実際にはすべてのトークンが同じように動作するとは限りません。手数料、リベースロジック、一時停止、ブラックリスト、アップグレード機能、一般的でない戻り値の動作を備えるトークンもあります。ABIは呼び出し可能なインターフェースを記述できますが、経済面や権限に関するすべてのリスクを説明するものではありません。トークンABIはソフトウェアがトークンを操作する助けになりますが、ユーザーはトークンコントラクトの動作も確認する必要があります。見慣れたABIに対応しているからといって、すべてのトークンがあらゆるDeFi連携で安全だと開発者が決めつけてはいけません。ABIの互換性は便利ですが、動作の互換性もテストする必要があります。

ABIとNFT

NFTコントラクトも、所有権、承認、転送、メタデータ、イベントに関するABIベースのインターフェースを利用します。

公式のERC-721規格は、非代替性トークンのインターフェースを定義しています。

公式のERC-1155規格は、代替可能資産と非代替性資産の両方を表せるマルチトークンインターフェースを定義しています。

対応している場合、ウォレットやマーケットプレイスはABIを使ってownerOf、tokenURI、safeTransferFrom、balanceOf、setApprovalForAllなどのNFT関連関数を呼び出します。ABIはNFTの転送イベントや承認イベントのデコードにも役立ちます。ただし、ABIはNFTの画像、コレクション、メタデータが本物であることを証明しません。偽NFTコントラクトが、別のプロジェクトの名称やアートを複製しながら、見慣れたABI関数を提供することがあります。NFTを信頼する前に、コントラクトアドレス、コレクションの詳細、メタデータ、マーケットプレイスの情報、公式プロジェクトの情報源を確認してください。ABIはNFTの操作に役立ちますが、文化的価値、法的価値、市場価値を認定するものではありません。NFTの安全性を確認するには、技術的なデコードと真正性の確認の両方が必要です。

ABIとプロキシ

アップグレード可能なプロキシコントラクトでは、ABIの扱いが複雑になります。ユーザーが操作するアドレスはプロキシでも、ロジックを含みユーザーが想定するABIに対応するのは現在の実装コントラクトの場合があります。

公式のEthereumのスマートコントラクトアップグレードに関するドキュメントでは、アップグレードパターンによりデプロイ後にスマートコントラクトの動作を変更できると説明されています。

プロキシがアップグレードされると、操作に必要なABIが変わる場合があります。古いABIを使うアプリケーションは、アップグレード後に失敗したり、関数を誤って表示したりすることがあります。アップグレード可能なコントラクトを確認するユーザーは、プロキシと実装コントラクトの両方を確認してください。利用可能な場合、ブロックチェーンエクスプローラーにはプロキシの検出情報、実装アドレス、ABIデータが表示されます。開発者は新しい実装ごとにABIを公開・検証する必要があります。アップグレードの発表では、ユーザーが使う関数、イベント、権限に変更があるかを説明してください。アップグレード可能なシステムでは、ABI管理もアップグレードの安全性を保つ一部です。

ABIとAPIの違い

ABIは通常のウェブAPIとは異なります。ウェブAPIは通常、インターネット経由でソフトウェアがサーバーと通信する方法を記述します。スマートコントラクトABIは、ブロックチェーン上のコントラクトバイトコードへの呼び出しをソフトウェアがエンコード・デコードする方法を記述します。ウェブAPIは、ブロックチェーンの状態を変更せずにサーバー運用者が変更できる場合があります。スマートコントラクトABIは通常、デプロイ済みコントラクトの関数やイベントに対応します。ウェブAPIは、多くの場合サーバーからJSONを直接返します。スマートコントラクトABIは、バイナリデータをcalldata、戻り値データ、ログにどう格納するかを定めます。どちらもソフトウェアが別のシステムと通信する助けになる点で、関連しています。異なるのは、スマートコントラクトABIが決定論的なオンチェーン実行と公開トランザクションデータに結び付いていることです。暗号資産分野でABIはコントラクトとの通信を指し、カスタマーサービスAPIへのアクセスを意味するものではありません。

ABIとソースコードの違い

ABIはスマートコントラクトのソースコードと同じではありません。ソースコードには、動作を定義する内部ロジック、状態変数、修飾子、継承、条件、計算が記述されています。ABIはソフトウェアが呼び出したりデコードしたりできる外部インターフェースを示します。ABIが単純でも、内部の動作が複雑なコントラクトはあります。トークンがtransferやapprove関数を公開していても、手数料や管理者ルールがソースコード内に複雑に隠れている場合があります。DeFiボールトがdepositやwithdraw関数を公開しつつ、内部では複雑なシェア計算を行うこともあります。ABIだけを見て安全性を判断しないでください。適切なセキュリティレビューには、ソースコード、バイトコード、テスト、デプロイ設定、プロトコルのドキュメントが必要です。ABIは操作方法を示し、ソースコードは操作後に何が起きるかを説明します。どちらも役立ちますが、答える問いは異なります。

ABIのセキュリティリスク

スマートコントラクトABIが誤っている、古い、不完全である、または意図的に誤解を招く場合、セキュリティリスクが生じることがあります。誤ったABIによって、ソフトウェアが呼び出しを誤ってエンコードする可能性があります。古いABIでは、アップグレード後に存在しない関数を呼び出してしまうことがあります。悪意のあるインターフェースが、無害に見える操作を表示しながら、危険なコントラクト呼び出しをエンコードすることがあります。偽サイトがABIを使い、正規のウォレットに承認や資産転送を求める可能性があります。ABIがデプロイ済みバイトコードに一致しない場合、ブロックチェーンエクスプローラーがデータを誤ってデコードすることがあります。関数名が見慣れたものだからといって、トランザクションを信用してはいけません。署名する前に、コントラクトアドレス、spenderアドレス、トークン数量、権限を確認してください。開発者はABIファイルをバージョン管理し、デプロイ後に正確な成果物を公開する必要があります。ABIの安全性は、正確なインターフェースデータと慎重なトランザクション確認に左右されます。

セレクターの衝突

セレクターの衝突とは、異なる2つの関数シグネチャが同じ4バイトのセレクターを生成することです。関数セレクターはわずか4バイトなので、通常のコントラクト設計ではまれですが、衝突する可能性があります。セレクターの衝突は、プロキシシステム、プラグインシステム、diamond形式のアーキテクチャ、多数の関数を持つコントラクトで特に重要です。セレクターの振り分け設計が不適切だと、呼び出しが意図しないロジックに到達する可能性があります。複雑なシステムでは、開発者はツールを使ってセレクターの競合を検出してください。明確さが重要なユーザー向けインターフェースでは、不要な関数オーバーロードを避ける必要もあります。ユーザーがセレクターを手作業で計算する必要はほとんどありませんが、開発者が明確なインターフェースを設計すれば、ユーザーにも利点があります。セキュリティレビューでは、プロキシやモジュール型コントラクトシステムのセレクターにも注意を払う必要があります。セレクターの衝突は、ABIの詳細がセキュリティ上の問題になり得ることを示しています。読みやすい関数名は、低レベルのセレクターとエンコード済みデータに付けられたラベルにすぎません。

ABIと人が読めるインターフェース

多くの開発者ツールでは、ABIを完全なJSONではなく、人が読める形式で記述できます。人が読めるABIには、function transfer(address,uint256) returns (bool)のような簡潔な文字列を含められます。この形式は、スクリプトやテストを記述する開発者にとって扱いやすい場合があります。コンパイラーの成果物や本番アプリケーションのビルドでは、完全なJSON ABIが今もよく使われます。コントラクトインターフェースの一部だけが必要な場合、人が読めるABI文字列は便利です。たとえば、スクリプトでトークンABI全体ではなく、balanceOfとtransferだけが必要な場合があります。ただし、部分ABIでは、レビューに必要な関数やイベントが隠れる可能性があります。開発者は完全なアプリケーションや検証ワークフローを構築する際、完全なABIを使ってください。アプリケーションが、把握している関数だけを使ってコントラクトを操作する場合があることをユーザーも理解する必要があります。部分ABIは開発に便利ですが、コントラクトの完全な説明ではありません。

ABIとNatSpec

NatSpecは、Solidityの自然言語仕様形式で、コントラクト、関数、パラメーター、戻り値、開発者向けメモを文書化します。

公式のSolidity NatSpecのドキュメントでは、開発者がソースコードのコメントにユーザー向け・開発者向けドキュメントを記載する方法が説明されています。

NatSpecはABIとは異なりますが、ABIを使った操作を補完できます。ABIは関数の型とエンコード規則をソフトウェアに伝えます。NatSpecは、関数の目的やパラメーターの意味を説明できます。対応している場合、ウォレットやインターフェースはドキュメント形式のメタデータを利用し、より明確な署名確認画面を表示できます。開発者は、リスクのある関数、権限、ユーザーに影響する動作を明確に文書化してください。ABIにapproveという関数名があっても、spenderや数量が重要である理由はドキュメントで説明できます。より良いドキュメントは、ユーザーのミスを減らし、監査時の読みやすさを高めます。ABIとNatSpecを組み合わせることで、低レベルのコントラクト操作と人の理解をより強くつなげられます。

ABIとコントラクト間の呼び出し

スマートコントラクトは、インターフェースを使って別のコントラクトを呼び出せます。Solidityのインターフェースでは、別のコントラクトが呼び出す関数シグネチャを定義できます。呼び出し側が関数セレクターと引数を正しくエンコードする必要があるため、これはABIの概念に関係します。プロトコルがトークンコントラクト、オラクルコントラクト、ボールトコントラクト、ガバナンスコントラクト、その他のアプリケーションコントラクトを呼び出すため、コントラクト間の呼び出しはDeFiのコンポーザビリティの中心です。ただし、インターフェースが記述するのは、呼び出しを想定する関数だけです。対象アドレスのコントラクトが安全に動作する証明にはなりません。悪意のあるコントラクトが、想定されたABIを公開しながら、内部で予想外の動作をすることがあります。開発者は外部コントラクトを連携する前に、アドレスと前提条件を検証してください。呼び出しの失敗や予期しない戻り値にも適切に対応する必要があります。ABIの互換性はコントラクト間の通信を助けますが、信頼性や動作の確認は別途必要です。

ABIとブロックチェーンエクスプローラー

ブロックチェーンエクスプローラーはABIを使って、コントラクトとのやり取りを読みやすく表示します。ABIが利用できる場合、エクスプローラーはトランザクション入力データ、イベントログ、コントラクトの読み取り・書き込み関数をデコードできます。これにより、トランザクションがtransfer、approve、mint、stake、withdrawなど、どの関数を呼び出したかをユーザーが把握できます。開発者が失敗したトランザクションをデバッグし、イベント履歴を確認するのにも役立ちます。コントラクトが検証済みであれば、エクスプローラーはABIからコントラクト操作ページを生成できることがよくあります。コントラクトが未検証の場合、エクスプローラーに生のcalldataが表示されたり、ユーザーが提出したABIに依存したりすることがあります。ブロックチェーンエクスプローラーの書き込みパネルから直接操作する場合、署名した操作は実資産に影響するため注意してください。ABIの内容が読みやすく表示されても、コントラクトの安全性が高まるわけではありません。操作を理解しやすくするだけです。ブロックチェーンエクスプローラーは便利な調査ツールですが、ウォレットのセキュリティやコントラクトのデューデリジェンスも引き続き必要です。

スマートコントラクトABIでよくある間違い

よくある間違いの一つは、ABIがコントラクトの安全性を証明すると考えることです。もう一つは、別バージョンのコントラクト用ABIを使うことです。3つ目は、プロキシアドレスを理解せずに実装コントラクトのABIを使うことです。4つ目は、コントラクトアドレスを確認せず、デコードされた関数名を信用することです。5つ目は、部分ABIを使い、重要なイベントやエラーを見落とすことです。6つ目は、オーバーロードされた関数を見落とし、誤ったシグネチャを選択することです。7つ目は、コントラクトのアップグレード後にフロントエンドのABIファイルを更新しないことです。8つ目は、トークンABIとの互換性を、そのトークンが安全に動作する証拠とみなすことです。9つ目は、リスクを理解せず、未検証コントラクトを生のcalldataで操作することです。10個目は、ウォレットのデコードが常に完全かつ正確だと思い込むことです。

スマートコントラクトABIの評価方法

まず、ABIが操作予定の正確なコントラクトアドレスに対応していることを確認します。コントラクトがプロキシか、実装コントラクトのABIを使うべきか確認します。ソースコードが検証済みか、ABIが検証済みソースと一致するか確認します。該当する場合、ABIに関数、イベント、エラー、コンストラクターの詳細、特殊なreceive関数やfallback関数が含まれるか確認します。ABIのバージョンがアップグレード後のデプロイ済みコントラクトのバージョンに一致しているか確認します。ABIが完全なものか、スクリプトで使う部分インターフェースにすぎないのか確認します。approve、transferFrom、mint、burn、pause、upgradeTo、setOracle、withdraw、setRoleなど、重要な関数を確認します。ユーザー向けアプリケーションが、ABIでデコードしたトランザクションの詳細を明確に表示するか確認します。可能であれば、信頼できる開発者の成果物、検証済みエクスプローラーのデータ、公式プロジェクトリポジトリを利用してください。適切なABIレビューでは、インターフェースが正確で、完全で、最新であり、正しいアドレスに関連付けられているかを確認します。

スマートコントラクトABIのメリット

スマートコントラクトABIの1つ目のメリットは、スマートコントラクトとのやり取りを読みやすくすることです。2つ目は、関数呼び出しを正確にエンコードできることです。3つ目は、戻り値データやイベントログをデコードできることです。4つ目は、ウォレットのトランザクション表示を改善できることです。5つ目は、フロントエンドから構造化インターフェースを通じてコントラクトを呼び出せるため、dApp開発が容易になることです。6つ目は、ユーザーが関数やイベントを明確に確認でき、ブロックチェーンエクスプローラーを使いやすくなることです。7つ目は、スクリプト、ボット、インデクサー、監視システムの自動化を改善できることです。8つ目は、ABI定義からコントラクトオブジェクトを生成できるため、コントラクトのテストが容易になることです。9つ目は、トークン規格やアプリケーションプロトコルとの連携が円滑になることです。10個目は、ABIデータが検証済みソースコードと結び付いている場合、透明性が高まることです。

スマートコントラクトABIのリスクと制約

1つ目の制約は、ABIがコントラクトの安全性を証明しないことです。2つ目は、ABIに内部ロジックのすべてが示されないことです。3つ目は、誤ったABIによってデータのエンコードやデコードを誤る可能性があることです。4つ目は、古いABIによってアップグレード後にアプリケーションが動作しなくなる場合があることです。5つ目は、部分ABIによって重要な関数やイベントが見えない可能性があることです。6つ目は、ABIによるデコードで、悪意のあるトランザクションが実際より見慣れた操作に見える場合があることです。7つ目は、複雑なシステムで関数セレクターの衝突が問題になる可能性があることです。8つ目は、ABIの互換性が動作の互換性を保証しないことです。9つ目は、デコードされたトランザクション確認画面をユーザーが誤解する可能性が残ることです。10個目は、ABIデータを本当に役立てるには、通常、ソースコードの検証、ドキュメント、セキュリティレビューが必要なことです。

開発者向けベストプラクティス

デプロイ時に使用した正確なコンパイラー成果物からABIを生成してください。コントラクトのバージョンとデプロイアドレスが分かるようにABIファイルをバージョン管理してください。検証済みソースコードを公開し、ブロックチェーンエクスプローラーやユーザーがABIデータを確認できるようにしてください。コントラクトをアップグレードまたは再デプロイするたびに、フロントエンドのABIファイルを更新してください。完全なアプリケーションには完全なABIを使い、スクリプトで部分ABIを使う場合はその旨を明記してください。簡潔さより明確さが重要なユーザー向けコントラクトでは、混乱を招くオーバーロードを避けてください。機密性の高い関数には、明確なNatSpecコメントを付けてください。ローンチ前にデプロイスクリプト、フロントエンド、監視ツールでABIベースの呼び出しをテストしてください。アップグレード時には、プロキシと実装のABIの動作を慎重に確認してください。ABIの正確さを、本番環境のセキュリティとユーザー保護の一部として扱ってください。

ユーザー向けベストプラクティス

ABIでデコードされた情報を信用する前に、コントラクトアドレスが正しいか確認してください。コントラクトABIを確認する際は、検証済みのブロックチェーンエクスプローラーページや公式プロジェクト情報を利用してください。読みやすい関数名だからといって、トランザクションが安全だと思い込まないでください。署名する前に、トークン数量、spenderアドレス、受取人アドレス、期限、権限を確認してください。ウェブサイトから承認、転送、permit、ミント、請求、アップグレード関連の署名を求められた場合は注意してください。ABIはコントラクトとの操作方法を説明するものであり、コントラクトが誠実または安全かどうかを示すものではありません。コントラクトがアップグレード可能か、実装の更新後にABIが変わったかを確認してください。呼び出し内容を正確に理解していない限り、生のcalldataトランザクションへの署名は避けてください。トランザクションシミュレーションやウォレットの警告は参考情報として利用し、完全な保証とはみなさないでください。ABIでデコードされたトランザクションも、承認前に実際の金融上の指示として扱ってください。

FAQ

スマートコントラクトABIとはどういう意味ですか？

スマートコントラクトABIはApplication Binary Interfaceの略であり、スマートコントラクトの呼び出しをエンコードし、コントラクトの出力、ログ、エラーをデコードするための構造化インターフェースです。

ABIはスマートコントラクトのコードと同じですか？

いいえ。ABIは外部インターフェースを説明し、スマートコントラクトのコードはオンチェーンで実行される内部ロジックを定義します。

ウォレットにABIが必要なのはなぜですか？

ウォレットはABIデータを使ってトランザクションの呼び出しをデコードし、呼び出し対象のコントラクト関数をより読みやすくユーザーに表示します。

ABIはコントラクトが安全であることを証明しますか？

いいえ。ABIが説明するのはコントラクトとの操作方法だけであり、コントラクトのロジックが安全、監査済み、誠実であることを証明しません。

スマートコントラクトABIはどこから取得できますか？

スマートコントラクトABIは通常、コンパイラーの成果物、検証済みソースコード、コントラクトメタデータ、公式の開発者ファイル、ブロックチェーンエクスプローラーのデータベースなどから取得できます。

ABIにおけるcalldataとは何ですか？

Calldataとは、トランザクションまたは読み取り専用の呼び出しでスマートコントラクト関数に送信される、ABIでエンコードされた入力データです。

関数セレクターとは何ですか？

関数セレクターとは、どのスマートコントラクト関数を呼び出すか識別するcalldataの先頭4バイトです。

ABIが誤っていることはありますか？

あります。ABIが誤っていたり、古かったり、不完全だったり、別のコントラクトに対応していたりすると、呼び出しが失敗したり、デコード情報が誤解を招いたりする可能性があります。

ブロックチェーンエクスプローラーでABIが重要なのはなぜですか？

ブロックチェーンエクスプローラーはABIを使って、トランザクション入力データ、イベントログ、エラー、コントラクト操作パネルを読みやすい情報にデコードします。

アップグレード可能性はABIにどう影響しますか？

アップグレードによってコントラクトのロジックやユーザー向け関数が変わることがあるため、プロキシが新しい実装を参照する際にアプリケーション側で新しいABIが必要になる場合があります。

まとめ

スマートコントラクトABI（Application Binary Interface）は、エンコードされた関数呼び出し、戻り値データ、イベント、エラーを通じて、ソフトウェアがスマートコントラクトと通信するための標準インターフェースです。ウォレット、分散型アプリケーション、ブロックチェーンエクスプローラー、開発者のスクリプト、インデクサー、分析システム、コントラクト自動化に不可欠です。ABIは、人が読めるコントラクト関数を低レベルのcalldataに変換し、低レベルの戻り値データやログを読みやすい値に戻します。関数セレクター、型付きパラメーター、配列、タプル、イベント、カスタムエラー、コンストラクター、receive関数、fallback関数に対応します。スマートコントラクトABIは使いやすさ、透明性、開発者の生産性を高めますが、コントラクトの安全性を証明するものではありません。ユーザーはコントラクトアドレスを検証し、トランザクションの詳細を確認し、ソースコードの検証状況を確かめ、承認の内容を理解し、アップグレード可能なシステムに注意する必要があります。開発者は正確なABI成果物を公開し、デプロイとの同期を保ち、ソースコードを検証し、機密性の高い関数を文書化し、アップグレード後にABIデータを更新する必要があります。初心者にとって、スマートコントラクトABIは、アプリやウォレットがブロックチェーン上のコントラクトと通信するための読みやすいインターフェースと捉えると理解しやすいでしょう。上級ユーザーにとって、ABIはJSONインターフェース、セレクター、calldata、戻り値データ、ログ、エラー、プロキシ実装、開発者ツールをつなぐ厳密なエンコード・デコードのスキーマです。暗号資産用語としてのスマートコントラクトABIは、EVMベースのスマートコントラクトと安全かつ構造化された分かりやすい方法でやり取りするためのコントラクトインターフェース仕様を指します。重要なのは、ABIがユーザー、ソフトウェア、オンチェーンのバイトコードをつなぐ一方で、安全な暗号資産取引には、アドレスの検証、ソースコードの確認、ウォレット操作への注意、インターフェースデータと安全性は同じではないという理解が引き続き必要だという点です。