Ich dachte, die geschichtete Architektur sei für Modularität. Die Dokumentation von Babylon hat meine Meinung geändert.

Die Dokumentation ist klar geschrieben. Die Architektur besteht aus vier Ebenen. Das Bitcoin-Skript ganz unten ist für die Staking-Logik zuständig. Die Gelder werden in einem Taproot-Skript gesperrt. Die Babylon-Knoten liegen in der Mitte. Das Cosmos SDK baut den Stack auf und koordiniert Staking und Finalität. Ein Finality-Provider liegt auf einer höheren Ebene. Er nutzt EOTS-Signaturen für Abstimmungen. Software am Rand ganz außen übernimmt Monitoring, Relaying und Indexing.

Ich frage mich, warum das so stark aufgeteilt ist. Warum nicht ein großes System bauen.
Je mehr ich darüber nachdenke, desto mehr glaube ich: Diese Schichtung dient nicht nur der Modularität. Sie reduziert auch den Umfang des erforderlichen Vertrauens für jede Ebene. Jede Ebene erledigt genau eine Aufgabe. Selbst wenn die Babylon-Chain vorübergehend nicht verfügbar ist, bleiben die gestakten Gelder durch das Bitcoin-Skript kontrolliert. Wenn ein Finality-Provider nachweisbar eine doppelte Signatur ausführt, kann das Protokoll das erkennen und einen Prozess für die Slashing-/Beschlagnahme auslösen. Wenn die Außen-Software ausfällt, laufen Finalitätsabstimmungen weiter.
Das ist keine Modularität. Das ist Kontrolle der Explosions-/Bruchradius: Wenn eine Ebene explodiert, laufen die anderen weiter.

Doch der Preis ist ebenfalls offensichtlich. Vier Ebenen bedeuten mehr Komponenten, die koordiniert und gewartet werden müssen. Vier mögliche Ausfallstellen. Vier Teile, die überwacht werden müssen.

#baby $BABY @BabylonLabs_io

Ist Schichtung für Sicherheit da – oder um Verantwortung zu verteilen?