zk-SNARKsとzk-STARKsの比較

zk-SNARKs

for layer2 execution engines

状態遷移はoff chainでcompact data storageをonchainで。(他の例：truebit）

plasmaやchannelsはexecutionもdataもoffchainでやろうとしている。

layer1はexecution engineのためのdata availabilityレイヤー。

ただlayer1はレイテンシーを改善する必要性が。

メリット：

証明のサイズが小さい(127~288bytes) 2294bits?

デメリット：

trustedなsetupが必要であること

多くの計算量が必要であること

証明時間：150~200kのconstraintsでlaptopで20~60sくらい

snarks for execution engine

https://gyazo.com/7b09fabe2e902296d59ccaea9a9bb35b

Bridgeコントラクトに任意の状態をマークルツリーで管理しておき、execution engineでindexに基づく状態を遷移。

特定のindexの状態はその秘密鍵により署名されたTxにしか変更できない。

オンチェーンでのペアリング検証はgasがやばいのでlayer2のexecution engineで処理したマークルルートのみをオンチェーンで証明。(roll_up ver.)

署名検証はsecp256k1 curveよりeddsa curveの方が効率的。

roll_upで200k constaintsでlaptopで30sほど。

onchain

snarkフレンドリーなハッシュ関数の必要性。provingはGPU farm。

zk-STARKs

for layer1

メリット：

trustedなsetupが必要ない

量子コンピューター耐性

証明の計算複雑性が低い（オーダー的にはsnarksの1/10くらい）

DIZK実装後は逆にzk-snarksの方が効率的

デメリット：

証明サイズが大きい(~250kB: aurora)

snarks、starksフレンドリーなハッシュ関数開発の必要性。

検証複雑性はsnarksのsetup後よりは高い。

starks;50~100ms vs snarks; ~10ms

証明時間

https://gyazo.com/33792b822030593fb75dbd6bba78a6bf

検証時間

https://gyazo.com/686f94c4d74f9f4a5c32aa85d9692e4f

コミュニケーション複雑性

https://gyazo.com/466f2aa41b465ea9c0cca5b03cfd1a72

現状のボトルネック

zk-snarks: execution engineとしてのlayer2

provingの計算複雑性

sha256が厳しい

zokrates: 250k constraints

zokrates native実装とlibsnark integration実装(non-master)

libsnark: 27k contraints

DIZKによる分散計算

onchainでのverifying gas cost

merkle treeで緩和可能

trusted setup

plasma operator

verifyerによるsetup

zk-starks: VDFsとしてのlayer1

proof size

auroraによる緩和

250KB...

Bulletproofs

メリット：

trustedなsetupが必要ない

デメリット：

circuitが増えるほど線形的に検証の計算量が増えるので、複雑な関数のZKPほどオンチェーンで行うのは非現実的。