キャスパープロトコル-コンセンサスを達成し、信頼の問題を解決する方法
これは、RChainブロックチェーンプロジェクトのデータと計算の信頼性を担当するCasperプロトコルの信頼ネットワークのグラフです。 開発者の中核はシアトルに住んでいますが、 RChain.coop協同組合にはアジア、アフリカ、ヨーロッパの開発者がいます。 このテキストは、プロジェクトの主任開発者の1人であるMichael BirchによるCasper Consensus Protocolに関する投稿に基づいています。
habrの聴衆は、おそらくコンセンサスを提供し、どのデータを信頼できるか、どのデータを信頼できないかを決定できるプロトコルに精通しているでしょう。 問題とその解決策のより詳細な説明は、Ethereumプラットフォームの主要な開発者の1人のプレゼンテーション、 Vlad Zamfiraおよび他の講義で見つけることができます。
キャスパープロトコルの概要
RChainブロックチェーンでは、コンピューティングプロセスのpi代数を使用して作成されたCasperプロトコルのおかげでコンセンサスが生まれています。 このプログラミングアプローチは
プロトコルにはいくつかの便利なプロパティがあります。
- イーサリアムのように、ブロックチェーンではなく、有向非巡回ブロックグラフ（blockDAQ）でコンセンサスが発生します。 これは、ブロックが複数の親と複数の子を持つことができることを意味します。 この構造のおかげで、独立したブランチを1つに結合するのが簡単になり、コンセンサスに達するまでの時間が短縮されます。
- このネットワークには、政治的資本（PC）の概念が含まれており、検証者によって検証され、正直な業務遂行のために開発されています。 バリデーターがこのブロックに賭けることを決定するPCのボリュームは、フォークGHOSTを選択するためのルールによって決定されるその重みに依存します。 バリデーターは、新しいブロックを作成して投票するだけでなく、古いブロックを確認することもできます。 確認手順はGHOSTルールに依存しないため、検証者はブロックグラフのどのブランチを継続する必要があるかについて、より強力な意見を持っています。 ブロックを認識することが、PCを獲得する唯一の方法です。 これは、他のプロトコルとの非常に重要な違いです。 これにより、このようなシステムで新しいブロックを作成する唯一の方法は、コンセンサスプロセスに最も長く関与していたブランチに参加することです。
gifは、RChainネットワークの3つのノードバリデーターの動作を示しています。 色付きの円はblockDAQのブロックを示し、色はそれらを作成したノードによって異なります。 最初の唯一のオレンジ色のドットは、ジェネシスブロックです。 円の直径は、ブロック内のトランザクションの数と、このブロックで実行される契約の数に依存します。 最小の円は、契約がなく、確認のみで構成されるブロックを示します。 矢印は親ブロックを示します。 赤い矢印は、ゴーストルールによって決定されるメインNAGの面に対応し、黒い矢印はドロップされた、またはドロップされるブランチを示します。
RChainノードバージョン0.3はgithubからダウンロードできます。 ブロックチェーンの最初のバージョンの発売は今年の終わりに予定されています。タイムライン「Flight to Mercury」をご覧ください。 このようなネットワークで開始された契約は、 Po言語で書かれています。