Babylon sorgt dafür, dass BTC-Inhaber die PoS-Kette sicherstellen können, indem sie ihre Coins an einen Finality Provider (FP) delegieren – diese Erzählung ist stimmig. Aber in den meisten Diskussionen wird eine entscheidende Zwischenrolle übersprungen: der FP selbst. $EUL
BTC-Inhaber delegieren ihre Coins an den FP. Der FP ist verantwortlich für die finale Signatur der Ziel-PoS-Kette. Wenn der FP doppelt signiert, legt die EOTS-Mechanik den privaten Schlüssel offen – und der BTC wird beschlagnahmt. Daher hängt das Risiko der Inhaber vom Verhalten des FPs ab: Wählt man einen vertrauenswürdigen FP, trägt das Sicherheitsmodell; wählt man einen unzuverlässigen, kann der BTC wegen der Fehler des FP bestraft werden.
Das Problem ist: Wie wählt man den FP? In der Staking-Oberfläche von Babylon werden Informationen zum FP angezeigt, darunter Name, Kommissionssatz und die gesamte staked Menge. Doch es gibt keine Betriebs-Historie des FPs – hat es zuvor Doppel-Signaturen gegeben? Wurde es herausgefordert? Läuft die von ihm bediente PoS-Kette ordnungsgemäß? Ist die Softwareversion des FP die aktuellste? Diese Informationen sind beim Staking nicht einsehbar.
Noch subtiler ist die Konzentration der FPs. Wenn viele BTC an denselben FP delegiert werden, bestimmt das Verhalten dieses einen FPs den Sicherheitszustand großer Geldmengen. Auch Babylons Dokumentation erwähnt, dass die FPs diversifiziert werden müssen. Ob das Wachstum der FP-Liste in der aktuellen Phase jedoch mit dem Wachstum der delegierten BTC-Mengen Schritt halten kann, ist eine andere Frage.
@BabylonLabs_io hat in der Phase-1-Testnetzumgebung verifiziert, dass die EOTS-Kryptographie praktikabel ist, und Phase 2 hat echte Delegations- und Slashing-Abläufe live geschaltet. Aber „kryptographisch machbar“ und „FP-Ökosystem gereift“ sind zwei verschiedene Dinge. Wenn BTC-Inhaber BTC delegieren, müssen sie nicht nur beurteilen, ob die PoS-Kette schützenswert ist, sondern auch, ob der FP es wert ist, ihm zu vertrauen. Wenn die operative Transparenz des FP nicht ausreicht, stammt das Risiko der Inhaber nicht nur aus Protokollrisiken der PoS-Kette, sondern auch aus Betriebs-/Operationsrisiken des FP.
Daher schaue ich mir beim Babylon-BTC-Staking inzwischen nicht nur an, wie viele BTC gesperrt sind, sondern vor allem an die Veränderung der Konzentration in der FP-Liste sowie an die öffentlich einsehbaren Betriebsaufzeichnungen der FP. Wenn das BTC-Wachstum schnell ist, aber das Wachstum der FP-Liste langsam, dann konzentriert sich der Großteil der Mittel in wenigen FPs – dann hängt die Systemsicherheit davon ab, dass diese wenigen FPs nicht Fehler machen. Wenn der Mechanismus zur Auswahl von FPs nicht transparent ist, wird das zu einer anderen Form von „Vertrauen in wenige“. #baby $BABY
BTC-Inhaber delegieren ihre Coins an den FP. Der FP ist verantwortlich für die finale Signatur der Ziel-PoS-Kette. Wenn der FP doppelt signiert, legt die EOTS-Mechanik den privaten Schlüssel offen – und der BTC wird beschlagnahmt. Daher hängt das Risiko der Inhaber vom Verhalten des FPs ab: Wählt man einen vertrauenswürdigen FP, trägt das Sicherheitsmodell; wählt man einen unzuverlässigen, kann der BTC wegen der Fehler des FP bestraft werden.
Das Problem ist: Wie wählt man den FP? In der Staking-Oberfläche von Babylon werden Informationen zum FP angezeigt, darunter Name, Kommissionssatz und die gesamte staked Menge. Doch es gibt keine Betriebs-Historie des FPs – hat es zuvor Doppel-Signaturen gegeben? Wurde es herausgefordert? Läuft die von ihm bediente PoS-Kette ordnungsgemäß? Ist die Softwareversion des FP die aktuellste? Diese Informationen sind beim Staking nicht einsehbar.
Noch subtiler ist die Konzentration der FPs. Wenn viele BTC an denselben FP delegiert werden, bestimmt das Verhalten dieses einen FPs den Sicherheitszustand großer Geldmengen. Auch Babylons Dokumentation erwähnt, dass die FPs diversifiziert werden müssen. Ob das Wachstum der FP-Liste in der aktuellen Phase jedoch mit dem Wachstum der delegierten BTC-Mengen Schritt halten kann, ist eine andere Frage.
@BabylonLabs_io hat in der Phase-1-Testnetzumgebung verifiziert, dass die EOTS-Kryptographie praktikabel ist, und Phase 2 hat echte Delegations- und Slashing-Abläufe live geschaltet. Aber „kryptographisch machbar“ und „FP-Ökosystem gereift“ sind zwei verschiedene Dinge. Wenn BTC-Inhaber BTC delegieren, müssen sie nicht nur beurteilen, ob die PoS-Kette schützenswert ist, sondern auch, ob der FP es wert ist, ihm zu vertrauen. Wenn die operative Transparenz des FP nicht ausreicht, stammt das Risiko der Inhaber nicht nur aus Protokollrisiken der PoS-Kette, sondern auch aus Betriebs-/Operationsrisiken des FP.
Daher schaue ich mir beim Babylon-BTC-Staking inzwischen nicht nur an, wie viele BTC gesperrt sind, sondern vor allem an die Veränderung der Konzentration in der FP-Liste sowie an die öffentlich einsehbaren Betriebsaufzeichnungen der FP. Wenn das BTC-Wachstum schnell ist, aber das Wachstum der FP-Liste langsam, dann konzentriert sich der Großteil der Mittel in wenigen FPs – dann hängt die Systemsicherheit davon ab, dass diese wenigen FPs nicht Fehler machen. Wenn der Mechanismus zur Auswahl von FPs nicht transparent ist, wird das zu einer anderen Form von „Vertrauen in wenige“. #baby $BABY