こんにちは！IoTやスマートコントラクトの世界へようこそ。
日々、世の中の仕組みがデジタル化され、ブロックチェーンを使ってお金や大切なデータをやり取りする機会が増えてきましたよね。「なんだか難しそうだな…」と感じている方もご安心ください。今回は、最先端のセキュリティ技術である「形式検証（Formal Verification）」について、身近な例えを交えながら、一歩ずつ優しく紐解いていきたいと思います。
セキュリティの現場で私たちが直面するのは、「人間は必ずミスをする」という冷徹な現実です。どんなに優秀な開発者でも、コードの隅っこにほんの小さなうっかりミス（バグ）を作り込んでしまうことがあります。そして、ブロックチェーンの世界では、その「たった一つのうっかり」が、一瞬で全財産の消失につながってしまうんです。
それでは、泥棒から大切な家を守る防犯の仕組みを思い浮かべながら、スマートコントラクトの安全な守り方を見ていきましょう！
—
1. 家の鍵とスマートコントラクトの「うっかり」
皆さんは、自分の家に頑丈な玄関の鍵をかけていますよね。ピッキングに強いディンプルキーを選んだり、二重ロックにしたり。
でも、もし「窓の鍵が最初から全開になっていた」としたらどうでしょう？ どんなに高級な玄関の鍵をつけても、泥棒は窓から簡単に侵入できてしまいますよね。
スマートコントラクトの世界でもこれと全く同じことが起きます。
コントラクトとは、ブロックチェーン上で動く「自動販売機のようなプログラム」です。お金のやり取りや権利の移転を自動で行ってくれますが、プログラムを書く段階で「誰でも勝手に金庫の扉を開けられる」という小さなミス（脆弱性）が混ざってしまっていると、悪意あるハッカー（泥棒）にすべてを奪われてしまうのです。
これまでのテスト（単体テストなど）は、「泥棒が正面玄関をガチャガチャと揺すってきた時に開かないか」を確かめるようなものでした。しかし、それだけでは「想定外の侵入経路」を見落としてしまうことがあります。
そこで登場するのが、今回紹介する「形式検証（Formal Verification）」です。
—
2. 形式検証ってなに？ 防犯カメラと数学の力
形式検証を身近な例でたとえるなら、「家の中のすべての間取りと窓のサイズを数学的に完全に計算し尽くし、『物理的にどうあがいても泥棒が侵入不可能な構造になっているか』を証明書付きで証明する最強の設計士」のようなものです。
テストが「動かしてみたら大丈夫だった」という経験則なのに対し、形式検証は「数学の数式を使って、あらゆる未来の可能性（ありとあらゆるハッカーの攻撃パターン）をすべて計算し、100%安全であると証明する」アプローチになります。
Certora（セルトラ）やK-Frameworkといった最先端のツールを使うことで、私たちはこの数学的な証明をスマートコントラクトに対して行うことができるんです。
—
3. 実際にコードを見てみよう！
難しく考えず、簡単な例を見てみましょう。
例えば、以下は「自分のお金だけを引き出せる」はずの、ちょっと危なっかしい銀行のスマートコントラクト（Solidity言語）です。
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract SimpleBank {
// ユーザーごとの残高を管理する台帳
mapping(address => uint256) public balances;
// お金を預ける関数
function deposit() external payable {
balances[msg.sender] += msg.value;
}
// お金を引き出す関数
function withdraw(uint256 amount) external {
// 残高が足りているかチェック
require(balances[msg.sender] >= amount, "Not enough balance");
// お金を送金する処理（ここにバグが潜みやすい！）
(bool success, ) = msg.sender.call{value: amount}("");
require(success, "Transfer failed");
// 残高を減らす処理
balances[msg.sender] -= amount;
}
}おっと、上記のコードには有名な「リエントランシー（再入可能性）脆弱性」というバグが隠れています。送金処理 (msg.sender.call) を行う前に残高を減らしていないため、ハッカーが悪意あるコントラクトを使って「お金をもらう→まだ残高が減っていないうちに再度引き出し関数を呼び出す」を繰り返すと、銀行の残高がすっからかんになるまで無限にお金を引き出せてしまうんです。
—
4. Certoraを使った「絶対に破られないルール」の定義
このバグを人間の目だけで見つけるのは至難の業ですが、形式検証ツール（Certoraなど）を使えば、次のような「破られてはならないルール（仕様）」を定義して、ツールに数学的に検証させることができます。
Certora Specification Language (CVL) という専用の言語を使って、ルールを書いてみましょう。
methods {
// 検証対象のコントラクトの関数を定義
function balances(address) external returns (uint256) envfree;
function withdraw(uint256) external;
}
// ルール：どんな攻撃者がどんな順序で関数を呼び出そうとも、
// 「コントラクト全体のETH残高」は「全ユーザーの預金残高の合計」以上でなければならない！
invariant sol_balance_covers_deposits(address a)
currentContract.balance >= balances(a)この仕様（インバリアント＝不変条件）をCertoraに読み込ませて実行すると、ツールは数秒〜数分かけて、「このルールを破るような悪意ある入力の組み合わせ（攻撃パターン）が存在するかどうか」を隅々まで計算します。
もし脆弱性があれば、Certoraは「この条件を満たさないルートが見つかりました！」と、ハッカーがどのように侵入してくるかの手順（反例）を完璧に暴き出して教えてくれるのです。これにより、私たちは本番環境にコードをデプロイする前に、完全にバグを潰すことができます。
—
5. 一歩ずつ、安全な開発者へ
いかがでしょうか？
形式検証という言葉を聞くと、何やら大学の数学の研究室のような難解なものをイメージしてしまいますよね。しかし本質は、「自分たちの作ったプログラムが絶対に破られないことを、数学の力で事前に保証してもらう心強い味方」です。
新人のIT担当者や開発者の皆さんも、最初から完璧なコードを書く必要はありません。まずはテストの重要性を知り、こうした最先端の安全網（セキュリティツール）が存在することを頭の片隅に置いておくだけで、プロとしての視点がガラリと変わります。
一歩ずつ、安全で信頼されるスマートコントラクトの作り手を一緒に目指していきましょう！次の実務でも、ぜひ「このコードの不変条件はなんだろう？」という視点を取り入れてみてくださいね。
コメント