Solidity

Solidityとは？

Solidityは、EthereumおよびEthereum Virtual Machineをサポートするその他のブロックチェーンネットワーク上で実行されるスマートコントラクトを作成するための高水準プログラミング言語です。

公式のSolidityウェブサイトでは、Solidityを、Ethereum上で実行されるスマートコントラクトの開発向けに設計された、静的型付けの中括弧を使用するプログラミング言語と説明しています。

スマートコントラクトとは、ブロックチェーン上に保存されるプログラムです。従来のサーバーを必要とせずに、資産の保有、ルールの適用、ロジックの実行、トランザクションへの応答を行えます。

公式のEthereumスマートコントラクトのドキュメントでは、スマートコントラクトはEthereumブロックチェーン上で実行されるプログラムと説明されています。

暗号資産分野では、Solidityはトークン、DeFiプロトコル、NFTコレクション、DAO、ステーキングシステム、レンディング市場、ブリッジ、エスクローシステム、ガバナンスコントラクトなど、さまざまなオンチェーンアプリケーションの構築に使用されます。

Solidityコードを人間のユーザーが直接実行することはありません。

開発者はSolidityのソースコードを記述し、それをEthereum Virtual Machineが実行できるバイトコードへコンパイルします。

公式のSolidityドキュメントでは、Solidityをスマートコントラクト実装のためのオブジェクト指向高水準言語と説明しています。

簡単に言えば、Solidityは、EVMベースのブロックチェーンでプログラム可能な暗号資産アプリケーションを作る際に、多くの開発者が使用する主要なプログラミング言語です。

暗号資産においてSolidityが重要な理由

Solidityが重要なのは、暗号資産エコシステム全体でユーザーが利用する多くのスマートコントラクトを支えているためです。

ユーザーがトークンをスワップし、NFTをミントし、DAO投票に参加し、担保を預け入れ、報酬を請求し、DeFiアプリを利用する際、その処理の一部をSolidityスマートコントラクトが担っている場合があります。

Solidityにより、開発者は所有権、移転、権限、手数料、流動性、ガバナンスに関する再利用可能なルールを記述できるようになり、プログラム可能なデジタル資産の実用化に貢献しました。

代替可能トークンやNFTなどのトークンは、Solidityで一般的に実装されるスマートコントラクト標準に依存していることが多くあります。

公式のERC-20トークン標準は、スマートコントラクトにおける代替可能トークンの共通インターフェースを定義しています。

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

公式のERC-1155トークン標準は、1つのコントラクトシステムで代替可能資産と非代替可能資産をサポートできるマルチトークン標準を定義しています。

これらの標準は、ウォレット、エクスプローラー、アプリケーション、プロトコルが共通のトークン動作をより容易にサポートできるため重要です。

また、スマートコントラクトのエラーは実際のユーザー資金に影響する可能性があるため、Solidityは重要です。

Solidityコードの小さなミスでも、トークンの損失、権限の破綻、不正確な会計処理、アップグレードの失敗、悪用可能なDeFiロジックにつながる可能性があります。

Solidityの仕組み

Solidityでは、開発者が人間にとって読みやすいソースコードでスマートコントラクトのルールを記述します。

そのコードは、一般にsolcと呼ばれるSolidityコンパイラを通じてEVMバイトコードへコンパイルされます。

公式のSolidityコンパイラのドキュメントでは、コンパイラがバイナリ、ABIデータ、アセンブリ、ガス見積もり、抽象構文木などを出力できると説明されています。

コンパイル後、デプロイメント用バイトコードはブロックチェーントランザクションで送信され、コントラクトアカウントが作成されます。

デプロイ後、コントラクトにはユーザーや他のコントラクトが呼び出せるアドレスが割り当てられます。

通常、ユーザーが生のバイトコードを記述してスマートコントラクトを呼び出すことはありません。

通常は、コントラクトABIを使用して関数呼び出しをエンコードするウォレット、アプリ、スクリプト、インターフェースを通じて操作します。

コントラクトはトランザクションデータを受け取り、EVMルールに従って実行されます。許可されていればストレージを更新し、記述されていればイベントを発行し、データまたはエラーを返します。

状態を変更するすべての操作にはブロックチェーントランザクションと、送信者が支払う手数料が必要です。

そのため、Solidity開発では正確性とガスコストの両方を考慮する必要があります。

SolidityとEthereum Virtual Machine

Ethereum Virtual Machine（EVM）は、コンパイル済みスマートコントラクトのバイトコードを実行するランタイム環境です。

公式のSolidityのスマートコントラクト入門では、EVMはEthereumスマートコントラクトのランタイム環境であり、周囲のシステムから隔離されていると説明されています。

SolidityはEVMを対象として設計されているため、SolidityコードはEVMが理解できる命令へコンパイルされます。

この設計により、スマートコントラクトは多数のノードで決定論的に実行されます。

決定論的実行とは、同じチェーン状態のもとで同じトランザクションを処理した場合、すべての正直なノードが同じ結果に到達することを意味します。

ブロックチェーンでは、残高、所有権、コントラクトストレージ、トランザクション結果について合意する必要があるため、これは不可欠です。

EVMは、コントラクトが実行できる処理を制限するサンドボックス環境も提供します。

Solidityコントラクトは、トランザクションやオラクルシステムを通じて情報がオンチェーンにもたらされない限り、任意のウェブサイトを直接呼び出したり、非公開サーバーデータを読んだり、オフチェーン情報へアクセスしたりできません。

この制限は決定論性を高める一方で、開発者は外部データの要件を慎重に設計する必要があります。

したがってSolidityは、厳格なルールを持つブロックチェーンの実行モデル内で動作するため、通常のWebプログラミング言語とは異なります。

Solidityとスマートコントラクト

Solidityスマートコントラクトとは、デプロイ後にブロックチェーンアドレス上に存在するコードとストレージの集合です。

コードは、呼び出し可能な関数と各関数の動作を定義します。

ストレージには、残高、所有者アドレス、設定値、マッピング、投票、債務、準備金、トークンメタデータなどの長期的な状態が保存されます。

コントラクトは、ユーザーが管理する外部所有アカウントからトランザクションを受け取れます。

また他のコントラクトを呼び出すこともでき、これにより組み合わせ可能なオンチェーンシステムが生まれます。

コンポーザビリティは、あるプロトコルが別のプロトコルのコントラクトインターフェースを基盤にできるため、Solidityにおける最も重要な暗号資産機能の一つです。

トークンコントラクトは、レンディングプロトコル、スワッププロトコル、ステーキングコントラクト、ガバナンスシステムで利用できます。

これはSolidityを強力にする一方、1つのコントラクトのバグが接続された多数のアプリケーションに影響するリスクも生みます。

スマートコントラクトは検証後に通常は透明になりますが、透明性が自動的に安全性を意味するわけではありません。

ユーザーは、すべてのコントラクト操作を技術的および金融上のリスクを伴うトランザクションとして扱う必要があります。

Solidityの構文

Solidityでは、中括弧、関数宣言、変数、型、構造体、マッピング、イベント、モディファイア、継承パターンを使用します。JavaScript、C++、Javaなどを知る開発者には馴染み深く感じられる場合があります。

公式のSolidityドキュメントでは、この言語はC++、Python、JavaScriptの影響を受けているとされています。

Solidityファイルは通常、ライセンス識別子とpragma文で始まります。

pragma文は、そのソースファイルで想定されるコンパイラバージョンをツールに伝えます。

コントラクト定義には、状態変数、イベント、エラー、コンストラクタ、関数、モディファイア、ときにネストした型が含まれます。

Solidityは静的型付け言語であり、変数と関数パラメータには宣言された型があります。

一般的な型には、bool、uint256、int256、address、bytes、string、配列、構造体、列挙型、マッピングがあります。

開発者は、ストレージ、メモリ、calldata、可視性、可変性、アクセス制御を慎重に検討する必要があります。

Solidityコードは資産を制御し、デプロイ後の変更が難しくなる可能性があるため、これらの詳細は重要です。

一見単純な構文でも、複雑なオンチェーン動作を引き起こすことがあります。

コントラクト

コントラクトはSolidityの主要な構成要素です。

コントラクトはデータを保存し、関数を定義し、イベントを発行し、他のコントラクトを継承し、他のコントラクトとやり取りできます。

トークンコントラクトは残高と承認額を保存する場合があります。

レンディングコントラクトは、担保、債務、金利インデックス、強制決済設定を保存する場合があります。

ガバナンスコントラクトは、提案、投票、定足数ルール、実行遅延を保存する場合があります。

ステーキングコントラクトは、入金、報酬率、出金ルール、請求データを保存する場合があります。

デプロイされた各コントラクトには、ブロックチェーン上で固有のアドレスが付与されます。

ユーザーはそのアドレスを呼び出してコントラクトの関数を操作します。

コントラクトコードは、トランザクションまたは呼び出しによってトリガーされた場合にのみ実行されます。

コントラクトは通常のサーバーアプリケーションのように継続して実行されるものではありません。

状態変数

状態変数は、コントラクトストレージに永続的に保存される変数です。

トランザクションをまたいで利用可能である必要があるデータに使用されます。

例として、トークン残高、所有者アドレス、総供給量、手数料設定、プロトコル準備金、投票数、ユーザーのポジションがあります。

ブロックチェーンノードがこのデータを保持・検証する必要があるため、ストレージは高コストです。

開発者は不要なデータをオンチェーンに保存しないようにすべきです。

特にアップグレード可能なコントラクトでは、ストレージレイアウトも慎重に設計する必要があります。

ストレージレイアウトのミスは、アップグレード時に重要なコントラクト状態を破損させる可能性があります。

Solidityはコンパイラを通じてストレージレイアウト情報を出力でき、開発者や監査人によるアップグレードリスクの確認に役立ちます。

コントラクトが検証されているか、ブロックチェーンエクスプローラーが読み取り可能な呼び出しを公開していない限り、ユーザーが状態変数を直接見ることはほとんどありません。

しかし、これらの変数がユーザー資金や権限の扱いを決めていることは多くあります。

関数

関数は、Solidityコントラクトが実行できる操作を定義します。

関数はデータの読み取り、ストレージの更新、トークン送信、別のコントラクトの呼び出し、イベント発行、条件を満たさない場合のrevertを行えます。

関数の可視性は、誰が関数を呼び出せるか、どのようにアクセスできるかを制御します。

一般的な可視性キーワードには、public、external、internal、privateがあります。

関数の可変性は、関数が状態を読み取るか変更するかを示します。

一般的な可変性キーワードには、view、pure、payableがあります。

view関数は状態を変更せずに読み取れます。

pure関数は、コントラクト状態の読み取りや変更を行わないことが想定されています。

payable関数は、valueを伴って呼び出された場合にチェーンのネイティブ資産を受け取れます。

多くのスマートコントラクト脆弱性は、チェック不足、不適切な権限、安全でない外部呼び出し、不正確な会計処理に起因するため、関数設計は重要です。

イベント

イベントは、Solidityコントラクトが実行中に発行するログです。

ウォレット、エクスプローラー、インデクサー、アプリケーションがトランザクション内で起きたことを追跡するのに役立ちます。

一般的なトークン標準に従って実装されている場合、トークン送信では通常Transferイベントが発行されます。

DeFiプロトコルは、入金、出金、借入、返済、強制決済、スワップ、投票、設定変更のイベントを発行する場合があります。

イベントは、完全なコントラクトストレージより保存コストが低く、オフチェーンシステムでインデックス化しやすいため便利です。

ただし、イベントはコントラクト状態と同じではありません。

コントラクトは、コードでそう指示されている場合にのみイベントを発行できます。

アプリケーションは、コントラクトロジックを理解せずにイベントログを盲目的に信頼すべきではありません。

イベントは透明性と分析に優れていますが、基盤となるコードと併せて解釈する必要があります。

ユーザーにとって、イベントはウォレットやエクスプローラーに表示される読み取り可能なトランザクション履歴の基盤となることが多くあります。

モディファイア

モディファイアは、関数の動作を変更または制限できる再利用可能なSolidityロジックです。

一般的なモディファイアは、関数の実行を許可する前に、呼び出し元が所有者、管理者、ガバナー、または認可済みロールであるかを確認します。

モディファイアは重複コードを減らし、アクセス制御を読みやすくできます。

ただし、過度に使用されたり不明確に記述されたりすると、重要なロジックを隠すこともあります。

関数が単純に見えても、モディファイアがバックグラウンドで重要なチェックや状態変更を実行している場合があります。

開発者はモディファイアを明確かつ目的に絞って維持すべきです。

モディファイアは重要な関数を保護していることが多いため、監査人は慎重に確認すべきです。

検証済みコードを確認するユーザーは、関数の見えている本体だけで判断すべきではありません。

継承されたモディファイアやアクセス制御条件も確認する必要があります。

モディファイアの欠落または破損は、重大なセキュリティリスクを生む可能性があります。

マッピング

マッピングは、Solidityコントラクトで一般的に使用されるキーと値のデータ構造です。

トークン残高は、アドレスから金額へのマッピングに保存されることが多くあります。

承認額は、所有者から利用者、さらに金額へとつながるネストしたマッピングに保存できます。

ガバナンスシステムでは、あるアドレスが投票済みかを追跡するためにマッピングを使用する場合があります。

レンディングシステムでは、各ユーザーの担保と債務を追跡するためにマッピングを使用する場合があります。

マッピングはキーによる値の検索に効率的です。

ただし、マッピングをオンチェーンで直接反復処理することは容易ではありません。

開発者は、オフチェーンシステムでマッピング項目を一覧表示する必要がある場合、イベントや追加のデータ構造を使用することが多くあります。

マッピングは強力ですが、慎重な会計処理が必要です。

誤ったマッピング更新は、不正確な残高、権限の破綻、資金損失につながる可能性があります。

インターフェース

インターフェースは、別のコントラクトが呼び出せる関数シグネチャを定義します。

スマートコントラクトは他のスマートコントラクトとやり取りする必要があることが多いため、インターフェースは重要です。

トークンインターフェースは、DeFiコントラクトにtransfer、transferFrom、approve、balanceOf、allowanceの呼び出し方法を伝えられます。

オラクルインターフェースは、レンディングプロトコルに価格データの読み取り方法を伝えられます。

ガバナンスインターフェースは、別のコントラクトが提案状態や投票権を確認できるようにします。

インターフェースにより、コントラクトは共通の関数形に依存できるため、コンポーザビリティが向上します。

ただし、インターフェースは期待される呼び出しと戻り値を記述するだけです。

アドレスの背後にあるコントラクトが誠実または安全に動作することを証明するものではありません。

開発者は、外部コントラクトを統合する前に、その前提を検証すべきです。

ユーザーは、コントラクトのコンポーザビリティが接続されたシステム全体にリスクを広げる可能性があることを理解する必要があります。

ライブラリ

ライブラリは、一般的なロジックを繰り返し記述することを避けるための、再利用可能なSolidityコードユニットです。

ライブラリは、数学関数、アドレスユーティリティ、安全な送信ヘルパー、配列ツール、文字列ツール、データ構造操作を提供できます。

一部のライブラリはコンパイル時にコントラクトバイトコードへ組み込まれます。

他のライブラリは別途デプロイされ、アドレスによってリンクされます。

十分にテストされ、広くレビューされたライブラリを使用すれば、コード品質が向上する可能性があります。

一方、ライブラリが古い、悪意がある、不正にリンクされている、誤って使用されている場合は、リスクが追加される可能性があります。

開発者は依存関係のバージョンを固定し、インポートしたコードを確認すべきです。

監査人は、コードベース全体の一部としてライブラリを確認すべきです。

ユーザーは、検証済みコントラクトがインポートされたライブラリや継承コードに依存する場合があることを理解すべきです。

コントラクトの安全性は、その動作に影響するコード全体の安全性に依存します。

継承

継承により、Solidityコントラクトは他のコントラクトのコードを再利用し、拡張できます。

これは、共有の所有権ロジック、トークン動作、アクセス制御、一時停止制御、アップグレードパターン、再利用可能なモジュールに役立ちます。

継承は、慎重に使用すればコードを整理しやすくします。

一方で、多数の継承コントラクトが複雑に相互作用する場合、コードレビューを難しくすることがあります。

子コントラクトは親関数をオーバーライドする場合があります。

多重継承では、微妙な順序やオーバーライドの問題が生じる可能性があります。

開発者は可能な限り継承構造を単純に保つべきです。

監査人は最終コントラクトだけでなく、継承ツリー全体を確認すべきです。

検証済みコードを読むユーザーは、ページに表示されるコントラクト名だけでなく、インポートされた親コントラクトも確認すべきです。

継承は強力ですが、隠れた継承ロジックを無視すると危険になり得ます。

ABI

ABIはApplication Binary Interfaceの略です。

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

ABIは、ソフトウェアに関数呼び出しのエンコード方法と戻り値のデコード方法を伝えます。

ウォレット、スクリプト、アプリケーション、ブロックチェーンエクスプローラーは、ABIを使用して読み取り可能な関数名とパラメータ欄を表示します。

ABIがなければ、ユーザーは理解がはるかに難しい生のcalldataを扱う必要があります。

ABIには、関数、イベント、エラー、入力、出力、型情報を含めることができます。

ABIはコントラクトの安全性を証明するものではありません。

公開されたインターフェースを通じてコントラクトを呼び出す方法を記述するだけです。

悪意のあるコントラクトであっても、見た目が整ったABIを持つことがあります。

ユーザーはABIデータを信頼性の保証ではなく、使いやすさを高める層として扱うべきです。

Solidityコンパイラ

Solidityコンパイラ、すなわちsolcは、SolidityソースコードをEVMバイトコードおよび関連成果物へ変換します。

solcは、ABIデータ、メタデータ、ガス見積もり、ストレージレイアウト、警告、エラー、中間出力も生成できます。

コンパイラの正確なバージョンと設定は、最終的なバイトコードに影響するため重要です。

公式のSolidity 0.8.35リリース発表によると、バージョン0.8.35ではerc7201ビルトイン、トップレベルの実験的フラグ、実験的なSSA CFGコードジェネレーターが導入されました。

Solidityは新機能、バグ修正、警告、EVMターゲット変更によって時間とともに進化するため、コンパイラのバージョンは重要です。

あるバージョンでコンパイルしたコントラクトは、別のバージョンで同じソースコードをコンパイルした結果と一致しない場合があります。

オプティマイザーの有効状態、オプティマイザー実行回数、EVMバージョン、via-IR、ライブラリアドレスなどの設定も出力に影響します。

そのため、検証済みコントラクトでは通常、デプロイ済みバイトコードと一致させるために使用したコンパイラバージョンと設定が表示されます。

開発者は本番デプロイメントでコンパイラバージョンを固定すべきです。

ユーザーは、検証済みソースコードが単なるテキスト一致ではなく、コンパイル設定の一致にも依存することを理解すべきです。

バイトコード

バイトコードは、Solidityコントラクトのコンパイルとデプロイ後にEVMが実行する低水準コードです。

デプロイメント用バイトコードはコントラクトの作成に使用されます。

ランタイムバイトコードは、デプロイ後にコントラクトアドレスに残るコードです。

ブロックチェーンが実行するのは、元のSolidityソーステキストではなくバイトコードです。

このため、ソースコード検証は重要です。

検証では、表示されているソースコードとコンパイラ設定がデプロイ済みバイトコードを再現できることを示します。

公式のEthereumスマートコントラクト検証のドキュメントでは、検証はソースコードとコンパイル済みバイトコードを比較するものと説明されています。

大半のユーザーにとって、バイトコードを直接読むことは困難です。

検証済みソースコードは、バイトコードを理解しやすくします。

ただし、検証済みバイトコードであっても、ユーザーが資金をコントラクトに託す前にはセキュリティレビューが必要です。

ガス

ガスは、トランザクションおよびスマートコントラクト操作の実行に必要な計算作業を測定する単位です。

高コストなコードはコントラクトの利用を高価または非現実的にする可能性があるため、Solidity開発者はガスを考慮する必要があります。

ストレージへの書き込みは、通常、メモリやcalldataの読み取りよりもコストが高くなります。

大規模なデータセットに対するループは、過剰なガスを必要とする場合に危険になり得ます。

外部呼び出しはコストとセキュリティリスクを追加する可能性があります。

コントラクトのデプロイにも、バイトコードをオンチェーンに保存するためのガスが必要です。

Solidityオプティマイザーはガスコストやバイトコードサイズを削減できる場合がありますが、慎重な設定とテストが必要です。

ガス最適化によって、ロジックの明確性や安全性が損なわれるべきではありません。

利用コストが高すぎるコントラクトは、ネットワーク混雑時にユーザーの操作を失敗させる可能性があります。

優れたSolidity開発では、安全性、明確性、効率性のバランスを取ります。

Solidityとトークン

Solidityは、トークンコントラクトの作成と管理に広く使用されています。

代替可能トークンのコントラクトは、残高、承認額、総供給量、送信、承認、ミント、バーン、アクセス制御を追跡できます。

NFTコントラクトは、固有のトークンID、所有者、承認、メタデータリンク、送信ルールを追跡できます。

マルチトークンコントラクトは、1つのコントラクトシステム内で多数のトークンタイプを管理できます。

トークン標準は、ウォレット、エクスプローラー、アプリケーションがトークンをサポートしやすくするため重要です。

ERC-20、ERC-721、ERC-1155は、Ethereumエコシステムにおける最も重要なアプリケーションレベルのトークン標準の一部です。

ただし、トークンがSolidityで書かれていること、または標準に従っていることは、その安全性や価値を保証しません。

トークンコントラクトには、ミント権限、ブラックリストロジック、手数料、一時停止制御、アップグレード可能性、危険な管理者権限が含まれる場合があります。

ユーザーは、トークンを信頼する前に、トークン権限、保有者分布、流動性、供給ルール、検証済みソースコードを確認すべきです。

Solidityはトークン作成を可能にしますが、トークンの品質は設計とガバナンスに依存します。

SolidityとDeFi

Solidityは、多くの分散型金融（DeFi）アプリケーションの中核です。

DeFiコントラクトは、スワップ、流動性プール、レンディング市場、ボールト、デリバティブ、ステーキング、イールド戦略、ガバナンスシステムを管理できます。

これらのシステムは大量のユーザー資産を保有する場合が多く、Solidityのセキュリティは極めて重要です。

DeFiプロトコルは、コーディングバグ、オラクルの問題、不適切な会計モデル、欠陥のある強制決済ルール、安全でないアップグレード、ガバナンス攻撃によって失敗する可能性があります。

Solidityではコントラクト同士が呼び出し可能であるため、DeFiは高いコンポーザビリティを持ちます。

コンポーザビリティは有用な金融上の構成要素を生み出すことがあります。

一方で、あるプロトコルが別のプロトコルの動作に依存する場合、依存関係リスクも生じます。

開発者は多様な市場状況と失敗シナリオのもとで統合をテストすべきです。

ユーザーは、DeFiスマートコントラクトが透明であると同時にリスクを伴う場合があることを理解すべきです。

高い利回りや高い取引高は、Solidityコードの安全性を証明しません。

SolidityとNFT

Solidityは、固有のデジタル資産に関する所有権および送信ルールを定義するNFTコントラクトの作成に一般的に使用されます。

NFTスマートコントラクトは、トークンIDの割り当て、所有権記録の保存、承認の管理、メタデータへのリンクを行えます。

NFTメタデータは、画像、属性、説明、外部ファイルを指すことが多くあります。

大きなデータをオンチェーンに保存すると高コストになるため、スマートコントラクトがすべてのメディアを直接オンチェーンに保存するとは限りません。

ユーザーは、NFTメタデータがオンチェーンか、分散化されているか、変更可能か、プロジェクト権限者に管理されているかを確認すべきです。

検証済みのSolidity NFTコントラクトでは、ミントルール、供給上限、ロイヤルティ動作、送信制限、管理者権限を確認できます。

ただし、NFTに関する多くのリスクはコードリスクだけではありません。

NFTのリスクには、偽コレクション、盗用アート、流動性の低さ、破損したメタデータ、誤解を招く約束、マーケットプレイス操作も含まれます。

Solidityは所有権ロジックを提供しますが、文化的価値や将来の需要を保証するものではありません。

NFT購入者は、コントラクトレビューに加え、コレクション検証と流動性分析を行うべきです。

SolidityとDAO

Solidityは、DAOのガバナンスコントラクト構築によく使用されます。

DAOコントラクトは、提案、投票権、委任、タイムロック、トレジャリー実行、ロール権限を管理する場合があります。

ガバナンスコントラクトは、トークン保有者またはメンバーがプロトコル変更に投票できるようにします。

また、アップグレード、トレジャリー送金、パラメータ変更、緊急一時停止などの重要な操作を制御する場合もあります。

ガバナンス攻撃は実際の資産に影響する可能性があるため、DAOコントラクトには慎重な設計が必要です。

設計が不十分な投票システムは、低投票率、票の買収、フラッシュローン投票、大口保有者による支配、性急な実行に対して脆弱となる可能性があります。

タイムロックにより、承認された変更が有効になる前にユーザーが対応する時間を確保できます。

緊急制御は被害を抑えられる場合がありますが、中央集権的な権限を導入することにもなります。

SolidityはDAOにプログラム可能なガバナンスツールを提供しますが、ガバナンスの安全性はコードと人間の協調の両方に依存します。

ユーザーは、誰がプロトコルを変更できるか、どの程度迅速に変更できるかを確認すべきです。

Solidityのセキュリティリスク

Solidityのセキュリティは、暗号資産開発における最も重要なテーマの一つです。

公式のSolidityセキュリティに関する考慮事項では、リエントランシー、ガス制限、etherの送受信、tx.origin、細かな注意点、コンパイラ関連の問題などのリスクを扱っています。

リエントランシーは、コントラクトが自身の状態を安全に更新する前に外部コントラクトを呼び出した場合に発生する可能性があります。

アクセス制御のバグにより、認可されていないユーザーが重要な関数を呼び出せる可能性があります。

整数計算や会計処理のミスは、不正確な残高や壊れた手数料ロジックを生む可能性があります。

オラクルのミスは、不正確な価格や不公平な強制決済を招く可能性があります。

アップグレードのミスは、安全なロジックを安全でないロジックに置き換える可能性があります。

未確認の外部呼び出しは、想定外の実行経路を生む可能性があります。

署名検証のミスにより、リプレイ攻撃や偽の承認が可能になる場合があります。

スマートコントラクトのセキュリティには、脅威モデリング、テスト、レビュー、監査、監視、保守的な設計が必要です。

リエントランシー

リエントランシーは、外部呼び出しにより、最初のコントラクトが状態の更新を終える前に別のコントラクトが再び呼び出せるようになる、よく知られたスマートコントラクト脆弱性です。

これにより、繰り返しの出金、会計処理の破綻、想定外の制御フローが発生する可能性があります。

Solidityのセキュリティドキュメントでは、リエントランシーリスクを軽減する方法の一つとしてChecks-Effects-Interactionsパターンを推奨しています。

このパターンでは、コントラクトは最初に条件を確認し、次に内部状態を更新し、最後に外部コントラクトとやり取りします。

リエントランシー対策には、ロック、プルペイメント設計、外部呼び出しの慎重なレビューも含められます。

開発者は、資産の送信が無害であると考えるべきではありません。

外部呼び出しはコードを実行し、制御フローを変更する場合があります。

ユーザーは、未監査の出金ロジックや複雑なコールバック経路を持つプロトコルに注意すべきです。

リエントランシーは唯一のSolidityリスクではありませんが、スマートコントラクトロジックが通常のソフトウェアと異なる理由を示す最も重要な例の一つです。

状態更新が不適切な順序で行われると、安全に見える送信でも危険になる可能性があります。

アクセス制御

アクセス制御は、誰が重要なSolidity関数を呼び出せるかを決定します。

重要な関数には、トークンのミント、送信の一時停止、コントラクトのアップグレード、手数料変更、オラクル設定、トレジャリー資金の出金、ロール付与などがあります。

アクセス制御は、所有者アドレス、ロール、マルチシグウォレット、ガバナンスコントラクト、タイムロック、独自の権限システムに基づく場合があります。

弱いアクセス制御により、攻撃者や内部者がコントラクトの動作を変更できる可能性があります。

過度に中央集権化されたアクセス制御も、ユーザーにとって信頼リスクを生む可能性があります。

1つの秘密鍵で資金を流出させたり、ルールを即座に変更したりできる場合、コントラクトは技術的に動作していても安全でない可能性があります。

開発者は、最小権限、明確なロール分離、復旧計画に基づいて権限を設計すべきです。

ユーザーは、プロトコルへ資金を預け入れる前に管理者権限を確認すべきです。

ソースコードが利用可能であれば、検証済みのSolidityコードから権限ロジックを確認できます。

コーディングバグがなくても、管理者リスクはスマートコントラクトリスクです。

整数の安全性

コントラクトは残高、シェア、価格、手数料、金利、報酬を扱うことが多いため、整数演算はSolidityで重要です。

古いSolidityバージョンでは、整数オーバーフローとアンダーフローに関してより多くの手動対応が必要でした。

Solidity 0.8.xでは、uncheckedブロックが使用されない限り、大半のオーバーフローおよびアンダーフロー条件でrevertするチェック付き演算がデフォルトで導入されました。

この安全性の向上によって、すべての数学的リスクが解消されるわけではありません。

開発者は、丸め、精度、スケーリング係数、小数点の違い、手数料の順序、シェア会計で依然としてミスをする可能性があります。

uncheckedブロックは特定の場合にガス効率を高められますが、慎重に使用する必要があります。

DeFiコントラクトでは固定小数点演算やトークンの小数桁を使用することが多く、微妙なエラーを生む可能性があります。

監査人は数学上の前提とエッジケースを確認すべきです。

ユーザーは、安全な演算が自動的に安全な経済設計を意味するわけではないことを理解すべきです。

正しい数式は、オーバーフロー対策と同様に重要です。

オラクルと外部データ

Solidityコントラクトは、それ自体でオフチェーンデータに直接アクセスできません。

公式のEthereumオラクルのドキュメントでは、オラクルが外部世界のデータをスマートコントラクトに提供すると説明されています。

オラクルは、価格、ランダム性、証明データ、天候データ、スポーツデータ、本人確認情報、その他のオフチェーン入力を提供できます。

DeFiでは、価格オラクルが担保価値、強制決済、ミント、償還、決済を決定する場合があるため、特に重要です。

Solidityコードが正しく書かれていても、不適切なオラクル設計は大きな損失を招く可能性があります。

開発者は、流動性の薄い市場で容易に操作できる現物価格への依存を避けるべきです。

更新頻度、フォールバック動作、データ遅延、サーキットブレーカーも考慮すべきです。

ユーザーは、担保を預け入れたり資産を借り入れたりする前に、プロトコルが使用するオラクルソースを確認すべきです。

Solidityはオラクルベースのルールを適用できますが、不適切なデータを適切なデータに変えることはできません。

外部データは、多くのスマートコントラクトシステムにおける最大の信頼前提の一つです。

アップグレード可能性

Solidityコントラクトは不変と説明されることが多い一方、多くのプロジェクトはデプロイ後にロジックを変更するためアップグレードパターンを使用しています。

アップグレード可能なコントラクトでは通常、プロキシコントラクトと実装コントラクトを分離します。

プロキシはアドレスとストレージを保持し、実装にはアップグレード関数を通じて置き換え可能なロジックが含まれます。

アップグレード可能性はバグ修正や機能追加を可能にします。

一方で、ユーザーが資金を預け入れた後に管理者またはガバナンスがルールを変更できるため、信頼リスクも生みます。

不適切なアップグレードは状態を破損する可能性があるため、ストレージレイアウトは慎重に扱う必要があります。

ユーザーは、コントラクトがアップグレード可能か、誰がアップグレードを管理するか、タイムロックがあるか、アップグレードが公開発表されるかを確認すべきです。

開発者はアップグレード権限を明確に文書化すべきです。

監査人は、現在の実装とアップグレード制御の両方を確認すべきです。

アップグレード可能性は有用ですが、Solidityコントラクトの信頼モデルを変化させます。

ソースコード検証

ソースコード検証は、公開されたSolidityソースコードがデプロイ済みバイトコードと一致することをユーザーが確認するのに役立ちます。

Ethereumの検証ドキュメントでは、検証はコントラクトソースコードと、コントラクト作成時に使用されたコンパイル済みバイトコードを比較すると説明されています。

検証には通常、正確なソースファイル、コンパイラバージョン、コンパイラ設定、コンストラクタ引数、ライブラリアドレス、メタデータ設定が必要です。

検証済みソースコードは、ユーザーがコントラクトの背後にあるロジックを読めるため、透明性を高めます。

また、ウォレットやエクスプローラーが関数呼び出しとイベントをデコードするのにも役立ちます。

ただし、ソースコード検証は監査と同じではありません。

検証済みコントラクトにも、バグ、安全でない管理者制御、アップグレードリスク、不適切な経済設計が含まれる可能性があります。

未検証コントラクトは、人間が読めるコードとデプロイ済みバイトコードを容易に比較できないため、信頼しにくくなります。

ウェブサイトが未検証コントラクトへの承認や入金を求める場合、ユーザーは注意すべきです。

検証はデューデリジェンスの出発点であり、終点ではありません。

Solidityのバージョン

Solidityのバージョンは、言語が時間とともに変化するため重要です。

新しいバージョンでは、機能の導入、警告の改善、デフォルト設定の変更、コンパイラバグの修正、新しいEVM動作のサポートが行われる場合があります。

公式のSolidityリリース発表では、コンパイラのリリースと言語変更の詳細が公開されています。

2026年時点で利用可能な公式リリース情報によると、Solidity 0.8.35は新機能および実験的なコンパイラ機能を備えた最近のコンパイラリリースです。

本番プロジェクトでは、コンパイラバージョンを安易にアップグレードすべきではありません。

バイトコード、ガス動作、警告、ビルド出力が変わる可能性があるため、すべてのコンパイラアップグレードはテストすべきです。

開発者はコンパイラバージョンを変更する前にリリースノートを読むべきです。

監査人は、監査対象ビルドで使用されたコンパイラバージョンを確認すべきです。

検証済みコントラクトを確認するユーザーは、エクスプローラーに表示されるコンパイラバージョンを確認すべきです。

Solidityバージョンの選択は、スマートコントラクトの安全性と再現性の一部です。

Solidityコンパイラのバグ

コンパイラはソースコードを実際にオンチェーンで実行されるバイトコードに変換するため、コンパイラのバグはまれでも重要です。

公式のSolidity既知のバグに関するドキュメントでは、既知のコンパイラバグと影響を受けるバージョンが追跡されています。

ソースコードが正しく見えても、コンパイラの問題の影響を受けるコントラクトがあります。

開発者は本番コントラクトをデプロイする前に、既知のコンパイラバグを確認すべきです。

監査人はコンパイラバージョンの確認をプロセスに含めるべきです。

明確な理由なく非常に古いコンパイラバージョンを使用するコントラクトには、ユーザーは注意すべきです。

古いコンパイラバージョンがすべて自動的に安全でないわけではありませんが、新しいチェックや修正が欠けている可能性があります。

スマートコントラクトチームは、コンパイラを信頼するソフトウェアサプライチェーンの一部として扱うべきです。

再現可能なビルドと記録されたコンパイラ設定は、既知のバグが適用される可能性の確認に役立ちます。

コンパイラリスクは、デプロイメント成果物を保存すべきもう一つの理由です。

Solidity開発ツール

Solidity開発者は通常、コントラクトの記述、コンパイル、テスト、デプロイ、検証、監視のためにツールを使用します。

公式のRemix IDEは、Solidityコントラクトの学習、記述、コンパイル、テストに広く使用されるブラウザベースの環境です。

コマンドラインフレームワークとローカル開発環境では、コンパイル、テスト、デプロイ、フォークテスト、検証を自動化できます。

静的解析ツールは、Solidityコードをスキャンして一般的な脆弱性や危険なパターンを検出できます。

ファジングテストツールは、多数の入力を生成して予期しない動作を見つけられます。

形式検証ツールは、定義された前提のもとで選択した特性を証明できます。

単一のツールで安全性を保証することはできません。

専門的なSolidity開発では通常、ユニットテスト、統合テスト、ファズテスト、コードレビュー、監査、デプロイスクリプト、監視、インシデント対応計画を組み合わせます。

初心者は、実際の資金を扱う前に小規模なコントラクトとテストネットから始めるべきです。

高度なチームは、再現可能なビルドパイプラインと厳格なリリース制御を使用すべきです。

Solidityコントラクトのテスト

デプロイ済みスマートコントラクトは価値ある資産を制御する可能性があるため、テストは不可欠です。

ユニットテストでは、個別の関数と期待される動作を確認します。

統合テストでは、複数のコントラクトがどのように連携するかを確認します。

フォークテストでは、実際のチェーン状態をローカル環境にコピーし、その状態に対するコントラクト動作をシミュレートします。

ファズテストでは、多数のランダムまたは構造化された入力を試し、エッジケースを見つけます。

不変条件テストでは、多数の操作を通じて重要なルールが真であり続けることを確認します。

テストには、通常のフロー、失敗フロー、権限確認、エッジケース、悪意あるユーザーのシナリオを含めるべきです。

開発者は、現実的なトークンの小数桁、通常と異なるトークン動作、高額値、ゼロ値、境界条件でテストすべきです。

テストはすべての可能な動作の安全性を証明できませんが、防止可能なミスを大幅に減らします。

テストされていないSolidityコードに重要な資金を託すべきではありません。

監査

スマートコントラクト監査とは、専門家がSolidityコード、アーキテクチャ、権限、テスト、リスク前提を確認するセキュリティレビューです。

監査では、バグ、設計上の欠陥、アクセス制御の問題、経済的リスク、アップグレードの問題、文書化の不足を見つけられる場合があります。

監査はコントラクトの安全性を保証するものではありません。

監査はリスク削減プロセスであり、完全な防御策ではありません。

監査の品質は、対象範囲、期間、監査人の技能、テストカバレッジ、文書、チームによる指摘事項の修正方法に依存します。

ユーザーは、監査での指摘事項が解決済みか、受容済みかを確認すべきです。

また、デプロイ済みコントラクトが監査対象のコミットとコンパイラ設定に一致するかも確認すべきです。

プロジェクトは監査を受けていても、その後に未監査のアップグレードをデプロイする可能性があります。

監査は、公開検証、バグバウンティ、監視、保守的なローンチ上限と組み合わせることで最も有用になります。

大きな価値を管理するSolidityコントラクトは、メインネットへのデプロイ前に真剣なレビューを受けるべきです。

Solidityとウォレット操作

ウォレットは、Solidityコントラクトを呼び出すトランザクションにユーザーが署名するのを支援します。

ウォレットには、コントラクトアドレス、関数名、パラメータ、資産承認、ガス代、警告メッセージが表示される場合があります。

ウォレットがコントラクトの安全性を常に把握できるとは限りません。

一部の悪意あるウェブサイトは、実在するSolidity関数を有害な形で呼び出す危険なトランザクションへの署名をユーザーに求める可能性があります。

トークン承認は、設定された金額までコントラクトがウォレットからトークンを使用できるようにするため、特に重要です。

ユーザーは署名前に承認額とコントラクトアドレスを確認すべきです。

理解できないトランザクションには署名しないようにすべきです。

インターフェースがcalldataを隠している場合や、無制限の承認を求める場合は注意すべきです。

Solidityはプログラム可能な操作を可能にしますが、ウォレットからの署名は依然としてユーザーが管理します。

トランザクション署名は、資金を恒久的に移動させたり、権限を付与したりする可能性があります。

Solidityとトークン承認

トークン承認は、あるアドレスが別のアドレスに代わってトークンを使用できるようにする一般的なSolidityパターンです。

ERC-20形式のトークンでは、approveが承認額を設定し、transferFromがその承認額を使用します。

この設計により、DeFiスワップ、入金、支払い、自動化された操作が可能になります。

一方で、悪意ある、または侵害された利用者は、承認上限の範囲内でトークンを移動できるため、リスクも生まれます。

無制限承認は便利ですが、エクスポージャーを高めます。

ユーザーは、実用的な場合、必要な分だけ承認すべきです。

信頼できるウォレットまたはセキュリティツールを通じて、未使用の承認を取り消すべきです。

開発者は承認内容を明確に説明するインターフェースを設計すべきです。

監査人は、承認額の処理について、競合状態、チェック不足、安全でない前提を確認すべきです。

承認は、一般ユーザーがSolidityリスクと関わる最も一般的な方法の一つです。

Solidityと形式検証

形式検証は、定義された前提のもとで、選択したコントラクト特性が成立することを証明する数学的手法です。

これは、高額なシステム、金融プロトコル、ブリッジ、ガバナンスモジュール、主要な会計ロジックに有用な場合があります。

例えば、総供給量が上限を超えないことや、ユーザーが残高を超えて出金できないことを特性として定義できます。

形式検証によってテストや監査の必要性がなくなるわけではありません。

実際に指定された特性だけを証明します。

仕様が不完全または誤っている場合、証明は現実世界のリスクを見逃す可能性があります。

形式手法には高いコストがかかる場合があり、専門知識も必要です。

明確なルールを持つ重要なロジックに適用した場合に最も強力です。

Solidityにおいて、形式検証は成熟したセキュリティプロセスの一部です。

コントラクトの失敗が大きな損失を生む可能性がある場合に、特に有用です。

Solidityの利点

Solidityの第1の利点は、エコシステムで広く採用されていることです。

多くのスマートコントラクトツール、チュートリアル、監査、標準、ライブラリ、開発者コミュニティがSolidityをサポートしています。

第2の利点は、EVM互換性です。

ネットワークルールとデプロイ設定に互換性がある場合、SolidityコントラクトはEthereumおよびその他のEVM対応環境を対象にできます。

第3の利点は、コンポーザビリティです。

Solidityコントラクトは他のコントラクトを呼び出し、既存のトークン標準やプロトコルインターフェースを基盤にできます。

第4の利点は、表現力です。

開発者は、トークン、DeFiシステム、DAO、ゲーム、NFT、自動化された金融ロジックを構築できます。

第5の利点は透明性です。検証済みのSolidityソースコードは、ユーザーや監査人が読んで確認できます。

これらの利点により、Solidityは暗号資産における最も重要なスマートコントラクト言語の一つであり続けています。

Solidityのリスクと制限

第1のリスクは、バグが高コストになり、デプロイ後の修正が困難な場合があることです。

第2のリスクは、弱点を発見したあらゆるユーザーがスマートコントラクトロジックを悪用できることです。

第3のリスクは、Solidityコントラクトが他のコントラクトとやり取りすることが多く、依存関係リスクを生むことです。

第4のリスクは、ガスコストにより一部の設計が非現実的になる可能性があることです。

第5のリスクは、アップグレード可能性により管理者またはガバナンスの信頼リスクが生じる可能性があることです。

第6のリスクは、検証済みソースコードであっても悪意がある、または設計不良である可能性があることです。

第7のリスクは、開発者がEVM動作、ストレージレイアウト、リエントランシー、外部呼び出しを誤解する可能性があることです。

第8のリスクは、ユーザーがSolidityコントラクトの動作を理解せずに有害なトランザクションへ署名する可能性があることです。

第9のリスクは、構文が正しくても、オラクルおよび経済設計の問題によりプロトコルが破綻する可能性があることです。

第10のリスクは、コンパイラ設定と依存関係バージョンが最終的にデプロイされるバイトコードを変える可能性があることです。

Solidityにおける一般的なミス

一般的なミスの一つは、重要な関数を保護しないアクセス制御を記述することです。

別のミスは、内部状態を安全に更新する前に外部呼び出しを行うことです。

3つ目のミスは、Solidityのセキュリティドキュメントで警告されている、認可目的でtx.originを信頼することです。

4つ目のミスは、計算におけるトークンの小数桁と精度の問題を無視することです。

5つ目のミスは、すべてのERC-20形式トークンが完全に同じ動作をすると仮定することです。

6つ目のミスは、ストレージレイアウトを維持せずにアップグレード可能なコントラクトを使用することです。

7つ目のミスは、監査対象ビルドとは異なるコンパイラ設定でデプロイすることです。

8つ目のミスは、コンパイラ警告を無視することです。

9つ目のミスは、1つの管理者キーに過剰な権限を与えることです。

10つ目のミスは、エッジケースと失敗シナリオをテストする前にコントラクトをローンチすることです。

Solidityコントラクトの評価方法

まず、コントラクトのソースコードが検証されているかを確認します。

次に、コンパイラバージョン、オプティマイザー設定、コンストラクタ引数、リンク済みライブラリを確認します。

コントラクトがアップグレード可能か、誰がアップグレードを管理するかを確認します。

管理者ロール、所有者権限、マルチシグ制御、タイムロック、緊急機能を確認します。

トークンコントラクトを評価する場合は、トークンのミント、バーン、一時停止、ブラックリスト、手数料、送信制限を確認します。

DeFiコントラクトを評価する場合は、オラクルソース、担保ルール、強制決済ロジック、会計処理を確認します。

監査があるか、監査の指摘事項が修正されたかを確認します。

デプロイ済みコントラクトアドレスを、公式プロジェクトの情報源と比較します。

最近のトランザクションとイベントを確認し、コントラクトがどのように利用されているかを把握します。

Solidityコントラクトは、コード、インフラ、ガバナンス、経済設計を総合して評価すべきです。

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

リリースノートを読み、動作をテストしたうえで、最近の安定版Solidityコンパイラを使用してください。

本番ビルドではコンパイラバージョンと依存関係バージョンを固定してください。

コンパイラ警告は無害なノイズではなく、レビュー項目として扱ってください。

明確なアクセス制御と最小権限の権限設定を使用してください。

該当する場合は、Checks-Effects-Interactionsなどの安全な外部呼び出しパターンに従ってください。

通常の経路、失敗経路、エッジケース、悪意あるユーザーの動作についてテストを記述してください。

重要な価値を管理するコントラクトには、静的解析、ファズテスト、監査を使用してください。

管理者権限、アップグレード権限、オラクルの前提、緊急制御を文書化してください。

デプロイ後、正確なコンパイラ設定を使用してソースコードを検証してください。

デプロイ済みコントラクトを監視し、ローンチ前にインシデント対応計画を準備してください。

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

コントラクトを操作する前に、検証済みかどうかを確認してください。

ランダムなメッセージのリンクを信頼するのではなく、コントラクトアドレスを公式プロジェクトの情報源と比較してください。

トランザクションに署名する前に、トークン承認を確認してください。

無制限承認には注意し、実用的な場合は不要な権限を取り消してください。

コントラクトがアップグレード可能か、誰がアップグレードを管理するかを確認してください。

検証済みコントラクトであることを、監査済みまたは安全であることとみなさないでください。

理解できない、または独自に信頼できないコントラクトに資金を預け入れないでください。

高額な操作には、ハードウェアウォレットまたは強力なウォレットセキュリティを使用してください。

新規、未監査、高利回り、または匿名のSolidityコントラクトには注意してください。

ブロックチェーントランザクションは、一度承認されると通常は取り消せないことを覚えておいてください。

FAQ

Solidityは何に使われますか？

Solidityは、Ethereumおよびその他のEVM互換ブロックチェーン環境向けのスマートコントラクトを記述するために使用されます。

Solidityは暗号資産ですか？

いいえ。Solidityはプログラミング言語であり、暗号資産やトークンではありません。

SolidityはEthereum専用ですか？

SolidityはEthereum向けに設計されましたが、Ethereum Virtual Machineまたは互換実行環境をサポートする他のブロックチェーンネットワークでも使用されています。

Solidityスマートコントラクトとは何ですか？

Solidityスマートコントラクトは、データの保存、トランザクション処理、資産管理、ユーザーまたは他のコントラクトとのやり取りに関するルールを定義するブロックチェーンコードです。

Solidityコンパイラとは何ですか？

solcと呼ばれるSolidityコンパイラは、SolidityソースコードをEVMバイトコード、ABIデータ、メタデータ、その他のビルド出力に変換します。

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

ABIはApplication Binary Interfaceであり、ウォレット、アプリ、スクリプトにコントラクト関数の呼び出し方法と応答のデコード方法を伝えます。

Solidityは安全ですか？

Solidityは安全に使用できますが、スマートコントラクトの安全性は、安全な設計、テスト、監査、コンパイラ設定、アクセス制御、慎重なデプロイに依存します。

Solidityコントラクトはデプロイ後に変更できますか？

基本的なデプロイ済みコントラクトは通常不変ですが、アップグレード権限が存在する場合、アップグレード可能なプロキシパターンによりコントラクトロジックを変更できる可能性があります。

Solidityコントラクトに監査が必要な理由は何ですか？

Solidityコントラクトは価値ある資産を制御することが多いため、監査はデプロイ前後にバグ、権限の問題、経済上の欠陥、安全でない前提を見つけるのに役立ちます。

ユーザーはSolidityコントラクトをどのように確認できますか？

ユーザーは、ソースコード検証、コンパイラ設定、コントラクトアドレス、監査、管理者権限、アップグレード可能性、トークン承認、トランザクション履歴、公式プロジェクトドキュメントを確認できます。

結論

Solidityは、トークン、DeFi、NFT、DAO、ステーキングシステム、その他多数のオンチェーンアプリケーション向けスマートコントラクトを可能にするため、暗号資産エコシステムにおける最も重要なプログラミング言語の一つです。

開発者は人間に読みやすいルールを記述し、それをEVMバイトコードにコンパイルしてブロックチェーンノードに実行させます。

Solidityの強みは、大きなエコシステム、スマートコントラクト標準、コンポーザビリティ、ツール群、幅広いEVMサポートにあります。

そのリスクは、デプロイ済みコードが実際の資産を制御でき、デプロイ後の修正が難しい可能性がある点にあります。

優れたSolidity開発には、慎重なコンパイラ設定、テスト、監査、アクセス制御、アップグレード計画、ガスへの配慮、セキュリティレビューが必要です。

Solidityを適切に利用するには、ユーザーがコントラクトアドレスを検証し、権限を読み、承認を管理し、監査を確認し、未知または未検証のコントラクトを避ける必要があります。

初心者にとってSolidityは、開発者がブロックチェーンプログラムを記述するために使用する言語として理解するのが最適です。

上級ユーザーにとってSolidityは、その安全性がコード品質、EVM動作、コンパイラ設定、外部依存関係、ガバナンス、経済設計に依存するスマートコントラクト言語です。

暗号資産用語集の文脈では、Solidityは、Ethereum型ブロックチェーン環境で実行されるスマートコントラクトの構築とデプロイに使用される主要な高水準言語を意味します。

重要なポイントは、Solidityはプログラム可能な暗号資産を可能にする一方で、すべてのSolidityコントラクトを、検証、セキュリティレビュー、慎重なユーザー判断を必要とする高リスクなソフトウェアとして扱うべきだということです。