Wiederverbinden und schon bist du zurück. Das ist die Annahme.
Die Finalitätsanbieter von Babylon können sich nicht so einfach an der Reihe vorbeischummeln. Finalitätsanbieter müssen ihre öffentliche Zufälligkeit im Voraus festlegen — für zukünftige Blockhöhen — in Paketen. Das ist kein kleines Detail – das ist die Grundlage dafür, wie EOTS-Signaturen funktionieren. Die „TimestampingDelayBlocks“-Einstellung bestimmt, wie weit diese Zusage im Voraus eintreffen muss; der empfohlene Wert liegt bei über 10.000 Blöcken, weil die Zufälligkeit selbst erst verwendbar ist, nachdem sie auf Bitcoin zeitgestempelt wurde.
Ein FP, das länger offline ist als sein vorher festgelegtes Zeitfenster, verpasst nicht nur Abstimmungen. Es geht ihm schlicht die Luft aus.
Angenommen, ein Anbieter hat eine Zufälligkeit bis einschließlich Höhe H festgeschrieben, fällt dann aus, und ist erst bei H plus 100 wieder online – also jenseits der Grenze dessen, wofür er geplant hatte. Er kann nicht einfach wieder mit dem Abstimmen anfangen. Er muss eine neue Festschreibung einreichen, und diese Festschreibung muss ebenfalls warten, bis das BTC-Timestamping nachgezogen hat, bevor sie aktiviert wird. Der Ausfall und die Wiederherstellung sind zwei getrennte Verzögerungen, die wie aufeinander gestapelt aufaddiert werden.
Das wirkte zunächst rückwärts. Ich ging davon aus, dass die Verfügbarkeit das eigentliche Problem ist – Knoten wieder online bringen, und schon läuft es wieder. Aber Verfügbarkeit und Wahl-/Abstimmungsberechtigung sind hier zwei verschiedene Uhren, und die zweite wurde Tage oder Wochen im Voraus gestellt, lange bevor der Ausfall überhaupt passierte.
Die reale Resilienz eines Betreibers ist also nicht nur „wie schnell kann ich neu starten“. Sondern: „Wie weit im Voraus habe ich geplant, bevor irgendetwas schiefging“ – eine Entscheidung, die als Konfigurationswert getroffen wird, lange bevor es überhaupt einen Ausfall gab, von dem man sich erholen müsste.
Wenn die Fähigkeit, nach einem Ausfall wieder abstimmen zu können, durch eine Zahl bestimmt wird, die man vor dem Ausfall festgelegt hat: Wie viel von dem Ruf eines Betreibers für „zuverlässige Verfügbarkeit“ ist dann tatsächlich nur eine im Voraus eingegangene Wette – und wie viel ist echte Resilienz im Moment?
@BabylonLabs_io #baby $BABY
Die Finalitätsanbieter von Babylon können sich nicht so einfach an der Reihe vorbeischummeln. Finalitätsanbieter müssen ihre öffentliche Zufälligkeit im Voraus festlegen — für zukünftige Blockhöhen — in Paketen. Das ist kein kleines Detail – das ist die Grundlage dafür, wie EOTS-Signaturen funktionieren. Die „TimestampingDelayBlocks“-Einstellung bestimmt, wie weit diese Zusage im Voraus eintreffen muss; der empfohlene Wert liegt bei über 10.000 Blöcken, weil die Zufälligkeit selbst erst verwendbar ist, nachdem sie auf Bitcoin zeitgestempelt wurde.
Ein FP, das länger offline ist als sein vorher festgelegtes Zeitfenster, verpasst nicht nur Abstimmungen. Es geht ihm schlicht die Luft aus.
Angenommen, ein Anbieter hat eine Zufälligkeit bis einschließlich Höhe H festgeschrieben, fällt dann aus, und ist erst bei H plus 100 wieder online – also jenseits der Grenze dessen, wofür er geplant hatte. Er kann nicht einfach wieder mit dem Abstimmen anfangen. Er muss eine neue Festschreibung einreichen, und diese Festschreibung muss ebenfalls warten, bis das BTC-Timestamping nachgezogen hat, bevor sie aktiviert wird. Der Ausfall und die Wiederherstellung sind zwei getrennte Verzögerungen, die wie aufeinander gestapelt aufaddiert werden.
Das wirkte zunächst rückwärts. Ich ging davon aus, dass die Verfügbarkeit das eigentliche Problem ist – Knoten wieder online bringen, und schon läuft es wieder. Aber Verfügbarkeit und Wahl-/Abstimmungsberechtigung sind hier zwei verschiedene Uhren, und die zweite wurde Tage oder Wochen im Voraus gestellt, lange bevor der Ausfall überhaupt passierte.
Die reale Resilienz eines Betreibers ist also nicht nur „wie schnell kann ich neu starten“. Sondern: „Wie weit im Voraus habe ich geplant, bevor irgendetwas schiefging“ – eine Entscheidung, die als Konfigurationswert getroffen wird, lange bevor es überhaupt einen Ausfall gab, von dem man sich erholen müsste.
Wenn die Fähigkeit, nach einem Ausfall wieder abstimmen zu können, durch eine Zahl bestimmt wird, die man vor dem Ausfall festgelegt hat: Wie viel von dem Ruf eines Betreibers für „zuverlässige Verfügbarkeit“ ist dann tatsächlich nur eine im Voraus eingegangene Wette – und wie viel ist echte Resilienz im Moment?
@BabylonLabs_io #baby $BABY