Getwork

提供: tezos-wiki
移動先: 案内検索

鉱夫が解決しようとするハッシング作業を取得するために使用するRPCメソッド。 ほとんどの場合、新しいgetblocktemplateマイニングプロトコルに取って代わられていますが、データフォーマットは依然として一部のマイナー構造の内部で使用されることがよくあります。

プロトコル[編集]

getworkは、HTTP転送で送信されるJSON-RPCメソッドです。 1つのオプションのパラメータを受け取ります。 これが提供されている場合、これはサーバーの作業実績要件を満たすために変更された以前の要求によって提供される「データ」でなければなりません。

引数なしのgetworkは、次の目的のための解決策を見つけるために、鉱夫のブロックヘッダを提供します。

!colspan = 4 |ネットワークジョブ
-

!キー!!必須!タイプ!!説明

- データ テンプレート:はい 文字列 16進数でエンコードされた文字列としてリトルエンディアンの順序で前処理されたSHA-2入力チャンク - ターゲット テンプレート:はい 文字列 16進数でエンコードされた文字列としての作業証明書ハッシュ・ターゲット - アルゴリズム テンプレート:いいえ 文字列 作業証明アルゴリズムの簡単な仕様。 bitcoindまたはほとんどのプールサーバーでは提供されません。

データキーは前処理されているため、汎用SHA256機能を使用する場合は、先に前処理を元に戻す必要があります。 これは2つのステップです。

  • getworkはリトルエンディアンでデータを提供し、SHA256はビッグエンディアンで動作するため、32ビットのチャンクごとにバイトオーダを交換する必要があります
  • SHA-2パディングを切断します。 Bitcoinの場合、最初の80バイトを取ることができますが、それ以外の場合は、(バイト単位の)データの最後の64ビットとして正しい長さ(ビット単位)を見つけることができます

たとえば、このデータを受け取った場合:  0071  000000008348d1339e6797e2b15e9a3f2fb7da08768e99f02727e4227e02903e  43a42b31511553101a051f3c0000000000000080000000000000000000000000  0000000000000000000000000000000000000000000000000000000080020000 最初に、各32ビットチャンクをリトルエンディアンからビッグエンディアンにbyteswapします。  020000001fba9705b223d40c25b0aba35fee549aa477307862fb45ad18020000  0071  312ba443105315513c1f051a0000000080000000000000000000000000000000  0000000000000000000000000000000000000000000000000000000000000280 次に、ビッグエンディアンの最後の64ビット(0x0000000000000280 = 640ビット= 80バイト)を読み込み、その後すべてを切り捨てます。  020000001fba9705b223d40c25b0aba35fee549aa477307862fb45ad18020000  0071  312ba443105315513c1f051a00000000 あなたが提出しなければならない結果がデータと同じフォーマットであるので、提出するときにこのプロセスを逆にしなければならないことに注意してください。

SHA256では多くの最適化が可能ですので、完全なSHA256ラウンドの実行はお勧めできません。 ほとんどの鉱夫は最初の512ビットのデータからSHA256を "中間状態"で事前計算し、最後の512ビットのチャンク(ノンスを含む)で2回目のSHA256ラウンドを繰り返すだけです。

ターゲットは標準のSHA256オーダ(ビッグエンディアン)ですが、Bitcoinのターゲット比較は256ビットのリトルエンディアンとして行われます。 これは、pdifficulty 1のために、最後の32ビットがゼロであることをチェックしたいということです。

擬似コード[編集]

(あなたがSHA256の内部を理解するまで、中天を無視してください)。

計算する:hash = SHA256(SHA256(EndianFlipForEach32Bits(First80BytesOf(data))))

それが[難しさ]を満たせば勝ちます([ブロック|ブロック]を生成するか共有する)!

そうでない場合は、608ビット(バイト76から79)で始まるデータの部分に格納されている番号であるNonceをインクリメントして、やり直してください。

インクリメントされた部分がオーバーフローした場合は、新しい作業をしてください( rollntime extension]も参照してください)。

拡張機能[編集]

新しい仕事をするとき、鉱夫はスペースで区切られたX-Mining-Extensionsヘッダーを、サポートされている拡張機能のリストとともに送信する必要があります。

ホストリスト[編集]

[Deepbitのオリジナル仕様] [https://deepbit.net/failover.php]

サーバーには、サーバーの詳細を含むオブジェクトの配列としてJSONでフォーマットされた使用可能なサーバーのリストを含むX-Host-Listヘッダーが含まれている場合があります。 "host"はサーバのホスト名またはIPアドレスを指定し、 "port"はTCPポートを指定し、 "ttr"は "return to time"を指定します。 ttrがゼロ以外のサーバを使用する場合は、この分数後に0 ttrでサーバに戻ろうとする必要があります。

例:  X-ホストリスト:[{"host": "server.tld"、 "port":8332、 "ttr":0}、{"host": "backup.tld"、 "port":8332、 "ttr ":20}]

この文字列は、 "server.tld"がメインサーバーであることを示します。 接続の問題が検出されたら、次のサーバー "backup.tld"を20分間試してから、 "server.tld"に戻ってみる必要があります。 メインサーバーがまだオフラインの場合は、引き続き "backup.tld"をさらに20分間使用する必要があります。 フェールオーバーワークフロー: #左から右にサイクリングしながら最初の稼動サーバーを選択する #サーバの「ttr」が0より大きい場合は、この分後に1)に進みます。

ロングポール[編集]

[Deepbitのオリジナル仕様] [https://deepbit.net/longpolling.php]

マイニングプールがLong Pollingをサポートしている場合は、相対URIまたは絶対URIを持つX-Long-Pollingヘッダーを含める必要があります。絶対URIは、元の接続とは異なるポートを指定することがあります。 Minerは、GETメソッドとメイン接続と同じ基本認可を使用して、ロングポーリングURIへのリクエストを開始する必要があります。この要求は、現在のブロックデータを期限切れにし、新しいデータが準備されるまで、サーバによって応答されません。答えは、メイン接続のネットワークと同じです。この回答を受け取った鉱夫は、進行中の現在の計算を破棄し、その結果を破棄し、受信したデータの処理を開始し、長いポーリングURIに対して新しい要求を行うべきです。 longpollからの応答に関係なく、新しい作業が要求される前に(通常の方法で)60秒の制限があります(ただし、これは[次の[rollntime | rollntime extensionによって上書きされます)。

真ん中[編集]

これは、鉱山会社が独自の中産階級の生成をサポートしている場合に宣伝する必要があります。この場合、プールは作業応答内の現在廃止された "中間状態"および "ハッシュ1"フィールドを省略することを決定するかもしれません。

ノンケランジュ[編集]

noncerangeディスカッションフォーラムスレッド

X-Mining-Extensionsに加えて、鉱山者はX-Mining-Hashrateを送って、1秒あたりの完全ハッシュで測定されるハッシュ値の整数値を送信する必要があります。 サーバーはJSON応答に追加フィールドを追加することができます。「noncerange」には、スキャンが許可されている開始および終了ナンスを指定する2つの32ビット整数が含まれています。 両方の値はビッグエンディアンで与えられますが、鉱夫はネイティブの32ビット整数型(SHA256は文字データではなく32ビット整数で動作します)で範囲を反復処理する必要があります。 鉱夫は毎秒の範囲内の最初のノンスから開始してロールタイムを実装する必要があります。

例:  "noncerange": "000000001fffffff" 応答:  ソリューション: "... dddddd1f ..."

拒否理由[編集]

注:クライアントは、X-Mining-Extensionsでこの機能を宣伝する必要はありません。

シェアが拒絶された場合、サーバはそれが拒否された理由を示すX-Reject-Reasonヘッダを含むことができる。 このヘッダーの値は未定義です。

ロールタイム[編集]

[1]

ネットワークレスポンスに「N」またはヌル文字列以外の値を持つ「X-Roll-NTime」ヘッダーが含まれている場合、鉱山者はノンスに加えてntimeフィールドも変更することができます。 サーバは、 "expire = <N>"の値を送ることができる。ここで、<N>は他のヘッダを受け入れることを望む秒数である。 「X-Roll-NTime」ヘッダーが作業応答に存在しない場合、同じサーバーからの以前の作業が許可されていても、その作業はロールバックされないことに注意してください。 また、共有提出のヘッダーが仕事の振る舞いに影響を与えてはならないことに注意してください。具体的には、共有提出にヘッダーがない場合は、現在の仕事(これを実行したもの)のロールタイムを無効にしてはなりません。

ネットワーク待ち時間のため、 Luke-Jrは、鉱夫にとって次のような設計を推奨しています。 #network、<ネットワーク要求の継続時間>、

階層[編集]

サーバは、そのStratumインタフェースへのURLを含むX-Stratumヘッダを含むことができる。このヘッダーが存在する場合、Stratum対応のマイナーは指定されたURLにすぐに切り替える必要があります

例:  X-Stratum:層+ tcp://example.com:3333

stratum + tcpは、TCP転送によるStratumプロトコルを示します。理論的にプールは他のトランスポートも実装することができますが、現在のところ、レイヤー・マイナーはTCPトランスポートのみを実装しています。

submitold[編集]

この機能は、longpoll要求でのみ宣言する必要があります。定期的な要求で受信された場合は、無視する必要があります。

サポートされている場合、サーバーはJSON結果に「submitold」キーを含めることができます。このキーが存在し、真である場合、鉱山者は古い作業の結果(デフォルトのlongpoll仕様)を破棄せず、その代わりにサーバーに送信してください。鉱山労働者は古い作業の作業をやめて、古い作業の結果を失うことなくできるだけ早く新しい作業に取り掛かるべきです。

スイッチト[編集]

[Deepbitのオリジナル仕様] [2]

サーバーには、 hostlist array extensionの項目と同じfashonでフォーマットされた単一のJSONオブジェクトを含むX-Switch-Toヘッダーが含まれている場合があります。 このヘッダーが存在する場合、現在の「ネットワーク」を終了して結果を送信した後、少なくともttr分間、指定されたサーバーに切り替える必要があります。

例:  X-Switch-To:{"host": "temporary.tld"、 "port":8332、 "ttr":10}

関連項目[編集]