こんにちは、Gincoの永田(@nagatkaz116)です。

皆さんはZilliqaという暗号通貨をご存知でしょうか？シャーディングという手法を用いることで高いトランザクションスループットを実現し、なおかつスマートコントラクトのプラットフォームも提供するZilliqaは、今非常に期待されている暗号通貨の一つです。

そんなZilliqaですが、Zilliqaの公式チームからホワイトペーパーの翻訳について許可を頂いたので、本日はホワイトペーパー全文を以下に翻訳したいと思います。一部、ホワイトペーパーから仕様変更がありますが、オリジナルのホワイトペーパーにも目を通したいという方は是非参考にして頂ければと思います。

なお、本ホワイトペーパーはこちらからpdf版を閲覧・ダウンロード可能です。「出力して勉強に用いたい」「輪読会したい」といった方はぜひご活用ください。

Zilliqaテクニカルホワイトペーパー

要約

既存の暗号通貨とスマートコントラクトプラットフォームはスケーラビリティ問題を持つことで知られる。つまり、秒間に処理することのできるトランザクション数は限られており、大抵の場合10より少ない。パブリックな暗号通貨とスマートコントラクトプラットフォームを利用したアプリケーションが増えるにつれて、秒間に数百とか数千のオーダーでトランザクションを処理できることが要求される。

我々はZilliqaを提案する。これはトランザクションレートにおいてスケールするように設計された新しいブロックチェーンプラットフォームである。 Zilliqaのマイナーが増えるにつれて、トランザクションレートの増加が期待される。現在イーサリアムのネットワークは30,000マイナーほどの規模であるが、同規模のネットワークならZilliqaの場合イーサリアムの約1000倍のトランザクションレートで処理することができる。 Zilliqa設計において非常に重要な概念がシャーディングである。マイニングネットワークをシャードと呼ばれる小さなグループに分割し、それぞれがトランザクションを並列に処理する。

さらにZilliqaは革新的であり特定の目的に適したスマートコントラクト記述言語と実行環境を提案し、Zilliqaアーキテクチャを利用して大規模かつ高効率な計算プラットフォームを提供する。 Zilliqaのスマートコントラクト記述言語は並列処理を簡単に行うことのできるような大規模計算に適したデータフロープログラミング形式に従っている。例えば、検索、並び替え、線形代数計算のような単純な計算からニューラルネットワークの学習やデータマイニング、科学計算のような複雑な計算も可能だ。一般的にMapReduceタスクなら何でも処理することができる。

第１章　導入

暗号通貨やスマートコントラクトプラットフォームは共有の計算リソースになりつつある。こうしたプラットフォームを何千ものコンピューターが同時に動く新世代のコンピューターと捉えることもできる。しかし、既存の暗号通貨やスマートコントラクトプラットフォームはスケーリングについてよく知られた限界が存在する。ビットコイン[1]、イーサリアム[2]や関連する暗号通貨の平均トランザクションレートは秒間10を下回る（大抵3から7程度）。パブリックな暗号通貨とスマートコントラクトプラットフォームを利用したアプリケーションが増えるにつれて、秒間に数百のオーダーでトランザクションを処理できることが要求される。世界規模の決済ネットワークの場合は秒間何万ものトランザクションレートが要求される。それほどの処理能力を持つ非中央集権的でオープンなブロックチェーンプラットフォームを開発することはできるのか？

既存プロトコルのスケーラビリティ問題は幾分根本的な問題で、コンセンサスプロトコルとネットワークプロトコルの設計に根付く問題である。よって、例えばビットコインやイーサリアムといった既存のプロトコルのパラメータ（例えばブロックサイズやブロックレート）を変更したところで、多少は速度が上がるだろうが、秒間何千ものトランザクションレートを必要とするようなアプリケーションをサポートするなら基礎となるプロトコルを最初から考え直さなければならない。

我々はトランザクションレートにおいてスケールするよう設計された新しいブロックチェーンプラットフォームであるZilliqaを提案する。 Zilliqaのマイナーが増えるにつれてトランザクションレートも増えることが期待される。具体的には、数百のノードがネットワークに加わるたびにトランザクションレートはおおよそ倍になるよう設計されている。執筆時点で、イーサリアムのマイニングネットワークは30,000ノード以上であるが、同程度の規模ならZilliqaはイーサリアムの約1000倍のトランザクションレートで処理することができるはずだ。

Zilliqaは最初から再設計され、2年以上研究開発が行われてきた。 Zilliqaの設計において非常に重要な概念はシャーディングである。これは、マイニングネットワークをシャードと呼ばれる小さなグループに分割し、それぞれがトランザクションを並列に処理するというものだ。例えば、Zilliqaのマイニングネットワークに8000マイナーいるとして、Zilliqaは自動的にそれぞれ800マイナーのサブネットワークを10個作成する。この時、信頼すべき調整者が存在しないような非中央集権的な方法でサブネットワークが作成される。ここで、一つのサブネットワークで１エポックにつき仮に100トランザクションの同意が得られたとすると、10のサブネットワークで合計すると1000トランザクションの合意が得られたことになる。各サブネットワークから安全にトランザクションを集めるためには各サブネットワークが二重支払いなどの重複なしで異なるトランザクションを処理していることを保証するのが重要だ。

前提条件は既存のブロックチェーンベースの解決策に似ている。マイニングネットワークには一部悪意を持ったノード・アイデンティティが存在し、その計算能力の合計はネットワーク全体の計算能力の1/4より少ないと仮定している。標準的なPoWのスキームに基づいているが、新しい２層ブロックチェーン構造を持ち、シャードを処理するために高度に最適化されたコンセンサスアルゴリズムを持つ。

さらにZilliqaは革新的であり特定の目的に適したスマートコントラクト記述言語と実行環境を提案し、Zilliqaアーキテクチャを利用して大規模かつ高効率な計算プラットフォームを提供する。 Zilliqaにおけるスマートコントラクト記述言語はデータフロープログラミング形式に従っており、スマートコントラクトは有向グラフで表すことができる。そのグラフにおけるノードはオペレーションや関数であり、二つのノード間の弧は１つ目のノードの出力と２つ目のノードへの入力を意味する。ノードはそのノードへの入力全てが有効になるとアクティブになる（つまり実行可能になる）ことから、データフローコントラクトは本質的に並列であり、Zilliqaのような非中央集権的システムに適しているのだ。

シャードを用いたアーキテクチャーは並列化が容易な大規模処理を行うのに非常に適している。例えば、検索、並び替え、線形代数計算のような単純な計算から、ニューラルネットワークの学習やデータマイニング、科学計算のような複雑な計算も可能だ。一般的にMapReduceタスクなら何でも処理することができる。

この文書ではZilliqaブロックチェーンプロトコルの技術設計について述べる。Zilliqaは新しく、概念的に簡潔でモジュール化された設計を持ち、６つの層で構成される。暗号層（第３章）、データ層（第４章）、ネットワーク層（第５章）、コンセンサス層（第６章）、スマートコントラクト層（第７章）、インセンティブ層（第８章）である。各層について説明する前に、まずはシステム設定、前提、脅威モデルについて第２章で議論する。

第２章　システム設定と前提

エンティティ Zilliqaにはユーザーとマイナーという２つのエンティティが存在する。ユーザーはZilliqaのインフラを使って送金したりスマートコントラクトを実行する外部のエンティティである。マイナーはZilliqaのコンセンサスプロトコルを実行し報酬を得るネットワーク内のノードである。このホワイトペーパーでは今後マイナーとノードを同じ意味で用いる。

Zilliqaのマイニングネットワークはさらにシャードと呼ばれるより小さな複数のネットワークに分割される。マイナーはDSノードと呼ばれるマイナーのグループによってシャードに割り振られる。このDSノードのグループをDSコミッティーと呼ぶ。各シャードとDSコミッティーにはリーダーが存在する。リーダーはZilliqaのコンセンサスプロトコルとネットワークの全体的な機能において重要な役割を担う。

各ユーザーは電子署名スキームのための公開鍵と秘密鍵のペアを持ち、各マイナーはアイデンティティとしての役目を持つIPアドレスと公開鍵を持つ。

ネーティブトークン ZilliqaにはZillingと呼ばれるネーティブトークン（短縮してZIL）を持つ。ユーザーはZillingを保有することでトランザクション処理やスマートコントラクトの実行に対して手数料を払うことができるため、ZillingはZilliqaプラットフォームにおけるある種の使用権利と言える。このホワイトペーパーでは、全ての金額はZILに基づくことを前提としている。

脅威モデル マイニングネットワークにはいかなる時も一部のビザンチンノード・アイデンティティが存在し、その合計計算能力はネットワーク全体の計算能力の1/4より小さいことを前提としている。 1/4という数字は1/3から離れている任意の定数であり、合理的な数字として選ばれている。さらに、正直なノードはプロトコルを実行している間信頼できると前提を置いており、ブロック生成に失敗したり接続が切れるノードはビザンチンノードに含むとする。

ビザンチンノードはプロトコルを守らず、メッセージを削除・修正したり、異なるメッセージを正直なノードに送ることができる。さらに全てのビザンチンノードは共謀することもできる。ビザンチンノードの合計計算能力は標準的な暗号学的前提である確率的多項式時間に基づくと限定する。

我々は（ネットワーク分断がないとして）正直なノードからのメッセージは正直なノードへある一定の時間待てば伝わるという前提をおいているが、この「一定の時間」は時間と共に変化する。この変数はライブネスを保証するものであり安全性を保証するものではない[3]。そのようなタイミングと接続の前提を満たさないとき、ビザンチンノードがメッセージを大幅に遅延させたり、もっと悪ければネットワークを「失墜」させることができるようになる[4]。ネットワーク分断がある時には、CAP理論でも述べられているように、一貫性と可用性のどちらかを選ぶしかない[5]。Zilliqaでは、一貫性をとり可用性を犠牲にする。

第３章　暗号層

暗号層はZilliqaで使われる低レベルの汎用暗号アルゴリズムを定義する。他のいくつかのブロックチェーンプラットフォームと同様に、Zilliqaは電子署名に楕円曲線暗号を用い、PoWにメモリーハードハッシュ関数を用いる。

このホワイトペーパーでは設計を説明するにあたり広くSHA3ハッシュ関数[6]を用いる。 SHA3はもともと特にイーサリアムをはじめとする様々なブロックチェーンプラットフォームに使われているKeccak[7]に基礎を置く。近い将来、他のプラットフォームとの相互運用性をより高めるためにKeccakに切り替える可能性がある。

A. シュノア署名

Zilliqaは楕円曲線シュノア署名アルゴリズム（EC-Schnorr）[8]を署名アルゴリズムとして採用している。カーブにはsecp256k1[9]を用いている。このカーブはビットコインやイーサリアムでも使われているがECDSA という異なる署名アルゴリズムを用いている。ECDSAではなくEC-Scnorrを用いると次のような利点がある。

1) 頑強性

俗な言い方をすると、頑強性とはある秘密鍵を使って得られたあるメッセージへの署名があった時に、悪意を持った第三者がその対応する公開鍵で有効だと認められる新しい署名を作成することが困難であることを意味する。ECDSAと違いEC-Shnorrは頑強性を持つと証明されている[10]。

2) マルチシグネチャー

マルチシグネチャーを用いると複数の署名者によるあるメッセージに対する署名を集めて一つの署名にすることができる。その署名は、権限を持つ人たちの鍵を集約した一つの公開鍵で認証することができる。 EC-Schnorrは元々マルチシグネチャースキームであるのに対して[11]、ECDSAはマルチシグネチャーを作ることは一応できるが柔軟性は低い。

Zilliqaはあるメッセージに対して複数の署名が求められる時に署名のサイズを減らすべくEC-Schnorrをベースとしたマルチシグネチャーを用いている。複数の参加者が署名をすることであるデータについて合意する必要のある我々のコンセンサスプロトコルでは、署名のサイズが小さいということは特に重要だ。

3) 速度

ECDSAは大きい数に対するモジュラ逆数を計算する必要があるのでEC-Shnorrの方がECDSAより速い。 EC-Schnorrでは逆数演算は必要ない。

EC-Shnorrの正確な鍵生成、署名、検証の手続きは付録Aに掲載する。付録ではEC-Schnorrがどのようにマルチシグネチャースキームとして使うことができるかも示している。

B. PoW

Zilliqaはシビル攻撃を防ぎノードアイデンティティを生成するためだけにPoWを用いる。これはPoWが分散コンセンサスを得るために使われている多くの既存ブロックチェーンと対照的である（特にビットコイン[1]やイーサリアム[12]）。 Zilliqaはイーサリアム1.0で用いられているPoWアルゴリズムであるEthash[13]を採用している。

EthashはGPUでマイニングするのを簡単にするがASICのような特定の計算ハードウェアでは難しくなるように設計されているメモリーハードハッシュ関数である。これを達成するためにEthashの計算には関数が特定の計算ハードウェアでは並列処理できないように大量のメモリとI/O帯域幅を必要とする。

大まかに説明すると、Ethashはデータ（例えばブロックヘッダー）と64ビットのnonceを入力として受け取り256ビットのハッシュを生成する。アルゴリズムは順番に計算される４つのサブルーチンで成り立つ。

Seed generation シードはエポックと呼ばれる毎30,000ブロックおきに生成されるSHA3-256ハッシュである。最初のエポックについては全て0でサイズ32のバイト列のSHA3-256ハッシュとする。それ以降は、常に前エポックのシードのSHA3-256ハッシュとする。
Cache generation シードはSHA3-512を用いて擬似乱数キャッシュを生成するのに用いられる。キャッシュのサイズはエポック数と共に線形に増えていく。最初のキャッシュサイズは16MBである。
Dataset generation キャッシュはデータセットを生成するのに用いられる。ここでデータセット内の各項目はキャッシュ内のごくわずかのアイテムに依存している。マイナーが頻繁にデータセットに変更を加えなくても良いように各エポック１回だけデータセットが更新される。データセットのサイズもエポックと共に線形に増えていく。最初のサイズは1GBである。
Mining and Verification マイニングではデータセット内のランダムな部分セットを取り出し、それのハッシュを生成する。検証ではハッシュを計算するのに必要なデータセット内の特定の部分セットを再生成するのにキャッシュを用いる。

第４章　データ層

一般的にデータ層はZilliqaのグローバル状態を構成するデータを定義する。さらにはZilliqaの様々なエンティティがグローバル状態を更新するために必要なデータも定義する。

A. アカウント、アドレス、状態

Zilliqaはイーサリアム同様アカウントベースのシステムである。２種類のアカウントが存在し、ノーマルアカウントとコントラクトアカウントだ。ノーマルアカウントはEC-Schnorrの秘密鍵を生成することで作られる。コントラクトアカウントは他のアカウントによって作られる。

各アカウントはアドレスで特定されるが、アカウントの種類によってその導出方法は異なる。ノーマルアカウントのアドレスはそのアカウントの秘密鍵から導出される。

各アカウントは（ノーマルアカウントでもコントラクトアカウントでも）アカウント状態と結びついている。アカウント状態はキーと値によるストレージであり、次のようなキーを含む。

account nonce（64ビット） ノーマルアカウントから送られたトランザクションの数を数えるカウンターである（初期値は0）。コントラクトアカウントの場合は、そのアカウントによって作られたコントラクトの数を数える。
balance（128ビット） 非負の値。アカウントが別のアカウントからトークンを受け取ると受取額がアカウント残高に加算される。アカウントが別のアカウントにトークンを送ると残高は適切な額だけ減る。
code hash（256ビット） コントラクトコードのSHA3-256ハッシュを保存する。普通アカウントに対しては空の文字列に対するSHA3-256ハッシュである。
storage root（256ビット） 先述の通り、各アカウントはキーと値のストレージを持つが、storage rootはこのストレージを表すSHA3-256ハッシュだ。例えば、このストレージがトライ木なら、storage rootはこのトライ木のルートである。

Zilliqaのグローバル状態はアカウントアドレスとアカウント状態のマッピングである。トライ木のようなデータ構造を用いて実装されている。

B. トランザクション

トランザクションは常にノーマルアカウントのアドレスから送られ、Zilliqaのグローバル状態を更新する。トランザクションは次のフィールドを持つ。

version（32ビット） 現在のバージョン。
nonce（64ビット） あるトランザクションの送信者によって送られたトランザクションを数えるカウンター。
to（160ビット） 送信先のアカウントアドレス。トランザクションが新しいコントラクトアカウントを作成する時には、このフィールドは空の文字列のSHA3-256の右側160ビットである。
amount（128ビット） 送信先のアドレスに送られたトランザクション金額
gas price（128ビット） ガスは計算の最小単位として定義される。gas priceとはトランザクション処理の中で起きる計算に対して送信者が払うガス単価のことを指す。
gas limit（128ビット） トランザクションを処理していている間に使っても良い最大ガス量。
code（無制限） コントラクトコードを表す拡張可能なバイト列。新しいコントラクトアカウントを作成する時のみ存在すする。
data（無制限） トランザクションを処理する際に用いられるデータを表す拡張可能なバイト列。あるアドレスに対してコントラクトを呼び出すトランザクションの時のみ存在する。
pubkey（264ビット） 署名を検証するために使われるEC-Schnorrの公開鍵。pubkeyからそのトランザクションの送信者アドレスも決まる。
signature（512ビット） データ全体に対するEC-Schnorr署名。

各トランザクションはtransaction IDと呼ばれるsignatureフィールドを除いたトランザクションデータに対するSHA3-256ハッシュでユニークに特定することができる。

C. ブロック

Zilliqaプロトコルは２種類のブロックを導入する。transaction block（TX-Block）とdirectry servise block（DS-Block）である。TX-Blockはユーザーに送られたトランザクションを含むのに対して、DS-Blockはコンセンサスプロトコルに参加しているマイナーに関するメタデータを含む。

1) DS-Block

DS-Blockはheaderとsignatureから構成される。 header部分は次のようなフィールドで構成される。

version（32ビット） 現在のバージョン。
previous hash（256ビット） 親ブロックのヘッダーに対するSHA3-256ハッシュ。
pubkey（264ビット） そのブロックヘッダーに対してPoWを行ったマイナーの公開鍵。
difficulty（64ビット） 前のブロックのディフィカルティとブロック番号から計算できる。PoWのディフィカルティを保存する。
number（256ビット） そのブロックよりも前に存在するブロックの数。ジェネシスブロックはブロック番号0である。
timestamp（64ビット） ブロックが生成された時のUnix時刻。
mixHash（256ビット） nonceから計算されるハッシュで、DoS攻撃を検知することができる。
nonce（64ビット） PoWの解。

signature部分は次の２つのフィールドで構成される。

signature（512ビット）

bitmap（1024ビット）

DSブロックはDSブロックチェーンを構成する。

2) TX-Block

先述の通りDS-Blockはトランザクションのコンセンサスに達したノードに関する情報を含む。 TX-BlockはDS-Block内のノードによってどのトランザクションが合意に達したのかについての情報を含む。各DS-Blockは複数のTX-Blockと結びついている。TX-Blockはheader、data、signatureの３つの部分から構成される。 headerは以下のフィールドで成り立つ。

Zilliqaテクニカルホワイトペーパー翻訳