zkSync と Ethereum は何が違うのか
zkHogeHoge って最近よく聞くけど...
ここ1年ほど、Polygon zkEVM, Astar zkEVM など "zk" を冠したチェーンの名前をよく聞くように思います。ゼロ知識証明を使っている Layer2 のチェーンで EVM と互換性があるんでしょ、程度のことはなんとなく知っていますが、結局何なの? Ethereum や無印の EVM と何が違うの?と言われるとうまく説明できなと思い、zk を冠したチェーンの整理と、zkSync と Ethereum の違いをまとめました。
zkEVM とは
zero-knowledge Ethereum Virtual Machine (zkEVM) とは、ゼロ知識証明と EVM の両方に互換性がある Layer2 ソリューションです。EVM との互換性をある程度保ちつつ、zk-rollups によりトランザクションのスループットを向上させていることが特徴です。
zkEVM の種類と主要プロジェクト
zkEVM 系のプロジェクトは複数存在し、プロジェクトごとに特徴があります。
以下の図表は Ethereum, EVM との互換性の度合いで整理したものです。
Vitalik 「The different types of ZK-EVMs」https://vitalik.eth.limo/general/2022/08/04/zkevm.html より引用
type | 特徴 | プロジェクト |
---|---|---|
1 | Ethereum と完全に互換性がある | Taiko |
2 | EVM と完全に互換性がある | |
2.5 | Gas 代を除いて EVM と互換性がある | |
3 | 概ね EVM に適合している | Polygon zkEVM, Astar zkEVM, Linea, Scroll |
4 | 高級言語で記述されている | zkSync |
type の数字が小さいほど Ethereum との差異が小さい代わりにゼロ知識証明の計算に比較的多くの時間を要し、大きくなるほど Ethereum との差異が大きくなる代わりに計算に要する時間は短くなります。
type2~3はゼロ知識証明で必要なプルーフの生成を高速化するために一部が変更されています。Type4 ではスマートコントラクトを高級言語から直接 ZK-SNARKs に対応した言語にコンパイルすることで、プルーフ生成にかかる時間を最適化しています。
Type3 に位置するプロジェクトの多くは今後の改善により Type2 に移行する予定であると発表していますが、数字が小さければ良いというわけではないことには注意が必要です。例えば、Ethereum, EVM と完全に互換性があり、かつゼロ知識証明の計算時間を短縮する独自の仕組みが搭載されている場合、それは Type3 に分類されます。目安の一つとしてご覧ください。
zkSync とは
zkSync は zk-rollups を利用した Layer2 ソリューションです。2020年に決済に特化した zkSync Lite(zkSync 1.0) がリリースされ、2023年3月に zkEVM に対応した zkSync Era(zkSync 2.0) が発表されました。
zkSync は 上記の分類の中では Type4 に位置します。そのためEthereum や EVM とは異なる部分がいくつか存在します。
zkSync と Ethereum の違い
こちらのページの内容を簡単に取り上げます。
EVM instructions
zkEVM では非対応の EVM の Opcodes が一定数存在します。
Nonces
Ethereum ではそれぞれのアカウントにユニーク id である nonce が紐づいています。EOA の場合はトランザクションの検証のために nonce が利用され、主に以下の役割があります。
- ネットワーク上でのリプレイ攻撃を防ぐ
- トランザクションが実行される順番を担保する
- アドレスを生成する際の計算においてユニーク id として利用する
EOA の nonce はトランザクションが1つ実行されるたびに1増えます。
スマートコントラクトの場合は、新しいスマートコントラクトをデプロイした時にそれのアドレスを決定するために使用されます。EOA の nonce とは異なり、1つのトランザクション複数のコントラクトをデプロイする可能性があるため、nonce を何回も増やすことができます。
対照的に zkSync にはプロトコルレベルで Account Abstraction(AA) が搭載されておりアカウントはスマートコントラクトである可能性が高いため、アカウントの nonce はトランザクションの検証にもコントラクトアドレス決定にも使用される可能性があります。そのため、zkEVM では2種類の nonce、つまりトランザクション検証用のものとコントラクトデプロイ用のものが用意されています。
また、細かい部分ですがデプロイ用の nonce は Ethereum では1から始まりますが、zkSync では0から始まります。そして zkSync ではコントラクトデプロイのトランザクションが成功した時のみインクリメントされますが、Ethereum では失敗してもインクリメントされます。
Libraries
Libraries のリンキングはコンパイル時にのみサポートされており、デプロイ時のリンキングはサポートされていません。
Precompiles
EVM に標準搭載されている precompile contract は現在は利用できませんが、ecrecover
, keccak256
, sha256
, ecadd
, ecmul
などの暗号プリミティブについては precompile contract としてサポートされています。但し、Gas 代が Ethereum と異なることがあります。
Native Account Abstraction(Native AA) vs EIP 4337
ZkSync の Account Abstraction と EIP-4337 では以下のような違いが存在します。
- Nonces の項でも述べた通り、zkEVM では Account Abstraction(AA) の仕組みがプロトコルレベルで実装されています。
- EOA を含むすべてのアカウントがスマートコントラクトアカウントのように振る舞います。
- EIP-4337 では UserOperations 専用の mempool が用意されたりと、スマートコントラクトアカウント用の独立したトランザクション処理が導入されていますが、zkSync ではアカウントタイプにかかわらず統一的にトランザクション処理が行われます。
- zkSync では スマートコントラクトアカウントだけてなく EOA も paymasters を有することができます。
Discussion