Scalability FAQ

提供: tezos-wiki
移動先: 案内検索

ブロックサイズの拡大などの「レベル1」ソリューションや、提案されているLightningネットワークなどの「レベル2」ソリューションなど、Bitcoinのスケーリングに関するよくある質問と懸案事項への回答。

目次

背景[編集]

Bitcoinが現在どのように動作しているか(スケーリングに関連する)、そしてスケーリングの議論に関連する技術用語に関する質問。

ブロックサイズ制限の歴史は?[編集]

注:現在、Bitcoin Coreと呼ばれるソフトウェアは以前は単にBitcoinと呼ばれていました。<ref> Bitcoin Core 0.9.0リリースノート、Bitcoin.org、2014年3月19日</ ref> Bitcoinシステムとの混乱を避けるため、Bitcoin Core名を使用します。

Bitcoin Coreは当初、明示的なブロックサイズの制限なしにリリースされました。しかし、コードはネットワークメッセージを最大32 MiBに制限し、ブロックサイズの有効上限を設定しました。<ref> [1]、< code> src / main.h:17 </ code> </ ref>

2010年7月15日ごろ、中本哲はBitcoin Coreのマイニングコードを変更し、990,000バイト以上のブロックを作成しないようにしました。[ref> Bitcoin Core commit a30b56e 、中本聡、2010年7月15日</ ref>

2010年9月7日の2ヶ月後、ブロックの高さが79,400を超えると、1,000,000バイト(1メガバイト)を超えるブロックを拒否するBitcoin Coreのコンセンサスルールが変更されました<ref> 8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin Coreコミット8c9479c、中本聡、2010年9月7日</ ref>(ブロック79,400は、後で2010年9月12日に制作されました)<ref> [https://www.biteasy.com/blockchain/blocks/000000000021d821ec06be7173f413690bc5c4bc648dfa70b3b6763236f055b7ブロック高さ79400、2010年9月12日</ ref>)

7月も9月のコミットメッセージも限界の理由を説明していませんが、フォークを防ぐための慎重な試みは中本がそれを緊急とはみなさなかったことを示しているかもしれません。

Nakamotoのその後の声明は、後でブロックサイズを上げることを支持した<ref> [2]、中本聡、2010年10月3日< / ref>と述べたが、彼は公式に決勝日や条件のセットを公表したことはなかった。

2010年夏、中本の声明によると、Bitcoinは1メガバイトをはるかに超えるサイズをブロックすることができると考えていた。たとえば、2010年8月5日に、彼は「あなたが必要とするマイクロペイメントのサイズは最終的に実用的なものになるだろう」と書いている.5年または10年後には、帯域幅とストレージは些細なものだと思う。より実用的になりました...クライアント専用モードを実装し、ネットワークノードの数をプロフェッショナルなサーバーファームに統合すると、より実用的になります」#msg6306ネットワークノードの数は、より少ない数のプロフェッショナルなサーバーファームに統合されます </ ref>。

これらのステートメントは、1メガバイトの制限の意図された目的は、Bitcoinノードをパーソナルコンピュータやコンシューマグレードのインターネット接続に実用的なほど十分に低い帯域幅とストレージ要件に保つことではなく、トランザクション能力の要求に対応できます。

しかし、中本の最後のパブリックメッセージの1つに、彼は次のように書いています。「Bitcoinのユーザーは、チェーンのサイズを制限することについて、ますます幅広くなり、多くのユーザーや小型デバイスにとって簡単です」と書いています。<ref> [https://bitcointalk.org/ index.php?topic = 1790.msg28917#msg28917 BitDNSとGeneralizing Bitcoin、中村聡、2010年12月10日</ ref>この文は、中小企業がブロックサイズの制限の価値を認識しており、 Bitcoinのユーザーは将来的に検討する必要があるだろうという問題を提起しました.Nakamotoが知っていたかもしれない未来は彼を含まないでしょう。

このトランザクション/秒(TPS)制限は何ですか?[編集]

現在のブロックサイズの上限は1,000,000バイト(1メガバイト)です<ref> MAX_BLOCK_SIZE </ code> 、2015年7月2日に検索されました。(ブロックヘッダーなど)そのスペースの少量はトランザクションを格納するために利用できませんが、<ref> -blocks Block serialization description、Bitcoin.org開発者リファレンス</ ref>

Bitcoinトランザクションは、単一シグネチャ入力または複数シグネチャ入力を使用しているかどうか、および複数の入力と出力があるかどうかなど、複数の要因によってサイズが異なります。

Bitcoinが処理できるトランザクション/秒(TPS)の数を計算する簡単な方法は、ブロックサイズ限界をトランザクションの予想平均サイズで除算し、ブロック間の平均秒数(600)で割ることです。たとえば、平均トランザクションが250バイトであると仮定すると、

<6.6 TPS = 1,000,000 / 250/600 </ pre>

2015年のBitcoinは現在のトランザクションの平均サイズで約3TPSを処理できるという一般的な合意があるようです。<ref> [3]、Mike Hearn、2015年5月8日<ref name = "maxwell_not_proposing"> [https://www.reddit.com/r/Bitcoin/comments/39yaod/bitcoinorg_position_on_hard_forks/cs7qz5c "誰も3TPSを永遠に提案する者はいません"、Gregory Maxwell、2015年6月15日</ ref>

両方の古い推定値<ref> Scalability、Bitcoin Wiki、7月7日検索 2015 </ ref>と新しい見積もり[1] 現在のBitcoinコンセンサスルールで7TPSでの理論最大値 (1MBのブロックサイズ制限を含む)。

スケーリング式O(1)、O(n)、O(n 2 </ sup>)などのdevsの意味は何ですか?[編集]

Big O notationは、コンピュータ科学者がシステムのスケールがどれくらいうまくいくのかを記述するために使用する略語です。このような記述は、潜在的な問題を予測し、潜在的な解決策を評価するのに役立つような概算です。彼らは通常、すべての変数を完全に取得することは期待されていません。

  • 'O(1)' は、システムの大きさに関係なく、ほぼ同じ特性を持つシステムを意味します。
  • 'O(n)' は、システムが線形に拡大することを意味します。物の数を2倍にすると(ユーザー、トランザクションなど)、作業量が倍増します。
  • 'O(n 2 </ sup>)' は、システムが二次的にスケールすることを意味します:四倍(4x)の作業量を倍加(2x)します。 O(n ^ 2)は便利な上付き文字のない場所です。
  • 追加の例は、Wikipediaの記事にあります。

以下のサブセクションでは、Bigcoinトランザクションボリュームに大きなO表記が適用されているケースを示します。

O(1)ブロック伝播[編集]

Bitcoin Coreは現在未確認のトランザクションをリレーし、その後、同じトランザクションの多くを含むブロックをリレーします。この冗長リレーを除去することで、鉱夫が大規模なブロックをアクティブネットワークノードに非常に素早く伝播させることができ、ピーク帯域幅の必要性を大幅に削減できます。現在、ほとんどの鉱夫は株式よりも約25倍効率的なネットワークを使用しています。<ref name = "block_relay_net"> Matt Coralloのブロックリレーネットワーク Bitcoin Core <ref> [https: / gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#i-know-that-you-know IBLT設計ドキュメント]、Gavin Andresen、2014年8月11日</ ref>、現在のブロックのO(1)ブロック伝播とほぼ同じくらい効果的ですサイズ。


分権化レベルが一定に保たれているO(n 2 </ sup>)ネットワークの合計検証リソース要件[編集]

thumb | right | O(n 2 </ sup>)スケーリングの可視化

完全ノードあたりの検証作業はO(n)で単純に増加しますが、すべてのノードの検証作業はO(n 2 </ sup>)だけ増加し、分散は一定に保たれます。 1つのノードでは、2倍のユーザー数のトランザクションを処理するのに2倍のリソースが必要ですが、すべてのノードでは、フルノードの数が増えたと仮定して2倍のトランザクションを処理するために4倍のリソースユーザー数に比例して

各オンチェーンBitcoinトランザクションは、各完全ノードによって処理される必要があります。ある割合のユーザーがフルノード(「n」)を実行し、各ユーザーが平均で一定数のトランザクションを作成すると仮定すると、ネットワークの総リソース要件は<code> n 2 </ sup> = n * n </ code>。つまり、これは、チェーン上のすべてのトランザクションを維持するための総コストが、ユーザー数が倍増するたびに4倍になることを意味します。 .html総システムコスト]、Dr. Adam Back、2015年6月28日</ ref>たとえば、

  • ネットワークが100人のユーザーと2つのノード(2%の比率)で始まるとします。
  • ネットワークはユーザー数で200を倍増します。ノード数も4倍になります(分散型低信頼セキュリティの2%の比率を維持します)。しかし、ユーザー数が2倍になるということは、トランザクション数の2倍を意味し、各ノードは「すべての」トランザクションを処理する必要があるため、各ノードは現在その帯域幅とCPUで2倍の処理を行います。ノード数を2倍にし、ノードあたりの作業量を2倍にすると、合計作業時間は4倍になります。
  • ネットワークは再び倍増しました。400人のユーザー、8ノード(合計の2%)、ノードあたりの元のワークロードの4倍の合計で、元の16倍の集約作業を実現します。
  • 別の倍増:800人のユーザー、16ノード(まだ2%)、ノードあたりの元のワークロードの8倍の合計で、元の64時間の集約作業。
  • もう1つの倍増:オリジナルの16倍の1600ユーザー - 32ノード(まだ2%)、ノードあたりの元のワークロードの16倍。ノードによって行われた総作業の総量は、元々の作業の256倍です。
批判[編集]

全体的な検証リソースの要求に重点を置いているのは、完全なノードのサポートベースの成長を難読化していると主張しているため、一部の人は誤解を招くことを示唆しています。 O(n)では、個々の完全ノードによって行われる検証リソースの努力が増加し、評論家は、これがスケーリングに関して唯一の適切な事実であると言います。一部の批評家は、O(n 2 </ sup>)ネットワークの検証リソース要件の主張は、ネットワークの規模に応じて分散を一定に保つ必要があり、これがBitcoinの基本原理ではないことを前提としています。

オンチェーン取引とオフチェーン取引の違いは何ですか?[編集]

オンチェーンBitcoinトランザクションは、Bitcoinブロックチェーンに表示されるトランザクションです。オフ・チェーン・トランザクションは、ブロック・チェーンにトランザクションを入れずにビットコインの所有権を移転するものです。

一般的で提案されたオフチェーン取引には、

  • 'エクスチェンジ取引:' 'あなたがビットコインを購入または販売すると、交換はブロックチェーンにデータを入れずにデータベースの所有権を追跡します。ビットコインを入金または引き出した場合にのみ、取引がブロックチェーンに表示されます。
  • 'Webウォレット内部支払い:' 多くのWebウォレットは、サービスのユーザーがオフチェーン支払いを使用して同じサービスの他のユーザーに支払うことを許可します。たとえば、1人のCoinbaseユーザが別のCoinbaseユーザに支払う場合です。
  • 'チップサービス:ChangeTipのような今日のほとんどのチップサービスは、預金と引き出しを除くすべてのオフチェーン取引を使用しています。[ref] ChangeTip fees、 2015年7月3日に検索</ ref>
  • '支払いチャネル:' チャネルは1つのオンチェーントランザクションを使用して開始され、2回目のオンチェーントランザクションを使用して終了します。[ref] Micropayment channels、Bitcoin.org開発者ガイド</ ref>間には、単一のsatoshi(ビットコインの1/10000000000)のような小さなオフチェーントランザクションは本質的に無制限です。支払いチャネルには、todayと提案されたハブアンドスポークチャネルとより高度なLightningネットワーク

今日のビットコイン建ての支払いの約90%から99%は、オフ・チェーンで行われています。<ref> [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html純粋なオフ・チェーン2015年6月19日のアダム・バック博士(Dr. Adam Back)は、層2の弱い形である[

手数料市場とは何ですか?[編集]

Bitcoinトランザクションを作成すると、取引手数料を支払うことができます。あなたのソフトウェアが柔軟であれば、無償(フリー・トランザクション)からトランザクションの価値の100%(費用対費用)まで何でも支払うことができます。この手数料はチップに匹敵します。それが高いほど、取引を次のブロックに組み込むインセンティブが大きくなります。

鉱夫がブロックを組み立てるときは、自由に任意の取引を含めることができます。彼らは通常、最大ブロックサイズまでできるだけ多くを含んでおり、データの1キロバイトあたり最も多くの料金を支払うトランザクションに優先順位を付けます。<ref name = "fee_pri"> = 95837.0手数料優先順位付けパッチ、Gavin Andresen、2012年7月26日</ ref>これは、より低額の取引の前に高額取引を確認します。ブロックが定期的に満杯になると、手数料が掛からないユーザーは、トランザクションが確認されるまでに長い時間と長い時間を待たなければなりません。現時点では、より高い手数料を支払う取引が、低い手数料を支払う取引よりも大幅に早く確認される場合、需要主導の手数料市場が発生する可能性があります。<ref name = "todd_coinwallet"> [https://gist.github.com/petertodd/ 8e87c782bdf342ef18fb CoinWallet.eu tx-floodストレステストに関するコメント、Peter Todd、2015年6月22日</ ref> [1]

競争の激しい市場では、価格は需要と供給によってもたらされ、新興均衡価格は漸近的に限界費用に近づく。しかし、Bitcoinの現在のバージョンでは、1ブロックあたり1 MBに制限されており、需要調整のみが可能です。自由市場を確立するには、ブロックあたりのトランザクション数を動的に調整できる仕組みが必要です。しかし、このようなメカニズムの設計は簡単ではありません。個々の鉱夫が望むだけ多くのトランザクションを含めることを可能にするだけでは、外部性によって問題があります。<ref name = "exernality"> [Wikipedia、2016年1月26日、外部性の定義] [4] </ ref>を参照してください。 '鉱夫はブロックサイズを決めることができますか?

Bitcoinをスケールする最も効率的な方法は何ですか?[編集]

分散化プロパティ、特に分散型のマイニングと分散型フルノードを削除します。鉱業は膨大な量の電力を無駄に消費し、分散型の元帳を提供し、フルノードは莫大な量の帯域幅とCPU時間を無駄にして鉱山者を正直に保ちません。

代わりにユーザーが信頼できる人物に権限を委譲することに決めた場合、鉱業者を正直に保つことは必要ないでしょう。これは、Visa、MasterCard、PayPal、およびその他の中央決済システムがどのように機能し、ユーザーが信頼しているかであり、[1時間あたりの膨大なトランザクション]にスケーリングすることは特別な困難はありません。非常に効率的です。それは分散されていません。

ハードフォークとは何ですか?また、他のフォークとどう違うのですか?[編集]

Bitcoinの開発では、forkという単語がひどくオーバーロードされています。

  • ハードフォーク:後方互換性のないシステムへの変更。誰もがアップグレードする必要がありますか、物事が間違って行くことができます。
  • ソフトフォーク '大半の鉱夫がそれを強制する限り、後方互換性のあるシステムへの変更。アップグレードしない完全なノードは、セキュリティが低下します。
  • 'チェーンフォーク:' は、ブロックチェーン上に同じ高さのブロックが2つある場合です。これは、典型的には、事故によって週に数回発生しますが、さらに重大な問題を示す可能性もあります。
  • '[5]:' オープンソースプロジェクトのコードを使用して、別のプロジェクトを作成します。
  • 'Git / GitHub fork:開発者がプロ​​ジェクトに貢献する前に、新機能を記述してテストする方法です。

(ソフトウェア関連の他のフォークもありますが、混乱を招く傾向はありません)

ブロックサイズのソフトリミットはいくらですか?[編集]

[2]これらの制限は、他の鉱夫やノードによって鉱夫に課される制限ではなく、鉱夫を助ける設定オプションです合理的なサイズのブロックを生成します。

マイナーは、<code> -blockmaxsize = <size> </ code>を使用してソフトリミットのサイズを変更できます(最大1 MB)

さまざまな時のデフォルトのソフトリミット:

  • '2012年7月:' <code> -blockmaxsize </ code>オプションが作成され、デフォルトの250 KBのソフト制限値に設定されました<ref> Bitcoin Coreコミットc555400、Gavin Andresen、2012年7月12日</ ref>

2013年11月27日、Gavin Andresen氏は、「Bitcoin Core commit ad898b40」と、2013年11月には750KBに上げました。<ref> Bitcoin Core commit ad898b40 2015年6月:2015年6月4日Chris Wheeler、2015年6月: '提案された1MBまでの提案[ref] Bitcoin Core pull#6231 >

一般ブロックサイズ増加理論[編集]

一般的なブロックサイズの増加に関する質問 具体的な提案。

ブロックサイズを1 MBに永久に保つことを好む人がいるのはなぜですか?[編集]

これは、2015年6月8日のMike Hearn(インタビュー)[1]<ref>Epicenter Bitcoin podcast#82最大ブロックサイズの上限を引き上げることに反対している人もいますが、Bitcoinの開発者は最大ブロックサイズを1メガバイトに永遠に保つことを提案していません[3]

すべての開発者は、ある時点で最大サイズを上げることをサポートしています。<ref> [6]、アダム・バック博士、2015年6月13日< /ref><ref>[7]、Pieter Wuille、2015年5月28日</ ref>彼らは今、正しい時であるかどうかについては同意しない。

鉱夫はブロックサイズを決めることができますか?[編集]

ブロックには1つのトランザクションだけが含まれるため、鉱夫は常にブロックサイズを制限できます。鉱夫に最大ブロックサイズを選択させることは、いくつかの理由からより問題が多い。

'鉱夫の利益、他の人はコストを支払う:より大きなブロックは鉱夫により多くの手数料を与えるが、鉱夫は数日以上ブロックを保管する必要はない。<ref> / bitcoin / bitcoin / pull / 5863 Bitcoinコアプル#5863プルーニング機能を追加、Suhas Daftuar他、2015年3月6日</ ref>完全な検証セキュリティを必要とする、または軽量財布にサービスを提供する他のユーザーは、それらの大きなブロックをダウンロードして保存することができます。 '大規模な鉱夫では帯域幅を増やすことができます:' '各鉱夫は、ブロックに含まれるすべてのトランザクションをダウンロードする必要があります。[4]これは、 。しかし、合計ハッシュレートの8.3%を持つ鉱夫は、1日の約300のBTCからそのコストを奪うことができますが、合計ハッシュレートのわずか0.7%の鉱夫では、1日当たりわずか25BTCからそのコストを払わなければなりません。これは、より大きな鉱夫が鉱業をさらに集中化するかもしれないが、より大きなブロックを作ることを論理的に選択するかもしれないことを意味する。 集中的なハードウェア生産:世界のいくつかの企業だけが効率的な鉱山機械を生産しており、その多くは一般に販売を停止することを選択している[ref> 2014/09/05 /忘れてしまった恋人のためのビットコインマシンから家庭鉱夫/ KnCMinerによる家庭鉱夫への販売を停止、ウォールストリートジャーナル、ユリヤチェルノバ、9月5日2014 </ ref>こうすることで、通常のBitcoinユーザーは、鉱山機械の支払いに喜んで参加してもプロセスに参加することができなくなります。 ハッシュレートに基づく投票は、現在のハッシュレートの大多数(または大多数)が少数派の条件を強制することを可能にします。これは、大企業のロビーが小規模なビジネスを傷つける可能性のある法律を通過させることに似ています。[ref> [8]、Meni Rosenfeld、2015年6月13日</ ref> "[2015年7月のフォーク]の間に鉱山者がユーザーを気にしないかもしれない: これは、鉱夫が無効なチェーンを採掘して得た収入で$ 50,000を失った後でさえ、長いフォーク<ref> SPVマイニングを継続する意図、Wang Chun、2015年7月4日</ ref>

しかし、鉱夫にブロックサイズを選択させるための正当な理由もあります:

'認証された参加者:' 鉱夫はBitcoinの積極的な参加者であり、作成したブロックにデータを追加することでそれを証明することができます<ref> -coinbase-field Coinbaseフィールド、Bitcoin.org開発者リファレンスReddit、BitcoinTalkなどの人々がBitcoinに積極的に関わっていることを証明することはずっと困難です。 大規模なブロックが生成されれば、小規模の鉱夫や不十分に接続された鉱夫は不利になります。大規模でよく接続された鉱夫でさえ、それが見つかるかもしれません。大規模なブロックは、帯域幅のコストが高すぎるか、失効率が高くなると利益率が低下します。懸念]、Chun Wang、2015年5月29日</ ref>

どのようにブロックサイズの増加がユーザのセキュリティに影響を与える可能性がありますか?[編集]

BitcoinのセキュリティはBitcoin Coreのような完全なノードでビットコインを保護するアクティブなユーザーの数に大きく依存します。フルノードのユーザーが活発になればなるほど、詐欺的なビットコインやその他の詐欺を受け入れるように詐欺師を騙すのは難しくなります。<ref> @lopp/bitcoin-nodes-how-many-is-十分な数 - 9b8e8f6fd2cf Bitcoinノード:いくらですか?、Jameson Lopp、2015年6月7日</ ref>

フルノードはすべてのブロックをダウンロードして検証する必要があり、ほとんどのノードはブロックとリレートランザクション、フルブロック、およびフィルタリングされたブロックをネットワーク上の他のユーザーにも格納します。ブロックが大きくなるほど、これをすべて実行するのが難しくなるため、ブロックが大きくなると、現在フルノードを実行しているユーザーの数が減少し、後でフルノードを実行することを決定したユーザーの数が抑えられます。 <ref> [9]、2015年6月28日、Adam Back博士</ ref>

また、フルブロックでは、マイニングが集中化されているため、複数回確認されたトランザクションを簡単にリバースすることができるようになるため、マイニングの集中化を高めることができます[5] bitcoin.stackexchange.com/questions/32562/when-to-worry-about-1-confirmation-payments/32564#32564 1つの確認支払いについて心配する場合]、David A. Harding、2014年11月17日</ ref>

より大きなブロックが作業証明(POW)セキュリティにどのように影響しますか?[編集]

労働安全保障の証明は、鉱夫が鉱山設備にどれくらいの金を費やしているかによって決まります。しかし、ブロックを効率的に採掘するために、鉱夫はまた、他の鉱夫によって作られた新しい取引やブロックを受け取るために、帯域幅に資金を費やす必要があります。受信したトランザクションおよびブロックを検証するためのCPU;新しいブロックをアップロードするための帯域幅。これらの追加費用は、捕虜の安全保障に直接的には寄与しません。<ref name = "maxwell_correcting_assumptions"> [10]マックスウェル、2015年6月15日</ ref>

ブロックサイズが増加すると、必要な帯域幅とCPUの量も増加します。ブロックのサイズが帯域幅とCPUの減少よりも速く増加する場合、鉱夫は獲得した総所得に対する囚人の安全保障のための資金が少なくなります。

さらに、ブロックが大きくなると失効した(孤児になる)危険性が高くなります[6]。これはPOWセキュリティの喪失に直接関係します。たとえば、ネットワークの平均失効率が10%の場合、実行されたPOWの10%はブロックチェーン上のトランザクションを保護していません。

逆に、トランザクションあたりの料金が低くなるブロックが大きくなると、オン・チェーン・トランザクションの需要が増加し、平均トランザクション手数料は低下しますが、鉱工業会社が獲得する総取引手数料が増加します。これにより、Proof of Workの世代をサポートする収益が増加し、ネットワークのセキュリティが強化されます。

ブロックサイズが1メガバイトから増加しない限り、Bitcoinは現在の鉱業収入とネットワークセキュリティに対する経済支出を維持するためブロック補助金が消滅すると、BTCがトランザクションあたり1ドル50セントの報酬を支払う必要があります。補助金が消えると現在の経済支出レベルを維持するための1回の取引当たりの必要な手数料は、ブロックサイズと最大チェーン連動処理スループットが増加するにつれて減少します。

価格上昇に対する需要の感応の結果、Bitcoin経済の成長、そしてBitcoinネットワークを確保するために支払った手数料の伸びは、ブロックサイズが十分に拡大できない場合には減速する可能性がある。

ブロックがすべての保留中のトランザクションを含めるのに十分な大きさでない場合[編集]

これは既に、<ref> Statoshi.info mempool queue June〜July July </ ref>よりも頻繁にそうです。鉱夫は単に取引を待ち行列に入れます。キロバイト当たり最高額を支払うブロック封じ込めの対象となる取引は、比較的低い手数料を支払う取引よりも早期に確認される[2]

基本的な経済理論は、価格の上昇が経済的需要を減らすことを示している。大規模なブロックでは、ネットワークの地方分権と検閲の喪失が認識されるため、チェーン上のトランザクション処理に対する需要が失われないと仮定すると、保留中のすべてのトランザクションを含むには小さすぎるブロックは、チェーン上のトランザクション処理ブロックが十分に大きい場合には、すべての保留中のトランザクションが含まれます。

そこから起こることは議論されている:

  • BitcoinJの主任開発者であるMike Hearn氏は、「ノードのクラッシュ、トランザクション・バックログの増加、二重支出の突然の急増、急上昇する料金の発生」と考えている。[ref] / crash- landing-f5cc19908e32クラッシュランディング、Mike Hearn、2015年5月7日</ ref>
  • Bitcoin Foundationのチーフ・サイエンティストのGavin Andresen氏は、「平均取引手数料が上昇すると、上昇しない料金を支払うことができない、あるいはできない人やアプリケーションが取引を提出しなくなる」と考えている。 "<ref> Bitcoin Core pull#6341、Gavin Andresen、2015年6月26日</ ref>

Bitcoin Coreの開発者であるPieter Wuilleは、上記のAndresenのコメントに次のように答えています。「ユースケースはもはや適合しないでしょう。人々はこれらの目的のためにブロックチェーンを使用しなくなり、料金が適応します。 '?私はすでに起こっていると思う[...]私はこの変更を恐れるべきではない、あるいはそれをやめようとしているとは思わない」<ref> June / 009098.htmlより大きなブロックの必要性、2015年6月26日、Pieter Wuille </ ref> Bitcoin Core開発者のJeff Garzik氏は、「ブロックが満ちて入札戦争が起こると、ビットコインのユーザーエクスペリエンスは急速に悪化します。ビットコインウォレットソフトウェアの相対的な未熟さとビットコインの決済ベースの設計の一部に起因して、トランザクションのユーザーエクスペリエンスがブロックサイズと競合すると、不安定で予期せぬことに検証時間が長くなります」[1]

特定のスケーリングプロポーザル[編集]

Andresen-Hearnブロックサイズの提案を増やす[編集]

Gavin Andresen氏とMike Hearn氏による一連の関連提案に関する質問にハードブロックを使用してブロックサイズを最大化することで、鉱山者がより多くのオンザフライトランザクションを含めることができます。 2015年7月現在、現在の焦点はBIP101です。

この提案の大きな利点は何ですか?[編集]

「Bitcoinは、より多くのユーザーをサポートできます」BitCinは、チェーン内トランザクションあたり250バイト、1日あたり144ブロック、ユーザーあたり1日に2トランザクションを可能な限り早期に採用することを想定して、

  • 2015年に288,000人のユーザー
  • 2016年に2,304,000ユーザー(800%増)
  • 2018年には4,608,000人(1,600%)
  • 2020年に921.6万人(3,200%)
  • 2022年に18432000(6,400%)
  • 2024年の36864,000(12,800%)
  • 2026年の73,728,000(25,600%)
  • 2028年の147,456,000人(51,200%)
  • 2030年に294,912,000(102,400%)
  • 2032年の589,824,000(204,800%)
  • 2034年の1,179,648,000(409,600%
  • 2036年の2,359,296,000(819,200%)

この提案の主な欠点は何ですか?[編集]

最も早期に採用され、全ノードオペレータに対する全ユーザの割合が今日と同じであると仮定すると、分散システムを維持するために必要な総作業量は[ [#O.28n2.29_network_total_validation_resource_requirements | O( 2 </ sup>)スケーリングモデル]]は、

  • 2015年の今日の仕事の100%
  • 2016年に6,400%
  • 2018年に25,600%
  • 2020年に102,400%
  • 2022年には409,600%
  • 2024年に1,638,400%
  • 2026年の6,553,600%
  • 2028年の26,214,400%
  • 2030年に104,857,600%
  • 2032年に419,430,400%
  • 2034年1,677,721,600%
  • 2036年の6,710,886,400%

たとえば、現在フルノードを稼働させるために費やされた合計金額(鉱業を考慮しない)が年間100,000ドルである場合、検証コストが同じであれば、2036年の同じ地方分権の推定コストは年間$ 6.7兆ドルになります。 (彼らは確かに下に行くだろうが、アルゴリズムとハードウェアの改善は、おそらく6,710,886,400%のコスト増加を排除しません。)

提案されているハードフォークの危険性は何ですか?[編集]

現在の提案では、鉱夫の75%が8MBまでのブロックを受け入れることに同意する必要があることを示す必要があります。<ref name = "bip101"> BIP101 、Gavin Andresen、2016年6月24日</ ref>変更が有効になった後、1MBを超えるブロックが作成された場合、まだアップグレードされていないすべてのノードがブロックを拒否します<ref> [https:// bitcoin .org / en / developer-guide#コンセンサスルールの変更コンセンサスルールの変更]、Bitcoin.org開発者ガイド</ ref>

すべてのフルノードがアップグレードされている場合、またはすべてのノードに非常に近い場合は、実際的な効果はありません。十分な数のフルノードがアップグレードされていない場合、アップグレードされたユーザーとは異なるブロックチェーンを使用し続けますが、次のような結果が生じます。

フォークの前から受け取ったビットコインは、フォークの両側に1回、2回使うことができます。これにより、高い二重支出リスクが発生します。

  • フォークの後に受け取ったビットコインは、受け取ったフォークの側で費やせることが保証されています。これはBitcoinを単一のチェーンに復元するために一部のユーザーが失うことになることを意味します。

ホステッドウォレット(Coinbase、BlockChain.infoなど)のユーザーは、ホストが選択するブロックチェーンを使用します。軽量P2P SPVウォレットのユーザーは、最長のチェーンを使用しますが、短いチェーンのノードにしか接続しない場合、実際の最長のチェーンではない可能性があります。 Electrumのような非P2P SPVウォレットのユーザーは、接続先のサーバーで使用されているチェーンを使用します。

このようなハードフォークが悪い場合は、大規模な混乱の原因となり、状況が解決するまでBitcoinを使用することを非常に困難にします。

BIP 101の展開スケジュールとは何ですか?[編集]

  • パッチは、Bitcoin Core、Bitcoin XT、またはその両方に適用する必要があります。
  • Bitcoin Coreに受け入れられた場合、そのソフトウェアを使用している鉱夫はアップグレードする必要があります(Bitcoin Coreの新しいリリース版が必要です)。 Bitcoin XTにしか受け入れられない場合、鉱夫はXTの使用に切り替える必要があります。
  • 75%の鉱夫がアップグレードされた後、(1)2016年1月11日または(2)75%アップグレードのしきい値の2週間後に、最新の8MBのブロックが許可されます。[7]
  • 有効期限が過ぎると、8MBを超えるブロックが作成されることがあります。 minerがこれを行うと、アップグレードされたフルノードはそのブロックを受け入れ、アップグレードされていないフルノードはそれを拒否し、ネットワークをフォークします。[7] for [[#What_are_the_dangers_of_the_proposed_hard_fork.3F |ハードフォークの危険性]彼が何を意味するのか。

1MBのブロックから8 MBのブロックまで、鉱夫はまっすぐ行くでしょうか?[編集]

それは非常にありそうもないでしょう。現在、8 MBのブロックをアップロードすると、1 MBのブロックをアップロードするよりもかなり時間がかかります。<ref name = "rusty_dsl"> [11] Rusty Russell、2015年6月19日</ ref>、Matt Coralloのブロックリレーネットワークを使用した場合のサイズの約25倍の縮小でさえも。[8]

ブロックをアップロードするのに時間がかかるほど、古いブロックになるリスクが高くなります。つまり、作成した鉱夫はブロック補助金や取引手数料(ブロックあたり約25BTC)を受け取ることはありません。

しかし、Invertible Bloom Lookup Tables(IBLTs)のような技術が展開され、期待通りに機能することが判明した場合、ブロックの伝播については、<ref name = "iblt"> O Gavin Andresen、2014年8月8日</ ref>、または掘削[さらに#中央集計化|]が行われた場合、鉱山者がフルブロックを作成するのを阻止するのに十分なコストがかかりません。その場合、デフォルトの中継料を支払う取引をしたいと思うほどの人がいるとすぐにブロックが埋め尽くされます<ref> Bitcoin Core pull#3305はデフォルトを落とします料金、Mike Hearn、2013年11月22日</ ref> 0.00001000 BTC /キロバイト。

この提案に関連してどのようなテストが実施されましたか?[編集]

明日最大ブロックサイズを20メガバイトに増やすと、20メガバイトブロックの作成を開始することに決めたばかりで、メガバイトでのトランザクション数が急激に増加すると、20 MBブロック処理 (Gavin Andresen)これらのブロックを埋め尽くすためのネットワークが必要になります。[Bitcoin Core]の0.10.0バージョンはうまく動作します。 "<ref> 20メガバイトのブロックテスト、Gavin Andresen、2015年1月20日</ ref>(オリジナルの省略記号)

  • 'マイニング&amp;ブロックを20秒間伝播させると、ハッシング・パワーの30%を持つ鉱夫のネットワークは、ブロックの30.3%を占めることになります。」[http:// gavinandresen。鉱山労働者のためのより大きいブロックはより良いですか?]、Gavin Andresen、2015年5月22日</ ref>

1-exp(t / 600)の大まかな公式を使用して、私は10.5%の1MBブロックを生成し、56.6%は8MBの孤立したレートを期待していますブロック;これは予想される利益の大幅な削減です。」[6]

  • 'マイニングの集中化の圧力' '(Pieter Wuille) "[これは、システムの集中化の圧力に大きなブロックが及ぼす影響を非常にはっきりと示しています" <ref name = "wuille_centralization"> [http:// lists。 linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008581.html 2015年6月12日Pieter Wuille </ ref>

Garzik Minerブロックサイズ投票提案(AKA BIP100)[編集]

BIP 100は、この提案のマーケティング名です。 BIP番号なし まだ公式に要求されており、割り当てられた番号は 100です。<ref> [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005756.html 2014年5月12日、Gregory Maxwell氏、

Jeff Garzikの提案に関する質問<ref name = "garzik_bip"> BIPドラフト:分散型経済政策、Jeff Garzik、2015年6月12日(6月15日改訂) 2015)</ ref>。鉱夫が最大ブロックサイズを上げ下げする際に投票できるようにする。

この提案は何をしていますか?[編集]

#最大ブロックサイズを自動的に変更しない1回限りのハードフォークを作成します。

#これは、鉱夫が最大ブロックサイズを1MBから32MBの範囲で増減させることを許可します。これらの変更は、ハードフォークでもソフトフォークでもなく、最初のハードフォーク後にすべてのノードが知っておくべきルールです。

ハードフォークのリスクを軽減しますか?[編集]

ハードフォークは、強くなくしてしまえば最も危険です 合意。[1]<ref>[12] 、 Pieter Wuille、2015年6月18日</ ref>

Garzikの提案が強力な合意を得るならば、それは可能な限り安全です ハードフォークの場合、ブロックサイズを32 MBまで増やすことができます フォークの追加のリスクなしに。

なぜそれは32メガバイトに制限されていますか?[編集]

BIPのドラフトによると、「32 MBのハードフォークは大部分が偶然で、32 MBのネットワーク全体がアップグレードされる可能性が高い」

雷ネットワーク[編集]

Bitcoinがサポートできるユーザー数を拡張する方法として、提案されたLightning networkの使用に関する質問。

トランザクションセキュリティとBitcoinのセキュリティはどのように違いますか?[編集]

提案されたLightningネットワーク上のトランザクションはBitcoinトランザクションを排他的にビットコインを転送するために使用します<ref name = "russell_lightning1"> Lightning Networks:Part I、Rusty Russell、2015年3月30日< / ref>を使用しているため、Lightningハブとクライアントの両方が協力している場合、通常のBitcoinトランザクションと同じセキュリティが提供されます。

Lightningハブまたはクライアントが(間違ってオフラインになったために)他のユーザーと協力し合うことを拒否した場合でも、相手は支払いチャネルをクローズして100%のビットコイン残高を引き続き受け取ることができますが、ハブとクライアントの両方で相互に選択されています。<ref> Lightning Networks:Part II、Rusty Russell、2015年4月1日</ ref>

一方の当事者が支払いチャネルを閉じるのに時間がかかり過ぎると、他方の当事者はビットコインを盗むことができる可能性がある。しかし、緊急時にチャネルを閉鎖する作業をインターネット上の無制限のハブに任せることは可能ですので、時間通りにチャネルを終了するのは簡単なはずです。<ref name = "russell_lightning4"> [http:// rusty .ozlabs.org /?p = 477 Lightning Networks:Part IV]、Rusty Russell、2015年4月8日</ ref>

要約すると、支払いチャネルが時間通りに閉鎖されていれば、ユーザーに起こる可能性のある最悪のことは、チャネルが完全に閉鎖されてから受信したビットコインを費やすまで数週間待たなければならないことです。彼らのセキュリティは、そうでなければ通常のBitcoinと同じです。

ライトニング・ハブの場合、潜在的に大量の資金をホット・ウォレットに入れておく必要があるという意味で、セキュリティは少し悪化します。<ref name = "lightning_paper"> DRAFT-0.5.pdf Lightning Network(Draft 0.5)、セクション6.3:ハッキングによるコイン盗難、Joseph Poon、Thaddeus Dryja </ ref>など、冷たい財布が提供するアンチハッキング保護を利用することはできません。それ以外の場合、Lightningハブはクライアントと同じセキュリティを持ちます。

いつ雷が使えるようになりますか?[編集]

Lightningは、基本的なテストの実装が必要です(2015年6月13日のRusty Russell <ref> [13])。 >)、Bitcoinプロトコルへのいくつかのソフトフォーク変更(作業中<ref> BIP65:CheckLockTimeVerify、Peter Todd、10月1日2014年5月28日、Mark Friedenbach </ ref> <ref> BIP68:コンセンサス強制取引の置き換え Lightningネットワークプロトコルをサポートするためにウォレットを更新する必要があります。[9]

Adam Back博士は、「1年以内に何かを稼ぐことができると期待しています。」[ref> Andresenに返信Lightningに関して、2015年6月28日のAdam Back博士</ ref>

雷は大掛かりなブロックを必要としませんか?[編集]

雷はブロックサイズニュートラルです。 [10]間には、誰とでもトランザクションを無限にサポートすることができますライトニングネットワーク上[11]

2015年2月23日のJoseph Poon、Lightningプレゼンテーション<ref name = "lightning_slides"> [14]の数字を使用して、人々が現実的な1メガバイトの制限で約5200万人のユーザーをサポートすることができ、各ユーザーは無制限のトランザクションを行うことができます。現在、Bitcoinのトランザクションは1日平均で2つしかないと仮定すると、Bitcoinの基本的なユーザー数は288,000人に過ぎません。

これらの前提の下で、Lightningは基本的なBitcoinよりも180倍(17,900%)効率的です。

おそらく、約3,000万人がBitcoin via Lightningを使用して容量を疑問視すると、ブロックサイズを2メガバイトに倍増させ、ユーザー容量を最大10500万人にするというコンセンサスを見つけることは難しくありません。 4MB、4億(8MB)、8億(16MB)、16億(32MB)、32億(64MB)、70億人の生きている人間(133MB)の後に増加する。いずれの場合も、すべてのLightningネットワーク参加者は他の参加者に無制限のトランザクションを取得します。

基本的なBitcoinが1日にわずか2トランザクションに拡張できるようにするには、70億人で24ギガバイトのブロックが必要です。[12]

サイドチェーン[編集]

素早く、サイドチェーンは何ですか?[編集]

Bitcoinのブロックチェーンとは別のブロックチェーンをブロックするが、双方向ペグ(2WP)を使用してビットコインを受信して​​使用することができる。<ref name = "sidechains_paper"> pdf Sidechains paper、Adam Back他、2014年10月22日</ ref>(サイドチェーンはBitcoinブロックチェーンよりも安全性が高くありませんが、 / comments / 39r85g / sidechain_hate / cs5spbg紐付きチェーンのセキュリティ制限]、Gregory Maxwell、2015年6月14日</ ref>)

サイドチェーンはスケーリングオプションですか?[編集]

いいえ。サイドチェーンにはBitcoinと同じ基本的なスケーリングの問題があります。いくつかのトランザクションをサイドチェーンに移動するだけで、ネットワーク上のいくつかの問題が単純に移動します。問題の全体の難しさは同じです。 htmlサイドチェーンは、Bitcoinが持つスケーリングの問題を解決するための直接的な手段ではない]、Pieter Wuille、2015年6月13日</ ref>

しかし、100GBのブロックを持つサイドチェーンを作成できませんでしたか?[編集]

確かに、サイドチェーンコードはオープンソースです。<ref> Elements Project </ ref> - 独自のサイドチェーンを作成できます。しかし、100 GBのブロックを完全なノードで検証しようとする人々を見つけるのは難しいでしょう。

サイドチェーンにはハードフォークが必要ですか?[編集]

いいえ。すでに実装されているような連合サイドチェーンは、Bitcoinのコンセンサスルールに変更を加える必要はありません。<ref> Elements Alpha </ ref>まだ実装されていない統合されたマイニングされたサイドチェーンは、Bitcoinとサイドチェーンの間で資金を転送するために、後方互換のソフトフォークが必要です。[13]

参考文献[編集]

<リファレンス/>

  1. 1.0 1.1 1.2 1.3 1.4 引用エラー: 無効な <ref> タグです。 「garzik_bip」という名前の引用句に対するテキストが指定されていません
  2. 2.0 2.1 引用エラー: 無効な <ref> タグです。 「fee_pri」という名前の引用句に対するテキストが指定されていません
  3. 引用エラー: 無効な <ref> タグです。 「maxwell_not_proposing」という名前の引用句に対するテキストが指定されていません
  4. 引用エラー: 無効な <ref> タグです。 「maxwell_correcting_assumptions」という名前の引用句に対するテキストが指定されていません
  5. 引用エラー: 無効な <ref> タグです。 「wuille_centralization」という名前の引用句に対するテキストが指定されていません
  6. 6.0 6.1 引用エラー: 無効な <ref> タグです。 「rusty_dsl」という名前の引用句に対するテキストが指定されていません
  7. 7.0 7.1 引用エラー: 無効な <ref> タグです。 「bip101」という名前の引用句に対するテキストが指定されていません
  8. 引用エラー: 無効な <ref> タグです。 「block_relay_net」という名前の引用句に対するテキストが指定されていません
  9. 引用エラー: 無効な <ref> タグです。 「russell_lightning4」という名前の引用句に対するテキストが指定されていません
  10. 引用エラー: 無効な <ref> タグです。 「russell_lightning1」という名前の引用句に対するテキストが指定されていません
  11. 引用エラー: 無効な <ref> タグです。 「lightning_paper」という名前の引用句に対するテキストが指定されていません
  12. 引用エラー: 無効な <ref> タグです。 「lightning_slides」という名前の引用句に対するテキストが指定されていません
  13. 引用エラー: 無効な <ref> タグです。 「sidechains_paper」という名前の引用句に対するテキストが指定されていません