↓もし、良かったらSNSでの紹介よろしくお願いします。

Ethereum勉強メモ~Serenityを理解する(その2)

bootstrap

本記事は

https://www.tech-tech.xyz/archives/understanding-serenity.html

の続きです。

Blocks, Chains and Consensus as Tug of War

従来のproof of workでは、チェーンによって承認が行われていますが、
Casperでは、承認はブロックごとに行われます。
これが、もう一つの独特な構成です。

承認プロセスは他のブロックの高さによらず、
各段階でブロックの状態が決まります。

このメカニズムはいくつかの非効率性をもたらします。
ベットするときにブロック上に記録された承認者の意見を
先頭のブロックのみだけではなく、各段階で記録する必要性があるからです。

しかし、これはconsensus by betの実装を容易にして
ブロックチェーンの処理速度の向上させるメリットもあります。
ブロックのファイナライズはまだまだ時間がかかりことは明らかです。

しかし、ブロックが互いに独立して生成できるため、
このモデルでは、理論上、ネットワークの伝播速度よりも
速いブロック生成を実現することもできます。

チェーンにごとの承認を行う場合、
フォークごとに綱引きを正と負で行います。

ここで、フォークの「状態」は、
右側の最長チェーンのブロック数から
左側のブロック数を引いた数で表します。

クライアントは、先祖のブロックからブロックの状態が負なら左に、
正なら右にたどることで「正しいチェーン」を決めます。
このときブロックが収束するインセンティブは明瞭です。

もし、正の方向に一度進んだら、
それを後押しする強い圧力が発生し正の方向に収束します。

ただし、これはとてもゆっくりです。
もし、負の方向に進んだら、負の方向に進む強い圧力が発生します。

ちなみに、この枠組みのもとでは、
GHOST scoring rule へ自然に一般化できます。

最長のチェーンの長さを数える代わりに
全てのブロックから枝分れしたチェーンのブロックの総数を数えます。

ブロックごとの承認では主導権争いは1回だけ行われます。
この場合、「状態」は、特定のアクションによって増減する任意の数字です。

すべての段階で、クライアントはブロックの状態が正のとき認証し、
負のときは認証を行いないません。

Proof of workは現在、チェーンごとになっていますが、
必ずしもそうである必要がないことがわかります。

容易に創造できるとおり、親のブロックを提供する代わりに
proof of workで認証されたブロックは、
すべての段階で、+1または-1の投票をしている必要があります。

+1の投票は、投票されたブロックが処理された場合に報酬を与えられ、
-1の投票は、投票されたブロックが処理されない場合に報酬を受けます。

もちろん、Proof of workでは、そのような仕組みは単純な理由で機能しません。
もし、過去の全ての段階に投票するとしたら、
投票にかかる計算量は時間とともに二次的に増加し、システムが破綻します。

しかし、コンセンサス・バイ・ベットでは、
綱引きが最終成果に指数関数的に収束するので、
投票処理の負担ははるかに軽いです。

このメカニズムが直観に反する結果の1つは、
あるブロックの後のブロックがファイナライズされいても、
あるブロックが未承認のままという事実です。

これは効率面で大きな壁かもしれないです。
1つのブロックの状態は、その上に10個のブロックがある場合、
10個のブロック全体の状態遷移を再計算する必要があります。

しかし、by-chainモデルでは、チェーン間で
まったく同じことが起こり得ます。

ブロックによる承認では、ユーザーにさらに情報を提供します。

もし、それらの取引が20101番目のブロックで承認、ファイナライズされて、
20100番目のブロックのないように関係なく取引がある結果を有する場合、
前の結果が一部が確定していなくても、そのブロックがファイナライズされます。

チェーンによる承認は、この性質を有することは決してできません。

のこりは次回の記事で…

Understanding Serenity, Part 2: Casperは長い記事でここまでの内容で半分を解説しました。
ここで一区切りなので今回はここまでです。
残りの部分については、近日、公開予定です。乞うご期待!