ポリシー、手続き、コード管理のテスト (Testing Policies, Procedures, and Code Management)
説明
ポリシー、手順、コード管理は、スマートコントラクトのセキュリティ、保守性、スケーラビリティを確保する上で極めて重要な役割を果たします。セキュアコーディングスタンダード、徹底したコードレビュー、一貫性のある文書化といった適切な開発プラクティスは、脆弱性を防ぎ、円滑な開発ワークフローを確保するために不可欠です。これらのプラクティスがなければ、スマートコントラクトは管理が困難になったり、エラーが発生しやすくなったり、セキュリティ上の悪用に脆弱になるかもしれません。
このセクションでは、脆弱性を軽減し、コードベースの品質を向上するための、セキュアコーディングスタンダード、コードレビュープロセス、コードの明確化、包括的テストに関するベストプラクティスを説明します。
例: 冗長コードやデッドコード
// Example: Code with redundant, duplicated, or dead code
function transfer(address recipient, uint256 amount) public {
// Redundant code: balance is checked twice
require(balanceOf[msg.sender] >= amount, "Insufficient balance");
balanceOf[msg.sender] -= amount;
balanceOf[recipient] += amount;
// Dead code: This line will never be reached
if (amount == 0) {
revert("Cannot transfer zero amount");
}
emit Transfer(msg.sender, recipient, amount);
}上記の例では、最初の require ステートメントで送金者が送金に必要な残高を有することを確認しているため、amount == 0 のチェックは不要です。また、amount == 0 の場合、require チェックによってトランザクションが元に戻る (revert) ため、二つ目のチェックは不要になります。さらに、前の revert のため、revert("Cannot transfer zero amount") が実行されることはありません。
影響
コードの冗長性: 冗長なチェックやロジックは不要な計算とガスコストの増加につながります。また、コントラクトの意図した動作に関する混乱を招き、保守や監査を困難にする可能性があります。
デッドコード: 到達不能なコードや不要なコードはコントラクトを肥大化し、より複雑化し、エラーや脆弱性のリスクを高めます。また、未使用のコードも全体の実行コストに寄与するため、コントラクト実行時にガスの無駄につながる可能性もあります。
セキュリティリスク: 冗長コードやデッドコードは実際の脆弱性を隠し、監査プロセスを複雑にし、攻撃者が欠陥を見つけて悪用しやすくなる可能性があります。
保守性の問題: 冗長コードやデッドコードが存在すると、開発者がシステムの機能に影響しないコード部分のデバッグや管理に時間を浪費する可能性があるため、コントラクトの保守や拡張を困難にします。
対策
冗長コードとデッドコードを削除する: 定期的なコードレビューとコントラクトのリファクタを実施し、冗長コードやデッドコードを取り除きます。これは複雑さを軽減し、コントラクトの効率性と分かりやすさを維持することを確保します。
ロジックをシンプルかつクリアに保つ: 既存の条件や関数で処理できる不要なチェックやロジックの重複を避けます。エラー発生の可能性を最小限に抑えることを可能にするため、コントラクトロジックをシンプルかつクリアに保ちます。
ガスコストを最適化する: 不要なロジックを削除するとガスの消費量を削減し、ユーザーに対してコントラクトの費用対効果を高め、ネットワーク全体のパフォーマンスを向上します。
自動ツールを使用する: 静的解析ツールとリンターを実装して冗長コードやデッドコードを検出し、コードベースを合理化し、ベストプラクティスを適用します。
コンパイラバージョンと非推奨関数のテスト (Test for Compiler Version and Deprecated Functions)
説明
開発ポリシー、セキュアコーディングスタンダード、コードの明確さ、テストカバレッジを適切に管理することで、スマートコントラクトの安全性、保守性、脆弱性に対する耐性を確保します。このテストはスマートコントラクトの開発とレビューに関するベストプラクティスとガイドラインの遵守を確保することに重点を置いています。これには、最新のコンパイラの使用、非推奨関数の回避、徹底したコードレビュー、適切なテストカバレッジを含みます。コードの明確さは、コントラクトを長期にわたって維持し、理解しやすく監査可能な状態を維持するためにも重要です。
テスト 1: コンパイラバージョンを検証して非推奨関数を回避する
脆弱なコード:
pragma solidity ^0.4.0;
contract Example {
uint256 public value;
function setValue(uint256 _value) public {
value = _value;
}
}なぜ脆弱なのか
コントラクトは古いコンパイラバージョン (^0.4.0) を使用しています。古いバージョンの Solidity を使用すると、既知のセキュリティ脆弱性や最新機能のサポートの欠如につながる可能性があります。
また、古いコンパイラは新しいバージョンで利用できる最適化やセキュリティ修正も欠いています。
修正されたコード:
pragma solidity ^0.8.0; // Update to the latest stable version
contract Example {
uint256 public value;
function setValue(uint256 _value) public {
value = _value;
}
}チェック方法
コードレビュー: pragma ディレクティブで最新バージョンの Solidity (例: ^0.8.x) を指定しており、^0.4.x などの古いものではないことを確認します。
自動チェック: Solidity リンティングツールまたは自動 CI/CD パイプラインを使用して、古いコンパイラバージョンの使用をフラグ付けします。
テスト 2: コードレビュープロセスを確認して非推奨関数を回避する
脆弱なコード:
pragma solidity ^0.4.24;
contract Token {
string public name = "Token";
uint public totalSupply = 1000000;
// Deprecated function in Solidity 0.4.x
function transfer(address recipient, uint amount) public {
require(msg.sender != recipient, "Cannot transfer to yourself");
require(amount <= totalSupply, "Amount exceeds total supply");
totalSupply -= amount;
// Deprecated: The transfer method below is obsolete
recipient.transfer(amount);
}
}
なぜ脆弱なのか
上記の例の関数 transfer は非推奨の
transfer()メソッドを使用して、受信者に Ether を送信します。transfer()メソッドは Solidity 0.5.x で削除されました。新しい Solidity バージョンでのガス制限と転送動作の変更によるエラーを防ぐため、代わりにcall()を使用することをお勧めします。非推奨関数を使用すると、コントラクトは Solidity の将来のバージョンと互換性がなくなり、予期しない動作に脆弱なままとなる可能性があります。
修正されたコード:
pragma solidity ^0.8.0;
contract Token {
string public name = "Token";
uint public totalSupply = 1000000;
function transfer(address payable recipient, uint amount) public {
require(msg.sender != recipient, "Cannot transfer to yourself");
require(amount <= totalSupply, "Amount exceeds total supply");
totalSupply -= amount;
// Replaced deprecated transfer method with call to ensure proper handling
(bool success, ) = recipient.call{value: amount}("");
require(success, "Transfer failed");
}
}
なぜ修正が機能するのか
更新されたコードは Ether を送信するために、非推奨の
transfer()の代わりに `call() メソッドを使用します。call()メソッドはより柔軟性が高く、ガスを指定してエラーを適切に処理できるため、Solidity 0.5.x 以上で推奨されます。この変更は、コントラクトが新しい Solidity バージョン (>=0.5.x) と互換があることを確保し、将来のアップグレードでの潜在的な問題を回避します。
チェック方法
コードレビュー: コントラクトが非推奨の関数や廃止された関数を使用していないことを確認します。Ether 送信時の、
transfer()、send()、その他の古いメソッドを探し、より安全なcall()メソッドで置き換えます。静的解析ツール: SolidityScan, MythX, Slither, リンターなどのツールを使用して、非推奨の機能を検出し、コードを更新するための提案を提供します。
テスト: 最新の Solidity バージョンを使用してコントラクトをテストし、非推奨の関数が使用されていないことを検証して、新しいコンパイラとの互換性を確保します。
Last updated