Newsletter-259:Translate into Japanese

Author: azuchi

_includes/specials/policy/ja/09-proposals.md

@@ -0,0 +1,88 @@
+[先週の記事][policy08]では、[アンカーアウトプット][topic anchor outputs]と
+[CPFP carve out][topic cpfp carve out]について説明しました。
+これにより、どちらのチャネル参加者も、協力することなく共有されたコミットメントトランザクションの手数料を
+引き上げることができます。このアプローチには、まだいくつかの欠点があります。
+アンカーアウトプットを作成するためにチャネル資金が拘束され、
+コミットメントトランザクションの手数料率は、mempoolの最小手数料率を満たすことを保証するために、
+通常過大に支払われ、CPFP carve outでは追加の子孫は１つしか認められません。
+アンカーアウトプットでは、[Coinjoin][topic coinjoin]やマルチパーティコントラクトプロトコルなど、
+２人よりも多い参加者間で共有されるトランザクションの手数料の引き上げを保証することはできません。
+この記事では、これらの制限やその他の制限に対処するための現在の取り組みについて説明します。
+
+[パッケージリレー][topic package relay]には、トランザクショングループの転送と検証を可能にする
+P2Pプロトコルとポリシーの変更が含まれています。
+これは、コミットメントトランザクションがmempoolの最小手数料率を満たしていない場合でも、
+子によるコミットメントトランザクションの手数料の引き上げを可能にします。
+さらに、_パッケージRBF_ は、子トランザクションによる
+競合する親トランザクションの[置換][topic rbf]のための手数料の引き上げを可能にします。
+パッケージリレーは、ベースプロトコルレイヤーにおける一般的な制限を取り除くように設計されています。
+しかし、共有トランザクションの手数料の引き上げにおけるその有用性から、
+特定のユースケースにおける[Pinning][topic transaction pinning]を排除するための多くの取り組みも生まれています。
+たとえば、パッケージRBFは、コミットメントトランザクションがそれぞれの手数料引き上げの子トランザクションと一緒にブロードキャストされる際に、
+相互に置換できるため、各コミットメントトランザクションに複数のアンカーアウトプットは必要なくなります。
+
+注意すべき点は、既存のRBFルールでは、置換トランザクションには、
+置換されるすべてのトランザクションによって支払われる合計手数料よりも高い手数料を支払う必要があるという点です。
+このルールは、置換の繰り返しによるDoSを防ぐのに役立ちますが、
+悪意あるユーザーが、低手数料率であるものの手数料額は高い子トランザクションをアタッチすることで、
+トランザクションを置換する際のコストを増加させることを可能にします。
+これは、高手数料率パッケージによるトランザクションの置換を不当に阻止することで、
+トランザクションがマイニングされるのを妨げるものであり、よく「ルール３Pinning」と呼ばれています。
+
+開発者はまた、署名済みトランザクションに手数料を追加する全く異なる方法を提案しています。
+たとえば、`SIGHASH_ANYONECANPAY | SIGHASH_ALL`を使用してトランザクションのインプットに署名することで、
+トランザクションブロードキャスターは、アウトプットを変更することなく、トランザクションにインプットを追加して手数料を提供できます。
+しかしながら、RBFには置換トランザクションがより高い「マイニングスコア」を持つこと（つまり、より速くブロックに選択される）を
+要求するルールがないため、攻撃者は低手数料率の祖先に邪魔される置換トランザクションを作成することで、
+この種のトランザクションをPinning可能です。
+トランザクションおよびトランザクションパッケージのマイニングスコアの正確な評価を複雑にしているのは、
+既存の祖先と子孫の制限が、この計算の計算量を制限するには不十分であることです。
+接続されているトランザクションは、トランザクションがブロックに選択される順序に影響を与える可能性があります。
+_クラスター_ とよばれる完全に接続されたコンポーネントは、現在の祖先と子孫の制限があれば、
+任意のサイズにすることができます。
+
+一部のmempoolの欠陥とRBFのPinning攻撃に対処するための長期的な解決策は、
+[mempoolのデータ構造を再構築して][mempool clustering]、
+祖先と子孫のセットだけでなくクラスターを追跡することです。これらのクラスターのサイズは制限されます。
+クラスターの制限により、ユーザーが未承認のUTXOを使用できる方法が制限されますが、
+祖先スコアベースのマイニングアルゴリズムを使用してmempool全体を線形化し、
+ブロックテンプレートを極めて迅速に構築し、置換トランザクションのマイニングスコアが
+置換されるトランザクションよりも高いという要件を追加することは可能になります。
+
+それでも、トランザクションリレーの幅広いニーズと期待に応えるための単一のポリシーセットは存在しない可能性があります。
+たとえば、バッチ処理された支払いは、多数の未承認の子孫を必要とするかもしれませんが、
+これは総手数料を通じて共有トランザクションのパッケージRBFをPinningする余地を残します。
+[v3トランザクションリレーポリシー][topic v3 transaction relay]の提案は、
+コントラクトプロトコルがより制限的なパッケージ制限のセットをオプトインできるようにするために開発されました。
+v3トランザクションは、サイズ2（親1つ子1つ）のパッケージのみを許可し、子のweightを制限します。
+これらの制限は、総手数料を通じたRBF Pinningを緩和し、
+mempoolの再構築を必要とせずにクラスターmempoolのメリットの一部を提供します。
+
+[エフェメラルアンカー][topic ephemeral anchors]は、v3トランザクションとパッケージリレーの特性をベースに、
+アンカーアウトプットをさらに改善するための提案です。これは、手数料ゼロのv3トランザクションに属するアンカーアウトプットが、
+手数料を引き上げる子トランザクションによって使用される場合に限り、[ダスト制限][topic uneconomical outputs]から免除されます。
+手数料ゼロのトランザクションは、正確に1つの子トランザクションによって手数料を引き上げる必要があるため
+（そうしないと、マイナーはそれをブロックに含めるインセンティブを得られません）、
+このアンカーアウトプットは「エフェメラル」であり、UTXOセットの一部にはなりません。
+エフェメラルアンカーの提案により、チャネルクローズトランザクションの手数料供給メカニズムとして
+[CPFP][topic cpfp]を使用した[LN symmetry][topic eltoo]が実現可能になります。
+また、このメカニズムは、3人以上の参加者で共有されるトランザクションにも利用可能です。
+開発者は、[bitcoin-inquisition][bitcoin inquisition repo]を使用してエフェメラルアンカーをデプロイし、
+[signet][topic signet]上でこれらのマルチレイヤーの変更を構築してテストするためのソフトフォークを提案しています。
+
+この記事で強調されたPinningの問題は、昨年、メーリングリストやプルリクエスト、
+ソーシャルメディア、直接の会議を通じて[RBFポリシーを改善するための豊富な議論や提案][2022 rbf]を生み出しました。
+開発者は、小さな修正から完全な刷新に至るまで、さまざまな解決策を提案し、実装しました。
+`-mempoolfullrbf`オプションは、Pinningの懸念とBIP125実装の不一致に対処することを意図したもので、
+トランザクションリレーポリシーにおけるコラボレーションの難しさと重要性を浮き彫りにしました。
+1年前にbitcoin-devメーリングリストで会話を始めるなど、一般的な手段を使って
+コミュニティを巻き込もうとする真摯な努力がされましたが、
+既存のコミュニケーションや意思決定の方法が意図した結果を生んでおらず、改善が必要であることは明らかでした。
+
+非中央集権的な意思決定は困難なプロセスですが、Bitcoinのトランザクションリレーネットワークを利用する
+プロトコルやアプリケーションの多様なエコシステムをサポートするためには必要です。
+来週は、このシリーズの最終回で、読者の皆さんにこのプロセスへの参加と改善を奨励していただきたいと考えています。
+
+[mempool clustering]: https://github.com/bitcoin/bitcoin/issues/27677
+[policy08]: /ja/newsletters/2023/07/05/#承認を待つ-8-インターフェースとしてのポリシー
+[2022 rbf]: /ja/newsletters/2022/12/21/#rbf

_posts/ja/2023-05-17-policy.md

@@ -74,6 +74,12 @@ h2:not(:first-of-type) { margin-top: 3em; }
 
 {% include specials/policy/ja/08-interface.md %}
 
+## ポリシーの提案
+
+*[ニュースレター #259](/ja/newsletters/2023/07/12/#承認を待つ-9-ポリシーの提案)*
+
+{% include specials/policy/ja/09-proposals.md %}
+
 {% comment %}<!--
 ## 脚注
 {:.no_toc}