ZeroKnowledge Summit #3レポート

Osuke
LayerX-jp
Published in
8 min readApr 3, 2019

お世話になっています。Osuke(@zoom_zoomzo)です。

先日のブログポストで公開したようにLayerXではZerochainというブロックチェーンをベースに秘匿化技術の研究開発に力を入れています。

その際にもっとも重要な技術になるのが、ゼロ知識証明です。そこで、今回は先日、ベルリンで開催されたZeroKnowledge Summit #3でのトピックに関してまとめた内容をお伝えしていきます。ZeroKnowledge SummitはParityがホストしているZeroKnowledge Podcastが定期的に行なっているゼロ知識証明の技術発表を行うイベントです。

今回もゼロ知識証明周りの主要なプレイヤーが発表を行いましたので、この記事ではそれぞれのチームはどのようなチームで何を開発していて、Zk Summitでは何を発表したのかをまとめていきます。

最初に、登壇チームそれぞれの開発内容をざっとまとめると以下の通りです。

  • StarkWare: zk-STARKを用いたスケーラブルな0xベースのDEX
  • Harry: Ethereumのための簡単かつ効率的なSNARK開発ツールキット
  • Matter: SNARKを用いたLayer2のスケーリングおよび秘匿化
  • Nucypher: Proxy Re-encryptionおよび完全準同型暗号
  • Coda: Recursive-SNARKsを用いたブロックチェーンのアクセシビリティ問題の解決

また、以下ではキーとなるキーワードを積極的にあげていきますのでより詳しく知りたい方はぜひ調べてみてください。

Scalability First with STARK — Avihu Levy (StarkWare Industries)

上記がzkSummitでのAvihuによるStark-based DEXの紹介動画で下記がStanford Blockchain Conference’19におけるEli Ben-Sassonからの紹介動画です。

Starkwareはリサーチャー中心の約20名ほどのチームでPCP(Probabilistically checkable proof)をベースとしたIOP(Interactive oracle proofs)の研究をメインに行なっています。IOPベースのアプリケーションの一つがzk-STARKsと呼ばれています。

zk-SNARKs(PGHR13, Groth16, GM17)は非標準的な暗号の安全性仮定やペアリングを用いた複雑な暗号学的手法をベースとしている一方、zk-STARKsの安全性仮定は暗号学的ハッシュ関数の衝突耐性に基づき、古典的なPCPの手法を応用しています。BitfieldのSTARKフレンドリーなハッシュ関数(Fryiday)の研究も個人的には注目しています。

Stark-based DEXの開発自体は0xと組み、動画にあるようにオフチェーンでMerkle treeとしてアカウントごとのトークン量を保持することで従来と比べてスケーラブルなDEXを目指しています。取引に伴うMerkle rootの更新と署名の妥当性を証明し、オンチェーンでその証明の検証とMerkle rootの保持をすることで、まとめてDEX取引の更新(つまり、アカウントのトークン量の更新)を行います。

より詳しいzk-STARKsは以下のScrapboxで紹介しています。

https://scrapbox.io/layerx/search/page?q=STARK

High-level programming languages for zkSNARKs, an overview — Harry Roberts (Ethsnarks)

HarryのメインプロジェクトはEthereum compatibleなzk-SNARKsのツールキット開発です。

https://github.com/HarryR/ethsnarks

SNARKsは証明したいことを算術回路(circuit)に落とし込むところまでをフロントエンド(zokrates, circom)、そのcircuitからconstraintsを計算し証明と検証を行う部分をバックエンド(libsnark, bellman)と言います。

https://speakerdeck.com/osuke/theory-and-practice-of-zk-snarks

そして、フロントエンドではTinyRAMなどを用いたり汎用的なプログラムを書けるほどcircuitの複雑性が向上してしまうトレードオフがあります。つまり、より制限されたlow-levelな環境からバックエンドに繋げることがSNARKsの最適化をもたらします。Harryのethsnarksでは、このトレードオフを最小限にするべくxjsnarksなどのstate-of-artなフロントエンドからバックエンドへの繋ぎこみなどが最近開発されています。また、barrywhitehatなどが中心で進めているSNARKs-basedなアプリケーションにも利用されています。

上記のHarryの動画ではより詳細にこれまでのSNARKsフロントエンドの解説がされています。

Scaling settlements with zkSNARKs — Alex Vlasov (Matter Labs)

エンジニアは3人ほどの比較的小規模なMatterのチームですが、SNARKsなどの開発力で圧倒的な技術力を持っています。以前は、Plasmaの開発に重点を置いていましたが、現在では特にEthereumのLayer2スケーリング(およびプライバシー)としてのSNARKs応用に力を入れています。

https://github.com/gluk64/awesome-zero-knowledge-proofs

上記動画では、現状のSNARKs(Groth16)での大きな問題であるtrusted setup問題の緩和が期待できるSONICsの解説がメインで行われています。SONICsの特徴は以下の通りです。

  • Universal: constraints数を一定に制限して全てのcircuitをサポート
  • Updatable: Setup時のSRS(structured reference string)に追加コントリビューティング可能
  • Helper: zk-proofsの集約を行うuntrustedな主体
https://eprint.iacr.org/2019/099.pdf
https://eprint.iacr.org/2019/099.pdf

Fully Homomorphic Encryption: The Road to Secure Computation — John ‘Tux’ Pacific (Nucypher)

Nucypherは、Proxy Re-encryption(再暗号化のプロキシプロトコル)とFHE(完全準同型暗号)の研究開発を進めるチームです。FHEはblockchain文脈に限らず暗号分野で最もホットな分野のひとつで、NucypherではFHEとゼロ知識証明を組み合わせ、FHEにVerifiabilityを与えることを目指しています。

スケーラビリティなどに課題。

  • 暗号文:平文の16,000倍: 1MB -> 16GB
  • Computation keys: ~100MB
  • リサーチレベルだがHEAANは~40x程度
  • Trustless.Helth: A WebAssembly interpreter with FHE

Notes from the SNARKonomicon: How to effectively program SNARKs — Izaak Meckler (Coda Protocol)

CodaはRecursive snarksを用いてブロックチェーンがどれだけ伸びても全体のサイズがコンスタントになるようなブロックチェーンを開発しています。つまり、snarksを再帰的に(n-1番目のブロックの妥当性証明をn番目のブロック生成時に検証する)用いることで、フルノードのインセンティブ問題(アクセシビリティ問題)の解決を図るプロトコルです。

また、SNARKsプログラミングのためのOCamlベースのDSLの開発(フロントエンド開発)も行なっています。

--

--