From 65e70b580d8338ffd67931418b350476cf9f8978 Mon Sep 17 00:00:00 2001 From: mashharuki Date: Sat, 8 Jun 2024 21:41:27 +0900 Subject: [PATCH] chore: Update memo2.md with information about ZK-rollup and its advantages --- docs/WhitePaper.md | 384 +++++++++++++++++++++++++++++++++++++++++++++ docs/memo2.md | 32 ++++ 2 files changed, 416 insertions(+) create mode 100644 docs/memo2.md diff --git a/docs/WhitePaper.md b/docs/WhitePaper.md index 9ecc6a8..a7934fc 100644 --- a/docs/WhitePaper.md +++ b/docs/WhitePaper.md @@ -258,3 +258,387 @@ Client Side Validation に使うことで、Stateless の力を最大化 ⇨ 無制限の並列化が可能になる。 ⇨ 他にこの考え方を取り入れているのが Mina Protocol + +## 以下もう一度翻訳した時の記録 + +タイトルと著者 +Intmax2: 最小限のオンチェーンデータと計算コストを実現する ZK-rollup、分散型アグリゲーター搭載 + +エリック・ライバッケン 1、レオナ・ヒオキ 1、マリオ・ヤクセティグ 2 + +1 Intmax (paper@intmax.io) +2 ポルト大学 + +概要 +私たちは、Intmax2 というブロックチェーンのスケーリングソリューションを紹介します。これは、ステートレスかつ許可不要なブロック生成を特徴とするゼロ知識ロールアップ（ZK-rollup）プロトコルであり、基盤となるブロックチェーンのデータ使用量と計算コストを最小限に抑えるものです。私たちのアーキテクチャは、既存の ZK-rollup とは異なり、データと計算コストのほとんどをクライアント側に移し、ブロックプロデューサーや基盤となる Layer 1（L1）ブロックチェーンに大きな負担をかけません。ブロックプロデューサーの唯一の仕事は、定期的に一連のトランザクションのコミットメントを生成し、各送信者に含有証明を配布し、送信者からの署名を収集・集約することです。この設計により、許可不要でステートレスなブロック生成が可能となり、ユーザー数に応じた高いスケーラビリティを実現します。 + +キーワード: ゼロ知識証明、ステートレス ZK-Rollup、ブロックチェーンスケーリング + +要約 +Intmax2 は、ゼロ知識ロールアップ（ZK-rollup）プロトコルを用いた新しいブロックチェーンスケーリングソリューションです。データと計算コストのほとんどをクライアント側に移すことで、ブロックプロデューサーの負担を軽減し、高いスケーラビリティを実現しています。 + +イントロダクションの翻訳 +1 はじめに +ブロックチェーンのエコシステムが進化するにつれ、セキュリティを維持しつつ取引コストを削減し、全体のスループットを向上させるためのスケーリングソリューションの緊急性が高まっています。Layer 2（L2）技術、特にロールアップは、これらの課題を克服するための重要なツールとして注目されています。その中でも、ゼロ知識ロールアップ（ZK-rollup）は、多数の取引を 1 つの証明にまとめ、オンチェーンで迅速かつ低コストで検証できるという独自の能力から、大きな期待を集めています。 + +既存の ZK-rollup は、基盤となる Layer 1（L1）ブロックチェーンから計算コストを移すことには成功しているものの、ユーザーの残高を検証するために必要なすべてのデータを L1 に投稿しなければならないという制約があります。通常、このデータには、取引送信者、トークンのインデックス、金額、および各取引の受取人が含まれます。このため、サポートできる 1 秒あたりの取引数が制限されています。 + +要約 +ブロックチェーンのスケーリングソリューションの必要性が高まる中、ゼロ知識ロールアップ（ZK-rollup）は、多数の取引を効率的に処理する手段として注目されています。しかし、既存の ZK-rollup は、データのオンチェーン投稿が必要なため、取引数の制限があるという問題があります。 + +1.1 データ可用性 +ブロックチェーンの基本的なボトルネックは、データ可用性と呼ばれる問題です。データ可用性とは、ブロックチェーンの現在の状態（例えばアカウント残高）を証明するために取引データが利用可能である必要があることを意味します。これは Layer 1 のブロックチェーンとロールアップの両方にとって問題です。 + +Layer 1 のブロックチェーンは、全ての取引データが公開され、ノードがブロックチェーンを有効とみなすために必要な方法でデータ可用性を達成します。ロールアップは、基盤となるブロックチェーンのデータ可用性を利用し、全ての取引データを L1 に投稿することでデータ可用性を実現します（例えば、イーサリアムでの calldata や blob データの使用）。 + +このデータは多くのノード間で複製される必要があるため、利用可能なデータの量には限界があり、これがブロックチェーンやロールアップがサポートできる 1 秒あたりの取引数を制限します。スマートコントラクトのブロックチェーンの場合、完全な取引データを提供する必要がありますが、シンプルな支払い取引の場合、ブロック内の取引セットへのコミットメント（例えば、Merkle ツリールート）と、コミットメントに署名した送信者のセットを提供するだけで十分です。送信者は、自分の取引が含まれている証明を受け取ったことを確認します。 + +ユーザーは、自分の送信した取引の含有証明と受け取った取引の含有証明および十分な残高のゼロ知識証明（ZK 証明）を組み合わせることで、自分の残高の ZK 証明を生成できます。これらの証明はオフチェーンで送信者から提供されます。私たちのロールアップデザインはこの方法を用いることで、既存の代替手段と比べてスループットを向上させています。 + +さらに、このデザインにより、ブロック生成を許可不要で並行して行うことができ、リーダー選出やブロック生成者間の調整を必要としません。ブロック生成者は取引の有効性を検証しないため、完全にステートレスで非常にシンプルかつ検閲抵抗性のあるロールアップデザインを実現しています。 + +1.2 私たちの貢献 +Intmax2 は、効率的かつステートレスなロールアップデザインであり、以下の特徴を持ちます： + +既存のロールアップよりも少ないオンチェーンデータを使用し、イーサリアム上で 1 秒あたり最大 7500 の取引バッチを処理できます。各取引バッチは無制限のトークンを無制限の受取人に転送できます。 +許可不要のブロック生成を提供します。 +伝統的な ZK-rollup よりも強力なプライバシー機能を提供します。 + +要約 +データ可用性はブロックチェーンのスケーラビリティの主要な課題です。Intmax2 は、この問題を解決するために、データと計算の大部分をクライアント側に移し、ステートレスかつ許可不要のブロック生成を実現しています。これにより、既存のロールアップよりも高いスループットと強力なプライバシーを提供します。 + +2 簡易設計の説明 +このセクションでは、ZK 証明を使用しない簡易版の設計について説明します。この簡易設計は、オンチェーンのデータ消費を抑えることができます（取引送信者ごとに 4-5 バイト）が、効率的でなく、プライバシーも保護されません。セクション 4 では、効率とプライバシーを達成するために、ZK 証明を設計に追加します。 + +2.1 概要 +簡易設計の動作は次の通りです。この設計の中心には、プログラム可能なブロックチェーン（例えばイーサリアム）にデプロイされたロールアップコントラクトがあります。ロールアップに資金を預けるには、ユーザーは受取人の L2 アドレスと共に資金をロールアップコントラクトに送信し、コントラクトはその預金を契約のストレージに記録します。 + +ロールアップ内で資金を転送するには、L2 アカウントの一部がまず取引を単一のアグリゲーターに送信し、アグリゲーターはその取引を Merkle ツリーの葉に挿入します。その後、アグリゲーターは各送信者に Merkle ルートとその送信者の取引の Merkle 証明を送ります。各送信者は、自分の公開 BLS キーで Merkle ルートに署名し、その署名をアグリゲーターに送り返します。 + +アグリゲーターは署名を 1 つの集約署名にまとめ、Merkle ルート、集約署名、および集約署名に含まれる送信者の公開鍵リストをロールアップコントラクトに送信します。ロールアップコントラクトは署名を検証し、ルート、署名、および送信者リストをそのストレージに追加します。 + +各送信者は、その取引の Merkle 証明をオフチェーンで各取引受取人に送信し、送信者が取引に十分な残高を持っていることを証明するために、以前の Merkle 証明も一緒に提供します。ユーザーは、集約者や他のユーザーから受け取ったすべての Merkle 証明を追跡し、これらの証明を「バランス証明」と呼びます。ユーザーが資金を L1 に引き出したい場合、このバランス証明をロールアップコントラクトに送ります。 + +次に、簡易設計の詳細を説明します。 + +2.2 記法 +X と Y が集合である場合、Y^X は X から Y へのすべての関数の集合を表します。関数 f ∈ Y^X を X の要素から Y の要素への写像と呼びます。 + +2.3 設定 +この設計は、認証された辞書スキーム 3 AD、署名集約スキーム 4 SA、および衝突耐性ハッシュ関数 H : {0, 1}^\* → {0, 1}^n に依存します。セキュリティパラメータ λ ∈ N が与えられた場合、認証された辞書スキーム +AD.(K, M, C, Π, Commit, Verify) +および署名集約スキーム +SA.(Kp, Ks, Σ, KeyGen, Sign, Aggregate, Verify)を設定します。 + +私たちは K2 := SA.Kp をエイリアスとして使用し、これを L2 アカウントの集合と呼びます。また、L1 アカウントの集合 K1 に依存し、取引値とアカウント残高の集合として使用される格子順序付きアーベル群 V に依存します。V+ ⊂ V は非負値の部分集合を表します。 + +2.4 ロールアップコントラクト +ロールアップコントラクトはプログラム可能なブロックチェーン（例：イーサリアム）にデプロイされたスマートコントラクトであり、ロールアップの状態を管理し、預金、転送、および引き出しを管理します。ロールアップコントラクトの内部状態は、これまでにロールアップに追加されたすべてのブロックのリストで構成されます。私たちの設計では、預金ブロック、転送ブロック、および引き出しブロックの 3 種類のブロックがあります。これらのブロックはそれぞれ Bdeposit、Btransfer、Bwithdrawal と呼ばれます。 + +B := Bdeposit ⨿ Btransfer ⨿ Bwithdrawal がすべてのブロックの集合であり、契約状態は正式には +Scontract := B^\* +と定義されます。ロールアップコントラクトがブロックチェーンにデプロイされるとき、空のリスト()で初期化されます。 + +2.5 預金 +L1 から L2 に資金を預けるには、L1 ユーザーは資金を受取人の L2 アドレスと共にロールアップコントラクトに送信します。ロールアップコントラクトは、指定された受取人と預け入れ金額からなる預金ブロックを構築します。正式には、預金ブロックの集合は次のように定義されます： +Bdeposit := K2 × V+. +コントラクトはこの預金ブロックをストレージ内のブロックリストに追加します。 + +要約 +Intmax2 の簡易設計は、オンチェーンデータ消費を抑え、資金の預金、転送、引き出しを管理するロールアップコントラクトを用いています。この設計は、ZK 証明を使用しないため効率的ではなく、プライバシーも提供しませんが、基本的なロールアップ機能を理解するための良い出発点となります。次のセクションでは、ZK 証明を追加することで、効率とプライバシーを向上させます。 + +2.6 資金の転送 +ここでは、ロールアップ上で資金を転送するプロトコルについて説明します（図 1 参照）。L2 アカウントから資金を転送するためには、アカウント所有者がまず、各取引の受取人に送る金額をマッピングする取引バッチを作成します。受取人は L2 アカウントまたは L1 アカウント（セクション 2.7 で述べるように L1 に引き出す場合）です。正式には、K を K1 と K2 の和集合とすると、取引バッチは VK+の要素、すなわち K から V+への写像です。 + +S ⊂ K2 の送信者の集合があり、各送信者 s ∈ S が秘密鍵 sks と送信したい取引バッチ ts ∈ VK+を持っているとします。転送プロトコルは 2 つのフェーズに分かれています。第 1 フェーズでは、送信者が単一のアグリゲーターと協力して転送ブロックを作成し、それをロールアップコントラクトに追加します。第 2 フェーズでは、転送ブロックがロールアップコントラクトに追加された後、各取引送信者 s は（オフチェーンで）各受取人（すなわち ts(r) ≠ 0 の r ∈ K のアカウント）に、転送ブロックで送信者が受取人に指定した金額を送ったことを証明するために必要なデータを送ります。次に、転送プロトコルの 2 つのフェーズを詳細に説明します。 + +フェーズ 1：転送ブロックの構築と追加 +取引バッチを送信するために、送信者はまず単一のアグリゲーターを選択し、共通のビット文字列 extradata ∈ {0, 1}\*に合意します。このビット文字列は、リプレイ攻撃や遅延ブロックの公開に対する保護を実装するために使用されます（セクション 2.8 参照）。その後、送信者とアグリゲーターは以下のプロトコルでやり取りを行います。 + +まず、各送信者 s はランダムなソルト salts を選び、そのソルトで取引バッチをハッシュ化します。 +hs ← H(ts, salts) +そして、このハッシュ hs をアグリゲーターに送ります。 + +アグリゲーターは送信者からすべての取引バッチハッシュを収集します。S' ⊂ S をアグリゲーターに取引バッチハッシュを送信した送信者の部分集合とします。アグリゲーターは辞書（S', h）を構築し、ここで hs は s ∈ S'の取引バッチハッシュです。そして、辞書コミットメントと検索証明を構築します： +(C, (S', π)) ← AD.Commit(S', h) +アグリゲーターは各ユーザー s ∈ S'に辞書コミットメント C とユーザーの取引バッチハッシュの検索証明 π を送ります。 + +辞書コミットメントと検索証明を受け取ると、各ユーザー s は検索証明がコミットメントと一致するかどうかを確認します： +AD.Verify(πs, s, hs, C) ?= True +検証が成功した場合、ユーザーは次の署名を生成します： +σs ← SA.Sign(sks, (C, aggregator, extradata)) +そして、この署名をアグリゲーターに送ります。 + +アグリゲーターはユーザーから署名を収集し、それを検証します。S'' ⊂ S'を有効な署名を送信した送信者の部分集合とします。アグリゲーターは集約署名を構築します： +σ ← SA.Aggregate((s, σs)s∈S'') +そして、転送ブロックと呼ばれるタプル（aggregator, extradata, C, S'', σ）を構築します。正式には、転送ブロックの集合は次のように定義されます： +Btransfer = K1 × {0, 1}\* × AD.C × P(K) × SA.Σ +アグリゲーターはこの転送ブロックを L1 アカウントを使用してロールアップコントラクトに送ります。 + +転送ブロックを受け取ると、ロールアップコントラクトは集約署名を検証します： +SA.Verify(S'', (C, aggregator, extradata), σ) ?= True +さらに、取引がアカウントアグリゲーターからのものであることも確認します。これらのチェックが有効であれば、契約は転送ブロックをストレージ内のブロックリストに追加します。無効であれば、取引は取り消されます。 + +要約 +このセクションでは、ロールアップ上で資金を転送するためのプロトコルについて説明しました。送信者はまず取引バッチを作成し、アグリゲーターと協力して転送ブロックを生成し、それをロールアップコントラクトに追加します。取引が完了すると、送信者はオフチェーンで受取人に取引の証拠を送ります。これにより、効率的で信頼性の高い資金転送が可能になります + +フェーズ 2：バランス証明の維持と配布 +自分のアカウントのバランスを証明するためには、各ユーザーがバランス証明を維持する必要があります。バランス証明とは、アグリゲーターから（取引を送信する際に）および他のユーザーから（取引を受信する際に）受け取った取引バッチ、対応するソルト、検索証明のコレクションです。バランス証明の集合を次のように定義します。 + +# Π + +𝐷 +𝑖 +𝑐 +𝑡 +( +𝐴 +𝐷 +. +𝐶 +× +𝐾 +2 +, +( +𝐴 +𝐷 +. +Π +× +0 +, +1 +∗ +) +× +𝑉 +𝐾 + +- ) + Π=Dict(AD.C×K2,(AD.Π×0,1 + ∗ + )×VK+) + バランス証明が有効であるかは、次のアルゴリズムが True を返すかどうかで判断します。 + +𝑉 +𝑒 +𝑟 +𝑖 +𝑓 +𝑦 +: +Π +→ +𝑇 +𝑟 +𝑢 +𝑒 +, +𝐹 +𝑎 +𝑙 +𝑠 +𝑒 +Verify:Π→True,False + +( +𝐾 +, +𝐷 +) +7 +→ +(K,D)7→ + +( +𝐶 +, +𝑠 +) +∈ +𝐾 +(C,s)∈K + +( +( +𝜋 +, +𝑠 +𝑎 +𝑙 +𝑡 +) +, +𝑡 +) += +𝐷 +( +𝐶 +, +𝑠 +) +((π,salt),t)=D(C,s) + +𝐴 +𝐷 +. +𝑉 +𝑒 +𝑟 +𝑖 +𝑓 +𝑦 +( +𝜋 +, +𝑠 +, +𝐻 +( +𝑡 +, +𝑠 +𝑎 +𝑙 +𝑡 +) +, +𝐶 +) +AD.Verify(π,s,H(t,salt),C) +言い換えれば、有効なバランス証明は、コミットメント送信者ペア（C, s）を、t ∈ VK+の取引バッチ、salt はランダムなソルト、π ∈ AD.Π は、H(t, salt)がコミットメント C を持つ認証辞書のインデックス s の値であることを示す有効な検索証明にマッピングする辞書です。 + +各ユーザーは、空の辞書として初期化されるバランス証明を維持します。転送プロトコルの第 2 フェーズでは、各取引送信者はアグリゲーターから受け取った（もし受け取った場合）対応する検索証明とともに取引バッチを自分のバランス証明に追加します。 + +図 1. 転送プロトコルの説明 +この例では、アリスがボブに 5 コインを送ろうとしています。 + +a) アリスはまず、ボブに 5 コインを送る単一の取引で構成される取引バッチのハッシュとランダムなソルトをアグリゲーターに送ります。 + +b) アグリゲーターは、アリスの取引バッチハッシュと他の送信者の取引バッチハッシュで構成されるマークルツリーを作成します。 + +c) アグリゲーターは、アリスに彼女の取引バッチのマークル証明を送ります。 + +d) アリスはマークル証明を確認し、あらかじめ決められたエクストラデータ e とともにマークルルートに署名します。この署名はアグリゲーターに送られます。 + +e) アグリゲーターはすべてのユーザーからの署名を収集し、転送ブロックを構築してロールアップ契約に送ります。 + +f) アリスは自分の取引が含まれるブロックが公開されるまでロールアップ契約に追加されるブロックを監視します。 + +g) アリスは取引バッチ、ソルト、マークル証明を追加してバランス証明を更新します。 + +h) アリスは更新されたバランス証明をボブに送ります。 + +i) ボブはアリスから受け取ったバランス証明と自分のバランス証明を統合して更新します。 + +取引バッチの各受信者は、新しいバランス証明を受け取った後、それを自分のバランス証明と統合します。具体的には、受信者であるボブの現在のバランス証明を πb ∈ Π とし、送信者であるアリスから受け取ったバランス証明を πa ∈ Π とします。この場合、ボブは次のアルゴリズムを実行します。 + +受け取ったバランス証明を検証します： +Verify(πa) ?= True. +有効であれば次のステップに進み、そうでなければ終了します。 + +バランス証明 πb を πa と統合して更新します： +πb ← Merge(πa, πb) +Merge は付録 A.1 で定義された辞書マージアルゴリズムです。 + +アカウントのバランスを計算するために、ユーザーはバランス関数 Bal を使用します。これは付録 B で定義されています。K+ := K1 ⨿ K2 ⨿ {Source}とし、Source は入金と引き出しを表す特別なアカウントです。バランス関数は、バランス証明 π ∈ Π とロールアップ契約の現在の状態(B*) ∈ B*を受け取り、バランス証明によって証明可能なロールアップ内の各アカウントのバランスを返します。 + +2.7 引き出し +ユーザーが L2 アカウントから L1 アカウントに資金を引き出したい場合、まず転送プロトコルを使用して資金を L1 アカウントに転送する必要があります。転送ブロックがロールアップ契約に追加されると、契約は自動的に資金を L1 に引き出しません。代わりに、引き出しを開始するためには、L1 アカウントの所有者が現在のバランス証明 π ∈ Π を含む引き出しリクエストをロールアップ契約に送信する必要があります。 + +バランス証明を受け取ると、ロールアップ契約は次のステップを実行します。 + +まず、バランス証明を検証します： +Verify(π) ?= True. +バランス証明が有効であれば、ロールアップ契約は引き出しブロックを構築します。これは、バランス証明と現在のロールアップ状態に基づいて計算された各 L1 アカウントのロールアップ内のバランスです： +B ← Bal(π, B*)K1 +B*はロールアップ契約内の現在のブロックリストです。正式には、引き出しブロックの集合は次のように定義されます： +Bwithdrawal = VK1+ +契約は引き出しブロック B をストレージ内のブロックリストに追加します： +B* ← (B*||(B)) + +各 L1 アカウント k ∈ K1 に対して、契約はその L1 アカウントに金額 Bk を引き出します。 +要約 +転送プロトコルの第 2 フェーズでは、各ユーザーが自分のバランス証明を維持し、取引の各受信者に更新されたバランス証明を送信します。受信者はこれを自分のバランス証明と統合します。ユーザーが資金を引き出す場合、まず転送プロトコルを使用して資金を L1 に転送し、現在のバランス証明を提出して引き出しを開始します。 + +2.8 リプレイ攻撃と遅延ブロック公開に対する保護 +悪意のあるアグリゲーターが行う可能性のある攻撃には、対策が必要です。1 つの攻撃は、遅延ブロック公開です。これは、悪意のあるアグリゲーターが転送ブロックの公開を長期間遅らせることで、システムのライブネス（活性）に問題を引き起こすものです。もう 1 つの攻撃はリプレイ攻撃で、悪意のあるアグリゲーターが同じ転送ブロックを何度も公開することで、送信者の残高を消耗させるものです。これらの攻撃に対する保護をプロトコル内で行う代わりに、以下の方法でプロトコル外で対策を講じることができます。 + +ユーザーがアグリゲーターを信頼するために、アグリゲーターは L1 にリレイヤー契約をデプロイすることで、これらの攻撃を実行できないように自己制限を設けることができます。ユーザーの一部がこのアグリゲーターと転送ブロックを作成したい場合、アグリゲーターはまず、近い将来の締め切りを設定します。この締め切りを受け入れたユーザーは、この締め切りをエクストラデータとして使用し、リレイヤー契約のアドレスをアグリゲーターとして転送プロトコルに参加します。転送ブロックを構築した後、アグリゲーターは L1 のアドレスからリレイヤー契約に転送ブロックを送信します。このアドレスは契約によってホワイトリストに登録されており、先回り攻撃から保護されます。リレイヤー契約は転送ブロックを受信すると、送信者を確認し、エクストラデータフィールドの締め切りが現在の時間を過ぎていないかをチェックし、転送ブロックをロールアップ契約に転送します。これにより、遅延ブロック公開に対する保護が提供されます。 + +さらに、リレイヤー契約はロールアップ契約に転送した最後のブロックのタイムスタンプを保存し、新しい転送ブロックのタイムスタンプが前回転送したブロックよりも厳密に大きいことを確認してから転送します。これにより、リプレイ攻撃に対する保護が提供されます。 + +要約 +悪意のあるアグリゲーターによる遅延ブロック公開とリプレイ攻撃に対する保護のために、アグリゲーターは L1 にリレイヤー契約をデプロイし、ユーザーが設定した締め切りを守るよう自己制限を設けます。リレイヤー契約は転送ブロックをチェックしてロールアップ契約に転送することで、これらの攻撃からユーザーを保護します。 + +3 データ使用量と圧縮 +このセクションでは、私たちの設計のスケーラビリティを分析し、さらにスケーラビリティを高めるための圧縮方法について説明します。スケーラビリティの主なボトルネックは、転送ブロックのサイズです。転送ブロックのサイズは次の要素から構成されます： + +アグリゲーターの L1 アドレス（Ethereum では 20 バイト） +エクストラデータ文字列（32 バイト） +認証された辞書のコミットメント（32 バイト、これは Merkle ツリーのルートの場合） +ブロック内の送信者のサブセット S ⊂ K2（BLS 公開鍵のリストとしてエンコードされる場合、|S| × 96 バイト） +集約署名（BLS 署名の場合 48 バイト） +これにより、転送ブロックのサイズは|S| × 96 + 132 バイトとなります。ここで、|S|はブロック内の送信者の数です。従来のロールアップでは、すべてのトランザクションの詳細（送信者、受信者、トランザクションの量など）がブロックに含まれるため、これより大きくなります。また、従来のロールアップとは異なり、ブロックサイズはトランザクションの数ではなく送信者の数にのみ依存します。つまり、送信者は任意の数の受信者に対してトランザクションバッチを送信しても、転送ブロックのサイズに影響を与えません。 + +さらにスケーラビリティを向上させるために、セクション 2.8 で紹介したリレイヤー契約を使用して、プロトコル外でブロック圧縮を追加することができます。アグリゲーターは圧縮された転送ブロックをリレイヤー契約に送信し、リレイヤー契約はそれを展開してからロールアップ契約に転送します。シンプルな圧縮アルゴリズムは次のように機能します。ユーザーはアグリゲーターのリレイヤー契約に自分の公開 BLS キーを登録し、短い増分 ID を受け取ります。リレイヤー契約は、ID を BLS 公開鍵にマッピングする辞書を保存します。次に、アグリゲーターが転送ブロックをリレイヤー契約に送信するとき、送信者の公開鍵の代わりに短い ID を送信します。リレイヤー契約はその辞書で各 ID を参照し、公開鍵で転送ブロックを再構築してからロールアップ契約に送信します。ID のサイズは辞書内の総 ID 数に依存します。たとえば、100 億のアドレス（現在の世界人口より多い）をサポートするためには、各 ID はおよそ 33 ビット（約 4.15 バイト）必要です。これにより、ブロックサイズは約|S| × 4.15 + 132 バイトになります。 + +Ethereum 上で実装されると、ブロックあたり 0.375 MB のデータが提供され、12 秒ごとにブロックが生成されるため、理論的には 1 L1 ブロックあたり約 90000 の送信者、または 1 秒あたり 7500 の送信者を処理できることになります。Ethereum がさらにスケーリングを追加すると、この数は増加します。目標はブロックあたり約 16 MB にすることで、1 秒あたり約 320000 の送信者を処理できるようになります。 + +要約 +データ使用量と圧縮のセクションでは、転送ブロックのサイズを削減し、スケーラビリティを向上させる方法について説明しています。転送ブロックのサイズは、送信者の数にのみ依存し、圧縮を利用することでさらに効率化できます。圧縮アルゴリズムを使用することで、Ethereum の現在および将来のスケーラビリティ目標を達成することが可能になります。 + +4 プライバシーと効率の追加 +セクション 2 で説明したシンプルな設計はプライバシーが不足しています。なぜなら、トランザクションの受信者が意図されていない他のトランザクションに関する情報を取得することができるためです。また、バランスプルーフが大きく、検証コストが高いため（特に引き出し時にはオンチェーンで）、効率も不十分です。このセクションでは、再帰的な ZK プルーフを使用してプライバシーと効率を追加します。 + +4.1 ロールアップ契約の状態とブロックの追加手順の変更 +まず、ロールアップ契約を変更して、ロールアップに追加されたすべてのブロックのリストを保存する代わりに、履歴ルートのリストを保存するようにします。ここで、各ルートは{0, 1} +n のハッシュダイジェストであり、さらに、各 L1 アカウントを L1 アカウントに引き出された合計金額にマッピングするマッピングです。 + +plaintext +コードをコピーする +Scontract := ({0, 1} +n +) +∗ × VK1 + +- . + もし((rooti)i∈[N] + , withdrawn)が契約の現在の状態であり、B ∈ B + がロールアップに追加される新しいブロックである場合、契約は新しいブロックを以下のように追加します。もしブロックがデポジットブロックまたは転送ブロックである場合、契約は最新の履歴ルートと新しいブロックのハッシュ H(rootN , B)を取り、この新しい履歴ルートをその履歴ルートのリストに追加します。新しいブロックが引き出しブロックの場合、引き出された金額は現在の引き出し金額のマップに追加されます。 + + 4.2 転送プロトコルの変更 + 転送ブロックを構築し追加する方法に関する転送プロトコルのフェーズ 1 は、セクション 2.6 で説明された内容とまったく同じです。ただし、バランスプルーフを維持し配布する方法に関するフェーズ 2 は次のように変更されます。トランザクション送信者 s が受信者 r に資金を送信する場合、（単純な設計のように）送信者の完全なトランザクション履歴および他のユーザーの履歴を再帰的に提供する代わりに、以下のタプル（root、s、r、v、π）のみを提供します。 + +root ∈ {0, 1} +n：トランザクションを含むロールアップブロックの履歴ルート +s ∈ K2：送信者の L2 アドレス +r ∈ K：受信者のアドレス +v ∈ V+：トランザクション金額 +π：トランザクションの有効性証明、つまり、送信者 s がロールアップブロックの履歴ハッシュ root において金額 v で受信者 r にトランザクションを送信し、送信者がそれを送信するための十分な残高を持っていたことを証明する ZK プルーフ +これにより、受信者はこのトランザクションについてのみ情報を得、送信者の残高や他のトランザクションなど、他の情報についてはゼロ知識です。トランザクションの有効性証明を構築するために、各ユーザーは次のデータを維持する必要があります。 + +オンチェーンで転送ブロックに含まれている送信したすべてのトランザクションバッチとそれらに対応する塩とルックアップ証明 +他のユーザーから受信したすべての検証済みのトランザクション（ハッシュ、s、r、v、π） +これらのデータとロールアップに追加されたブロックのリストを使用すると、各ユーザーは自分のトランザクションの有効性証明を生成できます。 + +4.3 引き出しプロトコルの変更 +L1 アカウントの所有者がロールアップ内の残高を L1 に引き出す場合、引き出しリクエストをロールアップ契約に送信します。この引き出しリクエストには、L1 アドレス address ∈ K1、値 v ∈ V+、履歴ルート root ∈ {0, 1} +n、およびアドレスが履歴ルート root で少なくとも v をロールアップで受け取ったことを証明する ZK プルーフが含まれます。引き + +5 結論 +私たちは、従来の ZK-rollup アプローチから完全に脱却した新しい ZK-rollup アプローチである Intmax2 を提案しました。従来のアプローチとは異なり、私たちの解決策では、すべてのトランザクションデータを基礎となる L1 に投稿する必要がありません。これにより、前例のないスケーラビリティが実現されます。アグリゲーターが計算集中型のゼロ知識証明を実行する必要がないという事実を活用し、代わりにシステム内のユーザー側で計算を行うことで、私たちの設計は L2 スケーリングに対する革新的で実用的で強固なソリューションを提供します。最後に、アグリゲーターの役割を完全に許可されたものとし、私たちの設計はより多くの検閲に対して耐性のあるソリューションを可能にするため、ロールアップ領域での主要な既存の問題の 1 つに対処します。 + +## 再帰的 ZK 証明（Recursive ZK-proofs）とは＿？？ + +再帰的 ZK 証明（Recursive ZK-proofs）は、ブロックチェーン上のプライバシーや効率性を向上させるための技術の 1 つです。 + +再帰的 ZK 証明は、ゼロ知識証明（ZK-proofs）の一種であり、ブロックチェーン上で行われるトランザクションのプライバシーを強化するために使用されます。通常の ZK-proofs は、特定のトランザクションに関する情報を隠すことができますが、再帰的 ZK 証明では、特定のトランザクションに関する情報を隠しつつ、他のトランザクションや関連する情報も同時に隠すことができます。 + +具体的には、再帰的 ZK 証明を使用すると、トランザクションの送信者や受信者、トランザクションの金額などの情報を隠しつつ、そのトランザクションが正当であることを証明することができます。これにより、他の参加者がトランザクションの詳細を見ることなく、トランザクションがブロックチェーンに正しく含まれていることを確認できます。 + +再帰的 ZK 証明は、プライバシーを強化するだけでなく、効率性も向上させることができます。なぜなら、再帰的 ZK 証明を使用すると、ブロックチェーン上のトランザクションをよりコンパクトに表現できるため、データの転送や処理にかかるコストを削減できるからです。 + +要するに、再帰的 ZK 証明は、ブロックチェーン上でのトランザクションのプライバシーや効率性を向上させるための強力なツールであり、ブロックチェーン技術の発展に貢献しています。 diff --git a/docs/memo2.md b/docs/memo2.md new file mode 100644 index 0000000..91a2530 --- /dev/null +++ b/docs/memo2.md @@ -0,0 +1,32 @@ +概要と背景 + +ZK-rollup とは何か？従来のアプローチとの違いは？ +Intmax2 が提案する ZK-rollup の新しいアプローチについての紹介。 +Intmax2 の特徴 + +どのようにして従来の ZK-rollup と異なるのか？ +アグリゲーターの役割や許可の考え方について。 +プライバシーと効率性の向上 + +プライバシーの問題と効率性の問題をどのように解決するのか？ +Recursive ZK-proofs の導入によるプライバシーと効率性の向上。 +ロールアップ契約とブロックの追加手順の変更 + +ロールアップ契約の状態の変更とブロックの追加手順の変更について。 +新しいブロックが追加される際の手順とその影響。 +トランスファープロトコルの変更 + +トランスファープロトコルのフェーズ 1 とフェーズ 2 の変更について。 +トランザクションの妥当性の証明方法の変更とその理由。 +引き出しプロトコルの変更 + +L1 アカウントの引き出し手順の変更について。 +引き出し要求の処理方法の変更とセキュリティの向上。 +結論と将来展望 + +Intmax2 のアプローチの利点と課題について。 +今後の展望や可能性についての考察。 +質疑応答 + +参加者からの質問や意見の収集。 +各トピックに関する議論や補足説明。