WeChatグループでのBitcoin Unlimited AMA

これはWeChatグループでのBitcoin Unlimitedに関するQ&A記録です。

参加者：

-アンドリュー・ストーン（thezerg）、BU開発チームリーダー

-アンドレア・スザンヌ（シックピッグ）

-Peter.Tschipper (ptschip)

アンドレア・スイザーニ: こんにちは。私は BU 開発者の Andrea (sickpig) です。私の主な焦点はテスト、CI、ドキュメントです。

ピーター・チッパー:   こんにちは。私は Peter Tschipper (ptschip) で、BU 開発チームのメンバーです。

Q: BU がブロック サイズの問題を解決する方法を教えてください。

A: 基本的に、BU は、マイナーとノード オペレーターが投票ベースの方法で投票し、自由市場が自然なコンセンサスの下でブロック サイズに到達するようにする、エマージェント コンセンサスを使用してブロック サイズの問題を解決します。ブロック サイズを人為的に制限するよりも、より大きなブロック ネットワークの方がこれを十分に処理できると考えています。 (ptschip)

BU では、フルノードとマイナーが希望するブロック サイズ制限に投票できます。しかし、一定数を超えるクライアントが「しぶしぶ」大きすぎるブロックを受け入れた場合、ネットワークの残りの部分はこれらの大きなブロックを拒否する可能性があります。この戦略により、「ナカモトコンセンサス」が最も重要であることがわかります。一般的に、ビットコインの通貨機能の原則が保証されない場合は、最長のチェーンに従うフルノードのコンセンサスも破られることになります。 （ザザーグ）

Q: Core との違いについて詳しく教えていただけますか?変更されたのはBUIP-001だけですか？また、フォークが発生すると具体的に何が起こるのか、また BIP (Bitcoin Improvement Protocols) は BU に統合されないのかについて説明していただけますか? （翻訳者注：原文に「13」がありますが、まだ理解できていません。タイプミスかもしれません）

A : BU は Core 0.12 のブランチですが、RBF 機能が削除されています。追加された主な機能は、Xthin ブロック、Xpedited、自然コンセンサス (sickpig) です。

変更点のほとんどはバグ修正とマイナーな改善であるため、すべての変更点をリストする必要はありません。たとえば、「getpeerinfo <IP アドレス>」を実行すると、1 つのノードからのみデータを取得できます。しかし、大きな変更点は、エマージェントコンセンサス、Xthinブロック、Expeditedブロック、トラフィックシェーピング、メモリプール、DOS保護です（thezerg）

Q: この分野で異なる開発チームがより効果的に連携するにはどうすればよいでしょうか? (私たちの何人かはすでにメモリプールの同期ロジックに協力していることは知っていますが、それをどのように改善して機能させることができると思いますか?

A: 開発チームがよりうまく連携できるようにするには、XT チームと Classic チームとの良好なオープンなコミュニケーションが実現し、しばらく一緒に作業を進められることを心から願っています。 (ptschip)

追加の質問: これは一方的な問題ではないと思いますが、xt/classic/bu は「本番環境では実行されない (Core は本番環境で実行される)」プロジェクトであることを考慮すると、以前のコミュニケーション不足は理解できます。私が尋ねているのは、どうすれば改善できるかということです。

チームと実装に関しては、多ければ多いほど良いです (sickpig)

Core を定期的にリベースする必要があるため、Unlimited は Core プロジェクトを適切に処理できません。しかし、近い将来、ブロック サイズをめぐって互いに議論することがなくなり、より直接的に協力できるようになることを願っています。他の開発チームは無能であるという、（コア）開発者やリーダーシップからの根拠のないコメントは役に立ちません。 (アダム・バックのツイートの1つについて詳しく説明したいと思ったのですが、すでに多すぎます) (thezerg)

私たちは常にオープンなコミュニケーションと対話を歓迎します。 Core と他の実装との間の問題は、ブロック サイズとトランザクション手数料に関する懸念に関する明確な哲学的な違いに帰着すると思います。私たちの哲学では、自由市場とは何か、手数料がどのように発展すべきかは極めて明確です。これは、2 つの開発チームの概念に大きなギャップがあることを示しています。 (ptschip)

Q: ブロックサイズの問題を毎日解決するためにハードフォークすることはできますか?

A: 私たちの計画は、コードからブロック サイズの制限を削除し、自由市場に決定を委ねることです。したがって、ブロック サイズの制限を毎日増やすのにハード フォークは必要ありません。 （病人豚）

追加の質問: 彼が言っているのは、マイナーが時々メインチェーンから分岐する偶発的なハードフォークのことだと思いますが、それとも、マイナーは常にメインチェーンに戻るのでしょうか?

マイナーが明示的に無限に近い深さを選択しない限り、マイナーは数ブロック後にメインチェーンに戻ります。 （ザザーグ）

ブロックチェーン上で BU ロジックを実行することを意味していると思います。私が言いたいのはそういうことではありません。ブロックサイズの制限を変更するためにハードフォークなしで BU を実行すると、その後ハードフォークは発生しません。もちろん、実際の運用ではトランザクションが十分ではなく、マイナーはブロック全体をブロードキャストする前に、薄いブロックを通じてマイニング情報を広めることができます。 （ザザーグ）

Q: @海洋ViaBTC のブログから学んだところによると、BU を実行しているマイナーは、大きなブロックが小さなブロックの Bitcoin ブロックチェーンよりも長く Bitcoin ブロックチェーンを継続できる限り、いつでも大きなブロックを受け入れることができると理解しています。これにより、特大のブロックがマイナーが承認に投票したブロック サイズを上書きできるようになるのでしょうか?たとえば、マイナーが 2MB のブロックを受け入れると言っているが、最長のチェーンが 2.1MB のブロックである場合、マイナーはそれを受け入れなければならないのでしょうか?これは、最長チェーンに切り替える前にこのマイナーによってマイニングされたブロックがすべて孤立することを意味しますか?

A: マイナーが明示的に無限に近い深さを選択しない限り、マイナーは数ブロック後にメインチェーンに戻ります。 （ザザーグ）

「消極的なブロックチェーンの切り替え」について、私が最後に検出したのは、「チェーンが AD (受け入れ深度) を超えると、EB を超えるブロックがチェーンに追加されても、チェーン上に EB を超えるブロックが 24 時間存在しない場合を除き、コードはチェーンの先端に残ります。その場合、colde は元のチェーンのマイニングに戻ります。」でした。 @Andrew Stone がさらに説明しました。 (翻訳者注: EB 値はマイナーがサポートするブロック サイズの値です。)

はい、その通りです。ただし、「24 時間」は実際にはブロック内で定義されます。 （ザザーグ）

EB? EB = ブロックサイズ超過 (sickpig)

つまり、マイナーが孤児率を低く抑えたい場合、AD を 0 に設定せざるを得なくなるということでしょうか?

または、超過したブロック サイズ値 (EB) を高く設定します... (thezerg)

Q:コードのレビューとデプロイメントのプロセスとは何ですか?コミットする権利は誰にありますか?

A: 選ばれた開発者にはコミットアクセス権が与えられます。他の全員が PRS を送信し、それを私と他の人がレビューしてからメインのコードベースにマージします。小さなバグ修正は「マスター」ブランチにコミットされ、より大きな機能は別のブランチにコミットされ、その後、徹底的なテストの後に集約されます。ザーグ

コード開発グループの管理プロセスについては、こちらの記事をご覧ください: https://www.bitcoinunlimited.info/articles。また、さらに多くの機能はサポートスタッフによる投票が必要です。 （病人豚）

Q:今後のリリースには Segregated Witness (SegWit) が含まれますか?それとも完全に反対ですか?また、Schnorr についてはどのような計画がありますか?

A: 最終的には、メンバーが Segregated Witness (SegWit) を採用するかどうかを投票で決定します。個人的には、Segregated Witness はかなり洗練されていないので、ハードフォークを使用してより洗練されて実装できると思います。また、ブロック サイズは合計 4MB なのに、有効なトランザクション保存スペースが 1.7MB しかないのも気に入りません。ブロック サイズを増やすと、これは非常に面倒になります。妥当な値は 2 MB に増やすことですが、実際のブロック サイズは不可解なことに 8 MB になっています。そして、スケーラビリティがほんのわずかな割合でしか向上しないのに、ビットコイン決済システムを中心に製品を設計する企業が出てくるとは信じがたい。 （ザザーグ）

Q:誰もが sigops 攻撃が 2 乗的に増加し、ブロック サイズが増加すると大きな問題になるだろうと話しているのですが、これは心配すべきことだと思われますか?そうでない場合、どのような変更を加えましたか?ブロック サイズの増加によって、どのような課題に直面すると思いますか?

A: 現在作業中であり、並列ブロックの検証はほぼ完了しています。並列スレッドを通じて複数のブロックを同時に検証できるため、中央処理スレッドの負担を軽減できます。これにより、非常に大きなブロックを持つノードまたはマイナーをブロックすることは不可能になり、非常に大きなブロックを持つ攻撃者は自分のブロックを孤立させるだけになります。 (ptschip)

Re: sigops 攻撃、比例ルールを追加するのは非常に簡単です。 – sigops は 1 MB あたり 20k 程度である必要があります。これにより、二次成長問題が解決されます。ただし、将来のユースケースがなくなる可能性があります (今日「奇妙」だと考えられていたスクリプトが突然役立つようになった場合)。そのため、並列検証を調査しています。 （ザザーグ）

Q: 「不本意なチェーン切り替え」はどのくらいの頻度で起こると思いますか?それは 1 日に複数回発生しますか、それとももっと少ない頻度で発生しますか?鉱山労働者は、お金を失うことなく、どうすればこのような事態を防ぐことができるでしょうか。受け入れ深度を低く設定するだけですか?受け入れ深度が一般的に低い場合、攻撃者はどのようにしてコンセンサス メカニズムを攻撃し、ブロック サイズを操作することができるのでしょうか。

Q: bu チームはフルタイムのプログラマーですか?それとも「フルタイムの仕事」（つまりパートタイムの仕事）に加えてですか？

A:少なくとも 2 人のフルタイム開発者がいることはわかっています。 (ptschip)

Q: BU チームを拡大する方法を知りたいです。

Q: BU ファンドについてはどうですか?つまり、2 人の開発者に給料をどうやって支払うのかということです。

A: 誰が開発者に支払うのかは言えませんが、私たちは最近、開発者へのボーナスの支払いに使用される 50 万ドルの寄付を受け取りました。 (ptschip)

Q: @Peter Tschipper 合意が得られていない分野で協力し、そこから作業を進めてみてはいかがでしょうか?

A: 喜んで協力します。ほんの数週間前、Matt Corallo 氏は、Core はブロックをヘッダーのみで識別したいと考えていることを私たちに思い出させました。それで私は彼に、私たちは幸せだと伝え、彼ら（コア）にドアを開けて、そうするつもりだと伝えました。私たちのコラボレーションはそれほど遅れたとは思いません。 (ptschip)

追加の質問: わかりません。BIP プロセスについては苦情が出ているので、私が質問しているのは… BU 開発者は BIP プロセスに反対し続けているのでしょうか? BIP プロセスではない場合でも、コラボレーションを促進するプロセスをどのように構築すればよいでしょうか? （ネットワークに反対する行為は本当に悪いことだから）

BIP プロセスの問題は、それが私たちのプロセスではなく、あなたのプロセスであり、私たちは BUIP を使用しているということだと思います。このギャップをどうやって埋めればいいのでしょうか?これら 2 つのプロセスはどのようにして相互に通信すればよいでしょうか?通常は他の開発チームに連絡してコミュニケーションをとります。もっと正式な手続きを望まない限り、これほど複雑にする必要があるのか​​どうかはわかりません。 (ptschip)

Q: BIP は正しい方向への一歩だと思います。少なくとも全体的な状況はそうです。あなたが提案する変更は市場を混乱させるほど大きなものです。この点に関して、BU が Core よりも市場のニーズに応えられると考えている理由が私には興味深いです。市場のニーズにどう応えられると思いますか? @アンドリュー・ストーン

A: BUIP の提案と承認には正式なプロセスがあります。メンバーが私の意見を無視するのを止めることはできません。ぜひ私たちの記事を読んでから、Bitcoin Unlimited 開発グループに参加して投票してください。 （ザザーグ）

記事はここからご覧いただけます: https://www.bitcoinunlimited.info/articles （病人豚）

たとえば、私は BU のコミッターですが、コード ベースを制御することはできず、それをハイジャックすることもできません。誰がコードをコミットできるかは大統領が管理します。しかし、私は DNS 解決を制御しているので、大統領がコードベースをハイジャックした場合、サイトをそのコードベースから遠ざけることができます。そして、抑制とバランスが保たれます。 （ザザーグ）

Q: BU メンバーシップは誰でも参加できますか、それともコード貢献者のみですか?皆さんの中に、以前にコード貢献者になったことがある人はいますか?

A: 誰でも参加できます。はい、私も参加する前はコードの貢献者でした。 (ptschip)

Q: これは BIP プロセスに関する苦情なので、私はこう尋ねました…BU 開発チームは BIP プロセスに引き続き反対しているのでしょうか? BIP プロセスではない場合でも、コラボレーションを促進するプロセスを構築するにはどうすればよいでしょうか?

A: BU メンバーの一部は、Core フォーラムに存在していた「ブロプログラマー」文化を排除するために脱退しました。そしてフォーラムの検閲には近づかないでください。数か月前、私は、Core で十分に説明および実証されていなかったため、番号が割り当てられたことのない機能ビットを使用するために BIP を発行しようとしました。しかし、BIP プログラムは、活動を調整するためだけに、レビューのためにプロセス、文化、コミュニケーション チャネルに私を強制すべきではないことを理解する必要があります。もう一度提出する方法はありません…状況が変わったのかもしれません。しかし、私たちはより効果的な変化のシグナルを探しており、Xthin の再実装のようなことを行うことで、そのシグナルに対して本当に意味があることがわかります。 （ザザーグ）

Q: Xthin について説明していただけますか?ブロック サイズが大きくなると xthin のパフォーマンスは変化しますか?

A: Xthin ブロック (平均で 95% の帯域幅削減) では、必要なメモリプールが小さくなるため、大きなブロックでパフォーマンスが向上すると思います。 （病人豚）

追加の質問:メモリプールのサイズを小さくしますか?もっと大きいってことですか？

反対の質問:なぜ大きいのですか? （病人豚）

追加の質問: 混乱しています。メモリ プールのパフォーマンスについて説明していただけますか :)

追加の回答: 混雑したネットワークではトランザクションのパッケージングのニーズを満たすことができず、メモリプールが大きくなると思います (sickpig)

ブロック サイズが大きくなるにつれて、パフォーマンスの維持はメモリ プールの同期に依存します。多少の低下は予想されます。たとえば、1 MB ブロックと 10 MB ブロック、およびより高いトランザクション増加率について話している場合、メモリプールの容量あたりがわずかに異なる可能性があります。 (ptschip)

xthin tl;dr (翻訳者注: 今のところ、この 2 つの文字の意味はわかりません) 1 つのブロックと次のブロックの間の期間中に 1 つのトランザクションのみを送信します。 （病人豚）

面白いのは、マイナーが「ゲーム」をしてブロックにトランザクションを追加し続けると、Xthin のパフォーマンスが悪化するということです。したがって、理論上は、巨大なブロックを作成するためにブロックを偽のトランザクションで埋めるマイナーは、そのようなブロックが適切にブロードキャストされないため、成功するのが困難になります。これらの「攻撃ブロック」は孤立率が非常に高くなり、したがってこれらの「攻撃ブロック」は孤立率が非常に高くなり、潜在的な空のブロックがこの大きな「攻撃ブロック」を破壊することになります... (thezerg)

Q: @Andrew Stone 単一のコミットされたアーキテクチャは複数のものよりも優れていると思いますか?

Q: コンセプトが承認された場合、コードの品質をどのように管理しますか?

A: 誰かがコードのパフォーマンス要求を提出すると、私 (および他の人) がそれをレビューしてテストします。私はすべてのコード行を読みます。そのため、パフォーマンスが要求されるコードほど時間がかかります。今後、私の時間がボトルネックになる場合は、最初のレビューの責任を他の開発者に委任します。通常のテスト「make check」と python qa を実行して拡張します。また、複数のブロックチェーン (メインチェーン、テストネット、nol チェーン) のテストに使用する、グローバルに実行される専用のノード ネットワークもあります。これらのノードでは、運用テスト用に個人用のマイナーとプール ソフトウェアを実行しています。また、BU を実行する Windows、Linux 32/64、Mac、および 4 台の ARM マシンがあります。そのため、このソフトウェアを実際の状況でテストする能力が十分にあります (thezerg)

私たちのプログラムがすべて Core と異なるとは思いません。コードレビューがあり、ユニットテストと回帰テストも行います。現在、Travis を使用して回帰テストを自動化しており、パフォーマンス要件がコミットされると、すべてのテストに合格することがわかっています。 (ptschip)

大幅なパフォーマンス改善のために、適切なレビュー、テスト、CI、BUIP を実施しています。これらは現在も実施しており、今後も継続して実施していきます (CI = 継続的インテグレーション)。 （病人豚）

翻訳者注: これは WeChat グループ内のクイズ番組であるため、一部の文法や語彙は特に厳密ではなく、翻訳が非常に困難です。翻訳に誤りがありましたら、お許しの上ご指摘ください。ありがとう。

原文はまだウェブページに移動されていないので、興味のある友人がダウンロードして読めるように Baidu Netdisk にアップロードしました。

リンク: https://pan.baidu.com/s/1eSHTW10 パスワード: 6vii

元の文書は @jake Lu Rui によって編集され、提供されました。