日本語

ホワイトペーパー

概要

Vela は、Ethereum とその他の EVM ネットワーク向けのセルフカストディ型スマートコントラクトウォレットです。各ウォレットは改変していない Safe v1.4.1 のアカウントで、ERC-4337 を通じて動作し、最大 7 本のパスキーで管理されます。パスキーは、端末、パスワードマネージャー、またはハードウェアセキュリティキーが保持する WebAuthn の P-256 鍵です。シードフレーズはありません。

会社としての Vela があなたの鍵を持つことはなく、あなたの Safe に対する権限もないため、Vela は単独ではあなたの資金を動かすことも、凍結することも、差し押さえることもできません。ただし、あなたの鍵に署名を求めるソフトウェアを書き、配信しているのは Vela です。だからこそ、後述の脅威モデルが重要になります。アプリ、取引を送信するリレー、それを支えるサービスはオープンソースで、どれも自分でコピーを動かせます。要するに、信頼するのは次のものです。コントラクト、鍵を保持する認証器、署名に使うアプリのコード、パスキーが属するドメイン、そしてアプリの接続先にしたサービスです。

Vela が存在する理由

  • シードフレーズのウォレットは、すべてのユーザーに 12〜24 語の秘密を突きつけます。単一障害点であり、常にフィッシングの標的です。
  • カストディ型ウォレットは、資金を預かることでシードフレーズをなくします。
  • 1 社のサーバーと非公開のコードに依存するパスキーウォレットは、シードフレーズをなくしますが、その会社がなくなれば、あなたは取り残されます。
  • ブラインド署名（読めない不透明なデータを承認すること）はいまもよく見られ、ウォレットから資金を抜かれる経路のひとつです。

Vela が目指すのは、こうした依存を一切持たずに、パスキーの便利さを得ることです。標準のアカウント、公開されたコード、差し替えられるサービス、そして署名の前に読める取引です。

設計の原則

  1. 例外のないセルフカストディ。鍵は認証器が作成し、保持します。Vela のサービスが鍵を目にすることはありません。サービスが何を目にするかは「プライバシー」に挙げています。
  2. 改変しない標準のコントラクト。資金に至る経路上に、Vela が書いたコントラクトはひとつもありません。
  3. 信頼ではなく検証。アプリとサービスは公開されており、サービスはセルフホストできます。
  4. 署名の前にデコード。デコードできないものには、ブラインド署名であることを明示する警告を付けます。
  5. 多くを抱えない。ウォレットがするのは、送金、受け取り、そしてあなたが選んだ dApp のための署名です。

アーキテクチャ

Vela のアプリ — ウェブ、ブラウザ拡張、デスクトップ（macOS/Windows/Linux）、iOS、Android
  共通の Rust コア（ルール、暗号、ABI、クリア署名）+ 各プラットフォームのネイティブシェル
  • UserOperation を組み立て、それが何をするかを表示する
  • 鍵に WebAuthn のアサーションを求める
        │  署名済みの UserOperation（手数料込み）
        ▼
リレー（vela-relay、セルフホスト可能）
  • 手数料を見積もり、ガス代を立て替え、handleOps を送信する
  • 操作を書き換えることはできない
        ▼
EVM チェーン
  EntryPoint v0.7 → あなたの Safe v1.4.1 → Safe 4337 モジュール
  Safe のパスキーモジュールが EIP-7951 / RIP-7212 プリコンパイルで P-256 署名を検証

それを支えるサービスは、すべてオープンソースです。新しいウォレットをオンチェーンのレジストリに登録し、検索に答える公開鍵インデックス、チェーンデータのディレクトリ、そして為替レートの配信です。セルフホスティングガイドを参照してください。

アカウント

ウォレットは Safe v1.4.1 のプロキシ（SafeL2 シングルトン）で、Safe の 4337 モジュール v0.3.0 がモジュール兼フォールバックハンドラーとして有効になっており、EntryPoint v0.7 を通じて動作します。所有者は Safe のパスキーモジュール v0.2.1 の署名器です。最初の鍵は共有署名器が検証し、追加の鍵はそれぞれ、Safe のファクトリーが作成した専用の署名器コントラクトが検証します。しきい値は 1 です。

アドレスは決定論的で、カウンターファクチュアルです。すべての最初の鍵を含む Safe のセットアップデータから、何もデプロイされる前に CREATE2 で計算されます。どのネットワークでも同じアドレスです。すぐに受け取ることができ、各ネットワークでの最初の取引がウォレットをデプロイし、その費用はその取引の手数料に含まれます。

鍵

ウォレットの鍵は 1〜7 本で、作成時に確定します。どれか 1 本だけで署名できます（1-of-n）。鍵にできるのは次のものです。

  • いま使っている端末のパスキー。あなたが許可すれば、iCloud キーチェーン、Google パスワードマネージャー、またはほかのパスワードマネージャーが同期します。
  • QR コードを読み取ってつなぐ別のスマートフォン（WebAuthn の hybrid トランスポート）。
  • USB または NFC でつなぐハードウェアセキュリティキー。どこにも同期されません。

署名には毎回、認証器自身による本人確認（生体認証か端末のパスコード、またはセキュリティキーの PIN とタッチ）が必要です。セッション鍵はありません。鍵はあとから追加・削除・交換できません。ウォレットがまだデプロイされていないすべてのチェーンでは、アドレスが最初の鍵の組を表したままなので、あるチェーンで所有者を変えると、アカウントの中身がチェーンごとに食い違ってしまうからです。

パスキーはリライングパーティーに属します。Vela のパスキーは getvela.app のために作られています。ブラウザがそれを提示するのは getvela.app とそのサブドメイン上のページだけで、それがフィッシングへの耐性を生んでいます。同時にこれは依存でもあり、このあとで改めて取り上げます。

署名の流れ

  1. 組み立てる：あなたの Safe のための UserOperation（リレーへの支払いの送金を含む）を組み立て、シミュレーションします。
  2. デコードする：人が読める意図にデコードし、あなたに表示します。
  3. 署名する：認証器があなたを確認したうえで、操作のハッシュに対する WebAuthn のアサーションを生成します。
  4. エンコードする：アサーションを、パスキーモジュールが期待する Safe の署名の形式にエンコードします。
  5. 送信する：署名済みの操作をリレーに送り、リレーが EntryPoint を呼び出します。
  6. オンチェーンで検証する：Safe が何かを実行する前に、パスキーモジュールが EIP-7951 / RIP-7212 プリコンパイルで P-256 署名を確認します。代わりの検証器はなく、プリコンパイルのないネットワークは追加できません。

手数料

  • リレーへの支払いはインバンドです。操作の EntryPoint への手数料はゼロとし、あなたの Safe からリレーのアドレスへの送金を含めます。金額と支払先はあなたが署名する内容に含まれるので、払うのは確認画面に表示された額ちょうどです。
  • 手数料は、ウォレットがその操作のために確保するガスの 3 倍（シミュレーションの見積もりを 1.5 倍にし、下限を設けたもの）で、ウォレット自身が読み取ったガス価格と、選んだ速度に対するリレーの提示価格のうち、高いほうで計算します。最低額は約 0.01 ドルです。Tempo では倍率が 2 です。確保量と価格の両方に余裕を持たせているため、手数料は操作の実際のオンチェーン費用を上回り、ネットワークでの最初の取引ではその差がさらに大きくなります。差額はリレーが受け取ります。正確な金額は、署名の前に確認画面に表示されます。
  • 手数料は、ウォレットに設定されているリレーに支払われます。既定では Vela のリレーですが、自分で動かすものも含め、どの vela-relay のデプロイメントでも構いません。
  • 手数料は、ネットワークのコインか、リレーが受け付ける米ドル建てのステーブルコインで払います（ネイティブコインのない Tempo では pathUSD）。ペイマスターはありません。誰もガス代を肩代わりせず、スポンサーの方針で取引をふるいにかけられる人もいません。
  • あるネットワークでリレー自身のガスのトレジャリーが空になると、ウォレットは署名の前にそれを知らせます。ユーザーごとのデポジットはありません。

詳しくはネットワークと手数料。

クリア署名

呼び出しと EIP-712 のメッセージは ERC-7730 のディスクリプターでデコードします。よく使われるコントラクトのものはアプリに内蔵し、それ以外はチェーンデータのサービスから取得するか、トークン標準の形に照らし合わせます。最後の手段として、公開のセレクターデータベースを使い、ベストエフォートと表示します。それでも残ったものには、ブラインド署名であることを明示する警告を付けます。取得したディスクリプターが検証済みと表示されることはありません。その言葉に値するのは、アプリに内蔵されたものか、それと完全に一致する取得結果だけです。「無制限」レベル（2^200 以上）のオンチェーン承認は赤で表示され、上限を設定できます。上限を設けなければ、dApp が組み立てたとおりの内容で送信されます。大きいが有限の額の承認には注意が表示されます。署名による許可には上限を設けられないため、求められたとおりに署名するか、拒否するかのどちらかです。詳しくはクリア署名。

ネットワーク

Vela には 24 のネットワークが内蔵されています。Ethereum、BNB Chain、Polygon、Arbitrum、Optimism、Base、Avalanche、Gnosis、Unichain、Tempo、Monad、World Chain、Arc、X Layer、Stable、Soneium、MegaETH、Robinhood Chain、Mantle、Kaia、Celo、Ink、Plume、XRPL EVM です。さらに、Vela が確認する 12 のコントラクトと EIP-7951 / RIP-7212 プリコンパイルを備えた EVM ネットワークなら、どれでも追加できます。12 のうち 2 つは Safe のパスキー署名器ファクトリーと、それがデプロイする署名器のコードで、鍵を 2 本以上持つウォレットにしか必要ありません。確認はこの 2 つを分けて報告します。

セキュリティモデル

Vela にできないこと

  • 単独で資金を動かす、使う、凍結すること。あなたの Safe を承認できるのはあなたの鍵だけで、Vela はそこに何の権限も持ちません。（Vela にできるのは、あなたに署名を求めるソフトウェアを配信することです。後述の脅威を参照してください。）
  • 署名後に取引を書き換えること。どこかを変えれば署名が無効になります。
  • 秘密鍵を読むこと。秘密鍵は認証器の中にとどまります。
  • あなたのウォレットに鍵を追加すること、または削除すること。

「凍結できない」が及ばないもの：トークン。USDC、USDT をはじめ、法定通貨を裏付けとするトークンの多くは、発行者がどのアドレスでも（あなたのアドレスでも）ブラックリストに載せられるようにしています。この権限は発行者のものであり、どのウォレットを使っても存在します。セルフカストディで得られるのは、Vela がその権限を持つ 2 人目の当事者にはならない、ということです。

信頼するもの

  • コントラクト：Safe、その 4337 モジュールとパスキーモジュール、EntryPoint v0.7、そしてチェーンの EIP-7951 / RIP-7212 プリコンパイル。
  • ドメイン：getvela.app やそのサブドメインから配信されるページはどれも、あなたの鍵に署名を求められます。
  • 鍵を保持する認証器と、同期されるパスキーについては、その裏にある Apple、Google、パスワードマネージャーのアカウント。
  • 署名に使うアプリのコード。取引を組み立て、それが何をするのかを表示するのはアプリです。侵害されたアプリは、あるものを見せて、別のものへの署名を求めることができます。認証器の確認画面では、その違いはわかりません。
  • 読み取りに使う RPC エンドポイント：嘘をつくノードは、間違った残高やシミュレーションの結果を表示させることができます。自分のエンドポイントを設定できます。
  • チェーンデータと為替レートのサービス：トークンの一覧、ディスクリプター、手数料に使えるトークンの一覧、そして法定通貨での金額をトークンの量に換算するためのレートを提供します。
  • リレー：あなたが署名した内容は変えられませんが、遅らせることや断ること、いつ取り込まれるかを選ぶこと（そのため、スリッページの範囲内でスワップをフロントランニングすることも可能です）、そして手数料の基準になるガス価格を、ウォレット自身の読み取り値の 3 倍まで設定することはできます。

想定している脅威

  • 端末の紛失や盗難 —— 盗んだ人も、認証器の確認を通過する必要があります。別の鍵があればアクセスを取り戻せます。ただし鍵は削除できません。鍵のどれかが他人の手に渡ったかもしれないときは、資金を新しいウォレットに移してください。古いアドレスは、どのネットワークでもその鍵で資金を動かせるままだからです。
  • フィッシング —— パスキーは偽サイトに打ち込めず、ブラウザは getvela.app とそのサブドメイン上のページにしかパスキーを提示しません。
  • 悪意のある dApp —— クリア署名、承認のガード、そして拒否で対処します。あなたの Safe から Safe 自身への呼び出しの要求 —— enableModule、addOwnerWithThreshold、swapOwner、setFallbackHandler、setGuard とその仲間 —— はブロックされます。バッチや MultiSend の中にあっても同じで、delegatecall を含む要素や SafeTx の型付きデータへの署名も同様です。そのどれかに一度署名すれば、Bybit の攻撃と同じくらい完全にアカウントを明け渡すことになるので、ウォレットはそもそもそれらを署名の対象として出しません。
  • バックエンドのサービスの侵害（リレー、インデックス、チェーンデータ、為替レート） —— 署名する力はありませんが、実際の影響力はあります。サービスの拒否、誤解を招くディスクリプターやトークンの一覧、法定通貨での金額に対して実際に送られる量を変えてしまう誤った為替レート、そして（リレーの場合）上に挙げたタイミングとガス価格です。チェーンデータサービスから取得した説明が検証済みと呼ばれることはありません。その言葉に値するのは、アプリに組み込まれたものか、それと完全に一致する取得結果だけで、それ以外には、何もそれを認証していないという一行が添えられます。どのサービスも差し替えられます。
  • アプリの配信経路の侵害 —— 改ざんされたウェブのデプロイ、拡張機能のアップデート、アプリのビルドは、悪意のある取引をあなたに署名させようとすることがあります。これが Bybit の種類の攻撃です。現時点の緩和策は限られています。アプリ自体のデコードと承認のガード、公証済みの macOS ビルド、そして拡張機能やアプリを自分でソースからビルドすることです（リリースパッケージには SHA-256 のチェックサムと、コミットとワークフローの実行を示す GitHub のビルド来歴証明が付きます。Windows のインストーラーは依然としてコード署名されていません）。アプリとコードを共有しない独立した署名ページである Trusted Signer は、デスクトップ、iPhone、Android のアプリで署名の方法として選べます。デスクトップの整合性の確認は、一致しないページをログに記録するだけで、スマートフォンのアプリはまだ確認をしていません。
  • ドメインから配信されるあらゆるもの —— getvela.app やそのサブドメイン上のページは、そこで読み込まれるスクリプトも含めて、どれも Vela のパスキーに署名を求めることができ、確認画面に表示されるのは「getvela.app」だけです。そのためウェブサイトは、自分のページがパスキーを使うことを禁止し、鍵を保持するページにはアナリティクスのスクリプトを載せていません。ドメインの持ち主が変われば、新しい持ち主が、どのアプリにパスキーを使わせるかも決められるようになります。拡張機能と自分でビルドしたアプリは自分のコードを内蔵していますが、既定では、ディスクリプターの取得やサービスの利用には、いまも getvela.app 配下のものを使います。

復旧

ウォレットを作成すると、その公開鍵とアドレスが Gnosis 上の公開レジストリコントラクトに登録されます（Ethereum にコピーすることもできます）。新しい端末では、鍵のどれか 1 本でサインインします。アプリはインデックスを通じて、それができなければレジストリから直接ウォレットを見つけ、鍵の組から記録どおりのアドレスが計算されることを確認します。鍵が 1 本のウォレットなら、レジストリをまったく使わずに、署名 2 つから再構築することもできます。

詳しくは復旧とサインイン。

Vela がなくなったら

資金はオンチェーンのあなたの Safe に残ります。コントラクトは Vela に依存しておらず、Vela が動かしているサービスはすべてオープンソースで、ほかの誰かが動かせます。動かせない唯一のものは、パスキーのリライングパーティーである getvela.app です。ウェブウォレットのコピーを別のドメインで動かせば、別のウォレットが作られます。既存のウォレットについては、Vela のブラウザ拡張（アクセス権によって getvela.app のパスキーを使えます）と、自分でビルドしたアプリ（スマートフォンかセキュリティキーで）が、getvela.app なしでも使い続けられます。それぞれの方法とその限界は、セルフホスティングガイドで詳しく説明しています。あるチェーンで Vela から独立してウォレットを使うには、そのチェーンが EIP-7951 / RIP-7212 に対応している必要もあります。

プライバシー

アカウント登録も、メールアドレスも、本人確認（KYC）もありません。公開されるのは、ウォレットの作成時にレジストリに書き込まれる内容です。各鍵の公開鍵とクレデンシャル ID、認証器の機種、ウォレット名と鍵の名前、アドレス、そして署名済みの登録データです。Vela のインデックスは、送信する前にその記録を目にし、あなたが名前を調べたアドレスも目にします。Vela のリレーは、あなたのアドレス、あなたが送信した操作、アプリが使っている RPC エンドポイント（URL に含まれる API キーも含む）を目にし、再試行と原因調査のために、操作を一定期間保存します。どのサービスも、あなたの IP アドレスを目にします。ウェブサイトは Cookie を使わないアナリティクスを使っています。正式な一覧はプライバシーポリシーです。

オープンソース

ウォレット（すべてのアプリとコア）、リレー、公開鍵インデックス、為替レートのサービス、チェーンデータのディレクトリは、すべて MIT ライセンスです。コードは github.com/mondaylabsltd にあります。

トークンはありません

Vela にトークンはなく、発行する予定もありません。買うものも、ファーミングするものも、投機の対象もありません。手数料は、各ネットワークのコインかステーブルコインで払います。

監査の状況と限界

Safe のコントラクト、その 4337 モジュールとパスキーモジュール、そして EntryPoint v0.7 は、独立した監査を受けており、広く使われています。Vela 自身のコード（アプリ、バックエンドのサービス、レジストリコントラクト）は、独立した第三者による監査を受けておらず、その予定もありません。専門家による監査は、プロジェクトが費用を賄えるようになったときの目標であり、日付の決まった約束ではありません。それまでのレビューは非公式なものです。コードは公開されており、力のあるコミュニティのメンバーが読み、AI ツールでもレビューしています。それは助けにはなりますが、専門家による監査と同等ではありません。Vela はアルファ版のソフトウェアとして扱ってください。詳しくは監査と既知の問題。

参考資料

  • ERC-4337 —— EntryPoint によるアカウント抽象化
  • EIP-1271 —— コントラクトの署名検証
  • ERC-7730 —— クリア署名のディスクリプター
  • EIP-5792 —— ウォレットの呼び出しのバッチ化（wallet_sendCalls）
  • EIP-7951 / RIP-7212 —— P-256 署名検証のプリコンパイル
  • WebAuthn / FIDO2 —— パスキー
  • Safe smart account v1.4.1
GitHub でこのページを編集