Tech と Culture

テクノロジーとカルチャー

AI

一つ前のエントリはだいぶ先の未来にしかやってこないことだけども、AIに関する怖さは結構目前にまで来てるんじゃないかと自分は感じてる。

最近のAIは、ある程度会話が成立するところまで来てる。まあうまく人間っぽく議論をそらすことができてるという見方もあるけど。 twitterで短い取り留めのない会話ができる(AIだとばれない)ぐらいまではもう近いんじゃないかって感じる時がある。

もし、それぐらいのレベルに来たら。。。

多くの人にAIで軽く話しかけて相互フォローまで持っていく。 気がつかないうちに、各人に100人ぐらいのAIが偽装したフォロワーができる。 都知事選の時に「2年前ぐらいにレストランで小池⚪︎⚪︎子と偶然遭遇したんだけど、すごいヒステリックに店員怒鳴りつけてた」みたいな嘘を一人のAIフォロワーつぶやかせる。 別のAIフォロワーが「実は私も***でたまたま遭遇したんだけど、こんなことされた。。。」と呟く。

自分が時々会話するフォロワーさんのうち複数が悪い評判の立つような実像をつぶやいていたら、やっぱり裏ではそうなのかと多くの人が思うんじゃないかな。

これで、得票率にある程度影響は与えられるんじゃないか。ここまでダイレクトだと何かしらの違和感を察知されるかもしれないけど、もっとうまいやり方はいくらでもありそうな気がする。

これぐらいの危なさはもう目前まで来てると思うし、もしかしたらもうやっているのかもしれない。。。

AI, Blockchain, Cyber Physical System....

今日は、とりとめのない雑記。

TheDAOからのEtherのドレインが始まった時、リアルタイムで開発者Slackを見てた。(もともとSlock.itのslackのinvitationのメールがStephanから来た時になんとなくJoinしただけで、全然中身は見てなかったのだけど、@channelが飛ぶとデスクトップにはNotificationが飛ぶようになってた。)

ちょっと記憶があいまいなんだけど、ある時、@channelで運営っぽい人からの「Emergency! **のプロポーザル出した人、もしくはそれが誰か知っている人は急いで運営に連絡してくれ!」みたいな尋常じゃないテンションの発言が自分のデスクトップに表示された。 最初は何事なんだ?と思って初めてslock.itのslackを追いかけた。「何事なんだ???」とか皆がいっぱい書き込んでたんだけど、誰かが「Etherがドレインしてる!!!」って書き込んでから、ものすごいスピードで書き込みが殺到し始めた。

その時に強烈に印象に残った発言があった。それは運営からの「Ethereum上でコード実行できる人は以下のコードを実行してくれ!皆でDDOS攻撃をして、悪意のあるHackerのコードが実行されるのを遅らせて時間を作ってくれ!」みたいな発言だ。

「さすが誰にも止めれないDapps。こんなことが起こるのか」と、初めてDappsという物の意味を理解した気がした。 仮に、世界中のインターネットからセキュリティに脆弱性のあるコンピュータを探し出して、フルノードのソフトウェアをデプロイするDappsを作ったら、世界中のコンピュータの電源落とさない限り誰にも止められないアプリケーションが動き出してしまうな。。。とDappsの潜在的パワーにちょっと怖くなった。 仮にCyberPhysical Systemが動き出していて、リアルな世界にもアクセスできるようになっていたら相当な影響力だし、コンピュータを自分で作れるところまで行ってたら、もはやどうやっても止めれない。 Skynetの誕生だ。

ちょっと厨二病的か。けど自分は結構怖さを感じてる。

"Blockchain" という言葉

どうも世の中と自分の感覚が合わないな〜と感じるのが、"Blockchain"という言葉が指している範囲についてだ。

Satoshi NakamotoがBitcoinを発明した時にそのアルゴリズムがBlockchainと名付けられた。その後に、Blockchainを変更してマイニング参加者を限定したりするPrivate Blockchainが考案されて、話題になりだした。 なので、 Blockchain(Public blockchain) -> 変形してPrivate Blockchainを考案 って時系列なんだけど、どうも世間では "Blockchain"と言うとPrivate blockchainを指している雰囲気がある。

このブログで、Blockhainと言った場合はPublic blockchainを念頭においている(Private blockchainにも当てはまる時と、当てはまら無い時がある)ので要注意。

Blockchain にできること?

Blockchainがバズワードになっていて、もう完全に???状態だ。。。

訳のわからない言説がまかり通ってるし、発表されてたりする。

特にIoM(Internet of Money)以外の所でのBlockchainに関しては訳が分からなくなっている。IoT絡ませるところなんて特に分かりにくいので狙い目だ。。。 Blockchainで何も考えずにTrustlessな取引ができるのはあくまでもBlockchain内部の価値の交換だけだ。それ以外の応用においては現実とのリンクにTrustが必要になる。

例えばビットコイン払いの自動販売機があったとする(実際には海外にはあるらしい)。自動販売機についているQRコードスマホのカメラで撮影してビットコインを送るとコーラが出てくるかもしれない。そんな自動販売機がいっぱいあったとする。詐欺師が人通りの多い街中にコーラの入っていない自動販売機を置いたらどうなる?コーラは出てこず、ビットコインはどんどん詐欺師のアカウントに振り込まれる。 (まあこれは現在の通貨でも同じなんだけど、あえてそんな費用のかかることしないだろうという前提がある。それは別にBlockchainとは何も関係ない。)

現実との境目にTrustは必要だ。Suicaのように誰でも簡単に電子マネーを支払わせることのできないシステムとは違うのだ。ビットコインオープンソースでTrustlessだからこそ(誰でも自由にシステムを組める)、現実との境目にしっかりTrustが必要になる。 物の所有権の移転だってそうだ。そもそもNick Szaboの最初の提案の車の所有権の移転でも、自動車のダッシュボードに埋め込まれた装置をTrustしている。自動車メーカーをTrustする必要があるのだ。ハードウェアが出てきた瞬間にその境目は”必ず”発生する。ハードウェアをオープンソースにしたところで、その通りに作っているとは限らない。

ハードウェアが絡まないもの(IoTじゃないもの)であってもBlockchainに内蔵された価値以外のものを載せる時にしっかりしたTrustが必要になるものは多い。そもそもビットコインだってデバイスにある秘密鍵とリンクしているだけでそれを別人が使えればリンクは切れる。仮に絶対に本人だということが必要なクリティカルなシステムをBlockchainで作ろうと思えば、本人認証にかなり強力な仕組みがいる。Blockchain使えばセキュリティーが上がりますとか簡単に言えるものじゃない。 もちろん、Trustの必要性を少しでも下げるという意図のものは充分検討に値する。シチュエーションによってはそれが非常に有効なものもあると思ってる。けど、クリティカルな部分に使う場合は相当な検討が必要だ。

なんでこんなことを言っているのか、、、 だいぶ前から仮想通貨界隈は詐欺コインとか横行していたけど、自分はお金が数十倍になるとか欲がくらんだ方にも責任があると感じるので全然気にしていない。 けど、最近は、”Blockchainを使ってIoTがセキュアになる"とか"Blockchainでシステムがセキュアに"とかの例で破綻している話を公的な場所で平然とする"テックサイド"の人間が出てきてる。何が目的なのかよく分からない。情報弱者からお金を取るお金儲けなのか、名前売りたいのか、補助金が欲しいのか。。。よく分からないけど、"テックサイド"の人間がやってるのが個人的にちょっといやな感じ。夢を語らないといけないシチュエーションもあると思うけど、テックサイドなのに明らかに真面目に検討してないだろうと感じる話がある。

今の状況では、Blockchainに関しては夢物語を語る人より、"何ができないのか"もきちんと説明できる人の話を聞きましょう。本気で取り組んでる人達は皆、課題を持ってメリットデメリットを考えてる。

CryptoEconomicsとTheDAO

Ethereum上のDecentralized ApplicationのTheDAOがHackingにやられた。 btcnews.jp この件そのものについてはネット上に色々あるし、正直どうでもいい。

TheDAOについてはCryptoEconomicsに関する自分の疑問や懸念点をもっとはっきり理解できる実験になるのではないかと注目していた。その項目は、 (1) CryptoEconomicsが作る世界は、「不当な支配力を持つ組織から個人を解放した世界」ではなく、「評判が大きな影響力を持つポピュリズムの世界」ではないか? そうならない対策はあるのか? (2) Decentralizedと呼べる状態の定義は何?

(2)については今回は考えずに(1)について色々考えてる。

BitcoinでTrustlessとよく言われるけど、これはTrustが無くなったという訳ではなく、Trustの形が変わったと言った方が正しい。神様サーバの無いP2Pネットワーク上で、いちentityやいち個人が恣意的にコントロールができない価値の送受信を行えるシステムだ。しかし、ユーザは何も信用していないという訳ではない。bitcoindのソフトウェアにバックドアが無いことを信用しているし、自分がインストールしたbitcoindが純正であることを信用している。それをどうやって信用しているかというと、githubという会社の評判、bitcoindがオープンソースでバザール開発であることと開発者の評判、などなど。信用の仕方が分散的なのでTrustlessになっている。 もともと「国家よりもMathematicsやソースコードを信じる」というようなスタンスでアナーキスト中心に広がっていったのがBitcoinだ。本当の初期は「ユーザ=開発者とその知人」だったと思うのでほぼその通りだったのだろうけど、Geekに広がり始めた時からbitcoindのコード自体は読んでない人の方が多分増えている。それでもGeekはWhitePaperは理解できるだろうし、githubに慣れていれば何となく情報の真偽は分かる。けど、今やBitcoinはマスアダプション寸前に来てる。マスアダプションとなると「国家よりもMathematicsやソースコードを信じる」などと言っても、WhitePaper読めない人の方が多いし、ソースコード読める人なんて少数の特殊技能者だ。結局、メディアなんかの評判から信用できる人やWebを探して使うって人の方が圧倒的多数だろう。

TheDAOが始まった時に、一応プログラムが読める自分ですらコードを読んでない。全てのプログラムを読むなんて時間はないのだ。。。なので全貌を知っている訳ではないので自分が知ってると思っている範囲で書いている。

元々、資本主義は持っている資本のサイズが大きい方が圧倒的に有利なゲームだ。1億持っている人と10億持っている人では、ゲームの有利さが1:10ではない(もちろん優秀だったらひっくり返せるんだろうけど)。 シリコンバレーの有望ベンチャー企業ベンチャーキャピタルへの出資は全ての人に門戸が開いている訳ではなく、大きな資本を持っていて売り先を持っているぐらい影響力がある人達が投資する。会社は資本の分散は避けたいのでむやみやたらに株主を増やしたりしない。

TheDAOはソフトウェアコードでVCを自動化した。ソフトウェアなので小口を大量に集めても運営上問題ないし、行動自体もコードに従うので、1:10の出資であれば権利も厳密に1:10だ。これは本当に画期的なことでゲームのルール自体がフェアに近づく。だからこそうまくいったら既成の権威に潰されるんじゃないかと思ってたんだけど、残念ながらそこまでも行かなかった。。。 (TheDAOにはバグがなかったとしても色々無理な部分があると思ってるけど、このエントリでは無視してる)

Ethereumは「不当に大きな権利を持つEntityから個人同士の世界へ」を掲げていたので、このような仕組みが広がればより良い世界へ向かうような気もする。 が最近自分が感じていたのはちょっと違う。Bitcoinのところで述べたように、このような社会システムが様々なところに適用されたとしたら、殆どの人はその仕組みを理解できず、専門家の意見が割れたとしても判断する方法が無く、結局能力が高いと言われている人の言葉に完全依存してしまうんじゃないかと感じる。 まあ個人ベースの世界に移行するのだからそれで良いような気もするけど、多分、CryptoEconomic界の評判をコントロールするメディアやビジネスがたくさんできて、今よりももっとひどいポピュリズムの世界になっちゃうんじゃないかという予感が最近はかなり強い。

そしてそれに対する対策は今のところ思いついてない。。。

追記: どうも書き方が良くなくてうまく伝わってないようだ。 (1)資本主義や民主主義は理念と実際の社会にずれがある。 (2)それとは別に資本主義や民主主義に基本的欠点がある (3)ソフトウェア実装で(1)のズレをなくすと(2)の本質的欠点が強烈に浮かび上がりそう

なんとなく雑記

FBから転載した。

個人的な感覚は、ブロックチェーンはコンピュータサイエンスじゃなくて工学。 エッセンスを抽象化して、アプリケーションを考えたりすることはできるけど、安全性考える時は工学的なアプローチが必須。

VitalikのFinalityの議論があったけど、そういうの以前にソフトウェアが動いている半導体自体が設計・製造メーカーから確率的な信頼性で出荷されてる。コンピューターサイエンス的な思考だと確率的な動作は違和感あるけど、工学的な思考だと当たり前のことに感じる。

バイスの出荷基準はFIT値で保証したりしてる。チップ内部で一方向にしか電流流れない配線はエレクトロマイグレーションで劣化していくし、ゲート電圧なんて少し高く与えると簡単に壊れる。 配線についてはテストデバイスを作って実験しまくってどれぐらい大丈夫か測定して上限を示し、チップレイアウトを設計している人たちがその値を守るように設計する。チップ全体でそれが守られているかチェックするソフトウェアもある。

新しいプロセスができる時に、トランジスタのプロファイル(不純物濃度をどうするとか)はエンジニアが物理制約の中で自由に決めれる。けど変なバランスで設計するとあっという間に壊れるので、なるべく面積小さく速度早く要求される年月で壊れないように設計される。それも全部統計的なデータ取って、ある確率で大丈夫なように設計してる。 いろんな設計レイヤーで徹底的な実験や研究をしてすごく高い信頼性のLSIが出荷されている。それでも100%保証じゃない。(アレニウスの式とか色々その分野だけで一つ教科書ができるぐらい研究されている) 100%保証じゃなくてもマーケットのニーズがあれば売れていく。

昔々、不揮発メモリのニーズはすごく強かったが実現してなかった。ある物理現象で実現できることを天才が示したけど、その現象使うと劣化しやすかった。それでもマーケットニーズが強かったので書き換え回数に制限をつけて出荷してる。

なので、ブロックチェーンのファイナリティが決定論的ではなくいつまで経っても100%にならないというのは"工学"的には特に問題なことじゃない(コンピュータサイエンス的には気持ち悪いかもしれないけど、むしろその方が狭い分野からの見方)。そもそもソフトウェアが動いている半導体の動作が確率に支配されてるんだよね。

誰かが最初に飛行機飛ばした時に、何故空を飛ぶのか良く分からなかったけど、後から色んな人が飛行機を作ったと思う。けど、人を乗せて旅客機事業をやるとなったら色んな安全性の議論は起きたはず。多分ブロックチェーンは今そのフェーズ(飛行機と違って、本当は空飛んでないんじゃないかって説もあるのでさらに難しい)。 まあけど、間違った理屈で「飛行機なんか詐欺だ」というのもすごく変。

ビットコインのブロックチェーンはブロックタイムが10分だけど、世界中にproof of workのパズルの解答を広めるのにおおよそ12秒かかるらしく、ブロックタイムをどんどん縮めていくと多分あるところからフォークして収束しなくなる確率がどんどん上がる。

その他にもcryptcurrencyはinternet of moneyなのでinternetがきちんと動くことに当然依存している。

ここら辺の安全性はコンピュータサイエンスじゃなくて"工学"なんだよ。コンピューターサイエンス的な議論も一杯必要だけど最終的に議論として残るのはコンピューターサイエンス的なところじゃなくて、実証論的な工学的な信頼性。だからビットコインは数学屋の世界からじゃなくてオープンソースの世界から生まれてきた。(もちろんコンピューターサイエンスは実証論てきな部分の追い込みには役に立つと思うけど)

マーケットニーズがあるなら、今ある部品を使ってどんどん新しいものを作ればいい。エンジニアなんだから。 それと同時に、単なる一部の人の投機ゲームから、産業の基盤にしようとするなら、どんなリスクがあるのかきちんと調べ上げて説明しないと受け入れられない。完全じゃなかったとしても、半導体みたいに調べ上げてマーケットが納得する仕様上の制約を作ればいいだけ。

どうも仮想通貨やブロックチェーンは、

・なんでもかんでも肯定してリスク評価せずに「理解できない人は遅れている」という人や

・なんでもかんでも否定して、「あんなものは使えない」という人

が多くて、本当に変な感じだ。

もうそういうフェーズは脱して、産業基盤に使えるものをエンジニアが作り出すフェーズに入りたいものですね。

翻訳:Satoshi Clientブロック交換

次はこれ。

https://en.bitcoin.it/wiki/Satoshi_Client_Block_Exchange

大事な部分の英語が分からない。。。

誰か偉い人教えて。

Satoshi Clientブロック交換
 
1 概要
2 Inventoryメッセージ
3 ブロックバッチング
4 バッチ継続メカニズム
5 ストールリカバリ
6 ロングオーファンチェイン
7 Flood Limit効果
8 パフォーマンス
9 脚注
 
1 概要
この記事はノード間でどのようにブロックの交換が行われるかを説明します。 どのようにブロックがバリデートされるかについても詳しい情報はProtocol rulesを参照してください。
最初のコネクションで、コネクションが内向きでない場合、言い換えるとコネクションがローカルノードから始まっている場合、versionメッセージがキューイングされ、即座に送信されます。リモートのノードがversionメッセージを受信した時に、リモートのノードは自分のversionメッセージを返信します。
ノードが”version”メッセージを受信した時に、もし下記のいずれかの条件が成り立つ時、”getblocks”リクエストをリモートノードに送ります。
 1 ノードは最初のgetblocksリクエストを他のいかなるノードにも送っていない
 2 もしくは、これが唯一のアクティブなノードコネクションである。おそらくノードはこのコネクション以前にはゼロコネクションであり、おそらく長い間接続できていないと思われる。そこでキャッチアップのためにブロックを要求する。
getblocksメッセージは、リクエストしたノードがすでに所有している複数のブロックハッシュを含み、リモートノードがノード間の最後の共通するブロックを見つけ出すのを助けます。ハッシュのリストは最新のブロックから10そして次にべき上倍にジェネシスブロックに届くまで戻っていきます。両方のノードはジェネシスブロックはハードコードされているため、少なくともそこから始めることができることは保証されています。もしなんらかの理由でそのブロックが一致しない場合、ブロックは一つも交換されません。
 
2 Inventoryメッセージ
ノードはgetblocksリクエストを受信しても返信において完全なブロックを実際に送信するわけではないことに注意しましょう。ノードはリクエストに相当するブロック群のハッシュのみを含んでいる”inv”メッセージを送ります。それによって、リモートノードが持っていない(しかしまだリモートノードが完全なブロックを望んでいるとは仮定しないように)実際のブロックを送ることを検証します。
ローカルのノードが”inv”メッセージを受信した時、”getdata”メッセージによって実際のブロックをリクエストします。下記を参照。
しかし、最初にローカルノードによって送られた”getblocks”リクエストへのレスポンスとしてどのようにリモートノードが”inv”メッセージを送るのか、詳細を見てみましょう。リモートノードはpFrom->PushInventoryをコールします。それはブロックをリクエストしたノード(このウォークスルー中ではローカルノードです)を表しているCNodeインスタンスメソッドです。そして、PushInventoryはCNodeの変数であるvInventoryToSendへブロックハッシュを追加します。main.cpp内のSendMessages関数はvInentoryToSendの中からinvのアイテムを取り出し、vInvの変数に追加していきます。それによって実際の送信の準備ができます。変数を分離させている理由は幾つかのInventoryアイテムは(現在はトランザクションのみです)リモートノードに対して”trickled"されています。それは即座に送信される訳ではないことを意味します。vInv変数が1000エントリ満たされた時、メッセージはこれらの1000個のエントリと共にキューイングされ、ループが続きます。最後に、残ったエントリは最後の”inv”メッセージで送信されます。
ローカルノードが”inv”メッセージを受け取った時、”getdata”メッセージで実際のブロックをリクエストします。正確に言うと、ノードはpfrom->AskForをブロックをリクエストするためにコールし、そのメソッドはmapAskForの中にあるブロックのリクエストをキューイングし、多目的なSendMessage()がmapから1000エントリのバッチの”getdata”リクエストを送信します。
 

The code attempts to limit redundant requests to every 2 minutes for the same block by using a map called mapAlreadyAskedFor to delay the message if necessary.[6]

(コードはmapAlreadyAskedForをコールし必要ならばメッセージを遅らせることで2分毎に冗長に同じブロックをリクエストすることを制限しようとします????)
 
3 ブロックバッチング
“getblocks”リクエストに対応するノードは要求者への応答に対して500ブロックの制限をつけようとします。
しかしながら変わったtwistがあります。もし要求者が、メインのブランチから分岐しているように見える時、ノードは要求者のバッドチェーン、最後の共通ブロックから要求者が持っている最後のブロック(間違ったメインブランチ)、を完全に置き換えることができるように必要な多数のブロックを送ります。これは500個のメインブランチアップデートをキャッチアップするためのものに追加でおこなわれます。
加えて、送信のためにキューイングされるブロックの数に制限があるだけでなく、bitcoindはキューイングされるブロックのサイズにも制限があることに注意しましょう。これは現在のところ、送信バッファサイズ、10MB、の半分に制限されており、5MBとなっています(?)。
 
4 バッチ継続メカニズム
ノードがブロックinventoryのバッチの送信を終了した時、バッチの最後のブロックのハッシュを記録します。
 
When the node receives a request for that full block, it realizes the remove node is done with the current batch and directly queues a special "inv" message (bypassing the normal SendMessage mechanism) with one block hash entry containing the latest block hash.[12] When the remote node receives that "inv" message, it will see that it does not have that block and it it will ask for that block as described above.
 
(ノードが完全なブロックのリクエストを受信した時、現在のバッチに合わせてノードの削除が行われ最新のブロックハッシュを含む一つのブロックハッシュエントリを持った特別な”inv”メッセージ(通常のSendMessageメカニズムをバイパスして)を直接キューイングします(?)。リモートのノードがそのような”inv”メッセージを受信した時に
?????)
 
 
しかしながら、ブロックを受信して処理する時に、一つ前のブロックを持っていないことに気がつきます。そこで、最後のブロックをオーファンブロックだと記録し、ギャップを埋めるためにオーファンブロックの直前のブロックから始まるブロックをアップデートするリクエストを送ります。その結果”getblocks”リクエストを出し、全体のバッチ処理が繰り返されます。
しかしながら、twistがあります。次のバッチが終了した時に、ブロックを送信しているリモートノードは”inv”を通常は最新のブロックハッシュとともに送信し、ローカルノードはこのブロックはオーファンブロックマップの中にすでに持っていると気がつき、ブロックのリクエストをスキップし、直接ブロックのアップデートを依頼します。
 
This process will continue until the last block prior to the latest block is received. At the end of processing that block, it will notice there is an orphan that pointed to this block and will process the orphan block, (and any other orphans, recursively) thus completing the entire process.[15]
 
 
5 ストールリカバリ
もしバッチング処理がなんらかの理由で中断した場合、例えばリモートノードが"バッチ継続メカニズム”を失敗したり、接続切れが起きたりしたとき、処理を再スタートする方法があります。新しいブロックが発見されアドバタイズされる時に、”inv”の中に新しいブロックがあると気がついたいかなるノードもメッセージを送ったノードに対して”getblock”アップデートをリクエストするトリガーをかけます。それはノードが現在持っているブロックチェーンのいかなる場所からでもブロックを送信させることができます。
 
6 長いオーファンチェイン
多数のテストにおいて、ブロックチェーンの同期が非常に遅れているノードを発見することが頻繁に起きる(十回に一回以上)ということが分かっています。おそらくそれらのノードはキャッチアップの最中です。きちんと接続されたノードは少なくとも8以上のコネクションをもっていますので、新しいノードが他のキャッチアップ中のノードに接続することはしばしば起こります。
キャッチアップ中のノードは自身がメインチェーンとして受け入れたブロックを他の全てのノードに対してアドバタイズします。あるチェックポイント以前に古いブロックをアドバタイズするのを防ぐコードが存在していますが、そのコードはもしブロック高さがリモートノードの現在の最大のブロック高さマイナス2000を超えていればリモートノードに対してアドバタイズするという条項を持っています。これは、両者が古いブロックを処理中であっても、ノードは他のノードのキャッチアップを助けることを許しているということです。
 
These advertisements cause the local node to request those blocks from the remote node, which could be blocks well into the future compared to what has been processed locally.
 
(これらのアドバタイズにより、ローカルノードはこれらのブロックをリモートノードにリクエストします。….????  。)
 
ブロックがリクエストされる方法により、リモートノードは応答として、大きなブロックのバッチを送信します。そして最後までローカルノードに対して続けて送信します。ローカルノードがメインチェーンのブロックを同時にダウンロードしていることが起こり得ることに注意しましょう。その処理は次第にオーファンチェインをキャッチアップし、非常に、非常に長い再評価のオペレーションを生み出し、全てのオーファンブロックとつながります。
一万を超える長さのオーファンチェインでは、一時間を超える処理になることもあり得ます。
それゆえ、二つのキャッチアップ中のノードがお互いにコミュニケーションを取っている時に、Suboptimalなインタラクションに陥ることがあり得ます。特に、片側がひじょうに遅れていて、もう一方が相手よりだいぶ進んでいる場合に。
 
7 Flood Limit Effects
上記のバッチングメカニズムをもってしても、ブロックの交換の際にリモートノードがローカルの受信バッファをオーバーフローさせることが起き得ます。
例えば、リモートノードがキャッチアップ中の時、ある条件では(上記[17]参照)ローカルノードに対して全てのブロックをアドバタイズします。ローカルノードはそれぞれのブロックを即座にリクエストするでしょう。ローカルノードがこれらのブロックを多すぎるリクエストすることを止める手立てはありません。リモートノードはリクエストされたブロックを全て送るでしょう。この状況下では、リモートノードがローカルノードが処理が終わる前にあまりにたくさんのブロックを送ることを防ぐ手立てはありません。
ローカル受信バッファはいっぱいになることがあり得ます。ローカルノードが受信バッファが一杯になったことに木がついた時、ノードのコネクションを切断します。もし、fDisconnectフラグが建てられた場合、一度バッファは空にされソケットは閉じられます。
 
8 パフォーマンス
2011年9月1日現在、circa 2005のサーバークラスのコンピュータで、コムキャストケーブルインターネットに接続したUbuntuにおいて、ブロックチェーンのダウンロード処理に10時間以上かかります。
 

While it is debatable what the bottleneck is early in the download process, it is clear from the processing of recent blocks that the network is not the bottleneck for all but the slowest internet connections.

(??????????)
 
ブロックは平均してダウンロードするのに一秒以上かかります。しかしながら、2011年の8月で、平均的なブロックサイズは24KBです。24Kバイトをダウンロードするのに1秒はかかりません。
 
Also, testing reveals very large queues of blocks being processed per message loop, which is not what you would expect if the thread was pulling them out of the queue as they arrive on the sockets.
(???????)
 
ネットワークパフォーマンスが問題であると信じる、幾つかの”false signal”が存在します。
最初のfalse signalは、2011年8月において、最初の60%〜70%のダウンロードされたブロックはひじょうに小さいです。最近の平均ブロックサイズは約100倍も大きい! そのため、突如として、ブロックレートは早い状態から非常に遅い状態になります。何か問題が起きたかのようです。実際のところ、KB単位のブロック処理のレートを計測すると、レートはほぼ定数のままであることが分かります。
 
他のfalse signalは、メッセージキューはノード毎に一つづつ完了するように処理されるという事実に関連します。このことによって、非常に大きな他のノードからのメッセージのバックアップが作成されます。
So, a long period of increasing blocks may freeze for long periods as other nodes are serviced.
(そのため、他のノードがサービスされている時に増加するブロックの時間に合わせて長い時間フリーズします。?)
 
 ブロックのダウンロードが典型的にはただ一つのリモートノードから行われ(少なくともマイナーか他のリレーノードかダウンロードノードが新しいブロックをアドバタイズしてプロセスを止めるまで)、そのため全ての処理が一つのノードで行われることを考えましょう。
また、上記のオーファン効果がオーファンチェインに接続するまで何の証拠もなしに過剰なブロック処理に導く可能性もあります。また、突如として反応の遅いノードにつながることもありえます。おそらくブロックを処理しているか、遅いマシンまたは遅いコネクションであることによります。
上記の全てがブロックダウンロードのプロセスにおいて、大きなジッタに貢献しえます。そしてそれは、一定のダウンロードレートよりもユーザ体験をフラストレーションが多いものにします。