ターンスタイル
TL;DR
- ターンスタイルは、各シールドプールにどれだけの価値が入り、どれだけの価値が出たかを追跡する公開会計ルールです
- これにより、内部のトランザクションがプライベートであっても、プールから払い出された価値が投入された価値を決して上回らないことを誰でも検証できます
- これは、偽造コインがカウントを破らずにプールの外へ出ることはできないため、隠れたバグから ZEC の供給を守ります
- プール内の支払いはプライベートなままです。ZEC をプール間で移動させるトランザクションでは、移動する金額が示されます
- ターンスタイルがあるからこそ、Orchard から Ironwood への移行ではシールドされた供給が健全であることを証明できます
これは誰向けですか
- Zcash がどのようにしてプライベートな供給の信頼性を保っているのかを理解したい人
- Orchard から Ironwood への移行を追っていて、それがどのように供給の実在性を証明するのか疑問に思っているユーザー
- プライベートなお金のシステムが、それでもどのように監査可能なのか気になる初心者
課題
シールドされた Zcash は、金額、送信者、受信者を隠します。そのプライバシーこそが本質です。しかし、そこには難しい問いが生じます。シールドプールの内部を誰も見られないのなら、ZEC の総量が正しいことをどうやって確認できるのでしょうか。見えないお金をどう監査するのでしょうか。
もしバグによって誰かがシールドプール内でコインを偽造できてしまったら、その偽造は、正直なユーザーを守るのと同じプライバシーによって隠されてしまいます。安全策がなければ、その不確実性は供給全体への信頼を損ないます。その問題を解決する安全策がターンスタイルです。
ターンスタイルとは何か
各シールドプールを、カウントされる出入口が1つだけある部屋だと考えてみてください。価値が外部からプールに入るときも、そこから別の場所へ出るときも、必ずその出入口を通り、そのたびに公開で集計されます。部屋の中のトランザクションはプライベートなままですが、出入口での累計は誰にでも見えます。
ルールは単純です。プールは、入った価値より多くの価値を外に出すことはできません。ノードは、プールの残高をゼロ未満に押し下げるようなブロックを拒否します。プールの中にあると考えられる金額は常に分かります。なぜなら、それは単に「入った合計」から「出た合計」を引いたものだからです。この公開集計がターンスタイルです。
どのように機能するか
Zcash にはこれまで、Sprout、Sapling、Orchard のように複数のシールドプールがありました。価値は透明チェーンとこれらのプールの間を移動し、ときにはプール同士の間も移動します。ターンスタイルはその動きを監視します。
- ZEC がシールドプールに入ると、その金額がそのプールの公開残高に加算されます
- ZEC がプールから出ると、その金額が差し引かれます
- あるプールの残高をマイナスにする、つまりそれまでに入った額より多くが出ていくことになるブロックは、ネットワークによって拒否されます
- 各トランザクションで示されるのは、プールへの流入またはプールからの流出の純額、すなわちその値の収支だけです。同一プール内での支払いの場合、それは手数料のみです
ネットワークはこの方法で、Sprout、Sapling、Orchard、新しい Ironwood プール、さらに透明残高と lockbox 残高を含む、すべての value pool の残高を追跡します。そのため、たとえプールの正確な中身が隠されていても、そこから出てこられる最大量は、入った量によって上限が定まります。隠れたインフレが流通に紛れ込むことはありません。
value balance はどのように検証されるか
出入口での集計が信頼できるのは、各トランザクションが、金額そのものを隠したままでも、自分が真実の金額を動かしたことを必ず証明しなければならないからです。各シールドトランザクションは、プールに対して出入りした正味の価値を示す1つの正直な数値を公開します。これを value balance と呼びます。正の value balance は資金がプールから透明側へ出たことを意味し、負の value balance は資金が入ったことを意味します。プライベートな詳細は封印されたままですが、この1つの正味値だけは公開され、ターンスタイルが加算していくのはこれです。
巧妙なのは、その公開数値が正しいことを、背後の非公開金額を明かさずにトランザクションがどのように証明するかです。仕組みはプールごとに異なり、ここにターンスタイルの本当の機構があります。
元の Sprout プールでは、各トランザクションは JoinSplit を使います。JoinSplit は2つの隠された note を消費し、2つの新しい note を作成します。また、2つの公開フィールドを持ちます。vpub_old は透明側からシールドプールへ入る価値、vpub_new はプールから透明側へ戻る価値です。すべての JoinSplit はそれ単体で収支が一致していなければならず、そのゼロ知識証明は、隠された入力と隠された出力が正しく釣り合っていることを保証します。Sprout のプール残高は、チェーン全体にわたるすべての vpub_old の累計から、すべての vpub_new の累計を引いたものにすぎません。だからこそ Sprout は後の例として便利です。vpub_old は価値がプールに入る唯一の方法なので、それを無効化する1つのルールだけで、そのプールを完全に封印できるからです。
Sapling、Orchard、Ironwood では、より賢いやり方で残高が証明されます。binding signature を使うのです。各送金が個別に収支を合わせるのではなく、トランザクション全体が value commitment を用いて各隠し金額にコミットします。value commitment は数値を封じた封筒のようなもので、homomorphic Pedersen commitment によって構成されます。これには特別な性質があり、封筒を開けることなく足し引きできます。ネットワークはすべての入力コミットメントを合計し、すべての出力コミットメントを差し引き、その結果をトランザクションが単一で宣言する正味値、つまり valueBalance フィールドと照合します。隠された金額が本当にその公開 valueBalance と一致しているトランザクションだけが、結合されたコミットメントに対して有効な binding signature を生成できます。もし誰かが宣言した値より大きな価値を動かそうとすれば、コミットメントの計算が合わず、binding signature の検証に失敗し、そのトランザクションは拒否されます。Ironwood は Orchard と同じプロトコルを使うため、同じ仕組みで動作します。
これにより、プール間送金も安全に検証できます。資金があるシールドプールから別のシールドプールへ移るとき、たとえば Orchard から Ironwood へ移るときでも、その金額を会計から隠すことはできません。各プールにはそれぞれ独自の value balance があり、それぞれ独自の証明で満たされなければなりません。Orchard 側は、自身の binding signature を通じて対応する流出を示さなければならず、Ironwood 側は、自身の証明を通じて対応する流入を示さなければなりません。あるプールから出る価値と別のプールに入る価値は、それぞれ独立して証明されます。つまり、プール間移動とは、実際には1つのトランザクションの中で起こる2回のターンスタイル通過、すなわち「出る」と「入る」であり、基礎となる金額はプライベートなままでも、その両方が公開で集計されるのです。
つまり、ターンスタイルは信頼ではありません。各トランザクションが自らの正味の効果を数学的に証明し、ネットワークはその証明済みの正味効果をプールごとに合計し、そしてコンセンサスルール（ZIP 209）が、プール残高をマイナスにするブロックを拒否します。トランザクションレベルでの証明、チェーンレベルでの強制です。
なぜ重要なのか
ターンスタイルは Zcash に3つのものを同時にもたらします。
第一に、リスクを区画化します。あるプールで暗号学的なバグが発生しても、その被害はそのプール内に閉じ込められます。なぜなら、ターンスタイルが偽造された価値がより広い供給へ渡るのを止めるからです。
第二に、コミュニティが後から供給を検証できるようにします。後になってバグが発見された場合でも、ターンスタイルの記録を見れば、あるプールから入った量を超える価値が出ていったことがあるかどうかが分かります。記録がクリーンであれば、偽造が悪用されなかった強い証拠になります。
第三に、そのすべてを行いながら、プール内の支払いを非公開に保ちます。各トランザクションが公開するのは、プールへの純流入またはプールからの純流出のみであり、同じプール内の支払いでは手数料だけです。たとえば Orchard から Ironwood へのようなプール間の送金では、プールをまたぐ金額が表示されます。監査可能性とプライバシーが両立しているのは珍しく、Zcash の静かな強みの1つです。
実際に機能するターンスタイル
ターンスタイルは新しい仕組みではなく、Zcash の歴史における重要な局面で使われてきました。
Zcash が元の Sprout プールから新しい Sapling プールへ移行したとき、ターンスタイルがその移行を守りました。その後 Sprout プールは新たな流入を受け取れないように制限され、ユーザーの移行を促しつつ、ターンスタイルが会計の正しさを保ちました。さらに何年も後になっても、Sprout から不正に価値が流出したことが一度もないという事実は、その初期の暗号技術が成功裏に悪用されたことはなかったという証拠になっています。
同じ設計が今、Orchard から Ironwood への移行も守っています。2026年、Orchard の proving system に健全性のバグが見つかり、修正されました。これが悪用された証拠はありませんが、シールドされた活動はプライベートであるため、確実な断定は不可能でした。そこで、古い Orchard プールを封印し、全員が資金をターンスタイル経由で修正済みプロトコルを使う新しい Ironwood プールへ移す、という対応が取られます。資金をターンスタイルに必ず通すことで、もし仮に残されていた偽造コインがあっても、それが一緒についてくることはできません。そして移行が完了すれば、誰でもシールドされた供給が健全であることを確認できます。
一方向のプール廃止
ターンスタイルにより、供給保証を一切壊すことなく、古いプールを安全に、一方向だけで廃止することが可能になります。コツは、出口を開いたまま入口だけを閉じることです。
最も分かりやすい例が Sprout です。これを廃止するために、ZIP 211 は単一のコンセンサスルールを追加しました。アクティベーション高以降、すべての JoinSplit の vpub_old フィールドはゼロでなければなりません。vpub_old は価値が Sprout に入る唯一の方法なので、これをゼロに強制することは、新たな価値が二度と入れなくなることを意味します。一方で、価値は引き続き透明側や Sapling へ流出できます。こうしてプールは一方向になりました。空にすることしかできず、満たすことはできません。ターンスタイルはその間ずっとカウントを続けるので、資金が出ていくにつれて残高は減ることはあっても増えることはなく、ゼロ未満になることもありません。
Orchard から Ironwood への移行も同じ考え方を使います。NU6.3 アップグレードで Orchard プールは新たな流入に対して閉じられ、ウォレットは Orchard の資金をターンスタイル越しに新しい Ironwood プールへ送るよう誘導されます。Orchard は空になることしかできない一方向プールになります。すべての流出は、証明が必要なターンスタイル通過であるため、もし Orchard に仮想的な偽造価値が残っていたとしても、それが正当な資金に紛れて静かについて出てくることはできません。それは、空になる一方で、出入口が監視されているプールの中に閉じ込められます。時間とともに、これによって古いプールは空へと近づき、外へ出た価値が、正当に入った価値を超えたことが決してないと誰でも確認できるようになります。
これこそが、単なる会計以上にターンスタイルが重要である深い理由です。Sprout のように複雑さを減らすためであれ、Orchard のように発見されたバグから回復するためであれ、Zcash がシールドプールを廃止しつつ、供給についての継続的で公開され、証明可能な保証を維持できるのは、この仕組みのおかげです。
よくある誤解
- ターンスタイルは、誰が誰に何を送ったかを明らかにしません。プール間でZECを移動するトランザクションについては、その金額を表示します
- 偽造者を名指しで突き止めるものではありません。プールから出ていける量に上限を設けるのであり、それが供給を守るのです
- Ironwood のための新発明ではありません。Zcash の歴史におけるすべての主要なシールドプール移行を守ってきました
- 公開されたプール総量は、プール内での支払いのプライバシーを弱めません。プール間でZECを移動すると移動額が表示されるため、ZIP 318ではウォレットに対し、時間をかけて標準額で移行するよう求めています
リソース
- ZIP 209: 範囲外のチェーン value pool 残高を禁止する - ターンスタイルの背後にあるコンセンサスルール
- ZIP 211: Sprout Chain Value Pool への新しい価値の追加を無効化する - Sprout プールが新規入金に対してどのように閉じられたか
- ZIP 258: NU6.3 - Ironwood プールを導入し、価値をターンスタイル越しに移動させるアップグレード
- 偽造に対するターンスタイルの強制 - Electric Coin Company による元の説明
- Zcash Protocol Specification - 完全な詳細については、balance と binding signature の節を参照してください
- Value Pools, the Zebra Book - ノードが各プールの value balance をどのように追跡するか
関連ページ
