Stratis マスターノード登録プロトコル

Stratis マスターノードは,サービスのリストを分散して改ざんを防ぎながら,ブロックチェーンネットワークに有用なサービスを提供します。
最初のマスターノードの実装で提供されるサービスは Breeze プライバシープロトコルですが,今後さらに多くのサービスが追加される事が予想されます。

各マスターノードは Stratis ブロックチェーンを介してその存在を登録(宣伝)する必要があります。
これはマスターノード登録プロトコルと呼ばれるものです。
マスターノード登録は,特別にフォーマットされた Stratis トランザクションで構成されています。
このトランザクションには,マスターノードに接続して検証するためにクライアントが必要とするすべての関連情報が含まれています。

登録トランザクションはいったんネットワークに提出されると,その登録を管理するコンセンサスルールの1つによって無効にされるまで無期限に有効となります。

  • マスターノードサーバの資金調達アドレスは,最初のウィンドウ期間内に資金が供給されません。
  • 担保資金は、ウインドウ期間の終了時には不十分です。(担保および残高の追跡に関する追加情報については,担保の検証を参照してください。)
  • 担保資金は全部または一部が別のアドレスに移されるため,残高は必要な基準額を下回ります。
    後続の登録はオリジナルよりも大きいブロック高で行われます。(例えばマスターノードの公開パラメータを更新します。)
  • 登録は N ブロックごとに有効期限が切れるため,オペレータは定期的にリフレッシュする必要があります。(現在施行されていません。)

Breeze クライアントソフトウェアの責任として,Stratis ブロックチェーンをスキャンして,サーバとの接触を開始する前に最新のマスターノード登録を取得してください。
ビットストリーム形式に一致するトランザクションを探して,各着信ブロックを観察することによってこれを行います。
登録が見つかると,ノードのローカルストアに登録されます。

登録が受信されたブロック高は,マスターノード資金調達トランザクションのウィンドウ期間を決定します。
マスターノードオペレータは,このウィンドウが経過する前に必要な担保を資金調達先に移動する必要があります。
これが行われない場合,登録は期限切れとみなされネットワーク上のすべてのノードのローカル記憶域からパージされます。

十分な数の有効なマスターノード登録がダウンロードされると,クライアントはランダムにそれを選択し,そのサービスを利用するために接続します。(Breeze プライバシープロトコル等)
オプションで,ブロックチェーン全体がダウンロードされるとマスターノードの選択を行うことができます。
これは,チェーンの後半に登録するマスターノードよりも公平です。

上記のプロセスは Stratis ソフトウェア製品に既に実装されています。

マスターノード登録トランザクションのビットストリーム形式

登録トランザクションは,Stratis ネットワーク上でブロードキャストされる単一のトランザクション(テスト用のテストネットまたはマスターネット用のメインネットのいずれか)で構成されます。
この取引には,通常通り任意の数の資金入力が可能です。

これは正確には,マスターノード登録としてトランザクション全体をマークする1つのヌルデータ(データストレージ)出力を持っているという事になります。
オプションの変更リターン出力が存在する場合は,出力リスト全体の終わりになければなりません。
残りの取引出力は,ほぼダスト値です。
各出力は64バイトのデータを公開鍵スクリプトにエンコードされます。
符号化されたデータの内容とフォーマットについては後述します。

データ破損の可能性があるため,トランザクションの出力がブロードキャストマスターバスによって並べ替えられないことが前提とされています。

OP_RETURN トランザクション出力

フィールド サイズ 記述
1 26 bytes リテラル ASCII 文字列:BREEZE_REGISTRATION_MARKER

エンコードされた公開鍵トランザクション出力

フィールド サイズ 記述
1 1 byte プロトコルバージョンバイト(>200の場合,メインネットウォレットによって無視されるテスト登録となります。)
2 2 bytes 登録ヘッダーの長さ
3 34 bytes マスターノードのサーバ ID(副次的なアドレスの base 58 表現で長さが34文字未満の場合は空白で埋められます。)
4 4 bytes マスターノードの IPv4 アドレスで1オクテットあたり1バイトとなります。空のアドレスには 00000000 を使用します。このフィールドは将来機能するプレホルダーのために Breeze プライバシープロトコルでは使用されません。
5 16 bytes マスターノードの IPv6 アドレスで1オクテットあたり1バイトとなります。空のアドレスには 00000000 00000000 00000000 00000000 を使用してください。このフィールドは将来機能するプレホルダーのために Breeze プライバシープロトコルでは使用されません。
6 16 bytes マスターノードサーバ URI で,現時点では接頭辞または接尾辞を持たない ASCII オニオンアドレスホスト名となります。空のアドレスは 00000000 00000000 00000000 00000000 と表示されますが,この空のままにしておくと現在の Breeze プライバシープロトコルの実装には無効です。
7 2 bytes マスターノードの TCP ポートはクライアントの実装によって無視される事があります。
8 2 bytes RSA 署名の長さ(バイト単位)
9 n byte Breeze プライバシープロトコルサーバの秘密鍵の所有権を証明する RSA 署名です。
10 2 bytes ECDSA 署名の長さ(バイト単位)
11 n bytes ECDSA 署名は,サーバ ID として使用されるアドレスの秘密鍵で作成されます。この同じアドレスには担保を置く必要があります。
12 40 byte Breeze プライバシープロトコルサーバの構成ファイルのハッシュです。これはプロトコルの次のバージョンのヘッダに移動する事ができます。
将来新しい機能に対応するためにプロトコルフォーマットを拡張する事ができます。新しいフィールドは,既存のフィールドとの下位互換性を維持するために可能な限り試行する必要があります。

クライアントによる Breeze プライバシープロトコルサーバとの接続では,サーバが公開鍵を所有していることを確認するために,サーバの公開鍵がクライアントによって検証されます。
その後,プライバシープロトコルが通常通りに機能します。

担保確認

Breeze プライバシープロトコルがうまく機能するためには,多数のまたは十分に強力でないマスターサーバを作成する必要があります。
したがって,参加するクライアントノードによってマスターノードの有効性を管理するコンセンサスルールを確立し,実施する必要があります。

Stratis マスターノードには,準拠とみなされる Stratis コイン($STRAT)を250,000枚要します。
STRAT は単一のアドレスに保管しておかなければならず,資金を移動しない様にしてください。

各新しいブロックの受信時に,非マスターノードは現在追跡されているマスターノードサーバに影響を与えるものについて各トランザクションをチェックします。
資金がアドレスから移動された場合,ステイキング残高は減少します。
資金が入金されると,ステイキング残高が増加します。
マスターノード登録は250,000 STRAT のしきい値を下回ると自動的に削除されます。
したがって,不注意に登録を無効にすることを防ぐために担保資金で重要な取引活動を行うことは推奨されません。

上の図は,マスターノードの登録シーケンスの4つの基本的なシナリオを示しています。

  • ノード1はウインドウ期間内に十分な資金調達取引を行っており,その担保は準拠しているとみなされます。
  • ノード2はウインドウ期間の後に最初は準拠していたが,後でアドレスから資金を取り除いたため,担保が足りなくなったものです。
  • ノード3は集約されたときにターゲットアドレスに十分な担保を形成する2つの送金を行いました。(これは有効ではありますが,資金調達を行う標準ではない方法です。)
  • ノード4は資金調達取引を実行するには時間がかかりすぎた(ウィンドウ期間外でした)ので,担保債務に関して非遵守とみなされます。また,担保検証機能も既に Stratis のソフトウェア製品に実装されています。

今後の改善

ノード間検出プロトコル

この論文で概説されているアプローチの欠点は,すべてのノードが担保のバランスを正確に決定するために起点ブロックからブロックチェーン全体をダウンロードしなければならない点です。
登録がフルノードによって累積され,正確さのある十分な証拠をもってピア(フルノードまたはライトノード)に回覧される方が効率的です。

ノード間検出プロトコルは Stratis ノードソフトウェアにすでに実装されていますが,初期バージョンを可能な限りシンプルに保つために現在は使用されていません。
また,ピアポリシングモデルのセクションで説明されているピアポリシングの間接的な要件もあります。

改善提案 – ピアポリシングモデル

既存のマスターノード実装と構想された Stratis マスターノードアプローチの間には以下の違いがあります:

  • Dash のマスターノードは’受動的に’報酬を受けます。これは,作業を行わないマスターノードの支払いを避けるためにネットワークの残りの部分が検証可能な方法で積極的に ping を実行する必要があります。
  • 逆に,Stratis マスターノードは現在接続されたクライアントの Breeze プライバシープロトコルに積極的に参加することによってのみ報酬を得ることができます。これは,マスターノードを直接警戒する必要性を取り除きます。
  • 最上位層の Stratis マスタノードのコストが高いため,オペレータはネットワークに積極的に参加するように経済的インセンティブを与えると推定されます。これは,Proof of Stake コンセンサスメカニズムの中心的な教義に似ています。

Dash のアプローチのいくつかの側面,特にコールドストレージに担保を置く方法はエミュレートすることが望ましいです。
Stratis トップティアマスターノードの要件は,次のように要約できます:

  • ノードオペレータは,少なくとも250,000 STRAT を所有していなければなりません。(移動または使用するための秘密鍵を所有している必要があります。)
  • これらの担保となる STRAT は単一のアドレスに存在しなければなりません。
  • Stratis の担保が別のアドレスに移動されると移動前に所有されていた証拠は無効になります。

これらの要件は,プライバシープロトコルセキュリティモデルの希釈を防ぐために積極的に実施する必要があります。
施行を実行するのに最も適したエンティティは,Stratis ネットワーク上のマスターノードのピアであることが提案されています。
これらのピアは,次のいずれかです:

  • 別のマスターノード(本質的に追加機能を備えたフルノード)
  • Stratis ブロックチェーンの完全なコピーを持つ「フル」ノード
  • チェーン全体のコピーを保持しないが,少なくともブロックヘッダーを保持する「ライト」ノード
  • 他のタイプのノード(ドキュメントの範囲外です。)

責任は,そのサービスをネットワークに広告する特定の幹線道路上にあります。
これは,すべてのノードが利用可能な情報に応じて,マスターノードの登録を有効と見なすかどうかを選択できることを意味します。
ゲーム理論的な観点からは,「ライバル」マスターノードのオペレータは,特定のマスターノードのネットワークの他の部分への非準拠の証明を直ちに提示することが有利となります。
さらに,正当なノードが無効であることが知られている登録を伝播するために得られる利点はないと推測されます。

「非準拠の証明」(Proof-of-Non-Compliance)コンセプトの登録と実装の「生涯」の例は,以下のとおりです:

  1. オペレータはマスターノードを構成し,起動時にマスターノード登録 Y を生成します。
  2. ノードオペレータは十分な担保を住所 X に移動します。(これは,登録取引が行われた後の有限ウィンドウ期間内に行われる必要があります。)
  3. 登録 Y は,ブロック Z 内の Stratis ブロックチェーンに含めるためのピアノードへのトランザクションとしてブロードキャストされます。
  4. 登録は各ピアノードにキャッシュされます。ブロック Z の後にネットワークに参加するノードは登録 Y を受け取るためにチェーン全体をダウンロードする必要はありません。ピアとの通信(ノード間検出プロトコル)によって,検証済みの履歴登録のリストを受け取る事ができます。ライトノードは,ローカルにダウンロードされたブロックヘッダーストレージに対する登録の Merkle 証明を評価することによって,自分自身の登録を検証できます。
  5. ネットワーク上のすべてのフルノードは,いつでもアドレス X で利用可能な残高を直接評価することができます。したがって,偽のマスターノード登録がブロードキャストされている(それが起こる可能性がある)と判明された場合,フルノードはその登録を新しい同輩に転送しません。既知の無効な登録を送信しようとする同輩は,それに応じて非準拠の証明を受け取ります。
  6. 現状はマスターノード登録の有効性に影響を与える変更なしで一定期間持続します。
  7. マスターノードオペレータは,アドレス X からの資金の一部を別の場所に移します。(それらは現在担保要件以下である必要があります。)
  8. ブロックをダウンロードするすべてのノードは,X のバランスが変化したことを直ちに知ることができますが,ライトノードでは実際のバランスが分からない事があります。フルノードは,残高を知る(または計算する)ことができ,マスターノードが準拠していないことを示す証拠を構築することができます。
  9. 非準拠の証明はノード間でブロードキャストされます。これは先取り的に行うこと(すなわち,すべての既知のピアに対して直ちにブロードキャスト)ができ,ピアから無効な登録を受信したことに応答して受動的に行えます。

高いレベルでは,資金不足の証拠は以下の要素で構成されます:

  • マスターノードのための「資金調達取引」のコピー(これは資金調達取引でより詳細に定義されています。)
  • 登録レコードそのもの(ピアがまだそれをダウンロードしていないかもしれないので,全体として)
  • 1つ以上の入力として(担保資金が移動/使用されたことを示すものとして)資金取引との少なくとも1つの完全な取引が含まれています。
  • 移動取引の結果として,担保を所有するアドレスの残高が250,000 STRAT 未満でなければなりません。
  • 移動取引の Merkle 証明が,資金取引と同じかそれ以上の高さでブロックに含まれていることを示します。

ライトノードは1つ以上のマスターノードの知覚された状態についてピアノードに問い合わせる事ができなければなりません。
照会されているピアがライトノードである場合でも,すでに受信したフルノードから保存したプルーフを渡すことのみ可能です。

資金調達取引

マスターノードの資金調達取引は,指定されたアドレスに 250000 STRAT の担保を割り当てる取引です。
これには,ピア間で通信される証明のサイズを最小限に保つために,1つのトランザクション出力のみを使用することをお勧めします。

資金取引のブロック高さと登録取引のブロック高さとの間には当然のことながらいくつかの資金移動が発生している可能性があります。
フルノードがマスターノードのソルベンシーを評価し,そのノード間プロトコルを介して他のピアにその登録を伝播するかどうかを決定するので,これは問題ではないはずです。

攻撃/ DoSベクトル

ネットワークの最も脆弱な部分はライトノードです。
したがって,証明機構はライトノードがブロックチェーン全体を利用可能にすることなく,マスターノード登録のポリシングに参加するのに十分なほど堅牢である必要があります。

マスターノードオペレータは,登録を検閲して特定のマスターノードへのトラフィックを抑制しようとする不正なフルノードからも保護する必要があります。
これは Stratis ブロックチェーンの分散した性質によって緩和されます。
登録がブロックおよびノード間検出プロトコルを介してネットワークを通って浸透するので,不正なノードの影響を最小化または無効化するのに十分な数の正直なノードが参加することだけが必要です。
不正なフルノードは,Merkle 証明が検証されないため偽の証明を生成できません。

マスターノードオペレータは,クライアントノードがサーバを使用するようにするために大量の登録トランザクション(すなわちスパム)を生成する可能性があります。
これはクライアントノードが既知の各マスターノードに対して最新の有効な登録のみを保持するというルールによって緩和されるため,ネットワークをスパムしてもクライアントが特定のマスターノードサーバを選択する可能性は高くなりません。

マスターノードのオペレータは,不注意にフルノードが非準拠の証明を作成する手段を提供するように担保資金を移動させないことが重要です。
資金を移動する必要がある場合は,まったく新しいアドレスを使用し,新しい登録を行うことをお勧めします。
これにより,以前の登録が無効にされ,ネットワーク上のノードのキャッシュから削除されます。
逆に新しい登録はキャッシュされ,転送されます。

原文:Stratis Masternode Registration Protocol

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です