Ich dachte, Babylon müsse nur im richtigen Moment das Bitcoin-Netz prüfen—eine Bestätigung der Einlage (Stake), das Verifizieren eines Checkpoints, dann weiterziehen. Beim Lesen des Moduls „BTC Light Client“ hat sich dieses Bild geändert.
Babylon Genesis hält eine eigene, fortlaufend aktualisierte Sicht auf die Bitcoin-Kette. Es beginnt mit einem Basiskopf, der tief genug gewählt ist, um als endgültig behandelt zu werden, und genau an einer Grenze für die Schwierigkeitseinstellung positioniert ist. Von dort aus wird die Kette erweitert, indem Babylons eigene Logik die eigenen Proof-of-Work-Regeln von Bitcoin anwendet—mittels einer Nachricht namens MsgInsertHeaders. Vigilante Reporters transportieren die Header zwar mit, aber sie dürfen nicht entscheiden, was als wahr gilt. Wenn konkurrierende Verzweigungen auftreten, folgt Genesis einfach derjenigen, die die meiste angesammelte Arbeit hinter sich hat—derselbe Regelmechanismus, den Bitcoin selbst verwendet.
Das ist eine andere Art von Vertrauen als das Prüfen eines einzelnen Einschlussbeweises und anschließendes Weitergehen. @BabylonLabs_io stellt keine Frage an einen Operator, ob ein Bitcoin-Ereignis stattgefunden hat. Es verifiziert dieses Ereignis anhand einer Header-Kette, die es die ganze Zeit über aufgebaut und selbst geprüft hat.
Der Preis dafür ist, dass Genesis jetzt eine laufende Aufgabe hat statt einer einmaligen Prüfung. Wenn Reporter zurückfallen oder ein Bitcoin-Reorg die jüngsten Blöcke neu anordnet, muss Genesis das bemerken und über den gesamten Zeitraum korrekt und aktuell bleiben—nicht nur jedes Mal dann richtig verifizieren, wenn jemand gerade danach fragt.
Ich habe immer noch kein gutes Gefühl dafür, wie das sich in einem tatsächlichen Reorg oder während einer Phase mit eingeschränkter Berichterstattung bewährt, aber zumindest ist die Regel zum Auflösen—folgt dem größten Maß an angesammelter Arbeit—einfach genug, um sie auf Papier zu vertrauen.
#baby $BABY
Babylon Genesis hält eine eigene, fortlaufend aktualisierte Sicht auf die Bitcoin-Kette. Es beginnt mit einem Basiskopf, der tief genug gewählt ist, um als endgültig behandelt zu werden, und genau an einer Grenze für die Schwierigkeitseinstellung positioniert ist. Von dort aus wird die Kette erweitert, indem Babylons eigene Logik die eigenen Proof-of-Work-Regeln von Bitcoin anwendet—mittels einer Nachricht namens MsgInsertHeaders. Vigilante Reporters transportieren die Header zwar mit, aber sie dürfen nicht entscheiden, was als wahr gilt. Wenn konkurrierende Verzweigungen auftreten, folgt Genesis einfach derjenigen, die die meiste angesammelte Arbeit hinter sich hat—derselbe Regelmechanismus, den Bitcoin selbst verwendet.
Das ist eine andere Art von Vertrauen als das Prüfen eines einzelnen Einschlussbeweises und anschließendes Weitergehen. @BabylonLabs_io stellt keine Frage an einen Operator, ob ein Bitcoin-Ereignis stattgefunden hat. Es verifiziert dieses Ereignis anhand einer Header-Kette, die es die ganze Zeit über aufgebaut und selbst geprüft hat.
Der Preis dafür ist, dass Genesis jetzt eine laufende Aufgabe hat statt einer einmaligen Prüfung. Wenn Reporter zurückfallen oder ein Bitcoin-Reorg die jüngsten Blöcke neu anordnet, muss Genesis das bemerken und über den gesamten Zeitraum korrekt und aktuell bleiben—nicht nur jedes Mal dann richtig verifizieren, wenn jemand gerade danach fragt.
Ich habe immer noch kein gutes Gefühl dafür, wie das sich in einem tatsächlichen Reorg oder während einer Phase mit eingeschränkter Berichterstattung bewährt, aber zumindest ist die Regel zum Auflösen—folgt dem größten Maß an angesammelter Arbeit—einfach genug, um sie auf Papier zu vertrauen.
#baby $BABY