Oracle-Typen im Vergleich: Push, Pull und First-Party

Definition

Blockchain-Smart Contracts sind von Natur aus von der Außenwelt isoliert und operieren deterministisch, basierend ausschließlich auf den Daten, die auf ihrer nativen Blockchain gespeichert sind. Um mit realen Ereignissen, Marktpreisen oder jeglichen Off-Chain-Informationen zu interagieren, benötigen sie eine Brücke. Diese Brücke ist als Blockchain-Oracle bekannt.

Ein Blockchain-Oracle ist ein Drittanbieterdienst, der Smart Contracts mit realen Daten und Off-Chain-Systemen verbindet und es ihnen ermöglicht, basierend auf externen Informationen zu agieren, die nativ nicht auf der Blockchain verfügbar sind.

Oracles fungieren als Datenlieferanten, die Informationen aus externen Quellen abrufen und sie Smart Contracts auf verifizierbare Weise zur Verfügung stellen. Ohne Oracles wäre der Nutzen von Smart Contracts stark eingeschränkt und würde sie auf rein On-Chain-Operationen beschränken. Die Methode, mit der diese Daten geliefert werden, und die für ihre Bereitstellung verantwortliche Entität definieren die verschiedenen Arten von Oracles, die hauptsächlich in Push-, Pull- und First-Party-Modelle unterteilt werden, jedes mit unterschiedlichen operativen Merkmalen und Implikationen für dezentrale Anwendungen.

Kernaussage

Der grundlegende Unterschied zwischen den Oracle-Typen liegt in ihrem Datenliefermechanismus und der Vertrauensquelle. Push-Oracles senden Daten proaktiv in vordefinierten Intervallen oder bei Erfüllung spezifischer Bedingungen an die Blockchain, wodurch eine konsistente Verfügbarkeit für kritische Anwendungen gewährleistet wird. Pull-Oracles hingegen stellen Daten nur auf explizite Anforderung eines Smart Contracts oder Benutzers bereit, was Effizienz für weniger häufig benötigte Daten bietet. First-Party-Oracles stellen ein Modell dar, bei dem der Datenanbieter oft der dApp-Entwickler oder eine direkte, vertrauenswürdige Entität ist, im Gegensatz zur Drittanbieter-Natur vieler Push- und Pull-Oracle-Netzwerke. Jedes Modell bietet einzigartige Kompromisse hinsichtlich Datenaktualität, Kosten, Sicherheit und Dezentralisierung, sodass ihre Auswahl von den spezifischen Anforderungen der dezentralen Anwendung abhängt.

Mechanik

Die operativen Mechanismen von Push-, Pull- und First-Party-Oracles unterscheiden sich erheblich und beeinflussen ihre Eignung für verschiedene Blockchain-Anwendungsfälle.

Push-Oracles arbeiten nach einem proaktiven Modell. Daten werden in regelmäßigen Abständen oder wenn vordefinierte Bedingungen erfüllt sind, wie eine signifikante Preisabweichung oder ein bestimmter Zeit-Heartbeat, auf die Blockchain übertragen. Dies bedeutet, dass das Oracle-Netzwerk Off-Chain-Datenquellen aktiv überwacht und bei Erkennung eines relevanten Updates eine Transaktion initiiert, um die neuen Daten On-Chain zu speichern. Ein Chainlink-Preis-Feed für ETH/USD könnte beispielsweise bei jeder Preisänderung von 0,5 % oder jede Stunde aktualisiert werden, je nachdem, was zuerst eintritt. Der Vorteil dieses Modells ist, dass Daten konsistent On-Chain verfügbar sind und von jedem Smart Contract sofort genutzt werden können, ohne eine explizite Anforderung. Dies gewährleistet eine hohe Datenaktualität für Anwendungen, die ständig aktuelle Informationen benötigen, wie z.B. Kreditprotokolle, die Echtzeit-Sicherheitenbewertungen für Liquidationen erfordern. Allerdings verursacht dieses ständige Aktualisieren Gaskosten für jede On-Chain-Transaktion, unabhängig davon, ob die Daten sofort von einem Smart Contract verwendet werden, was potenziell zu höheren Betriebskosten für das Oracle-Netzwerk führt.

Pull-Oracles hingegen verfolgen einen reaktiven, bedarfsgesteuerten Ansatz. Daten werden nicht kontinuierlich auf die Blockchain übertragen. Stattdessen verbleiben sie Off-Chain, oft von Oracle-Knoten signiert, und werden nur dann On-Chain gebracht, wenn ein Smart Contract oder Benutzer sie explizit anfordert. Wenn ein Smart Contract Daten benötigt, löst er einen Mechanismus aus, um die Daten von den Off-Chain-Oracle-Knoten abzurufen und sie dann in einer Transaktion auf die Blockchain zu schreiben. Dies kann durch einen Benutzer erfolgen, der eine Transaktion sendet, die den Smart Contract zur Datenanforderung veranlasst, oder durch einen Keeper-Dienst. Ein prominentes Beispiel ist RedStone Finance, das Datenpakete Off-Chain bereitstellt, die bei Bedarf von dApps abgerufen werden können. Der Hauptvorteil dieses Modells ist die Kosteneffizienz, da Gaskosten nur anfallen, wenn Daten tatsächlich benötigt und abgerufen werden. Dies ist besonders vorteilhaft für Anwendungen, die Daten seltener benötigen oder bei denen die Benutzer bereit sind, die Kosten für die Datenabfrage zu tragen, wie z.B. bestimmte Derivate oder Versicherungen, die nur bei Eintritt eines bestimmten Ereignisses Daten benötigen. Der Nachteil kann eine höhere Latenz sein, da die Daten nicht immer sofort On-Chain verfügbar sind und erst angefordert werden müssen.

First-Party-Oracles unterscheiden sich von Push- und Pull-Modellen nicht primär durch den Liefermechanismus, sondern durch die Identität des Datenanbieters. Bei First-Party-Oracles ist der Datenlieferant oft der Entwickler der dezentralen Anwendung (dApp) selbst oder eine direkt mit der dApp verbundene, vertrauenswürdige Entität. Anstatt sich auf ein externes, dezentrales Oracle-Netzwerk zu verlassen, signiert und übermittelt die dApp die benötigten Off-Chain-Daten direkt an ihre eigenen Smart Contracts. Ein Beispiel hierfür könnte eine dezentrale Börse sein, die ihre eigenen internen Preis-Feeds aus ihrem Orderbuch generiert und diese direkt für ihre Handels-Smart Contracts bereitstellt. Der Vorteil liegt in der direkten Kontrolle und potenziell geringeren Komplexität, da keine Abhängigkeit von externen Drittanbietern besteht. Allerdings birgt dieses Modell ein höheres Zentralisierungsrisiko und erfordert ein hohes Maß an Vertrauen in den dApp-Entwickler, da dieser die alleinige Autorität über die bereitgestellten Daten hat. Die Transparenz und Zensurresistenz können im Vergleich zu dezentralen Oracle-Netzwerken geringer sein.

Trading-Relevanz

Die Wahl des Oracle-Typs hat direkte und tiefgreifende Auswirkungen auf die Funktionsweise und Zuverlässigkeit von Trading-Protokollen und Finanzanwendungen im dezentralen Ökosystem. Für Trader und Entwickler ist das Verständnis dieser Unterschiede wesentlich, um die Risiken und Chancen von DeFi-Produkten richtig einzuschätzen.

Push-Oracles sind für Hochfrequenz-Trading-Anwendungen und Protokolle, die eine kontinuierliche und sofortige Datenverfügbarkeit erfordern, von immenser Bedeutung. Denken Sie an dezentrale Kreditplattformen wie Aave oder Compound, die Sicherheiten in Echtzeit bewerten müssen, um Liquidationsschwellen zu überwachen. Ein schneller und präziser Preis-Feed, der durch ein Push-Oracle bereitgestellt wird, ist hier unerlässlich, um das Risiko von Unterbesicherungen zu minimieren und faire Liquidationspreise zu gewährleisten. Wenn ein Push-Oracle aufgrund von Netzwerküberlastung oder fehlerhaften Updates verzögert wird, kann dies zu erheblichen Verlusten für Kreditgeber und Kreditnehmer führen, da Liquidationsereignisse nicht korrekt oder rechtzeitig ausgelöst werden. Für Derivatebörsen, die Perpetual Swaps oder Optionen anbieten, ist die ständige Verfügbarkeit eines aktuellen Indexpreises, der durch Push-Oracles geliefert wird, die Grundlage für die korrekte Berechnung von Finanzierungsraten und die Abwicklung von Positionen. Die Zuverlässigkeit und Aktualität der Daten sind hier direkt mit der Integrität des Marktes verbunden.

Pull-Oracles finden ihre Relevanz in Trading-Szenarien, die nicht auf ständige Echtzeit-Updates angewiesen sind oder bei denen die Kostenoptimierung im Vordergrund steht. Dies könnte beispielsweise bei exotischen Derivaten der Fall sein, die nur zu bestimmten Abrechnungszeitpunkten oder bei Erreichen spezifischer Schwellenwerte Daten benötigen. Auch für bestimmte Arten von Versicherungen oder Optionskontrakten, die nur bei Eintritt eines seltenen Ereignisses eine Datenabfrage erfordern, sind Pull-Oracles eine kostengünstige Lösung. Trader, die solche Produkte nutzen, müssen sich jedoch der potenziellen Latenz bewusst sein: Die Daten sind nicht immer sofort On-Chain verfügbar, und die Kosten für die Datenabfrage können auf den Endnutzer umgelegt werden. Dies erfordert eine sorgfältige Abwägung zwischen Datenaktualität und Transaktionskosten. Für Arbitrage-Strategien, die auf minimale Preisunterschiede angewiesen sind, sind Pull-Oracles in der Regel weniger geeignet, da die Verzögerung bei der Datenbereitstellung die Arbitrage-Möglichkeiten zunichtemachen könnte. Sie sind eher für langfristige Strategien oder für die Abwicklung von Ereignissen konzipiert, die nicht auf Millisekunden-Präzision angewiesen sind.

First-Party-Oracles sind im Trading-Kontext relevant, wenn die dApp selbst die primäre Quelle für die relevanten Daten ist oder eine hohe Kontrolle über die Datenintegrität benötigt. Eine dezentrale Börse (DEX) könnte beispielsweise ihre eigenen On-Chain-Orderbücher als First-Party-Oracle nutzen, um den Preis eines Assets für die Ausführung von Swaps zu bestimmen. Dies eliminiert die Abhängigkeit von externen Oracle-Netzwerken und reduziert potenzielle Angriffsflächen, die durch Drittanbieter entstehen könnten. Allerdings ist die Trading-Relevanz hier auch mit dem Vertrauen in die dApp selbst verbunden. Wenn die dApp kompromittiert wird oder böswillig agiert, können die First-Party-Daten manipuliert werden, was zu unfairen Handelsbedingungen oder Verlusten für die Nutzer führt. Trader, die solche Plattformen nutzen, müssen die Governance-Struktur und die Sicherheitsaudits der dApp genau prüfen. First-Party-Oracles sind oft in Nischenanwendungen oder in Ökosystemen zu finden, in denen die Datenquelle eng mit der Funktionalität der dApp verknüpft ist, wie z.B. bei bestimmten Gaming-Token-Preisen oder internen Liquiditätspools.

Risiken

Jeder Oracle-Typ birgt spezifische Risiken, die bei der Entwicklung und Nutzung von Smart Contracts berücksichtigt werden müssen. Das Verständnis dieser Risiken ist wesentlich, um die Robustheit und Sicherheit dezentraler Anwendungen zu gewährleisten.

Bei Push-Oracles sind die Hauptbedenken oft mit den Betriebskosten und der Datenaktualität verbunden. Da Daten regelmäßig On-Chain übertragen werden, können die Gaskosten bei hoher Netzwerkaktivität oder steigenden Gaspreisen erheblich werden. Dies kann die Wirtschaftlichkeit des Oracle-Dienstes beeinträchtigen und im Extremfall dazu führen, dass Updates verzögert oder eingestellt werden, wenn die Kosten die Einnahmen übersteigen. Eine weitere Gefahr ist die Stale Data (veraltete Daten). Wenn die Update-Bedingungen zu locker sind (z.B. nur alle 24 Stunden oder bei einer Preisänderung von 10 %), können Smart Contracts mit veralteten Informationen arbeiten, was in volatilen Märkten katastrophale Folgen haben kann, insbesondere bei Liquidationsereignissen. Zudem besteht das Risiko von Zentralisierung, wenn die Datenquelle oder das Push-Netzwerk selbst von einer begrenzten Anzahl von Entitäten kontrolliert wird, was Angriffe auf die Datenintegrität oder Zensur ermöglicht.

Pull-Oracles sind anfällig für Risiken im Zusammenhang mit der Datenverfügbarkeit und potenzieller Manipulation. Da Daten erst auf Anforderung On-Chain gebracht werden, kann es zu Latenzproblemen kommen, wenn die Daten nicht schnell genug abgerufen werden können, insbesondere in schnelllebigen Märkten. Dies kann zu Front-Running-Angriffen führen, bei denen ein Angreifer die Datenanforderung erkennt, eine eigene Transaktion mit höheren Gasgebühren sendet, um die Daten zuerst abzurufen und zu nutzen, bevor die ursprüngliche Anforderung verarbeitet wird. Ein weiteres Risiko ist die Manipulation der Abfrage. Wenn der Mechanismus zur Datenanforderung nicht robust ist, könnten böswillige Akteure versuchen, den Abfrageprozess zu beeinflussen, um bestimmte Daten zu einem für sie günstigen Zeitpunkt abzurufen oder die Kosten für andere zu erhöhen. Die Sicherheit hängt stark von der Integrität der Off-Chain-Datenpakete und der Verifizierbarkeit der Signaturen ab, die beweisen, dass die Daten von vertrauenswürdigen Oracle-Knoten stammen.

First-Party-Oracles tragen das höchste Zentralisierungsrisiko. Da der dApp-Entwickler oder eine einzelne Entität die Daten direkt bereitstellt, besteht ein Single Point of Failure. Wenn diese Entität kompromittiert wird, böswillig agiert oder einfach einen Fehler macht, können die Smart Contracts mit falschen Daten versorgt werden, was zu erheblichen Verlusten für die Nutzer führen kann. Das Vertrauen in die dApp und ihre Betreiber ist hier von größter Bedeutung. Es fehlt oft die Transparenz und die dezentrale Verifizierung, die von Drittananbieter-Oracle-Netzwerken geboten wird. Dies macht First-Party-Oracles anfälliger für Zensur und Manipulation durch die kontrollierende Partei. Obwohl sie in bestimmten Nischenanwendungen, in denen das Vertrauen in den Entwickler hoch ist und die Datenquelle eng mit der dApp verbunden ist, effizient sein können, sind sie für Anwendungen, die ein hohes Maß an Dezentralisierung und Zensurresistenz erfordern, weniger geeignet. Das Risiko eines Rug Pulls oder einer böswilligen Datenänderung ist hier am höchsten.

Geschichte und Beispiele

Die Notwendigkeit von Oracles entstand mit den ersten Smart Contracts auf Plattformen wie Ethereum, da diese von Natur aus nicht auf externe Daten zugreifen konnten. Frühe Implementierungen waren oft rudimentär und stark zentralisiert, was die Anfälligkeit für Single Points of Failure erhöhte. Mit der Zeit entwickelten sich komplexere und dezentralere Lösungen, um die Sicherheit und Zuverlässigkeit der Datenversorgung zu verbessern.

Ein historisch und aktuell prominentes Beispiel für ein Push-Oracle-Modell ist Chainlink. Chainlink hat sich als führendes dezentrales Oracle-Netzwerk etabliert, das eine Vielzahl von Daten-Feeds für DeFi-Protokolle bereitstellt. Seine Preis-Feeds, wie der ETH/USD-Feed, werden von einem dezentralen Netzwerk von Oracle-Knoten betrieben, die Daten von mehreren Off-Chain-Quellen aggregieren und diese Daten dann proaktiv auf die Blockchain übertragen, sobald bestimmte Update-Bedingungen (z.B. eine Preisänderung von 0,5 % oder ein Zeitintervall) erfüllt sind. Diese konstante Verfügbarkeit von aktuellen Daten ist von großer Bedeutung für Anwendungen wie Kreditprotokolle und Derivatebörsen, die auf zuverlässige und zeitnahe Preisinformationen angewiesen sind, um Liquidationsereignisse und Margenberechnungen korrekt durchzuführen. Die Entwicklung von Chainlink hat maßgeblich dazu beigetragen, die Sicherheit und Dezentralisierung von Push-Oracles zu verbessern, indem es Anreizmechanismen und Reputationssysteme für Oracle-Knoten implementiert hat.

Ein neueres und bemerkenswertes Beispiel für ein Pull-Oracle-Modell ist RedStone Finance. RedStone hat sich darauf spezialisiert, eine große Menge an Daten effizient und kostengünstig bereitzustellen, indem es diese Off-Chain speichert und nur bei Bedarf On-Chain bringt. RedStone-Oracles sammeln Daten von verschiedenen Anbietern, führen Berechnungen wie Median- oder gewichtete Durchschnittspreise durch und stellen dann signierte Datenpakete in einer Datenverteilungsschicht (DDL) bereit. Smart Contracts oder Benutzer können diese Daten dann bei Bedarf abrufen und On-Chain verifizieren. Dieses Modell ist besonders vorteilhaft für Anwendungen, die nicht auf ständige Echtzeit-Updates angewiesen sind oder bei denen die Gaskosten für Push-Oracles zu hoch wären. Es ermöglicht eine breitere Palette von Daten, einschließlich Long-Tail-Assets oder weniger häufig benötigter Informationen, die sonst zu teuer wären, um sie kontinuierlich On-Chain zu halten. RedStone wurde beispielsweise auf Konferenzen wie der Consensus 2024 vorgestellt, um die Vorteile seines Pull-Modells hervorzuheben.

First-Party-Oracles sind oft in spezifischen dApps oder Ökosystemen zu finden, wo der Entwickler oder eine zentrale Entität die Datenhoheit besitzt. Ein klassisches Beispiel könnte ein frühes dezentrales Spiel sein, bei dem der Spielentwickler die Ergebnisse von Zufallsgeneratoren oder Spielständen direkt in Smart Contracts schreibt. Auch eine dezentrale autonome Organisation (DAO), die ihre eigenen internen Abstimmungsergebnisse oder Treasury-Daten direkt in ihre Smart Contracts einspeist, könnte als First-Party-Oracle agieren. Ein weiteres Beispiel ist eine DEX, die ihre eigenen Liquiditätspool-Preise als Referenz für Swaps verwendet, ohne auf externe Oracle-Netzwerke angewiesen zu sein. Während diese Modelle eine hohe Kontrolle und oft eine einfachere Implementierung bieten, erfordern sie ein hohes Maß an Vertrauen in die ausgebende Partei und sind anfälliger für Zentralisierungsrisiken und potenzielle Manipulationen, da es keine unabhängige Verifizierung durch ein dezentrales Netzwerk gibt.

Häufige Missverständnisse

Im Bereich der Blockchain-Oracles gibt es mehrere weit verbreitete Missverständnisse, die zu Fehlinterpretationen der Funktionsweise und der Risiken führen können. Eine klare Abgrenzung ist für das Verständnis der Technologie unerlässlich.

Ein häufiges Missverständnis ist, dass Oracles selbst die primäre Datenquelle sind. Tatsächlich sind Oracles keine Datenquellen im eigentlichen Sinne, sondern Datenaggregator und -relayer. Sie sammeln Informationen von externen APIs, Börsen, Sensoren oder anderen Off-Chain-Systemen, verarbeiten diese (z.B. durch Medianberechnungen oder gewichtete Durchschnitte) und übermitteln sie dann an die Blockchain. Die Qualität und Zuverlässigkeit der Oracle-Daten hängt daher direkt von der Qualität und Zuverlässigkeit der zugrunde liegenden Off-Chain-Datenquellen ab. Ein Oracle kann nur so gut sein wie die Daten, die es speist. Wenn die externen Quellen fehlerhaft oder manipuliert sind, werden auch die Oracle-Daten unzuverlässig sein, unabhängig davon, wie robust das Oracle-Netzwerk selbst ist. Es ist entscheidend zu verstehen, dass Oracles eine Brücke sind, keine Insel der Datenproduktion.

Ein weiteres Missverständnis ist die Annahme, dass ein bestimmter Oracle-Typ – sei es Push, Pull oder First-Party – grundsätzlich „besser“ ist als die anderen. In Wirklichkeit sind diese Modelle nicht hierarchisch, sondern komplementär und für unterschiedliche Anwendungsfälle optimiert. Push-Oracles sind ideal für Anwendungen, die eine extrem hohe Datenaktualität und -verfügbarkeit erfordern, wie z.B. Liquidationsmechanismen in DeFi, wo jede Sekunde zählt. Pull-Oracles hingegen glänzen bei Anwendungen, die Daten seltener benötigen und bei denen die Kosteneffizienz im Vordergrund steht, oder wenn die Datenabfrage durch den Endnutzer initiiert werden soll. First-Party-Oracles sind nützlich, wenn die dApp selbst die autoritative Datenquelle ist und eine hohe Kontrolle über die Datenintegrität benötigt, allerdings auf Kosten der Dezentralisierung. Die Wahl des „besten“ Oracle-Typs hängt immer von den spezifischen Anforderungen des Smart Contracts, den Toleranzen für Latenz und Kosten sowie dem gewünschten Grad an Dezentralisierung und Vertrauen ab. Es gibt keine Einheitslösung.

Zudem wird oft angenommen, dass First-Party-Oracles automatisch dezentralisiert sind, nur weil sie direkt von einer dApp stammen. Dies ist jedoch selten der Fall. First-Party-Oracles implizieren oft, dass eine einzelne Entität (der dApp-Entwickler oder eine zentrale Organisation) die Daten bereitstellt und signiert. Dies führt zu einem inhärenten Zentralisierungsrisiko und einem Single Point of Failure. Während die dApp selbst dezentralisiert sein mag, ist die Datenquelle, die sie nutzt, in diesem Fall zentralisiert. Echte Dezentralisierung bei Oracles erfordert ein Netzwerk von unabhängigen Knoten, die Daten aggregieren und validieren, wie es bei dezentralen Push- oder Pull-Oracle-Netzwerken der Fall ist. Das Vertrauen in ein First-Party-Oracle ist letztlich ein Vertrauen in die Integrität und Sicherheit der ausgebenden Partei, nicht in ein dezentrales Konsenssystem.

Zusammenfassung

Blockchain-Oracles sind unverzichtbare Komponenten des dezentralen Ökosystems, die Smart Contracts die Interaktion mit der realen Welt ermöglichen. Die drei Haupttypen – Push, Pull und First-Party – bieten unterschiedliche Ansätze zur Datenbereitstellung, die jeweils spezifische Vor- und Nachteile mit sich bringen und für verschiedene Anwendungsfälle optimiert sind. Push-Oracles liefern Daten proaktiv und kontinuierlich auf die Blockchain, ideal für Anwendungen, die eine hohe Datenaktualität und ständige Verfügbarkeit erfordern, wie beispielsweise DeFi-Lending-Protokolle. Sie gewährleisten, dass kritische Informationen stets On-Chain bereitstehen, allerdings zu potenziell höheren Gaskosten. Pull-Oracles hingegen stellen Daten nur auf Anforderung bereit, was eine kosteneffiziente Lösung für Anwendungen darstellt, die Daten seltener benötigen oder bei denen die Latenz weniger kritisch ist. Dieses Modell verlagert die Kosten der Datenabfrage oft auf den Endnutzer und bietet Flexibilität für eine breitere Palette von Daten. First-Party-Oracles schließlich werden direkt von der dApp oder einer vertrauenswürdigen Entität bereitgestellt, was eine hohe Kontrolle und oft eine einfachere Implementierung ermöglicht, jedoch mit einem erhöhten Zentralisierungsrisiko und der Notwendigkeit eines hohen Vertrauens in den Datenanbieter einhergeht. Das Verständnis dieser unterschiedlichen Mechanismen ist für Entwickler, Trader und Nutzer gleichermaßen von großer Bedeutung, um die Sicherheit, Effizienz und Funktionalität von dezentralen Anwendungen korrekt zu bewerten und die jeweils am besten geeignete Oracle-Lösung auszuwählen. Die Wahl des richtigen Oracle-Typs ist keine Frage der Überlegenheit, sondern der optimalen Anpassung an die spezifischen Anforderungen und Risikoprofile einer Blockchain-Anwendung.