Chainlink hat die Version 2.0 seines Cross-Chain Interoperability Protocol (CCIP) veröffentlicht und darin Cross-Chain Verifier, neue Token-Pool-Funktionen sowie konfigurierbare Finalitätseinstellungen eingeführt, wie aus den Release Notes des Projekts hervorgeht. Eine ergänzende Sicherheitsübersicht erläutert die umfassendere Architektur, in die diese Funktionen eingebettet sind. CCIP, das Nachrichten und Tokens zwischen Blockchains überträgt, die den Zustand der jeweils anderen nicht nativ lesen können, baut auf dem Werk eines Projekts auf, das vor allem für seine Oracle-Infrastruktur im dezentralen Finanzwesen bekannt ist.

Insgesamt ermöglichen die Änderungen Token-Emittenten, zusätzliche Prüfungen zu verlangen, bevor ein Cross-Chain-Transfer genehmigt wird, und verschiedene Assets können unter unterschiedlichen Sicherheits- und Finalitätseinstellungen laufen. Benutzerdefinierte Verifizierung verlagert mehr Verantwortung auf den Emittenten, schnellere Routen können auf anderen Annahmen zur Finalität beruhen, und Nutzer müssen die konkrete Token-Route bewerten und nicht allein die Bridge-Marke.

Was sich geändert hat

Man kann sich einen Bridge-Transfer als Tor zwischen zwei Blockchains vorstellen. Bevor sich das Tor öffnet, muss jemand bestätigen, dass das Asset auf der anderen Seiteperrt oder vernichtet wurde. CCIP 2.0 lässt den Token-Emittenten entscheiden, welche zusätzlichen Prüfungen diese Behauptung bestätigen sollen. Ein Stablecoin, ein tokenisierter Fonds und ein krypto-nativer Token könnten daher jeweils unterschiedlichen Regeln folgen, bevor eine Cross-Chain-Version ausgegeben wird.

Cross-Chain-Transfers beruhen auf einer Entscheidung, der vertraut werden muss

Ein Cross-Chain-Transfer umfasst in der Regel mehr, als einen Token von einer Adresse auf eine andere zu bewegen. Ein Asset kann in einem Netzwerk gesperrt oder dort aus dem Umlauf entfernt werden, bevor eine entsprechende Version auf einer anderen Chain verfügbar wird. Der schwierige Teil besteht darin zu bestätigen, dass das erste Ereignis tatsächlich stattgefunden hat und dass die Ziel-Chain darauf reagieren sollte.

Ein Versagen dieses Entscheidungsprozesses kann schwerwiegende Probleme verursachen: Ein gültiger Nutzertransfer kann verzögert werden, oder eine ungültige Nachricht könnte dazu führen, dass Tokens freigegeben werden, obwohl sie es nicht sein sollten.

CCIP bietet bereits ein System zum Übertragen und Verifizieren von Cross-Chain-Nachrichten. Version 2.0 fügt eine Möglichkeit hinzu, mit der Token-Pools eine weitere Verifizierung verlangen können, bevor sie einen Transfer abschließen. Das gibt Emittenten mehr Flexibilität, macht aber auch die Konfiguration rund um eine Token-Route wichtiger.

Emittenten können eigene Verifizierungsregeln hinzufügen

CCIP 2.0 führt Cross-Chain Verifier (CCVs) ein — zusätzliche Verifizierungskomponenten, die neben dem bestehenden Sicherheitsprozess von CCIP eingesetzt werden können. Bemerkenswert ist, dass ein Projekt keine Zustimmung von Chainlink benötigt, bevor es einen zusätzlichen Verifier entwickelt oder nutzt. Diese Offenheit gibt Emittenten mehr Spielraum, eine Route an ihren eigenen Anforderungen auszurichten, verlagert aber auch mehr Verantwortung auf sie, den gewählten Verifier zu bewerten.

Ein Token-Pool kann festlegen, welche CCVs einen Transfer genehmigen müssen. Ein Emittent könnte einen zusätzlichen Nachweis verlangen, dass ein Asset auf der Ursprungs-Chain gesperrt wurde. Ein anderer könnte eine Compliance-bezogene Bedingung oder eine unabhängige Bestätigung durch ein separates System verlangen. Ein solcher Verifier kann Nachweise auf verschiedene Weise veröffentlichen, von signierten Daten und APIs bis hin zu kryptografischen Beweisen.

Der entscheidende Punkt für Nutzer ist, dass CCIP nicht entscheidet, welchen Nachweisen eine bestimmte Token-Route vertrauen muss. Der Unterschied ist praktisch: Eine Cross-Chain-Version eines Tokens folgt möglicherweise nicht mehr exakt demselben Genehmigungsprozess wie ein anderes Asset, das CCIP nutzt, und das Sicherheitsmodell der Route kann von den eigenen Entscheidungen des Emittenten abhängen.

Schnellere Ausführung ist optional

Das Update umfasst auch konfigurierbare Finalitätseinstellungen, darunter eine optionale Funktion namens Faster Than Finality. Blockchains erreichen Finalität nicht alle auf dieselbe Weise. Manche Transaktionen können bestätigt erscheinen, bevor Netzwerk den Punkt erreicht hat, an dem eine Reorganisation höchst unwahrscheinlich wird. Längeres Warten kann die Sicherheit erhöhen, kann aber auch einen Cross-Chain-Transfer verlangsamen.

CCIP 2.0 gibt den beteiligten Teilen einer Route die Option, einen früheren Bestätigungspunkt zu verwenden. Die Release Notes machen deutlich, dass diese Einstellung über alle relevanten Komponenten — Sender, Pool, Verifier, Executor und Receiver — hinweg unterstützt werden muss. Eine schnellere Route kann daher von anderen operativen Annahmen ausgehen als eine, die wartet, bis die Quell-Chain-Transaktion ihre übliche Finalitätsschwelle erreicht. Wenn diese Komponenten inkonsistent konfiguriert sind, warnen die Release Notes, könnten eine Nachricht und ihre Token-Inhalte hängen bleiben.

Mehr Prüfungen helfen nur, wenn sie nicht dieselbe Schwäche teilen

Das Hinzufügen von Verifiern macht eine Bridge-Route nicht automatisch sicherer. Die Qualität der Anordnung hängt davon ab, was jede Prüfung verifiziert und ob die Systeme hinter diesen Prüfungen tatsächlich unabhängig sind. So können beispielsweise zwei Verifier getrennt erscheinen, während sie auf dieselbe Datenquelle, denselben Betreiber oder denselben Off-Chain-Dienst zurückgreifen. Fällt diese gemeinsame Abhängigkeit aus, können beide Prüfungen zur selben falschen Schlussfolgerung gelangen.

Entscheidend ist, ob jede Prüfung aus einem anderen Grund fehlschlagen kann. Deshalb bietet das Release den Emittenten Flexibilität statt einer universellen Sicherheitsgarantie. Eine sorgfältig gestaltete Route kann nützliche unabhängige Kontrollen hinzufügen, während eine schlecht gestaltete Komplexität hinzufügen kann, ohne das Kernrisiko zu verringern.

CCIP 2.0 liefert den Rahmen für diese Prüfungen. Der Emittent muss weiterhin entscheiden, welche Regeln gelten, wie sein Code funktioniert und wer ihn später ändern kann.

Warum Emittenten-Kontrollen über DeFi hinaus wichtig sind

Denselben Designentscheidungen kommt ein höheres Gewicht zu, wenn ein Token etwas über eine gewöhnliche DeFi-Position hinaus repräsentiert. Ein Stablecoin-Emittent kann andere Bedingungen benötigen als ein Protokoll, das einen krypto-nativen Governance-Token überträgt. Ein tokenisierter Fonds könnte Transferbeschränkungen, Identitätsprüfungen oder die Genehmigung des Emittenten unter bestimmten Umständen verlangen. Institutionen bevorzugen möglicherweise zudem Systeme, die die Regeln rund um ein Cross-Chain-Asset leichter definierbar und prüfbar machen.

Wie eine frühere Coindoo-Analyse von Zentralbank-Tests mit Chainlink feststellte, wird Cross-Chain-Infrastruktur sowohl für tokenisierte Finanzabläufe als auch für krypto-native Transfers erforscht.

CCIP 2.0 zeigt nicht, dass eine bestimmte Institution bereits einen benutzerdefinierten Verifier übernommen hat. Es gibt einem Emittenten die technische Option, zusätzliche Bedingungen um seine eigene Cross-Chain-Route zu legen. Das könnte Protokoll für Assets nützlicher machen, die sich nicht auf einen einzelnen, einheitlichen Regelsatz stützen können. Es bedeutet auch, dass Nutzer je nach gehaltenem Token auf unterschiedliche Beschränkungen und Risiken stoßen können.

Was Nutzer prüfen sollten, bevor sie eine Cross-Chain-Route nutzen

Das Update macht es schwieriger, einen Transfer allein anhand der Frage zu beurteilen, ob er einen bekannten Bridge-Anbieter nutzt. Bevor ein Token zwischen Chains bewegt wird, sollten Nutzer Folgendes prüfen:

• Wer kontrolliert den Token-Pool: der Emittent, ein Protokoll-Team oder ein separates Governance-System.
• Ob die Route zusätzliche Verifier nutzt und auf welche Nachweise sich diese Verifier stützen.
• Ob schnellere Finalität aktiviert ist, da eine kürzere Wartezeit mit anderen operativen Annahmen einhergehen kann.
• Wer die Konfiguration ändern kann, einschließlich Verifier-Anforderungen, Pausierrechten und Upgrade-Befugnissen.
• Ob der Ziel-Token dieselben Einlösungs- und Transferrechte besitzt wie die Version auf der Ursprungs-Chain.

Diese Fragen bedeuten nicht, dass jede benutzerdefinierte Route unsicher ist. Sie helfen zu erklären, warum das Wort „bridged“ sehr unterschiedliche Systeme beschreiben kann.

Ein Bridge-Anbieter ist nur ein Teil der Sicherheitsarchitektur

CCIP 2.0 spiegelt eine umfassendere Entwicklung im Cross-Chain-Design wider. Bridge-Infrastruktur dreht sich weniger darum, einen festen Prozess auf jeden Token anzuwenden, sondern vielmehr darum, Emittenten Werkzeuge zu geben, um zu definieren, wie ihre Assets zwischen Netzwerken reisen. Das kann dort nützlich sein, wo verschiedene Assets unterschiedliche rechtliche, technische oder operative Anforderungen mitbringen. Der Nachteil ist, dass Nutzer klarere Informationen über die Regeln benötigen, die an die genutzte Route gebunden sind.

Die Bedeutung des Upgrades wird sichtbar werden, wenn man betrachtet, wie Routen tatsächlich konfiguriert werden — welche Emittenten benutzerdefinierte Verifier hinzufügen und wie viele schnellere Finalität aktivieren —, da diese Entscheidungen pro Token und nicht von Chainlink für das Protokoll als Ganzes getroffen werden.

Für Nutzer ist die praktische Änderung einfach: Der Bridge-Anbieter ist nur ein Teil des Sicherheitsbildes, und die Genehmigungsregeln der konkreten Token-Route verdienen dieselbe Prüfung.

Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Finanz- oder Anlageberatung dar. Cross-Chain-Transfers beinhalten Smart-Contract-, operationale und Liquiditätsrisiken.

Ursprünglich veröffentlicht von Coindoo.