レイテンシーと局所性
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 のプライバシー面をさらに改善できる可能性がある。
私が提案しているものはまだ存在しない。ブロック生成の熱力学的な非合理性について、類似の問題に関する議論はあった。中央ノードが1つだけなら、システムは一瞬でトランザクションブロックを生成できる。望めば10分に1回だけ行うこともできる。だが、単一プロセッサー上の一瞬のCPU時間以上は必要ない。
どちらのトランザクションが先だったかについて意見が分かれたらどうなるのか？多数決か？誰が多数派を決定するのか、そして 5 つのノードのうち 4 つがネットワークを離れ、別の 5 つのノードに置き換わった場合、結果は変わりうるのか？
また、大きなトランザクションを作成しようとしていることが分かっている場合、そのトランザクション（まだ送信していない）が自分の支配下にあるノードにハッシュされるよう、ノード ID を事前計算することはできないのか？トランザクションを保存するすべてのノードを支配していれば、「はい、間違いなく、そのトランザクションは有効で二重支払いはありません」と回答するだけで済む……
Bitcoin の背後にある素晴らしい洞察は、分散型タイムスタンプの仕組みだ。全員がトランザクションの順序に合意する。あなたの方式がその問題をどう解決するのか、私には分からない。
こんな場面を想像してほしい……
iPhone でフルクライアントがバックグラウンドで動作していて、停電が起きたとする。近所の店に行くと、店主が冷蔵庫のすべてを半額にしている。現金か Bitcoin のみだ。携帯電話のクライアントがアドホック Bluetooth を介して店主の携帯電話クライアントと接続する。送金アナウンス（ウォレットに実際の暗号コインがあるわけではなく、ブロックチェーンと呼ばれる暗号化された台帳への一連のエントリとしてのみ存在する。実際のコインというよりは小切手を書くようなものだ）に署名し、店主のアドレスに送る。店主のクライアントは、最後のブロックチェーン更新時点であなたが実際にその Bitcoin を所有していたかを自分のブロックチェーンのコピーで確認できる（しなくてもよい）。ローカルで問題なければ、あなたが騙そうとしていないと仮定して取引を受け入れ、あなたは半額の牛乳を持って帰る。これは意図的な二重支払いから店主を守るものではないが、これを行うにはある時点でコインを正当に所有していなければならない。停電時にコインを所有していなかった場合、店主のクライアントは送金を拒否する。
ここでもう一つ指摘したかったことがある。
上記の例と同様に、ほとんどの現金取引は実際には匿名ではなく、擬似匿名だ。例えば、一方の当事者は確立された存在（店主）で、もう一方はほぼ匿名（上記のお買い得品ハンター）だが、買い手でさえ真に匿名ではない。以前から何度もその店に来ており、店主が名前を知らなくても、顔を見覚えるほど見ている。だから、地元客や常連だからという信頼があり、機会主義的な詐欺を仕掛けるプロではないだろうと考える。
擬似匿名取引のもう一つの例は、両当事者が世界に対しては匿名だが、お互いにはそうでないタイプだ。これは現実世界のほとんどの現金取引の仕組みだ。しかしオンラインではこうなるだろう…
何か、変わったものが欲しいとする。Tor 上で隠しウェブサイトを運営し、欲しい商品を売っている人物を見つける。ウェブサイト上では「pothead420」としてしか知らない。連絡手段は他になく、実際に誰なのか知る術もない。この人物を信頼していないが、誰かが信頼の飛躍をしなければならず、それはおそらくあなただ。だからまず少量を注文する。数回の取引が成功すると、「pothead420」が正直な売り手だという信頼が高まり、注文量が増える。相手はいつでもあなたを裏切れるが、そうすれば常連客を失うことになるので、きちんと対応し続けるインセンティブがある。
3 つ目の擬似匿名信頼関係は、まさにこのフォーラムで見られる評判に依存するものだ。ほとんどの人は本名を使っていないが、使っている人もいる。Bitcoin プログラマーの名前を使っているメンバーが実際のプログラマーだと推定し、それを裏付ける証拠もあるが、確実にはわからない。しかし、このフォーラムに関する限り、彼には評判がある。だから直接取引をして裏切れば、あなたが信頼できないという彼の言葉は、どんな新参者よりも長い評判を持つ彼だけの理由で、将来のビジネスに悪影響を与える。
これらの例はすべて何らかの二者間信頼を含んでいるが、両者が第三者を信頼することを必要とするものは一つもない。ブロックチェーンの検証でさえも。
これらの例はすべて何らかの二者間信頼を含んでいるが、両者が第三者を信頼することを必要とするものは一つもない。ブロックチェーンの検証でさえも。
信頼できない相手と取引する際、信頼できる第三者は非常に有用だ。一方が取引管理者を信頼して Bitcoin を預け、もう一方が Liberty Reserve や Pecunix のような決済プロセッサーを信頼して支払い証明を取引管理者に提供し、管理者が支払い証明を受け入れることを信頼する。両方のトレーダーが取引サイトと決済プロセッサー、つまり両方の第三者を信頼する必要があるが、お互いを信頼する必要はない。
このアイデアを頭ごなしに否定する理由を探せば、見つかるだろう。しかし、なぜ一部の P2P システムは成功し、多くは失敗するのかを理解するためにこの例を使えば、何かしらの洞察が得られるはずだ。
その精神で、質問に直接答えよう。
ギャビン・アンドレセンの投稿（2010年8月6日 14:32 UTC）どちらのトランザクションが先だったかについて意見が分かれたらどうなるのか？多数決か？誰が多数派を決定するのか、そして 5 つのノードのうち 4 つがネットワークを離れ、別の 5 つのノードに置き換わった場合、結果は変わりうるのか？
その out-point を使う他のトランザクションが 1 つでも見つかれば二重支払いだ。現在の Bitcoin システムと同じルールだ。意見の不一致が起こり得るのは、競合するトランザクションが同時にブロードキャストされ、一方がノード A に先に到着し、競合する方がノード E に先に到着した場合だけだ。2 つの 5 ノードブロードキャストが完了するまでに、双方が二重支払いを発見する。
ではどちらが有効か？どちらでもいい。コインを投げればいい。Bitcoin はこの状況でまさにそうしている。自分のノードがあるトランザクションを含むブロックに取り組んでいて、あなたのノードが競合するトランザクションを含むブロックに取り組んでいる場合、先にブロックを解いた方が勝つ。分散コイン投げアルゴリズムは自明だ。これらすべてはほぼ即座に実行できる。10分間のウィンドウよりはるかに速い。だから 4 ノードが離脱しても多数派は変わらない。合意はすでに達成され、ノードは整合性が取れた状態になっているからだ。
ちなみに、標準的な DHT はノードが離脱した時のデータ保持と、ノードが参加した時のデータ分散にすでに対応している。
ギャビン・アンドレセンの投稿（2010年8月6日 14:32 UTC）また、大きなトランザクションを作成しようとしていることが分かっている場合、そのトランザクション（まだ送信していない）が自分の支配下にあるノードにハッシュされるよう、ノード ID を事前計算することはできないのか？トランザクションを保存するすべてのノードを支配していれば、「はい、間違いなく、そのトランザクションは有効で二重支払いはありません」と回答するだけで済む……
いいえ、これは要件上の制約だ。同じ理由で不可能だ——2 つの公開鍵が同じ Bitcoin アドレスに一致するものを生成することが不可能なのと同じだ。以前の私の失言を参照してほしい。
ノードは Bitcoin アドレスと全く同じように秘密鍵に基づいてノードアドレスを生成する。これによりノードのなりすましは非現実的になる。out-point ハッシュへのすべての入力は受取人を除いて固定されており、受取人は事前に指定されている。唯一の柔軟性は支払い額だろう。すべての可能な金額を反復して同時に 5 方向のハッシュ衝突を作ろうとするなら、どうぞ好きにしてくれ。
ギャビン・アンドレセンの投稿（2010年8月6日 14:32 UTC）Bitcoin の背後にある素晴らしい洞察は、分散型タイムスタンプの仕組みだ。全員がトランザクションの順序に合意する。あなたの方式がその問題をどう解決するのか、私には分からない。
実は全く同じ方法で問題を解決する。ただ CPU パワーがはるかに少なくて済む。
Bitcoin の分散タイムスタンプメカニズムの背後にある素晴らしい洞察は、絶対的なタイムスタンプは全く必要ないということだ！必要なのは相対的な順序だけだ。短いウィンドウ内での競合については、気にする必要すらない。単に任意に 1 つを選べばいい。
私の解決策はまさに同じことをする。トランザクション間の相対的な順序を維持する。競合については任意に合意に達する。どちらの方法も、無関係なトランザクションを時間順に正確に並べる必要はない。繰り返すが、あれは素晴らしい洞察だった。
このアイデアを頭ごなしに否定する理由を探せば、見つかるだろう。しかし、なぜ一部のP2Pシステムは成功し、多くは失敗するのかを理解するためにこの例を使えば、何かしらの洞察が得られるはずだ。
ここでまた混乱した。あなたのスキームにはブロックはなく、トランザクションだけだと思っていた。先に「ブロック」を解くとはどういう意味か？
しかし、標準的な DHT は通常 MP3 や映画のチャンクを保存するために使われ、各ピースのハッシュを持つトレントファイルによってインデックスされる。だから、特定の DHT ノードから不正なデータを受け取っているかどうかを簡単に判別できる。信頼する必要はない。
えっと？ネットワークに 10,000 ノードがあるとしよう。二重支払いしたいトランザクションに最も近いネットワークノードを見つけるためにクエリを行う。
そこで秘密鍵を生成する。現在最も近いノードよりも近くなる確率は約 1/10,000 だ。だから近い鍵を 5 つ見つけるまで秘密鍵を生成し続ける。確率を今から計算する余裕はないが、100,000 の秘密鍵を生成すれば、5 つ見つかる可能性はかなり高い。私のしょぼいラップトップでも少なくとも毎秒100 の ECC 鍵を生成できるので、20分もあれば 100,000 を生成できる。
それらの鍵で 5 つのノードを作成し（ネットワークの残りに「正直に言うと、これらの鍵はランダムに選んだんだ…」と言いながら）、勝利だ。
特定のハッシュを持つトランザクションを生成しようとしているのではなく、現在ネットワーク上の他のどのノードよりもそのトランザクションのハッシュに「近い」ノード ID を生成しようとしている。それはずっと簡単だ。
creightoの投稿（2010年8月6日 14:42 UTC）これらの例はすべて何らかの二者間の信頼を含むが、どれも双方が第三者を信頼する必要はない。ブロックチェーンの検証でさえもだ。
信頼できる第三者は、信頼できない相手と取引する際に非常に有用だ。
はい、ただ私が指摘していたのは、通貨の一般的な使用では検証を待つ必要は通常ないということだ。検証の待機や信頼できる第三者の利用を必要とするのは未知の相手だ。 したがって、オンラインでも IRL でも、ほとんどの日常的な取引は即座に信頼に基づいて行えるか、ローカルクライアントの検証による追加の確信でほぼ即座に行える。10分の遅延は実際にはデメリットではない。
ここでまた混乱した。あなたのスキームにはブロックはなく、トランザクションだけだと思っていた。先に「ブロック」を解くとはどういう意味か？
私のスキームにはブロックがない。ここでは既存のシステムの動作方法について言及していた。
ギャビン・アンドレセンの投稿（2010年8月6日 16:20 UTC）えっと？ネットワークに 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以上の冗長メッセージを送信するよりも良い解決策がありえないと考えているからか？
いいえ、全くそうではない。このスレッドに飛び込んだ時に言ったように、DHT ネットワークを使って何らかの方法で作業を分散するのは非常に興味深いアイデアだと思う。ただ、ネットワークを分割するどんなソリューションも、悪意のあるノードを挿入する攻撃に対してより脆弱になるように思える。実際に機能するリソース集約度の低いソリューションを考え出せたら素晴らしいと思う。
Freenet はどうやってノード ID を生成しているのか？最新の Freenet の論文で見つけた唯一の情報は： ……そして：……これは Bitcoin にはあまりうまく機能しないように聞こえる。
各ノードの影響力が CPU パワーに比例するシステムから離れてしまったら、（おおよそ）一人であるかどうかを判定するために何を使うのか？
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 パワーに比例するシステムから離れてしまったら、（おおよそ）一人であるかどうかを判定するために何を使うのか？
もちろんそれが核心の問いだ。自分は、人／ノードであることを示すのを難しくする必要があると思う。前回の投稿で初期の考えをいくつか書いた。