Bei den vier Ledgern unterscheiden sich die Mechanismen, die ihre Ausgabemengenobergrenze absichern. Die Gesamtmenge von XRP ist auf 100 Milliarden festgelegt und wird durch eine Invariante abgesichert, die verhindert, dass aus dem Nichts weitere Coins entstehen. Die Obergrenze von 21 Millionen Bitcoin ist in der Halbierungsformel auf Konsensebene verankert; alle vier Jahre wird sie protocolbedingt gekürzt. Ethereum hat keine feste Obergrenze, die jährliche Inflationsrate wird durch die Community-Governance angepasst. Auch Solanas Inflationsrate ist ein Abstimmungsparameter und nähert sich Jahr für Jahr 1,5 %. Was die vier voneinander unterscheidet, ist, wodurch die Obergrenze abgesichert wird und wer einen Fehler zuerst bemerkt.
Diesmal versagte die Invariante von XRP. Als die Zahlungs-Engine offene Orders auf integrierten Plattformen aufsummierte, verwendete sie einen 64-Bit-Zähler. Auch „XRPNotCreated“, das 2017 hinzugefügt wurde, stützte sich auf diesen 64-Bit-Zähler. Als der Zähler überlief, versagten sowohl die vorherige Summierung als auch die nachgelagerte Invariante. RippleX veröffentlichte am 25. September den Notfall-Patch xrpld 3.4.1 und umging damit die „80 % der Validatoren, zwei Wochen Abstimmung“ – zum ersten Mal seit Einführung des Mechanismus.
Ich bin dieser Invariante zurück zu ihrem Ursprung gefolgt: Sie verwendet denselben 64-Bit-Zähler wie die Logik, die für die Summierung offener Orders zuständig ist. Der Patch hat lediglich die Zählerbreite von 64 auf 128 Bit erhöht, die beiden Zähler aber nicht voneinander getrennt. Der Überlauf ist behoben, doch der Zähler, der die Obergrenze absichert, und die geschäftliche Summierung hängen weiterhin zusammen. Bei einer anderen Umsetzung könnte sich das wiederholen – und diesmal womöglich nicht so glimpflich ausgehen.
Der Schaden durch das Versagen war eigentlich nicht groß. Die Reproduktion des Fehlers war nur ein paar hundert XRP wert; öffentlich dokumentierte Fälle von neu geschaffenen Coins wurden nicht bekannt. In dieser Runde gibt es noch eine zweite Neuerung: fixBatchV1_2 wird am 9. Oktober aktiviert. Der Notfall-Patch umging die reguläre Abstimmung und trennte Sicherheitsreaktion und dezentrale Governance in zwei Vorgänge: Das schnelle Team entscheidet, während die langsamere Abstimmung den Validatoren vorbehalten bleibt.
Diesmal versagte die Absicherung, nicht die Obergrenze selbst – diese legt nur fest, dass es nicht mehr geben darf. Doch der Zähler, der sie absichert, und die geschäftliche Summierung nutzen dieselbe Stelle. Was versagt, ist nie nur eine einzelne Zahl, sondern der Zähler dahinter. Sollten künftig bei einem anderen Ledger mit unabhängigem Zähler ähnliche Überläufe auftreten oder die XRP-Menge von der Obergrenze von 100 Milliarden abweichen, müsste ich meine Einschätzung komplett revidieren. Solange sich an beiden Punkten nichts ändert, halte ich erst einmal an ihr fest. Diesen Zähler kann man anhand des XRP-Tagescharts verfolgen. Auf welcher Binance-Seite wird das klar? Die täglichen Werte in der Spot-Zeile sind vollständig zu sehen; folgt man der Reparatur rückwärts, lässt sich das nachvollziehen. Dieser Text gibt eine persönliche Einschätzung wieder und stellt keine Anlageberatung dar.$ZEC
$LUMIA
$ERA
#xrp账本修复可增发xrp的漏洞
Diesmal versagte die Invariante von XRP. Als die Zahlungs-Engine offene Orders auf integrierten Plattformen aufsummierte, verwendete sie einen 64-Bit-Zähler. Auch „XRPNotCreated“, das 2017 hinzugefügt wurde, stützte sich auf diesen 64-Bit-Zähler. Als der Zähler überlief, versagten sowohl die vorherige Summierung als auch die nachgelagerte Invariante. RippleX veröffentlichte am 25. September den Notfall-Patch xrpld 3.4.1 und umging damit die „80 % der Validatoren, zwei Wochen Abstimmung“ – zum ersten Mal seit Einführung des Mechanismus.
Ich bin dieser Invariante zurück zu ihrem Ursprung gefolgt: Sie verwendet denselben 64-Bit-Zähler wie die Logik, die für die Summierung offener Orders zuständig ist. Der Patch hat lediglich die Zählerbreite von 64 auf 128 Bit erhöht, die beiden Zähler aber nicht voneinander getrennt. Der Überlauf ist behoben, doch der Zähler, der die Obergrenze absichert, und die geschäftliche Summierung hängen weiterhin zusammen. Bei einer anderen Umsetzung könnte sich das wiederholen – und diesmal womöglich nicht so glimpflich ausgehen.
Der Schaden durch das Versagen war eigentlich nicht groß. Die Reproduktion des Fehlers war nur ein paar hundert XRP wert; öffentlich dokumentierte Fälle von neu geschaffenen Coins wurden nicht bekannt. In dieser Runde gibt es noch eine zweite Neuerung: fixBatchV1_2 wird am 9. Oktober aktiviert. Der Notfall-Patch umging die reguläre Abstimmung und trennte Sicherheitsreaktion und dezentrale Governance in zwei Vorgänge: Das schnelle Team entscheidet, während die langsamere Abstimmung den Validatoren vorbehalten bleibt.
Diesmal versagte die Absicherung, nicht die Obergrenze selbst – diese legt nur fest, dass es nicht mehr geben darf. Doch der Zähler, der sie absichert, und die geschäftliche Summierung nutzen dieselbe Stelle. Was versagt, ist nie nur eine einzelne Zahl, sondern der Zähler dahinter. Sollten künftig bei einem anderen Ledger mit unabhängigem Zähler ähnliche Überläufe auftreten oder die XRP-Menge von der Obergrenze von 100 Milliarden abweichen, müsste ich meine Einschätzung komplett revidieren. Solange sich an beiden Punkten nichts ändert, halte ich erst einmal an ihr fest. Diesen Zähler kann man anhand des XRP-Tagescharts verfolgen. Auf welcher Binance-Seite wird das klar? Die täglichen Werte in der Spot-Zeile sind vollständig zu sehen; folgt man der Reparatur rückwärts, lässt sich das nachvollziehen. Dieser Text gibt eine persönliche Einschätzung wieder und stellt keine Anlageberatung dar.$ZEC
$LUMIA
$ERA
#xrp账本修复可增发xrp的漏洞