ChainLink

Chainlink (ursprünglich ChainLink) ist eine Blockchain-Orakel-Plattform, die dezentrale Orakel-Netzwerke umfasst. Diese Netzwerke liefern Daten und Berechnungsergebnisse zwischen Blockchains und externen Systemen, so dass Smart Contracts Informationen verwenden können, die in ihrem eigenen Blockchain-Zustand nicht verfügbar sind. Das Projekt wurde von SmartContract.com, dem Unternehmen, das jetzt als Chainlink Labs bekannt ist, eingeführt.

Ein Orakel macht eine externe Tatsache nicht selbst zum Konsens einer Blockchain. Stattdessen liefert es eine Eingabe, für die ein Vertrag programmiert wurde. Das Design von Chainlink versucht, die Abhängigkeit von einem einzelnen Orakel zu reduzieren, indem mehrere Knotenoperatoren und gegebenenfalls mehrere Datenquellen kombiniert werden.

Geschichte

Sergey Nazarov und Steve Ellis gründeten SmartContract.com im Jahr 2014, um externe Daten und öffentliche Blockchains zu verbinden. Ellis, Nazarov und der Cornell-Informatiker Ari Juels veröffentlichten im September 2017 das erste Chainlink-Whitepaper. Es beschrieb On-Chain-Verträge zur Auswahl von Oracle-Knoten, Berichtsdaten und Aggregationsergebnissen sowie von Oracle-Betreibern ausgeführte Off-Chain-Software.

Das Projekt schuf eine feste Versorgung von einer Milliarde LINK. In seinem Token-Verkauf im September 2017 verkaufte das Unternehmen 350 Millionen LINK für etwa 32 Millionen $; weitere 350 Millionen waren für Knotenbetreiber und Ökosystemanreize reserviert, und 300 Millionen wurden dem Unternehmen zugewiesen. Diese Zuweisungen beschreiben die anfängliche Verteilung, nicht die Anzahl der zu einem späteren Zeitpunkt zirkulierenden Token.

Das Chainlink-Netzwerk startete im Mai 2019 auf Ethereum mit einem ETH/USD-Preis-Feed. Sein Anwendungsbereich wurde später über Marktdatenfeeds hinaus auf andere Oracle-Dienste und kettenübergreifende Kommunikation ausgeweitet. Ein zweites Whitepaper aus dem Jahr 2021 verwendete den weiter gefassten Begriff dezentralisiertes Orakelnetzwerk für Gruppen von Knoten, die Datenbereitstellung und Off-Chain-Berechnungen für sogenannte hybride Smart Contracts übernehmen können.

Chainlink wurde auch für Umgebungen außerhalb von Ethereum angepasst. Im Jahr 2020 demonstrierte das Polkadot-Projekt eine erste Chainlink-Integration mit einer Substrate-basierten Blockchain. Dieses Experiment ist nicht damit gleichzusetzen, dass Chainlink eine native Polkadot-Parachain ist.

Architektur

Blockchains erfordern normalerweise, dass jeder validierende Knoten das gleiche Ergebnis aus einer Transaktion erhält. Ein Vertrag kann daher nicht direkt eine willkürliche Webanfrage stellen und deterministisch bleiben. Ein Orakelsystem überbrückt diese Grenze, indem es Informationen außerhalb der Kette erhält und ein Ergebnis veröffentlicht, das ein On-Chain-Vertrag lesen kann.

Im ursprünglichen Chainlink-Design legt ein anfordernder Vertrag Anforderungen für einen Orakelauftrag fest. On-Chain-Verträge helfen, Knotenoperatoren auszuwählen, ihre Berichte zu erhalten und die Antworten zu aggregieren. Die Off-Chain-Knoten erhalten die angeforderten Daten, formatieren sie und übermitteln signierte Ergebnisse. Verschiedene Bereitstellungen können unterschiedliche Knotensätze, Datenquellen, Aggregationsregeln und Aktualisierungsbedingungen verwenden, sodass „Chainlink“ nicht ein einheitliches Vertrauensmodell für jeden Feed oder Dienst bezeichnet.

Spätere Chainlink-Designs verwenden Off-Chain-Berichte, bei denen eine Gruppe von Knoten Off-Chain kommuniziert und einen aggregierten Bericht On-Chain einreicht. Dadurch wird die Anzahl der On-Chain-Transaktionen reduziert, während signierte Beiträge beibehalten werden, die gemäß dem Protokoll überprüft werden können.

Services

Die Plattform wurde für verschiedene verwandte Arten von Orakeldiensten verwendet:

• Daten-Feeds veröffentlichen Werte wie Asset-Preis-Referenzdaten für zu lesende Verträge.
• Request-and-Response-Dienste geben von einer Anwendung angeforderte Daten oder Berechnungen zurück.
• Mit Automation können registrierte Vertragsfunktionen aufgerufen werden, wenn konfigurierte Bedingungen erfüllt sind.
• Verifizierbare Zufälligkeit liefert Ergebnisse zusammen mit einem kryptografischen Nachweis für Anwendungen, die unvorhersehbare Ergebnisse erfordern.
• Kettenübergreifendes Messaging überträgt Nachrichten und Token-Übertragungsanweisungen zwischen unterstützten Blockchain-Netzwerken.

Diese Dienste teilen Branding und Infrastruktur, haben aber unterschiedliche Protokolle, Knotenkonfigurationen und Sicherheitsannahmen. Die Verfügbarkeit auf einer Kette oder für einen Datenfeed bedeutet nicht, dass jeder Chainlink-Dienst in jedem Netzwerk verfügbar ist.

Cross-Chain Interoperability Protocol

Chainlinks Cross-Chain Interoperability Protocol (CCIP) unterstützt Nachrichten, Token-Transfers oder Nachrichten in Verbindung mit Token-Transfers zwischen unterstützten Netzwerken. Verbindungen sind als gerichtete Lanes organisiert; die Unterstützung eines Netzwerks bedeutet nicht, dass jeder Vermögenswert oder jede Route verfügbar ist. CCIP trat am 17 Juli 2023 auf Avalanche, Ethereum, Optimism und Polygon in den Mainnet-Early-Access ein.

Token-Pools setzen den asset-spezifischen Transfermechanismus um: Token können auf der Quell-Chain gesperrt oder verbrannt und auf der Ziel-Chain freigegeben oder geprägt werden. Ein Transfer hängt daher von den betreffenden Pools und Token-Berechtigungen ab; ein Token wird nicht physisch zwischen Blockchains bewegt. Nachrichten werden asynchron verarbeitet: Auf die Übermittlung auf der Quell-Chain folgen Verifizierung und Ausführung auf der Ziel-Chain. Die Annahme auf der Quell-Chain belegt für sich genommen nicht, dass die Zielanwendung ihren Vorgang abgeschlossen hat.

CCIP 2.0

Chainlink kündigte CCIP 2.0 am 28 September 2026 an. Die Ankündigung führte konfigurierbare Cross-Chain-Verifier (CCVs) ein, darunter eine Verifizierung durch den Emittenten oder Dritte, optionale Ausführung vor der Finalität und vom Emittenten festgelegte Richtlinien über die Automated Compliance Engine (ACE). Dies sind Konfigurationsoptionen und kein Beleg dafür, dass jeder unterstützte Vermögenswert zusätzliche Verifizierung nutzt oder ein Transfer eine bestimmte rechtliche Anforderung erfüllt. Unabhängige Berichte bestätigten die Veröffentlichung und unterschieden bestehende CCIP-Nutzer von Anwendern der neuen Funktionen.

Die Dokumentation nennt vollständige Finalität der Quell-Chain, den Chainlink Committee Verifier und den Chainlink Executor als Standardeinstellungen. Bestehende Integrationen übernehmen die neuen optionalen Funktionen nicht automatisch.

Anwendungen der Tokenisierung

CCIP wurde als Interoperabilitätsschicht für tokenisierte Finanzwerte und zugehörige Daten getestet. Im Jahr 2023 berichtete Swift über Experimente zur Verbindung seiner Infrastruktur mit Blockchains, darunter das Ethereum-Sepolia-Testnetz, mithilfe von Chainlink und CCIP. Im Mai 2024 berichtete DTCC über das Smart-NAV-Pilotprojekt mit zehn Marktteilnehmern, bei dem CCIP Nettoinventarwertdaten von Investmentfonds zwischen Blockchain-Umgebungen verteilte. Dies war ein Pilotprojekt zur Datenverteilung und kein Bericht über tatsächliche Fondsübertragungen. Diese Projekte zeigen experimentelle Anwendungen; sie belegen weder einen allgemeinen kommerziellen Einsatz noch eine allgemeine Übernahme von CCIP 2.0.

LINK-Token

LINK ist ein mit ERC-20 kompatibler Ethereum-Token, der in Teilen des Chainlink-Systems verwendet wird. Das ursprüngliche Whitepaper beschreibt Zahlungen von anfragenden Contracts an Node-Betreiber und Sicherheitsleistungen, die Fehlverhalten entgegenwirken sollen. Spätere Designs verwenden LINK auch in Staking-Mechanismen. Die Rolle des Tokens hängt vom Dienst und der Protokollversion ab; LINK zu besitzen verschafft weder Eigentum an externen Daten noch eine Garantie für die Richtigkeit einer Orakelantwort.

Vertrauens- und Sicherheitsüberlegungen

Die Dezentralisierung eines Orakels kann das Risiko verringern, dass ein Operator ausfällt oder einen falschen Wert übermittelt, kann aber nicht nachweisen, dass eine externe Quelle korrekt ist. Ein Vertrag kann immer noch scheitern, weil seine Datenquellen falsch oder manipuliert sind, zu wenige unabhängige Knoten verwendet werden, Aggregationsregeln ungeeignet sind, Aktualisierungen verzögert werden oder der verbrauchende Vertrag einen gültigen Bericht falsch behandelt.

Oracle-Benutzer müssen daher die Quelle der Daten, die Knoten- und Quellendiversität, die Aktualisierungsrichtlinie, die Aggregationsmethode, die Vertragsadressen und das Ausfallverhalten des genauen von ihnen verwendeten Dienstes bewerten. Smart-Contract-Code und Oracle-Konfiguration sind separate Sicherheitsgrenzen.

CCIP-Sicherheitsannahmen

Wie im Oktober 2026 dokumentiert, verwendet der standardmäßige Committee Verifier von CCIP 2.0 ein Netzwerk aus 16 Betreibern und verlangt mindestens neun signierte Attestierungen. Die tatsächlichen Verifier-Anforderungen hängen von Lane, Token-Pool sowie der Konfiguration von Empfänger und Sender ab. Lane-Standards dienen als Rückfalloptionen; für eine Lane vorgeschriebene Verifier sind immer erforderlich. Die Ausführung auf der Ziel-Chain erfordert alle erforderlichen Verifier und den konfigurierten Schwellenwert optionaler Verifier. Ein zusätzlicher CCV liefert nur dann eine erforderliche Prüfung, wenn die anwendbare Konfiguration sie verlangt; eine nicht verfügbare erforderliche Attestierung kann die Ausführung ebenfalls verzögern. Die Beschreibung des Standardkomitees ist daher keine vollständige Darstellung des Vertrauensmodells jeder benutzerdefinierten Integration.

Die vollständige Finalität der Quell-Chain bleibt der Standard. Faster-Than-Finality ist optional und erlaubt eine Ausführung mit weniger Bestätigungen, wodurch die Anfälligkeit für Reorganisationen der Quell-Chain steigt. Je nach Transfermechanismus können die dokumentierten Folgen doppelte Ausführungen, nicht gedeckte Token, eine Ausweitung des Angebots oder finanzielle Verluste umfassen.

Auch Versionsunterschiede sind relevant. Die CCIP2.0-Architektur behält einen On-Chain-RMN-Contract und Proxy für Notstopps bei: Betroffene Vorgänge werden zurückgewiesen, wenn das betreffende Subjekt als „cursed“ markiert ist. Diese Schutzmaßnahme unterscheidet sich vom separaten Off-Chain-Risk-Management-Network, das für frühere CCIP-Versionen beschrieben wurde.

Tokenverwaltung, Pool-Berechtigungen, benutzerdefinierte Verifier und der Code der empfangenden Anwendung schaffen weitere Abhängigkeiten. Laut dem Leitfaden für Token-Emittenten fallen benutzerdefinierte Pools nicht unter Chainlink-Audits und müssen unabhängig geprüft werden. Änderungen an der von CCIP verwalteten Konfiguration durchlaufen ein Multisignatur- und rollenbasiertes Timelock-Verfahren mit einer Prüf- und Vetoverzögerung oder einem Pfad mit explizitem Quorum für dringende Änderungen; eine zwingende Verzögerung kann nicht für jede Änderung vorausgesetzt werden. Protokolldokumentation und frühere Audits belegen nicht die Sicherheit einer bestimmten bereitgestellten Konfiguration oder Anwendung.

Externe Links

• Official website
• Chainlink software repository
• Developer documentation