アカウント名:
パスワード:
distributed.net [distributed.net]の場合、sourceを公開すると(悪意の有無に関わらず)現実にはあり得ない結果をserverへ返す恐れがあるとしてsourceの公開に消極的だったと記憶しています。BOINCでは返ってきた結果が正しいことをどうやって検証するのでしょうか?
a cheat-resistant accounting systemをつけるとは書いてあるけど、client側のbugにも効くのかな?
BOINCでは返ってきた結果が正しいことをどうやって検証するのでしょうか?
検算。
一方SETIの場合、
という事で、同じ「分散解析プロジェクト」であっても対象としているデータの性格が違うので、一概に比較はできないのではないでしょうか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
結果をまとめる際のsanity check (スコア:3, 興味深い)
distributed.net [distributed.net]の場合、sourceを公開すると(悪意の有無に関わらず)現実にはあり得ない結果をserverへ返す恐れがあるとしてsourceの公開に消極的だったと記憶しています。BOINCでは返ってきた結果が正しいことをどうやって検証するのでしょうか?
a cheat-resistant accounting systemをつけるとは書いてあるけど、client側のbugにも効くのかな?
Re:結果をまとめる際のsanity check (スコア:2, おもしろおかしい)
検算。
Re:結果をまとめる際のsanity check (スコア:2, 参考になる)
また、「見つからなかった」と虚偽申告されたブロックに正解があれば、全ブロックの検査が終わっても見つからないという状況が発生してしまいます。
RC5-Crackでは
一方SETIの場合、
また、SETIの場合参加者のClientでは「可能性のありそうな」データか、「ただのノイズか」を識別しているだけで、実際のデータの検証は再度行われるので、「見つかった」という虚偽の申告があっても単にS/N比が悪くなるだけです。(ま、それはそれで問題だけど)
逆に「見つからなかった」という虚偽申告も有り得ますが、その場合は単に発見が遅れるだけで、そこに有意な電波発信源があれば遅かれ早かれ見つかるでしょう。
という事で、同じ「分散解析プロジェクト」であっても対象としているデータの性格が違うので、一概に比較はできないのではないでしょうか?
Re:結果をまとめる際のsanity check (スコア:1)
Re:結果をまとめる際のsanity check (スコア:1)
以下、解釈に間違いがあるかもしれませんが。
まず、結果の確かさの検証ですが、基本的には検算によるようです。
同一のW.U.に対して他人が返した結果と比較する、というものですね。
これとは別に"a cheat-resistant accounting system"があります。
各アカウントには(CPU time) * (int + fp + mem)のcreditが与えられます。
"正しい結果"と判定されるには、ある閾値以上のcreditを持っている必要があります。
もちろん、正しくない結果を返した場合は減点されることもあるでしょう。
これによって、虚偽の結果を返してW.U数を稼ぐことにより上位入りしようとする行為は無駄になりそうです。
クライアント側のバグに関しては、特に何も書いていませんでした。
ですが、虚偽の結果を返していると判定されるような気がします。
ただ、プロジェクトとしては枯れているバージョンを推奨するでしょうし。
{自分でhackした|自分で選んだ}バージョンでスコアが上がらないとしても、それは"at your own risk"でというものなんじゃないかなぁ、と思います。
#どなたか識者の方の訂正を希望。