デリゲートハーベスティングの有効化

あなたのアカウントのインポータンスを安全にノードと共有します

紹介

デリゲートハーベスティング によってノードを運用せずにブロック報酬をアカウントで得ることができます。同時にノードはアカウントの (おそらくはより高い) インポータンススコア の恩恵を受けることができます。

アカウントの 秘密鍵 はノードと決して共有されないため、この方法は、すべてのノードは公にアクセス可能であり、攻撃を受ける可能性がある ローカルハーベスティング よりも本質的に安全です。このため、ローカルハーベスティング用のノード設定は簡単ですが、ノード所有者もデリゲートハーベスティングの使用を推奨します。

必要な手順の概要:

  1. AccountKeyLinkTransaction を使用して メインアカウント (M) のインポータンスを リモートアカウント (R) に委譲します。
  2. VrfKeyLinkTransaction を使用して、ランダム化したブロック生成とアカウント選択のために、メインアカウント MVRF アカウント (V) にリンクします。
  3. NodeKeyLinkTransaction を使用してノードを介してハーベスティングをするために、メインアカウント M をノードにリンクします。
  4. デリゲートハーベスタとしてリモートアカウント R を追加するために PersistentDelegationRequestTransaction を使用して、ノードにリクエストを行います。ノード構成にアクセスできる場合は、リモートアカウントの秘密鍵をノードの構成に設定できます。

リクエストに応じるのは完全にノード次第であることに注意してください。一部のノードは現在のデリゲートハーベスタの一覧を要求できますが、この情報が常に利用できるとは限りません。 (以下の 有効化の確認 を参照)

前提条件

デリゲートハーベスティングを有効にするには、次のアイテムが必要です:

  • メインアカウント (M)適格 となるためには、最低 10,000 symbol.xym が必要で、さらにトランザクション手数料を支払います。これはハーベスト手数料を受け取るアカウントです。その秘密鍵は常に秘密にしてください。
  • リモートアカウント (R)M とノード間でプロキシとして機能します。このアカウントは トランザクションを送受信したことがない 必要があり、デリゲートアカウントである間はトランザクションに関与できません。
  • VRF アカウント (V) はトランザクションを送受信したことがないものです。これはアカウントの選択プロセスにランダム性を追加するために使用される通常アカウントです。
  • ノードの公開 TLS キー。これはノードが TLS を介した転送のために、データを認証するためのキーであり、通常はノード所有者によって提供されます。

オプション:

  • トランザクション手数料を支払うに十分な symbol.xym を持つ アナウンサーアカウント (A)M の代わりに、このアカウントを介して最終的なデリゲートハーベスティングリクエストをアナウンスすることで、M がデリゲートハーベスティングに関与しているという事実をネットワークから隠蔽します。プライバシーを強化するためにはこのアカウントを使用してください。

必要であれば、新しいアカウントの作成ついて、 アカウントの作成 ガイドを参照してください。

注釈

bash コードスニペットは symbol-cliメインアカウント (M)デフォルト プロファイルとして設定されていることを前提としています。そうでない場合は ‑‑profile パラメタを使用してください。

ガイド

  1. M のインポータンスを R へ委譲 するための AccountKeyLinkTransaction を作成します。 M でトランザクションに署名し、ネットワークにアナウンスします。

    const accountLinkTransaction = AccountKeyLinkTransaction.create(
      Deadline.create(epochAdjustment),
      remoteAccount.publicKey,
      LinkAction.Link,
      networkType,
      UInt64.fromUint(2000000),
    );
    
    symbol-cli transaction accountkeylink \
        --linked-public-key <REMOTE_PUBLIC_KEY> \
        --action Link \
        --sync
    
  2. M を VRF キーへリンク するための VrfKeyLinkTransaction を作成します。 M でトランザクションに署名し、ネットワークにアナウンスします。

    const vrfLinkTransaction = VrfKeyLinkTransaction.create(
      Deadline.create(epochAdjustment),
      vrfAccount.publicKey,
      LinkAction.Link,
      networkType,
      UInt64.fromUint(2000000),
    ); // Absolute number
    
    symbol-cli transaction vrfkeylink \
        --linked-public-key <VRF_PUBLIC_KEY> \
        --action Link \
        --sync
    
  3. M をノードの TLS キーへリンク するための NodeKeyLinkTransaction を作成します。 M で NodeKeyLinkTransaction に署名し、ネットワークにアナウンスします。

    注釈

    ノードの公開 TLS キーは通常、ノードの所有者によって提供されます。しかし、Dual ノード (PeerAPI ノードの両方) を実行している、バージョン 2.2.0 以上の REST ゲートウェイ はその情報を REST エンドポイント node/infonodePublicKey フィールドで提供します。

    const nodeLinkTransaction = NodeKeyLinkTransaction.create(
      Deadline.create(epochAdjustment),
      nodeAccount.publicKey,
      LinkAction.Link,
      networkType,
      UInt64.fromUint(2000000),
    ); // Absolute number
    
    symbol-cli transaction nodekeylink \
        --linked-public-key <NODE_PUBLIC_TLS_KEY> \
        --action Link \
        --sync
    
  4. トランザクションが確認されたら、次のステップで R の秘密鍵をノードと共有 します。これはノードの所有者であり、ノードの構成にアクセスできるかどうかに応じて、2 つの方法があります。

    ノード所有者 の場合は、フィールドにリモートアカウントの秘密署名鍵を ハーベスティング設定harvesterSigningPrivateKey 設定するだけです。

    それ以外の場合 PersistentDelegationRequestTransaction を使用しなければなりません。秘密鍵は 暗号化メッセージ で共有されるため、ノードだけが平文を確認できます。さらに R はモザイクを保有していません。

    ハーベスティング手数料は NodeKeyLinkTransaction を介してノードとリンクを確立しているので、M へ送られます

    M (または前述の通りプライバシーのために A) PersistentDelegationRequestTransaction で署名して、ネットワークへアナウンスします。

    const persistentDelegationRequestTransaction = PersistentDelegationRequestTransaction.createPersistentDelegationRequestTransaction(
      Deadline.create(epochAdjustment),
      remoteAccount.privateKey,
      vrfAccount.privateKey,
      nodeAccount.publicKey,
      networkType,
      UInt64.fromUint(2000000),
    );
    
    # Optionally use --profile announcer
    symbol-cli transaction persistentharvestdelegation \
        --remote-private-key <REMOTE_PRIVATE_KEY> \
        --recipient-public-key <NODE_PUBLIC_TLS_KEY> \
        --vrf-private-key <VRF_PRIVATE_KEY> \
        --sync
    

注釈

上記すべてのトランザクションは、単一の アグリゲートトランザクション でまとめてアナウンスできます。

すべてが成功すると、ノードは WebSockets を使用して暗号化メッセージを受信します。ノードがデリゲートハーベスティングをする秘密鍵を復号すると、次の条件を満たす場合、ノードの所有者は デリゲートハーベスターとして R を追加 できます。

  • ノードがデリゲートハーベスティングを許可していること
  • ノードのハーベスティングスロットが有効であること (次のセクションを参照)
  • リモートアカウントは以前にトランザクションを送信も受信もしていないこと

リモート秘密鍵はノードごとに ディスクに保存されている ため、ノードが一時的に切断された場合でも、ノードがネットワークに再接続すると、永続的にデリゲートハーベスタが再確立されます。

さらに、暗号化メッセージを使用すると、ノード情報の バックアップ が作成されます。デリゲートキーを含むディスクが破損や破壊された場合でも、ノード所有者はブロックチェーンを照会してデータを取得できます。

有効化の確認

ノードを構成するのではなく PersistentDelegationRequestTransaction を介して委任をリクエストする場合、ノードがデリゲートハーベスティングを有効にしているかどうかは、 ネットワークではなく ノードに依存しています。要求に応じるか、その状態について嘘をつくかは、完全にノードによります。

したがって、アカウントがハーベスターになったかどうかを知るための 信頼できる 方法は (ブロックチェーンにリモートアカウントが署名したブロックが表示され、メインアカウントがハーベスト手数料の受け取りが始まるのを待つ以外に) ありません。

とはいえ、 Dual ノードとして構成したノード (PeerAPI ノードの両方) は現在のデリゲートハーベスタのリストを照会できます。繰り返しますが、この情報はノードから取得されるものであり、ブロックチェーンにバックアップされないので、あまり信頼しないでください。

このリストは getUnlockedAccount API エンドポイントを使用して取得できます (例として REST API or the Typescript SDK を使用) これにはノードに登録されているすべてのデリゲートハーベスタの公開鍵が含まれています。

デフォルトでは、ノードは最大 5 つのデリゲートハーベスタ (ハーベスティングスロット) を持ち、ノードが適切と判断した場合、過剰な要求に優先順位を付けることがあります。これは ハーベスティング設定maxUnlockedAccountsdelegatePrioritizationPolicy で設定できます。

最後に

  • インポータンスの高いアカウントは、ハーベスティングを実行するためにより頻繁に選択されます。デリゲートハーベスタとして、正常にノードに登録している場合でも、 インポータンススコア が十分に高くない限りは、ブロックをハーベスティングすることはありません。 (報酬も受け取りません)
  • インポータンススコアの計算は継続的に行われません 。デフォルトでは、アカウントのインポータンススコアは 180 ブロック (約 90 分) ごとに再計算されます。 ネットワークプロパティの設定 ガイドの importanceGrouping プロパティを参照してください。
  • 最後に、上記の 有効化の確認 で説明したように、 Harvesting Delegation リクエストをアナウンスしても、デリゲートハーベスタとして追加されるとは限りません。ノードは自由に要求に応じたり、そのステータスについて嘘をつく場合があります。