レイテンシーと局所性
Bitcoinユーザーの皆さんこんにちは
昨日Bitcoinを発見し、デジタルキャッシュシステムにおいて発行者/銀行を不要にするというアイデアに本当に感銘を受けた。
しかし、一つ異議がありみなさんの見解を聞きたい。
それはローカルなトランザクションにおけるレイテンシー、つまり遅延だ。例えば、支払い者と受取人が同じ都市にいるとしよう。ネットワーク接続のレイテンシーとほとんど変わらない遅延で支払いが完了することを望むだろうと主張したい。発行者を使い、ローカルコイン（例えばサーバーをローカライズするための接頭辞）を使えば、トランザクションは100マイクロ秒以内に完了・検証されるはずだ。グローバルなP2Pネットワークでは、すべてのノードがトランザクションを受信し、計算を行い、結果を送り返す必要がある。 光速を上限とすると、これを1秒未満で行うことは実現不可能だ。私の理解では、実際には1ブロックに約10分、あるいは複数ブロックの検証にはさらに長い時間を使っている。これは、二重支払いの不在の検証が10,000倍、あるいは数千万倍遅すぎることを意味する。惑星間取引ではさらに悪化するだろう。
理想的な決済システムは分散型であるべきだが、同時に局所的であるべきだ。つまり、ローカルなトランザクションの検証が、光信号が「宇宙」の反対側まで往復するのを待つ必要があってはならない。
ここで述べた意味での局所性は極めて重要だと主張したい。
敬具
Morten Krogh.
そう、それが私の要件だし、他の多くの人にとってもそうなるはずだ。二重支払いに対する保証なしに販売する企業はほぼ皆無だろう。
この話は知ってた？ ブロックに取り込まれるのを待たずとも、PayPalや小切手よりはるかに高い確実性を得ることができる。
サトシ・ナカモトの投稿（2010年7月17日22:29 UTC）決済処理会社がサービスとして、10秒以内程度の十分な検証を行いつつ、トランザクションの迅速な配信を提供することが可能になると考えている。
ネットワークノードは、生成しようとしているブロックに取り込むために、受信したトランザクションの最初のバージョンのみを受け入れる。トランザクションをブロードキャストした時、他の誰かが同時に二重支払いをブロードキャストした場合、最も多くのノードに最初に伝播させる競争になる。一方がわずかに先行していれば、ネットワーク全体に幾何級数的に速く広がり、ほとんどのノードを獲得する。
大まかな概算の例: 1 0 4 1 16 4 64 16 80% 20%
したがって、二重支払いがたった1秒でも待たなければならない場合、非常に不利になる。
決済処理業者は多くのノードと接続を持っている。トランザクションを受信すると、それを一斉に送り出し、同時にネットワーク上の二重支払いを監視する。多数のリスニングノードのいずれかで二重支払いを受信した場合、そのトランザクションが不正であることを警告する。二重支払いのトランザクションは、リスナーの1つに検出されずに遠くまで伝播することはないだろう。二重支払い者はリスニングフェーズが終わるまで待たなければならないが、その頃には決済処理業者のブロードキャストがほとんどのノードに到達しているか、伝播において非常に先行しているため、二重支払い者は残りのノードの大部分を獲得する見込みがない。
creighto、私は二重支払いがないことの検証についてだけ話している。もちろん、コインを受け取ってただ期待することはいつでもできる。それは明らかだ。
物理的なコインにはこの問題はないと思う。金にも。まず偽造は非常に困難であり、次に「紙幣検証機や金検証機」はローカルマシンだ。ローカルマシンでは検出できない方法で金やコインを偽造できる人がいたら、同じ問題になるだろう。だが誰もそんなことはできない。
私が見たバージョンのBitcoin（Redのものではない）では、それを検証するローカルマシンを作ることができない。Redが正確に何を提案しているのか理解できていない。
NewLibertyStandard、あなたの提案は銀行であり、支払者と受取者がそこに口座を持つ必要がある。それは構わないが、このスレッドの問題への答えにはならないと思う。
理想的な解決策として私が考えるものには以下の特性がある。
- コンピューター/スマートフォンにソフトウェアがあるだけで参加できる。
- コインは自分で保管する。コインは文字列であり、物理的な金などは関係しない。暗号鍵は自分で生成できるならそれで良い。
- 銀行や政府への口座登録は不要。
- 支払いは二重支払いチェックを含めて完全に検証できる。極めて小さな確率は無視できる。ただし、極めて小さいというのは、単にそこそこ小さいというのではない。
- ある人が都市に旅行する場合、コインを交換して訪問の準備ができる。この交換は遅くてもよい。都市に到着した後、その都市に住む人に高速な支払いができる。高速な支払いとは、コインシステム全体のサイズに依存しない時間枠で完全に検証される支払いを意味する。つまり、デジタルキャッシュシステムが世界中（または銀河中）で使われていても、ローカル取引が可能であるべきだ。到着前の準備がここでは重要だ。もちろん多くのコインは受取者によって高速に二重支払い検証できないが、場所が与えられれば検証できるコインが存在すべきであり、支払者はそのようなコインを入手して到着前に準備できる。
- システムがその誠実さに頼る発行者がいない。
1-5は発行者がいれば可能だ。コインには二重支払いがどこで検証されるかを示すタグがある。発行者はその場所のサーバーにそれらのコインに関する情報を保持する。つまり、発行者の分散ハッシュテーブルは、どのコインがどこに保存されるかについてのルールに従い、そのルールは公開されている。
1,2,3,4,6は私の理解が正しければBitcoinだ。
1-6は存在するのか。それがRedの言っていることなのかな？
creighto、私は二重支払いがないことの検証についてだけ話している。もちろん、コインを受け取ってただ期待することはいつでもできる。それは明らかだ。
ただ期待する以上のことがある。まず、既存のビジネス関係があり、誠実な過去の取引によって二者間に信頼が構築されている場合がある。
Bitcoinの偽造も非常に難しく、ローカルのブロックチェーンチェックはまさにそれに対する防御だ。同時ではない二重支払いに対しても保護される。例えば、ある人がウォレットファイルをバックアップしてから前の晩にコインを使い、あなたを騙そうとするような場合だ。プロの犯罪者からは守れないが、軽い試みには対処できる。
[/quote] 私が見たバージョンのBitcoin（Redのものではない）では、それを検証するローカルマシンを構築することはできない。 [/quote]
他のスレッドから、Redは私とはシステムの仕組みについて異なる理解を持っていることを知っている。どちらか、あるいは両方が間違っている可能性がある。私の理解では、現時点でクライアントは送金のアナウンスを試み、その後、集合体がその主張を少なくとも2つのブロックで有効として受け入れることで送金を確認するのを待つ。その時点でネットワークはあなたが有効なBitcoinを持っていると信じ、したがってあなたは持っていることになる。
しかし、理論上は2つのクライアントが直接やり取りできる。
こんな状況を想像してほしい…
iPhoneでフルクライアントがバックグラウンドで動作していて、停電が起きたとする。近所の店に行くと、店主が冷蔵庫のすべてを半額にしている。現金かBitcoinのみだ。携帯電話のクライアントがアドホックBluetoothを介して店主の携帯電話クライアントと接続する。送金アナウンス（ウォレットに実際の暗号コインがあるわけではなく、ブロックチェーンと呼ばれる暗号化された台帳への一連のエントリとしてのみ存在する。実際のコインというよりは小切手を書くようなものだ）に署名し、店主のアドレスに送る。店主のクライアントは、最後のブロックチェーン更新時点であなたが実際にそのBitcoinを所有していたかを自分のブロックチェーンのコピーで確認できる（しなくてもよい）。ローカルで問題なければ、あなたが騙そうとしていないと仮定して取引を受け入れ、あなたは半額の牛乳を持って帰る。これは意図的な二重支払いから店主を守るものではないが、これを行うにはある時点でコインを正当に所有していなければならない。停電時にコインを所有していなかった場合、店主のクライアントは送金を拒否する。
これはまた、店主が支出できるBitcoinは停電時に持っていたものに限られることも意味する。受け取った新しいBitcoinはまだ他のどの業者のブロックチェーンにも含まれておらず、未アナウンスのコインを送金しようとしても他のクライアントに拒否されるからだ。すべての送金は、ネットワーク再接続後30分以内に検証または拒否される。
私が提案しているものはまだ存在しない。ブロック生成の熱力学的な非合理性について、類似の問題に関する議論はあった。中央ノードが1つだけなら、システムは一瞬でトランザクションブロックを生成できる。望めば10分に1回だけ行うこともできる。だが、単一プロセッサー上の一瞬のCPU時間以上は必要ない。
その理由は純粋にコンセンサスに関係している。
つまり、2つのノードがあれば、両方にすべてのトランザクションを冗長に取得させ、それぞれが一瞬でブロックを生成できる。その後ブロックハッシュを交換し、一致すればコンセンサスが得られる。一致しなければ、2つの方法でコンセンサスに到達できる。1）各ブロックのトランザクションを1つずつ比較し、すべてのトランザクションの和集合からなるブロックを作成する。または2）ブロックの1つを選んでそのまま採用する。2番目がBitcoinが実際に現在行っていることだ。
世界で最も高価なコイン投げを使って選んでいるだけだ。もっと安いコイン投げでまったく同じことを達成でき、Bitcoinには何一つ変化がない。
これが「設計上の選択」と言っているものだ――システムの機能や動作の要件は何も変わらない。実装方法が異なるだけだ。
つまり、トランザクショングラフを分散ハッシュテーブル全体に分散させるという話は、Bitcoinの主要機能を実装する別の可能な（だが現時点ではコード化されていない）方法にすぎない。その機能とは、あるアドレスから別のアドレスへのBitcoinの送金を、二重支払いが不可能な形で検証することだ。
最適には、毎分x,000トランザクションがあり100ノードがある場合、各ノードはx,000トランザクションを処理する単一ノードの1/100の仕事だけで済む。各トランザクションは1回だけ記録されればよい。
しかし、現在のBitcoin実装では、100ノードがあると、x,000トランザクションに対してすべてが100%のCPU使用率で動作する。さらに100ノードを追加しても、すべてが100%のCPU使用率のままで、まったく同じ仕事をする。5人でできる仕事に50人を使うとき、我々はそれを「お役所仕事」と呼んでいた。人が多く働く方が経済に良いからだ！
そこで私が提案する新しい設計上の制約は、与えられたノード数(n)に対して、一定数のトランザクションを処理するのにCPUあたり(Order (1/n))、あるいはおそらく(Order log(n))の仕事量で済むべきだということだ。ここでの仕事とはCPU時間とネットワーク通信を意味する。私の設計変更は、既存システムのトランザクション保護のいずれかを放棄する場合には失敗となる。
実はブロックリスト自体はトランザクションの検証に必要ない。トランザクションだけが必要だ。したがって、私の提案を理解するには、システムの履歴のすべてのトランザクションを含む一枚岩のブロックリストがない同等のBitcoin実装を考える必要がある。
代わりに、トランザクションはすべてのノードに冗長に分散される。どのノードもすべてのトランザクションの完全なリストを保持する必要はないが、要求に応じて任意のトランザクションを迅速に取得できなければならない。最適にはOrder(1)時間で、だがOrder(log(n))時間でおそらく十分だろう。これにより、任意のノードのストレージ要件がOrder(1/n)に削減される。
トランザクションはトランザクションのout-pointによってノードにマッピングされる。トランザクション+out-point情報をハッシュすることで、2つの一意なout-point識別子を生成する。そして各out-point IDに最も「近い」5つのノードにトランザクションを冗長に保存する。つまり10,000ノードのシステムでは、各トランザクションは10,000倍の冗長性ではなく10倍の冗長性で保存される（10倍は任意の選択であり、冗長性はDHTアルゴリズムとノード集団の特性に基づく）。
これらの10ノードのそれぞれは、そのout-pointデータを完全にプライベートに保持する。ただし、別のノードが「知る必要性」を示せる場合を除く。この場合、知る必要性は、与えられたout-pointをin-pointとして含む署名されたトランザクションを提出することで示される。この場合、ストレージノードは新しいトランザクションを保存する。また、そのout-pointを参照する既知のトランザクションを返す。そのout-pointに関連する以前のトランザクションのin-pointがあれば、2番目のトランザクションは二重支払いである。
つまり、新しいトランザクションを検証するには、そのトランザクションの各in-pointに最も近い5つのノードに送信する。それらはトランザクションを記録し、二重支払いを検出したかどうかを即座に通知する。もし検出されていれば、それは不正なトランザクションであり、他の近くのノードにブロードキャストされる。
さて、私が提案しているものはプライバシーも向上させる。すべてのトランザクションを世界中にブロードキャストする必要がなくなるからだ。また、見知らぬ人があなたの取引を覗き見ることもできなくなる。
BitcoinトランザクションをDHTにマッピングする方法は多数ある。説明しやすい例を選んだだけだ。改善を提供する他の可能性もあるかもしれない。だが、要点を伝えるにはこれで十分だ。
「ダイニング暗号者ネットワーク」と呼ばれる面白い技術もあり、Bitcoinのプライバシー面をさらに改善できる可能性がある。
つまり、新しいトランザクションを検証するには、そのトランザクションの各in-pointに最も近い5つのノードに送信する。それらはトランザクションを記録し、二重支払いを検出したかどうかを即座に通知する。もし検出されていれば、それは不正なトランザクションであり、他の近くのノードにブロードキャストされる。
どちらのトランザクションが先だったかについて意見が分かれたらどうなるのか？ 多数決か？ 誰が多数派を決定するのか、そして5つのノードのうち4つがネットワークを離れ、別の5つのノードに置き換わった場合、結果は変わりうるのか？
また、大きなトランザクションを作成しようとしていることが分かっている場合、そのトランザクション（まだ送信していない）が自分の支配下にあるノードにハッシュされるよう、ノードIDを事前に計算しておくことはできるだろうか？ トランザクションを保存するすべてのノードを支配していれば、「はい、間違いなく、そのトランザクションは有効で二重支払いはありません」と回答するだけで済む……
Bitcoinの背後にある素晴らしい洞察は、分散型タイムスタンプの仕組みだ。全員がトランザクションの順序に合意する。あなたの方式がその問題をどう解決するのか、私には分からない。
こんな場面を想像してほしい……
iPhoneでフルクライアントがバックグラウンドで動作していて、停電が起きたとする。近所の店に行くと、店主が冷蔵庫のすべてを半額にしている。現金かBitcoinのみだ。携帯電話のクライアントがアドホックBluetoothを介して店主の携帯電話クライアントと接続する。送金アナウンス（ウォレットに実際の暗号コインがあるわけではなく、ブロックチェーンと呼ばれる暗号化された台帳への一連のエントリとしてのみ存在する。実際のコインというよりは小切手を書くようなものだ）に署名し、店主のアドレスに送る。店主のクライアントは、最後のブロックチェーン更新時点であなたが実際にそのBitcoinを所有していたかを自分のブロックチェーンのコピーで確認できる（しなくてもよい）。ローカルで問題なければ、あなたが騙そうとしていないと仮定して取引を受け入れ、あなたは半額の牛乳を持って帰る。これは意図的な二重支払いから店主を守るものではないが、これを行うにはある時点でコインを正当に所有していなければならない。停電時にコインを所有していなかった場合、店主のクライアントは送金を拒否する。
ここでもう一つ指摘したかったことがある。
上記の例と同様に、ほとんどの現金取引は実際には匿名ではなく、擬似匿名だ。例えば、一方の当事者は確立された存在（店主）で、もう一方はほぼ匿名（上記のお買い得品ハンター）だが、買い手でさえ真に匿名ではない。以前から何度もその店に来ており、店主が名前を知らなくても、顔を見覚えるほど見ている。だから、地元客や常連だからという信頼があり、機会主義的な詐欺を仕掛けるプロではないだろうと考える。
擬似匿名取引のもう一つの例は、両当事者が世界に対しては匿名だが、お互いにはそうでないタイプだ。これは現実世界のほとんどの現金取引の仕組みだ。しかしオンラインではこうなるだろう…
何か、変わったものが欲しいとする。Tor上で隠しウェブサイトを運営し、欲しい商品を売っている人物を見つける。ウェブサイト上では「pothead420」としてしか知らない。連絡手段は他になく、実際に誰なのか知る術もない。この人物を信頼していないが、誰かが思い切って信じなければならず、それはおそらくあなただ。だからまず少量を注文する。数回の取引が成功すると、「pothead420」が正直な売り手だという信頼が高まり、注文量が増える。相手はいつでもあなたを裏切れるが、そうすれば常連客を失うことになるので、きちんと対応し続けるインセンティブがある。
3つ目の擬似匿名信頼関係は、まさにこのフォーラムで見られる評判に依存するものだ。ほとんどの人は本名を使っていないが、使っている人もいる。Bitcoinプログラマーの名前を使っているメンバーが実際のプログラマーだと推定し、それを裏付ける証拠もあるが、確実にはわからない。しかし、このフォーラムに関する限り、彼には評判がある。だから直接取引をして裏切れば、あなたが信頼できないという彼の言葉は、どんな新参者よりも長い評判を持つ彼だけの理由で、将来のビジネスに悪影響を与える。
これらの例はすべて何らかの二者間信頼を含んでいるが、両者が第三者を信頼することを必要とするものは一つもない。ブロックチェーンの検証でさえも。
これらの例はすべて何らかの二者間信頼を含んでいるが、両者が第三者を信頼することを必要とするものは一つもない。ブロックチェーンの検証でさえも。
信頼できない相手と取引する際、信頼できる第三者は非常に有用だ。一方が取引管理者を信頼してBitcoinを預け、もう一方がLiberty ReserveやPecunixのような決済プロセッサーを信頼して支払い証明を取引管理者に提供し、管理者が支払い証明を受け入れることを信頼する。両方のトレーダーが取引サイトと決済プロセッサー、つまり両方の第三者を信頼する必要があるが、お互いを信頼する必要はない。
このアイデアを頭ごなしに否定する理由を探せば、見つかるだろう。しかし、なぜ一部のP2Pシステムは成功し、多くは失敗するのかを理解するためにこの例を使えば、何かしらの洞察が得られるはずだ。
その精神で、質問に直接答えよう。
ギャビン・アンドレセンの投稿（2010年8月6日23:32 UTC）どちらのトランザクションが先だったかについて意見が分かれたらどうなるのか？ 多数決か？ 誰が多数派を決定するのか、そして5つのノードのうち4つがネットワークを離れ、別の5つのノードに置き換わった場合、結果は変わりうるのか？
そのout-pointを使う他のトランザクションが1つでも見つかれば二重支払いだ。現在のBitcoinシステムと同じルールだ。意見の不一致が起こり得るのは、競合するトランザクションが同時にブロードキャストされ、一方がノードAに先に到着し、競合する方がノードEに先に到着した場合だけだ。2つの5ノードブロードキャストが完了するまでに、双方が二重支払いを発見する。
ではどちらが有効か？ どちらでもいい。コインを投げればいい。Bitcoinはこの状況でまさにそうしている。自分のノードがあるトランザクションを含むブロックに取り組んでいて、あなたのノードが競合するトランザクションを含むブロックに取り組んでいる場合、先にブロックを解いた方が勝つ。分散コイン投げアルゴリズムは自明だ。これらすべてはほぼ即座に実行できる。10分間のウィンドウよりはるかに速い。だから4ノードが離脱しても多数派は変わらない。合意はすでに達成され、ノードは整合性が取れた状態になっているからだ。
ちなみに、標準的なDHTはノードが離脱した時のデータ保持と、ノードが参加した時のデータ分散にすでに対応している。
ギャビン・アンドレセンまた、大きなトランザクションを作成しようとしていることが分かっている場合、そのトランザクション（まだ送信していない）が自分の支配下にあるノードにハッシュされるよう、ノードIDを事前に計算しておくことはできるだろうか？ トランザクションを保存するすべてのノードを支配していれば、「はい、間違いなく、そのトランザクションは有効で二重支払いはありません」と回答するだけで済む……
いや、これは要件上の制約だ。同じBitcoinアドレスに一致する公開鍵を2つ生成するのが不可能なのと同じ理由で、可能だ。以前の私の失言を参照してほしい。
ノードはBitcoinアドレスと全く同じように秘密鍵に基づいてノードアドレスを生成する。これによりノードのなりすましは非現実的になる。out-pointハッシュへのすべての入力は受取人を除いて固定されており、受取人は事前に指定されている。唯一の柔軟性は支払い額だろう。すべての可能な金額を反復して同時に5方向のハッシュ衝突を作ろうとするなら、どうぞ好きにしてくれ。
ギャビン・アンドレセンBitcoinの背後にある素晴らしい洞察は、分散型タイムスタンプの仕組みだ。全員がトランザクションの順序に合意する。あなたの方式がその問題をどう解決するのか、私には分からない。
実は全く同じ方法で問題を解決する。ただCPUパワーがはるかに少なくて済む。
Bitcoinの分散タイムスタンプメカニズムの背後にある素晴らしい洞察は、絶対的なタイムスタンプは全く必要ないということだ！ 必要なのは相対的な順序だけだ。短いウィンドウ内での競合については、気にする必要すらない。単に任意に1つを選べばいい。
私の解決策はまさに同じことをする。トランザクション間の相対的な順序を維持する。競合については任意に合意に達する。どちらの方法も、無関係なトランザクションを時間順に正確に並べる必要はない。繰り返すが、あれは素晴らしい洞察だった。
ではどちらが有効か？ どちらでもいい。コインを投げればいい。Bitcoinはこの状況でまさにそうしている。自分のノードがあるトランザクションを含むブロックに取り組んでいて、あなたのノードが競合するトランザクションを含むブロックに取り組んでいる場合、先にブロックを解いた方が勝つ。
ここでまた混乱した。あなたのスキームにはブロックはなく、トランザクションだけだと思っていた。先に「ブロック」を解くとはどういう意味か？
しかし、標準的なDHTは通常MP3や映画のチャンクを保存するために使われ、各ピースのハッシュを持つトレントファイルによってインデックスされる。だから、特定のDHTノードから不正なデータを受け取っているかどうかを簡単に判別できる。信頼する必要はない。
😕？ ネットワークに10,000ノードがあるとしよう。二重支払いしたいトランザクションに最も近いネットワークノードを見つけるためにクエリを行う。
そこで秘密鍵を生成する。現在最も近いノードよりも近くなる確率は約1/10,000だ。だから近い鍵を5つ見つけるまで秘密鍵を生成し続ける。確率を今から計算する余裕はないが、100,000の秘密鍵を生成すれば、5つ見つかる可能性はかなり高い。私のしょぼいラップトップでも最低でも毎秒100のECC鍵を生成できるので、20分もあれば100,000を生成できる。
それらの鍵で5つのノードを作成し（ネットワークの残りに「みなさん、正直なところ、これらの鍵は本当にランダムに選んだんだ…」と言いながら）、勝利だ。
特定のハッシュを持つトランザクションを生成しようとしているのではなく、現在ネットワーク上の他のどのノードよりもそのトランザクションのハッシュに「近い」ノードIDを生成しようとしている。それはずっと簡単だ。
MoonShadowの投稿（2010年8月6日23:42 UTC）これらの例はすべて何らかの二者間信頼を含んでいるが、両者が第三者を信頼することを必要とするものは一つもない。ブロックチェーンの検証でさえも。
信頼できる第三者は、信頼できない相手と取引する際に非常に有用だ。
はい、ただ私が指摘していたのは、通貨の一般的な使用では検証を待つ必要は通常ないということだ。検証の待機や信頼できる第三者の利用を必要とするのは未知の相手だ。 したがって、オンラインでもIRLでも、ほとんどの日常的な取引は即座に信頼に基づいて行えるか、ローカルクライアントの検証による追加の確信でほぼ即座に行える。10分の遅延は実際にはデメリットではない。
ここでまた混乱した。あなたのスキームにはブロックはなく、トランザクションだけだと思っていた。先に「ブロック」を解くとはどういう意味か？
私のスキームにはブロックがない。ここでは既存のシステムの動作方法について言及していた。
ギャビン・アンドレセン😕？ ネットワークに10,000ノードがあるとしよう。二重支払いしたいトランザクションに最も近いネットワークノードを見つけるためにクエリを行う。
そこで秘密鍵を生成する。現在最も近いノードよりも近くなる確率は約1/10,000だ。だから近い鍵を5つ見つけるまで秘密鍵を生成し続ける。確率を今から計算する余裕はないが、100,000の秘密鍵を生成すれば、5つ見つかる可能性はかなり高い。私のしょぼいラップトップでも最低でも毎秒100のECC鍵を生成できるので、20分もあれば100,000を生成できる。
それらの鍵で5つのノードを作成し（ネットワークの残りに「みなさん、正直なところ、これらの鍵は本当にランダムに選んだんだ…」と言いながら）、勝利だ。
トランザクションのハッシュに対して、ネットワーク上の他のどのノードよりも「近い」ノードIDを生成しようとしているのだ。それははるかに簡単だ。
はい、はるかに簡単だ！
この特定のケースについて、非常にもっともらしい議論をしてくれた。お見事！
ポイントはそこではないので、私も計算はしない。「解決策」を提案しているわけではない。bitcoinの要件を満たすために計算リソースがこれほど悪くスケールする必要はないことを示唆しているのだ。他の合理的な設計が、大幅に低いCPU使用量で、そしてこのスレッドの場合はより低いレイテンシーでbitcoinの要件を満たせることを示そうとしているだけだ。
このフォーラムのブレイントラストがあれば、分散型ソリューションの限界は容易に発見・修正できると思う。現在の実装においてもまさにそれが行われているとおりだ。おそらくノードIDの作成方法が不適切だったのだろう。Freenetは完全に異なるノードID共有生成方法を提案している。あなたが指摘する問題は発生しない。おそらくこの状況では他の問題があるかもしれない。しかし、機能する分散型実装が存在すると確信している。
あなたの議論の主旨と懐疑は、100,000のCPUを100%で24時間365日稼働させ、トランザクションごとに100,000以上の冗長メッセージを送信するよりも良い解決策が絶対にありえないと考えているからか？
（100,000という数字は、何百万人ものユーザーを支える想定のシステムにおいて、サトシが見込んでいたコアノード数だ）
あなたの議論の主旨と懐疑は、100,000のCPUを100%で24時間365日稼働させ、トランザクションごとに100,000以上の冗長メッセージを送信するよりも良い解決策が絶対にありえないと考えているからか？
いや、全くそうではない。このスレッドに飛び込んだ時に言ったように、DHTネットワークを使って何らかの方法で作業を分散するのは非常に興味深いアイデアだと思う。ただ、ネットワークを分割するどんなソリューションも、悪意のあるノードを挿入する攻撃に対してより脆弱になるように思える。実際に機能するリソース集約度の低いソリューションを考え出せたら素晴らしいと思う。
FreenetはどうやってノードIDを生成しているのか？ 最新のFreenetの論文で見つけた唯一の情報は： ……そして：……これはBitcoinにはあまりうまく機能しないように聞こえる。
BitCoinの動作について全ステップを文書化した大きな技術図が必要なのかもしれない。次に誰かが「bitcoinのあらゆる部分がうまく実装されていない理由」について新しいトピックを立てたら、その図を指して「これがどう動いているかだ。あなたの新しい仕組みがどう動くかを詳細に文書化してくれ。それで比較しよう」と言えばいい 😁
このフォーラムで「これは正しくやられていない」という話題が出るたびに見かける多くの思い込みや議論を、それで減らせると思う。
ちょっと言ってみただけだけど…… 😎
私が言及していた方式は、Freenetの最初期のバージョンにあったものだ。信頼接続モデルが実装される前に設計されていた。詳細を思い出すには全部を見直さないといけない。だが基本的には、接続するノードがまず選ばれ（選び方は忘れた）、次にあなたがランダムな数を選んでそれらすべてのノードにブロードキャストする。各ノードもランダムな数を選んで、あなたとその集合内の他のノードに送り返す。すべての数が数学的に結合されて（関数は覚えていない）あなたの任意のIDになる。その合意されたIDに応答しなければ、誰もあなたと通信しない。
間違っていても訴えないでくれ。明らかに当てにならない記憶からの話だ。
Sybil攻撃（映画にちなんで名付けられたと思う）はネットワーク分断攻撃だった。複数の人格を作り出して、あるノードを取り囲んで何を保存しているかを推測しようとする。明らかにこのID生成方式ではそれが可能だと判明した。そこで新しいfriend-to-friendトポロジーが生まれた。同じ制約はbitcoinにとっても弱点になり得る。だが失敗は、次の進み方への最良の手引きになることが多い。
Freenetの脱線はひとまず置いて……
「Proof-of-work」の技法は、あなたが鋭く指摘したID生成問題への対処にも実は応用できるかもしれない。トランザクションの記録を生成しにくくする代わりに、新しいノードを生成してネットワークに接続することを難しくすればいい。
仮に（思いつきで作るが）、ノードに秘密鍵を作らせ、その鍵に対してproof-of-workのチェックサムを計算させ、そしてノードIDをRIPE-160(SHA-256(POWCheckum(公開鍵) + SHA-256(公開鍵)))のようなものにする、と要求するとしよう。
意図は、ノードIDの生成を、攻撃を成立させられないほどに遅くすること。ただし、新規ノードの参加が苦痛になるほど遅くはしないこと。
それにトランザクションへの土壇場の「ソルト」を組み合わせれば、ほぼ目的地までたどり着けるかもしれない。
ところで、私の前回の構想で見落としていたものに気づいた。
トランザクションがDHTに送られたとき、実際には多数の（できれば独立した）ノードに保存されると私は仮定していた。各入力点に関連して5回、各出力点に関連して5回。さらに支払者によって1回、受取人によって1回。入力1・出力2なら17倍の冗長性ということになる。
これらの場所のどれもが、トランザクションが消えた場合にネットワークに「再送信できる」はずだ。
ただし、私は3つのことを考慮し損ねていた。1) 検証者は17箇所のうち5箇所だけを検証に使う。2) 最初の5箇所が侵害された場合、他の冗長な場所に問い合わせる手段がない。3) 追加の冗長な場所は、標的を絞った悪意ある虚偽を返してきた侵害ノードを識別する手段がない。
しまった。だがいい指摘だ！
各ノードの影響力がCPUパワーに比例するシステムから離れてしまったら、（おおよそ）一人であるかどうかを判定するために何を使うのか？
もちろんそれが核心の問いだ。自分は、人／ノードであることを示すのを難しくする必要があると思う。前回の投稿で初期の考えをいくつか書いた。