リップルの最高技術責任者、デビッド・シュワルツは、XRP Ledger (XRPL)の最初の32,000の台帳が存在しない理由を再確認し、ネットワークの初期の歴史の完全性と整合性に関する長年の質問に対処しました。## **帳簿ギャップの起源**XRPLの初期帳簿履歴におけるギャップは何年も前から知られていますが、依然として懐疑的な注目を集めています。最初に公開された帳簿は32,570番から始まっており、それ以前の記録は説明されていません。5月に共有された説明で、シュワルツはデータ損失の技術的理由を再確認しました。XRPレジャーの初期開発段階では、ソフトウェアがテストおよび改良される中で、いくつかの独立したレジャーストリームが生成されました。これらのストリームの中には、ソフトウェアのバグが原因で最初の10日間のレジャーデータが失われたものがありました。@mediaのみの画面と(min-width:0px)と(min-height:0px) {div[id^="wrapper-sevio-6a57f7be-8f6e-4deb-ae2c-5477f86653a5"]{width:320px;高さ:100px;}}@mediaのみの画面と(min-width:728px)と(min-height:0px) {div[id^="wrapper-sevio-6a57f7be-8f6e-4deb-ae2c-5477f86653a5"]{width:728px;高さ:90px;}}この問題は内部で知られており、開発チームはクリーンな履歴記録を作成するために台帳のリセットを開始することを検討しましたが、その決定は最終的に追求されませんでした。## **なぜレジャーはリセットされなかったのか**シュワルツは、台帳をリセットするというアイデアに直接対処しました。彼は、このようなステップが開発チームによって議論されたが、逆効果であると見なされたことを指摘しました。彼が説明した理由は、台帳をリセットすると、すでに失われた最初の32,000ブロックを超えるすべての履歴データが削除されることになるからです。リセットは失われたデータを回復することはなく、台帳の現在の利用可能な履歴の透明性をむしろ低下させることになったでしょう。シュワルツの言葉によれば、台帳をリセットする提案は「32,000の台帳の後のすべてを削除する」ことになり、実際には記録上保存されている唯一の歴史を消し去ることになります。この立場は、台帳の実際の活動をできるだけ多く保存することがより良い選択であるという技術的な判断を反映しています。## **XRPLの初期の頃からの既知の制限**欠落している台帳記録は、ネットワークの実験段階にさかのぼる認識された制限として残っています。シュワルツによれば、これはテスト環境と初期実装の課題の産物であり、意図的な削除や隠蔽ではありません。開発中に複数の台帳ストリームが存在したことは、特に当時の最終的な生産基準が欠如していたため、長期的なデータの継続性を確保することをより難しくしました。この問題は、暗号コミュニティの一部からの批判を引き起こしていますが、リップルの最高技術責任者は、状況を考慮すると台帳の損失は避けられなかったと一貫して主張しています。彼の回答は、失われたデータを回復するための実行可能な技術的手段は存在せず、台帳をリセットしようとする試みは、さらなる歴史の喪失をもたらすだけであることを強調しています。シュワルツは最近のコメントで、無行動が怠慢や秘密のせいだという考えを退けた。代わりに、彼の説明は、初期の回復不可能な技術的故障の後にできるだけ多くの歴史的データを保存するという利益のために行われた実用的な妥協としてその決定を位置づけている。***免責事項****: この内容は情報提供を目的としており、財務アドバイスと見なされるべきではありません。本記事に表明されている意見は著者の個人的な意見を含む可能性があり、Times Tabloidの意見を代表するものではありません。読者は投資決定を行う前に十分な調査を行うことをお勧めします。読者が取った行動は自己責任であり、Times Tabloidは財務的損失について責任を負いません。*---
リップル CTO が 32,000 の初期 XRP レジャーブロックの喪失について明らかにしました
リップルの最高技術責任者、デビッド・シュワルツは、XRP Ledger (XRPL)の最初の32,000の台帳が存在しない理由を再確認し、ネットワークの初期の歴史の完全性と整合性に関する長年の質問に対処しました。
帳簿ギャップの起源
XRPLの初期帳簿履歴におけるギャップは何年も前から知られていますが、依然として懐疑的な注目を集めています。最初に公開された帳簿は32,570番から始まっており、それ以前の記録は説明されていません。5月に共有された説明で、シュワルツはデータ損失の技術的理由を再確認しました。
XRPレジャーの初期開発段階では、ソフトウェアがテストおよび改良される中で、いくつかの独立したレジャーストリームが生成されました。これらのストリームの中には、ソフトウェアのバグが原因で最初の10日間のレジャーデータが失われたものがありました。
@mediaのみの画面と(min-width:0px)と(min-height:0px) { div[id^="wrapper-sevio-6a57f7be-8f6e-4deb-ae2c-5477f86653a5"]{width:320px;高さ:100px;} } @mediaのみの画面と(min-width:728px)と(min-height:0px) { div[id^="wrapper-sevio-6a57f7be-8f6e-4deb-ae2c-5477f86653a5"]{width:728px;高さ:90px;} }
この問題は内部で知られており、開発チームはクリーンな履歴記録を作成するために台帳のリセットを開始することを検討しましたが、その決定は最終的に追求されませんでした。
なぜレジャーはリセットされなかったのか
シュワルツは、台帳をリセットするというアイデアに直接対処しました。彼は、このようなステップが開発チームによって議論されたが、逆効果であると見なされたことを指摘しました。彼が説明した理由は、台帳をリセットすると、すでに失われた最初の32,000ブロックを超えるすべての履歴データが削除されることになるからです。リセットは失われたデータを回復することはなく、台帳の現在の利用可能な履歴の透明性をむしろ低下させることになったでしょう。
シュワルツの言葉によれば、台帳をリセットする提案は「32,000の台帳の後のすべてを削除する」ことになり、実際には記録上保存されている唯一の歴史を消し去ることになります。この立場は、台帳の実際の活動をできるだけ多く保存することがより良い選択であるという技術的な判断を反映しています。
XRPLの初期の頃からの既知の制限
欠落している台帳記録は、ネットワークの実験段階にさかのぼる認識された制限として残っています。シュワルツによれば、これはテスト環境と初期実装の課題の産物であり、意図的な削除や隠蔽ではありません。
開発中に複数の台帳ストリームが存在したことは、特に当時の最終的な生産基準が欠如していたため、長期的なデータの継続性を確保することをより難しくしました。
この問題は、暗号コミュニティの一部からの批判を引き起こしていますが、リップルの最高技術責任者は、状況を考慮すると台帳の損失は避けられなかったと一貫して主張しています。彼の回答は、失われたデータを回復するための実行可能な技術的手段は存在せず、台帳をリセットしようとする試みは、さらなる歴史の喪失をもたらすだけであることを強調しています。
シュワルツは最近のコメントで、無行動が怠慢や秘密のせいだという考えを退けた。代わりに、彼の説明は、初期の回復不可能な技術的故障の後にできるだけ多くの歴史的データを保存するという利益のために行われた実用的な妥協としてその決定を位置づけている。
免責事項*: この内容は情報提供を目的としており、財務アドバイスと見なされるべきではありません。本記事に表明されている意見は著者の個人的な意見を含む可能性があり、Times Tabloidの意見を代表するものではありません。読者は投資決定を行う前に十分な調査を行うことをお勧めします。読者が取った行動は自己責任であり、Times Tabloidは財務的損失について責任を負いません。*