資金の安全性確保：zkSync 2.0のセキュリティに対する3つの要素のアプローチ
分離・冗長化によるセキュリティ、信頼性を重視したアップグレード性、zkSyncのセキュリティ評議会の導入について
“Only the paranoid survive.” — アンディ・グローブ（インテルCEO）
NFT、スワップ、zkEVM、およびzkSyncへのユーザーと資金流入の急激な増加に備えて、新規ユーザーへの警告と既存ユーザーへの注意喚起の両面の実行が必要があると考えていますが、開発の初期段階で新たなプロトコルを使用することに関連するリスクと信頼の前提について説明します。
このリスクは、L2に適用される技術的な革新性と、そのソリューションにおける集中化の可能性の両面に起因するものです。多くのチームと同様に、zkSyncはイーサリアムエコシステムのセキュリティとスケーラビリティを迅速に革新し、迅速に提供するために漸進的な分散化の道を取っています。
ここでは主な注意点を紹介します、
バグがゼロである事は保証できることではありません。しかし、業界の最新のセキュリティベストプラクティスに従い、契約や回路、基盤をカバーする監査法人の監査を受けることで、バグの発生確率は最小限に抑えられます。このリスクはイーサリアム上に構築されるすべての新しいアプリケーション全体に当てはまりますが、このプロジェクトの場合はゼロ知識証明技術の新規性と複雑性によって増幅されます。
zkSyncは、機能範囲が安定するまでアップグレード可能です。しかし、アップグレード可能性はプロトコルガバナンスによって制御され、後述する4週間のタイムロックを受けることになります。
zkSyncは現在、信頼できるセットアップに依存しています。200人以上の参加者（Vitalik Buterin、Ethereum Foundation、Consensys、Argent、Matter Labsなど）が参加したセレモニーの結果を利用しており、少なくとも1人が正直者であれば我々のシステムは安全です。この仮定が大きな懸念となるようなブロックチェーンプロジェクトにはまだ発見されていませんが、それでも将来的には、信頼できるセットアップを一切必要としないRedShiftに切り替えるつもりです。
(1)と(2)の影響を軽減するために、私たちは以下のようなマルチレイヤーのセキュリティ戦略にコミットしています。
zkSyncの3ファクタ・アプローチによるセキュリティ
- 隔離と冗長性によるセキュリティ
- 信頼性を考慮したアップグレード性
- zkSyncのセキュリティ協議会
隔離と冗長性によるセキュリティ
zkSyncのL1スマートコントラクトは、数百行のコードで構成される非常に軽量な設計のため、深刻な問題は発生しないと考えています。ZKP側は、コード量が多く、暗号が複雑になるため、リスクが高いと考えています。
実際には、暗号の部分も問題になることはないでしょう。スマートコントラクトの悪用を突然の津波に例えると、暗号の悪用は徐々に雨が降ってくる洪水のようなものです。1階はすぐに影響を受けますが、実際には誰もが超高層ビルの上に住んでおり、避難するための十分な時間があります。新たに発見された脆弱性は、攻撃のコストが指数関数的に増加するため、通常、実運用で使用されているセキュリティ閾値よりもはるかに低いセキュリティ閾値でしか利用できません。例えば、有名なRSAチャレンジでは、100ビットの暗号を解読するのに1ヶ月しかかかりませんでしたが、250ビットの暗号を解読するのには30年近くかかりましたが、現実のシステムでは2048ビット以上が使われています。
ZKP側でバグや悪用に対する保護を強化するために、私たちは2つのアプローチをとっています：
- 隔離：承認されたシーケンサが提出したブロックのみが、zkSync L1スマートコントラクトに状態遷移をコミットすることができます。近々、PoSを用いたマルチバリデーターコンセンサスで保護された集団シーケンサに切り替える予定です
- 冗長性：シーケンサ（複数）に提出されたすべてのトランザクションは、ブロックに含まれる前に単純な実行によって検証されます
そのため、ZKP回路や基盤となる暗号に脆弱性があり、無効な取引に対してゼロ知識証明が生成されるようなことがあっても、それを容易に利用することはできません。
無効なブロックをロールアップに提出するためには、攻撃者は暗号技術とシーケンサ/POSのコンセンサスの両方を突破しなければなりません。
潜在的な悪用を早期に発見するために、ホワイトハットのハッカーのために、セキュリティの閾値を大幅に下げた大きなバグバウンティが設定されます。
信頼性を重視したアップグレード性
zkSyncプロトコルの初期段階でのアップグレード性により、革新、反復、バグ修正を迅速に行うことができます。もしユーザーが新しいアップグレードのたびに資産を移行しなければならないとしたら、大規模なUXの問題になります（数ヶ月ごとにUniswap v2からv3に移行することを考えてみてください）。しかし、アップグレード可能性は諸刃の剣です。それは、追加的な信頼の前提とリスクの増加を伴います。
私たちは、ユーザーが開発チームやガバナンスだけにセキュリティを頼るべきではないと強く信じています。そのため、私たちのzkRollupには、バリデータによる検閲からユーザーを守るための優先キュー/緊急終了メカニズムがあります：バリデータの調整に関わらず、常にzkSyncを終了することができます。しかし、チェックされていないアップグレード可能なバックドアがあると、この目的が完全に失われてしまいます。
zkSync 2.0のために良いバランスを見つけるために。
当初、アップグレードはzkSyncのガバナンスによって、展開される前に4週間のタイムロックをかけて開始することができます。ガバナンスの大部分が破損していたとしても、タイムロックにより、ユーザーは優先キュー/緊急退出メカニズムを介してオプトアウトする時間が与えられます。
プロトコルがテスト後に、プロトコルは不変となりユーザーは新しいバージョンへの参加を求められます。
zkSyncセキュリティ協議会
最後にもう一つのケースを説明しておきます。理論的には、特定のトランザクションによってzkEVMが内部的に失敗するバグが発生する可能性があります。そのようなトランザクションが優先キューに提出され、処理できない場合、システムは停止し、緊急モードに入ります。この問題を修正するアップグレードは、タイムロック期間である4週間よりも早く行うことができないため、zkSyncのすべての資本が4週間以上凍結されることになります。
このような事態を防ぐために、イーサリアムコミュニティの尊敬される15人のメンバーが、緊急時に介入することに合意しました。zkSync Security Councilは以下のメンバーで構成されています：
- Aave
- Itamar Lesuisse (Argent)
- Mike McDonald (Balancer)
- James Prestwich (cLabs)
- Michael Egorov (Curve)
- Jack Baumruk (Dekrypt)
- Haseeb Qureshi (Dragonfly)
- Justin Drake (Ethereum Foundation)
- Stefan George (Gnosis)
- Baek Kim (Hashed)
- Chris Burniske (Placeholder)
- Nick Grossman (USV)
- Will Harborne (ZK Validator)
- Sergej Kunz (1inch)
- Lasse Clausen (1kx)
セキュリティ評議会は、通常のアップグレード・プロセスでは解決できない状況を支援します。彼らの権限は、4週間のタイムロック通知期間を短縮することに限られています。セキュリティ協議会は zkSync ガバナンスの一部ではなく、またガバナンスをバイパスしてアップグレードを開始することもできません。
Gnosis Safe Multisigの協力を得て、以下のようなルールで運営されます:
- 8/15署名でタイムロックが2週間に短縮
- 8/15の署名でタイムロックを2週間に短縮、10/15の署名でタイムロックを1週間に短縮
- 12/15の署名でタイムロックが3日に短縮
最悪のケースに備えて、最小限のタイムロックは常に残っています。安全保障理事会は、ゼロ知識証明の安全性に対する信頼性を高めるための一時的な措置に過ぎない。純粋なオプトインによるアップグレードの仕組みに切り替わった後は、もはや必要ありません。
結論
ユーザーの資金の安全性は0日目からの最優先事項です。3年前にMatter Labsが設立されたとき、私たちはL1と同じセキュリティ特性を提供する唯一のL2スケーリング技術であるzkRollupsにのみ焦点を当てることにしました。教育、透明性、および当社の3ファクタアプローチにより、ユーザーがzkSyncを使用する際に安心していただけることを願っています。
資金のセキュリティについてご質問がある場合は下記リンクをフォローし、お問い合わせください。
