スマートコントラクト言語

スマートコントラクトの安全性は、言語の型システム・コンパイラ保証・実行モデルに大きく依存する。現在の主流は EVM 系（Solidity・Vyper）、Rust 系（Solana・NEAR・CosmWasm）、Move 系の 3 系統であり、各言語は異なる安全性トレードオフを持つ。情報カットオフ ~2025-08、confidence: medium 固定（2026-06 時点での外部再検証は未実施）。

Solidity — EVM の主流言語

Solidity は Ethereum がデザインした静的型付けのオブジェクト指向言語で、EVM 上のスマートコントラクト作成においてデファクトスタンダードとなっている（2015 年初リリース、現在は v0.8.x 系）。

構文と型システム: JavaScript に近い構文を持ち、uint256・address・bytes32・構造体・マッピング・動的配列などを扱える。public/private/internal/external の可視性修飾子と view/pure/payable の関数修飾子で状態変更とイーサ受信を宣言的に制限する。

既知の脆弱性パターン:

• Reentrancy: 外部コントラクト呼び出し後に状態を更新すると、再入呼び出しで不正引き出しが可能（The DAO 事件の根本原因）。checks-effects-interactions パターンや ReentrancyGuard で緩和する。
• 整数オーバーフロー: v0.8.0 以前はオーバーフローが silent だったが、v0.8.0 からデフォルトでリバートするよう変更された。
• アクセス制御ミス: onlyOwner などの修飾子を関数に付け忘れると、誰でも管理関数を呼び出せる。
• tx.origin 依存: tx.origin でなく msg.sender を使う必要がある（フィッシング攻撃リスク）。

Solidity のエコシステム: Remix IDE・Hardhat・Foundry など多様なツールチェーン、OpenZeppelin 標準ライブラリ（ERC-20、ERC-721、アクセス制御など）、豊富なコミュニティとドキュメントを持つ。

Vyper — シンプル志向の EVM 言語

Vyper は Python 風の構文を持つ EVM 向けスマートコントラクト言語で、Solidity の「過剰な機能」が脆弱性を生むという反省から設計されている。

設計方針（意図的な制限）:

• クラス継承なし（複雑な継承ツリーによる設計ミスを防ぐ）
• 関数のオーバーロードなし
• インラインアセンブリなし（assembly {} ブロック相当を排除）
• 再帰呼び出しなし（再入防止に貢献）

監査しやすさ: Vyper コードは Solidity よりもコード量が少なく、人間が読んで理解しやすいことを優先する。Curve Finance など DeFi の核心プロトコルが Vyper を採用している。

2023 年のコンパイラバグ: Vyper v0.2.15〜0.3.0 のコンパイラに reentrancy ガードが正しく適用されないバグが発覚し、Curve のいくつかのプールが攻撃を受けた（約 7,000 万ドル規模の被害）。言語の設計ではなくコンパイラのバグであったが、スマートコントラクト言語では「コンパイラ自体のセキュリティ」も重要であることを示した。

Rust — Solana・NEAR・CosmWasm の言語

Rust はメモリ安全性を所有権システムで保証するシステムプログラミング言語で、Solana・NEAR・CosmWasm（Cosmos）のスマートコントラクト言語として採用されている。

所有権モデルとスマートコントラクト: Rust の所有権・借用・ライフタイムシステムは、ダングリングポインタや二重解放などのメモリ安全性問題をコンパイル時に排除する。スマートコントラクト文脈では、コントラクトが不正なメモリアクセスをしない保証につながる。

Solana プログラム: Solana では Rust（または C）で書いたプログラムを BPF にコンパイルしてデプロイする。アカウントはデータストレージ、プログラムはロジックとして分離されており、Anchor フレームワークがボイラープレートを大幅に削減する。

NEAR スマートコントラクト: NEAR では Rust（または AssemblyScript）でコントラクトを書き WASM にコンパイルする。#[near_bindgen] マクロによる SDK が標準。

CosmWasm: Cosmos エコシステムの WASM ランタイム向けに Rust でコントラクトを書く。execute・query・instantiate のメッセージハンドラを実装するパターンで、reentrancy を構造的に防ぐ設計となっている。

Rust の課題: 学習コストが高く（ライフタイムの理解など）、Solidity に比べて開発者の絶対数が少ない。ただし、型安全性とパフォーマンス上のメリットから、新興 L1 の多くが Rust を選択している。

Move — リソース型と線形型による安全性

Move は Aptos・Sui で採用される言語で、スマートコントラクトの安全性問題を型システムレベルで解決することを目指す。

線形型（Linear Types）とリソース: Move の核心概念は「リソース（Resource）」である。リソースは以下の制約を持つ線形型で定義される。

1. コピー不可（Copy 能力なし）: デジタルアセットを誤ってコピーできない
2. 暗黙廃棄不可（Drop 能力なし）: アセットを「捨てる」コードを書くとコンパイルエラー
3. 所有権の明示的追跡: リソースは常にある場所に「存在」し、移動（move）のみ可能

これらの制約により、トークンの二重使用や意図しない消滅のバグをコンパイル時に検出できる。

Aptos Move vs Sui Move:

• Aptos Move はグローバルストレージモデルを採用。リソースはアカウントのストレージに格納される。
• Sui Move はオブジェクト中心モデル。すべてのデータは「オブジェクト」として管理され、所有関係（owned / shared / immutable）に基づき楽観的並列実行が可能になる。

形式検証との親和性: Move のリソース型システムは形式検証ツール（Move Prover）との統合が容易で、プロトコルの正しさを数学的に証明するアプローチが取りやすい。

言語選択の判断軸

各言語の脆弱性パターンの体系的整理は tech-226（セキュリティ監査）を参照のこと。