Helius、オペレーターへの信頼を残したままSolanaの送金を暗号化してメインネットで開始

Heliusは11月10日、SolanaメインネットでパーミッションレスなPrivacy Ringを稼働させ、送金者と受取人のウォレットアドレスは見える状態のまま、支払いの資産と金額を暗号化した。同システムの文書化されたデフォルトのプルーバー（ゼロ知識証明を構築するサービス）はハードウェア要件を追加しており、機密性の高い取引入力はアテステーション済みのAWS Nitroエンクレーブ（隔離されたコンピューティング環境）内で処理される。

Solanaの台帳は公開されており記録された送金は誰でも観測できるため、資産と金額の暗号化は、両側のアドレスが見える状態を保ちながらも、支払いにおいて最も直接的に機密性の高いフィールドに対応するものとなる。

Solanaは送金がプロトコルのルールを満たしていることを検証できるが、証明の生成中に入力を保護できるかは、プルーバーの分離性、そのコード、そしてデプロイポリシーに依存する。

証明サービスに渡る情報は何か

このローンチを組み込むウォレット開発者にとっての現実的な問題は、こうした保護のうちどれを自社のソフトウェアが実際に検証できるかである。ローカル復号か委任復号か、リモート証明かクライアントサイド証明かという選択が、取引のどの部分を他者に委ねるかを決める。

Heliusのウォレット統合ガイドは、証明の生成に完全な取引データとヌリファイアキーをカバーする平文の入力が必要であると述べ、アテステーション済みのAWS NitroエンクレーブをSDKのデフォルトのプルーバーとして明示している。

プロトコル仕様には、支出対象のノートに関する資産・金額・ブラインディング値・ヌリファイアシークレットといったプライベート入力と、それらのノートがステートツリーに属することを証明するパスが列挙されている。証明には出力の資産・金額・ブラインディング値も組み込まれる。

これらの入力はエンクレーブ内の証明コードから読み取り可能となる。文書化されたクライアントは、リクエストをアテステーション済みエンクレーブが保持する鍵で暗号化することにより、ホストオペレーターからそれらを守る。ヌリファイアシークレットは、再支出を防ぐためのマーカーの生成にも使われる。

ネイティブのウォレット統合では、署名鍵はウォレット側が保持し、TypeScript SDKは完成したSolanaトランザクションの署名をアプリケーションのサイナーに委ねる。Heliusは2つの復号モードを文書化している。閲覧鍵をデバイス上に保持するローカル復号と、閲覧鍵を認可されたプロバイダーと共有する委任復号である。委任により、そのプロバイダーは残高と履歴への読み取りアクセスを得るが、支出権限は付与されない。

エンクレーブモデルの仕組み

AWSはNitro Enclavesを、親インスタンスのプロセスや管理者からもメモリにアクセスできない隔離環境であると説明している。エンクレーブには永続ストレージ、対話アクセス、外部ネットワーキングはない。AWSの署名付きアテステーションドキュメントには、エンクレーブのイメージとソフトウェアの暗号学的フィンガープリントが含まれる。

証明の構築はプライベート入力が平文で存在する工程であるため、プルーバーの環境こそが、エンクレーブ設計が保護を集中させる場所となっている。

文書化されたPrivacy Ringsのチェックは、証明書チェーン、チャレンジレスポンスと鮮度、承認済み測定値、リクエスト暗号化鍵のバインディングを検証する。対象のSDKは、アテステーションなしのリモートプルーバーリクエストを、HTTP呼び出しの前に拒否する。ウォレットはレビュー済みのリリースポリシーをピン留めするか、SDKがピン留めした署名者によって認証されたネットワークポリシーを採用できる。署名付きポリシーはアテステーション中に更新され、使用後に失効する。

信頼が依然残る部分

ウォレットは、エンクレーブが承認済みのソフトウェアイメージと暗号化鍵に一致することを自動的に確認できる。しかし、どのイメージを承認するかの判断には、依然としてコードとそのレビュアーへの信頼が必要である。

Nitroデプロイガイドによると、測定対象のイメージにはプルーバー、起動スクリプト、証明書バンドル、許可された外部ホスト、インデクサーURL、KMS鍵IDが含まれる。この設計はAWS Key Management Serviceを使用し、共有される暗号化シードを、一致するアテステーションを持つエンクレーブにのみ解放する。クライアントはKMSの鍵ポリシーを読むことができず、その保証についてはオペレーターのデプロイに依存するとガイドは記している。同ガイドは、初期ポリシーバインディングにおける信頼のルートとして、AWS KMS、AWS Support、Nitroハードウェア、およびオペレーターを挙げている。

正しく暗号化されたリクエストであっても、パス、クエリ、タイミング、サイズといったメタデータは親インスタンスから見える状態が残る。パスからは証明の回路構造が明らかになる。

バージョン管理されたTEEガイドは、測定ビルドの来歴を持つ、v0.6.0-alphaベースのメインネットビルドを記録しており、これはts-sdk-v0.8.0-alphaのドキュメントタグとは異なる。仕様はクライアントサイド証明を許容しており、リポジトリはlocalnetツールとダウンロード可能なプルーバーバイナリを提供している。

Heliusのローンチ発表によると、Certora、zkSecurity、OtterSecがプログラムと回路を監査した。セキュリティページでは、Certoraの監査が10月、zkSecurityの監査が8月と記載され、OtterSecの報告書は保留中とされている。このローンチを評価するチームにとって、注視すべき文書化された項目は、保留中のOtterSec報告書、v0.6.0-alphaのメインネットビルドとts-sdk-v0.8.0-alphaドキュメントタグの間の差異、そして統合がピン留めされたリリースポリシー、ネットワークポリシー、仕様のクライアントサイド証明オプションのどれを採用するかである。

このローンチは、証明の入力を扱うためにどのコードとどのデプロイポリシーを承認するかという信頼の判断を、ウォレット開発者に委ねている。

出典：CryptoNewsNet | 原典：CryptoSlate