原作者:シノビオリジナルコンピレーション:ブロックユニコーン提案の範囲にもかかわらず、Rusty Russellの「素晴らしいスクリプトの回復」がビットコインの開発の前進の道になる可能性がある理由は何ですか?ブロックユニコーン 注:Rusty Russellはビットコインコミュニティのアクティブな開発者であり、コミュニティで非常に尊敬されています。 Linuxカーネル開発に幅広く携わり、多くのロング ビットコインコア開発プロジェクトに携わってきました。ビットコインはもともと、ユーザーが将来思いつく可能性のある潜在的なセキュリティユースケースをカバーしてサポートするように設計された完全なスクリプト言語を持つように設計されています。 サトシナカモトが失踪する前に言ったように:「ビットコインの本質は、バージョン0.1がリリースされると、残りのライフサイクルのコア設計が決定されることです。 したがって、考えられるすべての可能な取引タイプをサポートするように設計したいと思いました。 問題は、使用されているかどうかにかかわらず、すべてに特別なサポートコードとデータフィールドが必要であり、それが最も長い特別なケースにつながることです。 解決策は、問題を一般化するスクリプトであり、ノードネットワークがそれらの条件に基づいて評価または検証する特定の条件で両当事者がトランザクションを記述できるようにします。」 - サトシナカモト 2010年6月17日彼の全体的な目的は、ユーザーが望むようにトランザクションの種類を整理するのに十分なほど一般的な言語を提供することです。 つまり、ユーザーが自分のコインの書き方をデザインして実験するためのショーツです。彼が姿を消す前に、サトシナカモトはこれらの操作コードのうち15を削除し、それらを完全に無効にし、操作できるデータブロックのサイズ(520バイト)を制限するスクリプトエンジンスタックにハード制限を追加しました。 これは、彼が実際に失敗し、複雑なスクリプトを使用してネットワーク全体でDOS攻撃を実行する(多数のスパムリクエストを送信し、ネットワークをダウンさせる)多くの方法を残し、ノードをクラッシュさせる巨大でコストのかかるトランザクションを作成したためです。これらの操作コードが削除されたのは、サトシナカモトが機能が危険であると考えたため、または人々がそれらを使用して達成可能なものを構築するべきではないと考えたためではなく、単に(少なくとも表面上は)リソースの制約なしにネットワーク全体にもたらすリスクのために、制限なしでネットワークに課すことができる最悪の検証コスト。それ以来、ビットコインの各アップグレードは、残りの機能の機能最適化であり、サトシナカモトが私たちに残した他のそれほど深刻ではない欠陥を修正し、残りのスクリプトサブセットの機能を拡張しました。## 素晴らしいスクリプトの回復5月初旬のオースティンビットコイン++カンファレンスで、ライトニングネットワークのコア開発者であるラスティラッセルは、カンファレンスでの最初のスピーチで非常に過激な提案を行い、2010年にサトシナカモトが消える前に無効にした大きな憧れのオペレーションコードを再び有効にするというアイデアを基本的に思いつきました。2021年にタップルートがアクティブ化されて以来(タップルートはプライバシー、セキュリティ、スケーラビリティの向上を目的としたビットコインのメジャーアップグレードです)、開発スペースは実際には少し目的がありませんでした。 ビットコインは、世界人口のかなりの規模に自己主権型サービスを真に提供できるほどスケーラブルではなく、非常に大規模なカストディアンやサービスプロバイダーを超えることができるサービスプロバイダーにスケーラビリティを提供することさえできず、信頼や保管を最小限に抑える方法で政府のロングアームの制約から真に自由になることができない可能性があることは誰もが知っています。この記事では、ビットコインの技術レベルを指摘していますが、これは議論の余地のある問題ではありません。 議論に値する問題は、この欠陥をどのように修正するかであり、これは非常に物議を醸すトピックです。 タップルートが導入されて以来、誰もが特定のユースケースでしか達成できない問題を解決することを目的とした非常に狭い提案を考え出してきました。たとえば、ANYPREVOUT(APO)は、スクリプトと入力された量が同じであるロングと同様に、署名を異なるトランザクションで再利用できるようにする提案であり、この提案は、ライトニングネットワークとそのロングバージョンを最適化するように特別に設計されています。 CHECKTEMPLATEVERIFY(CTV)は、事前定義されたトランザクションと完全に一致するトランザクションによってのみハードコインを使用することを要求する提案であり、この提案は、事前に署名されたトランザクションチェーンを完全にトラストレスにすることで機能を拡張するように設計されています。 OP\_VAULT は、コールド ストレージ ソリューションの "タイムアウト" を設定するように特別に設計されているため、ユーザーはコールド ストレージをよりコールド ロング設定に送信してコールド ストレージから "フェッチ解除" し、秘密鍵が危険にさらされるのを防ぐことができます。他にも長い提案がありますが、要点はもうおわかりいただけたと思います。 過去数年間、各提案は、スケーラビリティをわずかに向上させるか、1 つの小さな機能を改善するように設計されてきました。 それが議論が進まない根本的な原因です。 他の提案は、彼らが見たいユースケースを満たしていなかったため、誰も満足しませんでした。提案のスポンサー以外の誰も、提案が合理的な次のステップと見なされるほど包括的であるとは考えていません。これが「Great Script Recovery」の背後にあるロジックです。 サトシナカモトが最初に設計したように、スクリプトの完全な回復をプッシュして分析することで、どの小さな機能拡張機能が今すぐ十分であるかについて議論したり内輪になったりするのではなく、必要な機能ショート全体を実際に探索しようとすることができます。## オペコード (オペレーションコード)* OP\_CAT: スタックから 2 つのデータを取り出し、それらを加算して 1 つのデータを形成します。* OP\_SUBSTR: 長さパラメータ (バイト単位) を受け取り、スタックからデータの一部を取得し、その長さのバイトを削除してスタックに戻します。* OP\_LEFT と OP\_RIGHT: スタックからデータの一部を取得し、指定された長さのバイトを一方または他方から削除する長さパラメータを受け入れます。* OP\_INVERT、OP\_AND、OP\_OR、OP\_XOR、OP\_UPSHIFT、OP\_DOWNSHIFT: データ要素を受け取り、対応するビット演算を実行します。* OP\_ 2 MUL, OP\_2D IV, OP\_MUL, OP\_DIV, OP\_MOD: 乗算、除算、モジュロ演算の算術演算子 (除算の余りを返す)。上記の回復する操作コードの上場に加えて、Rusty Russellは、異なる操作コードの組み合わせを簡素化するように設計されたさらに3つの操作コードを提案しています。OP\_CTV (または TXHASH/ と同等のオペレーションコード): 事前定義されたとおりにする必要があるトランザクションの特定の部分をきめ細かく適用できます。CSFS: トランザクション全体だけでなく、スクリプトの特定の部分または使用されるデータを実行するために注文に署名する必要がある署名を検証できます。OP\_TWEAKVERIFY: 集計公開鍵に対する個々の公開鍵の加算や減算など、公開鍵を伴う Schnorr ベースの操作を検証します。 これは、一方の当事者が共有未使用のトランザクション出力(UTXO)を一方的に残した場合に、他のすべての参加者の資金が、共同支出を行うために出発する当事者の署名を必要としない集約された公開鍵に送信されるようにするために使用できます。## なぜこれを行うのかレイヤー2ネットワークは本質的にビットコインのベースレイヤーの拡張であり、ベースレイヤーの機能によって機能的に制約されています。 ライトニングネットワーク実際に実装するには、CHECKLOCKTIMEVERIFY (CLTV)、checksequenceverify (csv)、セグウィット (隔離された署名領域) の 3 つの個別のソフトフォークが必要です。より柔軟なベースレイヤーがなければ、より柔軟なレイヤー 2 ネットワークを構築できません。 唯一の近道はサードパーティを信頼することですが、これは非常に単純明快であり、ビットコインとの相互作用のあらゆる側面から信頼できるサードパーティを可能な限り大規模に排除することを私たち全員が熱望することを願っています。2人以上の人を1つの未使用のトランザクション出力(UTXO)に安全にマージし、ベースレイヤーでトラストレスに実行できるようにするために、現在注文では不可能なことを実行できる必要があります。 ビットコインスクリプトの現在の柔軟性は十分ではありません。 最も基本的なレベルでは、コントラクトが必要であり、ユーザーが自分のUTXOを安全に終了しても他のユーザーの資金が危険にさらされないようにするために、トランザクションの実行に関するより詳細な詳細を実際に適用できるスクリプトが必要です。より高い視点では、これが必要なものです。イントロスペクション: 「この金額は、あるアウトプットのこの公開鍵に送られる」など、支出トランザクション自体に関するスタック上の特定の詳細を実際に確認できる必要があります。 これにより、他の人の資金を引き出すことができないようにしながら、自分の特定のタップルートブランチを使用して自分で資金を引き出すことができます。 実行されたスクリプトは、他の参加者が資金の損失を引き起こした場合に備えて、他の所有者の資金が他のユーザーの公開鍵で構成されるアドレスに送り返されるようにします。フォワードデータキャリング:たとえば、多数の人がいる単一のUTXOの概念を考えてみましょう。 この場合、通常はメークルツリーとそのルーツを使用して、誰が最も長いまたは少ないお金を持っているかを追跡する方法が必要です。 これは、誰かが去るとき、他の全員の資金の変更UTXOの一部として、誰が何を受け取る権利があるかを確実に「記録」する必要があることを意味します。 これは基本的に、イントロスペクションの特定の使用法です。公開鍵の変更: 集計公開鍵への変更がスタックで検証できることを確認する必要があります。 未使用トランザクションアウトプット(UTXO)共有スキームでは、すべての参加者を含む集約された公開鍵を通じて、協力と効率的な資金の流れを促進することを目標としています。 誰かが一方的に共有UTXOを離れる場合、集約された公開鍵から個人の公開鍵を削除する必要があります。 すべての可能な組み合わせが事前に計算されていない場合、唯一のオプションは、集約された公開キーから 1 つの公開キーを引くと、残りの個々の公開キーで構成される有効な公開キーが生成されることを確認することです。安全の方法:VAROPS 上で述べたように、これらすべての操作コードを無効にする理由は、ネットワークを構成するノードをクラッシュさせる可能性のあるDOS攻撃(多数のスパムリクエストを送信してネットワークをクラッシュさせる)に対処するためです。 この問題を解決する方法の 1 つは、これらの操作コードのいずれかで使用できるリソースの量を制限することです。ビットコインスクリプトの最も高価な部分である署名検証に関しては、署名操作(sigops)バジェットと呼ばれるそのようなソリューションがすでにあります。 署名チェックオペレーションコードを使用するたびに、特定の「予算」、つまりブロックごとに許可される署名操作の数が消費され、トランザクションがブロックを検証するために生成できるコストのハード制限が設定されます。タップルートはこの作業方法を変更し、単一のグローバルブロック制限を使用するロングはありませんが、代わりに各トランザクションには、トランザクションのサイズに比例した独自のシゴップ(署名操作)制限があります。 これは基本的に同じグローバル制限に等しくなりますが、各トランザクションで使用可能なシゴップがロング少なくなっていることを理解する方が簡単です。各トランザクションを処理するためのタップルートのsigops(署名操作)制限の変更は、Rusty Russellがvarops制限に関して提案した一般化アプローチの可能性を開きます。 アイデアは、再アクティブ化された各オペレーションコードに、各オペレーションコードが作成する可能性のある最悪のシナリオ、つまり検証時に発生する最も高価な計算コストのアカウントにコストを割り当てることです。 このようにして、各オペレーションコードには独自の「sigops」制限があり、検証プロセス中に消費できるリソースの量が制限されます。 これは、これらのオペレーションコードを使用するトランザクションのサイズにも基づくため、ブロックごとの暗黙的なグローバル制限に累積しながら推論を容易にすることができます。これにより、これらのスパムトランザクションによるDOS攻撃(大量のスパムリクエストを送信し、ネットワークをクラッシュさせることによる)が解決され、サトシナカモトが最初にこれらすべての操作コードを無効にした原因となります。## 前進の勢い「これは変化が多すぎる」と思う方も多いのではないでしょうか。 それは理解できますが、提案として理解すべき重要な側面は、すべてをやる必要はないということです。 この提案の価値は、必ずしもこれらの機能がすべて完全に復元されるということではなく、基本的なコンポーネントの膨大なスイートを全体的に見て、機能の観点から本当に必要なものは何かを自問することです。過去3年間の口論と議論から完全に転換し、特定の機能しか持たない小さな狭い変化についてのみ議論してきました。 みんなが集まって未来の方向性を考える広場のようなものです。 もしかしたら、最終的にはこれらの機能をすべて復元するかもしれませんし、コンセンサスは、私たち全員がオンにする必要があると同意している機能であるため、そのうちのいくつかだけをアクティブにすることになるかもしれません。最終的な結果がどうであれ、これは私たちの将来の方向性についての会話全体にプラスの影響を与える変化になる可能性があります。 私たちは実際に計画を立てて状況の全体像を把握することができ、次にどの曖昧なルートを取るべきかを手探りで議論する必要はありません。決して進まなければいけない道ではありませんが、どの道を進むかを決める絶好のチャンスだと思います。 今こそ、実用的かつ生産的な方法で再び協力し始める時です。
素晴らしいスクリプトの回復:ビットコインの前進
原作者:シノビ
オリジナルコンピレーション:ブロックユニコーン
提案の範囲にもかかわらず、Rusty Russellの「素晴らしいスクリプトの回復」がビットコインの開発の前進の道になる可能性がある理由は何ですか?
ブロックユニコーン 注:Rusty Russellはビットコインコミュニティのアクティブな開発者であり、コミュニティで非常に尊敬されています。 Linuxカーネル開発に幅広く携わり、多くのロング ビットコインコア開発プロジェクトに携わってきました。
ビットコインはもともと、ユーザーが将来思いつく可能性のある潜在的なセキュリティユースケースをカバーしてサポートするように設計された完全なスクリプト言語を持つように設計されています。 サトシナカモトが失踪する前に言ったように:
「ビットコインの本質は、バージョン0.1がリリースされると、残りのライフサイクルのコア設計が決定されることです。 したがって、考えられるすべての可能な取引タイプをサポートするように設計したいと思いました。 問題は、使用されているかどうかにかかわらず、すべてに特別なサポートコードとデータフィールドが必要であり、それが最も長い特別なケースにつながることです。 解決策は、問題を一般化するスクリプトであり、ノードネットワークがそれらの条件に基づいて評価または検証する特定の条件で両当事者がトランザクションを記述できるようにします。」 - サトシナカモト 2010年6月17日
彼の全体的な目的は、ユーザーが望むようにトランザクションの種類を整理するのに十分なほど一般的な言語を提供することです。 つまり、ユーザーが自分のコインの書き方をデザインして実験するためのショーツです。
彼が姿を消す前に、サトシナカモトはこれらの操作コードのうち15を削除し、それらを完全に無効にし、操作できるデータブロックのサイズ(520バイト)を制限するスクリプトエンジンスタックにハード制限を追加しました。 これは、彼が実際に失敗し、複雑なスクリプトを使用してネットワーク全体でDOS攻撃を実行する(多数のスパムリクエストを送信し、ネットワークをダウンさせる)多くの方法を残し、ノードをクラッシュさせる巨大でコストのかかるトランザクションを作成したためです。
これらの操作コードが削除されたのは、サトシナカモトが機能が危険であると考えたため、または人々がそれらを使用して達成可能なものを構築するべきではないと考えたためではなく、単に(少なくとも表面上は)リソースの制約なしにネットワーク全体にもたらすリスクのために、制限なしでネットワークに課すことができる最悪の検証コスト。
それ以来、ビットコインの各アップグレードは、残りの機能の機能最適化であり、サトシナカモトが私たちに残した他のそれほど深刻ではない欠陥を修正し、残りのスクリプトサブセットの機能を拡張しました。
素晴らしいスクリプトの回復
5月初旬のオースティンビットコイン++カンファレンスで、ライトニングネットワークのコア開発者であるラスティラッセルは、カンファレンスでの最初のスピーチで非常に過激な提案を行い、2010年にサトシナカモトが消える前に無効にした大きな憧れのオペレーションコードを再び有効にするというアイデアを基本的に思いつきました。
2021年にタップルートがアクティブ化されて以来(タップルートはプライバシー、セキュリティ、スケーラビリティの向上を目的としたビットコインのメジャーアップグレードです)、開発スペースは実際には少し目的がありませんでした。 ビットコインは、世界人口のかなりの規模に自己主権型サービスを真に提供できるほどスケーラブルではなく、非常に大規模なカストディアンやサービスプロバイダーを超えることができるサービスプロバイダーにスケーラビリティを提供することさえできず、信頼や保管を最小限に抑える方法で政府のロングアームの制約から真に自由になることができない可能性があることは誰もが知っています。
この記事では、ビットコインの技術レベルを指摘していますが、これは議論の余地のある問題ではありません。 議論に値する問題は、この欠陥をどのように修正するかであり、これは非常に物議を醸すトピックです。 タップルートが導入されて以来、誰もが特定のユースケースでしか達成できない問題を解決することを目的とした非常に狭い提案を考え出してきました。
たとえば、ANYPREVOUT(APO)は、スクリプトと入力された量が同じであるロングと同様に、署名を異なるトランザクションで再利用できるようにする提案であり、この提案は、ライトニングネットワークとそのロングバージョンを最適化するように特別に設計されています。 CHECKTEMPLATEVERIFY(CTV)は、事前定義されたトランザクションと完全に一致するトランザクションによってのみハードコインを使用することを要求する提案であり、この提案は、事前に署名されたトランザクションチェーンを完全にトラストレスにすることで機能を拡張するように設計されています。 OP_VAULT は、コールド ストレージ ソリューションの "タイムアウト" を設定するように特別に設計されているため、ユーザーはコールド ストレージをよりコールド ロング設定に送信してコールド ストレージから "フェッチ解除" し、秘密鍵が危険にさらされるのを防ぐことができます。
他にも長い提案がありますが、要点はもうおわかりいただけたと思います。 過去数年間、各提案は、スケーラビリティをわずかに向上させるか、1 つの小さな機能を改善するように設計されてきました。 それが議論が進まない根本的な原因です。 他の提案は、彼らが見たいユースケースを満たしていなかったため、誰も満足しませんでした。
提案のスポンサー以外の誰も、提案が合理的な次のステップと見なされるほど包括的であるとは考えていません。
これが「Great Script Recovery」の背後にあるロジックです。 サトシナカモトが最初に設計したように、スクリプトの完全な回復をプッシュして分析することで、どの小さな機能拡張機能が今すぐ十分であるかについて議論したり内輪になったりするのではなく、必要な機能ショート全体を実際に探索しようとすることができます。
オペコード (オペレーションコード)
上記の回復する操作コードの上場に加えて、Rusty Russellは、異なる操作コードの組み合わせを簡素化するように設計されたさらに3つの操作コードを提案しています。
OP_CTV (または TXHASH/ と同等のオペレーションコード): 事前定義されたとおりにする必要があるトランザクションの特定の部分をきめ細かく適用できます。
CSFS: トランザクション全体だけでなく、スクリプトの特定の部分または使用されるデータを実行するために注文に署名する必要がある署名を検証できます。
OP_TWEAKVERIFY: 集計公開鍵に対する個々の公開鍵の加算や減算など、公開鍵を伴う Schnorr ベースの操作を検証します。 これは、一方の当事者が共有未使用のトランザクション出力(UTXO)を一方的に残した場合に、他のすべての参加者の資金が、共同支出を行うために出発する当事者の署名を必要としない集約された公開鍵に送信されるようにするために使用できます。
なぜこれを行うのか
レイヤー2ネットワークは本質的にビットコインのベースレイヤーの拡張であり、ベースレイヤーの機能によって機能的に制約されています。 ライトニングネットワーク実際に実装するには、CHECKLOCKTIMEVERIFY (CLTV)、checksequenceverify (csv)、セグウィット (隔離された署名領域) の 3 つの個別のソフトフォークが必要です。
より柔軟なベースレイヤーがなければ、より柔軟なレイヤー 2 ネットワークを構築できません。 唯一の近道はサードパーティを信頼することですが、これは非常に単純明快であり、ビットコインとの相互作用のあらゆる側面から信頼できるサードパーティを可能な限り大規模に排除することを私たち全員が熱望することを願っています。
2人以上の人を1つの未使用のトランザクション出力(UTXO)に安全にマージし、ベースレイヤーでトラストレスに実行できるようにするために、現在注文では不可能なことを実行できる必要があります。 ビットコインスクリプトの現在の柔軟性は十分ではありません。 最も基本的なレベルでは、コントラクトが必要であり、ユーザーが自分のUTXOを安全に終了しても他のユーザーの資金が危険にさらされないようにするために、トランザクションの実行に関するより詳細な詳細を実際に適用できるスクリプトが必要です。
より高い視点では、これが必要なものです。
イントロスペクション: 「この金額は、あるアウトプットのこの公開鍵に送られる」など、支出トランザクション自体に関するスタック上の特定の詳細を実際に確認できる必要があります。 これにより、他の人の資金を引き出すことができないようにしながら、自分の特定のタップルートブランチを使用して自分で資金を引き出すことができます。 実行されたスクリプトは、他の参加者が資金の損失を引き起こした場合に備えて、他の所有者の資金が他のユーザーの公開鍵で構成されるアドレスに送り返されるようにします。
フォワードデータキャリング:たとえば、多数の人がいる単一のUTXOの概念を考えてみましょう。 この場合、通常はメークルツリーとそのルーツを使用して、誰が最も長いまたは少ないお金を持っているかを追跡する方法が必要です。 これは、誰かが去るとき、他の全員の資金の変更UTXOの一部として、誰が何を受け取る権利があるかを確実に「記録」する必要があることを意味します。 これは基本的に、イントロスペクションの特定の使用法です。
公開鍵の変更: 集計公開鍵への変更がスタックで検証できることを確認する必要があります。 未使用トランザクションアウトプット(UTXO)共有スキームでは、すべての参加者を含む集約された公開鍵を通じて、協力と効率的な資金の流れを促進することを目標としています。 誰かが一方的に共有UTXOを離れる場合、集約された公開鍵から個人の公開鍵を削除する必要があります。 すべての可能な組み合わせが事前に計算されていない場合、唯一のオプションは、集約された公開キーから 1 つの公開キーを引くと、残りの個々の公開キーで構成される有効な公開キーが生成されることを確認することです。
安全の方法:VAROPS 上で述べたように、これらすべての操作コードを無効にする理由は、ネットワークを構成するノードをクラッシュさせる可能性のあるDOS攻撃(多数のスパムリクエストを送信してネットワークをクラッシュさせる)に対処するためです。 この問題を解決する方法の 1 つは、これらの操作コードのいずれかで使用できるリソースの量を制限することです。
ビットコインスクリプトの最も高価な部分である署名検証に関しては、署名操作(sigops)バジェットと呼ばれるそのようなソリューションがすでにあります。 署名チェックオペレーションコードを使用するたびに、特定の「予算」、つまりブロックごとに許可される署名操作の数が消費され、トランザクションがブロックを検証するために生成できるコストのハード制限が設定されます。
タップルートはこの作業方法を変更し、単一のグローバルブロック制限を使用するロングはありませんが、代わりに各トランザクションには、トランザクションのサイズに比例した独自のシゴップ(署名操作)制限があります。 これは基本的に同じグローバル制限に等しくなりますが、各トランザクションで使用可能なシゴップがロング少なくなっていることを理解する方が簡単です。
各トランザクションを処理するためのタップルートのsigops(署名操作)制限の変更は、Rusty Russellがvarops制限に関して提案した一般化アプローチの可能性を開きます。 アイデアは、再アクティブ化された各オペレーションコードに、各オペレーションコードが作成する可能性のある最悪のシナリオ、つまり検証時に発生する最も高価な計算コストのアカウントにコストを割り当てることです。 このようにして、各オペレーションコードには独自の「sigops」制限があり、検証プロセス中に消費できるリソースの量が制限されます。 これは、これらのオペレーションコードを使用するトランザクションのサイズにも基づくため、ブロックごとの暗黙的なグローバル制限に累積しながら推論を容易にすることができます。
これにより、これらのスパムトランザクションによるDOS攻撃(大量のスパムリクエストを送信し、ネットワークをクラッシュさせることによる)が解決され、サトシナカモトが最初にこれらすべての操作コードを無効にした原因となります。
前進の勢い
「これは変化が多すぎる」と思う方も多いのではないでしょうか。 それは理解できますが、提案として理解すべき重要な側面は、すべてをやる必要はないということです。 この提案の価値は、必ずしもこれらの機能がすべて完全に復元されるということではなく、基本的なコンポーネントの膨大なスイートを全体的に見て、機能の観点から本当に必要なものは何かを自問することです。
過去3年間の口論と議論から完全に転換し、特定の機能しか持たない小さな狭い変化についてのみ議論してきました。 みんなが集まって未来の方向性を考える広場のようなものです。 もしかしたら、最終的にはこれらの機能をすべて復元するかもしれませんし、コンセンサスは、私たち全員がオンにする必要があると同意している機能であるため、そのうちのいくつかだけをアクティブにすることになるかもしれません。
最終的な結果がどうであれ、これは私たちの将来の方向性についての会話全体にプラスの影響を与える変化になる可能性があります。 私たちは実際に計画を立てて状況の全体像を把握することができ、次にどの曖昧なルートを取るべきかを手探りで議論する必要はありません。
決して進まなければいけない道ではありませんが、どの道を進むかを決める絶好のチャンスだと思います。 今こそ、実用的かつ生産的な方法で再び協力し始める時です。