今日は技術的な話を書こうかと思います。 以前、プールについて書いた方が良いかな?と思うメモをどこかの記事に書いたと思いますが、色々と動画を見ていると思う事もある訳ですね。 何回かに分けて書くつもりです。
結論としては ・(かなり初期にも書いたように)マイニングプールなんて気にするだけ無駄。 ・rejectなんて気にするだけ無駄。 という話になるんですが、それは人それぞれ考え方次第です。 ・そもそもNiceHashを使うのは会計処理に無駄な時間を割く気がない。 ・マイニングをするのも時間を他の事に使える放置プレイでチャリンチャリンだから。 という時間を有効活用したい人はワイと同じ結論になるんじゃないかと思います。
Stratumとは何ぞや?
マイナーからNiceHash指定する時にプロトコルはstratumを指定してますよね? そもそもNiceHashってハッシュ売買って言ってるのに何でNiceHashのプールを指定するんだ?って疑問に思いませんか?
GitHub - Atrides/eth-proxy: Stratum proxy for Ethereum
Stratum proxy for Ethereum. Contribute to Atrides/eth-proxy development by creating an account on GitHub.
上のgithubにstratum proxyの図が書いてありますが、要はイーサリアムマイニング用のプロキシーです。 日本から一番近いUSA-WESTのプロキシーに接続したとして、ハッシュパワーを買った人がカリフォルニア(usa-west)から遠いどこにします?中国の深センにマイニングプールある事にしときます? 日本→カリフォルニア→深センという通信をする訳ですよ。そらNiceHash使わずに直接マイニングプール指定で掘るよりも、通信経路が1段階増える分リジェクト出る可能性が多いのは仕組み上当たり前! っていう話ですよね? リジェクトを減らしたいというのを重要視するならNiceHashは使わない方が良いです。
Accepted Speedについて
増えてるタイミングと減ってるタイミングがあるのが分からんという話をよく見ますが、ハッシュレートと同じです。 クライアント側でShare #999 acceptedが大量に出てるタイミングだと上がって、ちょっと間隔が空いたタイミングだと下がるだけです。 (この集計タイミング=期間がグレーなのでよく分からんのはその通りだと思います) リジェクトが無ければ24時間もあればアベレージ(AVG.ACC.SPEED)はハッシュレートと近い数字に落ち着いているハズです。
Hashing speed, accepted, rejected speed and shares
NiceHash is the leading cryptocurrency platform for mining. Sell or buy computing power and support the digital ledger t...
staleって何ぞや?
みんな大好き、オープンソースでソースコードを公開してくれているethminerで見てみますね。
ethminer/libpoolprotocols/stratum/EthStratumClient.cpp at master · ethereum-mining/ethminer
Ethereum miner with OpenCL, CUDA and stratum support - ethereum-mining/ethminer
// In EthereumStratum/2.0.0 we can evaluate the severity of the
// error. An 2xx error means the solution have been accepted but is
// likely stale
bool isStale = false;
if (!_isSuccess)
{
string errCode = responseObject["error"].get("code","").asString();
if (errCode.substr(0, 1) == "2")
_isSuccess = isStale = true;
}
エラーコードの2xx(200番台)だとstale扱いって書いてるけど、20番台もじゃね? 頭1文字目で判定してるだけですからね。 ここら辺はプロトコルとして共通定義されているハズなので、そういうもんだと思って良いハズです。 よく分からんという事でプロトコル定義をググるとEIP-1571が出てきます。
EIP-1571: EthereumStratum/2.0.0
プロトコルを見ると2XXがstaleの実装で合ってます。
Error codes 2xx : request accepted and processed but some additional info in the Error codes 2xx : request accepted and processed but some additional info in the error member may give hint
要は2xxは通信エラーじゃなくて処理は受け付けたけど起こってるエラーですね。 エラーコードだけじゃ分からんから一緒に送られてくるメッセージを見ないと何のエラーか分からんけど、このエラーを見る術がないから調べようもないと。 ただNiceHashの場合は2xxの中のduplicateは外だしで扱ってるみたいなので、staleは本当にstaleだけを扱っているんじゃないですかね?Otherなんてのもあるし
Example 2 : a client submits a solution and server accepts it but it accounts the share as stale. Server MUST respond like this
{
"id": 31,
"error": {
"code": 202,
"message" : "Stale"
}
}
本当のstaleというのはこう書いてる部分ですね。 まぁshare受け取ったけど時すでにお寿司という扱いという解釈で良いんじゃないかと? なのでNiceHashを経由して日本→カリフォルニア→深センなんて世界中を駆け巡る通信をするとstaleが起こる確率は高くて当たり前っちゅー話ですわ。
話が脱線してstaleの説明に注力してしまったので今日はここまで! そう言えば昨日こんな動画も見ました。
たまにこういう煩いだけの短い動画あげてくれる日本人の人いますけど、面白いからどんどん上げて欲しいですね! ワシントンのエグい方を見せて欲しいですねw
コメント