TL;DR
最初のレベルのタイトル
1. 私たちは PE-VM に基づいた最初の ZKVM の構築に懸命に取り組んでおり、ZK フレンドリーな設計と ZK アルゴリズムの改良により、より高いスループット レートを実現しており、その技術的特徴は次のとおりです。
a. 早く証明してください:
i. ZK フレンドリー: 回路規模が小さくなり、基礎となる制約ユニットが簡素化されます。
ii. ZK 実装の高速化: plonky 2 のさらに最適化された改善。
b. 高速実行:
並列実行 VM を採用します (並列証明テクノロジのコンテキストでは、証明の生成時間が短いほど、効果がより顕著になります)。
2. 私たちが行ったこと:
a. 2022 年 7 月に、OlaVM のホワイト ペーパーがリリースされました。
c. 現時点で最も実行効率が高い ZK アルゴリズムについては、plonky 2 の回路設計とアルゴリズムの研究が完了しており、リンク https://github.com/Sin 7 Y/plonky 2/tree/ を開くことができます。 main/plonky 2/designs を参照して、plonky 2 のデザインについて詳しく学びます。次のステップで最適化および改善します。引き続き注目してください。 。 。
最初のレベルのタイトル
私たちは何をしているのですか
OlaVM は、並列実行 VM を導入した最初のレイヤー 2 ZKVM であり、2 つのスキームの技術的ポイントを統合して、より高速な実行速度とより高速なプルーフ速度を実現し、将来的にはより高いシステム スループットを実現します。
現在のイーサリアム システムでは、スループットが遅い主な理由は 2 つあります。
1. コンセンサスプロセス: 各ノードはトランザクションを繰り返し実行して、トランザクションの正当性を検証します。
2. トランザクションの実行: トランザクションの実行はシングルスレッドです。問題の最初の点を解決し、同時にプログラム可能である必要があるために、多くのプロジェクトが ZK(E)VM に関する研究を実施しました。つまり、トランザクションはチェーンから外れて完了し、状態は検証されるだけです。 (もちろん、他の拡張ソリューションもありますが、ここでは説明しません。詳細が多すぎるため)、システムのスループットを実際に向上させるには、次のことが必要です。できるだけ早く証拠を生成する
現段階では、ZK(E)VM の場合、システム全体のスループットに影響を与えるボトルネックは証明の生成にありますが、並列証明を使用してシステム全体のスループットを高速化すると、ブロックの速度が向上します。開始時間が早ければ早いほど (ZK アルゴリズムの進化と加速方法の改善により、プルーフ生成時間が短くなり、このモジュールの改善効果がより顕著になります)。
高スループットを実現するにはどうすればよいでしょうか?
副題
できるだけ早くプルーフを生成します (現時点では最優先)
証明の生成を高速化するには、回路規模をできるだけ小さくすることと、アルゴリズムをできるだけ速く実行することの 2 つの部分に大別できます。アルゴリズムをできるだけ速く実行するには、アルゴリズム自体のパラメータを改善する (小規模ドメインの選択など）や外部実行環境の改善（ハードウェア アクセラレーションなど）。
1. 制約サイズをできるだけ小さくする
a. Prophet
はい、プルーフ生成の消費量は、制約の全体的なスケール n に強く関連しています。制約の全体的なスケールを大幅に削減できれば、プルーフの生成にかかる時間は大幅に短縮されます。これには、VM の設計において、全体的な制約サイズを減らすために可能な限り多くの設計を使用する必要があります。
b. Zk-friendly
Prophet は「預言者」を意味し、最初に「予測」し、次に「検証」します。その主な目的は次のとおりです。一部の複雑な計算では、これらの複雑な計算を実装するために VM 命令を使用する必要がありません (大量の命令を消費する可能性があるため、 VM の実行軌跡と最終的な制約スケールを増加させるため)、代わりに、組み込みの Prophet を使用して計算を完了し、結果が VM に送信され、VM は結果の正当性チェックのみを実行します。 。 Prophet は、除算計算、平方根計算、立方根計算などの特定の計算関数を備えたいくつかの組み込み関数です。実際のシナリオに従って Prophet ライブラリを徐々に強化していき、最も複雑な計算シナリオでは、全体的な制約が緩和されるようにします。削減効果を最大限に発揮します。
計算が複雑な場合、Prophet は VM によって実行される軌道のサイズを削減するのに役立ちますが、その前に、計算自体が Zk フレンドリーであることが望ましいと考えます。したがって、設計では、一般的なハッシュ アルゴリズム、署名検証アルゴリズムなどの Zk に適した操作を使用します。これらの最適化は、他の ZK(E)VM ソリューションにもよく存在します。しかし、最後の鍵は、 Zk に優しい複雑な計算を選択します。この複雑な計算をより小さな制約で制約するにはどうすればよいでしょうか?
コンピューティング ロジックの実行に加えて、VM 自体には、RAM 操作など、証明する必要がある他の操作もあります。スタックベースの VM は、アクセスされるたびに POP および PUSH 操作を実行する必要があります。検証レベルでは、この操作の妥当性を検証する必要があります。これらの操作は独立したテーブルを形成し、制約を使用してこれらを検証します。スタック操作の有効性。レジスタベースの VM は同じロジックを実行しますが、結果として得られる実行トレースが小さくなるため、制約の規模も小さくなります。
Plonky 2 のパフォーマンスが優れているため、一時的に Plonky 2 を OlaVM の ZK バックエンドとして使用します。私たちは Plonky 2 のゲート設計、ガジェット設計、プロトコル原理を深く分析し、いくつかの最適化の方向性を見つけました。詳細については、Github リポジトリ: Plonky 2 設計をフォローしてください。
副題
トランザクション実行の高速化 (この段階ではボトルネックではありません)
プルーフの生成に数時間などの長い時間がかかる場合、並列実行によってもたらされる改善は明らかではありません。この並列処理によってもたらされる効果を改善できるシナリオは 2 つあります。1 つは、達成するために集約されたブロックの数が増加することです。量的変化 質的変化を引き起こすこと、もう一つは校正時間が大幅に短縮されることです。もちろん、二つのプロモーション効果が重なればさらに良くなります。
最初のレベルのタイトル
互換性?
もちろん、OlaVM の主な目標は依然として高スループットの ZKVM を構築することですが、最初のステップがうまく完了したら、互換性、特にイーサリアムとの互換性の実現を検討する予定ですが、これもロードマップの中間に含まれます。
All Together
上記のすべてのモジュールを統合した、システム全体のデータ フロー チャートは次の図に概略的に示されます。
Coming Soon
最初のレベルのタイトル
1. 2022 年 12 月初旬:
a. OlaVM DSL 設計を完了します。
b. OlaVM プリコンパイル済みコントラクトの設計と開発を完了します。
参照する
参照する
1.OlaVM:https://olavm.org/whitepaper/OlaVM-07-25.pdf
2.Plonkish:https://zcash.github.io/halo 2/concepts/arithmetization.html
3.Cairo VM:https://starknet.io/docs/how_cairo_works/cairo_intro.html#field-elements
4.Plonky 2:https://github.com/Sin 7 Y/plonky 2/blob/main/field/src/goldilocks_field.rs
5.Ingonyama:https://github.com/ingonyama-zk/cloud-ZK
6.Semisand:https://semisand.com/
7.Plonky 2 designs:https://github.com/Sin 7 Y/plonky 2/tree/main/plonky 2/designs
私たちについて
私たちについて
Sin7y は 2021 年に設立され、トップのブロックチェーン開発者で構成されています。私たちはプロジェクト インキュベーターであると同時にブロックチェーン テクノロジー研究チームでもあり、EVM、レイヤー 2、クロスチェーン、プライバシー コンピューティング、自律型決済ソリューションなどの最も重要で最先端のテクノロジーを研究しています。
GitHub | Twitter | Telegram | Medium| Mirror | HackMD | HackerNoon
IOS
Android