表現力の高いスマートコントラクトのリスク：最新のイーサリアムハックから得られる教訓

yutaro stacksats
2月25日
読了時間: 6分

イーサリアムのスマートコントラクトに対するBybitの新たな攻撃は、イーサリアム・プロトコルに組み込まれたセキュリティ上のトレードオフに関する長年の議論を再燃させています。

今回の事件は、Ethereum Virtual Machine（EVM）の限界と、特にマルチシグ（multisig）ウォレットのセキュリティに関して、複雑かつステートフル（状態を持つ）なスマートコントラクトへの依存が注目を集めています。

イーサリアムのマルチシグが抱える根本的な問題

マルチシグ（複数署名）ウォレットは、資金移動に複数の署名を必要とすることで、セキュリティの基本レイヤーとして機能します。ビットコインやLiquid Networkでは、OP_CHECKMULTISIGのようなネイティブのオペコードや、Schnorrベースのインタラクティブなマルチシグ機能によって、マルチシグの実装はシンプルで、コードの規模も小さく、バグのリスクも低く抑えられています。

しかしイーサリアムでは、マルチシグの機能を再現するために、開発者が独自のカスタムコードを書く必要があります。これにより、実装の複雑性が増し、セキュリティリスクも高まります。こうしたスマートコントラクトは、オンチェーンの状態管理や、実行中に再度呼び出される“リエントランシー”の対応、複数署名者のロジックの正確な実装などを自力で行わなければなりません。

これらの設計・実装ミスが重大な脆弱性を招くことは、2017年のParityウォレットのハッキング事件などの有名な事例からも明らかです。

イーサリアム設計上の構造的課題

1. ネイティブなマルチシグの欠如

ビットコインには、マルチシグ取引を実現するための組み込みスクリプト（例：OP_CHECKMULTISIG）が用意されています。しかし、イーサリアムにはそれに相当するネイティブ機能がなく、開発者は署名の管理、オンチェーン状態の追跡、署名の追加による更新処理などをすべて独自のコントラクトで実装する必要があります。このような実装は監査を困難にし、バグの発生リスクを高めます。

2. 高機能すぎるスクリプト環境

EVM（Ethereum Virtual Machine）は、ループ、任意の関数呼び出し、他の複数コントラクトとの相互作用など、ほぼあらゆるタイプの計算処理を許容します。こうした柔軟性によって複雑なdApps（分散型アプリケーション）の構築が可能になりますが、同時にセキュリティ監査は極めて困難になります。開発者は以下のような問題に対応しなければなりません：

リエントランシー（Reentrancy）：コントラクトが外部のコントラクトを呼び出す際、処理が完了する前に逆に再度呼び戻される可能性があります。これにより、状態の一貫性が崩れるリスクがあります。
グローバルな共有状態（Shared Global State）：イーサリアムでは、複数のコントラクトが同じグローバルなキーバリューストア（state tree）を共有しています。つまり、1つのコントラクトやライブラリのバグが、まったく関係ない他のコントラクトにまで影響を及ぼす可能性があります。
ガス制約（Gas Constraints）：すべての操作にはガスが必要です。不適切なタイミングでガスが不足すると、契約ロジックが凍結したり壊れたりするリスクがあります。

3. グローバル・キーバリューストアの使用

イーサリアムはアカウントベースモデルを採用しており、すべての状態は1つのグローバルな状態ツリーで管理されています。そのため、あるコントラクトの更新が他のコントラクトのデータや挙動に予期せず影響することがあります。これに対してビットコインはUTXO（未使用トランザクション出力）モデルを採用しており、状態変更は各トランザクション内に局所化されています。これにより、ある契約のバグが別の契約に波及するリスクを大幅に低減しています。

なぜイーサリアムのマルチシグは失敗するのか

イーサリアムでマルチシグによる高度なセキュリティを求めるユーザーには、通常3つの選択肢があります：

1. 単一鍵による管理

最もシンプルな方法ですが、秘密鍵が1つしかないため、万が一その鍵が漏洩した場合、資金はすべて奪われてしまいます。

2. 高度なマルチパーティ計算（MPC）

しきい値ECDSAのような暗号技術を使い、単一障害点を回避する手法です。ただし、専用ライブラリが必要になったり、計算コストが大きくなることがあります。

3. カスタムスマートコントラクトによるマルチシグ

イーサリアムで最も一般的な方法ですが、最も危険でもあります。契約コードそのものにバグがあると、攻撃者に資金を抜き取られる可能性があり、その被害は致命的です。

今回の事件（Bybitのスマートコントラクトの不正利用）が示すのは、イーサリアムの複雑性が、しばしば不完全なインターフェース（フロントエンド）への依存を生み出しているという点です。ユーザーは、ハードウェアウォレットが確認してくれると信じて表示された情報をもとに署名してしまいますが、実際にはウォレットはその内容を検証していないこともあります。

これに対して、ビットコインのネイティブなマルチシグ（例：2-of-3）の仕組みははるかにシンプルです。必要な署名数を指定するだけで、プロトコルがそれを厳格に執行し、複雑なコントラクトロジックに依存する必要がありません。

「ポスト・Simplicity」時代の展望

イーサリアムがスマートコントラクトの脆弱性に繰り返し悩まされている一方で、ビットコインとそのサイドチェーンは、より堅牢なマルチシグへの進化を続けています。

ビットコイン本体では、MuSigのような暗号方式が注目されています。MuSigは複数の署名をひとつにまとめることで、マルチシグ取引が単一署名のように見えるようにします。これにより、プライバシーと効率性の両方が向上します。

さらに未来を見据えると、Liquid上で提案されているSimplicityという新しいスクリプト言語は、ビットコインが大切にしてきた「慎重なセキュリティ姿勢」を維持しつつ、より高機能なスマートコントラクトを実現するものです。

Simplicityはチューリング完全なスマートコントラクトの代わりに、「形式的に検証可能なスクリプト」に重点を置いており、これによりコードの監査や正しさの証明が容易になります。また、コヴナント（資金の使用条件を強制する仕組み）やカスタムSIGHASHタイプなどの高度な機能も提供し、EVMに見られるような計算無制限による落とし穴を避ける設計となっています。

表現力の高すぎるスマートコントラクトへの警鐘

今回のイーサリアムにおけるマルチシグのハッキング事件は、重要な教訓を改めて示しています。スクリプト環境が複雑になればなるほど、見落とされがちなセキュリティホールが増えるということです。

イーサリアムは非常に柔軟な一方で、開発者には常に契約コードの設計・監査・アップデートに対する高い注意力が求められます。

対照的に、ビットコインではマルチシグがプロトコルレベルで実装されており、開発者のミスによる致命的なバグのリスクが大幅に低減されています。

ブロックチェーン業界が成熟していく中で、セキュリティは後付けの機能ではなく、設計段階で最優先すべき要件であることが、ますます明らかになってきています（参考）。

イーサリアムが直面している「コントラクトベースのマルチシグ」の課題は、セキュリティを後付けではなく標準機能として持つプロトコルの重要性を際立たせています。毎回ゼロから安全なマルチシグを開発しようとすれば、同時に新たな脆弱性を再発明してしまうリスクがついて回るのです。