zk-SNARKsのSolidity Gadgetを読む


#1

vbuterin がobfuscatonについてまとめた
chriseth がzkについて解説した
leo_hio がzkの限界を述べた
codaprotocol.com がストレージスケーラビリティにzkを使えることを示した
chrisethがzkのverify関数をcppやrustでなくsolidityで書き始めたので実験しやすくなった https://github.com/christianlundkvist/libsnark-tutorial/blob/master/src/ethereum/contracts/Verifier.sol#L162

・コードリーディング
・ガス代確認
・ガス代節約

等を行っていきたい


#2

愚直なコードリーディングが一切通用しなかったのでherumiさんのスライドでpairing暗号を学ぶとすっと入りました。英語資料も探したけど、これが一番わかりやすい説明


#3

まだ https://github.com/barryWhiteHat/libsnark-tutorial との関係があまりよくわかっていなくて、https://github.com/christianlundkvist/libsnark-tutorial の方は、どの部分をsolidityに変えているんでしょう。

また、すごい初歩的な質問かもしれないのですが、以下のassemblyのcallは、address=6をcallしているのだと思っているのですが、buildからdeployまでのコードを読んだのですが、何をcallしているかわからなくてリーディングに詰まっています。:sweat:


#4

前者

Chrisの “zk-SNARKs in the nutshell” というホワイトペーパーの最終段落にある「ネイティブ実装」「ガジェット実装」の差です。

barryWhitehatのはZoKratesというlibsnark wrapperを使っていて、ネイティブ実装です。これをEthereumで使えるようにするにはノードのクライアント実装に足さなければならないので、(既存のコードやデータを更新する改善ではないので?)ソフトフォークでデプロイすることになると思います[要出典]

Chrisのはコントラクトとして実装している(EVMがチューリング完全だからこんな離れ業ができる)ので、デプロイは普通にコントラクトとしてデプロイするだけでいいです。これをガジェットと呼ぶことが多く、Casper Friendly Finality Gadgetもその一種ですね。zkのガジェットは改善策が出てもコントラクトを新しく出すだけでいいです。基本stateを残さないはずなので更新しやすくていいですね。

後者

call(g, a, v, in, insize, out, outsize) はpairing暗号の理論からすると明らかに「トーラス構造(「余り」を拡張した概念らしい)でのベクトル和」ですがたしかにどこの関数を呼んでるのかわからないですね。


#5

なるほど、_Gadget_についての説明助かりました。

compose-gadget branchで何かやってるみたいなので見て見ます。


#6

Q1. なぜlibsnarkが出てくるのか
推測: 振る舞いのテスト用?

Q2. なぜSolidityのPairingライブラリは、楕円曲線における加算をコントラクトアドレス6に、と乗算をコントラクトアドレス8に置いているのか
推測: 書きかけ ∧ ドキュメントなし ∧ 参照先の関数の記述なし

P.S. 全然わからないのでそのコードを書いた人にメールした


#7

gethにいつの間にか実装されてた。


#8

Precompiled contract 6,7,8の提案時の根拠を見つけました

Current smart contract executions on Ethereum are fully transparent, which makes them unsuitable for several use-cases that involve private information like the location, identity or history of past transactions. The technology of zkSNARKs could be a solution to this problem. While the Ethereum Virtual Machine can make use of zkSNARKs in theory, they are currently too expensive to fit the block gas limit. Because of that, this EIP proposes to specify certain parameters for some elementary primitives that enable zkSNARKs so that they can be implemented more efficiently and the gas cost be reduced.

現状のEthereumでのスマートコントラクトの実行は完全に透明性があり、いくつかの個人情報(所在、ID、取引履歴)を含むユースケースにそぐわない。zkSNARKsはその解決策になり、原理的にはEVMに乗るが、現状だと処理が高価すぎてgas limitを超えてしまう。そのgas costを減らすためにこのEIPではzkSNARKsを可能にするためのプリミティブな要素とその効率的な実装を提案する。

Note that fixing these parameters will in no way limit the use-cases for zkSNARKs, it will even allow for incorporating some advances in zkSNARK research without the need for a further hard fork.

この提案における要素は、zkSNARKsに用途を限定するわけではないし、zkSNARKsをハードフォークなしに改善するのに役立つことを留意されたい。

Source: https://github.com/ethereum/EIPs/issues/196#Motivation


#9

zk-SNARKsのややこしいと思ったところ1: zkを使うケース

パブリック情報のobfuscation(難読化)の最高峰としてそもそも情報を載せない形のコントラクトを書ける機能

zk-SNARKsのややこしいと思ったところ2: SNARKsを使うケース

codaprotocol は「簡潔な(succinct)検証」の性質を利用してストレージを圧縮しているようで、zk要素はあまりなさそうに今のところ見えている。でもプロモーション的には「zk-SNARKsで」という言い方をするのでミスリードされた。


#10

おおーなるほど、Precompiledなcontractはここを見ればいいんですね、勉強になりました。ちょっと動かして見ます。


#11

結局miximusも似たようなコントラクト持ってたので訂正