Zerochain bi-weeklyアップデートレポート#0

Osuke
LayerX-jp
Published in
8 min readJul 1, 2019

Zerochainの進捗を隔週で簡単なレポートとしてお伝えしていきます。今回は6/17~6/28のアップデートレポートです。

今回のアップデートは主に以下の通りです。

  • フロントランニング攻撃対策の実装
  • HDKD (Hierarchical Deterministic Key Derivation)の実装
  • Zerochain Walletの鍵ファイル管理の仕様策定およびその暗号化実装

Zerochain自体の仕様概要については以下の記事でまとまっています。簡単に言うと、zk-SNARKsをベースにしたSubstrate上のアカウントベースブロックチェーンです。

フロントランニング攻撃対策の実装

よくDEXの攻撃で「フロントランニング攻撃」というキーワードを目にすると思います。Zerochainにおけるフロントランニング対策も同様の攻撃手法になります。

つまり、攻撃者がオンチェーンに送られた相手のトランザクションをウォッチして、それに先回りするようなトランザクションを送って、相手のトランザクションを無効化するなどの攻撃です。DEXの文脈だと、より高いgasを設定して同じオーダーのトランザクションを攻撃者がさせることによって、オーダーを無効化したり、より不利なオーダー処理を強制させたりできてしまいます。

Zerochainの文脈では攻撃者はある特定のトランザクションを上記の手法で無効化することができてしまいます。なぜなら、先回りして相手に対して送金するようなトランザクションを処理することで、相手の暗号化残高を更新し、ゼロ知識証明のproofを不正化することができてしまうからです。

詳しい内容は準備が多すぎるのでここでは解説しきれないですが、要は「自分がトランザクションを送って、それが実際に処理されるまでの間に攻撃者のトランザクションが処理されてしまうと、自分のトランザクションが処理されなくなってしまう」のです。

以上のような攻撃を防ぐために、Zerochainでは単にaddress => 暗号化残高のmapping構造で残高を保持するのではなく、追加でaddress => 保留暗号化残高を保持しています。

送られてくる送金は、まずaddress => 保留残高の方に記録され、(適当なエポックを設定し、そのエポックが過ぎたブロックチェーン高であれば)次回のトランザクション処理で、自分の保留残高から暗号化残高に残高が以降する処理も走ります。

具体的なコードでいうと以下のrollover関数がそれに当たります。

また、このフロントランニング対策は特に攻撃目的ではなくても、多く送金が行われるような状況で非同期的に秘匿送金が行えるようになることにも寄与します。

HDKD (Hierarchical Deterministic Key Derivation)

どのブロックチェーンのウォレットでも秘密鍵は原則、階層的な構造として導出して管理しています。例えば、以下の記事で紹介しているようなBIP32などの仕様がそれにあたります。

ビットコインやイーサリアムなどのウォレットを作る際は以上のように仕様が明確に定まっていて、そのライブラリを使用することができます。しかし、Zerochainの場合は鍵コンポーネント自体を別仕様で作っていますので、当然このHDKDもそれに合わせて実装する必要があります。

暗号のコアなアルゴリズム自体を独自で作ることはリスキーなので、原則BIP32の仕様(より厳密にはzcash提案のZIP32)にそって、Zerochainの鍵に適用できるようにHDKDの実装を行いました。該当のコード箇所は主に以下のファイルになります。

鍵ファイル管理およびその暗号化

現在、最低限CLIで動かせるZerochain Walletを開発中です。そのために、コアとなる鍵ファイルの仕様を決めたり、どう管理するか、どう暗号化するかなどを決めて実装する必要があります。

Ethereumなどでは様々なウォレット間で鍵ファイルをimport/exportできるように様々なパラメタが設定されていますが、Zerochainの場合はそれをよりシンプルにした仕様でjson形式で定義しています。

keyfile.json
  • fileName: タイムスタンプ
  • accountName: ユーザー定義のアカウント名
  • ss58Address: SS58というエンコード形式でエンコードされた公開鍵
  • version: Zerochainのバージョン
  • encryptedKey: 秘密鍵の暗号文およびそのパラメタ(mac, salt, iv, iters)

以上のようなデータが一つのkeyfile(一つのアカウントに相当)に保持されています。また、他にもマスター秘密鍵のkeyfileやアカウントのindex管理のためのjsonファイルも用意していますが、今回省略します。

秘密鍵はパスワード入力の共通鍵暗号(AES 128-bitsのCTRモードをベース)によって暗号化しています。

次回のプラン

直近で力を入れて実装しているのは、ウォレットのコア部分です。2週間後のアップデートレポートまでにCLIでウォレットの通常操作は行えるところまで持っていく予定です。(鍵ファイルベースのトランザクション送信や暗号残高の復号化も含む。)

また、オンチェーンの機能面では秘匿化アセットのMint & Burn機能も追加していきます。現在では単一の秘匿アセットのみしか扱うことができていませんでしたが、アセットIDをつけて識別可能にし、そのアセットに対して、MintやBurnを行える機能を追加していきます。

実装アップデートとは関係ありませんが、先1ヶ月で大きめな技術者カンファレンスに国内1つ、海外で1つZerochainについて登壇してきます。

ブロックチェーンに限らず、国内の企業研究に特化したカンファレンスです。

韓国で開催される大規模なブロックチェーンカンファレンスです。

最後に。Zerochainをガンガン一緒に進めていける仲間を絶賛募集してるので興味ある方はぜひ僕のツイッターDMや以下のWantedlyから連絡ください!

--

--