一只瓢虫

Übersetzung ansehen

我第一次看到双交易模型这个设计，第一反应有点复杂。一条链上跑两种交易模型，一个账户模型一个UTXO模型，给我的感觉像是在同一台电脑上装两个操作系统。能跑，但切换的时候会不会卡顿，会不会出兼容性问题，我当时心里没底。

后来我仔细看白皮书里对两个模型的定位，才慢慢理解了它为什么这么设计。

Moonlight是透明账户模型，跟Ethereum那种类似，账户余额是公开的，适合需要透明审计的场景。比如机构想证明自己持有多少资产、$DUSK 资金流向是否合规，直接Moonlight上走就行，一目了然。

Phoenix走的是UTXO路线，支持透明和混淆两种交易。这里的混淆不是指完全的匿名，而是让第三方无法直接关联交易双方。白皮书里提到它使用的加密技术包括密钥共识、椭圆曲线密码学和零知识证明，是经过审计的密码学方案。@Dusk

两个模型共存，本质上是把不同的隐私需求分到了不同的轨道上。需要公开的就走Moonlight，需要机密的就走Phoenix，用户自己选，协议不替你做决定。

我后来想明白了一件事。这个设计的核心矛盾不是技术能不能实现，而是「给用户选择权」。传统公链只给了透明一条路，隐私币只给了隐私一条路，Dusk把两条路都铺好了，让用户按场景选择。代价是协议的复杂度增加了，但换来的是更灵活的金融场景适配能力。#dusk

Ich habe bei den von mir getesteten öffentlichen Blockchain-Projekten festgestellt, dass die P2P-Schicht oft erst als Letztes beachtet wird. Alle reden lieber über Konsens, über die virtuelle Maschine, über Cross-Chain. Aber wer wirklich ein Full Node betreibt, weiß: Sobald die Bandbreite stärker belastet wird, kann im Monat schnell mehrere Terabyte an Datenvolumen verbraucht werden. Diese Kosten sind in kleinem Maßstab noch in Ordnung – sobald man jedoch globale Finanzinstitute bedienen muss, wird das zu einem nicht zu ignorierenden Problem. In dem Whitepaper ist die Beschreibung des traditionellen P2P-Netzwerks recht direkt: Es habe zwei große Schwächen – hoher Bandbreitenverbrauch und große Latenz. Mein eigenes Verständnis ist, dass bei der herkömmlichen Broadcast-Methode jede Block- oder Transaktionsnachricht im gesamten Netzwerk verbreitet wird: Jeder Knoten, der die Nachricht erhält, leitet sie an alle Nachbarn weiter. Dadurch wächst die Nachrichtenmenge exponentiell. Das Netz ist voller redundanter, sich wiederholender Daten. Die Lösung von Dusk@Dusk_Foundation heißt Kadcast, basierend auf Kademlia DHT. Es organisiert die Knoten hierarchisch in einer Baumstruktur. Jeder Knoten leitet nicht blind weiter, sondern berechnet anhand der XOR-Distanz, und sendet nur an ausgewählte Knoten mit zunehmender Distanz weiter. Die Nachricht wird in der Baumstruktur Schritt für Schritt nach unten übertragen und erzeugt so eine Kaskadenwirkung. Pro Ebene wird nur an wenige Knoten weitergeleitet – nicht an alle Knoten im gesamten Netzwerk. #dusk Dieser Ansatz hat mich wirklich inspiriert. Im Grunde sagt er: Die P2P-Schicht der Blockchain muss nicht zwingend nach dem Muster funktionieren „Alle sagen allen“. Die Logik der Verteilung von Finanzinformationen $DUSK ist selbst bereits „Wer es braucht, empfängt es“. Wie viel Bandbreite Kadcast konkret spart, nennt das Whitepaper zwar nicht mit konkreten Testergebnissen, aber allein aus dem Mechanismusdesign heraus sollte die Reduktion redundanter Nachrichtenmengen sehr beträchtlich sein. Allerdings hat eine Baumstruktur auch ihre Schwachstellen: Die Stabilität der Knoten in der Mitte ist für das Netzwerk entscheidend. Das muss im weiteren Betrieb kontinuierlich beobachtet werden.

Ich habe bei den von mir getesteten öffentlichen Blockchain-Projekten festgestellt, dass die P2P-Schicht oft erst als Letztes beachtet wird. Alle reden lieber über Konsens, über die virtuelle Maschine, über Cross-Chain. Aber wer wirklich ein Full Node betreibt, weiß: Sobald die Bandbreite stärker belastet wird, kann im Monat schnell mehrere Terabyte an Datenvolumen verbraucht werden. Diese Kosten sind in kleinem Maßstab noch in Ordnung – sobald man jedoch globale Finanzinstitute bedienen muss, wird das zu einem nicht zu ignorierenden Problem.

In dem Whitepaper ist die Beschreibung des traditionellen P2P-Netzwerks recht direkt: Es habe zwei große Schwächen – hoher Bandbreitenverbrauch und große Latenz. Mein eigenes Verständnis ist, dass bei der herkömmlichen Broadcast-Methode jede Block- oder Transaktionsnachricht im gesamten Netzwerk verbreitet wird: Jeder Knoten, der die Nachricht erhält, leitet sie an alle Nachbarn weiter. Dadurch wächst die Nachrichtenmenge exponentiell. Das Netz ist voller redundanter, sich wiederholender Daten.

Die Lösung von Dusk@Dusk heißt Kadcast, basierend auf Kademlia DHT. Es organisiert die Knoten hierarchisch in einer Baumstruktur. Jeder Knoten leitet nicht blind weiter, sondern berechnet anhand der XOR-Distanz, und sendet nur an ausgewählte Knoten mit zunehmender Distanz weiter. Die Nachricht wird in der Baumstruktur Schritt für Schritt nach unten übertragen und erzeugt so eine Kaskadenwirkung. Pro Ebene wird nur an wenige Knoten weitergeleitet – nicht an alle Knoten im gesamten Netzwerk. #dusk

Dieser Ansatz hat mich wirklich inspiriert. Im Grunde sagt er: Die P2P-Schicht der Blockchain muss nicht zwingend nach dem Muster funktionieren „Alle sagen allen“. Die Logik der Verteilung von Finanzinformationen $DUSK ist selbst bereits „Wer es braucht, empfängt es“. Wie viel Bandbreite Kadcast konkret spart, nennt das Whitepaper zwar nicht mit konkreten Testergebnissen, aber allein aus dem Mechanismusdesign heraus sollte die Reduktion redundanter Nachrichtenmengen sehr beträchtlich sein.

Allerdings hat eine Baumstruktur auch ihre Schwachstellen: Die Stabilität der Knoten in der Mitte ist für das Netzwerk entscheidend. Das muss im weiteren Betrieb kontinuierlich beobachtet werden.

Als ich das Projekt Dusk zum ersten Mal sah, war der erste Gedanke, der mir durch den Kopf schoss: „Dieses Projekt wirkt ein wenig gierig.“ Privatsphäre und Compliance zusammenzubringen fühlt sich für mich an wie Wasser und Öl – schwer, sie wirklich zu vereinen. Die grundlegende Logik von Privacy Coins lautet „du sollst es nicht sehen können“. Die grundlegende Logik von Compliance lautet „die, die es sehen müssen, müssen es auch sehen“. Wie diese beiden Linien miteinander koexistieren können – das konnte ich mir damals nicht erklären.$DUSK Mit dieser Frage im Hinterkopf habe ich weitergelesen und festgestellt, dass meine damalige Einschätzung nicht wirklich standhält. In dem Whitepaper wird ein Blickwinkel erwähnt, an den ich vorher nicht ernsthaft gedacht hatte. In den gängigen Mainstream-Blockchains wie Ethereum ist Privatsphäre in Finanzszenarien tatsächlich nicht ausreichend. Transaktionsdaten und Bestände liegen komplett on-chain offen, sodass institutionelles Kapital gar nicht erst hineinkommt. Auf der anderen Seite bringen Monero und Zcash die Privatsphäre zwar auf den maximalen Punkt, aber sie sind völlig losgelöst von dem bestehenden Finanz-Compliance- und Regulierungsrahmen. Es gibt kein KYC, kein AML und keine Nachvollziehbarkeit durch Prüfungen – auch dadurch können Institutionen es nicht nutzen.#dusk Dusk@Dusk_Foundation hat sich entschieden, sowohl Privatsphäre als auch Compliance zu machen. Die Logik, die ich später dafür verstanden habe, ist im Grunde ganz direkt: Es zielt auf den Markt des regulierten Finanzsystems. In diesem Markt gibt es einen gleichzeitigen harten Bedarf an Privatsphäre und Compliance. Du musst sowohl in der Lage sein, die Vertraulichkeit von Transaktionen zu schützen, als auch bei Bedarf Daten gegenüber Aufsichtsbehörden offenzulegen. Das Dual-Trade-Modell von Moonlight und Phoenix sowie das Zedger-Protokoll sind Lösungen, die aus genau diesem Widerspruch heraus entstanden sind. Dieser Weg ist deutlich schwieriger als nur das eine zu machen. Ob er sich wirklich „durchlaufen“ lässt, hängt letztlich davon ab, wie gut die weitere Ökologie im Alltag umgesetzt wird.

Als ich das Projekt Dusk zum ersten Mal sah, war der erste Gedanke, der mir durch den Kopf schoss: „Dieses Projekt wirkt ein wenig gierig.“ Privatsphäre und Compliance zusammenzubringen fühlt sich für mich an wie Wasser und Öl – schwer, sie wirklich zu vereinen. Die grundlegende Logik von Privacy Coins lautet „du sollst es nicht sehen können“. Die grundlegende Logik von Compliance lautet „die, die es sehen müssen, müssen es auch sehen“. Wie diese beiden Linien miteinander koexistieren können – das konnte ich mir damals nicht erklären.$DUSK

Mit dieser Frage im Hinterkopf habe ich weitergelesen und festgestellt, dass meine damalige Einschätzung nicht wirklich standhält.

In dem Whitepaper wird ein Blickwinkel erwähnt, an den ich vorher nicht ernsthaft gedacht hatte. In den gängigen Mainstream-Blockchains wie Ethereum ist Privatsphäre in Finanzszenarien tatsächlich nicht ausreichend. Transaktionsdaten und Bestände liegen komplett on-chain offen, sodass institutionelles Kapital gar nicht erst hineinkommt. Auf der anderen Seite bringen Monero und Zcash die Privatsphäre zwar auf den maximalen Punkt, aber sie sind völlig losgelöst von dem bestehenden Finanz-Compliance- und Regulierungsrahmen. Es gibt kein KYC, kein AML und keine Nachvollziehbarkeit durch Prüfungen – auch dadurch können Institutionen es nicht nutzen.#dusk

Dusk@Dusk hat sich entschieden, sowohl Privatsphäre als auch Compliance zu machen. Die Logik, die ich später dafür verstanden habe, ist im Grunde ganz direkt: Es zielt auf den Markt des regulierten Finanzsystems. In diesem Markt gibt es einen gleichzeitigen harten Bedarf an Privatsphäre und Compliance. Du musst sowohl in der Lage sein, die Vertraulichkeit von Transaktionen zu schützen, als auch bei Bedarf Daten gegenüber Aufsichtsbehörden offenzulegen. Das Dual-Trade-Modell von Moonlight und Phoenix sowie das Zedger-Protokoll sind Lösungen, die aus genau diesem Widerspruch heraus entstanden sind.

Dieser Weg ist deutlich schwieriger als nur das eine zu machen. Ob er sich wirklich „durchlaufen“ lässt, hängt letztlich davon ab, wie gut die weitere Ökologie im Alltag umgesetzt wird.

Ich habe kürzlich über eine Frage nachgedacht. Bitcoin ist das wertvollste Asset in der Krypto-Szene: die gesamte Marktkapitalisierung liegt bei ungefähr 600 Milliarden US-Dollar, $DUSK macht mehr als die Hälfte des gesamten Marktes aus. Diese Zahl habe ich beim Lesen des Whitepapers noch einmal bestätigt. Aber wenn man sich DeFi ansieht, findet man von Bitcoin so gut wie nichts. wBTC ist zwar die bislang größte Wrapping-Lösung, aber die Marktkapitalisierung liegt auch nur bei weniger als 5 Milliarden – im Vergleich zum Volumen von Bitcoin ist das nicht mal ein Bruchteil @Dusk_Foundation Dieser Abstand ist so groß, dass es mich ein wenig unwohl macht. Wo liegt das Problem? Am Anfang dachte ich, es liege daran, dass Bitcoin selbst keine Smart Contracts unterstützt und diese Logik wie Kreditvergabe direkt auf der Chain nicht ausführen kann. Daher muss man es über Wrapping bzw. Cross-Chain-Lösungen abbilden. Dieses Verständnis stimmt, aber als ich das Whitepaper las, fiel mir eine noch wesentlichere Ebene auf. Im Whitepaper gibt es einen Satz, den ich mir immer wieder angesehen habe: Bridge- und zentrale Custody-Lösungen gelten für viele Bitcoin-Besitzer als zu riskant. Es ist nicht so, dass man es technisch nicht machen könnte – vielmehr sind die Besitzer nicht bereit, dieses Risiko einzugehen. Ich habe versucht, es mir praktisch vorzustellen. Wenn ich eine Menge Bitcoin besitze und damit in DeFi Zinsen verdienen möchte, muss ich sie erst in wBTC umtauschen. Das bedeutet: Ich muss meinen Bitcoin an einen Custodian übergeben und ihm vertrauen, dass dabei nichts schiefgeht. In der Vergangenheit sind bei Cross-Chain-Brücken und Custodians schon zu viele Dinge passiert. Dieser Vertrauensaufwand wiegt für mich möglicherweise schwerer als ein paar Zinsen. Ich vermute, dass viele Hoderer ähnlich denken wie ich – lieber liegt der Bitcoin im Wallet, zumindest ist er sicher. #dusk So entsteht eine ziemlich vertrackte Situation. Bitcoin ist das größte und sicherste Asset, aber wegen seines Sicherheitsmodells und der Risikoneigung der Inhaber wird es dadurch paradoxerweise zu den Assets, die in DeFi am wenigsten genutzt werden. TBV will genau diese Lücke schließen: Bitcoin soll ohne Bridging und ohne Custody in DeFi kommen. Ob dieser Weg wirklich funktioniert, kann ich heute noch nicht sicher sagen, aber dieses Widerspruchsproblem an sich lohnt es sich, klar durchzudenken.

Ich habe kürzlich über eine Frage nachgedacht. Bitcoin ist das wertvollste Asset in der Krypto-Szene: die gesamte Marktkapitalisierung liegt bei ungefähr 600 Milliarden US-Dollar, $DUSK macht mehr als die Hälfte des gesamten Marktes aus. Diese Zahl habe ich beim Lesen des Whitepapers noch einmal bestätigt. Aber wenn man sich DeFi ansieht, findet man von Bitcoin so gut wie nichts. wBTC ist zwar die bislang größte Wrapping-Lösung, aber die Marktkapitalisierung liegt auch nur bei weniger als 5 Milliarden – im Vergleich zum Volumen von Bitcoin ist das nicht mal ein Bruchteil @Dusk

Dieser Abstand ist so groß, dass es mich ein wenig unwohl macht. Wo liegt das Problem?

Am Anfang dachte ich, es liege daran, dass Bitcoin selbst keine Smart Contracts unterstützt und diese Logik wie Kreditvergabe direkt auf der Chain nicht ausführen kann. Daher muss man es über Wrapping bzw. Cross-Chain-Lösungen abbilden. Dieses Verständnis stimmt, aber als ich das Whitepaper las, fiel mir eine noch wesentlichere Ebene auf. Im Whitepaper gibt es einen Satz, den ich mir immer wieder angesehen habe: Bridge- und zentrale Custody-Lösungen gelten für viele Bitcoin-Besitzer als zu riskant. Es ist nicht so, dass man es technisch nicht machen könnte – vielmehr sind die Besitzer nicht bereit, dieses Risiko einzugehen.

Ich habe versucht, es mir praktisch vorzustellen. Wenn ich eine Menge Bitcoin besitze und damit in DeFi Zinsen verdienen möchte, muss ich sie erst in wBTC umtauschen. Das bedeutet: Ich muss meinen Bitcoin an einen Custodian übergeben und ihm vertrauen, dass dabei nichts schiefgeht. In der Vergangenheit sind bei Cross-Chain-Brücken und Custodians schon zu viele Dinge passiert. Dieser Vertrauensaufwand wiegt für mich möglicherweise schwerer als ein paar Zinsen. Ich vermute, dass viele Hoderer ähnlich denken wie ich – lieber liegt der Bitcoin im Wallet, zumindest ist er sicher. #dusk

So entsteht eine ziemlich vertrackte Situation. Bitcoin ist das größte und sicherste Asset, aber wegen seines Sicherheitsmodells und der Risikoneigung der Inhaber wird es dadurch paradoxerweise zu den Assets, die in DeFi am wenigsten genutzt werden. TBV will genau diese Lücke schließen: Bitcoin soll ohne Bridging und ohne Custody in DeFi kommen. Ob dieser Weg wirklich funktioniert, kann ich heute noch nicht sicher sagen, aber dieses Widerspruchsproblem an sich lohnt es sich, klar durchzudenken.

Ich habe immer gedacht, dass für eine Abwicklung „Menschen“ gebraucht werden, um das auszuführen: Richter, Schiedsrichter, die Abwicklungskommission. Bis ich gestern Section 6 erneut gelesen habe, den „unhappy path“. Meine erste Vorstellung war ganz einfach: In DeFi stellt ein Kreditnehmer Sicherheiten bereit. Wenn die Sicherheiten die Schulden nicht decken, braucht es jemanden, der die Abwicklung ausführt, oder einen Abwicklungsbot. Das klingt ganz selbstverständlich – irgendjemand muss doch „diesen Knopf drücken“. Also, als ich die Slashing-Mechanik von Babylon sah, war meine erste Reaktion: Wer löst das Slashing aus? Wer überprüft die Belege für Fehlverhalten? #baby Aber in Sec 6 gibt es einen Satz, der mich stoppen ließ: „Anyone can impersonate Alice and send a slashing transaction to burn her 1 BTC.“ Nicht der „bestimmte Abwickler“, nicht das Multi-Sig-Komitee, sondern anyone. Jeder. Ich habe diese Logikkette neu gezeichnet und gemerkt: Babylon entwirft gar keinen „Ablauf zur Abwicklung“, sondern eine kausale Kette, die bei einem Schlüssel-Leak entsteht. Die mathematische Grundlage von EOTS (Extractable One-Time Signatures) ist: Wenn ein Validator auf derselben Höhe doppelt signiert, legen die zwei Signaturen mathematische Informationen über den privaten Schlüssel frei. Jeder, der diesen geleakten privaten Schlüssel hat, kann dann direkt eine Bitcoin-Slashing-Transaktion auslösen und die gestaketen Bitcoins an eine Burn-Adresse senden. $BABY Daher glaube ich nicht, dass es „drei Schritte“ sind: „Das System erkennt, dass du Schlechtes tust → benachrichtigt den Abwickler → führt das Slashing aus“, sondern eher „ein Schritt“: „Du tust Schlechtes → der private Schlüssel leakt automatisch → die Bitcoins werden automatisch zerstört“. Keine Abwicklung – Selbstzerstörung. Der Zerlegungsblick auf diese Struktur ließ mich erkennen, dass Babylon die Machtbeziehungen beim Slashing neu definiert hat. In traditionellen Lösungen liegt das Abwicklungsrecht bei Dritten: dem DeFi-Abwicklungsbot oder dem Validatoren-Komitee einer PoS-Kette. Bei Babylon liegt das Slashing-Recht in der Mathematik. Kein Ermessensspielraum, keine verzögerte Ausführung, kein „schon gut, dieses Mal lassen wir dich durch“. Die einzige Konsequenz von Fehlverhalten ist: Der private Schlüssel wird öffentlich, und die Bitcoins werden verbrannt. Das Kernthema ist also nicht „wie effizient das Slashing ist“, sondern dass es Vertrauen von „menschlicher Bewertung“ auf „mathematische Notwendigkeit“ verlagert. Im TBV-Kredit-/Leihszenario bedeutet das: Die Sicherheit der Sicherheiten hängt nicht mehr von Gutwillen oder Effizienz irgendeiner Person ab, sondern nur von kryptografischen Einmal-Signatur-Bindungen. @babylonlabs_io Voraussetzung ist natürlich, dass die Kette Doppelsignaturen erkennen kann.

Verifiziert

Ich habe immer gedacht, dass für eine Abwicklung „Menschen“ gebraucht werden, um das auszuführen: Richter, Schiedsrichter, die Abwicklungskommission. Bis ich gestern Section 6 erneut gelesen habe, den „unhappy path“.

Meine erste Vorstellung war ganz einfach: In DeFi stellt ein Kreditnehmer Sicherheiten bereit. Wenn die Sicherheiten die Schulden nicht decken, braucht es jemanden, der die Abwicklung ausführt, oder einen Abwicklungsbot. Das klingt ganz selbstverständlich – irgendjemand muss doch „diesen Knopf drücken“. Also, als ich die Slashing-Mechanik von Babylon sah, war meine erste Reaktion: Wer löst das Slashing aus? Wer überprüft die Belege für Fehlverhalten? #baby

Aber in Sec 6 gibt es einen Satz, der mich stoppen ließ: „Anyone can impersonate Alice and send a slashing transaction to burn her 1 BTC.“

Nicht der „bestimmte Abwickler“, nicht das Multi-Sig-Komitee, sondern anyone. Jeder.

Ich habe diese Logikkette neu gezeichnet und gemerkt: Babylon entwirft gar keinen „Ablauf zur Abwicklung“, sondern eine kausale Kette, die bei einem Schlüssel-Leak entsteht. Die mathematische Grundlage von EOTS (Extractable One-Time Signatures) ist: Wenn ein Validator auf derselben Höhe doppelt signiert, legen die zwei Signaturen mathematische Informationen über den privaten Schlüssel frei. Jeder, der diesen geleakten privaten Schlüssel hat, kann dann direkt eine Bitcoin-Slashing-Transaktion auslösen und die gestaketen Bitcoins an eine Burn-Adresse senden. $BABY

Daher glaube ich nicht, dass es „drei Schritte“ sind: „Das System erkennt, dass du Schlechtes tust → benachrichtigt den Abwickler → führt das Slashing aus“, sondern eher „ein Schritt“: „Du tust Schlechtes → der private Schlüssel leakt automatisch → die Bitcoins werden automatisch zerstört“. Keine Abwicklung – Selbstzerstörung.

Der Zerlegungsblick auf diese Struktur ließ mich erkennen, dass Babylon die Machtbeziehungen beim Slashing neu definiert hat. In traditionellen Lösungen liegt das Abwicklungsrecht bei Dritten: dem DeFi-Abwicklungsbot oder dem Validatoren-Komitee einer PoS-Kette. Bei Babylon liegt das Slashing-Recht in der Mathematik. Kein Ermessensspielraum, keine verzögerte Ausführung, kein „schon gut, dieses Mal lassen wir dich durch“. Die einzige Konsequenz von Fehlverhalten ist: Der private Schlüssel wird öffentlich, und die Bitcoins werden verbrannt.

Das Kernthema ist also nicht „wie effizient das Slashing ist“, sondern dass es Vertrauen von „menschlicher Bewertung“ auf „mathematische Notwendigkeit“ verlagert. Im TBV-Kredit-/Leihszenario bedeutet das: Die Sicherheit der Sicherheiten hängt nicht mehr von Gutwillen oder Effizienz irgendeiner Person ab, sondern nur von kryptografischen Einmal-Signatur-Bindungen. @BabylonLabs_io

Voraussetzung ist natürlich, dass die Kette Doppelsignaturen erkennen kann.

Ich hatte schon immer das Gefühl, dass die „ungenutzte“ Seite von Bitcoin ein übersehenes Problem ist, bis ich lange auf einen Satz im Whitepaper starrte. Zuerst dachte ich, das größte Problem von Bitcoin seien die Kursvolatilität oder das Regulierungsrisiko. Aber als ich das Whitepaper las, fiel mir eine Zahl zu wBTC ins Auge: Die Marktkapitalisierung liegt bei unter 5 Milliarden US-Dollar und macht nur ein Prozent der gesamten Bitcoin-Marktkapitalisierung aus. Das bedeutet: In einem Marktwert von $BABY 6,000 Milliarden US-Dollar liegen die allermeisten Bitcoins einfach nur in Wallets herum – und tun nichts. Sie sind wie Gold in einem Tresor: perfekt gelagert, aber ohne Ertrag. Sec 2.2 sagt es noch direkter: „Most of the Bitcoin asset sits idle and is not deployed.“ Dieser Satz ließ mich innehalten. Nicht „ein Teil“ ist ungenutzt, sondern „most“. Nicht weil es technisch nicht möglich wäre, sondern weil die bestehenden Brückentechniken darauf vertrauen müssen, dass Dritte vertrauenswürdig handeln – und Bitcoin-Holder dieses Risiko nicht eingehen wollen.#baby Als ich noch einmal eine Grafik zum Kapitalfluss neu gezeichnet habe, wurde mir klar: Was Babylon tut, ist nicht, Bitcoin eine „Vermögensverwaltungs“-Funktion hinzuzufügen, sondern den „arbeitsfähigen Zustand“ von Bitcoin neu zu definieren. Es ersetzt das Bridging durch Remote-Staking, sodass Bitcoin ohne den Verlassen der Bitcoin-Blockchain Sicherheitsmargen für PoS-Chains bereitstellen kann. Bitcoin muss nicht mehr umgezogen werden, muss nicht mehr verwahrt werden – es muss nur in einem selbstverwalteten Tresor gesperrt werden, mit kryptografischen Regeln, die die Möglichkeit von Slashing absichern. Babylon baut keinen neuen Ertragskanal. Es definiert Bitcoin vielmehr von „ungenutztem Vermögenswert“ zu „Sicherheits-Treibstoff für PoS-Chains“ um. Das verändert die Effizienz der Kapitalnutzung: PoS-Chains müssen nicht mehr auf hohe Inflation setzen, um natives Token-Staking zu gewinnen, sondern können direkt den gewaltigen 600-Milliarden-US-Dollar-Pool an Bitcoin als Sicherheit nutzen. Das klar definierte „zweiseitige Markt“-Modell in Sec 3 ist im Grunde genommen die Treibstoffpumpe.@babylonlabs_io Natürlich hängt diese Erzählung derzeit noch von einem Wandel im Verständnis der Bitcoin-Holder ab. Wer daran gewöhnt ist, „zu halten und nichts zu tun“, ist dann bereit, die Komplexität des „geblockten Stakings“ zu akzeptieren? Ich beobachte das weiterhin – die tatsächliche Akzeptanzrate auf diesem Pfad der Erweckung.

Ich hatte schon immer das Gefühl, dass die „ungenutzte“ Seite von Bitcoin ein übersehenes Problem ist, bis ich lange auf einen Satz im Whitepaper starrte.

Zuerst dachte ich, das größte Problem von Bitcoin seien die Kursvolatilität oder das Regulierungsrisiko. Aber als ich das Whitepaper las, fiel mir eine Zahl zu wBTC ins Auge: Die Marktkapitalisierung liegt bei unter 5 Milliarden US-Dollar und macht nur ein Prozent der gesamten Bitcoin-Marktkapitalisierung aus. Das bedeutet: In einem Marktwert von $BABY 6,000 Milliarden US-Dollar liegen die allermeisten Bitcoins einfach nur in Wallets herum – und tun nichts. Sie sind wie Gold in einem Tresor: perfekt gelagert, aber ohne Ertrag.

Sec 2.2 sagt es noch direkter: „Most of the Bitcoin asset sits idle and is not deployed.“ Dieser Satz ließ mich innehalten. Nicht „ein Teil“ ist ungenutzt, sondern „most“. Nicht weil es technisch nicht möglich wäre, sondern weil die bestehenden Brückentechniken darauf vertrauen müssen, dass Dritte vertrauenswürdig handeln – und Bitcoin-Holder dieses Risiko nicht eingehen wollen.#baby

Als ich noch einmal eine Grafik zum Kapitalfluss neu gezeichnet habe, wurde mir klar: Was Babylon tut, ist nicht, Bitcoin eine „Vermögensverwaltungs“-Funktion hinzuzufügen, sondern den „arbeitsfähigen Zustand“ von Bitcoin neu zu definieren. Es ersetzt das Bridging durch Remote-Staking, sodass Bitcoin ohne den Verlassen der Bitcoin-Blockchain Sicherheitsmargen für PoS-Chains bereitstellen kann. Bitcoin muss nicht mehr umgezogen werden, muss nicht mehr verwahrt werden – es muss nur in einem selbstverwalteten Tresor gesperrt werden, mit kryptografischen Regeln, die die Möglichkeit von Slashing absichern.

Babylon baut keinen neuen Ertragskanal. Es definiert Bitcoin vielmehr von „ungenutztem Vermögenswert“ zu „Sicherheits-Treibstoff für PoS-Chains“ um. Das verändert die Effizienz der Kapitalnutzung: PoS-Chains müssen nicht mehr auf hohe Inflation setzen, um natives Token-Staking zu gewinnen, sondern können direkt den gewaltigen 600-Milliarden-US-Dollar-Pool an Bitcoin als Sicherheit nutzen. Das klar definierte „zweiseitige Markt“-Modell in Sec 3 ist im Grunde genommen die Treibstoffpumpe.@BabylonLabs_io

Natürlich hängt diese Erzählung derzeit noch von einem Wandel im Verständnis der Bitcoin-Holder ab. Wer daran gewöhnt ist, „zu halten und nichts zu tun“, ist dann bereit, die Komplexität des „geblockten Stakings“ zu akzeptieren? Ich beobachte das weiterhin – die tatsächliche Akzeptanzrate auf diesem Pfad der Erweckung.

Ich habe abends noch einmal das Whitepaper, Abschnitt 7.2, hervorgeholt. Als ich es zuvor gelesen habe, dachte ich, „Strafabzug“ bedeute einfach: „Man packt den Übeltäter, und zieht Geld ab.“ Doch als ich mir diesmal die beiden Passagen genau ansah, merkte ich, wie stark ich die Schwierigkeit dieser Sache unterschätzt hatte: Bitcoin hat keine Smart Contracts. Du kannst „Beweise“ nicht an ihn übergeben, damit er beurteilt, wer im Recht ist und wer nicht. Was also tun? Die Antwort lautet: — Die Beweise selbst in einen privaten Schlüssel verwandeln.#baby Das Whitepaper sagt das ganz klar. Da Bitcoin keine Smart Contracts hat, kannst du nicht wie bei Ethereum eine Regelwidrigkeits-Beweisvorlage an einen On-Chain-Contract übergeben, damit dieser die Strafe vollzieht. Babylons Ansatz ist: Keine „Beweise“ einreichen, sondern direkt „private Schlüssel“ — damit der Angreifer beim Moment des Fehlverhaltens zwangsläufig seinen privaten Schlüssel preisgibt. Wie macht man das? Durch die Kombination von zwei Dingen: extrahierbaren Einmal-Signaturen (EOTS) und Werkzeugen für die Endgültigkeit. Die Zusage von EOTS ist recht simpel: Mit demselben privaten Schlüssel werden zwei verschiedene Nachrichten signiert, und der private Schlüssel kann dann mathematisch aus den Signaturen extrahiert werden — sichtbar für das ganze Netzwerk. Das Problem ist: Die Strafabzug-Szenarien eines Konsensprotokolls gehen weit über „Doppel-Signatur“ hinaus. Casper hat zwei Sätze von Strafabzugsbedingungen, Tendermint ebenfalls — sogar ein „Forgetfulness-Angriff“ lässt sich nicht einmal als Doppel-Signatur-Angriff formulieren. Babylons Lösung ist dabei sehr clever: Man verändert das grundlegende Konsensprotokoll nicht, sondern fügt nach der Konsensentscheidung über einen Block noch eine weitere Runde EOTS-Signaturabstimmung hinzu. Erst wenn nach dem Signieren durch mehr als 2/3 der verpfändeten Rechte, gilt der Block wirklich als final endgültig festgelegt. Dadurch werden alle Handlungen, die die Unversehrtheit der Blockchain sabotieren, auf „Zwei Blöcke auf derselben Höhe signieren“ reduziert — also auf einen klaren und geschickten Doppel-Signatur-Angriff. So kann EOTS den privaten Schlüssel extrahieren, und die Schnorr-Signaturen (das Signaturschema, das Bitcoin verwendet) sind genau kompatibel; der private Schlüssel kann direkt für die Strafabzugs-Transaktion verwendet werden.$BABY Später habe ich in meinen Notizen einen Satz geschrieben: „Andere Protokolle sagen: ‚Gib mir die Beweise, dann entscheide ich über Recht und Unrecht.‘ Babylon sagt: ‚Du musst gar nichts entscheiden. Wenn du Böses tust, ist dein Schlüssel der Beweis.‘ — Das ist nicht die Optimierung von Justiz, das ist die Abschaffung des Richters. “@babylonlabs_io

Ich habe abends noch einmal das Whitepaper, Abschnitt 7.2, hervorgeholt. Als ich es zuvor gelesen habe, dachte ich, „Strafabzug“ bedeute einfach: „Man packt den Übeltäter, und zieht Geld ab.“ Doch als ich mir diesmal die beiden Passagen genau ansah, merkte ich, wie stark ich die Schwierigkeit dieser Sache unterschätzt hatte: Bitcoin hat keine Smart Contracts. Du kannst „Beweise“ nicht an ihn übergeben, damit er beurteilt, wer im Recht ist und wer nicht. Was also tun? Die Antwort lautet: — Die Beweise selbst in einen privaten Schlüssel verwandeln.#baby

Das Whitepaper sagt das ganz klar. Da Bitcoin keine Smart Contracts hat, kannst du nicht wie bei Ethereum eine Regelwidrigkeits-Beweisvorlage an einen On-Chain-Contract übergeben, damit dieser die Strafe vollzieht. Babylons Ansatz ist: Keine „Beweise“ einreichen, sondern direkt „private Schlüssel“ — damit der Angreifer beim Moment des Fehlverhaltens zwangsläufig seinen privaten Schlüssel preisgibt.

Wie macht man das? Durch die Kombination von zwei Dingen: extrahierbaren Einmal-Signaturen (EOTS) und Werkzeugen für die Endgültigkeit.

Die Zusage von EOTS ist recht simpel: Mit demselben privaten Schlüssel werden zwei verschiedene Nachrichten signiert, und der private Schlüssel kann dann mathematisch aus den Signaturen extrahiert werden — sichtbar für das ganze Netzwerk. Das Problem ist: Die Strafabzug-Szenarien eines Konsensprotokolls gehen weit über „Doppel-Signatur“ hinaus. Casper hat zwei Sätze von Strafabzugsbedingungen, Tendermint ebenfalls — sogar ein „Forgetfulness-Angriff“ lässt sich nicht einmal als Doppel-Signatur-Angriff formulieren.

Babylons Lösung ist dabei sehr clever: Man verändert das grundlegende Konsensprotokoll nicht, sondern fügt nach der Konsensentscheidung über einen Block noch eine weitere Runde EOTS-Signaturabstimmung hinzu. Erst wenn nach dem Signieren durch mehr als 2/3 der verpfändeten Rechte, gilt der Block wirklich als final endgültig festgelegt. Dadurch werden alle Handlungen, die die Unversehrtheit der Blockchain sabotieren, auf „Zwei Blöcke auf derselben Höhe signieren“ reduziert — also auf einen klaren und geschickten Doppel-Signatur-Angriff. So kann EOTS den privaten Schlüssel extrahieren, und die Schnorr-Signaturen (das Signaturschema, das Bitcoin verwendet) sind genau kompatibel; der private Schlüssel kann direkt für die Strafabzugs-Transaktion verwendet werden.$BABY

Später habe ich in meinen Notizen einen Satz geschrieben: „Andere Protokolle sagen: ‚Gib mir die Beweise, dann entscheide ich über Recht und Unrecht.‘ Babylon sagt: ‚Du musst gar nichts entscheiden. Wenn du Böses tust, ist dein Schlüssel der Beweis.‘ — Das ist nicht die Optimierung von Justiz, das ist die Abschaffung des Richters. “@BabylonLabs_io

Ich dachte anfangs, dass Dezentralisierung im Krypto-Bereich „gerechter“ ist oder „besser gegen Zensur schützt“. Es klingt stimmig, aber ich kann nicht genau erklären, was das mit Cybersicherheit im Konkreten zu tun hat. Also, als ich gestern Abend sah, dass Babylon sagt, sein sogenanntes Staking-Protokoll sei „ohne die Notwendigkeit, irgendeinem Dritten zu vertrauen“, war meine erste Reaktion: Das ist cool, aber die Umsetzungsmechanismen sind Kryptografie und Zeitstempel – das hat nicht viel mit Dezentralisierung zu tun #baby Doch in Sec 2.3 gibt es einen Satz, der mich hat innehalten lassen: „Bitcoin, als älteste Blockchain, verfügt wahrscheinlich über die dezentralisierteste Gruppe von Token-Inhabern: Miner, frühe Anwender und Entwickler, Projektgründer, einzelne Investoren, institutionelle Investoren, Börsen usw.“ Ich habe dann ein Vermögensverteilungsdiagramm neu gezeichnet und erst dadurch verstanden: Die Dezentralität der Bitcoin-Besitzer ist kein „politisch korrekter“ Aspekt, sondern ein struktureller Sicherheitsparameter. In vielen PoS-Ketten konzentriert sich das Vermögen bei frühen Investoren, Gründerteams und Stiftungen. Wenn diese Vermögenswerte zum Validieren des Netzwerks gestaked werden, können wenige Entitäten sich zusammentun, um die Kette zu kontrollieren. Bei Bitcoin ist die Verteilung der Inhaber jedoch extrem dezentral – das bedeutet, dass man genügend private Schlüssel einsammeln muss, um einen Angriff zu starten, und die Hürde steigt exponentiell an $BABY Ich glaube, Babylon „entwirft“ kein Dezentralisierungs-Protokoll, sondern „leiht“ sich die bereits vorhandene Dezentralisierungsstruktur von Bitcoin. Es bildet die Dezentralität der Bitcoin-Inhaber direkt auf den Sicherheits-Trust-Anchor der PoS-Kette ab: Je mehr Staker, desto stärker verteilt – desto mehr Kollaborateure müsste der Angreifer finden, und desto höher werden die Angriffskosten. Das ist kein Feature, sondern ein strukturelles Axiom @babylonlabs_io Ich denke, das bedeutet nicht, dass Staking bei Bitcoin keine Zentralisierungsrisiken hätte. Wenn ein großer Teil der gestakten Bitcoins bei nur wenigen großen Custodian-Instanzen konzentriert wäre, würde dieses Dezentralitäts-Argument versagen. Ich beobachte das weiterhin: Werden Stimmrechte beim Staking ähnlich wie Rechenleistung im Laufe des langen Betriebs allmählich wieder stärker konzentriert?

Verifiziert

Ich dachte anfangs, dass Dezentralisierung im Krypto-Bereich „gerechter“ ist oder „besser gegen Zensur schützt“. Es klingt stimmig, aber ich kann nicht genau erklären, was das mit Cybersicherheit im Konkreten zu tun hat. Also, als ich gestern Abend sah, dass Babylon sagt, sein sogenanntes Staking-Protokoll sei „ohne die Notwendigkeit, irgendeinem Dritten zu vertrauen“, war meine erste Reaktion: Das ist cool, aber die Umsetzungsmechanismen sind Kryptografie und Zeitstempel – das hat nicht viel mit Dezentralisierung zu tun #baby

Doch in Sec 2.3 gibt es einen Satz, der mich hat innehalten lassen: „Bitcoin, als älteste Blockchain, verfügt wahrscheinlich über die dezentralisierteste Gruppe von Token-Inhabern: Miner, frühe Anwender und Entwickler, Projektgründer, einzelne Investoren, institutionelle Investoren, Börsen usw.“

Ich habe dann ein Vermögensverteilungsdiagramm neu gezeichnet und erst dadurch verstanden: Die Dezentralität der Bitcoin-Besitzer ist kein „politisch korrekter“ Aspekt, sondern ein struktureller Sicherheitsparameter. In vielen PoS-Ketten konzentriert sich das Vermögen bei frühen Investoren, Gründerteams und Stiftungen. Wenn diese Vermögenswerte zum Validieren des Netzwerks gestaked werden, können wenige Entitäten sich zusammentun, um die Kette zu kontrollieren. Bei Bitcoin ist die Verteilung der Inhaber jedoch extrem dezentral – das bedeutet, dass man genügend private Schlüssel einsammeln muss, um einen Angriff zu starten, und die Hürde steigt exponentiell an $BABY

Ich glaube, Babylon „entwirft“ kein Dezentralisierungs-Protokoll, sondern „leiht“ sich die bereits vorhandene Dezentralisierungsstruktur von Bitcoin. Es bildet die Dezentralität der Bitcoin-Inhaber direkt auf den Sicherheits-Trust-Anchor der PoS-Kette ab: Je mehr Staker, desto stärker verteilt – desto mehr Kollaborateure müsste der Angreifer finden, und desto höher werden die Angriffskosten. Das ist kein Feature, sondern ein strukturelles Axiom @BabylonLabs_io

Ich denke, das bedeutet nicht, dass Staking bei Bitcoin keine Zentralisierungsrisiken hätte. Wenn ein großer Teil der gestakten Bitcoins bei nur wenigen großen Custodian-Instanzen konzentriert wäre, würde dieses Dezentralitäts-Argument versagen. Ich beobachte das weiterhin: Werden Stimmrechte beim Staking ähnlich wie Rechenleistung im Laufe des langen Betriebs allmählich wieder stärker konzentriert?

Am Freitagabend habe ich erneut den Abschnitt 9.8 des Whitepapers zu „Bitcoin-Bridges“ hervorgeholt. Als ich ihn zuvor gelesen hatte, fand ich die Zusammenfassung der verschiedenen Bridge-Typen ziemlich umfassend: zentralisierte Bridges, überbesicherte Bridges, Sidechain-Bridges, Hardware-Sicherheitsbrücken … Dieses Mal habe ich jedoch speziell für jede Bridge-Art eine Sicherheits-Annahmen-Stärke als eine Art Spektrum eingezeichnet – von „vollständigem Vertrauen in den Custodian“ bis hin zu „mathematisch verifizierbar ohne Vertrauen“. Dabei ist mir ein interessantes Gegenüberstellen aufgefallen. Ich habe eine kleine Tabelle erstellt: wBTC vertraut Bitgo einen Custodian an – damit ist die Sicherheits-Annahmen-Stärke am niedrigsten; Interlay ist überbesichert und erfordert, dass das Tresor-Setup keinen Kollusionsfall eingeht und die Beleihungsquote hoch genug ist; sBTC stützt sich auf eine 70%-STX-Delegierten-Schwellen-Signatur – die Annahme ist, dass schon 30% ehrliche Teilnehmer ausreichen, um Sicherheit zu gewährleisten; Rootstock hat beim PowPeg Hardware hinzugefügt, aber die Annahme lautet, dass die Hardware nicht kompromittiert wird. Jede Bridge trifft einen Trade-off zwischen „Sicherheit“ und „Kapazität“: Wenn die Beleihungsquote höher ist, sind weniger BTC gesperrt; wenn die Threshold-Signaturgruppe größer ist, wird die Ausführbarkeit/Live-ness anfälliger.#baby Keine davon ist reine mathematische Gewähr. Danach habe ich Bitcoin-Staking mit in die Betrachtung aufgenommen: Es braucht keine Bridge. Bitcoin bleibt auf der Bitcoin-Blockchain, und Slashing/Strafabzüge werden über EOTS und Skripte umgesetzt. Aus Sicht der „Trust-Annäherungen“ ist das tatsächlich am saubersten – es braucht keinen Trust in Custodians, keine Staking-Pools und keine Threshold-Signaturgruppen. Aber ich habe daneben eine Randnotiz ergänzt: Der Nachteil dieses Ansatzes ist, dass das gestakte Bitcoin nicht an eine PoS-Chain übertragen werden kann, um dort eingesetzt zu werden; es kann nur als Sicherheits- bzw. Sicherheitsdepot verwendet werden. Wenn eine PoS-Chain BTC als Ausführungs-layer-Asset nutzen möchte (z. B. für Kredite oder Handel), kann $BABY Bitcoin-Staking nicht direkt diese Liquidität bereitstellen. Später habe ich in meine Notizen geschrieben: „Bridge-Lösungen handeln alle eine Art ‘Security Tax’ – um BTC in andere Chains zu transferieren, muss man einen Teil der Trust-Annäherungen oder der Kapitaleffizienz opfern. Bitcoin-Staking spart sich diese Steuer, verzichtet dafür aber auf die plattformübergreifende, übertragbare Eigenschaft der Assets.“ Daher ist es nicht die „bessere“ Bridge, sondern ein „völlig anderes“ Asset-Nutzungsmodell. Dieser Unterschied ist entscheidend; das Whitepaper stellt ihn nicht direkt gegenüber, aber ich glaube, das ist der Kern, um die Positionierung von Bitcoin-Equity-/Staking-Assets zu verstehen. Ich habe noch kein Fazit, werde aber weiter beobachten, ob im Bitcoin-Staking-Ökosystem PoS-Chains bereit sind, diese „nicht übertragbaren Sicherheits-Assets“ als Collateral zu akzeptieren.@babylonlabs_io

Am Freitagabend habe ich erneut den Abschnitt 9.8 des Whitepapers zu „Bitcoin-Bridges“ hervorgeholt. Als ich ihn zuvor gelesen hatte, fand ich die Zusammenfassung der verschiedenen Bridge-Typen ziemlich umfassend: zentralisierte Bridges, überbesicherte Bridges, Sidechain-Bridges, Hardware-Sicherheitsbrücken … Dieses Mal habe ich jedoch speziell für jede Bridge-Art eine Sicherheits-Annahmen-Stärke als eine Art Spektrum eingezeichnet – von „vollständigem Vertrauen in den Custodian“ bis hin zu „mathematisch verifizierbar ohne Vertrauen“. Dabei ist mir ein interessantes Gegenüberstellen aufgefallen.

Ich habe eine kleine Tabelle erstellt: wBTC vertraut Bitgo einen Custodian an – damit ist die Sicherheits-Annahmen-Stärke am niedrigsten; Interlay ist überbesichert und erfordert, dass das Tresor-Setup keinen Kollusionsfall eingeht und die Beleihungsquote hoch genug ist; sBTC stützt sich auf eine 70%-STX-Delegierten-Schwellen-Signatur – die Annahme ist, dass schon 30% ehrliche Teilnehmer ausreichen, um Sicherheit zu gewährleisten; Rootstock hat beim PowPeg Hardware hinzugefügt, aber die Annahme lautet, dass die Hardware nicht kompromittiert wird. Jede Bridge trifft einen Trade-off zwischen „Sicherheit“ und „Kapazität“: Wenn die Beleihungsquote höher ist, sind weniger BTC gesperrt; wenn die Threshold-Signaturgruppe größer ist, wird die Ausführbarkeit/Live-ness anfälliger.#baby Keine davon ist reine mathematische Gewähr.

Danach habe ich Bitcoin-Staking mit in die Betrachtung aufgenommen: Es braucht keine Bridge. Bitcoin bleibt auf der Bitcoin-Blockchain, und Slashing/Strafabzüge werden über EOTS und Skripte umgesetzt. Aus Sicht der „Trust-Annäherungen“ ist das tatsächlich am saubersten – es braucht keinen Trust in Custodians, keine Staking-Pools und keine Threshold-Signaturgruppen. Aber ich habe daneben eine Randnotiz ergänzt: Der Nachteil dieses Ansatzes ist, dass das gestakte Bitcoin nicht an eine PoS-Chain übertragen werden kann, um dort eingesetzt zu werden; es kann nur als Sicherheits- bzw. Sicherheitsdepot verwendet werden. Wenn eine PoS-Chain BTC als Ausführungs-layer-Asset nutzen möchte (z. B. für Kredite oder Handel), kann $BABY Bitcoin-Staking nicht direkt diese Liquidität bereitstellen.

Später habe ich in meine Notizen geschrieben: „Bridge-Lösungen handeln alle eine Art ‘Security Tax’ – um BTC in andere Chains zu transferieren, muss man einen Teil der Trust-Annäherungen oder der Kapitaleffizienz opfern. Bitcoin-Staking spart sich diese Steuer, verzichtet dafür aber auf die plattformübergreifende, übertragbare Eigenschaft der Assets.“ Daher ist es nicht die „bessere“ Bridge, sondern ein „völlig anderes“ Asset-Nutzungsmodell. Dieser Unterschied ist entscheidend; das Whitepaper stellt ihn nicht direkt gegenüber, aber ich glaube, das ist der Kern, um die Positionierung von Bitcoin-Equity-/Staking-Assets zu verstehen. Ich habe noch kein Fazit, werde aber weiter beobachten, ob im Bitcoin-Staking-Ökosystem PoS-Chains bereit sind, diese „nicht übertragbaren Sicherheits-Assets“ als Collateral zu akzeptieren.@BabylonLabs_io

Ich blätterte im Whitepaper zu dem Kapitel über die Protokollarchitektur und in meinem Kopf wechselten die ganzen Zeit zwei Fragen: Wie passt das zu Tendermint? Wie passt das zu Casper? Unterschiedliche PoS-Ketten haben unterschiedliche Slashing-Bedingungen und Konsenslogiken. Instinktiv dachte ich: Da muss man doch eine ganze Reihe maßgeschneiderter Middleware schreiben. Pro Kette ein Adapter – wenn man das bedenkt, ist die Komplexität erschreckend.#baby Aber als ich am Ende von Abschnitt 7.2 die Zusammenfassung der Finality-Tools las, blieb ich stehen.$BABY Das Whitepaper ist sehr zurückhaltend formuliert, aber die Bedeutung ist schwer: „Kann in allen BFT-Konsensprotokollen verwendet werden und erfordert keine Änderungen am grundlegenden Konsensprotokoll selbst.“ Ich las es zweimal, bevor mir das Gewicht dieses Satzes wirklich klar wurde. Es geht nicht darum, den Konsens zu verändern, sondern außen herum eine Overlay-Schicht zu legen. Wie eine PoS-Kette Blöcke produziert – wie sie signiert und welche Signaturen sie nutzt – wird komplett nicht angefasst. Man fügt nur in der Phase der Blockfinalisierung eine zusätzliche EOTS-Signier-Runde hinzu. Diese Signierung verändert nicht die Urteile des zugrunde liegenden Konsenses; sie fügt ihm lediglich eine zusätzliche „Bitcoin-ähnliche“ Slashing-Versicherung hinzu. Ich kritzelte mir instinktiv eine Skizze: unten das Konsensprotokoll, in der Mitte eine saubere Schnittstelle, oben das EOTS-Finality-Tool. Nachdem ich gezeichnet hatte, starrte ich noch ein paar Sekunden darauf.@babylonlabs_io Diese Entkopplung ist extrem engineering-stark. Zum Vergleich: Bei EigenLayer, wenn man ein neues AVS anbinden will, muss man Verträge schreiben, Logik ändern und ist stark gebunden. Bei Babylon wird einfach außerhalb der Konsensschicht eine Schicht darübergelegt. Deine Kette läuft weiterhin so, wie sie ohnehin läuft; ich setze nur nach deiner endgültigen Bestätigung eine harte Zusatzbindung. Echte Plug-and-Play-Fähigkeit. Aber ich denke auch: Könnte es bei so einer Overlay-Lösung einen Aktivitäts-Fallstrick geben? Wenn der darunterliegende Konsens den Block bereits bestätigt, aber die EOTS-2/3-Signaturen nicht rechtzeitig eingehen – blockiert das System und wartet, oder läuft es zunächst weiter? Im Whitepaper heißt es: „truly finalized“ setzt beides voraus, aber das Verhalten bei extremen Netzpartitionen habe ich noch nicht vollständig durchdrungen. Ich muss nachsehen, ob sie eine öffentlich zugängliche formale Verifikation haben. Ich halte das erst mal fest; morgen grabe ich weiter.

Ich blätterte im Whitepaper zu dem Kapitel über die Protokollarchitektur und in meinem Kopf wechselten die ganzen Zeit zwei Fragen: Wie passt das zu Tendermint? Wie passt das zu Casper? Unterschiedliche PoS-Ketten haben unterschiedliche Slashing-Bedingungen und Konsenslogiken. Instinktiv dachte ich: Da muss man doch eine ganze Reihe maßgeschneiderter Middleware schreiben. Pro Kette ein Adapter – wenn man das bedenkt, ist die Komplexität erschreckend.#baby

Aber als ich am Ende von Abschnitt 7.2 die Zusammenfassung der Finality-Tools las, blieb ich stehen.$BABY Das Whitepaper ist sehr zurückhaltend formuliert, aber die Bedeutung ist schwer: „Kann in allen BFT-Konsensprotokollen verwendet werden und erfordert keine Änderungen am grundlegenden Konsensprotokoll selbst.“ Ich las es zweimal, bevor mir das Gewicht dieses Satzes wirklich klar wurde.

Es geht nicht darum, den Konsens zu verändern, sondern außen herum eine Overlay-Schicht zu legen. Wie eine PoS-Kette Blöcke produziert – wie sie signiert und welche Signaturen sie nutzt – wird komplett nicht angefasst. Man fügt nur in der Phase der Blockfinalisierung eine zusätzliche EOTS-Signier-Runde hinzu. Diese Signierung verändert nicht die Urteile des zugrunde liegenden Konsenses; sie fügt ihm lediglich eine zusätzliche „Bitcoin-ähnliche“ Slashing-Versicherung hinzu. Ich kritzelte mir instinktiv eine Skizze: unten das Konsensprotokoll, in der Mitte eine saubere Schnittstelle, oben das EOTS-Finality-Tool. Nachdem ich gezeichnet hatte, starrte ich noch ein paar Sekunden darauf.@BabylonLabs_io

Diese Entkopplung ist extrem engineering-stark. Zum Vergleich: Bei EigenLayer, wenn man ein neues AVS anbinden will, muss man Verträge schreiben, Logik ändern und ist stark gebunden. Bei Babylon wird einfach außerhalb der Konsensschicht eine Schicht darübergelegt. Deine Kette läuft weiterhin so, wie sie ohnehin läuft; ich setze nur nach deiner endgültigen Bestätigung eine harte Zusatzbindung. Echte Plug-and-Play-Fähigkeit.

Aber ich denke auch: Könnte es bei so einer Overlay-Lösung einen Aktivitäts-Fallstrick geben? Wenn der darunterliegende Konsens den Block bereits bestätigt, aber die EOTS-2/3-Signaturen nicht rechtzeitig eingehen – blockiert das System und wartet, oder läuft es zunächst weiter? Im Whitepaper heißt es: „truly finalized“ setzt beides voraus, aber das Verhalten bei extremen Netzpartitionen habe ich noch nicht vollständig durchdrungen. Ich muss nachsehen, ob sie eine öffentlich zugängliche formale Verifikation haben. Ich halte das erst mal fest; morgen grabe ich weiter.

Ich dachte eine Zeit lang, dass es bei Bitcoin-Staking mit der Einziehung wohl zwangsläufig ein totes Ende gibt. Bitcoin hat keine Smart Contracts, du kannst nicht wie auf Ethereum eine Codezeile schreiben: „Wenn ein Doppelsignieren erkannt wird, wird das Staking eingezogen.“ Also, jedes Mal wenn jemand das Bitcoin-Staking anspricht, schießt mir automatisch die Frage durch den Kopf: „Wie kriegt man die Einziehung überhaupt hin?“ und ich streiche es still beiseite. Als ich das Whitepaper von Babylon auf Abschnitt 7.2 aufschlug, war ich eigentlich auch mit der Einstellung hingegangen: „Mal schauen, wie du das hinbiegen willst.“ Aber ich habe zwei Absätze gelesen und saß danach wie erstarrt auf meinem Stuhl. #baby Es geht nicht darum, einen Weg zu finden, um dir böses Handeln nachzuweisen, dann Beweise einzureichen und damit das Bitcoin-Netz die Einziehung ausführen zu lassen – diese Route funktioniert nicht, weil Bitcoin keine komplexen Beweise verarbeitet. Es hat stattdessen die Perspektive gewechselt: In dem Moment, in dem du dich bösartig verhältst, wird dein privater Schlüssel direkt öffentlich. Wer auch immer deinen privaten Schlüssel bekommt, kann eine Einziehungs-Transaktion auslösen und deine Coins vernichten. $BABY Das heißt: Kein Richter, keine Abstimmung, und nicht einmal das „Beweisen“ dieses Vorgangs ist nötig. Die Mathematik selbst ist der Richter. Dieses Mechanismus heißt EOTS – Extractable One-Time Signatures, extrahierbare Einmalsignaturen. Die Grundidee ist eigentlich nicht kompliziert: Wenn du mit demselben privaten Schlüssel zwei verschiedene Dinge signierst, kann man den privaten Schlüssel aus den beiden Signaturen berechnen. Babylon legt auf der Konsensschicht eines PoS-Systems noch eine zusätzliche Endgültigkeits-Funktion oben drauf: Nach der finalen Blockbestätigung müssen alle Validatoren zusätzlich einmal mit EOTS signieren. Wenn es zu einem Sicherheitsverstoß kommt (z. B. einen Double-Spend-Angriff), dann müssen notwendigerweise mehr als 1/3 des eingesetzten Kapitals auf derselben Höhe zwei Blöcke signiert haben – und ihre privaten Schlüssel werden dabei aus den Signaturen offengelegt. Instinktiv hatte ich mir im Notizbuch den Satz notiert: „Nicht Einziehung, sondern der Schlüssel explodiert.“ Ich starrte ein paar Sekunden darauf und fand, das Bild passt ziemlich gut. Die klassische PoS-Einziehung ist: „Ich entdecke, dass du gegen die Regeln verstößt → ich reiche Beweise ein → die Chain führt es on-chain aus.“ Babylon hingegen ist: „Du verstößt → dein Schlüssel wird automatisch öffentlich → jeder kann es ausführen.“ Die Phase „entdecken“ und „einreichen“ wird komplett übersprungen. Was ich noch nicht ganz durchdrungen habe: Wenn der Angreifer nur einmal signiert und dann nicht weiter signiert, oder die Wahlbeteiligung zu niedrig ist, kann dieses Mechanismus dann überhaupt noch greifen? Aber zumindest hat mir dieser Gedanke neu erklärt, was es bedeutet, „keinem Dritten vertrauen zu müssen“. @babylonlabs_io

Ich dachte eine Zeit lang, dass es bei Bitcoin-Staking mit der Einziehung wohl zwangsläufig ein totes Ende gibt. Bitcoin hat keine Smart Contracts, du kannst nicht wie auf Ethereum eine Codezeile schreiben: „Wenn ein Doppelsignieren erkannt wird, wird das Staking eingezogen.“ Also, jedes Mal wenn jemand das Bitcoin-Staking anspricht, schießt mir automatisch die Frage durch den Kopf: „Wie kriegt man die Einziehung überhaupt hin?“ und ich streiche es still beiseite. Als ich das Whitepaper von Babylon auf Abschnitt 7.2 aufschlug, war ich eigentlich auch mit der Einstellung hingegangen: „Mal schauen, wie du das hinbiegen willst.“ Aber ich habe zwei Absätze gelesen und saß danach wie erstarrt auf meinem Stuhl. #baby

Es geht nicht darum, einen Weg zu finden, um dir böses Handeln nachzuweisen, dann Beweise einzureichen und damit das Bitcoin-Netz die Einziehung ausführen zu lassen – diese Route funktioniert nicht, weil Bitcoin keine komplexen Beweise verarbeitet. Es hat stattdessen die Perspektive gewechselt: In dem Moment, in dem du dich bösartig verhältst, wird dein privater Schlüssel direkt öffentlich. Wer auch immer deinen privaten Schlüssel bekommt, kann eine Einziehungs-Transaktion auslösen und deine Coins vernichten. $BABY Das heißt: Kein Richter, keine Abstimmung, und nicht einmal das „Beweisen“ dieses Vorgangs ist nötig. Die Mathematik selbst ist der Richter.

Dieses Mechanismus heißt EOTS – Extractable One-Time Signatures, extrahierbare Einmalsignaturen. Die Grundidee ist eigentlich nicht kompliziert: Wenn du mit demselben privaten Schlüssel zwei verschiedene Dinge signierst, kann man den privaten Schlüssel aus den beiden Signaturen berechnen. Babylon legt auf der Konsensschicht eines PoS-Systems noch eine zusätzliche Endgültigkeits-Funktion oben drauf: Nach der finalen Blockbestätigung müssen alle Validatoren zusätzlich einmal mit EOTS signieren. Wenn es zu einem Sicherheitsverstoß kommt (z. B. einen Double-Spend-Angriff), dann müssen notwendigerweise mehr als 1/3 des eingesetzten Kapitals auf derselben Höhe zwei Blöcke signiert haben – und ihre privaten Schlüssel werden dabei aus den Signaturen offengelegt.

Instinktiv hatte ich mir im Notizbuch den Satz notiert: „Nicht Einziehung, sondern der Schlüssel explodiert.“ Ich starrte ein paar Sekunden darauf und fand, das Bild passt ziemlich gut. Die klassische PoS-Einziehung ist: „Ich entdecke, dass du gegen die Regeln verstößt → ich reiche Beweise ein → die Chain führt es on-chain aus.“ Babylon hingegen ist: „Du verstößt → dein Schlüssel wird automatisch öffentlich → jeder kann es ausführen.“ Die Phase „entdecken“ und „einreichen“ wird komplett übersprungen.

Was ich noch nicht ganz durchdrungen habe: Wenn der Angreifer nur einmal signiert und dann nicht weiter signiert, oder die Wahlbeteiligung zu niedrig ist, kann dieses Mechanismus dann überhaupt noch greifen? Aber zumindest hat mir dieser Gedanke neu erklärt, was es bedeutet, „keinem Dritten vertrauen zu müssen“. @BabylonLabs_io

Am Montagabend, nachdem ich den ersten Abschnitt in meinem Arbeitszimmer durchgelesen hatte, nahm ich es zunächst nicht so ernst – PoS-Ketten brauchen Kapital, Bitcoin hat Kapital. Ist das nicht einfach eine passende Relation von Angebot und Nachfrage? Aber als ich den Abschnitt über Akash las, blieb ich stehen. 100% anfängliche jährliche Inflation: Dieses Geld muss sowohl für Sicherheit sorgen als auch Anbieter von KI-Computing-Hardware dazu anreizen. Ich starrte ein paar Sekunden lang, schrieb instinktiv „Inflation muss zwei Rechnungen bezahlen“ auf Papier. Eine Rechnung für Validatoren gegen Angriffe, eine für die Anwendungsschicht, um Angebot heranzuziehen. Zwei Rechnungen übereinander – und bevor die Kette überhaupt anspringt, verbrennt die Inflation das Ganze zuerst weg. Das ist im Grunde kein nachhaltiges Modell. #baby Ich hatte vorher gedacht, dass Bitcoin-Staking lediglich Bitcoin-Haltern zusätzlich einen ertragbringenden Kanal gibt, aber beim Lesen von Abschnitt drei wurde mir klar: Wirklich gerettet wird die PoS-Kette. Das Beispiel von Akash ist kein Einzelfall; im Cosmos-Ökosystem gibt es zuhauf Ketten mit anfänglicher Inflation von 20% bis 100%. Hohe Inflation kauft zwar Sicherheit, aber die Sicherheitskosten drücken die Nutzbarkeit on-chain zu Tode – du könntest die Inflation eigentlich nutzen, um Anwendungen anzureizen, doch am Ende frisst die Sicherheit alles auf. Das ist das „Inflation–Sicherheit“-Dilemma von PoS-Ketten: Das Kapital ist zu teuer – so teuer, dass die Kette selbst kaum Luft bekommt. Dann wird das Bild von Bitcoin klar. Das Whitepaper formuliert es ganz direkt: 600 Milliarden Dollar, $BABY der Großteil liegt brach, ist nicht gebunden, und wird nicht eingesetzt, um sich selbst zu schützen. Das sind ganz andere Spezies als die nativen Assets auf PoS-Ketten. Akash zieht Kapital mit 100% Inflation an, während Bitcoin einfach stillliegt. Babylon macht genau das: Diese beiden Enden verbinden – Bitcoin-Halter staken das ungenutzte Kapital in die PoS-Kette, nehmen die Erträge mit, und gleichzeitig kann die PoS-Kette mit geringeren Kosten Sicherheit erhalten, sodass die Inflation sinkt. Zweiflächiger Markt – keine Scheinnachfrage. Noch nicht ganz durchdrungen habe ich, woher die Erträge der Bitcoin-Staker kommen. Wenn die PoS-Kette ursprünglich die Sicherheit aus hoher Inflation bezahlt hat, zahlt man nun an Bitcoin – kann die Kostenposition wirklich sinken? Oder verlagert man die Inflation am Ende einfach auf Bitcoin-Halter? Ich muss noch etwas tiefer in die ökonomischen Modelle graben. Aber zumindest: Diese Logik der Fehlzuordnung von Angebot und Nachfrage – die habe ich verstanden. @babylonlabs_io

Am Montagabend, nachdem ich den ersten Abschnitt in meinem Arbeitszimmer durchgelesen hatte, nahm ich es zunächst nicht so ernst – PoS-Ketten brauchen Kapital, Bitcoin hat Kapital. Ist das nicht einfach eine passende Relation von Angebot und Nachfrage? Aber als ich den Abschnitt über Akash las, blieb ich stehen. 100% anfängliche jährliche Inflation: Dieses Geld muss sowohl für Sicherheit sorgen als auch Anbieter von KI-Computing-Hardware dazu anreizen. Ich starrte ein paar Sekunden lang, schrieb instinktiv „Inflation muss zwei Rechnungen bezahlen“ auf Papier. Eine Rechnung für Validatoren gegen Angriffe, eine für die Anwendungsschicht, um Angebot heranzuziehen. Zwei Rechnungen übereinander – und bevor die Kette überhaupt anspringt, verbrennt die Inflation das Ganze zuerst weg. Das ist im Grunde kein nachhaltiges Modell. #baby

Ich hatte vorher gedacht, dass Bitcoin-Staking lediglich Bitcoin-Haltern zusätzlich einen ertragbringenden Kanal gibt, aber beim Lesen von Abschnitt drei wurde mir klar: Wirklich gerettet wird die PoS-Kette. Das Beispiel von Akash ist kein Einzelfall; im Cosmos-Ökosystem gibt es zuhauf Ketten mit anfänglicher Inflation von 20% bis 100%. Hohe Inflation kauft zwar Sicherheit, aber die Sicherheitskosten drücken die Nutzbarkeit on-chain zu Tode – du könntest die Inflation eigentlich nutzen, um Anwendungen anzureizen, doch am Ende frisst die Sicherheit alles auf. Das ist das „Inflation–Sicherheit“-Dilemma von PoS-Ketten: Das Kapital ist zu teuer – so teuer, dass die Kette selbst kaum Luft bekommt.

Dann wird das Bild von Bitcoin klar. Das Whitepaper formuliert es ganz direkt: 600 Milliarden Dollar, $BABY der Großteil liegt brach, ist nicht gebunden, und wird nicht eingesetzt, um sich selbst zu schützen. Das sind ganz andere Spezies als die nativen Assets auf PoS-Ketten. Akash zieht Kapital mit 100% Inflation an, während Bitcoin einfach stillliegt. Babylon macht genau das: Diese beiden Enden verbinden – Bitcoin-Halter staken das ungenutzte Kapital in die PoS-Kette, nehmen die Erträge mit, und gleichzeitig kann die PoS-Kette mit geringeren Kosten Sicherheit erhalten, sodass die Inflation sinkt. Zweiflächiger Markt – keine Scheinnachfrage.

Noch nicht ganz durchdrungen habe ich, woher die Erträge der Bitcoin-Staker kommen. Wenn die PoS-Kette ursprünglich die Sicherheit aus hoher Inflation bezahlt hat, zahlt man nun an Bitcoin – kann die Kostenposition wirklich sinken? Oder verlagert man die Inflation am Ende einfach auf Bitcoin-Halter? Ich muss noch etwas tiefer in die ökonomischen Modelle graben. Aber zumindest: Diese Logik der Fehlzuordnung von Angebot und Nachfrage – die habe ich verstanden. @BabylonLabs_io

Am Mittwochmittag saß ich in einem Café und überarbeitete ein altes Manuskript, als ich nebenbei die chinesische Kurzfassung des Babylon-Whitepapers öffnete. Beim ersten Blick auf „Bitcoin-Staking“ ergänzte mein Kopf automatisch das Wort „Bridging“ – sind nicht alle Bitcoin-Zinsmodelle auf dem Markt $BABY im Grunde erst einmal so aufgebaut, dass die Coins über eine Brücke auf eine andere Kette gebracht und dann gestakt werden? wBTC, Multisig-Brücken, sogar manche Sidechains: Im Kern wird Bitcoin auf eine andere Chain verschoben, und die Sicherheit hängt dann von einem Verwahrer oder einem Komitee ab. Nach ein paar Seiten dachte ich, ich würde wieder ein altbekanntes Brückenmodell lesen. Aber bei „5 Herausforderungen“ blieb ich hängen. Ich merkte nicht einmal, dass mein Kaffee kalt geworden war. Das Whitepaper verwarf die Bridging-Methode direkt. #baby Es sagt, dass alle Bridging-Lösungen auf Vertrauen in Dritte beruhen – selbst die idealste Bitcoin-Brücke hängt davon ab, dass die Staker der Zielkette ehrlich sind. Daher kann Bridging kein „vertrauensloses Staking“ ermöglichen: Entweder vertraust du dem Verwahrer oder dem Multisig. Genau deshalb ist Eigenschaft 2 auf diesem Weg nie erreichbar. Wie reflexhaft schrieb ich in mein Notizbuch „Bridging ist kein Weg“ und starrte ein paar Sekunden darauf. Dann wurde eine andere Richtung vorgestellt: Remote Staking. Bitcoin verlässt die Hauptkette nicht, sondern bleibt in einer selbstverwahrten Vault auf der Bitcoin-Chain eingeschlossen, während auf der Bitcoin-Chain mittels kryptografischer Mechanismen Slashing durchgesetzt wird. Erst nach ein paar Sekunden begriff ich: Das ist überhaupt keine Brücke, sondern die Nutzung von Bitcoin als Sicherheitsquelle, die remote auf die PoS-Chain projiziert wird. Bridging bedeutet, den Vermögenswert hinüberzuschieben; hier bleibt der Anker an Ort und Stelle, während sich die Sicherheitsbedingungen ausdehnen. Dieser Denkwechsel ist extrem wichtig. Wenn man Babylon weiterhin mit einer „Brücken“-Logik versteht, liegt man komplett falsch. Es bridged nicht – nicht, weil es es nicht könnte, sondern weil Bridging selbst im Widerspruch zu „vertrauenslos“ steht. Deshalb wählt es einen anderen, schwierigeren, aber reineren Weg: keine Coins verschieben, nur Sicherheit übertragen. Ich habe noch nicht ganz durchschaut, ob dieser Weg versteckte Schwachstellen hat, aber zumindest hat er mir ein neues Verständnis davon gegeben, was „Staking“ eigentlich bedeutet. @babylonlabs_io

Am Mittwochmittag saß ich in einem Café und überarbeitete ein altes Manuskript, als ich nebenbei die chinesische Kurzfassung des Babylon-Whitepapers öffnete. Beim ersten Blick auf „Bitcoin-Staking“ ergänzte mein Kopf automatisch das Wort „Bridging“ – sind nicht alle Bitcoin-Zinsmodelle auf dem Markt $BABY im Grunde erst einmal so aufgebaut, dass die Coins über eine Brücke auf eine andere Kette gebracht und dann gestakt werden? wBTC, Multisig-Brücken, sogar manche Sidechains: Im Kern wird Bitcoin auf eine andere Chain verschoben, und die Sicherheit hängt dann von einem Verwahrer oder einem Komitee ab. Nach ein paar Seiten dachte ich, ich würde wieder ein altbekanntes Brückenmodell lesen.

Aber bei „5 Herausforderungen“ blieb ich hängen. Ich merkte nicht einmal, dass mein Kaffee kalt geworden war.

Das Whitepaper verwarf die Bridging-Methode direkt. #baby Es sagt, dass alle Bridging-Lösungen auf Vertrauen in Dritte beruhen – selbst die idealste Bitcoin-Brücke hängt davon ab, dass die Staker der Zielkette ehrlich sind. Daher kann Bridging kein „vertrauensloses Staking“ ermöglichen: Entweder vertraust du dem Verwahrer oder dem Multisig. Genau deshalb ist Eigenschaft 2 auf diesem Weg nie erreichbar. Wie reflexhaft schrieb ich in mein Notizbuch „Bridging ist kein Weg“ und starrte ein paar Sekunden darauf.

Dann wurde eine andere Richtung vorgestellt: Remote Staking. Bitcoin verlässt die Hauptkette nicht, sondern bleibt in einer selbstverwahrten Vault auf der Bitcoin-Chain eingeschlossen, während auf der Bitcoin-Chain mittels kryptografischer Mechanismen Slashing durchgesetzt wird. Erst nach ein paar Sekunden begriff ich: Das ist überhaupt keine Brücke, sondern die Nutzung von Bitcoin als Sicherheitsquelle, die remote auf die PoS-Chain projiziert wird. Bridging bedeutet, den Vermögenswert hinüberzuschieben; hier bleibt der Anker an Ort und Stelle, während sich die Sicherheitsbedingungen ausdehnen.

Dieser Denkwechsel ist extrem wichtig. Wenn man Babylon weiterhin mit einer „Brücken“-Logik versteht, liegt man komplett falsch. Es bridged nicht – nicht, weil es es nicht könnte, sondern weil Bridging selbst im Widerspruch zu „vertrauenslos“ steht. Deshalb wählt es einen anderen, schwierigeren, aber reineren Weg: keine Coins verschieben, nur Sicherheit übertragen.
Ich habe noch nicht ganz durchschaut, ob dieser Weg versteckte Schwachstellen hat, aber zumindest hat er mir ein neues Verständnis davon gegeben, was „Staking“ eigentlich bedeutet.
@BabylonLabs_io

Ich habe gestern die ein paar Abschnitte aus dem Whitepaper zu „automatischem Slashing“ im Vergleich zu Casper/Tendermint wieder hervorgeholt. Damals wirkte der Vergleich zwischen „automatisch“ und „Community-Konsens“ sehr klar: Einmal wird es automatisch ausgeführt, einmal braucht es eine komplexe Koordination—und damit war sofort klar, wer gewinnt. Aber diesmal habe ich genauer auf das Wort „automatisch“ geschaut, und je länger ich es ansehe, desto mehr habe ich den Eindruck, dass dahinter eine Bedingung steckt, die ich noch nicht vollständig durchdrungen habe. Ich habe den Ausführungsweg für das Slashing noch einmal neu gezeichnet. Im Whitepaper, Abschnitt 9.2, steht: Bei Etherereums PoS ist für Slashing bei Sicherheitsverstößen ein Community-Konsens erforderlich, weil mehr als 1/3 böswilliger Validatoren die Slashing-Belege auf der Kette prüfen können. Dadurch muss ein Off-Chain-Koordinationsprozess durchlaufen werden, um die Chain neu zu starten. Beim Bitcoin-Staking liegt das eingesetzte Kapital hingegen auf der Bitcoin-Kette (aufgrund von $BABY ), sodass bei einem Verstoß „sofort ein automatisches Slashing“ erfolgt. Die eigentliche Frage ist jedoch: Wer ist dafür verantwortlich, die Slashing-Transaktion in die Bitcoin-Kette einzureichen? Wenn ein(e) Monitor/Überwacher eine einzelne Einheit oder eine begrenzte Menge an Akteuren ist—was passiert dann, wenn sie/er angegriffen wird oder offline geht? Und wenn das Bitcoin-Netzwerk gerade ausgelastet ist und die Slashing-Transaktion für ein paar Stunden im mempool hängt: Gilt dieses „automatisch“ dann immer noch? Später habe ich in meinen Notizen formuliert: Das „automatische Slashing“ beim Bitcoin-Staking verlagert im Kern den Engpass der Lebendigkeit von „Koordination auf der gleichen Kette über den PoS-Chain-Konsens“ hin zu „Kombination aus Cross-Chain-Ausführungsverzögerung + Zuverlässigkeit des/der Überwachers + Reaktionsfähigkeit des Bitcoin-Netzwerks“. Der Community-Konsens in Ethereum (#baby ) ist zwar langsam und schmerzhaft, aber er ist protokollimmanent—selbst wenn mehr als 1/3 der Validatoren Schaden anrichten, gibt es für die Community immer einen Weg zu einer endgültigen Entscheidung. Beim Bitcoin-Staking ist es zwar schnell, aber sein „automatisch“ braucht externe Rahmenbedingungen: Der/die Überwacher muss online und ehrlich sein, das Bitcoin-Netzwerk darf nicht überlastet sein, und die Slashing-Transaktion muss rechtzeitig bestätigt werden. Natürlich heißt das keineswegs, dass die Ethereum-Lösung besser ist. Ein Community-Konsens entspricht in extremen Fällen fast einem Kettenstillstand, während die Cross-Chain-Verzögerung bei Bitcoin in den meisten Fällen akzeptabel ist. Aber die Zweiteilung „automatisch“ vs. „manuell“ vereinfacht das Ganze tatsächlich zu stark. Genauer wäre vielleicht: „wirksam unter den Bedingungen eines funktionierenden Cross-Chain-Automatik-Trigger-Mechanismus in Kombination mit einem funktionierenden Überwacher und einer funktionsfähigen Bitcoin-Netzwerkfunktion“. Diese Bedingung ist nicht zwingend tödlich, aber als Forscher halte ich es für notwendig, diese Grenze klar zu benennen. @babylonlabs_io

Ich habe gestern die ein paar Abschnitte aus dem Whitepaper zu „automatischem Slashing“ im Vergleich zu Casper/Tendermint wieder hervorgeholt. Damals wirkte der Vergleich zwischen „automatisch“ und „Community-Konsens“ sehr klar: Einmal wird es automatisch ausgeführt, einmal braucht es eine komplexe Koordination—und damit war sofort klar, wer gewinnt. Aber diesmal habe ich genauer auf das Wort „automatisch“ geschaut, und je länger ich es ansehe, desto mehr habe ich den Eindruck, dass dahinter eine Bedingung steckt, die ich noch nicht vollständig durchdrungen habe.

Ich habe den Ausführungsweg für das Slashing noch einmal neu gezeichnet. Im Whitepaper, Abschnitt 9.2, steht: Bei Etherereums PoS ist für Slashing bei Sicherheitsverstößen ein Community-Konsens erforderlich, weil mehr als 1/3 böswilliger Validatoren die Slashing-Belege auf der Kette prüfen können. Dadurch muss ein Off-Chain-Koordinationsprozess durchlaufen werden, um die Chain neu zu starten. Beim Bitcoin-Staking liegt das eingesetzte Kapital hingegen auf der Bitcoin-Kette (aufgrund von $BABY ), sodass bei einem Verstoß „sofort ein automatisches Slashing“ erfolgt. Die eigentliche Frage ist jedoch: Wer ist dafür verantwortlich, die Slashing-Transaktion in die Bitcoin-Kette einzureichen? Wenn ein(e) Monitor/Überwacher eine einzelne Einheit oder eine begrenzte Menge an Akteuren ist—was passiert dann, wenn sie/er angegriffen wird oder offline geht? Und wenn das Bitcoin-Netzwerk gerade ausgelastet ist und die Slashing-Transaktion für ein paar Stunden im mempool hängt: Gilt dieses „automatisch“ dann immer noch?

Später habe ich in meinen Notizen formuliert: Das „automatische Slashing“ beim Bitcoin-Staking verlagert im Kern den Engpass der Lebendigkeit von „Koordination auf der gleichen Kette über den PoS-Chain-Konsens“ hin zu „Kombination aus Cross-Chain-Ausführungsverzögerung + Zuverlässigkeit des/der Überwachers + Reaktionsfähigkeit des Bitcoin-Netzwerks“. Der Community-Konsens in Ethereum (#baby ) ist zwar langsam und schmerzhaft, aber er ist protokollimmanent—selbst wenn mehr als 1/3 der Validatoren Schaden anrichten, gibt es für die Community immer einen Weg zu einer endgültigen Entscheidung. Beim Bitcoin-Staking ist es zwar schnell, aber sein „automatisch“ braucht externe Rahmenbedingungen: Der/die Überwacher muss online und ehrlich sein, das Bitcoin-Netzwerk darf nicht überlastet sein, und die Slashing-Transaktion muss rechtzeitig bestätigt werden.

Natürlich heißt das keineswegs, dass die Ethereum-Lösung besser ist. Ein Community-Konsens entspricht in extremen Fällen fast einem Kettenstillstand, während die Cross-Chain-Verzögerung bei Bitcoin in den meisten Fällen akzeptabel ist. Aber die Zweiteilung „automatisch“ vs. „manuell“ vereinfacht das Ganze tatsächlich zu stark. Genauer wäre vielleicht: „wirksam unter den Bedingungen eines funktionierenden Cross-Chain-Automatik-Trigger-Mechanismus in Kombination mit einem funktionierenden Überwacher und einer funktionsfähigen Bitcoin-Netzwerkfunktion“. Diese Bedingung ist nicht zwingend tödlich, aber als Forscher halte ich es für notwendig, diese Grenze klar zu benennen. @BabylonLabs_io

Am Freitagabend habe ich das Whitepaper wieder hervorgeholt und den Abschnitt zur Systemarchitektur durchgearbeitet. Zuerst fand ich Babylons Chain als Design für die Kontroll-Ebene sehr klar: Die Drei-Schichten-Architektur (Bitcoin-Babylon-PoS-Chain) sieht richtig gut aus. Aber diesmal bin ich dem Vertrauenspfad nach unten gefolgt und habe plötzlich ein Problem entdeckt: Wessen Aufgabe ist die Sicherheit der Babylon-Chain?#baby Laut Whitepaper basiert Babylon Chain auf dem Cosmos SDK und gewährleistet die Sicherheit durch Staking mit ATOM (oder dem eigenen Token)$BABY . Der Kernversprechen von Bitcoin-Staking-Rechten lautet jedoch „keine vertrauenswürdige Drittpartei“. Jetzt wird aber die gesamte Synchronisation des Protokolls, die Registrierung der Rechte und selbst die Aufzeichnungen über Slashing an eine PoS-Kette delegiert. Wenn die Staking-Quote der Babylon-Chain nicht ausreicht oder der Validatorenverbund von Angreifern durchdrungen wird, kann der Angreifer weit mehr tun als nur Double-Signing: Er könnte Zeitstempel manipulieren, finale Signaturen fälschen und sogar verhindern, dass Slashing-Transaktionen on-chain gehen. Das bringt mich auf ein rekursives Vertrauensproblem: Verkommt das Vertrauensmodell von Bitcoin-Staking-Rechten am Ende zu einem Vertrauen in die Staking-Ökonomie der Babylon-Chain (oder von ATOM)? Ich habe einen rekursiven Vertrauenskreis gezeichnet: Proof-of-Work von Bitcoin → Nachweis/Proof der Rechte der Babylon-Chain → Vertrauen der Bitcoin-Staker. Die Schwachstelle dieses Kreises liegt nicht wirklich bei Bitcoin, sondern bei der Babylon-Chain. Das Whitepaper räumt ein, dass die Kontroll-Ebene dezentralisiert und Zensurresistenz braucht, aber es quantifiziert nicht, „auf welches Sicherheitsniveau das Modell zurückfällt, falls die Babylon-Chain angegriffen wird“. In meinen Notizen habe ich einen Satz geschrieben: „Der Vertrauensanker der Bitcoin-Staking-Rechte landet letztlich auf einer PoS-Kette.“ Das heißt nicht, dass der Vorschlag nicht umsetzbar ist – aber es heißt, dass die Formulierung „ohne Vertrauen“ neu kalibriert werden muss: nicht im absoluten Sinne „ohne Vertrauen“, sondern dass das Vertrauen vom Treuhand-/Bridge-Verwalter auf das Validatoren-Sozialkontrakt der Babylon-Chain übergeht. Ist dieser Transfer besser? Vielleicht, aber es ist auf keinen Fall so, dass Vertrauen auf Null fällt. Ich habe vorerst keine Antwort, aber ich werde weiterhin die Validatorenverteilung und die Staking-Quote der Babylon-Chain im Blick behalten.@babylonlabs_io

Am Freitagabend habe ich das Whitepaper wieder hervorgeholt und den Abschnitt zur Systemarchitektur durchgearbeitet. Zuerst fand ich Babylons Chain als Design für die Kontroll-Ebene sehr klar: Die Drei-Schichten-Architektur (Bitcoin-Babylon-PoS-Chain) sieht richtig gut aus. Aber diesmal bin ich dem Vertrauenspfad nach unten gefolgt und habe plötzlich ein Problem entdeckt: Wessen Aufgabe ist die Sicherheit der Babylon-Chain?#baby

Laut Whitepaper basiert Babylon Chain auf dem Cosmos SDK und gewährleistet die Sicherheit durch Staking mit ATOM (oder dem eigenen Token)$BABY . Der Kernversprechen von Bitcoin-Staking-Rechten lautet jedoch „keine vertrauenswürdige Drittpartei“. Jetzt wird aber die gesamte Synchronisation des Protokolls, die Registrierung der Rechte und selbst die Aufzeichnungen über Slashing an eine PoS-Kette delegiert. Wenn die Staking-Quote der Babylon-Chain nicht ausreicht oder der Validatorenverbund von Angreifern durchdrungen wird, kann der Angreifer weit mehr tun als nur Double-Signing: Er könnte Zeitstempel manipulieren, finale Signaturen fälschen und sogar verhindern, dass Slashing-Transaktionen on-chain gehen. Das bringt mich auf ein rekursives Vertrauensproblem: Verkommt das Vertrauensmodell von Bitcoin-Staking-Rechten am Ende zu einem Vertrauen in die Staking-Ökonomie der Babylon-Chain (oder von ATOM)?

Ich habe einen rekursiven Vertrauenskreis gezeichnet: Proof-of-Work von Bitcoin → Nachweis/Proof der Rechte der Babylon-Chain → Vertrauen der Bitcoin-Staker. Die Schwachstelle dieses Kreises liegt nicht wirklich bei Bitcoin, sondern bei der Babylon-Chain. Das Whitepaper räumt ein, dass die Kontroll-Ebene dezentralisiert und Zensurresistenz braucht, aber es quantifiziert nicht, „auf welches Sicherheitsniveau das Modell zurückfällt, falls die Babylon-Chain angegriffen wird“.

In meinen Notizen habe ich einen Satz geschrieben: „Der Vertrauensanker der Bitcoin-Staking-Rechte landet letztlich auf einer PoS-Kette.“ Das heißt nicht, dass der Vorschlag nicht umsetzbar ist – aber es heißt, dass die Formulierung „ohne Vertrauen“ neu kalibriert werden muss: nicht im absoluten Sinne „ohne Vertrauen“, sondern dass das Vertrauen vom Treuhand-/Bridge-Verwalter auf das Validatoren-Sozialkontrakt der Babylon-Chain übergeht. Ist dieser Transfer besser? Vielleicht, aber es ist auf keinen Fall so, dass Vertrauen auf Null fällt. Ich habe vorerst keine Antwort, aber ich werde weiterhin die Validatorenverteilung und die Staking-Quote der Babylon-Chain im Blick behalten.@BabylonLabs_io

ATOM-2,81%

Ich habe gestern wieder den Abschnitt im Weißbuch über schnelles Unbinden herausgezogen. Damals fand ich die Kombination aus „Unbinden in 3 Tagen + Bitcoin-Zeitstempel“ ziemlich stimmig, aber diesmal habe ich die Zeitparameter extra auf Papier gezeichnet – und beim Draufschauen hat mir nach und nach ein ungutes Gefühl beschlichen. Ich habe eine Zeitleiste skizziert: Nehmen wir an, der Angreifer löst auf der Bitcoin-Chain eine Unbind-Transaktion aus. $BABY Bitcoins haben im Durchschnitt ein Blockintervall von 10 Minuten. Unter Berücksichtigung der Bestätigungen muss man auf das erste Block-Confirmation warten (10 Minuten), um eine anfängliche On-Chain-Verifikation anzunehmen. Aber zu diesem Zeitpunkt kann die PoS-Chain bereits 600 Blöcke gelaufen sein (wenn ein Block pro Sekunde erzeugt wird). Der Angreifer kann diese 10-Minuten-Windows komplett nutzen, um mithilfe der noch nicht entfernten alten Validatorenmenge auf der PoS-Chain schnell zu forken – denn obwohl die Unbind-Transaktion auf die Bitcoin-Chain gelangt, hängt die Aktualisierung der PoS-Validatorenmenge von Bitcoin-Zeitstempeln ab, um synchronisiert zu werden, und dieser Zeitstempel hat selbst eine Verzögerung. Im Weißbuch steht „muss eng synchronisiert werden“, aber wie eng ist „eng“ genug, um sicher zu sein? Sind es 10 Minuten, 30 Minuten oder muss es innerhalb eines PoS-Blocks passieren? Es wird keine konkreten Grenzen angegeben.@babylonlabs_io Später habe ich in meinen Notizen einen Satz festgehalten: Der Gewinn des Angreifers ist nicht die Zeitdifferenz nach dem Unbinden, sondern der Zeitraum, in dem die Unbind-Transaktion von der Bitcoin-Chain als Zeitstempel bestätigt wird, bevor dieser Zeitstempel von der PoS-Chain übernommen wird – diese „Grauzone“. Wenn dieser Zeitraum lang genug ist, kann die Stimmkraft der alten Validatorenmenge möglicherweise dazu verwendet werden, einen bereits bestätigten Fork zu konstruieren. Und selbst wenn der Bitcoin-Zeitstempel später aufgezeichnet wird, kann er möglicherweise einen bereits erfolgten Sicherheitsverstoß nicht mehr rückgängig machen. Das Weißbuch erkennt dieses Problem an, aber der Satz „diese Technologie wird neu verortet“ lässt mich vermuten, dass diese Sicherheitsgrenze möglicherweise noch erforscht wird.#baby Als Nächstes habe ich wieder [35] nachgeschlagen. Dort geht es um native PoS-Chains, die mit Bitcoin-Zeitstempeln schnelles Unbinden ermöglichen. Aber wenn man das auf das Szenario des Bitcoin-Stake-Contents anwendet, sind die Parameterannahmen komplett unterschiedlich. Ich habe vorerst keine Antwort darauf, aber wie genau man dieses Zeitdifferenz-Window berechnet, werde ich weiter im Blick behalten.

Ich habe gestern wieder den Abschnitt im Weißbuch über schnelles Unbinden herausgezogen. Damals fand ich die Kombination aus „Unbinden in 3 Tagen + Bitcoin-Zeitstempel“ ziemlich stimmig, aber diesmal habe ich die Zeitparameter extra auf Papier gezeichnet – und beim Draufschauen hat mir nach und nach ein ungutes Gefühl beschlichen.

Ich habe eine Zeitleiste skizziert: Nehmen wir an, der Angreifer löst auf der Bitcoin-Chain eine Unbind-Transaktion aus. $BABY Bitcoins haben im Durchschnitt ein Blockintervall von 10 Minuten. Unter Berücksichtigung der Bestätigungen muss man auf das erste Block-Confirmation warten (10 Minuten), um eine anfängliche On-Chain-Verifikation anzunehmen. Aber zu diesem Zeitpunkt kann die PoS-Chain bereits 600 Blöcke gelaufen sein (wenn ein Block pro Sekunde erzeugt wird). Der Angreifer kann diese 10-Minuten-Windows komplett nutzen, um mithilfe der noch nicht entfernten alten Validatorenmenge auf der PoS-Chain schnell zu forken – denn obwohl die Unbind-Transaktion auf die Bitcoin-Chain gelangt, hängt die Aktualisierung der PoS-Validatorenmenge von Bitcoin-Zeitstempeln ab, um synchronisiert zu werden, und dieser Zeitstempel hat selbst eine Verzögerung. Im Weißbuch steht „muss eng synchronisiert werden“, aber wie eng ist „eng“ genug, um sicher zu sein? Sind es 10 Minuten, 30 Minuten oder muss es innerhalb eines PoS-Blocks passieren? Es wird keine konkreten Grenzen angegeben.@BabylonLabs_io

Später habe ich in meinen Notizen einen Satz festgehalten: Der Gewinn des Angreifers ist nicht die Zeitdifferenz nach dem Unbinden, sondern der Zeitraum, in dem die Unbind-Transaktion von der Bitcoin-Chain als Zeitstempel bestätigt wird, bevor dieser Zeitstempel von der PoS-Chain übernommen wird – diese „Grauzone“. Wenn dieser Zeitraum lang genug ist, kann die Stimmkraft der alten Validatorenmenge möglicherweise dazu verwendet werden, einen bereits bestätigten Fork zu konstruieren. Und selbst wenn der Bitcoin-Zeitstempel später aufgezeichnet wird, kann er möglicherweise einen bereits erfolgten Sicherheitsverstoß nicht mehr rückgängig machen. Das Weißbuch erkennt dieses Problem an, aber der Satz „diese Technologie wird neu verortet“ lässt mich vermuten, dass diese Sicherheitsgrenze möglicherweise noch erforscht wird.#baby

Als Nächstes habe ich wieder [35] nachgeschlagen. Dort geht es um native PoS-Chains, die mit Bitcoin-Zeitstempeln schnelles Unbinden ermöglichen. Aber wenn man das auf das Szenario des Bitcoin-Stake-Contents anwendet, sind die Parameterannahmen komplett unterschiedlich. Ich habe vorerst keine Antwort darauf, aber wie genau man dieses Zeitdifferenz-Window berechnet, werde ich weiter im Blick behalten.

#baby $BABY 刚把巴比伦白皮书的“远程质押”部分又拉了回来，之前第一遍读的时候觉得“无需信任”这个点很漂亮，比特币留在原链上，桥接那套托管人风险直接绕过去了。但这次我翻了翻EOTS罚减的执行路径，心里突然有点不踏实。

我重新画了一下攻击场景：假设一个验证者双签了，那罚减交易需要由谁来广播到比特币链？白皮书没有明说，但逻辑上一定要有一个“监控者”角色，可能是巴比伦链自身，也可能是第三方全节点。如果这个监控者离线了，或者被审查了，或者说这个监控者本身就是恶意的，它选择不广播罚减交易，那这个验证者的违规行为是不是就滑过去了？那“无需信任”究竟还成不成立？

我后来在笔记里写了一句：远程质押把信任从桥托管人转移到了“监控者+比特币网络时效性”这个组合上。桥接方案要信任锁仓方，远程质押要信任有人会及时按正确路径广播交易。这两种信任的差异其实不是质的飞跃，而是成本的转移。监控者是否构成了一个全新的信任锚点？白皮书没有展开讨论监控者的去中心化假设，也没有量化监控者作恶或失联下的安全退化边界。

想到这里我又翻了翻EOTS密钥的假设，如果验证者密钥泄露了，攻击者可以伪造违规吗？罚减交易需要验证者签名，但如果密钥泄露了，攻击者可能主动制造违规并立即广播罚减，那监控者反而成了被动工具。这个路径越想越复杂，好像“无需信任”只是对桥接问题的相对改进，但绝对意义上的信任归零，恐怕还差得远。我暂时没有确定的结论，这个点我会继续拆。

凌晨一点，我在Newton白皮书里发现一个没人提的缺口

昨晚咖啡喝多了，翻来覆去睡不着，又拿起手机刷Newton白皮书。第六章NIO部分写得很顺——加密、选择性披露、TEE验证、凭证跨链携带——一套漂亮的技术闭环。我划过去，准备睡了。

但“Issuers are entities that attest to user attributes”这句话里的entity突然卡在脑子里，再也睡不着。

翻了个身，我把第六章从到尾又看了一遍。它讲了怎么验凭证、怎么保护隐私、怎么防重放。唯独一个问题一个字没提：谁来验发凭证的那个人？

系统假设Issuer天然可信——但攻击者伪造一个叫“合规KYC机构”的Issuer，给一批假钱包签发“accredited investor”凭证，然后用这些凭证去操作合规资金池，结果会怎样？TEE验的是证书签名，不是Issuer的合法身份。如果说整个授权网络是座金库，保险柜防弹、密码量子级、流程全自动——唯独配钥匙的人没人审查。

我不是在唱反调。Newton完全可以在主网Beta里补上Issuer注册白名单或信誉机制，团队大概率已经想到了。但白皮书选择把这个问题当作“已知前提”跳过，让我觉得早期阶段的用户有必要自己多问一句：都说凭证可验证，签发凭证的人，谁来验证？

我现在对Newton的跟踪又多了一个指标：不仅是看它的授权层能否跑通，更要看它如何回答这个“信任的最后一公里”。这个答案，将决定它到底是真去信任，还是只是把信任往前挪了一步。
#newt $NEWT @NewtonProtocol

NEWT+4,59%

Nachvollziehbar, aber wem wird vertraut? Das Vertrauensdilemma des TaskManagers von Newton Protocol

Vorgestern Abend habe ich das Vertrags-Integrationsbeispiel aus der Newton-Protocol-Vertragsbibliothek von Anfang bis Ende durchgelesen, genau dieses USDC-Überweisungsszenario aus dem Whitepaper 7.6. Die ersten Male habe ich vor allem nur zugeschaut: Wallet holt eine Attestation, der Vertrag prüft sie, und schon ist eine regelkonforme Überweisung erledigt. Aber an jenem Tag habe ich besonders auf eine Zeile geachtet: „Smart contract validates the attestation against the TaskManager“. Dann habe ich mit einem Marker diesen Satz durchgestrichen und daneben eine Frage notiert: Was ist dieser TaskManager?
Ich starrte auf die Seite und geriet in eine Art diffuse Unbehaglichkeit. Ehrlich gesagt, konnte ich damals auch nicht klar benennen, was genau daran nicht stimmt. Es war wie der Eindruck, in eine nobel renovierte Bank zu gehen: Die Tresortür ist aus Titanlegierung, die Kameras sind 4K – aber ich merke, dass der zentrale Hauptschalter des gesamten Sicherheitssystems direkt unter dem Empfangstresen im Foyer ist, sodass im Grunde jeder einfach dagegen treten kann.

USDC+0,00%

NEWT+4,59%