zkSyncの紹介：Ethereumの大量導入の為のミッシングリンク
ZK Rollup上に構築されたMatter Labsのトラストレス・スケーリング＆プライバシー・エンジン
Update June 18 2020: zkSync v1 is live on Mainnet!!!!
パブリックブロックチェーンにおけるスケーリング問題を解決する為には、トランザクションのスループットが高い事だけが要点とはなりません。また、分散性を犠牲にすることなく、何百万人ものユーザーのリクエストに応えることができるシステムの能力として定義されなければなりません。暗号の大量導入の前提条件として、高速、低コスト、スムーズなUX、プライバシーが挙げられます。
技術的なブレイクスルーがない場合、既存のスケーリングソリューションは、これらの要件の1つまたは複数に大きな妥協をしなければなりませんでした。幸いなことに、最近の ゼロ知識証明の進歩は、この問題に対処するための根本的な新しい可能性を開くものとなっています。
今日、私たちMatter LabsはzkSyncのビジョンを明らかにすることに興奮しています：ZK RollupをベースにしたEthereumの信頼性のないスケーリングとプライバシーソリューションで、優れたユーザーと開発者の体験に重点を置いています。また、zkSyncのテストネットの開始を発表できることを誇りに思います。
ZK Syncは、VISAスケールの毎秒数千件のトランザクション（TPS）のスループットをEthereumにもたらすように設計されていますが、その一方で、資金を基礎となるL1アカウントと同様に安全に保ち、高度な検閲耐性を維持します。このプロトコルのもう一つの重要な点は、超低レイテンシーであり、ZK Syncでの取引は経済的な最終決定を即座に提供します。
我々はリーンデザインの哲学を支持しており、各ステップでユーザーに最も具体的な価値をもたらす順序で一つずつ機能を導入することで、プロトコルを徐々に進化させていきます。そのため、私たちは基本的なこと（セキュリティ）から始め、最初は基本的なスケーラビリティ（トークンの転送）、次にプログラマビリティ（スマートコントラクト）、そして最後にプライバシーに焦点を当てています。
ブロックチェーンのスケーリングで最も難しい問題
実際には、暗号は現状ほとんど投機の為に使われています。実際に大量に採用されなければ、マジック・インターネット・マネー、DeFi、Web 3.0、その他すべての有望なブロックチェーンのアイデアの価値提案は、ほとんど実現されないままとなるでしょう。
スケーラビリティとは、単に取引のスループットだけではなく、ブロックチェーンシステムが何百万人ものユーザーの要求に応える為の全体的な準備ができているかどうかを意味します。
ここでは、ブロックチェーン革命を大衆に拡大する上で最も困難な3つの問題について考えてみましょう。
課題1：非中央集権の維持
現実の世界での採用には、現在最も分散化されたブロックチェーンが処理できるその数値よりも、桁違いに高いトランザクション・スループットが必要となります。ビットコインの処理能力は7TPS、イーサリアムは15TPSですが、VISAだけでも平均2000TPSという気の遠くなるような処理能力があります。
しかし、ビットコインやイーサリアムの遅さは、バグではなく機能なのです。バリデーター数を減らせば、速度を上げることは自明の理です。両大手ブロックチェーンネットワークが誇る膨大な数のフルノードは、彼らの最も重要な資産です。これがレジリエンスを提供し、実際にこれらのブロックチェーンが既存の金融機関と根本的に異なる点です。
一般的なスケーラビリティのアプローチとしては、各バリデータに、関連するブロックチェーントラフィックの全てではなく、一部のみのチェックを要求する方法があります。しかし、これは必然的に追加の信頼前提を導入することになり、このようなシステムはゲーム理論的に非常に不安定なものになります。
課題2：プライバシーの確保
ほとんどの人は、自分の財産の大部分を、公にさらされたガラスの箱に移すことに抵抗を感じるでしょう。例えば、ベネズエラのような危険な場所の住民は、地元の商人がいくら持っているかをすぐに知ることができる場合、暗号通貨で支払うことはないでしょう。ポルノなどのわいせつなコンテンツを作成または消費している人は、これらの支払いが実世界のIDとリンクする可能性がある場合、Paypalの代替手段として暗号通貨を使用することはないでしょう。
更に、チェーン上の機密性が確保できない場合、GDPRやCCPAなどのプライバシー規制により、一般企業はパブリック・ブロックチェーンからより中央集権的な決済・金融ハブへと移行し、キャッシュレス化が進む社会を監視の悪夢へと変えてしまうでしょう。
プライバシーは大量導入のための絶対的な前提条件です。
パブリック・ブロックチェーンでプライバシーを実現することは、いくつかの要因から困難となっています：
- プライバシーは、プロトコルの不可欠な機能としてデフォルトでオンになっている必要があります。Vitalik Buterin氏の言葉を借りれば、あなたのプライバシーモデルがある程度の匿名性セットを持っているとしたら、それは実際には小さな匿名性セットを持っている。プライバシーモデルの匿名性セットが小さい場合、それは匿名性セットが1であることを意味します。
- デフォルトでプライバシーを実現するためには、計算上のオーバーヘッドが大きくなっても、プライベートな取引コストは非常に低くなければなりません
- プライバシーモデルはプログラマビリティをサポートしなければなりません。現実のユースケースでは、単なる送金だけではなくアカウントリカバリーやマルチシグネチャ、支出制限などが必要となるからです
課題3: UXの期待に応える
現実は厳しいものです。プロダクトマネージャーは、ユーザーが日常的に、より簡単で、より軽量で、直ちに満足できるエクスペリエンスを他の選択肢よりも好むことを理解しており、しばしばロングテールリスクを無視します。ユーザーが慣れ親しんだものから新しいものに乗り換えるように仕向けるには、並外れた力が必要となります。一部の人にとっては暗号の価値提案（過激な自己所有権、検閲への抵抗、健全な貨幣）で十分かもしれません。しかし、そのような人たちは既にその潮流に乗っているでしょう。暗号通貨がその約束を果たすために必要な規模に達するには、数十億人とは言わないまでも、数百万人が必要となります。
何百万人ものユーザーを惹きつけるためには、これらの期待に応えるだけでなく、それを上回るユーザーエクスペリエンスを提供する必要があります。その為には、人々が慣れ親しんできた従来のウェブ製品の便利な特性を維持しつつ、まったく新しい可能性を提供しなければなりません。速くて、シンプルで、直感的で、エラーに強い。それです。
zkSyncのコミット：高い信頼性と機密、そして高速
このテクニカルレポートでは、提案されているプロトコルのハイレベルなアーキテクチャや設計上の選択、特性について説明します。
1. セキュリティ ZK Rollupに根ざしたセキュリティ
ZK Sync は ZK Rollup のコンセプトに基づいて構築されています。一言で言えば、ZK RollupはL2スケーリングソリューションであり、全ての資金はメインチェーン上のスマートコントラクトによって保持され、計算とストレージはオフチェーンで実行されます。Rollupのブロックごとに、状態遷移ゼロ知識証明（SNARK）が生成され、メインチェーンのコントラクトによって検証されます。このSNARKには、Rollupブロック内のすべての単一トランザクションの有効性の証明が含まれています。更に、各ブロックのパブリックデータの更新は、安価なcalldataとしてメインチェーンネットワーク上で公開されます。
このアーキテクチャにより、以下のような保証が得られます：
- Rollup validator(s)は、(Sidechainsとは異なり)状態を破損したり、資金を盗んだりすることはできない
- ユーザーは、データが利用可能である場合、バリデータが協力をやめても、Rollupから資金を回収することができる（Plasmaとは異なる）
- 妥当性証明のおかげで、ユーザーも信頼できる第三者も、不正を防ぐためにロールアップブロックを監視するためにオンラインにいる必要はない。
ZK Rollupは、基盤となるL1のセキュリティ保証を継承しています。この事実は、イーサリアムのコミュニティや既存のインフラの豊かさとともに、独自のL1を構築しようとするのではなく、L2ソリューションに焦点を当てるという私たちの決断の決定的な要因となりました。
このコンセプトをよりよく理解するためには、 ZCon1とDappconでの講演、Matter Labsをフィーチャーしたpodcast、または以前の技術説明記事を参照してください。
Ethereum Foundationからの助成金を受けて、Matter Labsは過去1年間、ZK Rollupの開発に取り組んできました。最初のプロトタイプを発表して以来、アーキテクチャとZK回路を完全に書き換えました。最新バージョンでは、コミュニティから寄せられたフィードバックを取り入れ、様々なユーザビリティとパフォーマンスの改善を実装しています。
2. 使いやすさ：リアルタイムトランザクション
現在開発中のZKプローバー技術では、ZK Rollupのブロックを1分以内に生成できる証明時間を実現することが期待されています。ブロック証明がメインチェーンに提出され、Rollupスマートコントラクトによって検証されると、このブロック内のすべてのトランザクションが確定し、L1の耐リゴリズム保証の対象となります。
しかし、小売やオンライン決済では、イーサリアムの15秒のブロックレイテンシーでも長すぎることがあります。どうすればいいのでしょうか？
ZK Syncではインスタントtxレシートを導入しています
ZK Syncのブロック生産に参加する為に選ばれたバリデーターは、メインネット上のZK Syncスマートコントラクトに多額のセキュリティボンドをポストする必要があります。バリデーターによるコンセンサスが行われると、ユーザーは自分の取引が次のZK Syncブロックに含まれることを秒単位で確認でき、コンセンサス参加者のうち⅔の超過半数（ステークで加重）の署名が得られます。
新しいZK Syncブロックが生成され、メインチェーンに提出された場合、そのブロックを元に戻すことはできません。しかし、約束されているトランザクションが含まれていなければ、元のレシートの署名者と新しいブロックの署名者の交点のセキュリティボンドがスラッシュされます。この交点は、ステーク額の⅓以上が保証されています。これにより、セキュリティボンドの少なくとも⅓がスラッシュ可能であることが保証され、悪意のあるユーザーのみが罰せられることになります。
スラッシュされた資金の一部は、tx受信者への補償に使用され、残りはバーンされます。
スラッシュは、ユーザ自身、あるいはオリジナルのtxレシートに署名したコンセンサスの誠実な参加者のいずれかによって引き起こされます。後者には、不正行為を通報するという当然のインセンティブがあります。後続のブロック生成に参加すれば、彼らもスラッシュされる可能性があります。このように、不正を検知するには、コンセンサスに少なくとも1人の誠実な参加者がいれば十分となります。
このプロトコルの特性を調べてみましょう。ここでは、まだEthereumに公開されていないZK Syncブロックのインスタントレシートを持つ取引をゼロ確認txと呼びます。
ZK Syncの0確認取引の二重使用は、ブロック証明がメインチェーンに公開されるまでの数分という非常に短い時間枠の中でのみ悪用される可能性があります。さらに、悪意のある検証者は、ユーザを騙してセキュリティ・ボンドの⅙以上の価値があるゼロ確認取引を受け入れさせなければなりません。
バイヤーとマーチャントの両方の視点から見ると、ゼロコンファメーション取引は :
- インスタント
- 元に戻せる可能性はあるが、数分以内にしか戻せない
- 一人ずつではなく、何千ものマーチャントに対して一斉に攻撃した場合にのみ、元に戻せる
これは、クレジットカード決済に比べて、UXとセキュリティの面で非常に優れています。では、異なるアクターの視点から見てみましょう：
- 物理的な商品を扱うオンラインストアでは、ユーザーに購入を即座に確認することができますが、出荷前に完全な確認を待つため、攻撃に対して免疫があります
- 実店舗では、少額の商品を扱う場合、攻撃の影響をほとんど受けません。Macbookを販売する際に、即時のTxレシートが必要だとしても、何千人もの物理的な攻撃者がさまざまな場所で連携し、大多数の検証者が共謀しなければ、損失を被ることになります
もっと深く掘り下げてみましょう。リスクを定量化するために、ボンドが提供する経済的保証を、プルーフ・オブ・ワークのブロックチェーンが提供する決済保証と比較することができます（Nic Carter氏による素晴らしいスレッドご覧ください）
例えば、CoinbaseはEthereumでの入金確定前に35回のtx確認を必要とします。AWSからレンタルしたGPUで10分間51%の攻撃を実行してこの取引を元に戻すコストは、およそ6万ドルです。数百万米ドルの保証金を想定すると、インスタントZK Syncレシートを戻すのはもっとコストがかかります。このように、インスタントレシートは一般的にETHのような、あるいはそれ以上の経済的最終性の特性を持つ可能性が高くなります。
また、インスタントtxレシートは、その有効性がEthereumとは独立しているため、ETHのブロックリオーグからも保護されていることに注意する必要があります。さらに、Ethereumの決済保証は、ZK Syncの決済保証と複合しています。
3. Liveness: 検閲とDoSへの耐性
スケーリングソリューションの必然的な特性として、ほとんどのユーザーが全てのトランザクション量の検証に参加できないことが挙げられます。この為、L2スケーラビリティソリューションでは、特殊な役割が必要になります（PlasmaやRollupsのバリデータ及びLightningのハブなど）
これらの役割によって課せられるセキュリティとパフォーマンスの要件の増加は、集中化と検閲のリスクをもたらします。
ZK Syncのデザインは、長期的には2つの異なる役割を導入することでこの問題に取り組んでいます。バリデーターとガーディアンです。
バリデーター
バリデーターは、トランザクションをブロックにまとめ、ゼロ知識証明を生成する役割を担います。バリデーターはコンセンサスに参加するため、即時のTx受信のためのセキュリティ・ボンドの一部を負担しなければなりません。彼らのノードは、インターネットの帯域幅が確保された安全な環境で動作する必要があります。また、安全でないオンデマンド・クラウド上でZK証明を生成することも可能となります。
検証者にはトランザクション手数料が支払われますが、この手数料は取引されるトークンで支払うことができます（エンドユーザの利便性を最大限に高めるため）
ZK Syncのコンセンサスを高速に保つために、限られた数のバリデータのみが許可されています（プロファイリングの結果では30～100人）しかし、ZK Rollupのバリデータは完全に信頼できない事を考慮してみましょう。ZK Sync では、悪意のあるバリデータはシステムのセキュリティを危険にさらすこともできなければ、誠実なバリデータを騙してスラッシュ状態にすることもできません。したがって、optimistic Rollupとは異なり、小さなバリデータのセットをガーディアンが頻繁に交代させる事が可能です。同時に、指名されたバリデータのうち⅔以上が誠実で稼働している限り、コンセンサスの有効性は保証されます。
ガーディアン
ガーディアンはZK Syncトークン保有者の大部分で構成され、トークンのシェアをステークしてバリデーターを指名します。ガーディアンの目的は、ピアツーピアの取引トラフィックを監視し、検閲行為を検知し、検閲を受けたバリデータが指名されないようにすることである。ガーディアンのインセンティブは、ZK SyncがDoSや検閲に強いことを確認することで自分の出資金の価値を守ることにあります。
投票キーをオンラインにしていても、ZK Syncのガーディアンはスラッシュや盗難のリスクにさらされることはありません（所有キーはコールドストレージに保管することができます）。また、ガーディアンはトラフィックの一部だけを監視する事もできます。そのため、ガーディアンのノードは通常のラップトップやクラウドサーバで動作させることができ、特殊なバリデータサービスは必要ありません。
ガーディアンはバリデータからの報酬をZK Syncのネイティブ・トークンで受け取ります。ガーディアンの収益やステークは長期にわたってロックされ、短期的なリターンよりも長期的なZK Syncトークンの価値を優先させるインセンティブとなります。
4. プログラマビリティとプライバシー：ビルディングブロック
効率的なプログラマビリティとプライバシーを実現することは、ZK Syncのビジョンの中で最も難しい部分です。その為には、適切なゼロ知識証明システムとスマートコントラクトのプログラミングフレームワークの両方をしっかりと設計・実装する必要があります。
4.1. RedShift: 透過的なユニバーサルSNARK
ZKベースのスマートコントラクトを実装する上での最大の障害は、（透過的なものであれ、プライバシーを守るものであれ）再帰的な構成を持つ効率的なジェネリックZK証明システムがないことでした。当時、最も効率的なZK SNARKであるGroth16は、アプリケーション固有の信頼できる設定を必要とし、再帰を適用すると多くの効率性を失ってしまいます。一方、FRIベースのSTARKは、構築に高度な専門技術を必要とし、任意の汎用回路の効率的な再帰的合成ができません。
FRIベースの多項式コミットメント方式から派生した、透明性が高く、効率的で、完全に簡潔な新しいSNARKであるRedShiftを開発したのは、この点が主な動機の一つでした。現在、ピアレビューやコミュニティからのフィードバックを取り入れているところですが、その後、RedShiftをZK Syncの中核部分として展開する予定です。
Redshiftは普遍的なSNARKであり、任意のプログラムを証明可能なZK回路に変換するのに便利に使う事がかのうであり、異種の回路（例：異なるスマートコントラクト）を1つのSNARKで再帰的に構成することができます。RedShiftは、衝突耐性のあるハッシュ関数のみに依存している為、ポスト量子の安全性を確保しています。
4.2. Zinc: ゼロ知識スマートコントラクトのためのフレームワーク
ZK Sync のプログラマビリティモデルの設計では、いくつかの目標にコミットしています：
- 高いスケーラビリティ
- パブリックとプライベートの両方のスマートコントラクトのサポート
- 最重要事項：フラットな学習曲線と容易な開発
多くの優れたプロジェクトがこれらの目標の一部を共有していますが、一度に全ての目標をコミットしているものはありません。例えば、ZkVMは一般的な機密スマートコントラクト用の仮想マシンを提供していますが、bulletproofsに基づいており、succinct proof aggregationをサポートしていません。ZEXEは優れたプライバシー保護設計を持っていますが、ゼロ知識回路の仕様とトレードオフを深く理解する必要があり、より広い範囲のプログラマーにとって参入障壁が非常に高くなっています。また、他のシンプルなZKプログラミングフレームワークでは、スマートコントラクトを安全に開発するために必要な表現力や機能が不足していました。
これが、ZKPベースのスマートコントラクトのために特別に設計された、安全でシンプルかつ効率的なプログラミングフレームワークとVMベースの実行環境であるZincの開発を決定しました。
SyncVMの設計上の優先事項は、安全性と開発者の利便性です。コントラクトを定義するためのプログラミング言語は、簡略化されたRustのシンタックスに忠実で、スマートコントラクトのプログラミング要素はSolidityやLibraのMoveから借りています。効率的で安全なプログラムを書くために、開発者がZKPドメインの仕様を深く理解する必要はありません。実際、ZincはRust、Solidity、C++などのプログラミング言語のバックグラウンドを持つ開発者が1日で習得することができます。
ベルマン・フレームワーク用にRustで書かれたプログラムの一部（ZEXEも同様のAPIを持っています）と、同じ部分をZincで書いた場合を考えてみましょう。
ZK Sync v0.1のテストネットが始動
ZK Sync v0.1のテストネットがライブになりました。このバージョンの範囲は、シングルオペレーターでのETHとERC20のトークン転送に限定されています。
v0.1 devnetのローンチは、ZK Syncのビジョンを実現するための長い旅の第一歩です。これには多くの研究、実験、開発努力が必要であり、いくつかのデザイン面では、学習やフィードバックを取り入れることで変更されるかもしれません。しかし、私たちはその志が決して変わらないことを約束します。ZK Syncは、何百万人ものユーザーを暗号化するための架け橋となることを目指しています。私たちはユーザーエクスペリエンスに高いハードルを設定しており、ブロックチェーン革命の価値を犠牲にすることなくウェブのようなエクスペリエンスを提供できるzk技術の可能性を示すつもりです。
私たちの進捗状況は、Matter LabsのTwitter、Telegramチャンネル、またはニュースレターを購読することで確認できます。
ZK Syncの開発に貢献したいとお考えの方は、ぜひ私たちにご相談ください。私たちは常に才能あるエンジニアや暗号技術者を募集しています！
