liu_001

Komm zum Binance-Sommercamp 🎉#币安夏令营

Als ich das Dokument @TermMax durchgesehen habe, ist mir ein leicht zu übersehendes Design aufgefallen: seine Curator-Rolle.

In den meisten Kreditvergabeverträgen wird der Liquiditätspool vom Vertrag einheitlich verwaltet. Wer Geld einlegt, wirft es in einen Pool, und wer einen Kredit aufnimmt, leiht aus demselben Pool. Der Zinssatz wird automatisch durch die Auslastung der Liquidität gesteuert, ohne dass jemand eingreift.

TermMax ist anders. Es führt eine Rolle namens Curator ein, die ihren eigenen Liquiditätspool erstellen und verwalten kann. Der Curator kann selbst den Zinskorridor dieses Pools festlegen, die Art der Sicherheiten bestimmen, die Liquidationsparameter konfigurieren und sogar eine Whitelist setzen, sodass nur bestimmte Adressen Kredite erhalten.

Das entspricht einer Verlagerung der Kontrolle über den Kreditmarkt vom Vertrag hin zur Community. Wenn du ein Market Maker bist, kannst du einen Pool erstellen, der speziell auf deine Handelspaare zugeschnitten ist, die Zinsen etwas unter dem Marktniveau setzen und ihn nur deinen eigenen Geschäftspartnern zur Verfügung stellen. Wenn du ein Projektteam bist, kannst du einen Pool erstellen, der nur deine eigenen Token als Sicherheiten akzeptiert, und deiner Community Kredit- und Darlehensdienste anbieten.

Das Einkommen des Curators stammt aus einem Teil der Zinsen, die der Pool erwirtschaftet. Je aktiver der von dir erstellte Pool ist, desto mehr verdienst du. Diese Anreizstruktur motiviert den Curator, die Parameter seines Pools zu optimieren und mehr Nutzer anzuziehen, um Geld einzulegen und Kredite aufzunehmen.

Natürlich trägt der Curator auch die Verantwortung. Wenn der Preis der Sicherheiten im Pool stark einbricht und dadurch uneinbringliche Forderungen entstehen, wird der Anteil der vom Curator gehaltenen Rechte zuerst eingesetzt, um die Verluste auszugleichen. Dieses Design bindet Risiko und Ertrag aneinander – der Curator hat einen Anreiz, hochwertige Sicherheiten und Kreditnehmer auszuwählen, statt blind zu expandieren.

Für Einleger bedeutet die Existenz des Curators, dass du dein Geld in den Pool legen kannst, dem du am meisten vertraust, statt gezwungen zu sein, die einheitlichen Parameter des Vertrags zu akzeptieren. Du kannst prüfen, welche Curator-Historie gut ist, Liquidationen rechtzeitig erfolgen und wie niedrig die Quote uneinbringlicher Forderungen ist, und dann dein Geld in genau diesen Pool einzahlen.

Ich persönlich habe das Gefühl, dass dieser Wettbewerbsmechanismus theoretisch dazu beitragen könnte, dass die Zinssätze und die Risikobepreisung im gesamten Markt effizienter werden.
#TermMax

Ich habe mir die Account-Abstraction-Schicht von Dusk genau angesehen und festgestellt, dass sie nicht wie bei Ethereum <a>$ETH </a> als Patch auf der Anwendungsebene arbeitet, sondern bereits ab der Konsensschicht direkt unterstützt.

Die WASM-Smart-Contracts von Dusk ermöglichen es Nutzern, eigene Verifikationslogik zu definieren. Das System erlaubt es, mit der eigenen Logik festzulegen, was als eine gültige Transaktion gilt. Du kannst die Verifikationslogik als ein WASM-Contract schreiben, ihn on-chain bereitstellen – und dein Account ist dann nicht mehr an traditionelle Signaturen mit elliptischen Kurven gebunden. Du kannst Logiken für Social Recovery, Multi-Faktor-Authentifizierung, Kombinationen aus Hardware-Schlüsseln und sogar zeitbasierte Bedingungen für die Autorisierung direkt im Contract definieren.

Das ist besonders nützlich für institutionelle Nutzer. So kann eine Vermögensverwaltungsgesellschaft eine Kontoregel festlegen: Bei einer Einzelüberweisung über einen bestimmten Betrag sind drei Direktoren-Signaturen erforderlich; bei einem Betrag darüber sind fünf Signaturen plus eine 48-stündige Zeitsperre nötig. Diese Logiken werden direkt im Account-Contract fest verdrahtet – ohne Umwege über zusätzliche Contracts oder Multi-Signature-Wallets.

Ein weiteres Detail ist die Atomizität der Transaktionsausführung. Die Account-Contracts von Dusk erlauben es, in einer einzigen Transaktion mehrere Operationen zu verketten – erst die Identität verifizieren, dann den Kontostand prüfen, dann die Überweisung ausführen und schließlich den Status aktualisieren. Der gesamte Ablauf wird in einer atomaren Einheit abgeschlossen: Entweder gelingt alles oder es wird alles zurückgerollt. Das ist viel einfacher als die zweistufigen Abläufe in Ethereum, bei denen erst autorisiert und anschließend übertragen wird, und spart außerdem eine zusätzliche On-Chain-Interaktion.

Natürlich bedeutet das Anpassen der Verifikationslogik auch eine größere Angriffsfläche. Wenn in deinem Account-Contract eine Schwachstelle steckt, könnte ein Angreifer deine Verifikationsregeln umgehen und die Assets direkt abziehen. Dusk begegnet dem, indem es dazu anregt, entscheidende Contracts streng zu auditieren und formal zu verifizieren, um die Sicherheit der Nutzer-Assets zu gewährleisten. Diese vorausgesetzte Sicherheitsbarriere ist für Entwickler eine Belastung, für Nutzer jedoch ein Schutz.
$DUSK @Dusk #dusk

#termmax @TermMax Ich habe die Dokumentation von TermMax gelesen und festgestellt, dass es eine Kreditsumme mit fester Laufzeit in drei handelbare Wertpapiere zerlegt – eine ganz andere Denkweise als bei Aave und dessen Protokollen mit variablen Zinssätzen.

Der Geldgeber bringt das Kapital ein und erhält dafür FT, also Token mit festem Zinssatz. Das ist im Kern eine Nullkuponanleihe: Du kaufst sie heute mit Abschlag, bekommst bei Fälligkeit zum Nennwert ausgezahlt, und der Ertrag wird bereits im Moment der Order fest einkalkuliert. Wie sich die Marktzinsen später auch bewegen mögen, beeinflusst das deine Rechnung nicht.

Der Kreditnehmer stellt Sicherheiten bereit; die jeweilige Schuldposition wird dann als ein GT (Gearing Token) NFT geprägt. Darin sind Informationen über die Sicherheiten, den Schuld-Nennbetrag und das Fälligkeitsdatum enthalten.

Die Doku liefert ein sehr anschauliches Beispiel: Eine einjährige Schuld mit einem Nennwert von 1 US-Dollar. Wenn der Zinssatz 8 % beträgt, dann hat der FT aktuell ungefähr einen Wert von 0,92 (92 Cents), der XT etwa 0,074 (7,4 Cents). Zusammen ergibt das genau 1.

Je näher das Fälligkeitsdatum rückt, desto mehr fällt der Wert von XT gegen Null – Null werden ist kein Bug, sondern ein Zeichen dafür, dass die Abwicklung abgeschlossen ist.

Diese drei Komponenten können separat gehandelt werden; damit werden die drei Dimensionen Zinssatz, Laufzeit und Leverage getrennt bepreist. Der Geldgeber kann nur FT handeln, um die fixe Zinsspanne zu verdienen, ohne sich um Schwankungen des Sicherheitenpreises kümmern zu müssen. Der Kreditnehmer kann mit GT per Klick Kredite wiederholt aufnehmen; die Kosten sind beim Einstiegsszeitpunkt sofort fest fixiert. XT gibt Market Makern ein Werkzeug, um den Zeitwert abzusichern.

Im traditionellen Finanzwesen müsste man ähnliche Effekte über einen Anleihe-Handelsbereich plus einen Repo-Markt plus einen Zins-Swap abbilden – also drei getrennte Systeme, die jeweils ihren Job machen. TermMax setzt das in einer einzigen Transaktion mit drei Token zusammen.
@TermMax

Ich habe das Dokument zum Bestrafungsmechanismus von Dusk gelesen und festgestellt, dass es „aus Versehen einen Fehler machen“ und „absichtlich Böses tun“ in zwei völlig unterschiedliche Behandlungsarten einteilt.

Viele Blockchain-Projekte bestrafen Validatoren auf einfache Weise: Geldbußen. Leicht bedeutet, ein Teil des Einsatzes wird abgezogen, schwer bedeutet, der gesamte Einsatz wird eingezogen. Aber @Dusk macht das nicht.

Stattdessen gibt es eine Art Soft-Penalty, die gezielt gegen unabsichtliche Fehltritte eingesetzt wird. Zum Beispiel: dein Knoten geht offline, du wurdest zwar zum Blocken ausgewählt, hast aber nicht broadcastet, die Netzwerkports sind nicht erreichbar oder die Version ist nicht auf dem neuesten Stand gegenüber der aktuellen Kettenhöhe. Das sind Probleme auf Betriebsebene und keine subjektiv böse Absicht.

Die Vorgehensweise läuft in zwei Schritten ab. Schritt eins ist eine Warnung: Du bekommst eine Chance, ohne dass dir irgendetwas abgezogen wird. Wenn du jedoch nochmal denselben Fehler machst, wird deine Berechtigung zum Blocken für einen Zyklus ausgesetzt. Während dieser Zeit wirst du nicht zum Blocken ausgewählt und kannst auch nicht an Abstimmungen teilnehmen, sodass du natürlich keine Blockbelohnungen erhältst. Bei wiederholten Verstößen wird die Sperrzeit immer länger: beim zweiten Mal zwei Zyklen, beim dritten Mal drei Zyklen und so weiter.

Schritt zwei ist das Absenken des Gewichts (Weight). Bei jeder Sperrung wird ein Teil deines aktiven Stakes in den gesperrten Zustand verschoben. Beim ersten Mal 10 %, beim zweiten Mal 20 % – die Beträge werden kumuliert. Der verschobene Anteil ist weiterhin dein Eigentum; er wird nicht vernichtet. Du kannst warten, bis der Knoten wieder repariert ist, und dann beantragen, die Sperrung aufzuheben, um ihn zurückzuerhalten. Wenn dein aktiver Einsatz jedoch auf unter 1000 Coins gedrückt wird, wird der Knoten vollständig eingefroren: Dann musst du ihn abmelden und neu registrieren, um wiederherstellen zu können. $DUSK

Wirklich „Verbrennung“ (also harte Bestrafung) gibt es nur bei der Hard-Penalty. Diese richtet sich gegen eindeutig böswillige Handlungen – etwa wenn du auf derselben Höhe zwei widersprüchliche Blöcke unterschreibst oder wenn du widersprüchliche Stimmen (conflicting votes) abgibst. Nur in solchen Fällen wird dein Einsatzguthaben wirklich zerstört.

Die Logik dieses Designs ist sehr klar und zugleich ziemlich menschlich: Ein Fehler im Betrieb ist nichts Ungewöhnliches – dafür sollte man nicht sein Kapital verlieren, aber man darf dich auch nicht ohne jede Konsequenz davonkommen lassen. Die Konsequenz ist, dass dein Stimmgewicht sinkt, die Wahrscheinlichkeit, zum Blocken ausgewählt zu werden, immer geringer wird und damit auch dein Ertrag zwangsläufig schrumpft. Wenn du dreimal hintereinander offline gehst, kann dein effektives Gewicht unter Umständen nur noch bei etwa vierzig Prozent liegen, und die Einnahmen fallen ungefähr in demselben Verhältnis.

Meiner Ansicht nach ist das zwar keine kostenlose Amnestie, aber deutlich milder als „mit der Keule“ alles auf einmal abzuwürgen. Gerade für Leute, die ihren Knoten zu Hause selbst laufen lassen, ist dieser Spielraum für Fehlertoleranz sehr wichtig. #dusk

#dusk $DUSK @Dusk In der Welt der Blockchain werden Datenschutz und Compliance seit Langem als ein unvereinbarer Widerspruch betrachtet. Privacy Coins werden aufgrund ihrer schwierigen regulatorischen Prüfungen von Institutionen gemieden, während völlig transparente Public Chains jede Transaktion und jede Position eines Instituts der Öffentlichkeit offenlegen. Das Aufkommen des Dusk Network ist genau dazu da, dieses „Entweder-oder“-Dilemma zu durchbrechen.

Dusk Network ist eine Layer-1-Blockchain, die speziell für regulierte Finanzanwendungen entwickelt wurde. Ihre Kernmission ist es, Institutionen zu ermöglichen, Vermögenswerte on-chain auszugeben, zu handeln und abzuwickeln, ohne sensible Marktdaten öffentlich preiszugeben. Ihre Lösung ist kein nachträglicher Flickenteppich, sondern verankert Datenschutz und Compliance von Grund auf im Kern des Protokolldesigns.$ETH

Auf technischer Ebene nutzt Dusk Zero-Knowledge-Proofs (ZKP), um „prüfbaren Datenschutz“ zu realisieren. Wenn Transaktionen stattfinden, bleiben Details wie Betrag, Adresse und Transaktionspfad vollständig verborgen, doch bestimmte Regulierungs-Knoten können jederzeit den Compliance-Status der Transaktion verifizieren — das Ergebnis wird geliefert, der Prozess nicht offengelegt. Dieses Design ermöglicht es Institutionen, Geschäftsgeheimnisse zu schützen und zugleich regulatorische Anforderungen wie KYC/AML sowie Melde- und Offenlegungspflichten zu erfüllen.

Beim Transaktionsmodell bietet $DUSK eine Dual-Track-Option: Moonlight ist ein öffentliches Kontenmodell für Transaktionen und eignet sich für Szenarien, in denen Transparenz erforderlich ist; Phoenix hingegen ist ein auf Zero-Knowledge-Proofs basierendes Privacy-Transaktionsmodell, das Transaktionsinformationen vollständig verbirgt. Beide werden auf derselben Settlement-Schicht endgültig bestätigt, und Nutzer können je nach Geschäftsanforderung frei wechseln.

Auf der Konsensebene verwendet Dusk einen Mechanismus namens Succinct Attestation (SA), ein permissionloses Proof-of-Stake-Verfahren, bei dem zufällig ausgewählte Validierungsknoten die Blockproduktion, Verifizierung und endgültige Bestätigung übernehmen. Dieses Design bietet eine für Finanzmärkte geeignete schnelle deterministische Finalität — nicht „mit hoher Wahrscheinlichkeit in Ordnung“, sondern „zweifelsfrei sicher“. Am 7. Januar 2026 wurde das Mainnet von Dusk offiziell gestartet.

@Dusk s ultimative Vision ist es, regulierte Finanzanlagen — Wertpapiere, Fonds, tokenisierte Real-World Assets — on-chain konform zirkulieren zu lassen, ohne die Datenschutzrechte einer der Parteien zu opfern. Es geht nicht darum, zwischen Datenschutz und Compliance zu wählen, sondern beides gleichzeitig möglich zu machen.

Ich habe in dem Konsens-Strafsystem von $DUSK ein leicht zu übersehendes Design entdeckt: Es trennt „Strafe“ und „Sperre“ in zwei unabhängige Werkzeuge.

Viele PoS-Ketten behandeln Fehler von Validatoren sehr eindimensional – mit Geldbußen. Leichter: ein Abzug eines Teils des Einsatzes, schwerer: vollständige Einziehung. Der Dusk-SBA-Konsens ist anders: Er unterteilt die Strafen in zwei Dimensionen – eine wirtschaftliche Strafe und eine zeitweise Aussetzungsmaßnahme der Berechtigung. Beide können unabhängig voneinander ausgeführt oder kombiniert werden. $DUSK

Wirtschaftliche Strafe umfasst sowohl „weiche“ als auch „harte“ Bußen (Soft/Hard Penalty). Bei der weichen Einziehung werden keine Coins verbrannt; stattdessen wird das aktive Gewicht in den locked-Zustand verschoben. Nach der Reparatur kann der Knoten wieder reaktiviert werden. Die harte Einziehung richtet sich gegen böswillige Handlungen wie Double-Sign (Doppelsignierung) und böswilliges Abstimmen: Dabei wird direkt ein bestimmter Prozentsatz des Einsatzes vernichtet. Der Vernichtungsgrad wird nach der Schwere des Vergehens gestaffelt und ist nicht „alles oder nichts“.

Die zeitliche Sperrung ist eine weitere Dimension. Selbst wenn der Knoten für keinen Cent bestraft wird, entfernt die Konsensschicht ihn bei wiederholten Fehlern über einen Schwellenwert hinaus vorübergehend aus der provisioner-Collection. Während dieser Zeit darf der Knoten keine Blöcke erzeugen, nicht abstimmen und erhält keine Belohnungen. Die Wiedererlangung der Berechtigung erfordert, dass der Knoten selbst aktiv eine re-register-Transaktion initiiert und anschließend eine Abkühlphase abwartet. $ETH

Diese beiden Dimensionen zusammen ergeben vier mögliche Strafzustände: nur strafen, aber nicht sperren; nur sperren, aber nicht strafen; beides – strafen und sperren; sowie weder strafen noch sperren. Dieses fein abgestufte Design ermöglicht es der Konsensschicht, je nach Art und Schwere des Fehlers unterschiedlich zu reagieren: Bei sporadischen Betriebsfehlern wird nur gesperrt, bei böswilligen Double-Sign-Verhalten werden sowohl Strafe verhängt als auch Sperrung vorgenommen.

Ich glaube, diese Designphilosophie zeigt das Verständnis von @Dusk für die Rolle „Knotenbetreiber“: Sie sind Partner, keine Feinde. Der Zweck der Bestrafung ist, das Verhalten zu korrigieren – nicht, den Knoten zu vernichten. Den Weg zurück ins Netzwerk zu erhalten, schützt die langfristige Gesundheit des Netzwerks besser als ein Schlag, der alles beendet. #dusk

$DUSK Es gibt einen eher unbekannten Detailpunkt: Die Account-Abstraktionsschicht ist nicht so eine nachträglich kompatible Lösung wie bei EIP-4337, sondern von der Konsensschicht an direkt eingebaut.

Das Account-Contract-System von Dusk ermöglicht es Nutzern, mit eigener Logik zu definieren, was als „gültige Transaktion“ gilt. Du kannst deine Validierungslogik als ein WASM-Contract schreiben, auf der Kette bereitstellen, und dann ist dein Account nicht mehr auf ECDSA-Signaturen angewiesen. Du kannst Social Recovery, Multi-Faktor-Authentifizierung, Kombinationen aus Hardware-Schlüsseln oder sogar zeitbasierte Bedingungsautorisierung innerhalb des Contracts selbst definieren. $DUSK

Das ist besonders praktisch für institutionelle Nutzer. Beispielsweise kann eine Vermögensverwaltungsgesellschaft eine Kontoregel festlegen: Einzelne Überweisungen über 100.000 DUSK erfordern drei Unterschriften von Direktoren, über 500.000 benötigen fünf Unterschriften plus eine 48-Stunden-Zeit-Sperre. Diese Logik ist direkt im Account-Contract „fest verdrahtet“ und muss nicht über irgendeinen Zwischen-Contract oder ein Multi-Sig-Wallet laufen.

Ein weiteres Detail betrifft die Atomizität der Transaktionsausführung. Die Account-Contracts von Dusk erlauben, in einer einzigen Transaktion mehrere Operationen zu verketten – erst Identität verifizieren, dann den Kontostand prüfen, dann die Überweisung ausführen und schließlich den Status aktualisieren – der gesamte Ablauf wird in einer atomaren Einheit abgeschlossen: entweder gelingt alles oder es wird alles rückgängig gemacht (Rollback). Das ist viel kompakter als die zweistufige „approve dann transferFrom“-Abfolge in Ethereum und spart auch einen zusätzlichen On-Chain-Interaktionsschritt. $ETH

Natürlich bedeutet das Anpassen der Validierungslogik auch eine größere Angriffsfläche. Wenn in deinem Account-Contract ein Bug steckt, könnte ein Angreifer deine Validierungsregeln umgehen und die Assets direkt abziehen. Dusk begegnet dem, indem verlangt wird, dass der Account-Contract zunächst die Prüfungen formaler Verifikations-Tools bestehen muss, bevor er vom Netzwerk akzeptiert wird. Diese vordere Sicherheits-Schwelle ist eine Belastung für Entwickler, aber ein Schutz für Nutzer.
@Dusk #dusk

Ich habe die letzten zwei Tage das Piecrust-VM von $DUSK untersucht und eine sehr interessante Design-Entscheidung entdeckt: Die Art und Weise, wie der Vertrag bereitgestellt wird, ist völlig anders als im EVM.

Im EVM stellt man einen Vertrag bereit, indem man eine Transaktion mit dem Bytecode sendet. Die Chain erzeugt dann eine Adresse, und der Vertragscode wird dauerhaft im State gespeichert. Die Piecrust VM geht diesen Weg nicht. Stattdessen wird der Vertrag in Form von WASM-Bytecode bereitgestellt. Beim Deployment wird der Code jedoch nicht direkt in den Chain-State geschrieben. Zuerst wird er zu einer Piecrust-Zwischenrepräsentation kompiliert und dann in einen separaten Speicherbereich namens „Contract Store“ abgelegt.$ETH

Das hat zwei Vorteile. Erstens die Ausführungseffizienz. WASM-Bytecode wird vor der Ausführung weiter optimiert – etwa durch das Entfernen von totem Code und das Inlineen kurzer Funktionen. Zur Laufzeit muss man nicht wie im EVM Opcode für Opcode einzeln interpretieren, sondern kann direkt auf die Maschinenanweisungen des Host-Systems abgebildet werden. Ich habe ihre Benchmarks gesehen: Für denselben Logik-Contract ist die Ausführungsgeschwindigkeit in Piecrust ungefähr 3–5× schneller als im EVM.

Zweitens die Speichereitrennung. Jeder Vertrag hat im Contract Store einen eigenen Namensraum. Vertrag A kann den Speicher von Vertrag B nicht durchlaufen, es sei denn, B stellt explizite Abfrage-Schnittstellen bereit. Diese Isolation ist für Finanzszenarien entscheidend – die Positionsdaten eines Wertpapier-Token-Contracts werden nicht versehentlich durch einen Bug im Nachbar-Contract ausgelesen oder geändert.

Ein weiterer Detailpunkt ist der Mechanismus für Vertrags-Upgrades. Piecrust unterstützt Upgrades über Proxy-Contracts. Beim Upgrade muss jedoch ein Nachweis erbracht werden, dass der neue und der alte Contract über passende WASM-Hashwerte zusammenpassen. So wird sichergestellt, dass der aktualisierte Code logisch eine legitime Weiterentwicklung des ursprünglichen Contracts ist und nicht heimlich durch einen komplett anderen Vertrag ersetzt wurde. Diese kryptografische Garantie setzt im Vergleich zum EVM-Proxy-Modell noch einen zusätzlichen Sicherheitsanker.@Dusk

Natürlich hat Piecrust auch seinen Preis. Der WASM-Toolchain ist noch nicht so ausgereift wie Solidity. Entwickler müssen sich mit Rust oder AssemblyScript vertraut machen, und Debugger sowie Profiler werden ebenfalls noch weiterentwickelt. Für Dusk jedoch, das auf institutionelle Nutzer abzielt, stehen Effizienz und Sicherheit über Entwicklerkomfort – dieses Abwägen ist sinnvoll.#dusk

#dusk $DUSK Ich habe in den letzten Tagen in Dusk’s GitHub-Repository herumgestöbert und in einem Dokument eine Designidee entdeckt, die zwar kaum ausgeführt wird, aber tatsächlich sehr entscheidend ist: das Speichereisolierungsmodell der Piecrust VM.

Die meisten Smart-Contract-Virtual-Machines nutzen gemeinsam genutzten Speicher. Daten zwischen verschiedenen Contracts gelangen dann über Message-Calls miteinander in Verbindung. Das ist flexibel – aber der Nachteil ist, dass ein Bug in einem Contract den Speicherbereich anderer Contracts verschmutzen kann. Piecrust VM geht einen anderen Weg: Jede Contract-Instanz hat ihren eigenen, separaten linearen Speicherbereich. Contracts können den Speicher des jeweils anderen nicht direkt lesen oder schreiben, sondern nur über klar definierte ABI-Schnittstellen serialisierte Daten austauschen.

Diese Art der Isolation – analog gedacht – ist eher wie ein WebAssembly-Sandbox als wie ein EVM-Shared-State. Für die von Dusk anvisierten regulierten Finanzszenarien passt dieses Design sehr gut: Ein Bug in einem Wertpapier-Token-Contract kann nicht die Kundenguthaben aus dem „Nachbar“-Zahlungs-Contract offenlegen. Bei Audits lässt sich jeder Contract unabhängig prüfen, ohne sich Gedanken über implizite Datenflüsse zwischen Contracts machen zu müssen.

Ein weiteres Detail, das mir aufgefallen ist, ist die Art, wie Piecrust Gas bemisst. Es ist nicht so wie im EVM, wo jede Opcode-Zeile einzeln abgerechnet wird, sondern es berechnet die Kosten als gewichtete Ausführungskosten der wasm-Instruktionen. Addition/Subtraktion und Multiplikation/Division haben unterschiedliche Gas-Kosten, und auch Memory-Reads/-Writes sowie arithmetische Operationen unterscheiden sich in ihrer Gas-Bepreisung. Diese feingranulare Abrechnung kann Entwickler theoretisch dabei unterstützen, effizientere Contracts zu schreiben – weil man weiß, welche Operationen teuer sind, und ihnen entsprechend ausweichen kann.

Natürlich bedeutet das auch, dass die Gas-Schätzung komplexer wird. Die Gas-Schätzung im EVM ist durch die Toolchains bereits stark ausgereift; bei Piecrust fehlt bislang noch ein ausgereifter Profiler. Aber die Richtung ist richtig: Mit genauerer Messung zu effizienterer Ausführung. @Dusk

#dusk $DUSK Als ich die Dusk-Dokumentation gelesen habe, fand ich am spannendsten, dass sie „Transparenz“ und „Geheimhaltung“ als zwei nebeneinanderliegende native Transaktionsmodelle umsetzt – statt erst nachträglich mit Patches nachzubessern.

In der Dusk-Settlement-Layer ist Moonlight das Kontomodell: Kontostand, Absender/Empfänger und Beträge sind vollständig offengelegt, ähnlich einem gewöhnlichen ERC-ähnlichen Transfer. Phoenix ist jedoch anders: Es ist ein note-basiertes, verschlüsseltes Geheimhaltungsmodell. Die Gelder liegen als verschlüsselte notes vor; beim Transfer wird mit PLONK-basierten zk-SNARK-Beweisen belegt, dass drei Dinge stimmen: keine Double-Spends, die Eingaben sind nicht kleiner als die Ausgaben und der Betrag liegt im gültigen Bereich. Beobachter können weder die Beträge sehen noch die Zuordnung von Adressen; Entschlüsseln und Prüfen ist nur für diejenigen möglich, die den viewing key besitzen.

Zuerst dachte ich, das sei im Kern wie bei Zcash. Bei genauerem Hinsehen fiel mir jedoch der entscheidende Unterschied „selektive Offenlegung“ auf. Eine Phoenix-note kann an einen viewing key gebunden werden. Wenn eine Institution gegenüber den Regulierungsbehörden die Konformität einer bestimmten Transaktion nachweisen muss, muss sie nicht die gesamten Daten der gesamten Kette offenlegen, sondern nur das Klartext-Element dieser einen Transaktion plus einen Zero-Knowledge-Beweis übergeben. Diese Feinheit – „standardmäßig verschlüsselt, nach Bedarf entschlüsselt“ – passt besser zu regulatorisch geprägten Finanzszenarien als eine global anonyme Lösung.

Noch besser: Beide Modelle werden im selben Transfer Contract abgerechnet, wobei der Zustand des jeweils anderen sich nicht gegenseitig „verschmutzt“. Du kannst mit Moonlight Mittel des Treasury transparent ausweisen, mit Phoenix hingegen OTC-Transaktionen betreiben, bei denen die Gegenpartei verborgen bleibt – und am Ende werden beide in derselben Blockchain-Blockfolge deterministisch festgeschrieben. Dusk überlässt das „ob transparent oder nicht“ dem Nutzer je nach Szenario und zwingt es nicht als einheitliche Protokollregel auf – das ist die größte Korrektur, die Dusk für den Privacy-Track vornimmt.

Ein weiteres Detail: In der Phoenix-note-Struktur ist eine Ablaufmechanik eingebaut. Jede note hat eine Obergrenze der Blockhöhe; wenn sie bis über diese Höhe hinaus nicht ausgegeben wird, verfällt sie automatisch und die Mittel gehen an den Absender zurück. Das verhindert, dass sich „Zombie-notes“ endlos anhäufen, und sorgt dafür, dass sich der Zustand der Kette nicht unendlich aufbläht. Diese kleinen technischen Feinarbeiten zeigen, dass das Team die langfristigen Betriebskosten wirklich im Blick hat.@Dusk

Ich möchte heute über einen technischen Detailpunkt sprechen, über den nur selten gesprochen wird: den OP_CHECKSIGADD-Opcode, der in den Vault-Skripten von Babylon verwendet wird.

Dieser Opcode ist eine Neuerung, die durch das Taproot-Upgrade eingeführt wurde. In traditionellen Bitcoin-Skripten, wenn du mehrere Signaturen verifizieren willst, musst du mehrere OP_CHECKSIG-Operationen schreiben – jede Signatur wird einzeln geprüft, und der Skriptumfang wird riesig. OP_CHECKSIGADD erlaubt dir, mehrere öffentliche Schlüssel und Signaturen in einen Batch-Verifizierungsablauf zu packen und alles auf einmal zu erledigen; dadurch schrumpft die Skriptgröße erheblich.

Im Vault-Skript von TBV wird dieser Opcode auf dem Multisig-Pfad eingesetzt. Ein typisches Vault richtet mehrere Co-Signer ein – der Depositor selbst, der Vault Provider, der Keeper-Knoten – und jede zulässige Kombination darf diese UTXO ausgeben. Mit OP_CHECKSIGADD wird diese Logik umgesetzt; das Skript ist im Vergleich zur alten Lösung ungefähr 40 % kleiner.

Ich habe mir das ausgerechnet. Wenn es kein Taproot-Upgrade gäbe, könnte das Babylon-Vault-Skript auf über 4000 Weight Units anwachsen: Die Anzahl an Vaults, die in einen einzelnen Block passen, würde sich halbieren, und die Transaktionsgebühren würden sich verdoppeln. Taproot bringt nicht nur mehr Privatsphäre, sondern ganz konkret auch Gas-Einsparungen.

Ein weiterer verwandter Opcode ist die Schwester-Variante von OP_CHECKSIGADD: OP_CHECKSIGADDVERIFY. Er sorgt dafür, dass das Skript bei einem Verifizierungsfehler direkt fehlschlägt und die Transaktion beendet. Babylon verwendet diesen Opcode in einigen entscheidenden Pfaden, um Sicherheitsprüfungen zu erzwingen – etwa indem man am Ende des Skripts im Rahmen der Reaktion auf die Challenge-Phase die VERIFY-Variante ergänzt, sodass die Ausführung erst weitergeht, nachdem alle Signaturprüfungen bestanden sind.

Diese kleinen Details werden im Alltag kaum beachtet, aber sie bilden die fundamentalen Bausteine des TBV-Sicherheitsmodells. Jede Weiterentwicklung der Bitcoin-Skriptsprache schafft wieder neuen Spielraum für die Fantasie der Anwendungen darüber.

$BABY #baby @BabylonLabs_io

Ich möchte heute über eine ganz konkrete Zahl sprechen: die Größe des Vault-Skripts von Babylon.

Die Weight-Limit für Bitcoin-Blockdaten liegt bei 4 Millionen Einheiten; eine typische Transaktion beansprucht etwa 200–300 Einheiten. Aber die Vault-Erstellungs-Transaktion für TBV ist viel größer als eine normale Transaktion, weil sie komplexe Covenant-Skripte, Merkle-Pfad-Beweise und Logik für mehrere Signaturen enthält.

Ich habe das grob überschlagen: Eine standardmäßige TBV-Vault-Erstellungs-Transaktion hat einen Weight von etwa 1500–2500 Einheiten. Das bedeutet, dass ein Bitcoin-Block maximal nur 1600–2600 Vault-Erstellungs-Transaktionen fassen kann. Wenn die Nutzerzahl von Babylon steigt, kann allein das Erstellen von Vaults einen beträchtlichen Teil des Blockraums belegen.

Das führt zu zwei Problemen.

Erstens: Wettbewerb. Wenn Vault-Erstellungs-Transaktionen und andere normale Bitcoin-Transaktionen sich den Blockraum teilen, gilt: Wer mehr bietet, wird zuerst gepackt. Große Akteure können die Gasgebühren sehr hoch setzen und sich vordrängeln; kleinere Privatanleger müssen warten oder mehr Gebühren zahlen. Das ist im Kern dasselbe wie der Gas-Krieg auf Ethereum – nur dass sich die Schlacht vom EVM auf das Bitcoin-Hauptnetz verlagert.

Zweitens: Langfristige Nachhaltigkeit. Wenn Babylon wirklich Millionen von Nutzern erreichen würde und täglich zehntausende Vault-Erstellungs- und -Rückkaufs-Transaktionen in das Bitcoin-Netz strömen, reicht dann der Blockraum überhaupt? Die Probleme, mit denen das Lightning Network damals konfrontiert war, wird Babylon früher oder später ebenfalls haben.

Babylons Gegenmaßnahmen habe ich in zwei Punkten gesehen. Erstens: Aggregierter Rückkauf – mehrere Rückkaufsanfragen werden zu einer einzigen Transaktion zusammengefasst, um die On-Chain-Spur zu reduzieren. Zweitens: Anreize für langfristiges Sperren – je länger gesperrt wird, desto niedriger sind die Amortisationskosten für die Vault-Erstellungs-Transaktion.

Aber das sind nur Linderungen, keine Heilung. Solange die Basis weiterhin das Bitcoin-Hauptnetz ist, liegt dort auch die Obergrenze für den Durchsatz.
@BabylonLabs_io $BABY #baby

Ich habe dieses Mal eine @BabylonLabs_io weiße Arbeit gelesen und bin dabei auf ein Wort gestoßen, das ich zuvor überflogen hatte, ohne genauer hinzuschauen: Covenant Tree.

Das TBV-vault ist kein einlagiges Skript, sondern eine baumartige Struktur, die aus mehreren Covenants besteht. Jeder Blattknoten steht für eine Art gültige Ausgabebedingung – normales Einlösen, Gewinn bei einer Challenge, Rückerstattung nach Zeitablauf, Slash-Strafen usw. Der Wurzelknoten ist der tweaked public key der P2TR-Ausgabe.

Der Vorteil dabei ist: Wenn du eine Ausgabetransaktion initiierst, musst du nur den Merkle-Pfad von dem Blatt bis zur Wurzel offenlegen, statt die komplette Baumstruktur preiszugeben. Beim Verifizieren durch Bitcoin-Knoten wird nur geprüft, ob der von dir offengelegte Pfad mit dem Wurzel-Hash übereinstimmt; die anderen Zweige bleiben für dich Privatsache.$BABY

Was bedeutet das? Dass die vollständige Logik des vault für externe Beobachter verborgen ist. Andere wissen nur den Root dieser Baumstruktur, nicht, wie viele verschiedene Ausstiegsbedingungen darin hängen und welche Parameter jede Bedingung hat.

Ein weiterer Punkt ist die rekursive Verifikation. Das Whitepaper erwähnt, dass bestimmte komplexe Challenge-Szenarien mehrere Runden an Beweisen erfordern: Die Ausgabe einer Beweisschleife wird zur Eingabe der nächsten. Die Struktur des Covenant Tree unterstützt diese Rekursion von Natur aus – die Ausgabebedingung jedes Blattknotens kann auf einen anderen Knoten im Baum verweisen und so eine Ketten-Verifizierungspfade bilden.

Ich verstehe den Zweck dieses Designs: Die Ausdruckskraft von Bitcoin-Skripten ist begrenzt. Wenn sich eine komplexe Logik in einem einzigen Verifikationsschritt nicht abbilden lässt, wird sie in mehrere Schritte zerlegt – jeder Schritt entspricht einem Knoten im Baum. Schritt für Schritt werden sie über Covenant-Einschränkungen miteinander verkettet. So umgehst du die Längenbeschränkung von Skripten, während die Verifizierungsintegrität erhalten bleibt.#baby

Ich habe gestern die TBV-Whitepaper wieder durchgearbeitet und bin im Abschnitt zu peg-in eine Weile hängen geblieben. Alle sagen immer: „BTC in einen Taproot Vault sperren und fertig“, aber im Whitepaper gibt es tatsächlich vor dem echten Einstieg in den Vault noch einen Zwischestatus namens „Pre-PegIn HTLC output“. Diese Stelle wird kaum zerlegt. $BABY

Laut der Dokumentation im Whitepaper wird bei der Auslösung der ersten Bitcoin-Transaktion der BTC nicht direkt in den endgültigen Vault-P2TR-Output geschoben, sondern erst in einen Pre-PegIn-Output, der einen Hashlock sowie einen Timelock-Refund besitzt. Zu diesem Zeitpunkt liegt der BTC bereits on-chain, aber der Vault ist noch nicht „aktiv“. Er muss auf zwei Dinge warten: erstens, dass auf der Bitcoin-Seite genügend Bestätigungen zusammenkommen, und zweitens, dass du auf der Ethereum-Seite das Hashlock-Preimage (den geheimen Wert, den nur du kennst) offenlegst. Sobald das Preimage bekannt ist, wird der letzte Schritt mit den erforderlichen Witness-Daten getriggert und der BTC in den echten Vault-Output weitergeschoben; wenn diese Offline-Koordination (Vault Provider, Keeper bauen zusammen den Transaktionsgraphen) hakt oder du deine Entscheidung änderst und das Preimage nicht offenlegst, sorgt der Timelock-Refund-Pfad im Pre-PegIn dafür, dass du die Coins einseitig zurückholen kannst. @BabylonLabs_io

Anfangs dachte ich, das sei nur ein technisches Backup. Dann ist mir klar geworden: Es verwandelt das „Cross-Chain-Aktivieren“ in einen atomaren Schalter. Die Registrierungs-Events auf Ethereum und die Asset-Sperrung auf Bitcoin werden über eine SHA-256-Preimage-Offenlegung miteinander gekoppelt; wenn eine Seite nicht fertig wird, bleibt das Asset nicht im Protokoll feststecken. Das ist etwas ganz anderes als bei traditionellen Bridges, wo man erst die Mainchain sperrt und dann die geminten, angekoppelten Tokens prägt – der BTC verlässt dabei von Anfang bis Ende nie die UTXO-Sammlung.

Noch härter ist das Manöver der „Transaktionsgraph-Pre-Signierung“. Das Whitepaper sagt, dass beim Vault-Create bereits alle erlaubten Ausgabepfade für spätere legitime Verwendungen – Redemption, Liquidation, Challenge-Response usw. – komplett als Pre-Sign-Transaktionen gebaut und signiert werden. Nach dem Erstellen kann keine Seite mehr eine neue Route erfinden. Die Bitcoin-Nodes, die danach etwas tun müssen, ist lediglich „Skripte und Signaturen verifizieren“, nicht „Aave oder eine PoS-Chain-Logik verstehen“. Externen Zustand in aus Bitcoin verständliche Ausgabebedingungen zu übersetzen, verschiebt das Vertrauen weg vom Custodian hin zur Berechnung selbst – das war der Satz, den ich vor dem Zerpflücken der Details nicht wirklich „gegessen“ hatte. #baby

Ich habe eine Frage überlegt: Würden die „Puristen“ von Bitcoin Babylon boykottieren? $BABY

In der Bitcoin-Community gibt es eine sehr starke Strömung. Sie ist der Ansicht, Bitcoin sollte ganz brav als digitales Gold funktionieren und mit keinem DeFi, keinem Staking, keinem Zinsverdienen oder sonstigem „Schnickschnack“ herumspielen. Für sie liegt der Wert von Bitcoin in seiner Reinheit – einer dezentralen Währung, die nicht durch irgendeine Drittpartei eingegriffen wird.

Was @BabylonLabs_io Babylon in ihren Augen tut, könnte also wie eine „Verunreinigung“ der Reinheit von Bitcoin wirken.

Das ist keine bloße Sorge. Damals, als SegWit und Taproot aktualisiert wurden, gab es innerhalb der Community heftige Diskussionen. Gegner waren der Meinung, jede Änderung sei eine Verratshandlung am Geist von Bitcoin. Babylon verändert zwar nicht die Konsensschicht von Bitcoin, baut aber tatsächlich eine Finanzanwendung darüber. Das könnte bei manchen Puristen empfindliche Nerven treffen.

Ein realistischeres Problem ist: Wenn die Community der Bitcoin-Core-Entwickler eine negative Haltung gegenüber Babylon einnimmt, könnte das die künftige technische Kompatibilität von Babylon beeinträchtigen? Beispielsweise: Wenn Bitcoin in Zukunft ein Upgrade erhält, könnte es dann – bewusst oder unbewusst – dazu kommen, dass bestimmte Funktionen von Babylon unwirksam werden? $ETH

Eine weitere oft übersehene Gruppe sind die Bitcoin-Miner. Die Einreichung von Checkpoints durch Babylon erhöht die Transaktionsmenge im Bitcoin-Netzwerk und bringt den Minern dadurch mehr Einnahmen aus Transaktionsgebühren. Eigentlich müssten Miner das begrüßen. Aber wenn das Babylon-Ökosystem zu groß wird und Checkpoint-Transaktionen einen beträchtlichen Teil des Blockraums einnehmen, steigen die Transaktionskosten für normale Nutzer. Diese könnten sich beschweren und dadurch entsteht dann möglicherweise öffentlicher Druck auf die Miner.

Das Ringen dieser Interessengruppen könnte im Entwicklungsprozess von Babylon unsichtbare Strömungen werden lassen. #baby

Ich möchte heute über ein Thema sprechen, das nur selten zur Sprache kommt: Babylons MEV-Risiken.$BABY

Viele glauben, dass es auf Bitcoin kein MEV gibt, weil Bitcoin nur begrenzte Smart-Contract-Fähigkeiten hat und nicht so wie Ethereum Front-Running und Sandwich-Angriffe ermöglicht. Doch das Auftreten von Babylon hat diese Situation verändert.

Wenn Babylon@BabylonLabs_io die Checkpoints einer PoS-Kette auf Bitcoin einreicht, können Validatoren auswählen, in welchem Block sie die Einreichung vornehmen und wann sie sie einreichen. Diese Wahlmöglichkeit der Zeit ist an sich schon eine Form von MEV. Wenn ein Validator gleichzeitig eine DeFi-Kette betreibt, kann er vorteilhafte Checkpoints priorisiert einreichen und nachteilige entsprechend verzögern.

Ein noch subtileres Risiko ist Cross-Domain-MEV. Zwischen den PoS-Ketten, die Babylon verbindet, können sich Arbitragegelegenheiten ergeben. Beispielsweise kann auf Kette A eine bestimmte Transaktion passieren. Validatoren auf Kette B können diese Information zuerst sehen und dann im Checkpoint-Einreichungsprozess von Babylon manipulieren, um daraus Profit zu schlagen.

Gibt es bei Babylon aktuell Schutzmaßnahmen gegen MEV? Ich habe mich umgesehen, und es scheint keine spezielle Gestaltung dafür zu geben. Ihre Hauptenergie steckt offenbar darin, die Kernfunktionen zum Laufen zu bringen; Probleme auf höherer Ebene wie MEV stehen noch nicht auf dem Plan.

Aber das heißt nicht, dass es unwichtig ist. Das MEV-Problem von Ethereum$ETH ist bis heute nicht vollständig gelöst; man muss es mit Randlösungen wie MEV-Boost abmildern. Wenn Babylon erst nach dem Wachstum des Ökosystems nachbessert, könnte es zu spät sein.

Ein weiterer Blickwinkel ist das Risiko der Zentralisierung von Validatoren. Validatoren in Babylon müssen sowohl Bitcoin-Node(n) als auch PoS-Knoten betreiben. Die technischen Anforderungen liegen damit deutlich höher als bei reinen PoS-Validatoren. Das könnte dazu führen, dass es weniger Validatoren gibt und sich die Macht stärker konzentriert. Wenn eine kleine Gruppe von Validatoren einmal kolludiert, wäre das für die Sicherheit des gesamten Netzwerks ein verheerender Schlag.

Diese Probleme werden derzeit zwar nicht von vielen diskutiert, aber ich glaube, dass sie für die langfristige Entwicklung von Babylon unvermeidliche Hürden sind.#baby

Ich schaue mir gerade den Code-Repository von @BabylonLabs_io an und habe eine ziemlich interessante Besonderheit entdeckt: Der Code-Stil sieht sehr ähnlich aus wie bei Projekten aus dem Cosmos-SDK-Umfeld, und es wird in großem Umfang die zugrunde liegende IBC-Library verwendet. Dadurch ist mir ein Fakt bewusst geworden, den viele übersehen – Babylon ist im Grunde ein Projekt im Cosmos-Ökosystem, nur dass es als Sicherheitslayer zufällig Bitcoin nutzt.

Was bedeutet das? Es bedeutet, dass die zukünftige Entwicklung von Babylon in hohem Maße davon abhängt, wie prosperierend das Cosmos-Ökosystem ist. Wenn ATOM nicht mehr funktioniert, wenn IBC von niemandem mehr genutzt wird – woher sollen dann die nachgelagerten Kunden für Babylon kommen?

Zurzeit loben alle, wie großartig Bitcoin-Staking sei, aber kaum jemand fragt: Warum sollten PoS-Chains überhaupt zu Babylon kommen, um sich Sicherheit mieten zu lassen? Könnten sie nicht einfach selbst ATOM oder DOT staken?

Die Antwort könnte in den Kosten liegen. Wenn du ATOM stakest, musst du zuerst ATOM kaufen und trägst damit das Risiko von Preisschwankungen bei ATOM. Wenn du Babylon nutzt, musst du nur BABY-Token bezahlen, und die Bitcoin-Inhaber haben die Sicherheitskosten bereits aufgefangen.

Aber die Voraussetzung ist, dass $BABY -Token selbst über genügend Liquidität verfügen müssen – weder zu teuer noch zu billig. Dieses Gleichgewicht ist schwer zu treffen.

Ein weiterer Punkt, den ich übersehen habe, ist die Regulierung. Die regulatorische Einordnung von Bitcoin in den USA ist inzwischen relativ klar, die Einstufung als Commodity ist im Grunde etabliert. Aber Babylon ist ein Protokoll, das auf Bitcoin Finanzprodukte aufbaut – wo liegt dort die Compliance-Grenze? Wenn die US-SEC entscheidet, dass Babylons Staking-Produkt als Wertpapier gilt, müsste die ganze Story neu geschrieben werden.

Diese Risiken werden derzeit kaum diskutiert; alle sind in der BTCFi-Erzähl-Feier versunken. Aber ich glaube, ob ein Projekt weit kommen kann, hängt nicht davon ab, wie gut es in seiner besten Phase ist, sondern davon, ob es die schlimmsten Zeiten überstehen kann. #baby

#baby $BABY Ich habe etwas Interessantes festgestellt: Babylon wird oft mit EigenLayer verglichen, aber ich glaube, dass es im Kern zwei völlig unterschiedliche Wege sind.

EigenLayer macht Re-Staking: Ethereum-Validatoren nehmen das bereits gestakte ETH heraus und schützen damit andere Netzwerke. Es stützt sich auf das Validatoren-Netzwerk von Ethereum – im Grunde auf die Wiederverwendung von Humankapital.

Babylon ist anders. Es nutzt den Proof-of-Work von Bitcoin, also Rechenleistung – nicht Humankapital. Die Bitcoin-Miner verbrauchen jeden Tag echte Stromkosten, um die Netzwerksicherheit aufrechtzuerhalten. Babylon bündelt diese Sicherheit zu einem Produkt und verkauft sie an andere Chains, die ebenfalls Sicherheit benötigen.

Das eine ist ein gemeinsamer Validator-Pool, das andere eine gemeinsame Rechenleistung. Klingt ähnlich, aber die zugrunde liegende Logik ist komplett verschieden.

Die Sicherheitsobergrenze von EigenLayer hängt von der Anzahl der Ethereum-Validatoren und den Annahmen über Ehrlichkeit ab. Die Sicherheitsobergrenze von Babylon hängt von der gesamten Rechenleistung des Bitcoin-Netzwerks ab. Die Größenordnung der Bitcoin-Rechenleistung ist ein Vielfaches des Gesamtwerts der bei Ethereum gestakten Validatoren – und sie wächst weiter.

Daher ist mein Fazit: In Bezug auf das Sicherheits-Potenzial hat Babylon vermutlich mehr Spielraum.

Aber es gibt auch klare Nachteile. Ethereum-Validatoren können flexibel auswählen, welche Netzwerke sie verifizieren; die Bitcoin-Rechenleistung kann nicht direkt angeleitet werden. Babylon kann sich daher nur indirekt durch Zeitstempel und Checkpoints „einhaken“. Das führt dazu, dass Babylon viel weniger Arten von Diensten anbieten kann als EigenLayer.

Eines kann komplexe Dinge tun, aber mit einer etwas niedrigeren Decke; das andere kann einfache Dinge tun, aber mit einer extrem hohen Decke. Beide haben ihre jeweiligen Einsatzszenarien.

$BABY #baby @BabylonLabs_io

#baby $BABY Ehrlich gesagt: Nachdem ich mir das Projekt Babylon einmal rund angeschaut habe, hat mich eigentlich vor allem die praktische Ausrichtung beeindruckt.

Viele Bitcoin-Layer-2-Projekte kommen sofort damit um die Ecke, dass sie den Konsenslayer von Bitcoin neu aufbauen wollen oder eine komplett neue virtuelle Maschine entwickeln möchten. Das klingt cool, aber wenn man genauer darüber nachdenkt: Die Stabilität von Bitcoin über zehn Jahre hinweg wurde von unzähligen Miner und Entwicklern gemeinsam gepflegt—nicht so, dass man das einfach mal eben umkonstruieren könnte.

Babylons Ansatz ist ein anderer. Es erkennt die Grenzen von Bitcoin an, rüttelt nicht am Kern von Bitcoin herum, sondern sucht innerhalb der bestehenden Regeln von Bitcoin nach Spielraum.

Die Skriptsprache von Bitcoin ist tatsächlich relativ simpel, die Möglichkeiten sind begrenzt. Aber Babylon hat erkannt, dass man mit grundlegenden Funktionen wie Time-Locks und Multisignaturen bereits genug hat, um ein ganzes Staking-Framework aufzubauen. Kein Hard Fork, keine Sidechains, keine Änderungen an Bitcoin selbst.

Diese Haltung schätze ich sehr. Babylon will Bitcoin nicht „umbauen“, sondern Bitcoin „anpassen“.

Natürlich hat diese pragmatische Herangehensweise auch einen Preis in Form von Kompromissen bei der Funktionalität. Babylon kann nicht so viel: Es beschränkt sich im Wesentlichen auf drei Dinge—Staking, Verifizierung und Abrechnung. Es wird nicht wie Ethereum dabei unterstützen, verschiedene komplexe Smart-Contract-Interaktionen abzuwickeln.

Wenn man es aber aus einer anderen Perspektive betrachtet: Vielleicht braucht Bitcoin gar kein Allzweck-Layer-2, sondern ein Protokoll, das eine Sache richtig gut bis zum Maximum umsetzt. Babylon hat sich dafür entschieden, „sichere Vermietung“ (Security Leasing) wirklich gut zu machen—und ich finde, die Richtung ist richtig.

@BabylonLabs_io $ETH