Meine erste Reaktion auf „Dual Staking“ war, dass es nach Marketing-Blabla klang, ein weiterer Buzzword, um einer Kette mehr Sicherheit vorzutäuschen, als tatsächlich vorhanden ist. Ich habe genug Projekte gesehen, die „dual“ oder „hybrid“ einfach auf ihren Konsens aufkleben und es als Innovation verkaufen. Also habe ich mir angesehen, wie Babylon Genesis das wirklich strukturiert, bevor ich irgendetwas geschrieben habe.
Dabei stellte sich heraus: Das ist eine echte architektonische Aufteilung, nicht nur ein Namensding. Babylon Genesis läuft auf CometBFT mit 100 Validatoren, die den normalen PoS-Konsens übernehmen – genauso, wie es jede Cosmos-SDK-Kette tun würde. Aber darüber liegt noch eine zweite Schicht: 60 Bitcoin-staked Finality Provider, die Bitcoin-Finality-Signaturen hinzufügen. Ein Block gilt erst dann als wirklich finalisiert, wenn beide Gruppen sich einig sind: die CometBFT-Validatoren und die BTC-gestützten Finality Provider.
Was bei mir Klick gemacht hat, ist, warum das über „mehr Sicherheit“ hinaus wichtig ist. BABY-Staker und BTC-Staker sichern unterschiedliche Ausfallmodi ab. BABY-Staker halten den täglichen Konsens der Kette durch standardmäßiges Slashing ehrlich. BTC-Staker ergänzen einen härteren, teureren Backstop, der schwieriger anzugreifen ist, weil es viel mehr kostet, die Sicherheit auf Bitcoin-Level zu kompromittieren, als eine junge Cosmos-Kette mit ihrem Token zu kompromittieren. Beide Seiten erhalten BABY-Rewards für ihren jeweiligen Beitrag.
Das, was ich nirgendwo in den öffentlichen Dokus klar erklärt gesehen habe: die tatsächliche Aufteilung der Reward-Quote zwischen BTC-Stakern und BABY-Stakern – und ob diese Quote fix ist oder per Governance anpassbar. Ich würde diese Lücke lieber markieren, als eine Zahl zu erfinden.
Der echte Test für BABY ist, ob dieses Dual-Quorum-Design tatsächlich durch einen Live-Angriffsversuch getestet wird – nicht nur, ob es im Whitepaper beschrieben wird.
Hat sonst noch jemand bemerkt, wie wenige Projekte ihre „dual“-Mechanismen so konkret erklären?
@BabylonLabs_io #baby $BABY
$BANK $DEXE
Dabei stellte sich heraus: Das ist eine echte architektonische Aufteilung, nicht nur ein Namensding. Babylon Genesis läuft auf CometBFT mit 100 Validatoren, die den normalen PoS-Konsens übernehmen – genauso, wie es jede Cosmos-SDK-Kette tun würde. Aber darüber liegt noch eine zweite Schicht: 60 Bitcoin-staked Finality Provider, die Bitcoin-Finality-Signaturen hinzufügen. Ein Block gilt erst dann als wirklich finalisiert, wenn beide Gruppen sich einig sind: die CometBFT-Validatoren und die BTC-gestützten Finality Provider.
Was bei mir Klick gemacht hat, ist, warum das über „mehr Sicherheit“ hinaus wichtig ist. BABY-Staker und BTC-Staker sichern unterschiedliche Ausfallmodi ab. BABY-Staker halten den täglichen Konsens der Kette durch standardmäßiges Slashing ehrlich. BTC-Staker ergänzen einen härteren, teureren Backstop, der schwieriger anzugreifen ist, weil es viel mehr kostet, die Sicherheit auf Bitcoin-Level zu kompromittieren, als eine junge Cosmos-Kette mit ihrem Token zu kompromittieren. Beide Seiten erhalten BABY-Rewards für ihren jeweiligen Beitrag.
Das, was ich nirgendwo in den öffentlichen Dokus klar erklärt gesehen habe: die tatsächliche Aufteilung der Reward-Quote zwischen BTC-Stakern und BABY-Stakern – und ob diese Quote fix ist oder per Governance anpassbar. Ich würde diese Lücke lieber markieren, als eine Zahl zu erfinden.
Der echte Test für BABY ist, ob dieses Dual-Quorum-Design tatsächlich durch einen Live-Angriffsversuch getestet wird – nicht nur, ob es im Whitepaper beschrieben wird.
Hat sonst noch jemand bemerkt, wie wenige Projekte ihre „dual“-Mechanismen so konkret erklären?
@BabylonLabs_io #baby $BABY
$BANK $DEXE