デリゲートハーベスティングを手動で有効化

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

紹介

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

注釈

ノード所有者はノードの設定にアクセスできるため、 リモートハーベスティング を利用する方が便利です。

SDK または CLI を使用した、 開発者向け に 手動で デリゲートハーベスティングを有効にする方法をガイドします。一般ユーザは デスクトップウォレット を使用してください。

概要

必要なステップ:

  1. AccountKeyLinkTransaction を使用して メインアカウント (M) のインポータンスを リモートアカウント (R) に委譲します。

  2. VrfKeyLinkTransaction を使用して、ランダム化したブロック生成とアカウント選択のために、メインアカウント M を VRF アカウント (V) にリンクします。

  3. NodeKeyLinkTransaction を使用してノードを介してハーベスティングをするために、メインアカウント M をノードにリンクします。

  4. ハーベスタとしてリモートアカウント R を追加するために Persistent Delegation Request Transaction を使用して、ノードにリクエストを行います。ノード構成にアクセスできる場合は、リモートアカウントの秘密鍵をノードの構成に設定できます。

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

前提条件

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

  • メインアカウント (M) が 適格 となるためには、 10,000 symbol.xym 以上と支払うトランザクション手数料が必要です。アカウントには 0 より大きい インポ―タンススコア (このスコアは 12 時間ごとに計算されます) が必要です。これはハーベスト手数料を受け取るアカウントです。その秘密鍵は常に秘匿してください。

  • リモートアカウント (R) は M とノード間でプロキシとして機能します。このアカウントは トランザクションを送受信したことがない 必要があり、デリゲートアカウントである間はトランザクションに関与できません。

  • VRF アカウント (V) はトランザクションを送受信したことがないものです。これはアカウントの選択プロセスにランダム性を追加するために使用される通常アカウントです。

  • ノードの公開 TLS キー。これはノードが TLS を介した転送のために、データを認証するためのキーであり、通常はノード所有者によって提供されます。

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

注釈

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

ガイド

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

    View Code
    const accountLinkTransaction = AccountKeyLinkTransaction.create(
  Deadline.create(epochAdjustment),
  remoteAccount.publicKey,
  LinkAction.Link,
  networkType,
  UInt64.fromUint(2000000),
);
    View Code
    symbol-cli transaction accountkeylink \
    --linked-public-key <REMOTE_PUBLIC_KEY> \
    --action Link \
    --sync

  2. M を VRF キーへリンク するための VrfKeyLinkTransaction を作成します。 M でトランザクションに署名し、ネットワークにアナウンスします。

    View Code
    const vrfLinkTransaction = VrfKeyLinkTransaction.create(
  Deadline.create(epochAdjustment),
  vrfAccount.publicKey,
  LinkAction.Link,
  networkType,
  UInt64.fromUint(2000000),
); // Absolute number
    View Code
    symbol-cli transaction vrfkeylink \
    --linked-public-key <VRF_PUBLIC_KEY> \
    --action Link \
    --sync

  3. M をノードの TLS キーへリンク するための NodeKeyLinkTransaction を作成します。 M で NodeKeyLinkTransaction に署名し、ネットワークにアナウンスします。

    注釈

    The node's public TLS key is typically provided by the node owner. However, Dual nodes (being both Peer and API nodes) running a version of the REST Gateway higher than 2.2.0 offer this information through the nodePublicKey field of the node/info REST endpoint.

    ブラウザで NODE_URL /node/info を開きます。

    View Code
    const nodeLinkTransaction = NodeKeyLinkTransaction.create(
  Deadline.create(epochAdjustment),
  nodeAccount.publicKey,
  LinkAction.Link,
  networkType,
  UInt64.fromUint(2000000),
); // Absolute number
    View Code
    symbol-cli transaction nodekeylink \
    --linked-public-key <NODE_PUBLIC_TLS_KEY> \
    --action Link \
    --sync

  4. トランザクションが確認されたら、次のステップで R の秘密鍵をノードと共有 します。これはノードの所有者であり、ノードの構成にアクセスできるかどうかに応じて、2 つの方法があります。

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

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

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

    M で Persistent Delegation Request Transaction に署名して、ネットワークへアナウンスします。

    View Code
    const persistentDelegationRequestTransaction = PersistentDelegationRequestTransaction.createPersistentDelegationRequestTransaction(
  Deadline.create(epochAdjustment),
  remoteAccount.privateKey,
  vrfAccount.privateKey,
  nodeAccount.publicKey,
  networkType,
  UInt64.fromUint(2000000),
);
    View Code
    # 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 を追加 できます。

  • ノードがデリゲートハーベスティングを許可していること

  • ノードのハーベスティングスロットが有効であること (次のセクションを参照)

  • リモートアカウントは以前にトランザクションを送信も受信もしていないこと

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

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

有効化の確認

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

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

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

You can retrieve this list using the getUnlockedAccount API endpoint (point your browser to NODE_URL /node/unlockedaccount) or the Typescript SDK for example). It contains the public keys of all registered delegated harvesters in the node, so your remote account (R) public key should appear here.

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

最後に

  • インポータンスの高いアカウントは、ハーベスティングを実行するためにより頻繁に選択されます。デリゲートハーベスタとして、正常にノードに登録している場合でも、 インポータンススコア が十分に高くない限りは、ブロックをハーベスティングすることはありません。 (報酬も受け取りません)

  • インポータンススコアの計算は継続的に行われません。デフォルトでは、アカウントインポータンススコアは、1440 ブロックごと (約 12 時間ごと) に再計算されます。 ネットワークプロパティの設定 ガイドの importanceGrouping プロパティを参照してください。

  • 最後に、上記の 有効化の確認 で説明したように、 Harvesting Delegation リクエストをアナウンスしても、デリゲートハーベスタとして追加されるとは限りません。ノードは自由に要求に応じたり、そのステータスについて嘘をつく場合があります。