Modular ist derzeit ein beliebter Begriff in Web3, den eine Reihe von Protokollen und Projekten zur Selbstbeschreibung verwenden. Celestia hat den Begriff durch die Einführung des Konzepts der modularen Blockchains populär gemacht. Unser Ziel ist es, den Fokus und die Verwendung des Begriffs auf eine sehr spezifische Definition der modularen Interoperabilität einzugrenzen. Außerdem stellen wir ein Framework zum Nachdenken und Bewerten modularer Blockchains und Interoperabilitätsprotokolle vor.

Blockchain-Protokolle aufschlüsseln

Es gibt einige zusammensetzbare Schichten im modularen Blockchain-Stack:

• Datenverfügbarkeit (DA)
• Sequenzierung oder Transaktionsbestellung (TO)
• Ausführung
  – Abwicklung

Beachten Sie, dass der Konsens hier nicht enthalten ist, da er in jede der oben genannten Schichten gebündelt werden kann, um die Überprüfung eines Konsensnachweises zu ermöglichen, anstatt die Regeln der Funktionsschicht direkt zu überprüfen.

Beispielsweise könnte man ein Single-Node-Rollup auf Celestia Sans Consensus aufbauen, das sich auf Betrugsnachweise stützt, um Dritte von der Richtigkeit zu überzeugen. Dies würde man als optimistisches Rollup bezeichnen. Wenn wir den Betrugsnachweis gegen einen Zero-Knowledge-Beweis (ZK) austauschen, erhalten wir ein ZK-Rollup. Wenn wir einen Konsens hinzufügen, können wir stattdessen den Konsensbeweis verwenden, um einen Dritten von der Richtigkeit zu überzeugen. Dies würde als pessimistisches Rollup bezeichnet werden.

Interoperabilitätsprotokolle aufschlüsseln

Ein vollständiges Interoperabilitätsprotokoll besteht aus drei klar definierten Schichten mit klarer Trennung dazwischen.

Eine einfache Definition jeder Interoperabilitätsschicht:

• Anwendung: Was bedeuten Datenpakete?
• Transport: Wie übersetzen wir den Zustand der anderen Kette in App-<>App-Konversationen und Datenpakete?
• Zustand: Wie erfahren Blockchains den Zustand der anderen?

Definition modularer Interoperabilität

Da der Begriff „modular“ oft verwendet wird und in vielen Kontexten relevant ist, werden wir versuchen, unsere Definition eines modularen Interoperabilitätsprotokolls mit den oben definierten Schichten sowie Celestias Definition einer modularen Blockchain in Verbindung zu bringen. Celestia definiert eine modulare Blockchain als eine Blockchain, die mindestens eine Funktionsschicht vollständig an eine externe Kette auslagert. Wir definieren ein modulares Interoperabilitätsprotokoll als eines, das die Transportschicht vollständig auslagert.

Der Hauptunterschied zwischen den beiden besteht darin, dass die definierende Schicht für Interoperabilitätsprotokolle die Transportschicht ist . Die Analogie hier am Beispiel des OSI-Modells besteht darin, dass Sie ein völlig anderes Netzwerkprotokoll erhalten, wenn Sie TCP/UDP durch ein anderes Transportprotokoll ersetzen. Außerdem kann die Zustandsschicht auf verschiedene Weise eingerichtet werden und definiert kein eindeutiges Interoperabilitätsprotokoll (z. B. Light Clients, Zero-Knowledge-Beweise, optimistische Betrugsbeweise usw.). Die Logik der Anwendungsschicht kann auch verallgemeinert werden und macht ein Interoperabilitätsprotokoll nicht mit einem anderen kompatibel. Wenn beispielsweise der IBC-Transport gegen eine andere Transportschicht ausgetauscht wird, ist das neue Protokoll nicht mit IBC-fähigen Ketten kompatibel .

Die staatliche Schicht kann auch teilweise ausgelagert werden, aber Outsourcing allein macht das Protokoll nicht modular, da es nicht die definierende Schicht von Interoperabilitätsprotokollen ist. Es gilt als vollständig in der Kette, wenn jede Kette direkt die Light-Client-Logik ihres Gegenstücks ausführt. Die Zustandsschicht wird als teilweise in der Kette betrachtet, wenn die Light-Client-Logik außerhalb der Kette ausgeführt und in der Kette mithilfe von ZK-Beweisen (Zero Knowledge) überprüft wird oder wenn ein vertrauenswürdiger Dritter verwendet wird.

Außerdem hat die Modularisierung monolithischer Ketten Auswirkungen auf die Zustandsschicht von Interoperabilitätsprotokollen. Beispielsweise kann eine einzelne logische Kette nicht mehr durch einen einzelnen Light-Client dargestellt werden, da der Nachweis verschiedener Funktionsschichten nun aus mehreren Ketten stammt.

Polymer der IBC Transport Hub

Polymer entwickelt das erste wirklich modulare Interoperabilitätsprotokoll , das die Transportschicht vollständig und die Zustandsschicht teilweise auslagert. Wie im Diagramm unten zu sehen ist, läuft die IBC-Transportschicht auf Polymer, während die IBC-App-Schicht auf der IBC-aktivierten Kette läuft. Mit diesem Design ist die Aktivierung von IBC in einer neuen Kette mit Polymer so einfach wie die Bereitstellung eines Roll-Ups auf Celestia . Polymer lagert die Statusschicht teilweise aus, indem es zk-IBC-Verbindungen verwendet, um eine Verbindung zu neu IBC-aktivierten Ketten herzustellen, während der zk-Verifizierer in der Kette sitzt (der Einfachheit halber im Diagramm oben nicht dargestellt).

Lasst uns gemeinsam bauen

Lassen Sie uns eine Zukunft aufbauen, in der IBC das Standard-Interoperabilitätsprotokoll für alle Ketten ist. Ideen zur Verbesserung des IBC sind jederzeit willkommen. Kommen Sie und chatten Sie mit uns auf Discord . Wir stellen auch ein . Innovation beschleunigt sich, wenn wir alle zusammenarbeiten!

Vielen Dank für die Gespräche, Jim (Catalyst) und Josh (Astria)!

Über Polymer

Polymer glaubt an eine Multichain-Zukunft, die vor allem durch einen Open-Source-, von der Community entwickelten und gepflegten Industriestandard, IBC x Polymer, verbunden ist. Polymer ist der erste IBC-Transportknotenpunkt, der sich auf die Ausweitung von IBC auf alle Ketten konzentriert. Der Polymer-Hub integriert die IBC-Transportschicht mit verbundenen Ketten. Auf der Statusebene werden ZK-IBC-Verbindungen zu allen integrierten Ketten geöffnet. Hierbei handelt es sich um eine vertrauensminimierte Architektur, die auf einer leichten Überprüfung des Clientstatus basiert.

Folgen Sie unserem Twitter , besuchen Sie unsere Website und treten Sie unserer Community auf Discord bei !