ヴィタリク・ブテリンがKohaku-cliツールを通じてプライベートEthereum支払いを実施

Ethereumの共同創設者であるヴィタリク・ブテリンは、10月31日のエッセイで、kohaku-cliがブテリンのプライバシープロトコルに関連する多くの支払いを処理していたと述べた。ブテリンはまた、AIが作成したコマンドラインツールが、EthereumのネーミングシステムであるENS上のIPFSコンテンツハッシュの最近の更新を処理していたと述べた。ENSのアップデーターは、支払い用ウォレットとは異なるアプリケーションであった。ブテリンは、ユーザーが再訪問するたびにアプリケーションコードをサーバーから新たに提供されることに反対しており、これはユーザーがサーバーの配信に繰り返し依存することを意味する。

ローカルに保持されるアプリケーションにより、ユーザーは選択したソフトウェアのリビジョンを維持し、交換版をいつインストールするかを決定できます。承認されたコードは、支払い指示と支払いを承認する署名の間で仲介し、依存関係と署名アクセスは引き続き重要です。Kohaku-cliのドキュメントでは、このアプリケーションは監査されておらず、AIによって支援され、現在積極的に開発中であると記載されています。ドキュメントは、ユーザーがそのアクティビティと資金の壊滅的損失のリスクを理解していない限り、メインネットでの使用を推奨していません。Kohaku-cliは、Tornado Cash、Railgun、Privacy Pools V1を通じて、パブリックなEthereum口座とプライベートな残高をサポートしています。このウォレットは、プロトコルライブラリとウォレットインフラからなる広範なKohakuツールキットとは分離されており、このアプリケーションの警告は、すべての下位コンポーネントやプロトコルの監査評価を意味するものではありません。

インストール手順では、ユーザーがnpm installで依存関係を取得し、npm run buildでアプリケーションをコンパイルした後、ローカルランチャーを実行する必要があります。コミット0ef5c44では、ドキュメント、マニフェスト、ロックファイル、実装が1つのアプリケーションリビジョンに対応しています。マニフェストはバージョン0.1.0およびNode.js 22以降を指定していますが、ButerinはButerinの使用にインストールされたリビジョンを特定していません。マニフェストは、viemおよび複数のKohakuパッケージを含む直接依存関係を固定し、別個のkohaku-artifacts Git依存関係を特定のコミットに固定しています。ロックファイルは解決済みのレジストリパッケージと整合性ハッシュを提供しており、ローカルインターフェースが依然としてソフトウェアサプライチェーンに依存していることを示しています。したがって、このソースビルドプロセスを通じて置換を受け入れることは、熟悉的なプロジェクト名だけでなく、依存関係およびビルドツールも受け入れることを意味します。

バッチ処理なしの通常のパブリック振替では、実装はトランザクションをシミュレートし、トランザクションを送信せずにドライラン結果を生成します。ブロードキャストには、送信者の秘密鍵と、その鍵から派生した署名用口座を持つローカル構築されたウォレットクライアントが必要です。代わりに、Railgunのunshieldコマンドは、ブロードキャストせずに既に署名済みのUserOperationを生成できます。UserOperationには、互換性のあるツールが送信可能なアカウント操作ペイロードが含まれており、別途実装されたブロードキャスト機能は、署名済みの操作をPimlicoバンダー経由で送信します。したがって、送信を保留しても、署名が常に保留されるわけではありません。互換性のあるツールが後から署名済みの操作を送信できるためです。認証の構築、署名、送信は、たとえ単一のコマンドラインアプリケーションがこれらのアクティビティを統括しても、それぞれ異なる形の権限を表します。

検査されたパブリック振替実装では、ウォレットアクセス権を持つ適切に設定された呼び出し元が、--non-interactive と --broadcast を組み合わせることで、さらに確認プロンプトなしで送信できます。ウォレットのロック解除、必須パラメータ、チェーンの一致チェック、シミュレーションチェックは引き続き適用されます。この機能はスクリプトやエージェントにとって重要ですが、Buterin が無人で支払いを行うことを意味するものではありません。README には、POSIX オートメーション用に暗号化されたシードとパスワードファイルを所有者のみがアクセスできるようにディスクに保存する方法が記載されています。これらの保護は秘密情報の保存とプロセスへのアクセスを制御しますが、プロセスが署名者アクセス権を獲得した後、これらだけでは独立した支出制限や受信者ルールを課すものではありません。

ソフトウェアの出所情報は、アーティファクトの起源とビルドプロセスを記録し、アプリケーションの配信を評価する手段を提供します。SLSA検証基準では、出所署名とアーティファクトのダイジェストの検証、信頼できるビルド元の認証、およびソースとビルドパラメータが期待値と一致しているかを確認することが求められます。これらのチェックにより、置き換えられたアーティファクトや予期しないビルドソースを特定できる可能性がありますが、その有効性は検証者が信頼するビルド元やソースの期待値に依存します。SLSAでは、解決された依存関係の再帰的検証をオプションの追加機能として扱っているため、メインアーティファクトの認証は、すべてのビルド入力の認証を自動的に意味しません。正当な起源とビルド記録を持つアプリケーションでも、ユーザーが拒否するような動作を含む可能性があります。

CLIドキュメントでは、一部の非RPCトラフィックに対してデフォルトでTorを使用すると明記されていますが、Ethereum RPCトラフィックは通常のネットワーク接続を使用します。したがって、ローカルインターフェースではすべての外部通信がプライベートになるわけではありません。アプリケーションコードを維持し、置換を制御することで、ユーザーは具体的な制御手段を得られますが、その利点は、その制御を依存関係の選択や署名者権限まで拡張することに依存します。