Binanceスマートチェーンのコンセンサスエンジン#

概要#

以下の目標を達成するために、BSC(Binance Smart Chain)のコンセンサスエンジンを設計することを目標としています。

1.確認するために数ブロック待ちます(Ethereum 1.0未満である必要があります)。ほとんどの場合、フォークは使用しない方がよいでしょう。
2.ブロッキング時間はイーサリアム1.0より短く、つまり5秒以下にする必要があります。
3.インフレなし、ブロック報酬はトランザクションガス料金です。
4.イーサリアムと同じくらい互換性があります。
5.宇宙と同じくらい強力なステーキングとガバナンスを備えています。

Gethは、ethash(PoWに基づく)とclique(PoAに基づく)の2種類のコンセンサスエンジンを実装しています。BSCはPoWを放棄するため、EthashはBSCに適したオプションではありません。Cliqueはブロッキング時間が短く、51%の攻撃に対して無防備ですが、既存のイーサリアムクライアントの互換性を維持するためにコアデータ構造にできる限りの影響を与えません。PoAの欠点は、集中化と、チェーン上の意味のあるステーキングおよびガバナンス機能の欠如です。一方、Binanceチェーンは、ステーキングとガバナンスのメカニズムが展開されているCosmos上に構築されています。したがって、ここでは、次のようなコンセンサスエンジンを提案しようとします。

  • Binanceチェーンは、BSCのステーキングとガバナンスの部分を実行します。
  • ValidatorSetの変更、BSCの二重記号スラッシュがチェーン間通信を通じて更新されます。
  • BSCのコンセンサスエンジンは、クリークと同じくらいシンプルに保たれます。

PoAコンセンサスのいくつかの一般的な実装を調査したところ、Borは上記と同様の設計に従っていることがわかりました。Borからいくつかの部品を借りて、これらすべての目標を達成するための新しいコンセンサスエンジンを提案します。

インフラストラクチャコンポーネント#

1.Binanceチェーン。独立した選挙を通じてBSCの検証者を決定するためのステーキング機能を保持する責任があり、選挙ワークフローはステーキング手順によって実行されます。
2.BSCバリデーター。検証者は、トランザクションの検証とブロックの生成を担当し、ネットワークのセキュリティと元帳の一貫性を確保します。その見返りに、彼らは取引のガス消費から報酬を受け取ります。
3.BSC(システムコントラクトとも呼ばれます)にdAppをステーキングします。BSCへのステーキングの実装を支援するためのいくつかのジェネシス契約があります。

6つの分類グループ:

  • 軽いクライアント契約。これは、Binance Chainのコンセンサスアルゴリズムのみを検証する、コントラクトによって実装される分散コンセンサスプロセスのウォッチャーです。
  • クロスチェーン契約。クロスチェーン通信層です。クロスチェーンパッケージのシーケンスとマークルプルーフを検証します。
  • BSCValidatorSetコントラクト。BinanceChainでのBSCのバリデーター変更のウォッチャーです。BSCのバリデータセットの変更が適用されます。また、バリデーターのブロッキングの報酬ガス料金を保存し、validatorSet変更のクロスチェーンパッケージを受け取ったときにバリデーターに収益を分配します。
  • システム報酬契約。中継者がシステム契約を維持するためのインセンティブメカニズム。彼らはシステム報酬契約から報酬を受け取ります。
  • 活気スラッシュ契約。BSCの活性は、検証セットに依存しており、順番が来たときにタイムリーにブロックを生成できます。検証者は、何らかの理由で順番を逃す可能性があります。この操作の不安定さは、ネットワークのパフォーマンスを低下させ、システムにより多くの非決定論をもたらします。このコントラクトは、各バリデーターの欠落したブロッキングメトリックを記録する責任があります。メトリックが事前定義されたしきい値を超えると、検証者のブロック報酬は配布のためにBCに中継されませんが、他のより優れた検証者と共有されます。
  • その他の契約。BSCは、Binanceチェーンの強力なガバナンスを利用する場合があります。たとえば、システム契約のパラメーターを変更することを提案します。

Binance Chainのステーキングとガバナンスは、コンセンサスに基づいて上位層にあります。Relayerに関しては、それはスタンドアロンプ??ロセスであり、それを実装する方法についてオープンです。それらの詳細は、このドキュメントには含まれません。

このドキュメントは、コンセンサスエンジンにより近いBSCパーツのBSCバリデーターとステーキングdAppにのみ焦点を当てています。

システム報酬の分配#

BSCのシステム報酬構造は高度に構成可能です。ガバナンスを通じてパラメータを調整する場合があります。

報酬は取引手数料から発生し、報酬はいくつかの(構成可能な)ルールに基づいて分配されます。

1.ブロックを生成する検証者は、ガス料金の15/16を受け取ります。
2.システム報酬契約は、ガス料金の1/16を受け取ります。

システム報酬契約の残高が100BNBを超える場合、BNBは配布されません。次のセクションでは、これらの契約がどのように報酬を分配するかについて説明します。

BSCでdAppをステーキング#

BSCValidatorSetコントラクト (URL Link: https://bscscan.com/address/0x0000000000000000000000000000000000001000)
Binanceチェーン上のBSCのバリデーター変更のウォッチャーです。次のインターフェイスを実装します。

  • handleSynPackage(uint8、bytes calldata msgBytes) Conditions:1 メッセージ送信者はCrossChainContractである必要があります。

Action:1 msgBytesの最初のバイトが0x00の場合、アクションバリデーターを更新します。2. msgBytesの最初のバイトが0x01の場合、アクションjailを実行します。

Actions jail:1 検証者をjailedとしてマークします。

Actions validators update:

1. Do distribue the revenue of validators:
if the revenue is large than 0.1 BNB, will do cross chain transfer to its account on BC, otherwise will transfer to its address on BSC.
2. Update the latest validatorSet.
3. Clean the metrics record on slash contract.

CurrentValidator() returns ([]address)

returns the the consensus address of not jailed validators.

deposit(address valAddr) external

Conditions:

1. The message sender must be the coinbase
2. Can only call once in one block.

Actions:

1. Increase the revenue of the validator.

システム報酬契約(URL Link: https://bscscan.com/address/0x0000000000000000000000000000000000001002)

現在のところ、システム報酬契約を呼び出すことができるのはクロスチェーン契約のみです。次のインターフェイスを実装します。

  • claimRewards(address payable to, uint256 amount) external

Conditions:

1. The message sender must in permission list.
2. The amount should be no more than 1 BNB

Actions:

1. Transfer amount of BNB to specified address

Liveness Slash contract(URL Link: https://bscscan.com/address/0x0000000000000000000000000000000000001001)

バリデーターがブロックの生成に失敗した場合、それを記録し、最後にスラッシュします。次のインターフェイスを実装します。

Slash(validator address) external

Conditions:

1. The message sender must in coinbase.
2. can only call once in one block.

Actions:

1. increase the missing blocks metrics of the validator by one.
2. if the missing blocks metrics is times of 50, will call misdemeanor func of BSCValidatorSet contract to trigger a misdemeanor event and distribute the revenue of the validator to others.
3. if the missing blocks metrics is times of 150, will call felony func of BSCValidatorSet contract to trigger a felony event, not only distribute the revenue of the validator to others, but also kick the validator out of validatorset.

コンセンサスプロトコル#

コンセンサスエンジンの実装は、クリークに似たParliaと呼ばれます。このドキュメントでは、違いに焦点を当て、一般的な詳細は無視します。

紹介する前に、いくつかの用語を明確にしたいと思います。

1.Epoch block : コンセンサスエンジンは、BSCValidatorSetコントラクトからvalidatorSetを定期的に更新します。今のところ、期間は200ブロックですが、ブロックの高さが200倍の場合、そのブロックはエポックブロックと呼ばれます。 2.Snapshot : スナップショットは、ブロックの検証者と最近の署名者を保存するのに役立つアシスタントオブジェクトです。

主な機能#
軽いクライアントセキュリティ#

バリデーターセットの変更は、(エポック+ N / 2)ブロックで行われます。(Nは、エポックブロックの前のvalidatorsetのサイズです)。ライトクライアントのセキュリティを考慮して、validatorSetの変更が行われるようにN / 2ブロックを遅延させます。

エポックブロックごとに、validatorはコントラクトからvalidatorsetを照会し、ブロックヘッダーのextra_dataフィールドに入力します。フルノードは、コントラクトのバリデータセットに対してそれを検証します。ライトクライアントはそれを次のエポックブロックのvalidatorSetとして使用しますが、コントラクトに対して検証することはできず、エポックブロックの署名者を信じる必要があります。エポックブロックの署名者が間違ったextra_dataを書き込んだ場合、ライトクライアントは間違ったチェーンに移動する可能性があります。N / 2ブロックを遅らせてvalidatorSetの変更を行わせると、間違ったエポックブロックは、他のバリデーターによって署名された別のN / 2後続ブロックを取得しないため、ライトクライアントはそのような攻撃を受けません。

システムトランザクション#

コンセンサスエンジンはシステムコントラクトを呼び出す場合があり、そのようなトランザクションはシステムトランザクションと呼ばれます。システムトランザクションは、ブロックを作成している検証者によって署名されます。監視ノードの場合、は、固有のロジックに従ってシステムトランザクション(署名なし)を生成し、それらを適用する前にブロック内のシステムトランザクションと比較します。

バックオフを実施する#

クリークコンセンサスプロトコルでは、ターン外の検証者は、ブロックを封印する前にランダム化された時間待機する必要があります。これはクライアント側のノードソフトウェアに実装されており、バリデーターが正規バージョンを実行することを前提として機能します。ただし、検証者ができるだけ早くブロックをシールするように経済的に動機付けられることを考えると、検証者はそのような遅延を無視するためにノードソフトウェアの修正バージョンを実行する可能性があります。バリデーターがブロックをシールするために急いでいるのを防ぐために、すべてのアウトターンバリデーターはブロックをシールするために指定されたタイムスロットを取得します。アウトターンバリデーターによって生成されたブロッキング時間が早いブロックは、他の監視ノードによって破棄されます。

新しいブロックを作成する方法#

Step1:準備
検証ノードは、次のブロックのブロックヘッダーを準備します。

  • キャッシュまたはデータベースからスナップショットをロードし、(height%epoch)== 0の場合、BSCValidatorSet コントラクトからValidatorSetをフェッチする必要があります。
  • すべてのエポックブロックは、extraDataライトクライアントの実装を容易にするために、検証子セットメッセージをブロックヘッダーのフィールドに格納します。
  • コインベースは検証者のアドレスです

Step2:組み立て
* バリデーターが順番にバリデーターでない場合は、活性スラッシュコントラクトを呼び出して、予想されるバリデーターをスラッシュし、スラッシュトランザクションを生成します。 * ブロック内にガス料金があり、システム報酬契約に1/16を分配し、残りは検証者契約に行きます。

Step3:密閉
バリデーターが新しいブロックをブロードキャストする前の最後のステップ。

  • ブロックヘッダー内のすべてのものに署名し、extraDataに署名を追加します。
  • 検証者がブロックに署名する順番がずれている場合、正直な検証者はランダムな妥当な時間待機します。
ブロックを検証/再生する方法#

Step1:ヘッダーの検証
新しいブロックを受信するときに、ブロックヘッダーを確認します。

  • コインベースの署名がブロックヘッダーのextraDataにあることを確認します
  • blockHeaderのブロック時間と、署名者が使用することを想定している予想ブロック時間を比較すると、予想よりも小さいblockerHeaderが拒否されます。利己的な検証者が急いでブロックを封印するのを防ぐのに役立ちます。
  • コインベースは署名者であり、難易度は期待値である必要があります。

ステップ2:最終段階
* エポックブロックの場合、バリデータノードはBSCValidatorSetからvalidatorSetをフェッチし、extra_dataと比較します。 * ブロックがinturnvalidatorvalidarorによって生成されない場合、スラッシュコントラクトを呼び出します。ブロック内にガス料金があり、システム報酬契約に1/16を分配し、残りは検証者契約に行きます。 * コンセンサスエンジンによって生成されるトランザクションは、ブロック内のtxと同じである必要があります。

署名#

コインベースの署名はブロックヘッダーのextraDataにあり、extraDataの構造は次のとおりです。
エポックブロック

  • 32バイトのextraVanity + N * {20バイトのバリデータアドレス} +65バイトの署名。

なしエポックブロック

  • 32バイトのextraVanity + 65バイトの署名。

署名されたコンテンツは、ブロックヘッダーでエンコードされたRLPのKeccak256です。

セキュリティとファイナリティ#
  • 1/2 * N + 1を超える検証者が正直であることを考えると、PoAベースのネットワークは通常安全かつ適切に機能します。ただし、一定量のビザンチン検証ツールがネットワークを攻撃する可能性がある場合もあります。 「クローンアタック」を通じて。 BCをできるだけ確保するために、BSCユーザーは、2/3 * N +1を超える異なるバリデーターによって封印されたブロックを受信するまで待つことをお勧めします。このようにして、BSCはBCと同様のセキュリティレベルで信頼でき、1/3 * N未満のビザンチン検証子を許容できます。
  • 21個のバリデーターで、ブロック時間が5秒の場合、2/3 * N + 1の異なるバリデーターシールには(2/3 * 21 + 1)* 5 = 75秒の期間が必要になります。 BSCの重要なアプリケーションは、比較的安全なファイナリティを確保するために2/3 * N +1を待たなければならない場合があります。ただし、そのような取り決めに加えて、BSCは、二重署名または不安定性に対してビザンチン検証者にペナルティを課すためのスラッシュロジックを導入しています。このスラッシュロジックは、悪意のある検証ツールを非常に短時間で公開し、クローン攻撃の実行を非常に困難または非常に非経済的にします。この機能拡張により、ほとんどのトランザクションの確認として、1/2 * N +1以下のブロックで十分です。
潜在的な問題#
一時的な検閲を介して現在の検証者セットの決定を拡張する#

検証ツールを更新するトランザクションがエポック期間にBSCに送信された場合、順番の検証ツールがトランザクションを検閲し、そのエポックの検証ツールのセットを変更しない可能性があります。他のn / 2バリデーターの助けがなければ、トランザクションを永久に検閲することはできませんが、これにより、現在のバリデーターセットの時間を延長し、いくつかの報酬を得ることができます。一般に、このスキームの可能性は、他の検証者と共謀することによって増加する可能性があります。ブロックが約5秒で、1つのエポックが240ブロック、つまり20分である可能性があるため、バリデーターをさらに20分間しか延長できないことは、比較的良性の問題です。

BCとBSCの比較#

--- Binanceチェーン Binanceスマートチェーン
コンセンサス DPoS PoSA
検証者の数 11 21まで
平均ブロック時間 <1秒 ~ 5秒
プログラマビリティ BEP EVM互換のスマートコントラクトをサポートする
  • クロスチェーン
Binanceチェーン Binanceスマートチェーン
BEP3は、ハッシュタイマーロックコントラクト関数と、ブロックチェーン間トークンペグを処理するためのさらなるメカニズムを導入しています。 BSCには、効率的なネイティブデュアルチェーン通信が付属しています。高速でスムーズなユーザーエクスペリエンスを必要とする高性能dAppのスケーリング用に最適化されています。