Vitalikは暗号通貨ウェブサイトなしでプライベートイーサリアム支払いを行っている

受け入れられたコードは支払い指示とそれを承認する署名の間にあるため、ダウンロードされたインターフェイスの制御は重要です。コードをいつ変更するかを選択することで、繰り返し発生する危険性を 1 つ減らすことができますが、その依存関係と署名アクセスにより、インストールされたソフトウェアが実行できる内容が決まります。

コピーを保持すると配送の決定が変わります

実際の利点は、Web サイトにアクセスするたびに Web サイトのインターフェイスを再度取得するのではなく、選択したアプリケーションのリビジョンを保持できることです。代替リビジョンを受け入れると、別の納品決定が作成されます。このソース-ビルドルートの場合、その決定には依存関係セットと、ソースを実行可能なソフトウェアに変換するツールも含まれます。よく知られたプロジェクト名だけでは、受け入れられるすべてのコードを説明できるわけではありません。

Kohaku-cli は、Tornado Cash、Railgun、および Privacy Pools V1 のパブリック Ethereum アカウントとプライベート残高を処理します。これは、再利用可能なプロトコルライブラリやウォレットインフラストラクチャからなる広範な Kohaku ツールキットとは異なる、特定のウォレットアプリケーションです。その警告は、使用するすべてのコンポーネントまたはプロトコルに対する監査判定としてではなく、そのアプリケーションレベルで読まれる必要があります。

文書化されたインストールルートには、「ローカル」に何が必要かも示されています。プロジェクトの手順では、依存関係をインストールする必要があります。 npm install、アプリケーションを構築します npm run build、ローカルランチャーを実行します。コミット時 0ef5c44、ドキュメント、マニフェスト、ロックファイル、および実装は、同じアプリケーションリビジョンについて説明します。そのマニフェストではバージョン 0.1.0 が識別され、Node.js 22 以降が必要です。 Buterin のアカウントでは、彼がインストールしたリビジョンは特定されません。

マニフェストは、viem およびいくつかの Kohaku パッケージを含む直接依存関係のバージョンを修正します。また、別のピンも固定されます kohaku-artifacts コミットに対する Git の依存関係。対応するロックファイルには、解決されたレジストリパッケージと整合性ハッシュが記録されます。したがって、アプリケーションには、そのインターフェイスがユーザーのマシン上で実行されている場合でも、ソフトウェアサプライチェーンが存在します。

準備にはすでに署名が含まれている可能性があります

Kohaku-cli のパブリック転送とレールガンのシールド解除パスは、提出前の一時停止が異なる意味を持ち得る理由を示しています。通常のパブリック転送のドライランは、トランザクションを送信せずに戻ります。準備されたレールガンのシールド解除には、すでに署名が含まれている場合があります。

通常の非バッチパブリック転送の場合、転送実装はトランザクションをシミュレートし、送信せずに予行出力を返します。ブロードキャストパスには送信者の秘密キーが必要で、ローカルウォレットクライアントを構築してトランザクションを送信します。ウォレットクライアントコードは、その秘密鍵から署名アカウントを取得します。

プライベートな操作ではさらなる問題が露呈します。 unshield コマンドは、ブロードキャストが保留されている場合でも、すでに署名されている準備済みの Railgun UserOperation を出力できます。 UserOperation は、互換性のあるツールが送信できるアカウント操作ペイロードです。別のブロードキャスト実装は署名された操作を予期し、それを Pimlico バンドラーを通じて送信します。

そのパスの場合、送信を保留しても、互換性のあるツールが後で送信できるように、署名された操作を残すことができます。したがって、結果を「準備済み」と呼んでも、それが普遍的に署名されていないわけではありません。認可を構築する可能性のあるソフトウェア、認可に署名する可能性のあるソフトウェア、および認可を送信する可能性のあるソフトウェアは、1 つの CLI がそれらを調整する場合でも、個別の権限ソースとして評価される必要があります。

人間による確認も別の選択肢です。検査されたパブリック転送パスでは、ウォレットへのアクセス権を持つ適切に設定された呼び出し元は、 --non-interactive と共に --broadcast 追加の確認プロンプトを表示せずに送信します。ウォレットのロック解除、必須パラメータ、チェーンのマッチング、シミュレーションのチェックは引き続き適用されます。この機能はスクリプトとエージェントに関連します。ブテリン氏が無人決済を利用しているかどうかは明らかにしていない。

README には、POSIX 自動化のためのディスク上の暗号化シードと所有者制限のパスワードファイルについて説明されています。これらの措置は、保存されたシークレットと、プロセスがそれらのシークレットにアクセスする方法を管理します。プロセスが署名者を使用できるようになると、それら自体は、独立した支出制限や受信者ポリシーを確立しません。

CryptoSlate は以前、ローカル AI のウォレット権限の問題を取り上げました。配信制御により、別の側面が追加されます。ユーザーは、選択したインターフェイスリビジョンを保持しながら、そのコードは、受け取った署名および送信権限の範囲内で動作します。

来歴は起源を確認し、行動については別の質問が含まれます

ソフトウェアの来歴は、配信側をより厳密に検査する方法を提供します。アーティファクトがどこから来たのか、どのように構築されたのかを記録します。 SLSA 検証標準では、来歴署名の確認、アーティファクトのダイジェストの照合、信頼できるビルダーの認識、指定されたソースとビルドのパラメーターと期待値の比較について説明します。

これらのチェックは、予期されるビルドと、置換されたアーティファクトまたは意図しないビルドソースを区別するのに役立ちます。これらは依然として、検証者が信頼するビルダーとソースの期待に依存します。

依存関係のチェックは独自のタスクのままです。 SLSA では、オプションの追加手順として、解決された依存関係の再帰的検証について説明します。トップレベルのアーティファクトを認証しても、そのアーティファクトへのすべての入力が自動的に認証されるわけではありません。

正しいオリジンとビルド履歴には、ユーザーが依然として拒否するアプリケーションロジックが伴う場合があります。

ネットワークプライバシーも同様に、アプリケーション配信とは別のものです。 CLI ドキュメントでは、Ethereum RPC が通常のネットワーク接続に留まる一方で、特定の非 RPC トラフィックに対してデフォルトで Tor が使用されると説明されています。したがって、インターフェイスをローカルで実行しても、すべての外部対話がプライベートになるわけではありません。以前の Kohaku と Verified-RPC の報道は、この広範な信頼問題の別の部分に関係していました。

Buterin の実験は、ユーザー制御の具体的な形式、つまりマシン上に残すアプリケーションコードを選択し、置き換えコードをいつ受け入れるかを決定することを示しています。その値は、依存関係の選択および署名者を通じてそのコントロールを運ぶことに依存します。