Lambdaのテクニカルイエローペーパーの翻訳 #4

コンセンサスプロトコル

バリデーター

Lambdaは、バリデーターにとってコンセンサスネットワークを維持する。バリデーターの数は、1024を想定しており、他のノードは、自動的に除外されるルールを考えている。

ストレージマイナーは、ストレージサイズとLAMBを登録することでマイナー候補になることができる。注文がマッチした後、その登録情報はPoSTsにとってブロックチェーンに書き込まれ公開される。そうすることで、候補のマイナーは、公式にストレージマイナーになることができ、更に一定の要件を満たすことでバリデーターに昇格することもできる。バリデーターの数は、Mの変数に設定される値の頻度で更新される。

バリデーターのプロモーションメカニズム

1) ストレージマイナーは、自分たちのストレージにバリデーターがログインできる仕組みを用意する。そして、このルールに違反が続く場合は、デポジットしているLAMBを焼却することになる。

a) バリデーターがそのストレージマイナーにログインできているかを確認

b) ストレージマイナーの実際のストレージ容量をチェックし、またそのストレージ環境が必要要件を満たしているか確認。

2) 上のストレージマイナーリストを計算検証し、NのサイクルでPoSTのエラーが出ないかをチェックする。

3) ストレージ容量に応じて、ストレージマイナーをソートし、TOP(x)の値を設定、Xは、必要最低限のバリデーターの数を表す。

4) 更新されたバリデーターテーブルは、Sort Validator (HASH (Validator ID+Block Height))のアルゴリズムでソーティングされる。

バリデーターのログアウトメカニズム

1) バリデーターテーブルの計算検証を実施し、最後のバリデーターステータスになっているバリデーターがログアウト対象となる。

2) ステータスがログイン状態になるが、そのログインされたストレージキャパシティの要件は満たっていない状態。

3) 上記のバリデーターテーブルの計算検証を実行し、Nの周期で、Mの値に誤りがないかを検証する

4) 上記のバリデーターテーブルを計算検証し、N周期でコンセンサスへの不参加や悪意的な行為がないかを検証する。

Lambdaのコンセンサス

Lambdaのコンセンサスアルゴリズムは現在のバリデーターテーブルに基づく。バリーデーターテーブルの更新戦略についてはセクション3.1を参照

Lambdaのコンセンサスアルゴリズムは、以下のステップに従う:

1) VRFのパラメーターは、新しいブロックナンバー、ConsensusNode Hash、Hash、そして、現在のブロックデータのVRFのシードから作られる。

2) VRFの関数は、VRFのパラメーターに基づいて、新しいVRFシードのラウンドを生成する。

3) ConsensusNodeList = GetConsensusNodeList (ValidatorTable, Index (VRFSeed), TotalConsensusNode)は、VRFシードの新たなラウンドと、バリデーターテーブルに基づいて生成される。

4) ConsensusNodeListは、あらかじめ選ばれたブロックと、投票によって最も高いウェイトのブロックを獲得することで認証される。そのウェイトは、バリデーターセクターの数とノードのハッシュの値に関連している。

5) 投票後、BFTコンセンサスにブロックが到達し、ブロックはネットワークにブロードキャストされる。

コンセンサスインプットの条件:

Height (Block Height) :
Max Block Interval
Max Block Size
Election Seed (VRF Random Seed)
Validator Table
VT Update Cycle
Difficulty (time parameter used to dynamically adjust the block generation cycle)
Block Reward
Reward Curve

コンセンサスのプロセスは以下の通りである:

 

データ・インテグリティ


a) ユーザーは、タグを生成し、アウトソースされるデータの各パーツにそのタグを紐づける。

b) 第3者のアドミニストレーター(TPAs)が、ランダムに、一つかそれ以上のアウトソースされたユーザーデータのブロックに対して検証を行う。この対象は、TPAsによってランダムに生成された値を含む

c) ストレージマイナーは、対象のデータブロック、タグ情報、チャレンジ情報、そして、それらによって生成されたランダム情報の内容に基づく計算を通じて、証明を獲得する。

d) TPAsは、これらのチャレンジ、証拠、そしてパラメーターとしてのユーザーのパブリックキーを使って、バイリニアのマッピング機能を通じて、ストレージマイナーが、そのデータをきちんと保管しているかを認証する。

PDPのスキームは、以下のような問題に直面するだろう:

1) ランダムチャレンジ情報の生成は、TPAsに依存する。つまり、その値が問題がないかどうかはTPAsが保証することになる。

2) チャレンジがローンチされると、検知率を改善するために、複数のブロックのデータが一度に検知される必要があり、各ブロックごとにランダムチャレンジ変数の値が生成される必要があり、これは、チャレンジを立ち上げるためのコミュニケーションの複雑性を大幅に増幅させる。

3) インタラクティブなチャレンジは、高いシンクロ率をもつネットワークを必要とし、その高頻度のインタラクションは、ネットワークのロード率の上場の問題を引き起こす。

4) ストレージマイナーは、様々な種類のフラグメント化されたユーザーのデータを保有するため、各チャレンジが、一つのオーダーに対して立ち上がる場合、その数が増えるほど、ネットワークのロード率の上昇の問題を引き起こす。

5) あるデータのピースが、複数のコピーファイルとして保存されるか、ないしは複数のストレージマイナーとマッチした場合、これはシビルアタックや、誤ったファイルのコピーが出来上がるリスクが発生する。

6) 我々は、どのファイルが現在保存されているかを証明することができるが、二つの検知期間の間におけるファイルがきちんと保管されているかの証明はどのようにして可能か?

7) LAMB-PDPのスキームは、PDPアルゴリズムを元に、以上の問題を解決する必要がある。そして、そのプロセスは以下の通りである。

1) マイナーは、複数のフラグメント化されたファイルを、一つのセクターにカプセル化し、ブロックチェーンンの中に、そのタグ情報や、公開変数、ファイルのインデックス情報を格納する。

2) マイナーは、最新のブロックからランダムチャレンジシード”R”を受け取り、今回のチャレンジターゲットであるセクター”S”を計算する。マイナーは、全てのセクターが、Mの周期内にProof of Storageを提出し、その計算に応じた収益を受け取る。

3) マイナーは、GenChallenge(R , S , Index) -> challenge.に基づき、チャレンジを生成し、GenProof(data, challenge, tag) -> proof.に基づき、その証明を生成する。

4) マイナーは、GenNextChallenge(proof_i)を使って、Proof Setをt時間の証明とともに生成する。

5) マイナーは、そのProof setをネットワークにサブミットし、バリデーターにとって認証され、パッケージされるのをまつ。

6) マイナーは、一つのセクターに、PoSTを継続的に提供しなければならない。もし、PoSTが、Tの周期内に実行されな場合、そのセクターは、紛失したと判断される。

7) そのセクターが、紛失した場合、それに応じたペナルティが発動し、別のセクターのマイナーとマッチングされ、格納される。

8) その再格納の作業は、ユーザーによって実行される。

つづく。

関連記事