Was ist RedStone? Modulares Oracle-Design

2026-08-14

RedStone ist ein modulares Blockchain-Oracle-System. Seine Materialien trennen Datengewinnung, die Verteilung signierter Daten, die Weiterleitung an eine Ziel-Chain und die Nutzung durch eine Anwendung. Im Pull-Modell kommt ein signiertes Datenpaket mit dem Aufruf, der die Daten benötigt; im Push-Modell wird ein Onchain-Feed nach einer Aktualisierungsrichtlinie erneuert. RED ist der dokumentierte Utility-Token des Netzwerks. Das sind Systemrollen, keine Aussage über den Wert von RED.

Was ist RedStone

RedStone ist Infrastruktur, die Daten außerhalb einer Ziel-Blockchain in die Umgebung eines Smart Contracts bringt. Eine Blockchain kann ihren eigenen Zustand prüfen, aber nicht selbst einen Handelsplatz, einen Reservebeleg, einen Webdienst oder eine andere Chain beobachten. Ein Oracle ist die Gesamtheit der Komponenten, die eine externe Beobachtung zusammen mit Regeln an einen Vertrag übermitteln, damit dieser über die Annahme der Nachricht entscheiden kann.

RedStone lässt sich am besten als modularer Datenweg verstehen, nicht als ein unteilbarer Feed-Vertrag. Die Entwicklerunterlagen trennen diesen Weg in Datengewinnung, Datenverteilung, Weiterleitung und Datenverbrauch. Die Komponente, die Daten gewinnt, muss nicht dieselbe sein, die sie weiterleitet; der empfangende Vertrag muss den erhaltenen Wert dennoch selbst prüfen und verwenden.

Der Name RedStone kann in gewöhnlichen Suchergebnissen Unterschiedliches meinen. In diesem Artikel steht RedStone für das vom Projekt beschriebene Oracle-System und den gesondert benannten RED-Token. Gemeint ist nicht jedes ähnlich benannte Asset, nicht jeder Token mit dem Symbol RED und auch kein Wert aus einem beliebigen Feed, der automatisch mit dem RED-Token gleichgesetzt wird.

Welches Problem will RedStone lösen

Smart Contracts sind deterministisch: Gleiche Onchain-Eingaben führen zur gleichen Berechnung. Das ist nützlich, doch ein Vertrag kann keine externe Tatsache selbst feststellen. Eine Kreditberechnung, eine Abwicklungsregel, eine Besicherungsprüfung oder ein reservesensitives Design kann Daten außerhalb der Chain benötigen. Der Vertrag braucht einen definierten Weg von einer Quelle zu einer überprüfbaren Nachricht, nicht nur eine in Code eingetragene Zahl.

Das Problem besteht nicht nur darin, einen Feed zu erhalten. Eine Anwendung muss festlegen, welche Daten relevant sind, welchen Quellen und Signierern sie vertraut, wie alt ein Wert sein darf, was bei fehlenden Daten geschieht und wer die Verfügbarkeit zum benötigten Zeitpunkt sicherstellt. Das sind Entwurfsentscheidungen des Integrators. Ein Oracle kann Material für diese Entscheidung liefern, sie aber nicht anstelle des nutzenden Protokolls treffen.

Die modulare Darstellung von RedStone soll Quelle, Verteilung, Weiterleitung und Verbrauch trennen, damit unterschiedliche Lieferarten einen gemeinsamen Datenweg nutzen können. Diese Trennung macht externe Daten nicht zu einer durch die Blockchain garantierten Tatsache und beweist nicht, dass eine konkrete Integration sinnvolle Validierungsregeln gewählt hat.

Wie RedStone funktioniert

Die RedStone-Seite für Entwickler beschreibt vier Stufen. Bei der Datengewinnung werden die Eingaben für einen Feed zusammengestellt. Bei der Datenverteilung stellt eine Knoten-Infrastruktur signierte Daten bereit. Die Weiterleitung bringt dieses Material auf die Ziel-Chain. Beim Datenverbrauch entpackt und prüft ein Vertrag auf der Ziel-Chain das Empfangene, bevor es in der Anwendungslogik verwendet wird.

Im in den technischen Materialien beschriebenen Pull-Ansatz sind signierte Pakete außerhalb der Chain verfügbar, und ein Aufruf, der einen Wert benötigt, bringt das Paket in calldata mit. Der konsumierende Vertrag kann das Paket während der Ausführung prüfen. Das öffentliche Monorepo des Projekts beschreibt den Ansatz als das Anhängen von Daten an eine Nutzertransaktion, ohne sie nach der Verarbeitung als gewöhnlichen EVM-Speicher vorzuhalten.

Paketformat, Signierer-Richtlinie, erlaubtes Datenalter und die Behandlung ungültiger Eingaben bleiben Details des jeweiligen konsumierenden Vertrags. Die bloße Unterstützung von Pull bedeutet nicht, dass alle Verträge das gleiche Paket akzeptieren oder denselben Frische-Schwellenwert verwenden.

Im Push-Ansatz schreibt eine aktualisierende Komponente einen Feed-Wert in einen Onchain-Vertrag, bevor ein separater Verbrauchsaufruf ihn benötigt. Die Produktunterlagen beschreiben solche Aktualisierungen über Heartbeat- und Deviation-Bedingungen. Ein späterer Aufruf kann den gespeicherten Wert lesen, muss aber weiterhin Frische, Vertragsadresse und erwartete Genauigkeit prüfen; die Onchain-Speicherung macht Daten nicht automatisch passend.

Diese Wege zeigen auch, warum Feed und Token verschiedene Objekte sind. Ein Feed kann einen Referenzwert zu einem Asset, einer Reserve oder einem anderen Datensatz tragen; RED ist der in den Projektunterlagen verwendete Ticker. Dass ein Oracle ein datenbezogenes Paket liefern kann, sagt für sich genommen nichts über den Wert von RED aus, und eine Beschreibung der RED-Rolle beweist nicht die Korrektheit eines bestimmten Feed.

Was RED im System tut

Das offizielle Tokenomics-Material nennt den Ticker ausdrücklich RED, und die aktuelle Projektseite zum Token bezeichnet RED als nativen Utility-Token des RedStone-Netzwerks. Diese Seiten beschreiben ein Design, in dem der Token wirtschaftliche Sicherheit, Dezentralisierung und Anreize für Teilnehmer des Oracle-Ökosystems unterstützen soll. Das ist eine dokumentierte Systemrolle, kein Versprechen, dass jeder Halter eine operative Funktion erfüllt oder ein bestimmtes Ergebnis erhält.

Fragen zu Tokenomics und Anwendungsfällen sollten in zwei Teile getrennt werden. Tokenomics ist das dokumentierte Design von Angebot und Anreizen; Anwendungsfälle sind die Funktionen, die das umgebende Oracle-System liefern soll. Keines von beiden ersetzt die Prüfung von Datenqualität, Anwendungssicherheit oder eine Bewertung des Tokens. Token-Schicht und Datenliefer-Schicht können verbundene Anreize haben, erfüllen aber verschiedene technische Aufgaben.

Das Material von 2025 behandelt Staking als Teil des beabsichtigten wirtschaftlichen Sicherheitsdesigns. Dieser Artikel gibt keine Staking-Anleitung, behandelt das historische Material nicht als aktuellen Belohnungsplan und leitet daraus keine Governance-Rechte, Vertragsparameter oder einen Deployment-Status ab. Ticker, Chain, Vertragsadresse und Version sollten getrennt geprüft werden.

RedStone-Ökosystem und Kontext der Verbreitung

Modulares RedStone-Oracle-Design: Quelle, Verteilung, Pull- oder Push-Weiterleitung, Verbrauch, RED-Rolle und Prüfschritte

Mit Ökosystem sind hier die Beziehungen zwischen Datenquellen, Datenanbietern oder Knoten, Verteilungsdiensten, Weiterleitungsmechanismen, konsumierenden Verträgen, Entwicklern und der RED-Anreizschicht gemeint. Die aktuellen RedStone-Seiten für Entwickler und Produkte stellen Pull- und Push-Feeds als Lieferoptionen dar. Das hilft beim Verständnis der Begriffe, ist aber keine unabhängige Prüfung jeder Integration.

Verbreitung sollte für jedes Deployment einzeln geprüft werden. Ein Logo, ein Feed-Katalog oder eine öffentliche Aussage beweist nicht, dass ein bestimmter Vertrag aktiv, richtig konfiguriert oder derzeit von einem konkreten Liefermodell abhängig ist. Die präzisere Frage lautet: Welcher Vertrag ist auf einer benannten Chain eingesetzt, welches Paket oder welchen Feed liest er, und welche Validierungsbedingungen führt er aus?

Worin RedStone sich unterscheidet: Pull, Push und modulare Lieferung

Der Hauptunterschied zwischen Pull und Push ist der Zeitpunkt, zu dem die Ziel-Chain die Daten erhält. Bei Pull kommt das Paket an, wenn ein Anwendungsaufruf es benötigt. Die Frische ist an diesen Aufruf und die Annahmeregeln des konsumierenden Vertrags gebunden. Wenn kein Aufruf ein gültiges Paket mitbringt, wird nicht allein wegen des Zeitablaufs automatisch ein neuer Zustand geschrieben.

Bei Push schreibt eine aktualisierende Komponente Werte nach festgelegten Bedingungen in einen Onchain-Feed. Ein späterer Vertragsaufruf kann den gespeicherten Feed lesen, ohne das Paket in diesen Aufruf einzubetten. Es gibt keine allgemeingültige Rangfolge: Die aktualisierende Komponente, das Protokoll oder eine andere Vereinbarung muss Aktualisierungen ermöglichen und überwachen, während das konsumierende Protokoll weiterhin eigene Frische- und Ausfallregeln festlegt.

Modulare Lieferung bedeutet, dass ein breiter Datenweg mit mehr als einer Weiterleitungsart verbunden werden kann, statt jede Anwendung zum Empfang zum gleichen Zeitpunkt zu zwingen. Das bedeutet weder, dass jeder Feed auf jeder Chain in beiden Formen existiert, noch dass eine Integration das Modell ohne Codeprüfung wechseln kann. Modularität beschreibt trennbare Komponenten und gibt keine absolute Zusage zu Geschwindigkeit, Kosten oder Sicherheit.

Risiken und Grenzen

Das erste Risiko liegt an der Grenze von Quellen und Signaturen. Eine Signatur kann zeigen, dass ein zugelassener Signierer eine Nachricht erzeugt hat, aber nicht allein Vollständigkeit, Aktualität und Richtigkeit der Quellbeobachtung oder ihre Eignung für die Ökonomie eines bestimmten Protokolls belegen. Der Verbraucher sollte wissen, welche Signierer und Quellen seine Konfiguration akzeptiert, welche Aggregation sie nutzt und welche Markt- oder Infrastrukturbedingungen das Design voraussetzt.

Das zweite Risiko betrifft Lieferung und Verfügbarkeit. Eine Pull-Integration hängt davon ab, während eines Aufrufs ein gültiges Paket zu erhalten; eine Push-Integration hängt davon ab, dass die aktualisierende Komponente und der gespeicherte Wert innerhalb des für den Verbraucher akzeptablen Alters bleiben. Netzstörung, verzögerte Weiterleitung, eine falsche Chain, ein Endpoint-Problem oder eine alte Integration können eine Anwendung ohne die erwarteten Daten lassen. Modularität schafft Wahlmöglichkeiten, entfernt aber keine Betriebsabhängigkeiten.

Das dritte Risiko liegt im konsumierenden Vertrag. Falsche Genauigkeit, eine nicht passende Feed-Kennung, eine zu lockere Zeitprüfung, fehlendes Ausfallverhalten, ein Upgrade oder eine falsche Vertragsadresse können schädliches Anwendungsverhalten auslösen, selbst wenn eine Oracle-Komponente wie vorgesehen arbeitet. Eine Audit-Aussage benötigt einen Bericht mit klarem Umfang und klarer Version auf der eigenen Website des Prüfers; dieser Artikel behauptet weder einen Audit- noch einen Nicht-Audit-Status für RedStone insgesamt oder ein bestimmtes Deployment.

Wie du RedStone selbst überprüfst

Beginne bei der offiziellen RedStone-Domain und folge deren eigenen Links zu Entwicklerunterlagen, Token-Unterlagen und dem öffentlichen Code-Repository. Prüfe, ob das offizielle Token-Material den Projektnamen genau mit RED verbindet, statt dich auf ein Suchergebnis oder ein ähnlich benanntes Asset zu verlassen. Soziale Beiträge, Werbung und ähnlich aussehende Domains sind Prüfhinweise, kein Beweis.

Für einen Token oder Feed auf einer bestimmten Chain vergleichst du zuerst Chain und Vertragsadresse mit aktuellem offiziellem Material und siehst die Adresse anschließend im passenden Block-Explorer nach. Prüfe Vertragsname, sichtbaren verifizierten Quellcode, Symbol und Adresse. Der Ethereum-Explorer-Eintrag für RED ist ein nützliches Ziel für eine Gegenprüfung, doch ein Explorer-Label ersetzt keine offizielle Adressankündigung.

Bei einer konsumierenden Anwendung kannst du Code oder Dokumentation nur lesend auf Feed-Kennung, Regeln für Signierer oder Anbieter, Zeitprüfungen, Genauigkeitsbehandlung, Ausfallverhalten sowie Pausen- oder Upgrade-Kontrollen untersuchen. Wird ein Audit behauptet, suche den Bericht auf der Domain des Prüfers und gleiche Umfang und Codeversion mit dem eingesetzten Code ab. Für diese Prüfungen musst du keine Wallet verbinden, keine Nachricht signieren und keinem Anspruchsaufruf folgen.

Fazit

RedStone ist am besten als modulares Oracle-Design zu verstehen: Datengewinnung, Verteilung, Weiterleitung und Verbrauch sind getrennte Verantwortungsbereiche. Pull bringt signiertes Material mit einem Aufruf, der Daten benötigt; Push schreibt Werte nach einer Aktualisierungsrichtlinie onchain. Der Unterschied liegt im Zeitpunkt der Datenankunft und in dem, was die konsumierende Anwendung prüfen muss.

RED ist der Ticker des Utility-Tokens in den Unterlagen des RedStone-Netzwerks, während ein Feed ein Mechanismus zur Datenlieferung ist. Diese Trennung verhindert, die Mechanik eines Feed mit einer Aussage über den Token zu verwechseln. Der sichere nächste Schritt ist ausschließlich lesende Prüfung der offiziellen Domain, der genauen Chain und des Vertrags, des Explorer-Quellcodes und der eigenen Validierungslogik des konsumierenden Vertrags.

Zugehörige Marktseiten

RED: Preis ansehen · Spotmarkt · Perpetual-Markt

Haftungsausschluss: Dieser Artikel ist Bildungsinhalt der Bitbase Academy, nur zu Informationszwecken. Er erklärt, was ein Projekt tut und welche Rolle sein Token in diesem System spielt; er ist keine Anlage-, Handels-, Steuer- oder Finanzberatung und weder eine Empfehlung noch eine Befürwortung eines Projekts oder Tokens. Bitbase hat das hier beschriebene Projekt keiner Due Diligence unterzogen, und die Erwähnung bedeutet nicht, dass Bitbase den Vermögenswert listet oder unterstützt. Krypto-Assets bergen erhebliche Risiken, darunter Kursschwankungen, geringe Liquidität, Fehler in Smart Contracts, regulatorische Unsicherheit und den möglichen Totalverlust. Stand August 2026; Projektstatus, Tokenomics, Team und Verträge können sich jederzeit ändern. Prüfe alles selbst — über offizielle Kanäle, die Contract-Adresse und einen Block-Explorer — und hüte dich vor nachgeahmten Websites und Phishing-Links.