AiAda Docs / Smart Contract Writeups

Appearance

Return to top
On this page

スマートコントラクトのストレージ可視性とセキュリティ：Ethernaut Vaultチャレンジの詳細解説

はじめに：ブロックチェーンにおける「プライベート」変数の誤解

Ethereumスマートコントラクト開発において、最もよくある誤解の一つが「プライベート」変数の性質に関するものです。Solidityのprivateキーワードは、他のコントラクトからの直接的なアクセスを制限しますが、ブロックチェーンの根本的な性質上、データの完全な秘匿性を保証するものではありません。本記事では、Ethernautの「Vault」チャレンジを通じて、ブロックチェーンストレージの仕組みとセキュリティの重要な原則について詳細に解説します。

チャレンジ概要：Vaultコントラクトの分析

コントラクト構造の理解

提供されたVaultコントラクトは一見シンプルに見えますが、ブロックチェーンの基本原則に関する重要な教訓を含んでいます。

solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Vault {
    bool public locked;
    bytes32 private password;

    constructor(bytes32 _password) {
        locked = true;
        password = _password;
    }

    function unlock(bytes32 _password) public {
        if (password == _password) {
            locked = false;
        }
    }
}

このコントラクトには2つの状態変数があります：

  1. locked（public）: ボルトがロックされているかどうかを示すブール値
  2. password（private）: ロックを解除するためのパスワード（bytes32型）

セキュリティ上の誤解

開発者が犯しがちな誤りは、private修飾子がパスワードを外部から完全に隠蔽すると考えることです。しかし、Ethereumブロックチェーンでは、すべてのデータが公開されており、適切なツールと知識があれば誰でもアクセス可能です。

Ethereumストレージの仕組み：技術的基盤

ストレージレイアウトの基本

Ethereum仮想マシン（EVM）では、コントラクトストレージが256ビット（32バイト）のスロットの配列として構成されています。各スロットは0から始まるインデックスでアドレス指定されます。

ストレージの配置は以下のルールに従います：

  1. 静的サイズの変数は宣言順にストレージスロットに配置される
  2. 各スロットは32バイト（256ビット）を保持
  3. 32バイト未満の変数は可能な場合にパッキングされる

Vaultコントラクトのストレージレイアウト

Vaultコントラクトの場合：

  • スロット0: locked変数（bool型、1バイトのみ使用）
  • スロット1: password変数（bytes32型、32バイト全体を使用）

bool型は1バイトしか必要としませんが、EVMのストレージ最適化（パッキング）が行われない特定の条件下では、専用のスロットを占有します。このケースでは、boolとbytes32が連続して宣言されているため、別々のスロットに配置されます。

ストレージへの直接アクセス：実践的なエクスプロイト

ブロックチェーンストレージの公開性

Ethereumブロックチェーンの核心原則の一つは透明性です。すべてのトランザクション、すべてのコントラクトの状態、そしてすべてのストレージ値は、ネットワーク上の誰でも検査可能です。これは設計上の特徴であり、検証可能性と信頼性を確保するためのものです。

ストレージ読み取りの実装

以下のTypeScriptコードは、プライベート変数passwordをどのように読み取るかを示しています：

typescript
import { ethers } from "hardhat";
import { expect } from "chai";
import { Vault } from "../typechain-types";

describe("Vault", function () {
  describe("Vault testnet sepolia", function () {
    it("testnet sepolia Vault unlock", async function () {
      // コントラクトアドレスとABIの定義
      const VAULT_ADDRESS = "0x...";
      const VAULT_ABI = [
        "function unlock(bytes32 _password) public", 
        "function locked() external view returns (bool)"
      ];

      // 署名者の取得
      const challenger = await ethers.getNamedSigner("deployer");
      
      // コントラクトインスタンスの作成
      const vaultContract = new ethers.Contract(
        VAULT_ADDRESS, 
        VAULT_ABI, 
        challenger
      );

      // ストレージスロット1（password変数）の直接読み取り
      const SLOT1 = 1;
      const VALUE_PASSWORD_SLOT = await ethers.provider.getStorage(
        VAULT_ADDRESS, 
        SLOT1
      );

      // 取得したパスワードでロック解除を試みる
      const tx = await vaultContract.unlock(VALUE_PASSWORD_SLOT);
      await tx.wait();

      // ロック状態の確認
      const stateLocked = await vaultContract.locked();
      expect(stateLocked).to.be.equals(false);
    });
  });
});

コードの詳細解説

  1. ストレージスロットの特定: SLOT1 = 1は、password変数がストレージのスロット1に配置されていることを示します。

  2. getStorageメソッド: ethers.provider.getStorage()関数は、指定されたアドレスとストレージスロットの値を直接読み取ります。これはEthereumノードのeth_getStorageAt RPCメソッドを呼び出します。

  3. パスワードの使用: 読み取った値をunlock関数に渡すことで、コントラクトのロックを解除します。

根本的な問題：ブロックチェーンでのデータ秘匿性

スマートコントラクト設計の原則

このチャレンジから得られる重要な教訓は以下の通りです：

  1. ブロックチェーン上のすべてのデータは本質的に公開されている

    • privateとinternal変数は、他のコントラクトからの直接アクセスを防ぐだけ
    • ブロックチェーンの性質上、すべてのデータはノードを通じてアクセス可能

  2. 機密データの取り扱い

    • パスワード、秘密鍵、個人情報などをブロックチェーン上に保存すべきではない
    • 必要な場合は、暗号化やオフチェーンストレージを検討する

セキュアな設計パターン

機密性の高いデータを扱う必要がある場合のアプローチ：

solidity
// 安全な設計の例：パスワードの代わりにコミットメントスキームを使用
contract SecureVault {
    bool public locked;
    bytes32 public hashedPassword;
    
    constructor(bytes32 _hashedPassword) {
        locked = true;
        hashedPassword = _hashedPassword;
    }
    
    function unlock(string memory _password) public {
        bytes32 hashedInput = keccak256(abi.encodePacked(_password));
        if (hashedInput == hashedPassword) {
            locked = false;
        }
    }
}

このアプローチでは：

  • 元のパスワードではなく、ハッシュ値を保存
  • ハッシュ関数の原像計算困難性により、ストレージから元のパスワードを推測できない
  • ただし、弱いパスワードは依然としてブルートフォース攻撃の対象となる

実践的なセキュリティ対策

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

  1. ストレージ設計の最適化

    solidity
    // パッキングを活用した効率的なストレージ使用
contract OptimizedStorage {
    uint128 public data1;  // スロット0: 0-15バイト
    uint128 public data2;  // スロット0: 16-31バイト
    bytes32 private secret; // スロット1
}

  2. 機密データのオフチェーン管理

    • ユーザー認証情報はオフチェーンで管理
    • 必要に応じてゼロ知識証明などの高度な暗号技術を検討

  3. アクセス制御の適切な実装

    solidity
    contract AccessControlled {
    address private owner;
    mapping(address => bool) private authorizedUsers;
    
    modifier onlyOwner() {
        require(msg.sender == owner, "Not owner");
        _;
    }
    
    modifier onlyAuthorized() {
        require(authorizedUsers[msg.sender], "Not authorized");
        _;
    }
}

監査とテストの重要性

  1. ストレージアクセスのテスト

    • プライベート変数が外部からアクセス可能かどうかのテストを含める
    • ストレージレイアウトの想定を検証する

  2. セキュリティ監査

    • 専門的な監査チームによるコードレビュー
    • 自動化されたセキュリティ分析ツールの活用

結論：ブロックチェーン開発における根本的な理解の重要性

EthernautのVaultチャレンジは、ブロックチェーン開発における重要な原則を明確に示しています。スマートコントラクト開発者は、ブロックチェーンの根本的な性質—特にその透明性と不変性—を深く理解する必要があります。

privateキーワードはコントラクト間のアクセス制御を提供しますが、データの秘匿性を保証するものではありません。機密性の高い情報を扱う場合、開発者は適切な暗号技術、オフチェーンソリューション、または専用のプライバシー保護プロトコルを検討すべきです。

このチャレンジから得られる最も重要な教訓は、ブロックチェーン上に配置するデータはすべて公開される可能性があるという前提で設計を行うことです。セキュリティは単なるキーワードや修飾子ではなく、システム全体のアーキテクチャと根本的な理解に基づく包括的なアプローチが必要です。

スマートコントラクト開発者は、これらの原則を理解し、適切な設計パターンを適用することで、より安全で堅牢な分散型アプリケーションを構築することができます。ブロックチェーンの透明性は強力な機能ですが、それと同時に開発者に新たな責任と考慮事項をもたらすことを常に認識しておく必要があります。

Built with AiAda

Copyright © 2026