Chatter Babylon-Knoten: Viele glauben, dass man für Vigilante (Sentry) unbedingt einen Bitcoin-Full-Node braucht, sonst läuft das Spiel nicht richtig. Am Anfang dachte ich auch so. Später habe ich dann die offizielle Doku gelesen und festgestellt: Die Sentry-Schicht kann tatsächlich im Light-Client-Modus laufen—spart zwar Festplattenspeicher, aber die Verifizierungsfähigkeit ist eingeschränkt.
Das Babylon-BTC-Light-Client-Modul speichert keine kompletten Blöcke, sondern synchronisiert nur die Chain der Block-Header. Der Light Client prüft per SPV (Simplified Payment Verification) Merkle-Zweige und kann bestätigen, ob die aktuelle Mainnet-Höhe stimmt und ob die Header-Chain fortlaufend ist. Der Sentry erledigt zwei Aufgaben: Er überwacht, ob der Finality Provider einen Block mit Doppelsignatur-Konflikt veröffentlicht. Wenn jemand Schurkenhandlungen entdeckt, wird das EOTS—zwei Signaturen—zusammengesetzt, der private Schlüssel berechnet, und dann wird die Straf-Transaktion gesendet. Das Berechnen des privaten Schlüssels ist reine Kryptografie-Arbeit und hängt nicht vom Verlauf eines Full Nodes ab—das kann auch mit einem Light Client. Aber er kann nicht allein unabhängig verifizieren, ob „ein bestimmtes UTXO wirklich in das Babylon-Skript gesperrt wurde“; das braucht einen Full Node oder einen Indexer. Der Light Client vertraut nur auf die Header-Chain.
In den Installationsanleitungen in der offiziellen Doku für Vigilante steht, man müsse „einen synchronisierten Bitcoin Full Node“ einsetzen. In der Praxis konnte man aber mit dem Bitcoin Core Light-Mode (prune=1), also mit abgespecktem Verlauf, den Sentry-Job über Tests laufen lassen. Nachdem 0,05 Testnet-BTC ins System gesperrt wurden, meldete der Sentry einmal FP skip Signatur—es kam aber zu keinem Leck.
Wenn im Mainnet eine tiefe Reorganisation auftritt (>>6 Blöcke), kann der Light Client die Position des Zeitstempels vorübergehend falsch einschätzen, während ein Full Node das zuerst bemerkt. Beim Light Client spart man Speicher (ca. 80 MB/Jahr), als Nachteil kann die Header-Quelle bei Verschmutzung die Kette „mitziehen“. Für den privaten Betrieb des Sentry reicht ein Light Client aus, sofern man der ausgewählten Header-Quelle vertraut. Wer es paranoid betreibt, lässt zusätzlich einen Full Node mit Indexer laufen und verifiziert alles selbst.
Beides ist keine Entweder-oder-Frage, sondern eine Abwägung zwischen Kosten und dem Grad an Selbsthosting.
#baby $BABY @BabylonLabs_io
Das Babylon-BTC-Light-Client-Modul speichert keine kompletten Blöcke, sondern synchronisiert nur die Chain der Block-Header. Der Light Client prüft per SPV (Simplified Payment Verification) Merkle-Zweige und kann bestätigen, ob die aktuelle Mainnet-Höhe stimmt und ob die Header-Chain fortlaufend ist. Der Sentry erledigt zwei Aufgaben: Er überwacht, ob der Finality Provider einen Block mit Doppelsignatur-Konflikt veröffentlicht. Wenn jemand Schurkenhandlungen entdeckt, wird das EOTS—zwei Signaturen—zusammengesetzt, der private Schlüssel berechnet, und dann wird die Straf-Transaktion gesendet. Das Berechnen des privaten Schlüssels ist reine Kryptografie-Arbeit und hängt nicht vom Verlauf eines Full Nodes ab—das kann auch mit einem Light Client. Aber er kann nicht allein unabhängig verifizieren, ob „ein bestimmtes UTXO wirklich in das Babylon-Skript gesperrt wurde“; das braucht einen Full Node oder einen Indexer. Der Light Client vertraut nur auf die Header-Chain.
In den Installationsanleitungen in der offiziellen Doku für Vigilante steht, man müsse „einen synchronisierten Bitcoin Full Node“ einsetzen. In der Praxis konnte man aber mit dem Bitcoin Core Light-Mode (prune=1), also mit abgespecktem Verlauf, den Sentry-Job über Tests laufen lassen. Nachdem 0,05 Testnet-BTC ins System gesperrt wurden, meldete der Sentry einmal FP skip Signatur—es kam aber zu keinem Leck.
Wenn im Mainnet eine tiefe Reorganisation auftritt (>>6 Blöcke), kann der Light Client die Position des Zeitstempels vorübergehend falsch einschätzen, während ein Full Node das zuerst bemerkt. Beim Light Client spart man Speicher (ca. 80 MB/Jahr), als Nachteil kann die Header-Quelle bei Verschmutzung die Kette „mitziehen“. Für den privaten Betrieb des Sentry reicht ein Light Client aus, sofern man der ausgewählten Header-Quelle vertraut. Wer es paranoid betreibt, lässt zusätzlich einen Full Node mit Indexer laufen und verifiziert alles selbst.
Beides ist keine Entweder-oder-Frage, sondern eine Abwägung zwischen Kosten und dem Grad an Selbsthosting.
#baby $BABY @BabylonLabs_io