スケーラビリティ
すべてのユーザーがネットワークノードである現在のシステムは、大規模向けの意図された構成ではない。それはすべてのUsenetユーザーが自分のNNTPサーバーを運用するようなものだ。この設計はユーザーを単なるユーザーのままにすることをサポートしている。ノードの運用負担が大きくなるほど、ノード数は少なくなる。少数のノードは大規模なサーバーファームになるだろう。残りはトランザクションのみを行い生成を行わないクライアントノードになる。
トランザクションのないブロックヘッダーは約80バイトだ。ブロックが10分ごとに生成されると仮定すると、80バイト × 6 × 24 × 365 = 年間4.2MBだ。2008年時点でコンピュータシステムが通常2GBのRAMで販売されており、ムーアの法則が年間1.2GBの成長を予測していることから、ブロックヘッダーをメモリに保持する必要があっても、ストレージは問題にならないはずだ。
すべてのノードがすべてのトランザクションに関する情報を受信する（技術論文に記載されている通り）という理解で正しいだろうか？それでは、ビットコインを大規模な通貨として使用することは完全に非実用的にならないだろうか？
経済の議論はたぶん別スレッドでやるべきだから、これくらいにしておく。新しいスレッドを立てようとしたら、この人が自分の言いたいことをもっとうまく言ってくれていた：topic 57
knightmb：ブロックあたりのコイン数は時間とともに減少するよう設定されているから、数値はそれよりかなり大きくなる。トランザクションも含める必要がある。最初の67kブロックの間のトランザクション数は、何百万人もの人がこのシステムを使い始めた場合よりはるかに少ない。
コードに取り組んでいる人、スケーリングがどう対処されるのか答えてくれないか？今一番重要なのは、このシステムが機能する理由を売り手に納得させることだと思う。PDFは詳細が不十分だ。
Quote from: TopSoil on July 13, 2010, 09:37:33 PM
経済の議論はたぶん別スレッドでやるべきだから、これくらいにしておく。新しいスレッドを立てようとしたら、この人が自分の言いたいことをもっとうまく言ってくれていた：topic 57
knightmb：ブロックあたりのコイン数は時間とともに減少するよう設定されているから、数値はそれよりかなり大きくなる。トランザクションも含める必要がある。最初の67kブロックの間のトランザクション数は、何百万人もの人がこのシステムを使い始めた場合よりはるかに少ない。
コードに取り組んでいる人、スケーリングがどう対処されるのか答えてくれないか？今一番重要なのは、このシステムが機能する理由を売り手に納得させることだと思う。PDFは詳細が不十分だ。
指摘してくれてありがとう、時間とともにどうスケールするのか分からなかったから、推測しただけだった。コイン生成の式はどこかで分かるはずだから、XYZのトランザクションが与えられた場合にX量のコインがどれだけのディスク容量を使うか、誰か計算できないのか。
自分自身もどのくらいの容量になるか気になる。 Smiley
Quote from: knightmb on July 13, 2010, 10:08:58 PM
Quote from: TopSoil on July 13, 2010, 09:37:33 PM
経済の議論はたぶん別スレッドでやるべきだから、これくらいにしておく。新しいスレッドを立てようとしたら、この人が自分の言いたいことをもっとうまく言ってくれていた：topic 57
knightmb：ブロックあたりのコイン数は時間とともに減少するよう設定されているから、数値はそれよりかなり大きくなる。トランザクションも含める必要がある。最初の67kブロックの間のトランザクション数は、何百万人もの人がこのシステムを使い始めた場合よりはるかに少ない。
コードに取り組んでいる人、スケーリングがどう対処されるのか答えてくれないか？今一番重要なのは、このシステムが機能する理由を売り手に納得させることだと思う。PDFは詳細が不十分だ。
指摘してくれてありがとう、時間とともにどうスケールするのか分からなかったから、推測しただけだった。コイン生成の式はどこかで分かるはずだから、XYZのトランザクションが与えられた場合にX量のコインがどれだけのディスク容量を使うか、誰か計算できないのか。
自分自身もどのくらいの容量になるか気になる。 Smiley
論文から： 「トランザクションのないブロックヘッダは約80バイトになる。」 そして 「コインの最新トランザクションが十分なブロックの下に埋もれたら、それ以前の使用済みトランザクションは ディスク容量を節約するために破棄できる。」
つまり、80 × ブロック数 + 平均トランザクションサイズ × トランザクション数だ。
実際に自分のディスクから： 66663ブロック中の77428トランザクションは約46,752,464バイト。 これは1トランザクションあたり約600バイトになる（ブロックヘッダとデータベースのオーバーヘッドを含む）
Quote from: Insti on July 13, 2010, 11:34:03 PM
Quote from: knightmb on July 13, 2010, 10:08:58 PM
コイン生成の式はどこかで分かるはずなので、XYZのトランザクションが与えられた場合にX量のコインがどれだけのディスク容量を使うか計算できないのか。 自分自身もどのくらいの容量になるか気になる。
論文から： 「トランザクションのないブロックヘッダは約80バイトになる。」 そして 「コインの最新トランザクションが十分なブロックの下に埋もれたら、それ以前の使用済みトランザクションは ディスク容量を節約するために破棄できる。」
つまり、80 × ブロック数 + 平均トランザクションサイズ × トランザクション数だ。
実際に自分のディスクから： 66663ブロック中の77428トランザクションは約46,752,464バイト。 これは1トランザクションあたり約600バイトになる（ブロックヘッダとデータベースのオーバーヘッドを含む）
それくらいだろう。
つまり1日100万トランザクションなら6億バイトだ。1日600メガバイト、月18GB。
それほど悪くない。実際のネットワーク帯域幅はもっと大きくなる（ネットワークの接続方法により、ピアから同じトランザクションを複数回受信する）。iPhoneで常時接続ネットワークノードを動かすことにはならないが、安価なサーバーならその20倍の月間帯域幅を提供できる。そして18GBはテラバイトのハードドライブの時代にはたいしたディスク容量ではない。
1日100万トランザクションは非常に多い！ 比較のために言えば、2006年にはアメリカで1日あたり約6000万件のクレジットカード取引があった。
最終的に、Bitcoinが生き残ってクレジットカードと同じくらい普及すれば、誰かがより効率的なネットワーク構造を持つ互換バージョンを作るだろう（その頃には何か洗練されたIPV6マルチキャストプロトコルなどがあるかもしれない）。そして彼らはいくつかのゲートウェイノード（非常に高速な回線で動作する）を実装して、現在のBitcoinネットワークからトランザクションとブロックのトラフィックを超効率的なネットワークに中継するだろう。そしてほとんどの人は、ウォレットの保持、トランザクションの署名、そしてすべてのトランザクションを監視している超高速ノードへのトランザクションの送受信だけを行う軽量クライアントを使うことになるだろう。
つまり、インターネットのバックボーントラフィックを処理する巨大なルーターや、超高速のDNSルートサーバーのようなものだ。インターネットも最初から驚異的に高速なルーターがパケットを飛ばし合っていたわけではない。
Quote from: gavinandresen on July 14, 2010, 12:42:32 AM
Quote from: Insti on July 13, 2010, 11:34:03 PM
Quote from: knightmb on July 13, 2010, 10:08:58 PM
コイン生成の式はどこかで分かるはずなので、XYZのトランザクションが与えられた場合にX量のコインがどれだけのディスク容量を使うか計算できないのか。 自分自身もどのくらいの容量になるか気になる。
論文から： 「トランザクションのないブロックヘッダは約80バイトになる。」 そして 「コインの最新トランザクションが十分なブロックの下に埋もれたら、それ以前の使用済みトランザクションは ディスク容量を節約するために破棄できる。」
つまり、80 × ブロック数 + 平均トランザクションサイズ × トランザクション数だ。
実際に自分のディスクから： 66663ブロック中の77428トランザクションは約46,752,464バイト。 これは1トランザクションあたり約600バイトになる（ブロックヘッダとデータベースのオーバーヘッドを含む）
それくらいだろう。
つまり1日100万トランザクションなら6億バイトだ。1日600メガバイト、月18GB。
それほど悪くない。実際のネットワーク帯域幅はもっと大きくなる（ネットワークの接続方法により、ピアから同じトランザクションを複数回受信する）。iPhoneで常時接続ネットワークノードを動かすことにはならないが、安価なサーバーならその20倍の月間帯域幅を提供できる。そして18GBはテラバイトのハードドライブの時代にはたいしたディスク容量ではない。
1日100万トランザクションは非常に多い！ 比較のために言えば、2006年にはアメリカで1日あたり約6000万件のクレジットカード取引があった。
最終的に、Bitcoinが生き残ってクレジットカードと同じくらい普及すれば、誰かがより効率的なネットワーク構造を持つ互換バージョンを作るだろう（その頃には何か洗練されたIPV6マルチキャストプロトコルなどがあるかもしれない）。そして彼らはいくつかのゲートウェイノード（非常に高速な回線で動作する）を実装して、現在のBitcoinネットワークからトランザクションとブロックのトラフィックを超効率的なネットワークに中継するだろう。そしてほとんどの人は、ウォレットの保持、トランザクションの署名、そしてすべてのトランザクションを監視している超高速ノードへのトランザクションの送受信だけを行う軽量クライアントを使うことになるだろう。
つまり、インターネットのバックボーントラフィックを処理する巨大なルーターや、超高速のDNSルートサーバーのようなものだ。インターネットも最初から驚異的に高速なルーターがパケットを飛ばし合っていたわけではない。
それは可能なのか？どのようなものになるのか？技術的な観点から「軽量クライアント」はどういうものをイメージしているのか？私の理解では、Bitcoinクライアントは信頼を確立するためにブロックチェーン全体が必要だ。
ちょっと思いつきを述べてみる…
P2Pモデルは確かに斬新だが、多少ユートピア的に思える。少し付き合ってほしい（荒らしたいわけではない）。銀行を考えてみよう。銀行には効率的に協力し合うシステムがある。銀行Yの口座を持っていても、銀行XのATMからお金を引き出せる。銀行同士は融資し合う。基本的に協力的だ。すべての人がPC（やスマートフォン）にBitcoinクライアントを入れてオープンなP2Pネットワークに参加する代わりに、Bitcoinの「銀行」の集まりがブロックチェーンのホスティングと「ピアリング」のサービスを提供するのはどうだろう。これらは十分に大きな組織で、1日100万件（以上）のトランザクションを持つ無限に長いブロックチェーンを維持するための帯域幅とハードウェアを賄える。これらの銀行はP2Pのままであり、完全にオープンであることが望ましい。理想的には誰でもP2Pネットワークに参加できるが、参入障壁があるため一般の人はそうしないだろう。これらの銀行は今日あるのと同じ基本技術で運営される。Bitcoinの美しい側面はすべて保たれるが、アクティブな参加者の数がいくらか減少する。参加したい人は引き続き参加できる。
残る問題は典型的な「ラストマイル」問題だ。一般ユーザーはどうやってトランザクションを行うのか？この時点では問題はかなり単純になる。信頼は2者間（「銀行」とユーザー）だけで済む。これは本質的にプロキシの問題になる。ユーザーは「銀行」を通じてトランザクション要求を送信する。プロキシトランザクション用のプロトコルをBitcoinに組み込むことさえ可能かもしれない。
とにかく…これは私の個人的な意見に過ぎない。この問題に対する具体的な回答がほしい。なぜなら、この取り組みの成功にとって根本的に重要だと思うからだ。
Quote from: spaceshaker on July 14, 2010, 01:52:00 AM
Quote from: gavinandresen on July 14, 2010, 12:42:32 AM
そしてほとんどの人は、ウォレットの保持、トランザクションの署名、そしてすべてのトランザクションを監視している超高速ノードへのトランザクションの送受信だけを行う軽量クライアントを使うことになるだろう。
それは可能なのか？どのようなものになるのか？技術的な観点から「軽量クライアント」はどういうものをイメージしているのか？私の理解では、Bitcoinクライアントは信頼を確立するためにブロックチェーン全体が必要だ。
ちょっと思いつきを述べてみる…
P2Pモデルは確かに斬新だが、多少ユートピア的に思える。少し付き合ってほしい（荒らしたいわけではない）。銀行を考えてみよう。銀行には効率的に協力し合うシステムがある。銀行Yの口座を持っていても、銀行XのATMからお金を引き出せる。銀行同士は融資し合う。基本的に協力的だ。すべての人がPC（やスマートフォン）にBitcoinクライアントを入れてオープンなP2Pネットワークに参加する代わりに、Bitcoinの「銀行」の集まりがブロックチェーンのホスティングと「ピアリング」のサービスを提供するのはどうだろう。これらは十分に大きな組織で、1日100万件（以上）のトランザクションを持つ無限に長いブロックチェーンを維持するための帯域幅とハードウェアを賄える。これらの銀行はP2Pのままであり、完全にオープンであることが望ましい。理想的には誰でもP2Pネットワークに参加できるが、参入障壁があるため一般の人はそうしないだろう。これらの銀行は今日あるのと同じ基本技術で運営される。Bitcoinの美しい側面はすべて保たれるが、アクティブな参加者の数がいくらか減少する。参加したい人は引き続き参加できる。
残る問題は典型的な「ラストマイル」問題だ。一般ユーザーはどうやってトランザクションを行うのか？この時点では問題はかなり単純になる。信頼は2者間（「銀行」とユーザー）だけで済む。これは本質的にプロキシの問題になる。ユーザーは「銀行」を通じてトランザクション要求を送信する。プロキシトランザクション用のプロトコルをBitcoinに組み込むことさえ可能かもしれない。
とにかく…これは私の個人的な意見に過ぎない。この問題に対する具体的な回答がほしい。なぜなら、この取り組みの成功にとって根本的に重要だと思うからだ。 Quote from: gavinandresen on July 14, 2010, 12:42:32 AM Quote from: Insti on July 13, 2010, 11:34:03 PM
66663ブロック内の77428トランザクションは約46,752,464バイトだ。 トランザクションあたり約600バイト（ブロックヘッダ+データベースのオーバーヘッドを含む）になる。
それくらいだろう。
つまり1日100万トランザクションなら6億バイトだ。1日600メガバイト、月18GB。
それほど悪くない。実際のネットワーク帯域幅はもっと大きくなる（ネットワークの接続方法により、ピアから同じトランザクションを複数回受信する）。iPhoneで常時接続ネットワークノードを動かすことにはならないが、安価なサーバーならその20倍の月間帯域幅を提供できる。そして18GBはテラバイトのハードドライブの時代にはたいしたディスク容量ではない。
1日100万トランザクションは非常に多い！ 比較のために言えば、2006年にはアメリカで1日あたり約6000万件のクレジットカード取引があった。
最終的に、Bitcoinが生き残ってクレジットカードと同じくらい普及すれば、誰かがより効率的なネットワーク構造を持つ互換バージョンを作るだろう（その頃には何か洗練されたIPV6マルチキャストプロトコルなどがあるかもしれない）。そして彼らはいくつかのゲートウェイノード（非常に高速な回線で動作する）を実装して、現在のBitcoinネットワークからトランザクションとブロックのトラフィックを超効率的なネットワークに中継するだろう。そしてほとんどの人は、ウォレットの保持、トランザクションの署名、そしてすべてのトランザクションを監視している超高速ノードへのトランザクションの送受信だけを行う軽量クライアントを使うことになるだろう。
つまり、インターネットのバックボーントラフィックを処理する巨大なルーターや、超高速のDNSルートサーバーのようなものだ。インターネットも最初から驚異的に高速なルーターがパケットを飛ばし合っていたわけではない。
私のイメージはこうだ：
軽量クライアントはコインの入ったウォレット（公開鍵+秘密鍵のペア）を持つ。
そして、常時接続の超高速ヘビー級ノードとの間で安全にメッセージを送受信する方法を持つ。
軽量クライアントは送金時に： トランザクションを作成する（秘密鍵でコインに署名する） 署名済みトランザクションを超高速サーバーに安全に送信し、サーバーがネットワークに流す トランザクションが有効で送信されたことの確認を受け取り、ウォレットを更新する（コインを使用済みにする） （またはサーバーから「そのコインはすでに使用済みだ」というエラーを受け取る）
軽量クライアントは受け取り時に： 定期的にサーバーにポーリングして「ウォレット内のこれらのBCアドレスへの支払いはあるか？」と尋ねる …またはBCアドレスのリストへのトランザクションを検知した時（あるいはN回の確認が得られた関連トランザクションを検知した時）に通知するようサーバーに依頼する トランザクションが発生したら、軽量クライアントはウォレットを更新する（コインを追加する）
サーバーを信頼する必要はない。サーバーは秘密鍵を持つことはない。
まあ、サーバーがトランザクションの有効性について嘘をつかないことは信頼する必要があるが、サーバーがなぜそんな嘘をつくのか？
確かにそのように動作はするが、それが理想なのか？ネットワークの堅牢性が低下し、攻撃や操作に対してより脆弱にならないか？攻撃者がスーパーノードのクラスタを運用し始めたらどうなるのか？要点は、その必要がないのに、なぜこのより脆弱なアーキテクチャに依存するのかということだ。実装がより簡単というわけでもない。
そう、どちらのシステムもあまり良い設計ではないと思う。LimewireはGnutellaのルーティングを実際にKademliaに置き換えた。
spaceshaker：そう、モバイルデバイスのプロキシとして機能するノードが必要になるという点には同意する。
Quote from: TopSoil on July 14, 2010, 03:59:18 PM
確かにそのように動作はするが、それが理想なのか？ネットワークの堅牢性が低下し、攻撃や操作に対してより脆弱にならないか？攻撃者がスーパーノードのクラスタを運用し始めたらどうなるのか？要点は、その必要がないのに、なぜこのより脆弱なアーキテクチャに依存するのかということだ。実装がより簡単というわけでもない。
そう、どちらのシステムもあまり良い設計ではないと思う。LimewireはGnutellaのルーティングを実際にKademliaに置き換えた。
spaceshaker：そう、モバイルデバイスのプロキシとして機能するノードが必要になるという点には同意する。
実際にはそうでもない。心配なら、自分自身のサーバーをいつでも運用できる。
何も問題ない。たまたまそのスーパーノードの一つを使っている場合を除けば。使う必要はない。自分でスーパーノードを運用すればいい。あるいは、人々がGoogleにメールを任せるように、信頼できるノードを使えばいい。
実装がより簡単だというわけではないだろう？ここは根拠を示してほしい。
反例：ライス大学で開発された完全分散型メールシステムは、半集中型のメールサーバー（群）を運用するよりもはるかに複雑だ。
それはまさにスーパーノードサーバーがやることだ。
Quote from: DataWraith on July 14, 2010, 04:42:16 PM
Quote from: TopSoil on July 14, 2010, 03:59:18 PM
引用：なぜ？メールやJabberも同じ仕組みだ。誰でも自分のサーバーを運用でき、多くの人がそうしているが、ほとんどのユーザーは他人のサーバーを使うことを好む。確かにそのように動作はするが、それが理想的なのか？それだとネットワークの堅牢性が低下し、攻撃や操作に対してより脆弱になるのではないか？
実際にはそうでもない。心配なら、自分自身のサーバーをいつでも運用できる。
何も問題ない。たまたまそのスーパーノードの一つを使っている場合を除けば。使う必要はない。自分でスーパーノードを運用すればいい。あるいは、人々がGoogleにメールを任せるように、信頼できるノードを使えばいい。
実装がより簡単だというわけではないだろう？ここは根拠を示してほしい。
反例：ライス大学で開発された完全分散型メールシステムは、半集中型のメールサーバー（群）を運用するよりもはるかに複雑だ。
それはまさにスーパーノードサーバーがやることだ。
うーん。確かに。一周回ったようだ。ギャビンが一番うまく言ったと思う：
Quote from: gavinandresen on July 14, 2010, 02:20:45 AM
Quote from: spaceshaker on July 14, 2010, 01:52:00 AM
Quote from: gavinandresen on July 14, 2010, 12:42:32 AM
そしてほとんどの人は、ウォレットの保持、トランザクションの署名、そしてすべてのトランザクションを監視している超高速ノードへのトランザクションの送受信だけを行う軽量クライアントを使うことになるだろう。
それは可能なのか？どのようなものになるのか？技術的な観点から「軽量クライアント」はどういうものをイメージしているのか？私の理解では、Bitcoinクライアントは信頼を確立するためにブロックチェーン全体が必要だ。
ちょっと思いつきを述べてみる…
P2Pモデルは確かに斬新だが、多少ユートピア的に思える。少し付き合ってほしい（荒らしたいわけではない）。銀行を考えてみよう。銀行には効率的に協力し合うシステムがある。銀行Yの口座を持っていても、銀行XのATMからお金を引き出せる。銀行同士は融資し合う。基本的に協力的だ。すべての人がPC（やスマートフォン）にBitcoinクライアントを入れてオープンなP2Pネットワークに参加する代わりに、Bitcoinの「銀行」の集まりがブロックチェーンのホスティングと「ピアリング」のサービスを提供するのはどうだろう。これらは十分に大きな組織で、1日100万件（以上）のトランザクションを持つ無限に長いブロックチェーンを維持するための帯域幅とハードウェアを賄える。これらの銀行はP2Pのままであり、完全にオープンであることが望ましい。理想的には誰でもP2Pネットワークに参加できるが、参入障壁があるため一般の人はそうしないだろう。これらの銀行は今日あるのと同じ基本技術で運営される。Bitcoinの美しい側面はすべて保たれるが、アクティブな参加者の数がいくらか減少する。参加したい人は引き続き参加できる。
残る問題は典型的な「ラストマイル」問題だ。一般ユーザーはどうやってトランザクションを行うのか？この時点では問題はかなり単純になる。信頼は2者間（「銀行」とユーザー）だけで済む。これは本質的にプロキシの問題になる。ユーザーは「銀行」を通じてトランザクション要求を送信する。プロキシトランザクション用のプロトコルをBitcoinに組み込むことさえ可能かもしれない。
とにかく…これは私の個人的な意見に過ぎない。この問題に対する具体的な回答がほしい。なぜなら、この取り組みの成功にとって根本的に重要だと思うからだ。 Quote from: gavinandresen on July 14, 2010, 12:42:32 AM Quote from: Insti on July 13, 2010, 11:34:03 PM
66663ブロック内の77428トランザクションは約46,752,464バイトだ。 トランザクションあたり約600バイト（ブロックヘッダ+データベースのオーバーヘッドを含む）になる。
それくらいだろう。
つまり1日100万トランザクションなら6億バイトだ。1日600メガバイト、月18GB。
それほど悪くない。実際のネットワーク帯域幅はもっと大きくなる（ネットワークの接続方法により、ピアから同じトランザクションを複数回受信する）。iPhoneで常時接続ネットワークノードを動かすことにはならないが、安価なサーバーならその20倍の月間帯域幅を提供できる。そして18GBはテラバイトのハードドライブの時代にはたいしたディスク容量ではない。
1日100万トランザクションは非常に多い！ 比較のために言えば、2006年にはアメリカで1日あたり約6000万件のクレジットカード取引があった。
最終的に、Bitcoinが生き残ってクレジットカードと同じくらい普及すれば、誰かがより効率的なネットワーク構造を持つ互換バージョンを作るだろう（その頃には何か洗練されたIPV6マルチキャストプロトコルなどがあるかもしれない）。そして彼らはいくつかのゲートウェイノード（非常に高速な回線で動作する）を実装して、現在のBitcoinネットワークからトランザクションとブロックのトラフィックを超効率的なネットワークに中継するだろう。そしてほとんどの人は、ウォレットの保持、トランザクションの署名、そしてすべてのトランザクションを監視している超高速ノードへのトランザクションの送受信だけを行う軽量クライアントを使うことになるだろう。
つまり、インターネットのバックボーントラフィックを処理する巨大なルーターや、超高速のDNSルートサーバーのようなものだ。インターネットも最初から驚異的に高速なルーターがパケットを飛ばし合っていたわけではない。
私のイメージはこうだ：
軽量クライアントはコインの入ったウォレット（公開鍵+秘密鍵のペア）を持つ。
そして、常時接続の超高速ヘビー級ノードとの間で安全にメッセージを送受信する方法を持つ。
軽量クライアントは送金時に： トランザクションを作成する（秘密鍵でコインに署名する） 署名済みトランザクションを超高速サーバーに安全に送信し、サーバーがネットワークに流す トランザクションが有効で送信されたことの確認を受け取り、ウォレットを更新する（コインを使用済みにする） （またはサーバーから「そのコインはすでに使用済みだ」というエラーを受け取る）
軽量クライアントは受け取り時に： 定期的にサーバーにポーリングして「ウォレット内のこれらのBCアドレスへの支払いはあるか？」と尋ねる …またはBCアドレスのリストへのトランザクションを検知した時（あるいはN回の確認が得られた関連トランザクションを検知した時）に通知するようサーバーに依頼する トランザクションが発生したら、軽量クライアントはウォレットを更新する（コインを追加する）
サーバーを信頼する必要はない。サーバーは秘密鍵を持つことはない。
まあ、サーバーがトランザクションの有効性について嘘をつかないことは信頼する必要があるが、サーバーがなぜそんな嘘をつくのか？
このシナリオでは、Bitcoinクライアントは現在とほぼ同じままだが、「スーパーノード」や「トランザクションサーバー」や「プロキシサーバー」（これらのシステムはおそらく3つの役割すべてを果たす）で使われるか、そのゲームに参加したい人が使うことに焦点が当てられるだろう。BitcoinクライアントがDHTを使うよう拡張されれば改善になるかもしれないが、ギャビンが上記で説明した「軽量クライアント」の必要性は依然としてある。ギャビンの「軽量クライアント」コンセプトは、私のスケーラビリティの懸念をある程度解消してくれるようだ。
Quote from: gavinandresen on July 14, 2010, 02:20:45 AM
Quote from: spaceshaker on July 14, 2010, 01:52:00 AM Quote from: gavinandresen on July 14, 2010, 12:42:32 AM
そしてほとんどの人は、ウォレットの保持、トランザクションの署名、そしてすべてのトランザクションを監視している超高速ノードへのトランザクションの送受信だけを行う軽量クライアントを使うことになるだろう。
それは可能なのか？どのようなものになるのか？技術的な観点から「軽量クライアント」はどういうものをイメージしているのか？私の理解では、Bitcoinクライアントは信頼を確立するためにブロックチェーン全体が必要だ。
私のイメージはこうだ：
軽量クライアントはコインの入ったウォレット（公開鍵+秘密鍵のペア）を持つ。
そして、常時接続の超高速ヘビー級ノードとの間で安全にメッセージを送受信する方法を持つ。
軽量クライアントは送金時に： トランザクションを作成する（秘密鍵でコインに署名する） 署名済みトランザクションを超高速サーバーに安全に送信し、サーバーがネットワークに流す トランザクションが有効で送信されたことの確認を受け取り、ウォレットを更新する（コインを使用済みにする） （またはサーバーから「そのコインはすでに使用済みだ」というエラーを受け取る）
軽量クライアントは受け取り時に： 定期的にサーバーにポーリングして「ウォレット内のこれらのBCアドレスへの支払いはあるか？」と尋ねる …またはBCアドレスのリストへのトランザクションを検知した時（あるいはN回の確認が得られた関連トランザクションを検知した時）に通知するようサーバーに依頼する トランザクションが発生したら、軽量クライアントはウォレットを更新する（コインを追加する）
サーバーを信頼する必要はない。サーバーは秘密鍵を持つことはない。
まあ、サーバーがトランザクションの有効性について嘘をつかないことは信頼する必要があるが、サーバーがなぜそんな嘘をつくのか？ Quote from: spaceshaker on July 14, 2010, 01:52:00 AM Quote from: gavinandresen on July 14, 2010, 12:42:32 AM
そしてほとんどの人は、ウォレットの保持、トランザクションの署名、そしてすべてのトランザクションを監視している超高速ノードへのトランザクションの送受信だけを行う軽量クライアントを使うことになるだろう。
それは可能なのか？どのようなものになるのか？技術的な観点から「軽量クライアント」はどういうものをイメージしているのか？私の理解では、Bitcoinクライアントは信頼を確立するためにブロックチェーン全体が必要だ。
ちょっと思いつきを述べてみる…
P2Pモデルは確かに斬新だが、多少ユートピア的に思える。少し付き合ってほしい（荒らしたいわけではない）。銀行を考えてみよう。銀行には効率的に協力し合うシステムがある。銀行Yの口座を持っていても、銀行XのATMからお金を引き出せる。銀行同士は融資し合う。基本的に協力的だ。すべての人がPC（やスマートフォン）にBitcoinクライアントを入れてオープンなP2Pネットワークに参加する代わりに、Bitcoinの「銀行」の集まりがブロックチェーンのホスティングと「ピアリング」のサービスを提供するのはどうだろう。これらは十分に大きな組織で、1日100万件（以上）のトランザクションを持つ無限に長いブロックチェーンを維持するための帯域幅とハードウェアを賄える。これらの銀行はP2Pのままであり、完全にオープンであることが望ましい。理想的には誰でもP2Pネットワークに参加できるが、参入障壁があるため一般の人はそうしないだろう。これらの銀行は今日あるのと同じ基本技術で運営される。Bitcoinの美しい側面はすべて保たれるが、アクティブな参加者の数がいくらか減少する。参加したい人は引き続き参加できる。
残る問題は典型的な「ラストマイル」問題だ。一般ユーザーはどうやってトランザクションを行うのか？この時点では問題はかなり単純になる。信頼は2者間（「銀行」とユーザー）だけで済む。これは本質的にプロキシの問題になる。ユーザーは「銀行」を通じてトランザクション要求を送信する。プロキシトランザクション用のプロトコルをBitcoinに組み込むことさえ可能かもしれない。
とにかく…これは私の個人的な意見に過ぎない。この問題に対する具体的な回答がほしい。なぜなら、この取り組みの成功にとって根本的に重要だと思うからだ。
想像する必要もない。実際には既にノードを「リモートコントロール」できるので、自分の（高速接続、HDD満載の）ホームサーバーに情報を送受信するだけの小さな軽量クライアントを作ればいい。
ある種の「管理されたサーバー-クライアント版」はMyBitcoinにすでに存在している。自分のウェブホストで同様のものを実行して、どこからでもどんな接続速度でもアクセスできる。
「軽量クライアント」自体がそうである必要はなく、接続して何をすべきか指示すればいい。 JSONでできる。
クライアントリストの維持にDHTを使うアイデアを支持する――何百万人もの人がIRCチャンネルなどに依存するわけにはいかない。スケーリングの問題に関して言えば、HDDの容量は問題ではなく、ネットワーク帯域幅だ。皆忘れているが、bytes_per_transaction*transactionsではない（これは皆が使っている数字だ）。その数字は、皆が言うように完全に管理可能だ。いや、我々が関心を持つべき数字はbytes_per_transaction * transactions * number_of_clients * total_hops_beyond_first_between_all_clients_combinedだ。
これが、ネットワークがスケールするにつれてBTCプロトコルが消費する帯域幅だ。各トランザクションの1コピーを各クライアントに送信するだけではなく、複数のクライアントが互いに冗長なデータをブロードキャストし、それを複数のホップを通じて行うため、何度もリブロードキャストされる。はるかに大きな数字であり、扱いがはるかに難しい。しかし、管理は可能だ。ただし、クライアントの現在のネットワーク処理の形では無理だ。
おそらく「普及」段階では、BTCチェーンを地域ごとに分割できるかもしれない。現在のドメインネーム管理機関の管轄と同様に。そして、これらの地域境界を越えた取引には代替プロトコルを使うとか？ これは問題の生の数字を改善し、レイテンシーや関連する問題も軽減するだろう。これが優れた解決策だとは思わないが――量子コンピューティングなどの大きなブレークスルーがない限り、全アクティブクライアントへのP2Pフラッディングは明らかに無理だ。
設計では、完全なブロックチェーンを必要としない軽量クライアントの概要が示されている。設計PDFでは簡易支払い検証（Simplified Payment Verification）と呼ばれている。軽量クライアントはトランザクションの送受信ができるが、ブロックの生成はできない。支払いの検証にノードを信頼する必要はなく、自分で検証できる。
軽量クライアントはまだ実装されていないが、必要になった時に実装する計画だ。今のところ、全員がフルネットワークノードを実行している。
ノード数は10万を超えることはないと予想しており、おそらくそれ以下だろう。それ以上のノードが参加する価値がない均衡点に達する。残りは軽量クライアントになり、数百万になる可能性がある。
均衡サイズでは、多くのノードはサーバーファームとなり、1つか2つのネットワークノードがLAN経由でファームの残りに供給する。