プライバシー重視の暗号資産Zcashのコントリビューターの間で現在検討されている提案は、ネットワークアップグレード(NU)のたびに未処理の署名済みトランザクションを無効化する仕組みの撤廃を目指すものだ。直近のアップグレードでは、ウォレットが新たなリリースやファームウェアを提供するまで送金できない状態が続いた。

新しい不満と、その新たな実例

11月9日のフォーラム投稿で、開発者のValarDragonは、次期アップグレードNU8の7つの目標の1つとしてコンセンサスブランチIDの更新の撤廃を挙げ、「毎回のNUでウォレットを壊す」というパターンを終わらせることを目的として明示した。

この不満には新たな実例が背景にある。先週、NU7がブロック3,543,405で有効化された際、トランザクション形式には一切変更がなかった。しかし、同じスレッドでフォーラムメンバーのstrahncryptographyが指摘したように、すべてのウォレットは再び送金できるようになる前に、新たなリリースまたは新たなファームウェアを必要とした。エアギャップされたスマートフォンや非対応デバイスを使うユーザーは身動きが取れなかった。

翌朝までに、スレッドでは3つの立場が示された。仕組みを撤廃する、維持しつつユーザーがオプトアウトできるようにする、あるいは真の問題は署名の失効ではなくウォレットの陳腐化であると受け止める、というものである。その後、ボールト開発者がこの選択が単なる理論上の問題ではない理由を示した。

実際に壊れるもの

Zcashのすべての署名は、現行のルールセットを示すラベルであるコンセンサスブランチIDに対してコミットされる。ZIP 200は、プロトコルのルールを規定するZcash Improvement Proposals(ZIP)の1つで、この仕組みを導入した。これは、あるチェーン向けに署名されたトランザクションが、同じ履歴を共有するフォーク上でリプレイされることを防ぐためである。アップグレードが有効化されるとIDが変更され、旧IDのもとで署名されたものはすべて即座に無効となる。

NU7のデプロイZIPは、直近のアップグレードについてこの点を明示している。バージョン5およびバージョン6のトランザクションは構造を維持したが、署名がブランチIDにバインドされるため、トランザクションは有効化をまたいでは依然として有効にならない。さらに同文書は、保存されたトランザクションやオフラインで署名されたトランザクションも、稼働中のものと同じ有効化チェックを必要とすると述べている。

これが、トランザクションの構築方法に何ら変更がないアップグレードにもかかわらず、ウォレットがアップデートを提供せざるを得なかった理由である。新しいIDを知らないウォレットは、もはや存在しないチェーンに向けて署名することになる。

期限内に署名できないボールト

Deega LabsでKonclaveのt-of-nボールトを開発するDaniel Gorgonhaは、その後スレッド内で実務上のコストを説明した。Konclaveはまずトランザクションを構築し、その後に閾値署名を収集するため、署名が必要な全メンバーはトランザクションの有効期限ウィンドウ、おおよそ50分以内に行動しなければならない。このウィンドウの途中でアップグレードが発生すると、すべてが無効となる。

50分という数字はZIP 203に由来し、ブロック時間の3回の変更を経てもデフォルトの有効期限はほぼこの長さに維持されている。NU7以降、これは25秒の目標間隔で120ブロックに相当する。これはウォレットのデフォルト値であり、ノードごとに設定可能で、フィールドをゼロに設定すれば有効期限のないトランザクションを構築することもできる。

つまり時間の問題は、ウォレットがその設定を公開している限り、すでに解決可能である。しかし、アップグレードの境界は解決できない。ボールトがメンバーに1週間の署名期間を与えても、ブランチIDが切り替わった瞬間にトランザクションは失われる。Gorgonhaの要請は、nuttycomが直前に提案したオプトアウトに関するもので、グループが自己責任で数時間から数日かけて署名を収集できるようにするというものだった。

3つの打開策、それぞれに代償あり

ブランチIDコミットメントを撤廃する。 これがValarDragonの当初の提案である。Electric Coin Company(ECC)のエンジニアstr4dは、ZIP 200が策定された当時、リプレイ保護は取引所やその他のエコシステム参加者による厳格な要件だったと回答し、撤廃には代替メカニズムが必要であり、理想的にはメインチェーンの混乱のみを目的とした敵対的フォークにも対応するものであるべきだと述べた。

デフォルトとして維持し、ユーザーのオプトアウトを認める。 同じくECCのnuttycomは、ブランチIDと有効期限高の両方を省略する署名バリアントをZIP 248のもとで提案した。これを選択したユーザーは一部のリプレイ保護を犠牲にする代わりに、アップグレードをまたいで存続するトランザクションを得る。大多数のトランザクションには既存のアルゴリズムで十分だとnuttycomが述べたように、既存のアルゴリズムは安全なデフォルトとして維持される。str4dは既に、ZIP 248が有効化されればこの種のバリアントは容易に定義できると指摘していた。

それがウォレットにとって何の解決にもならないのではないかという疑問。 strahncryptographyは、このバリアントはトランザクションの長寿命化には対応するが陳腐化には対応しないと論じた。ブランチIDがハードコードされていなければ、ユーザーが正しいIDを提供する必要があり、同じ負担がウォレットソフトウェアに戻されるという。友好フォークに対するリプレイ保護には価値があるが、その便益は比較考量されるべきだと彼は書いた。

スレッドは意見の不一致を解決していない。果たされたのは、必要とするユーザーのためにオプトイン型バリアントを構築する価値があるか、そしてそのユーザーは何を犠牲にすることになるのか、という問いへの絞り込みである。

オプトアウトのコスト

リプレイリスクは、直近のアップグレードを例にするのが最も分かりやすい。NU7に限り、ZIP 259は、旧ノードソフトウェアが有効化前に自身を廃止するという通常の要件を免除した。つまり、アップグレードしなかった運用者はオンラインに留まり、NU7以前のブランチを追い続けることができる。署名が特定のブランチに紐付かれていないトランザクションは、まさに両方で受け入れられ得る種類のものだ。

このリスクの範囲は、背後にある鍵ではなく、承認のスコープにある。リプレイされたトランザクションは、署名者が意図しなかった別のチェーン上で同じインプットを使用する。誰かが新しいトランザクションを偽造できるわけではない。

署名から有効期限高を外すことには第二の効果もある。承認済みの支払いは、そのインプットが使用されない限り、未確認のまま留まり続けられる。これはボールトが求める機能であると同時に、個人のユーザーが気づかないかもしれないリスクでもある。

nuttycomはまた、匿名セットの縮小の可能性にも言及した。シールドされたシステムでは、プライバシーはトランザクションが他のすべてのトランザクションと同じように見えることに依存する。あまり使われないバリアントで署名されたトランザクションは、隠れるための母集団が小さくなる。この投稿はその影響を定量化しておらず、バリアントの仕様もまだ定められていない。

長寿命の署名は旧デバイスを更新しない

このすべてが依存する拡張可能なトランザクション形式であるZIP 248は、いまだドラフト段階にある。str4dは、その設計は半年以上安定しており、直近1週間はその後にデプロイされたコンセンサス変更に合わせた更新に費やしたと述べた。特定のアップグレードへの割り当てはまだなく、オプトアウト型バリアントもまだ存在しない。

たとえ存在するようになっても、ハードウェアウォレットやオフライン署名者には新しい形式を理解するソフトウェアが必要である。ZIP 248は、ウォレットがパースできないコンポーネントを構築・署名することを禁じている。互換性の便益は現実のものだが、それはウォレットのリリースを通じて提供される。まさにstrahncryptographyが繰り返し失敗しているというステップである。

また、廃止された形式のトランザクションには、これらのいずれも役に立たない。ZIP 259は、バージョン4トランザクションに対するNU7の禁止がSproutだけでなくトランザクントおよびSaplingの使用にも及ぶこと、そして再署名では救済できないことを記している。唯一の解決策は、対応バージョンで支払いを再構築することである。Coindooは先週、より困難なケース——代替形式が一切存在しないSproutコイン——を取り上げた。

Konclaveには未完の課題もある。非同期署名に関する公開イシューは、時間をかけて収集される承認を、現在ボールトが実行している対話型の閾値セレモニーから分離するものだ。アップグレードをまたいで存続するトランザクションは一つの障害を取り除くが、メンバーがオンラインになり次第参加できるワークフローは、まだ作成とレビューが行われていない。

実務上の指針

グループウォレットを運用している場合:

• 有効化は日付ではなくブロック高で決まる。各アップグレードのデプロイZIPが事前にそれを公表している。
• そのブロック高をまたぐ可能性のある署名ラウンドを開始してはならない。
• 有効化前に準備されたものは、誰もまだ署名していなくても、有効化後に再構築が必要になる。

旧デバイスでコインを保有している場合:

• 送金を試みる前に、ファームウェアまたはアプリがNU7対応をリリース済みか確認する。
• 対応プールからの停止した送金はウォレットの問題であり、資金の消失ではない。
• 11月6日より前に保存されたバージョン4トランザクションは、再署名によって有効化できない。

Coindooのウォレット側の支払い改善に関する以前の記事は、トランザクションの構築と確認の間のギャップを扱った。今回のスレッドはその間に第三の段階を加える。人とデバイスが追いつくまで承認を生かし続けることである。

今後の展開

1月下旬はValarDragonの目標であって、確定した日程ではない。str4dは同じスレッドで、同じリストにあるTachyonプールについては2か月半で十分か疑問を呈しており、ブランチIDの項目は7つの中で最も強い反発を招いている。NU8にオプトアウトが搭載されるのか、リプレイ保護の代替策が搭載されるのか、あるいはどちらでもないのかは、フォーラムではなくZIPプロセスの中で決定される。