RippleのCTO、David Schwartzは最近、数ヶ月にわたり稼働している彼のXRP Ledgerハブについてのアップデートを共有しました。
RippleのCTOによるXRP Ledgerハブのアップデートは、暗号コミュニティから反響を呼びました。あるXユーザーはその安定性を称賛しつつ、rippledのアップグレードやXRP Ledgerの修正プロセスに関する重要な質問を提起しました。
XRP Ledgerは、取引処理に影響を与える変更を承認するためにコンセンサスプロセスを利用した修正システムを採用しており、バリデーターが投票します。修正案が2週間以上80%以上の支持を得た場合、その修正案は承認され、すべての後続の台帳バージョンに恒久的に適用されます。
このXユーザーは、dUNLサーバー上の多くのバージョンのrippledのケースを挙げて、修正プロセスをrippledのアップグレードを可能にするために適用できるかどうかを尋ねました。
11月に、rippled v2.6.2リリースが公開され、新たにfixDirectoryLimit修正案と重要なバグ修正が追加されました。12月18日に「fixDirectoryLimit」修正案が有効化されると、多くのノードがアップグレードしなかったため、「修正案ブロック」状態になりました。
rippled v2.6.2のリリースから3週間も経たないうちに、Ripplexは新しいバージョンのrippled v3.0.0が利用可能であることを知らせました。これには新しい修正案やバグ修正が含まれ、バージョンv3.0.0には、まだ有効化されていないものの、ほぼコード完成に近い貸付プロトコルなどの修正案も追加されました。
これを踏まえ、XユーザーはRippleのCTOに、「rippledのアップデート」を投票可能な修正案として追加できるかどうかを尋ねました。80%以上のバリデーターがアップグレードに投票すれば、サーバーはユーザーの介入なしに段階的にアップグレードを行うと、Xユーザーは付け加えました。
RippleのCTOはこれについて、「これにより、バリデーターの権限に対する重要な制限が弱まる可能性がある」と回答しました。もしこれが行われると、バリデーターはノードに対して、自分たちが意識的に受け入れたくないルール変更を受け入れるように促すことができてしまいます。
なぜこのアイデアがあまり好ましくないのかについて、Schwartzは、「修正プロセスを単なる調整メカニズムとして維持し、主要なガバナンスメカニズムとしない方が良い」と強調しました。
Xユーザーは、XRP Ledgerの革新のスピードが速いため、アップデートの同期、テスト、変化の兆しを聞き続けることは多大な労力になるかもしれないと述べました。RippleのCTOは、「ノード運用者に通知する優先的な方法が何らか必要だ」と指摘しました。
