ビットコイン上で複雑なコントラクトを書くことは、これまでほぼ不可能でした。Bitcoin Scriptには制約があり、主要な代替手段を使うにはチェーンそのものから離れる必要があります。Simplicityは、まさにこの隔たりを埋めるために構築されたプログラミング言語です。2025年7月からLiquid Mainnetで稼働しており、開発者向けの環境も着実に提供されています。

開発者が現在利用できるものと、今後提供予定のものをご紹介します。

すぐに使える開発環境

以前はSimplicityコントラクトのツールチェーンを使うために、ローカル環境を一から設定する必要がありました。現在は、GitHub Codespaceとローカル用のVSCode devcontainerを利用できます。どちらにもSimplicityHLコンパイラー、Simplicity SDK、コントラクト例のライブラリが含まれています。

この環境にはlanguage serverも組み合わされており、Simplicityコントラクトから呼び出すコンパイル済みネイティブ演算であるSimplicityHL jetsの自動補完とホバー表示ドキュメントを利用できます。従来Simplicity開発の初期段階を占めていた煩雑さが解消されました。

SimplicityHL v0.7.0：モジュール化された保守しやすいコード

SimplicityHLは開発者が記述するRust風の高水準言語で、コンパイルされたbytecodeはfull node上で実行されます。最新版v0.7.0では、現代的なシステム言語に期待される機能がさらに整いました。

ネイティブのmodule対応により、コントラクトロジックを複数ファイルへ分割し、必要なものだけをimportできます。コンパイラーはbytecode生成前に入れ子の式を平坦化するため、コンパイル済みプログラムを監査しやすくなります。診断機能も刷新され、下流で現れる結果ではなく、失敗の原因となった正確な構文箇所を示します。

本格的なSimplicityコントラクトを開発する場合、単一ファイルの例から複数moduleのコードベースまで無理なく拡張できる初のSimplicityHLリリースです。

Simplicity SDKのSmplx v0.0.8で信頼性の高いローカルテスト

Simplicity SDKは、live networkへ接続する前にコントラクトを実行、検証、ステップ実行できるローカルテスト環境です。v0.0.8ではCLIを改善し、コントラクト実行に関するedge caseのバグをまとめて修正しました。変更のたびにregtest nodeを起動せず、「記述、コンパイル、テスト、反復」という予測可能なローカルループを実現します。

Blockstream自身も、開発者へ提供するものと同じstackを使用しています。Simplicity上で構築中の世界初のビットコイン担保融資アプリケーションでも、開発者と同じ検証をSimplicity SDKで行っています。

Liquid Mainnetで稼働する耐量子署名

2026年3月3日、Blockstream ResearchはLiquid Mainnetで初の耐量子署名トランザクションを実行しました。使用した署名方式は、eprint 2025/2203で解説されているハッシュベース設計のSHRINCS（Stateful Hash-based Reduced-size Incremental CoSign Scheme）です。SHRINCSの初回署名は324バイトと小さく、stateful modeでは同じ鍵による2回目以降の署名が1回につき約16バイト増加します。Simplicity検証プログラムを含むトランザクション全体は約38KBですが、将来ネイティブopcodeを導入すれば、このoverheadを除去できます。

開発者にとって特に重要なのは、ネットワーク全体のconsensus変更なしに、SHRINCSをSimplicityコントラクトとしてLiquidへ導入できたことです。Simplicityは標準的なコントラクトとして耐量子署名方式を検証できる表現力を備えています。暗号学的仮定は、ビットコインがProof of Work、アドレス導出、Merkle treeですでに利用するSHA-256の安全性だけで、新たな暗号primitiveは導入していません。

Liquidで新しい暗号機能を提供するために、開発者がconsensus forkを何年も待つ必要はありません。Simplicityのprogram budgetに収まるprimitiveであれば導入できます。

確定した融資アーキテクチャと成長するエコシステム

Lending v2アプリケーションのコントラクトコードが確定しました。Liquid上で融資・信用アプリケーションを構築する開発者は、テスト済みのtemplateを参考にできます。

Blockstream以外のエコシステムでも開発が進んでいます。SideSwap、Resolvr、独立開発者が、金融ロジックの中核にSimplicityを利用しています。最近のhackathonでは参加者が増えており、Turinのイベントは過去最多のSimplicity参加者を集めました。

今後の予定

Fuzz testingによるセキュリティ自動化

Blockstream Researchは、Simplicity専用のfuzz testing frameworkを開発しています。提供後はMainnetへ展開する前に、数百万件の自動生成されたランダム入力をコントラクトへ与えられます。Fuzzingは、高水準開発とSimplicity stackが基盤として備える数学的証明をつなぐ実用的な橋渡しであり、慎重なcode reviewでも見逃し得るedge caseを検出します。

現在も開発中で、リリース時期は確定していません。

標準化されたウォレットインターフェース

ウォレットとコントラクトアプリケーションをつなぐブラウザ拡張機能は壊れやすいものです。今後のElements Library Improvement Proposal（ELIP）では、この拡張機能層を、安全なWebSocket接続を使う標準ウォレットインターフェースへ置き換えます。

設計の中心はユーザーによる管理です。Simplicityコントラクトと共有する公開鍵はユーザーの管理下に置かれ、重要なウォレットデータはローカルに残ります。アプリケーションが誤って秘密情報を読み取ったり漏えいしたりすることはありません。Wallet ABI ELIPと関連するWallet RPC仕様を並行して開発しており、開発ツールがLiquid・ビットコインエコシステムのSimplicityコントラクトと通信する方法を定義します。Liquid Wallet Kit（LWK）へのネイティブ統合と、LWK-Jadeによるハードウェア保護も同じ取り組みに含まれます。

開発者は、ウォレットベンダーごとの個別統合ではなく、複数ウォレットで共通する単一のinterface仕様を利用できます。

Contract Registry、tx-manifest.json、人が読める署名リクエスト

コントラクト操作で最も危険なのは署名の瞬間です。ウォレットが生のbytecodeだけを表示する場合、ユーザーは内容を確認できないまま署名します。EthereumのERC-7730 clear-signing標準を参考にしたContract Registryでは、コンパイル済みSimplicity bytecodeとCommitment Merkle Root（CMR）を対応付けます。これにより、監査済みで改変されていないコントラクトtemplateを操作しているか、ウォレットがリアルタイムに検証できます。

関連するtx-manifest.jsonにより、コントラクトの動作を平易な言葉で記述できます。16進数の塊よりも、「35,000 USDTを借りるため1 LBTCをロック」と表示される方が明確です。詳細を確認したい監査人向けには「View Source」も残ります。

ウォレットはコントラクトのライフサイクル（Fund > Active > Liquidate > Claim）も追跡します。数週間または数カ月にわたり動作するコントラクトでも、直感的なinterfaceを構築する基盤になります。同じpatternは、ユーザーが承認内容を明確に把握する必要があるNFTなど、金融以外のassetにも応用できます。

Simplicityで開発を始める

原文：Building on Simplicity: What Ships Today, What's Coming Next