2024 年 7 月 18 日、SSP Wallet v1.6.0 は Ethereum を追加し、SSP は ERC-4337 Account Abstraction を用いて Ethereum 上に真の Schnorr-multisig アカウントを出荷した最初のウォレットとなりました。他のウォレットは、外部所有アカウントを 1 つだけ UI の裏に積み上げて自らを「Ethereum multisig」と称しています。SSP は難しい道を選び、SSP 内で Bitcoin を守っているのと同じ 2-of-2 モデルが、いまや ETH も守るようにしました。
TL;DR
- Ethereum(ETH)が一級チェーンとして SSP に加わります。
- アカウントは EOA ではなく ERC-4337 に従うスマートコントラクトで、2-of-2 の強制はオンチェーンで生きます。
- 2 つの Schnorr 署名は Ethereum に到達する前に 1 つに集約され、ガスを予測可能に保ちます。
- 署名ライブラリは npm でオープンソース:
@runonflux/aa-schnorr-multisig-sdk。 - ERC-20 トークン対応が次の一手で、本リリースは ETH 自体と、その下の AA 基盤を届けます。
何が着地したか:Ethereum 対応、ただし難しいやり方で
ほとんどのウォレットは、外部所有アカウント(EOA)を生成することで「Ethereum を対応」しています — 単一の秘密鍵、単一の署名、単一の故障点。その上に multisig を載せても、たいていはウォレット側のソフトウェア方針であって、チェーン上で強制されるルールではありません。チェーンは依然として 1 本の鍵を見ているだけで、それを持つ者は単独で資金を動かせます。
SSP はその近道を断りました。SSP の 2-of-2 モデルの要は、デスクトップの SSP Wallet も、スマートフォンの SSP Key も、単独では資金を動かせないということです — 共同署名は UI の約束事ではなく、アカウントの性質です。これを Ethereum 上で保つには、EOA では決して足りませんでした。Ethereum アカウントは、構造上 2 つの署名を要求するスマートコントラクトでなければならなかったのです。v1.6.0 で出荷されたのは、まさにそれです。
ここで Schnorr multisig が意味するもの
Bitcoin の UTXO スクリプトは 2-of-2 をネイティブに表現できます — 既存の SSP チェーンが共同署名を強制しているのはそのおかげです。Ethereum のアカウントモデルは、それを助けなしには行えません。SSP はそのギャップを Schnorr 署名で埋めます。
Schnorr はある重要な性質を持つ署名方式です:2 名の署名者がそれぞれ部分署名を生成でき、それらの部分を 1 つの有効な署名に合成して、集約された 1 つの公開鍵の下で検証できるのです。チェーンを読む者から見れば、1 人の署名者が 1 度署名したように見えます。SSP にとっては、2 つのデバイスが合意しなければなりません。暗号学的な深度 — 鍵の集約、ノンスの調整、MuSig2 風のラウンド — は、必要であればアカデミーの記事 Schnorr 署名と multisig の集約 で扱っています。ユーザー側の要約は短く、あなたが既に使っているのと同じ SSP Wallet + SSP Key のハンドシェイクが、いまや Ethereum 上で集約された 1 つの Schnorr 署名として表現される、ということです。
ERC-4337 Account Abstraction
Account Abstraction(AA)は、Ethereum アカウントを単なる鍵ペアではなく、プログラム可能なウォレットのように振る舞わせるための包括的な用語です。標準的な Ethereum モデルにはアカウントが 2 種類あります:単一の秘密鍵で制御される EOA と、自分から取引を開始できないコントラクトです。AA はその区別をアプリケーション層で解消します。
ERC-4337 は、Ethereum 自体を変えずに AA を届ける Ethereum 標準です。ハードフォークの代わりに、より高位のトランザクションオブジェクトである UserOperation、それを通常の Ethereum トランザクションに変換する bundler、それらを検証する EntryPoint コントラクトを定義します。あなたの「アカウント」は、どう支出を認証したいかを自分で決めるスマートコントラクトです — SSP にとってその認証ルールは、SSP Wallet と SSP Key からの集約された Schnorr 署名以外は受け付けない、というものです。L1 のハードフォーク不要、特別なノード運用者不要、メインネットに既にデプロイされているもの以外の信頼仮定もありません。
オープンソースのライブラリ
Schnorr-multisig の署名層は SSP アプリの内部に埋もれていません。私たちはそれを再利用可能なライブラリとして切り出し、SSP の他の部分と同じオープンソースの姿勢で公開しました。TypeScript SDK は npm に @runonflux/aa-schnorr-multisig-sdk として、対応する Solidity の Account Abstraction コントラクトは GitHub の @runonflux/account-abstraction リポジトリ にあります。
あなたがウォレット開発者、セキュリティ研究者、あるいは Schnorr-multisig AA が Ethereum 上で実際にどのように組み上がるのかに興味があるなら、両プロジェクトとも読み、フォークし、改善を寄せ返すために存在しています。Pull Request と Issue を歓迎します — このプリミティブを欲しがるすべてのウォレットに毎回車輪を再発明させるより、より多くの目に晒される 1 つの共有ライブラリを鍛え上げる方が良いからです。
これが解放するもの
v1.6.0 に限れば、提供されるチェーンは Ethereum そのもの — ETH の残高、ETH の送金、他のすべてのコインで使うのと同じ Chains パネルのトグルが、いまや背後に AA アカウントを伴って動きます。本リリースが敷設した配管こそが、難しい方の部分です。2-of-2 Schnorr AA アカウントが存在して動く以上、Ethereum 形状のあらゆる残高が到達可能になります。
ERC-20 トークン対応は自然な次の一歩で、ロードマップに既に乗っています — リリース時には独立した newsroom 記事で扱います。今日の見出しはこうです:Ethereum は SSP の中にあり、正しいやり方で SSP の中にあり、その下にある暗号学とスマートコントラクトの基盤は npm と GitHub に公開されたオープンソースであり、誰でも検証できる、と。