ZKEVM でのメモリ制限の削除に関するいくつかの考え

ZKEVM は、ZK テクノロジーに基づいたプログラム可能な仮想マシンであり、仮想マシンによって実行されるすべての操作に対してゼロ知識証明 (zk 証明) を生成して、仮想マシンの操作の正しさを証明できます。 ZKEVM のいくつかの実装スキームの紹介と利点と欠点の比較については、V God の記事を参照してください。The different types of ZK-EVMs; 設計の詳細を知りたい場合は、PSE の ZKEVM スキーム (ネイティブ レベル) を読むこともできます。privacy-scaling-explorations/zkevm-specsPolygon の ZKEVM 設計 (バイトコード レベル):Polygon zkEVM Documentation; Sin7y の ZKEVM 設計 (言語レベル):OlaVM: An Ethereum compatible ZKVM。ソリューションに関係なく、zk を使用して、次のような VM のすべての動作を制限する必要があります。

• 契約計算ロジックの実行

• メモリアクセスを実行する

• ハッシュ計算を実行する

• 世界状態の更新を実行する

• ...

誰もが知っているように、zk には圧縮計算の分野で大きな応用の可能性があり、元の計算がどれほど複雑であっても、その検証プロセスは非常に効率的であり、これはすべての zk アルゴリズムの基本スキルです。したがって、zk は計算部分 (コントラクト ロジック、ハッシュ計算など) で優れた役割を果たします。一部のデータは事前​​にメモリに配置し、計算を実行するときにフェッチする必要があります。

ほとんどの VM はメモリの読み取りと書き込みを行うため、これらのメモリ アクセス操作の正確性を制限する必要があります (たとえば、特定のアドレスから読み取られたデータが最後に書き込まれたデータと同じであるかどうかの一貫性チェック)。それ自体は複雑ではありません (ケースが少ない) が、メモリ アクセスの数が多いため、多項式の次数が非常に高く、メモリ関連の制約に時間がかかることがわかります。

最初のレベルのタイトル

文章

によるEVM画像の説明

文章

文章

文章

•  MSTORE(x,文章

•  MSTORE8(x,y): アドレス x から開始して、y の 8 バイトを書き込みます (下位ビットの開始) 興味のある読者は見つけることができます。EVM Playground文章

存在する

存在するOlaVMセクション 5.3.5 では、メモリ制約の設計原則を確認できます (OlaVM メモリ関連の命令は EVM に似ています)。

OlaVM では、すべての RAM 操作が独立したテーブルを形成し、テーブルの内容はメモリとストレージの 2 種類で構成されます。ここでは、メモリの制約のみに焦点を当てます。メモリ操作の種類は、大きく次の 3 つのカテゴリに分類できます。

• 初期化操作

• 書き込み操作

• 読み取り操作

Init をトリガーするシナリオは ctx の変換、type の変更、addr の変更の 3 つで、いずれかのシナリオがトリガーされると制約が必要になります。操作タイプは w (書き込み)、v (値) は 0。 

上記の 3 つのシナリオがトリガーされない場合は、現在の操作の種類に応じて制限する必要があります。

• w (書き込み) 操作の場合、clk がインクリメントされ (rangecheck モジュールを呼び出し)、書き込まれた値 v が正しいことを制約する必要があります (コピー制約を呼び出し、OlaVM ではメモリ命令のすべての値を呼び出します)。レジスターから来ています）。

• r(read) 操作の場合、clk が増加するように制限する必要があります (rangecheck モジュールを呼び出します)。読み取られた値は最後に書き込まれた値と同じです。

いくつかの改善の可能性 (より ZK フレンドリー)

• Init 操作の場合、メモリ アドレスの初期化値を 0 に制約する必要がありますか?

初期化操作を制約する必要はないと思います。実際、どのアドレスでも、最初のアクセスは読み取り操作ではなく書き込み操作でなければならないと制約できます。ライトワンス メモリ モデルの場合、これはしたがって、仮想マシンのメモリモデルをライトワンスモデルに変更すると、メモリへのアクセス制限が軽減されます。

• 読み取り操作の場合、対応する制約を回避できますか。つまり、読み取り値が最後に書き込まれた値と一致するかどうかの検証を回避できますか。

VM 自体によって定義されたメモリ タイプの読み書きメモリは保証できないため、VM がこのメモリ アドレスの値を読み取る前に、このメモリ アドレスの値は変更されていないため、次のように等価性チェックを追加する必要があります。次の図に示されています。

このことから、この制約の主な理由は、メモリ モデルがメモリの読み取りと書き込みを行うことであり、アドレスの値が書き換えられる可能性があるためであることがわかります。 ) の場合、上記の一貫性制約を達成するための制約をメモリに書き込む必要はありません。

注: これは一般的なメモリ モデルであるため、仮想マシンの実装の難易度が高くなる可能性があります。また、この言語は Dapp 開発者にとってやや馴染みにくいため、最初にこの仮想マシンで高度な DSL を定義するべきではありません。フレンドリーを削除する必要があります。コンパイラ レベルで行われるため、これらは不親切で開発者には見えなくなります。したがって、上記のメモリ モデルが採用される場合、メモリ モジュールの制約は書き込み操作の制約のみになります。つまり、コピー制約を使用して、書き込まれた値が正しいことを確認します。制約なし： 

• メモリは一度しか書き込むことができないため、読み取られた値は書き込まれた値と同じになります。

• 読み取り clk は、最初に書き込んでから読み取ることしかできないため、書き込み clk より大きくなります。

• メモリは0に初期化されます（どちらも必要ありません）

WeChat 公開アカウント: Sin7Y

ethereum_evm_illustrated, page 51

私たちについて

Sin7y は 2021 年に設立され、トップのブロックチェーン開発者で構成されています。私たちはプロジェクト インキュベーターであると同時にブロックチェーン テクノロジー研究チームでもあり、EVM、レイヤー 2、クロスチェーン、プライバシー コンピューティング、自律型決済ソリューションなどの最も重要で最先端のテクノロジーを研究しています。

WeChat 公開アカウント: Sin7Y

GitHub | Twitter | Telegram | Medium| Mirror | HackMD | HackerNoon