$BABY #baby i früher dachte ich, dass die Finalitäts-Signierung beginnt, sobald ein Block erscheint.

Je mehr ich mir das EOTS-Design von Babylon ansah, desto deutlicher wurde mir, dass die wichtigen Entscheidungen viel früher getroffen werden.

In einem vertrauten Validator-System erhält ein Operator einen Block und signiert ihn. Babylon fordert Finality Provider auf, der Kette voraus zu sein, indem sie öffentliche Zufälligkeit für zukünftige Blockhöhen fest zusagen – oft in Paketen zu 100.

Erst nachdem diese Zusagen auf Genesis erfasst sind, können die entsprechenden EOTS-Signaturen akzeptiert werden.

Diese Reihenfolge ist beabsichtigt. Wenn ein Finality Provider zwei widersprüchliche Blöcke in derselben Höhe unter Verwendung derselben fest zugesagten Zufälligkeit signiert, legen die beiden Signaturen den privaten Schlüssel offen, der benötigt wird, um den Slashingspfad zu aktivieren. Was mich interessiert hat, ist, dass Babylon nicht versucht, das Signieren im letzten Moment „smarter“ zu machen. Es will diese letzte Moment-Lücke an Ermessensspielraum vollständig beseitigen.

Traditionelle Validator-Systeme bewahren die Flexibilität bis zu dem Augenblick, in dem eine Signatur erzeugt wird. Babylon tauscht diese Flexibilität gegen ein Design ein, in dem Uneindeutigkeit kryptografisch bestraft werden kann, statt dass etwas von einem externen Beobachter beurteilt werden muss.

Nichts wurde einfacher. Die operative Belastung wurde nur nach vorn verlagert. Anstatt auf den nächsten Block zu reagieren, müssen die Anbieter weiter vorbereiten, veröffentlichen und Zufälligkeits-Zusagen nachfüllen, noch bevor die Kette diese Höhen jemals erreicht.

Ich habe das Gefühl, dass der schwierige Teil nicht die Kryptografie sein wird. Ich glaube, es wird das tägliche, lückenlose Vorausbleiben sein – ohne Verzögerungen bei Zusagen oder Betriebsfehlern, sobald das Netzwerk unter weniger verzeihenden Bedingungen läuft..
@BabylonLabs_io #baby
$BANK
$ESP