アカウント名:
パスワード:
昔、表に出たことがあるですよ。
なるほど。この記事が掲載された頃はまだ週に1度しか/.Jを見ていなかったので、掲載された事がある事を全然知りませんでした。 分散コンピューティングの偽造問題はSETI [hotwired.co.jp]などでも問題があったりするので、今のところチェックを厳しくする、2度計算して結果を比較するなどの方法しかなさそうです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
すらどにて。 (スコア:1)
あと分散コンピューティングについては、無理っぽいんじゃない?という話 [srad.jp]もあるです。
全てのクライアントが100%信頼できる結果を返さなきゃいけないわけで。
いや、でも工夫して、偽造が事実上できないような暗号化をすればいいのかな。。。
いちお、「分散コンピューティング」の指すものが、
Re:すらどにて。 (スコア:1)
なるほど。この記事が掲載された頃はまだ週に1度しか/.Jを見ていなかったので、掲載された事がある事を全然知りませんでした。
分散コンピューティングの偽造問題はSETI [hotwired.co.jp]などでも問題があったりするので、今のところチェックを厳しくする、2度計算して結果を比較するなどの方法しかなさそうです。
Re:すらどにて。 (スコア:1)
同じ計算を沢山のクライアントにしてもらえば信頼性は上がりますけど、絶対正しいかと言われるとうーん。
不正できないようにする方法はいくつか考えてみました。
この桁を計算してね、っていうのを送った時間とかから乱数を作り、500桁くらいのデータを100kBくらいに暗号化して送信、受信したのを照合。
500桁にしてみたのは、計算にある程度の時間がかかることで暗号化の方法をばれにくくするため、とサーバの負荷をちょっと考えて。
ただ、万が一つにも間違いがあればダメなので、そこは本当に辛いですね。
1つのデータの信頼度が0.9999999999でも、100億個のデータがあれば信頼度は1/e程度になってしまいますので。。
それと、データが集まったら結局、スパコンで10進数に直すんでしょうね(^-^;
それでもだいぶ手間が省けるには違いないですけれど。
#あ、技術を身につけたら分散で求めてみたいと思ってるです。
#そのときはもっと真剣に考えて。
#ちなみに、この記事を読んですらどに来るようになりましたです。