#baby $BABY In der tiefsten Nacht kann ich nicht schlafen und wälze mit den Jungs mal, was gerade bei Babylon so richtig angesagt ist (#baby $BABY @BabylonLabs_io ). Ganz ehrlich: Als ich mir gerade deren Pledge-/Staking-Skripte angesehen habe, kam mir ein riesiges Fragezeichen in den Kopf. Wenn das Projekt die ganze Zeit „reines, selbstverwaltetes Custody“ propagiert, warum muss dann trotzdem noch zwingend ein „Covenant Committee“ als Mittelsmann dazwischengepresst werden? Das ist nicht nur überflüssig, sondern bringt auch ganz unnötig ein zusätzliches Vertrauensrisiko mit sich. Anfangs dachte ich wirklich, das sei eine Art Notlösung: Die Projektseite kriegt die Technik nicht hin und bastelt deshalb einen Kompromiss.
Aber nachdem ich diese zwei Tage die Whitepaper und die technischen Underlying-Dokumente richtig durchgearbeitet habe, ist mir klar geworden: Ich lag falsch. Diese Last darf Babylon nicht tragen—das muss sich das „Kuchenstück“ selbst auf die Schultern nehmen.
Jungs, die etwas Technik draufhaben, wissen: Die nativen Bitcoin-Skripte sind einfach zu „dumm“. Damit kann man diese komplexen Logiken für Strafen und Bedingungen zum Freischalten nicht direkt schreiben. Das Babylon-Team wurde offenbar förmlich dazu gezwungen, einen Umweg zu gehen—also ein Threshold-Signature-Committee einzurichten. Kurz gesagt: Deren Aufgabe ist es, wenn du vorher entschließen/unbonding machst (Unbonding) oder wenn jemand Böses tut und bestraft werden muss (Slashing), als „gemeinsamer Unterzeichner“ zu fungieren. So wird sichergestellt, dass das Geld nur nach den vorgegebenen Regeln bewegt wird.
Wenn man das verstanden hat, ist vieles plötzlich schlüssig. Der Kern des Genialen an Babylon ist: „Mit Fesseln tanzen“—unter der harten Prämisse, dass sie die rote Linie nicht anfassen, also den Bitcoin-Konsens auf der Basisschicht nicht verändern, hauen sie dem Staking-Kuchen dennoch eine zweckgebundene, bestrafbare Variante hin. Natürlich gibt es einen Preis: Das System wird komplexer, und als Retail-Investor müssen wir eben noch eine weitere Stelle genau im Blick behalten. Aber in der Engineering-Welt nennt man das einen pragmatischen „Trade-off“: Erst von null auf etwas schaffen, und dann nach und nach die Perfektion jagen.
Allerdings bewahre ich weiterhin ein Restmaß an Wachsamkeit. Wenn wir investieren, dürfen wir nicht nur auf das Hier und Jetzt schauen. Mich interessiert nicht primär, ob dieses Komitee heute vielleicht etwas vorhat. Sondern vielmehr: Ob seine Macht sich in Zukunft mit Upgrades still und heimlich ausweiten könnte. Noch weiter gedacht: Falls eines Tages in der Zukunft Bitcoin wirklich ein natives Script-Upgrade bekommt (zum Beispiel dieser geradezu vielbeschworene OP_CAT, der dann endlich durchgeht), dann könnte der „Kuchen“ solche komplexen Aufgaben womöglich direkt selbst erledigen. Würde Babylon dann das „Komitee“ konsequent in ein Geschichtsmuseum verbannen? Ob dieses Design sauber und ohne Schaden durch die Zeit kommt, ist der eigentliche Knackpunkt für die langfristige Festung (Moat) des Projekts—wir werden sehen.
Aber nachdem ich diese zwei Tage die Whitepaper und die technischen Underlying-Dokumente richtig durchgearbeitet habe, ist mir klar geworden: Ich lag falsch. Diese Last darf Babylon nicht tragen—das muss sich das „Kuchenstück“ selbst auf die Schultern nehmen.
Jungs, die etwas Technik draufhaben, wissen: Die nativen Bitcoin-Skripte sind einfach zu „dumm“. Damit kann man diese komplexen Logiken für Strafen und Bedingungen zum Freischalten nicht direkt schreiben. Das Babylon-Team wurde offenbar förmlich dazu gezwungen, einen Umweg zu gehen—also ein Threshold-Signature-Committee einzurichten. Kurz gesagt: Deren Aufgabe ist es, wenn du vorher entschließen/unbonding machst (Unbonding) oder wenn jemand Böses tut und bestraft werden muss (Slashing), als „gemeinsamer Unterzeichner“ zu fungieren. So wird sichergestellt, dass das Geld nur nach den vorgegebenen Regeln bewegt wird.
Wenn man das verstanden hat, ist vieles plötzlich schlüssig. Der Kern des Genialen an Babylon ist: „Mit Fesseln tanzen“—unter der harten Prämisse, dass sie die rote Linie nicht anfassen, also den Bitcoin-Konsens auf der Basisschicht nicht verändern, hauen sie dem Staking-Kuchen dennoch eine zweckgebundene, bestrafbare Variante hin. Natürlich gibt es einen Preis: Das System wird komplexer, und als Retail-Investor müssen wir eben noch eine weitere Stelle genau im Blick behalten. Aber in der Engineering-Welt nennt man das einen pragmatischen „Trade-off“: Erst von null auf etwas schaffen, und dann nach und nach die Perfektion jagen.
Allerdings bewahre ich weiterhin ein Restmaß an Wachsamkeit. Wenn wir investieren, dürfen wir nicht nur auf das Hier und Jetzt schauen. Mich interessiert nicht primär, ob dieses Komitee heute vielleicht etwas vorhat. Sondern vielmehr: Ob seine Macht sich in Zukunft mit Upgrades still und heimlich ausweiten könnte. Noch weiter gedacht: Falls eines Tages in der Zukunft Bitcoin wirklich ein natives Script-Upgrade bekommt (zum Beispiel dieser geradezu vielbeschworene OP_CAT, der dann endlich durchgeht), dann könnte der „Kuchen“ solche komplexen Aufgaben womöglich direkt selbst erledigen. Würde Babylon dann das „Komitee“ konsequent in ein Geschichtsmuseum verbannen? Ob dieses Design sauber und ohne Schaden durch die Zeit kommt, ist der eigentliche Knackpunkt für die langfristige Festung (Moat) des Projekts—wir werden sehen.
