Die schwierigste Frage in Babylon: FP wurde mit BTC beauftragt, aber sein Verhalten kann nicht in Echtzeit überwacht werden.
Ich hatte früher geglaubt, dass alle Signaturen von FP auf der Kette liegen und dass eine ordnungsgemäße Abstimmung in Echtzeit verifiziert werden kann. Erst als ich die Überwachungs-„Chain“-Verbindung von FP wirklich im Detail auseinander genommen habe, merkte ich, dass es tatsächlich zwei völlig unterschiedliche Mechanismen gibt.
Die Signaturaufzeichnungen, die FP einreicht, liegen auf der Babylon Genesis Chain – wer signiert hat, in welcher Höhe signiert wurde und für welchen BSN-Block signiert wurde: Diese Daten sind on-chain sichtbar. Aber ob „FP korrekt abgestimmt hat“, muss mit dem erwarteten Verhalten des BSN verglichen werden – ob FP hätte signieren sollen oder ob er rechtzeitig signiert hat, aber stattdessen verzögert hat. Dieses Vergleichsprotokoll wird auf Protokollebene nicht zwingend durchgesetzt.
Mit anderen Worten: Babylon hält fest, was FP getan hat, aber nicht, was FP hätte tun sollen. Letzteres muss entweder das BSN selbst nachverfolgen oder man nutzt ein Tool eines Drittanbieters zur Überwachung.
Dieser zeitliche Spalt bedeutet: Wenn ein Nutzer feststellt, dass das Verhalten von FP ungewöhnlich ist, läuft FP möglicherweise bereits seit mehreren Epochs ungewöhnlich. Wenn der Nutzer große Mengen BTC delegiert hat, kann das Zeitfenster für das unnormale Verhalten von FP – von der Entdeckung bis zur Initiierung einer Auszahlung und bis zum Ende der Unbonding-Periode – deutlich länger sein, als der Nutzer erwartet.
Das erklärt auch, warum die Betriebs- und Vertrauenshistorie von FP wichtiger ist als der APY. APY lässt sich anpassen, aber die Verhaltensaufzeichnungen nicht.
Wenn Nutzer gleichzeitig mehrere FP delegieren, unterscheiden sich außerdem die Überwachungsverzögerungen je FP, wodurch sich das Risiko zusätzlich kumuliert.
Daher betrachte ich bei der Bewertung der Auswahl von FP nicht nur den APY. Ich schaue mir drei Kennzahlen an: ob es eine öffentlich einsehbare Aufzeichnung der Wahlbeteiligungsrate von FP gibt, die Verzögerungszeit von Benachrichtigungen bei ungewöhnlichem Verhalten und die gesamten operativen Kosten vom Beschluss, zu einem neuen FP zu wechseln, bis dessen Wirksamwerden.
Die eigentliche Bewährungsprobe liegt nicht darin, dass FP zur Delegationszeit zuverlässig wirkt, sondern darin, wie lange du brauchst, um ein ungewöhnliches FP-Verhalten zu entdecken und dann zu verlassen.
@BabylonLabs_io $BABY #baby
Ich hatte früher geglaubt, dass alle Signaturen von FP auf der Kette liegen und dass eine ordnungsgemäße Abstimmung in Echtzeit verifiziert werden kann. Erst als ich die Überwachungs-„Chain“-Verbindung von FP wirklich im Detail auseinander genommen habe, merkte ich, dass es tatsächlich zwei völlig unterschiedliche Mechanismen gibt.
Die Signaturaufzeichnungen, die FP einreicht, liegen auf der Babylon Genesis Chain – wer signiert hat, in welcher Höhe signiert wurde und für welchen BSN-Block signiert wurde: Diese Daten sind on-chain sichtbar. Aber ob „FP korrekt abgestimmt hat“, muss mit dem erwarteten Verhalten des BSN verglichen werden – ob FP hätte signieren sollen oder ob er rechtzeitig signiert hat, aber stattdessen verzögert hat. Dieses Vergleichsprotokoll wird auf Protokollebene nicht zwingend durchgesetzt.
Mit anderen Worten: Babylon hält fest, was FP getan hat, aber nicht, was FP hätte tun sollen. Letzteres muss entweder das BSN selbst nachverfolgen oder man nutzt ein Tool eines Drittanbieters zur Überwachung.
Dieser zeitliche Spalt bedeutet: Wenn ein Nutzer feststellt, dass das Verhalten von FP ungewöhnlich ist, läuft FP möglicherweise bereits seit mehreren Epochs ungewöhnlich. Wenn der Nutzer große Mengen BTC delegiert hat, kann das Zeitfenster für das unnormale Verhalten von FP – von der Entdeckung bis zur Initiierung einer Auszahlung und bis zum Ende der Unbonding-Periode – deutlich länger sein, als der Nutzer erwartet.
Das erklärt auch, warum die Betriebs- und Vertrauenshistorie von FP wichtiger ist als der APY. APY lässt sich anpassen, aber die Verhaltensaufzeichnungen nicht.
Wenn Nutzer gleichzeitig mehrere FP delegieren, unterscheiden sich außerdem die Überwachungsverzögerungen je FP, wodurch sich das Risiko zusätzlich kumuliert.
Daher betrachte ich bei der Bewertung der Auswahl von FP nicht nur den APY. Ich schaue mir drei Kennzahlen an: ob es eine öffentlich einsehbare Aufzeichnung der Wahlbeteiligungsrate von FP gibt, die Verzögerungszeit von Benachrichtigungen bei ungewöhnlichem Verhalten und die gesamten operativen Kosten vom Beschluss, zu einem neuen FP zu wechseln, bis dessen Wirksamwerden.
Die eigentliche Bewährungsprobe liegt nicht darin, dass FP zur Delegationszeit zuverlässig wirkt, sondern darin, wie lange du brauchst, um ein ungewöhnliches FP-Verhalten zu entdecken und dann zu verlassen.
@BabylonLabs_io $BABY #baby
