Eth solidity

Solidityは何故ブロックチェーン開発で使われ続けるのか?

10,105文字

Solidityが覇権を握っているのは、それがプログラミング言語として世界で最も優れているからではありません。むしろ、セキュリティの脆弱性が指摘されることもあれば、ガス代の最適化に苦労させられることもある、頑固オヤジのような言語です。

それなのに、なぜBNBも、Avalancheも、果ては独自路線を行くはずだったCardanoやSolanaまでもが、MilkomedaやSolangのような仕組みを入れてまで、ひれ伏すようにSolidityを採用したのでしょうか？

それは、Solidityが単なる「コードを記述する道具」ではなく、Web3という新しい経済圏のリンガ・フランカになってしまったからです。

イメージしてください。あなたが新しい国を作るとします。そこで話される言葉を、文法が完璧なエスペラント語にするか、それとも語彙が乱れていても世界中のビジネスマンが話せる「英語」にするか。

Solidityは、Web3における「英語」です。

この記事では、Web3の歴史上で最も成功し、最も愛され、そして最も呪われている言語について、どこよりも詳しくご紹介します。

Solidityとは?

言うより見るほうが早いので、まずはSolidityのサンプルコードを見てみましょう。

pragma solidity ^0.8.0;

contract DigitalTipJar {
    address public owner;
    mapping(address => uint256) public contributions;

    constructor() {
        owner = msg.sender;
    }

    function donate() public payable {
        contributions[msg.sender] += msg.value;
    }

    function withdraw() public {
        require(msg.sender == owner, "Only the owner can withdraw");
        payable(owner).transfer(address(this).balance);
    }
}
Code language: SAS (sas)

このわずか20行にも満たないSolidityのコードを一度ブロックチェーンにデプロイするだけで、世界中のどこに住む誰からでも24時間365日、1円単位での寄付を募ることが可能になります。

特筆すべきは、ここに銀行や決済代行会社の介入余地が一切ない点です。そこのあるのはコードとトランザクションだけであり、資金を引き出す権利は、コードのオーナーのみが持ち、そのルールは数学的に保証されています。この透明性と強制力こそが、スマートコントラクトがWeb3の心臓部として採用される最大の理由です。

この魔法のような仕組みが誕生したのは、2013年の暮れのことでした。

当時19歳の若き天才ヴィタリック・ブテリンは、ビットコインが持つ決済機能に魅入られると同時に限界も感じており、より複雑な計算ができるワールド・コンピュータとしてのイーサリアムを構想しました。

しかし、その巨大なコンピュータを動かすには、開発者が容易に扱える高度な言語が必要でした。そこで2014年、共同創設者のギャビン・ウッドが開発したもの。それこそが、JavaScriptやC++の書き味を継承しつつ、資産管理に特化した「Solidity」だったのです。

Chrome h4scaT88t8

10年ほど前に産声を上げたこのSolidityという名の言語は、スマートコントラクト言語別のTVL（預かり資産）占有率において、2026年2月6日現在、85.65%という驚異的なシェアを叩き出しています1。

このシェア率は、他の製品と比べても圧倒的です。例えばMicrosoft Windowsですら、デスクトップOSシェアでは約70~80%に過ぎません。

つまりSolidityの支配力は、「PCといえばWindows」というレベルを優に超え、もはやインフラそのものと化しているのです。欠点や脆弱性が議論されながらも、なぜこの「独占状態」は崩れないのでしょうか？

EVM互換性という名の最強の包囲網

なぜ、後発のブロックチェーンは独自の言語を開発せず、わざわざSolidityを採用したのでしょうか。

その答えは、イーサリアムが作り上げた実行環境EVM（Ethereum Virtual Machine）にあります。

「開発者の引越し」を無料にした戦略

新しいブロックチェーンを立ち上げる際、最大の課題は「開発者にアプリを作ってもらうこと」です。もしそのチェーンが独自の言語しか受け付けないなら、開発者は新しい学習コストを支払わなければなりません。

しかし、Binance Smart Chain（BSC）やAvalanche、Polygonなどは賢い選択をしました。Ethereumと完全互換性を有することを宣言したのです。

これにより、Ethereumで成功したdAppsたちは、そのコードをそのままコピー＆ペーストするだけで、数時間以内に新しいチェーンへ移住させることが可能になりました。

この「互換性」こそが、Solidityを単なる言語から、全チェーン共通の言語へと昇華させたのです。

この「コピー＆ペースト」がもたらした最大の恩恵は、単にアプリを移植しやすかったことにとどまりません。
真の価値は、「一度書いたコードが、そのまま数十のチェーンで通用する」というメンテナンス効率にあります。

例えば、DeFiの巨人、AaveはEthereumだけでなく、Polygon、Avalanche、Arbitrum、Optimism、Baseといった、数多くの「EVM互換チェーン」に展開しています。

これらすべてのチェーンで異なるプログラミング言語を使わなければならなかったとしたらどうなるでしょう？各言語を操るプログラマを雇い、バグが見つかるたびに各言語のコードを直し、セキュリティ監査にも多額の費用を払う…。そんな非効率に対して、永久にコストを支払い続けなければならないのです。

しかし、Solidityという「共通言語」を使っているAaveにとって、マルチチェーン展開は驚くほど合理的です。一つのSolidityコードベースさえ維持すれば、それを全世界のEVM互換チェーンへ一斉にデプロイできるからです。

Write Once, Run Anywhereという、かつてJavaが掲げた理想を、Web3の世界で最も実現しているのがSolidityなのです。

Milkomedaが証明したSolidityの引力

さらに興味深いのが、独自の設計思想を持つチェーンの動向です。CardanoやSolana、Algorandなどは、それぞれPlutus(Haskellベース)、Rust,PyTeal(Pythonベース)といった、本来Solidityとは無縁の言語を採用していました。

しかし、結果として彼らはMilkomedaのようなサイドチェーンを介して、Solidityが動く環境を後付けで用意せざるを得ませんでした。なぜか。

「Solidityが動かない場所には、開発者も資金も集まらない」という残酷な現実を突きつけられたからです。まさに、どれだけ高性能な独自OSを作っても、Windowsのソフトが動かなければ普及しない、という歴史の繰り返しがブロックチェーンの世界でも起きています。

コピペが生むセキュリティの盾

Solidityは脆弱性が指摘されやすいのに、なぜ「安全」だと言われるのでしょうか？ この矛盾を解く鍵が、OpenZeppelinに代表される標準ライブラリの存在です。

しかし、その重要性を語る前に、まずSolidityが抱えるリスクの正体を、最新の研究結果から直視する必要があります。

完璧なコードすら裏切るコンパイラの罠

2024年に発表された最新の研究論文「Towards Understanding the Bugs in Solidity Compiler2」（Maら, 2024）では、Solidityのソースコードを機械語に変換する「コンパイラ」そのものに潜む深刻なバグが暴かれています。

Like other compilers, smart contract compiler is not immune to bugs that can affect performance, reliability, and security of the compiled contracts, even when the source code is flawlessly crafted.

他のコンパイラと同様、スマートコントラクトのコンパイラもバグから無縁ではない。たとえソースコードが完璧に（非の打ち所がないように）書かれていたとしても、コンパイル後のコントラクトの性能や信頼性、そしてセキュリティに悪影響を及ぼす可能性があるのだ。

この研究では、Solidityコンパイラにおいて実に533個ものユニークなバグが確認されています。
つまり、開発者がどれほど注意を払って「正しい」コードを書いても、言語を動かすシステムそのものがバグを引き起こし、資産を危険にさらすリスクが常に存在しているのです。

「車輪の再発明」を禁止したエコシステム

これほどまでに呪われたリスクを抱え、既存のスマートコントラクトの90%以上を占めるほど普及しているSolidity。
この混沌とした状況に対する、開発者コミュニティの現実的な最適解がOpenZeppelinです。

論文が指摘するように、Solidity開発における最大のリスクは「独自の複雑なロジックを1から書くこと」にあります。
独自のコードを書けば書くほど、開発者のミスだけでなく、コンパイラの未知のバグを踏み抜く確率も上がります。

これに対してOpenZeppelinは、ERC-20やERC-721といった標準的な機能を、世界中のエンジニアが数年かけて磨き上げた「完成されたテンプレート」として提供しました。OpenZeppelinのコードは、世界で最も多くのハッカーに狙われ、最も多くの監査を受け続けてきた「戦場帰りのコード」です。

皮肉なことに、過去に多くのハッキング事件を経験し、そのたびに「血の教訓」をコードに刻み込んできたSolidityは、現在において「世界で最も戦場に慣れた、枯れた言語」としての地位を確立したのです。

挑戦者Vyperの躍進と、安全の崩壊

Chrome JwMrDnw4Rp

Solidityが頑固オヤジだとするなら、2017年に登場したVyperは、親父の背中を見て育った反骨精神に溢れた若者でした。

VyperはPythonに近い、可読性の高い美しい構文を持ち、コード設計上においても、例えば複雑な継承や関数のオーバーロードを禁止して「読みやすさ」を徹底したり、無限ループを禁止してガス代の予測不可能性を排除することで「安全性」を強制するなど、Solidityの欠点を徹底的に排除することを目指しました。

このVyperの可読性を極限まで高めていく思想に共鳴したのが、ステーブルコインのスワップに強みを持つCurve Financeでした。彼らはその極めて高度なロジックを記述するために、あえてSolidityではなくVyperを選択しました。
実際、Vyperで書かれたコントラクトの中には、一時期、230億ドル規模の資産が平然と預けられており、それに伴ってVyperのTVLドミナンスは市場全体の30%を占める程にまでになったのです。

しかし、Maらが指摘した通り、どんなに言語の設計が美しくても、それを動かすコンパイラの中に魔物が潜んでいれば、すべては一瞬で崩壊します。

2023年7月、スマートコントラクトの歴史に残る悲劇がCurve Financeを襲いました。

A notable reported smart contract compiler flaw was its inadvertent transformation of a well-implemented reentrancy guard at the source code level into a malfunctioning version in the bytecode.

極めて重大なコンパイラの欠陥が報告された。それは、ソースコードレベルでは正しく実装されていた「再入攻撃への防御」が、バイナリコードに変換される際に、誤って機能しないバージョンに書き換えられてしまうというものだった。

開発者が書いた「鍵をかける」という命令が、Vyperコンパイラのバグによって、機械には「鍵をかけない」と伝わっていたのです。この欠陥は2年以上も誰にも気づかれずに潜伏していました。

This concealed flaw remained undetected for over two years until it was exploited by malicious entities in July 2023, culminating in a financial loss of approximately $73.5 million.

この隠れた欠陥は2年以上も検出されなかった。しかし2023年7月、悪意ある実体によって悪用され、結果として約7,350万ドル（当時のレートで約110億円）もの巨額損失を招くこととなった。

この事件が業界に与えた衝撃は、単なるハッキング以上の意味を持っていました。「より新しく、洗練された言語」よりも、「古く、何度も攻撃され、そのたびに修正されてきた言語」の方が、皮肉にも安全であるという残酷な事実を突きつけたからです。

Solidityコンパイラにも、確かに533個ものバグが報告されています 。しかし、その多くはすでに特定され、対策が議論され、OpenZeppelinのような盾によって防御方法が確立されています。

既存のスマートコントラクトの90%近くがSolidityで書かれているという事実は、単なる慣習ではありません 。それは、数千回に及ぶハッキングの試行、何千万ドルものバグ懸賞金、そして何万人もの開発者による監視と改善によって、地獄のような戦場を生き残ってきたという「生存証明」なのです。

新興言語がどれだけ「理論上の安全性」を謳おうとも、Solidityが持つ「歴史という名のセキュリティ」という壁を崩すことは、今なお、極めて困難であると言わざるを得ません。

Solidityキラー Rust

もっとも、最近では特にSolanaやNear Protocolといった高性能なレイヤー1ブロックチェーンがRustをメイン言語に採用したことで、Solidity一強時代に明確なヒビが入り始めました。なぜ今、多くのトップエンジニアたちがSolidityを脱ぎ捨て、Rustへと乗り換えているのでしょうか。

最大の理由として、イーサリアムとSolidityの最大の弱点は、すべての処理を一つずつ順番に行う直列処理という点にあります。対して、Rustを採用するSolanaは並列処理を武器にしています。複数の取引を同時に処理できるそのスピードは、Solidity勢を文字通り置き去りにする異次元の速さを誇ります。

人間なら数秒の待ち時間は許容できるかもしれません。しかし、ミリ秒単位で膨大なデータを処理し、取引を行うAIエージェントにとって、この「順番待ち」は致命的なボトルネックとなります。SolanaやNear Protocolがこの言語を選択したのは、まさにこの「数百万のAIエージェントが同時に、リアルタイムで意思決定を行う未来」を見据えているからにほかなりません。

更に前述の論文でも指摘された通り、Solidityはその柔軟さゆえに、ソースコードが完璧でもコンパイラの挙動一つで資産が失われる危うさを孕んでいます 。 これに対し、Rustは「メモリ安全性」に極めて厳格な言語です。コンパイル段階で、少しでも危険なコードがあれば「そもそも実行すらさせない」というボローチェッカーが組み込まれています。Solidityが「後から盾（OpenZeppelin）で守る」文化なのに対し、Rustは「最初から鎧を着た状態でしか外に出さない」文化なのです。

「エンジニアの壁」という名の選別

では、このように良いところしかないように思えるRustが、なぜいまだにSolidityのシェアを逆転できないのでしょうか？

その最大の理由は、ひとえに「習得難易度の高さ」にあります。

SolidityはJavaScriptに近い構文を持ち、数日あれば「なんとなく」動くものが作れます。しかしRustは、プログラミング言語の中でもトップクラスに難解です。

試しに、記事冒頭で示したコードと同じ動きをするコントラクトをRustで実装してみると：

use anchor_lang::prelude::*;

declare_id!("TipJar111111111111111111111111111111111");

#[program]
pub mod digital_tip_jar {
    use super::*;

    pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
        let tip_jar = &mut ctx.accounts.tip_jar;
        tip_jar.owner = *ctx.accounts.owner.key;
        Ok(())
    }

    pub fn donate(ctx: Context<Donate>, amount: u64) -> Result<()> {
        let ix = anchor_lang::solana_program::system_instruction::transfer(
            &ctx.accounts.user.key(),
            &ctx.accounts.tip_jar.key(),
            amount,
        );
        anchor_lang::solana_program::program::invoke(
            &ix,
            &[ctx.accounts.user.to_account_info(), ctx.accounts.tip_jar.to_account_info()],
        )?;
        Ok(())
    }

    pub fn withdraw(ctx: Context<Withdraw>) -> Result<()> {
        let tip_jar = &ctx.accounts.tip_jar;
        let rent_balance = Rent::get()?.minimum_balance(tip_jar.to_account_info().data_len());
        let withdrawable = tip_jar.to_account_info().lamports() - rent_balance;
        
        **ctx.accounts.tip_jar.to_account_info().lamports.borrow_mut() -= withdrawable;
        **ctx.accounts.owner.to_account_info().lamports.borrow_mut() += withdrawable;
        Ok(())
    }
}

#[account]
pub struct TipJar {
    pub owner: Pubkey,
}

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(init, payer = owner, space = 8 + 32)]
    pub tip_jar: Account<'info, TipJar>,
    #[account(mut)]
    pub owner: Signer<'info>,
    pub system_program: Program<'info, System>,
}

#[derive(Accounts)]
pub struct Donate<'info> {
    #[account(mut)]
    pub tip_jar: Account<'info, TipJar>,
    #[account(mut)]
    pub user: Signer<'info>,
    pub system_program: Program<'info, System>,
}

#[derive(Accounts)]
pub struct Withdraw<'info> {
    #[account(mut, has_one = owner)]
    pub tip_jar: Account<'info, TipJar>,
    #[account(mut)]
    pub owner: Signer<'info>,
}
Code language: Rust (rust)

Rust版がこれほど複雑になるのは、並列処理を実現するための代償です。

Solidityには同時受付する窓口が一つしかないため、誰がどのデータを使っているか管理する必要がありませんでした。一方で、Rustは並列処理のため、どの処理がどのアカウントを触るのか、事前にすべて明示しなければなりません。

この難解さゆえに、Rustは極限のパフォーマンスを求める一部のプロトコルには喜ばれますが、一般的な開発者にとっては依然として高い壁となっています。

対してSolidityは、最近の研究で指摘されたような「コンパイラ自体の脆弱性」というリスクを孕みつつも 、その圧倒的な開発効率と、OpenZeppelinによる「安全なコピペ」文化によって、Web3のメインストリートを守り続けているのです。

ツールが生む好循環

Solidityが覇権を握り続ける最後の、そして最大の理由は、技術そのものではなく、その周囲に築き上げられた圧倒的なエコシステムの厚みにあります。

新しい言語に乗り換える際、開発者が最も絶望するのは「道具のなさ」です。しかし、Solidityには開発者のストレスを極限まで減らす強力な武器が揃っています。例えば：

  • Remix Project: ブラウザ上でスマートコントラクト開発を行えるIDE
  • Hardhat: JavaScript/TypeScriptベースでCI/CDが可能
  • Foundry: Rust製の超高速テストツール

特にFoundryは、Rustの速さ・安全性を享受しながら開発者が書くのはSolidityという、最高の美味しいとこ取りを実現します。これらのツールがあるからこそ、新人は迷わずSolidityを選び、プロはSolidityから離れられなくなるのです。

この記事のまとめ

Solidityは、Web3におけるJavaScriptです。

JavaScriptは、決して完璧な言語ではありません。その言語設計はひどく、数多の脆弱性や奇妙な挙動が指摘されてきました。しかし、ウェブブラウザの標準になったことで、誰もそこから逃げられなくなりました。そして、標準になったことで集まってきたデベロッパーがECMA標準などを通じて改善を繰り返し、TypeScriptやReScriptのような派生を生み、ReactやVue,NodeJSやDeno,Bunと、気がつけばWebブラウザの世界に留まらず、世界で最も使われる言語へと成長しました。

Solidityも全く同じ道を歩んでいます。 コンパイラには数多のバグが報告され、使いづらい部分も多くあります。しかし、それ以上に多くの開発者によって洗練され、OpenZeppelin,Hardhat,Foundryのようなツールを生み出し、EVMという枠組みを飛び越えて何兆円もの資産を動かし続けているのです。

Solidity Logo by Ethereum Foundation is licensed under CC BY 4.0

  1. DeFiLlamaによる。画像も同サイトから2026年2月6日時点のデータをキャプチャ。 https://defillama.com/languages ↩︎
  2. https://arxiv.org/html/2407.05981v3 ↩︎

Ryutaro Nakamura

Author

Ryutaro Nakamura

オランダ在住。プログラマ、データアナリスト。数千万件規模の行動ログに基づき、集団内における個人の相対的立ち位置をリアルタイムに算出する統計エンジンを開発。 ソフトウェア開発のさなかWeb3の行く末に興味を持ち、技術構造と経済圏に対する独自リサーチを展開。

分析を探索

テーマから探す

トークンから探す

Ethereum Render Network(RENDER) The Graph(GRT)