本稿について
本稿では、The ZILLIQA Technical Whitepaper Version0.1の「VI. Consensus Layer」の日本語訳を掲載します。プログラム的な構造体や変数を主に意図して記載されている語（プログラムの自体で記述されている語）に関しては日本語ではなく英語のまま記載します。
原文はこちらになります。
スポンサードサーチ
6 コンセンサスレイヤ
以前述べたように、各シャードとDSコミティはマイクロブロックとファイナルブロックのどちらに対してもコンセンサスプロトコルを実行せねばならない。このセクションでは各シャードとDSコミティで実行するコンセンサスプロトコルを定義するコンセンサスレイヤ（consensus layer）を説明する。以降の議論では、シャードとDSコミティをまとめてコンセンサスグループ（consensus group）と呼ぶものとする。
A. PBFT（Practical Byzantine Fault Tolerance）
ZILLIQAのコンセンサスプロトコルの中核はCastroとLiskov[3]により提唱されたPBFTプロトコルに基づく。しかし、既に開発されている[14],[15]ようにPBFTプロトコルにEC-Schnorrマルチシグを利用するというアイデアを用いることでZILLIQAは効率性を向上させている。EC-Schnorrマルチシグの利用により通常時の通信レイテンシはO(n2)からO(n)へ、署名サイズをO(n)からO(1)へ低減される。ここで、nはコンセンサスグループのサイズである。このセクションではPBFTの概要を説明する。
PBFTでは、コンセンサスグループの全てのノードは直列に並べられて、主（primary）ノード（またはリーダー）が1つあって、それ以外はバックアップ（backup）ノードと呼ばれる。PBFTの各ラウンドには以下に述べるように3つのフェーズがある。
- 準備の準備フェーズ：このフェーズでは、リーダーはグループが合意すべき次の記録（ZILLIQAの場合はTX-Block）を知らせる。
- 準備フェーズ：準備の準備メッセージを受信するとすぐに各ノードはその正当性を検証して他ノードへ準備（prepare）メッセージを多重送信する。
- コミットフェーズ：n*2/3より多くの準備メッセージを受信するとすぐにノードはグループにコミット（commit）メッセージを多重送信する。最後にノードは十分な数のノードが同一の意思決定をしたことを確実にするために2/3より多くのコミットメッセージを待機する。従って全ての誠実なノードは同一の有効なレコードを受け入れる。
十分な多数派が存在する場合、PBFTは各ラウンドを開始して進むために正しいリーダーに依存する。もしリーダーがビザンチンであれば、コンセンサスプロトコルをストールさせることができてしまう。この問題に対処するため、PBFTはビザンチンなリーダーを他のリーダーと入れ替えるビューチェンジ（view change）プロトコルを提供している。一定時間内に何らの進捗も見られない場合、ノードは単独でリーダーの変更要望を出すことができる。定足数であるn*2/3より多くのノードがリーダーは不正であると判断すると、周知のスケジュールの次のリーダーに引き継がれる。準備フェーズとコミットフェーズにおける各ノードの多重尊信のお陰で、通常時のPBFTの通信複雑性はO(n2)である。
B. 効率性の向上
古典的なPBFTはノード間の認証付き通信にMAC（message authentication code, メッセージ認証コード）を用いる。MACは2ノード間で共有されている秘密鍵が必要なので、1つのコンセンサスグループ内のノードは1ノードあたりO(n2)の通信複雑性で同一のレコードに合意できる。2次関数の複雑性のせいでPBFTはコミティに20を超えるノードがいる場合は非実用的になる。
効率性向上のためZILLIQAはByzCoin[15]から着想を得たアイデアを使う。
- MACを電子署名に置き換えることで効率的に通信のバーヘッドをO(n)に低減する。
- その間に他のノードが合意を検証できるようにするための典型的な方法は誠実な多数派から署名を集めて合意に追加することで、これにより合意のサイズはコンセンサスグループのサイズに対して線形となる。これについて改善するためにEC-Schnorrマルチシグを利用していくつかの署名を集約してO(1)サイズのマルチシグにする。
しかし、PBFTのセッティングで古典的なEC-Schnorrマルチシグスキームを直接利用することはできない。というのも古典的なセッティングでは、全署名者は所与のメッセージに署名することについて合意し、そしてその署名は全署名者が当該メッセージについて署名しない限り有効にならないからである。PBFTのセッティングにおいてZILLIQAが必要とするのはコンセンサスグループのノードのn*2/3超が署名したメッセージだけである。必要となる主な修正の一つは署名プロセスに参加した署名者に関するビットマップBを保持することである。i番目のノードが署名プロセスに参加したのならば、B[i] = 1で、それ以外の場合はB[i] = 0である。ビットマップはリーダーが作成する。そしてあらゆる検証者は署名を検証するのにビットマップを利用できる。出来上がったプロトコルをAppendix Bに示す。
C. ZILLIQAのコンセンサス
ZILLIQAではPBFTを基本的なコンセンサスプロトコルとして用いつつ、PBFTにおける準備フェーズとコミットフェーズを置き換えるためにEC-Schnorrマルチシグを利用する。PBFTの各フェーズに対する変更をいかに説明する。
- 準備の準備フェーズ：スタンダードなPBFT同様、リーダーはTX-Blockやステートメント（リーダーが署名したもの）をコンセンサスグループの全ノードへ分配する。
- 準備フェーズ：全ての誠実なノードはTX-Blockの有効性をチェックし、リーダーはn*2/3より多くのノードからの応答を集める。これにより、リーダーにより提案されたステートメントが安全かつ過去のあらゆる履歴と一致していることが保証される。署名はEC-Schnorrマルチシグを使って生成される。また、リーダーはTX-Blockに署名したノードのビットマップも作成する。
- コミットフェーズ：n*2/3より多くのノードがTX-Blockに署名したという事実をn*2/3より多くのノードが分かっていることを確実にするために、ZILLIQAでは2ラウンドのEC-Schnorrマルチシグを実行する。署名されるステートメントは最後のラウンドから生成されたマルチシグである。
3つのフェーズの最後にリーダーが提案したTX-Blockについてのコンセンサスが形成される。
D. 元帳の変更
ZILLIQAのコンセンサスプロトコルでは、リーダーが誠実であればリーダーはコンセンサスグループ内のノードを新しいトランザクションの集まりについての合意形成に継続的に導くことができる。しかし、リーダーがビザンチンであればリーダは誠実なノードからのメッセージを意図的に遅延したり欠落したりしてプロトコルを低速にすることができる。このような悪意あるリーダーにペナルティを科すために、プロトコルは各シャードとDSコミティのリーダーを定期的に変更する。これによりビザンチンなリーダーがコンセンサスプロトコルを無期限にストールさせてしまうのを防ぐ。全てのノードは順序付けられているので、次のリーダーはラウンドロビン方式で選ばれる。
実際にシャードのリーダーはマイクロブロックごとに変更され、DSコミティのリーダーはファイナルブロックごとに変更される。コンセンサスグループのサイズをnとすると、1DS-epoch中に最大でn個のファイナルブロックを作ることができて、各ファイナルブロックは1シャードあたり最大1個のマイクロブロックを集約したものである。
（ZILLIQAホワイトペーパー日本語訳6 ←← 前）｜（次 →→ ZILLIQAホワイトペーパー日本語訳8）
免責
邦訳には誤りがある場合がございます。予めご承知おき下さい。
確実な情報を知るためには冒頭に示した原文をご参照くださいますようお願いいたします。