Greetings! New to Zcash?
The Zcash network is young, but evolving quickly! Sign up and we'll be in touch with more information about how you can get started with Zcash!

言語

Zcashのイーサリウムへの統合 (ZoE)に関するアップデート

Ariel Gabizon and Christian Reitwiessner | Jan 19, 2017

イーサリウムR&DチームメンバーとZcash社は、ブロックチェーンのプログラマビリティ及びプライバシーの連結に向けたリサーチプロジェクトにおいて提携しています。この記事は、Ariel Gabizon(Zcash)とChristian Reitwiessner(イーサリウム)の共同執筆によるもので、 イーサリウムのブログ * に同時掲載されています。*

イーサリウムのフレキシブルなスマートコントラクトインターフェイスでは、様々なアプリケーションを使用できます。その多くは、おそらく未だ生まれてもいません。プライバシーの範囲が増えるに従い、可能性は非常に大きくなります。

例えば、スマートコントラクト経由のブロックチェーンによって運営された選挙やオークションを 想像してみてください。結果はブロックチェーンを観察していれば誰でも確認できますが、個人の投票先やビッドが明らかになることはありません。他に選択的開示も考えられます。例えば、ユーザーに相手の正確な位置を教えることなく、特定の都市にいることだけを証明することもできます。

イーサリアムに能力を加えるキーとなるのは、ゼロ知識の簡潔な非対話型議論の知識です(zk-SNARKs)。これこそが、Zcashの基礎となる暗号エンジンです。

Zcashのゴールの1つに、 Project Alchemy というコードネームのプロジェクトがあります。これは、イーサリウムとZcash間の直接的な脱中心化した交換を可能とするものです。 2つのブロックチェーンとチームを結びつけ、片方がプログラマビリティに、他方がプライバシーに焦点を当てることで、自然に両者を必要とするアプリケーションが生み出されることとなります。

Zcash/イーサリアムの提携事業の一部として、ZcashのAriel Gabizonは数週間前、ベルリンのイーサリアムハブのChristian Reitwiessnerを訪問しました。この出張のハイライトは、イーサリアムのC++クライアントの為に導入されたプレコンパイルのイーサリアムコントラクトを基としたSolidityによって書かれたzk-SNARK認証システムの導入コンセプトのプルーフにあります。これは、 Baby ZoE を補充するものですが、ここでは zk-SNARKのプレコンパイルされたコントラクトはイーサリアム・ラストのクライアントであるParityによって書かれています。異なる点は、細かな暗号プリミティブ(楕円曲線倍算、加法とペアリング)のみを加え、あとはSolidityで行うということです。これにより柔軟性が向上し、ハードフォークを使用することなく多様なzk-SNARKを建設することが可能となります(詳細は後述)。このコードはイーサリアムブロックチェーンのテストネットで、実際にプライベートが保護されたZcash取引を認証するテストに成功しました。認証にかかった時間はわずか42ミリ秒でした。このようにプレコンパイルされたコントラクトの追加が可能であり、使用コストも手頃であるということがわかります。

このシステムで何ができるか

Zcashシステムは、イーサリアムにおいて再利用して保護されたカスタムトークンを作成することができます。このトークンは、既に投票(詳細は後述)や、バイヤーが他人のビッドを見ることのできないシンプルなオークションのようなアプリケーションを構成しています。

概念実証のコンパイルを試してみたい場合は、以下のコマンドをご利用ください。サポートが必要な場合は、https://gitter.im/ethereum/privacy-tech までお問い合わせください。

git clone https://github.com/scipr-lab/libsnark.git

cd libsnark
sudo PREFIX=/usr/local make NO_PROCPS=1 NO_GTEST=1 NO_DOCS=1 CURVE=ALT_BN128 \
   FEATUREFLAGS="-DBINARY_OUTPUT=1 -DMONTGOMERY_OUTPUT=1 -DNO_PT_COMPRESSION=1" \
   lib install
cd ..
git clone --recursive -b snark https://github.com/ethereum/cpp-ethereum.git
cd cpp-ethereum
./scripts/install_deps.sh && cmake . -DEVMJIT=0 -DETHASHCL=0 && make eth
cd ..
git clone --recursive -b snarks https://github.com/ethereum/solidity.git
cd solidity
./scripts/install_deps.sh && cmake . && make soltest
cd ..
./cpp-ethereum/eth/eth --test -d /tmp/test
# And on a second terminal:
./solidity/test/soltest -t "*/snark" -- --ipcpath   /tmp/test/geth.ipc  --show-messages

zk-SNARKsのイーサリアムブロックチェーンへの統合に関する様々な側面に関しても議論を行ってきました。現在この上に拡張させているところです。

プレコンパイルされたコントラクトが何を定義するかを決定する

SNARKとはある種の資産の短いプルーフであり、イーサリアムのブロックチェーンにプライバシーの性質を加えるのに必要なのは、クライアント側がこのようなプルーフを認証する能力を持っていることだということを思い出してください。

最近のコンストラクションでは全て、認証システムは楕円曲線のオペレーションだけで構成されています。特に、認証者は楕円曲線グループにスカラー乗法と加法、また同時に、バイリニアペアリングと呼ばれる重いオペレーションを要求します。

こちら で言及されているように、EVMにおいて直接こうしたオペレーションを実装するのには非常にコストがかかります。 そこで、こうしたオペレーションを実行するプレコンパイルされたコントラクトを実装したいと考えています。 議論になっていたのは、こうしたプレコンパイルされたコントラクトが目標とすべき一般性レベルはどの程度か、という問いでした。

SNARKのセキュリティレベルは、曲線パラメータに相当します。 ざっくりと言うと、曲線オーダーが大きいほど、また埋め込まれている角度が大きいほど、 この曲線をベースとしたSNARKはより安全になります。逆に、当然のごとく、こうした量が大きければ、より相当する曲線でのオペレーションにはコストがかかってきます。 従って、SNARKを用いるコントラクトの設計者は、自ら設計した効率性/安全性のトレードオフに従ってパラメータを選びたいと考えるはずです。 これが、高レベルの一般性によるプレコンパイルされたコントラクトの実装についての議論の1つです。ここでは、コントラクト設計者は曲線の大きなファミリの中から選択することができます。 事実、私たちは高レベルの一般性に的を絞ることから始めました - ここでは、曲線の解説はコントラクトのインプットの一部として所与のものとなっています。このような状況では、スマートコントラクトは例えば、いかなる曲線カーブグループにおいてでも加法を実行することができます。

このアプローチの厄介なところは、ガスコストをオペレーションに割り当てている点です。ユーザーは曲線の説明だけから、特定の実装へアクセスすることもなく、該当曲線でのグループオペレーションに どれだけ費用がかかるか評価しなければなりません(最悪の場合)。 もう少し一般性の低いアプローチでは、所与のファミリからすべての曲線を使用できます。 こうした曲線は全て特定の最適化Ateペアリングをサポートするため、Barreto-Naehrig (BN)曲線のファミリを使用した場合、曲線パラメータにとってペアリングオペレーションはどの程度のコストとなるか、ざっくりと評価することができることに気がつきました。このようなプレコンパイルの動作のしくみ、およびガスコストのコンピューティング方法に関する 概略 をご覧ください。

この議論からは様々なことが学べましたが、結果的にこのプルーフ・オブ・コントラクトでは"シンプルにしていく"ことと、Zcashが現在使用している特定の曲線でのオペレーションに対するコントラクトを実装することを決定しました。 これは、Zcashでも使っている libsnark ライブラリの中の該当関数のラッパーを使って行いました。 上記のBaby ZoEプロジェクトで行ったように、現在Zcashが使っているSNARK認証関数のためのラッパーを使うことも可能だったと記載しておきます。しかし、はっきりと定義した楕円曲線オペレーションのメリットは、幅広いSNARK構築が可能だという点にあります。つまり、繰り返しになりますが、全てが上記3つの楕円曲線オペレーションの何らかの結合体によって作動する認証者を持つことになるのです。

新規の匿名トークンとその他アプリケーションのためのZcashセットアップを再利用する

既に耳にしているかもしれませんが、SNARKを使うには、 複雑なセットアップ段階 が必要になります。ここでは、いわゆるシステムの公開パラメータが構築されます。特定のサーキット用のSNARKを使いたい場合にいつでも安全に公開パラメータを生成する必要があるという事実は、SNARKの使用が妨げられる要因です(このセットアップ段階を単純化については、Zcashでも検討されましたが、今のところ成功していません)。

逆に良いニュースとしては、プライバシーが保護されたトランザクションによってサポートされたトークンの発行を希望する場合は、Zcashによって安全に生成された公開パラメータを単純に再利用できるということです。 この理由は、プライバシー保護されたトランザクションを認証するために使用されたZcashのサーキットは内在的に1つの通貨やブロックチェーンに縛られていないためです。むしろ、分かりやすいインプットの1つは、通貨の妥当なノートを全て含むマークルツリーの根源となります。このインプットは、ユーザーが使用したいと考える通貨によって変化するのです。 更に、新しい匿名のトークンを開始する方が簡単だという場合は、一見トークンには見えない多くのタスクを既に達成していることになります。 例えば、2つの選択肢のうち好ましい方を選ぶ匿名選挙を行いたいとします。 私たちは投票のために匿名のカスタム・トークンを発行し、各投票者に1コインを送信します。 “採掘”はないので、いかなる方法においてもトークンを生成することはできません。 こうして、各パーティは投票先に従って2つのアドレスの内1つにコインを送ることになります。 より大きな最終バランスを備えたアドレスが選挙結果となります。

その他のアプリケーション

シンプルに「選択的開示」ができるように構築された非トークンベースのシステムでは、例えば、ブロックチェーンに対して物理的な居場所を含んだ暗号化メッセージを恒常的に投稿することができます(恐らく、他の人々の署名によりいたずらを防ぐ形で)。それぞれのメッセージに異なるキーを使うことで、そのキーを開示した特定の時にだけ居場所を明らかにすることができます。しかし、zk-SNARKsを使った場合は、具体的にどこにいるかを明らかにすることなく、特定のエリアにいるということだけを証明できます。zk-SNARKの内部で居場所が解読され、それがエリア内にあることが示されます。ゼロ知識資産により、全員が事実を認証できても誰も実際の居場所を見つけられないということが可能になります。

この先に控えているもの

言及した機能を真の意味で実現するには、すなわち匿名のトークンを作り、Zcashトランザクションをイーサリアムのブロックチェーン上で認証するには 、SolidityにおいてZcashが使っている他の要素を実装する必要が出てきます。 最初に、ノートコミットメントツリーのアップデートのような、Zcashネットワークにおけるノードによって実行される実装を備える必要があります。 第二に、SolidityにおいてZcashが使っているequihashのプルーフ・オブ・ワークのアルゴリズムを実装する必要があります。さもなければ、トランザクションはそれ自体は妥当と認証されますが、使われたノートがZcashのブロックチェーンに存在していたのか、それともトランザクションは実際にZcashブロックチェーンに送られたものなのかわかりません。 幸運にも、こうした実装はすでに 書かれています。しかし、実践的なアプリケーションで使用するには効率を改善する必要があります。

謝辞: 技術的なサポートを提供していただいたSean Bowe氏に感謝いたします。また、有益なご意見をいただいたSean氏とVitalik Buterin氏、また編集を行っていただいたMing Chan氏にも感謝いたします。