• About Us
  • The Value Of Tourism
  • Why Tratok?
  • Tratok Features
  • Tokenomics
  • Buy Tratok
  • Buy TRAT → Explore Platform →

    Warum wir unsere eigenen Orakel gebaut haben, anstatt Chainlink zu verwenden

    UNTER DER HAUBE

    Warum wir unsere eigenen Orakel gebaut haben, anstatt Chainlink zu verwenden

    Die erste Frage, die jede kryptointerne Person stellt, wenn sie unsere Architektur sieht. Hier ist die ehrliche Antwort.

    Fast jeder technisch interessierte Investor, mit dem wir uns hingesetzt haben, stellt in den ersten zehn Minuten eine Variante derselben Frage.

    “Ihr verwendet eure eigenen Orakel? Warum nicht einfach Chainlink nutzen?”

    Das ist eine berechtigte Frage. Chainlink ist bei weitem das dominierende dezentrale Oracle-Netzwerk. Sie haben einen starken Ruf, ein ernstzunehmendes Sicherheitsprotokoll und ein breites Entwickler-Ökosystem. Vom Skript abzuweichen kostet uns etwas. Also warum haben wir es getan?

    Die kurze Antwort: Die Gastronomie hat Bedürfnisse, für die universelle Oracle-Netzwerke nicht gut entwickelt wurden.

    Ein kurzer Überblick, für alle, die sich nicht täglich damit beschäftigen

    Ein Smart Contract ist Code, der auf einer Blockchain läuft. Er kann Vermögenswerte halten, Regeln durchsetzen und Zahlungen basierend auf Bedingungen freigeben. Was er von Natur aus nicht tun kann, ist etwas über die Außenwelt wissen. Es kann keinen Verfügbarkeitskalender eines Hotels lesen. Es kann den aktuellen Wechselkurs nicht sehen. Es kann nicht verifizieren, dass ein Gast tatsächlich eingecheckt hat.

    Ein Orakel ist die Brücke zwischen der Blockchain und der Realität. Es speist externe Daten (Preise, Ereignisse, Verifizierung, Identität) in intelligente Verträge ein, damit diese darauf reagieren können. Wenn das Orakel lügt oder ausfällt, handelt der Vertrag auf Grundlage schlechter Informationen. Deshalb ist das Orakel-Design eines der Probleme mit dem höchsten Einsatz im Blockchain-Engineering.

    Was unsere Orakel tun mussten

    Tratoks Smart Contracts treffen täglich viele Entscheidungen. Rückerstattungen, Buchungsbestätigungen, dynamische Preisgestaltung, Streitbeilegung. Jede einzelne benötigt vertrauenswürdige externe Daten:

    Echtzeit-Bestand und Verfügbarkeit
    Ist dieses Zimmer jetzt verfügbar? Wurde es gerade gebucht? Hat sich der Preis geändert, seit der Nutzer die Seite geöffnet hat? Sub-Sekunden-Latenzzeit ist hier entscheidend.
    Buchungslebenszyklus-Ereignisse
    Ist der Gast tatsächlich eingecheckt? Hat die Unterkunft ein No-Show gemeldet? Erfolgte die Stornierung vor oder nach dem Policenfenster? Diese lösen Smart-Contract-Logik aus und sind gastgewerbespezifisch.
    Multi-Source-Preisgestaltung und Devisenkurse
    Wir benötigen TRATs Fair-Markt-Kurs, Fiat-Konvertierung über 50+ Währungen hinweg und dynamische Preissignale aus dem Gastgewerbemarkt. Streaming, nicht Momentaufnahme.
    Verifizierte Identitätsbestätigung
    Damit unser Bewertungssystem funktioniert, muss das Orakel bestätigen, dass ein verifiziertes Wallet eine verifizierte Buchung abgeschlossen hat. Diese Bestätigungslogik ist angepasst an unsere KYC-Prozesse und an die Struktur der Bewertungsarchitektur.

    Der Kompromiss, ehrlich betrachtet

    Allzweck-Oracle-Netzwerke sind für Allzweckdaten konzipiert. Sie optimieren auf Breite (Preis-Feeds für jedes Asset, jede Chain) und sie haben damit brillante Arbeit geleistet. Aber diese Breite bedeutet, dass sie zwangsläufig eine oder zwei Abstraktionsschichten über der spezifischen Domänenlogik liegen, die wir benötigten.

    Für uns wurde diese Lücke zu drei echten Problemen:

    Latenz. Eine Buchungsentscheidung passiert in Sekunden. Ein Gast ist auf einer Seite, er klickt, er erwartet eine Bestätigung. Das Hin- und Herschicken von Daten durch ein Allzweck-Oracle-Netzwerk fügt Latenz hinzu, die wir uns für die Hot-Path-Operationen nicht leisten konnten. Wir brauchten Antwortzeiten unter einer Sekunde für Verfügbarkeits- und Preisabfragen.

    Kosten bei Skalierung. Jeder Oracle-Aufruf hat Kosten. Für eine Plattform, die auf Millionen von Transaktionen pro Monat abzielt, hätten pay-per-query-Gebühren an ein Drittanbieter-Netzwerk unsere Ökonomik umgekehrt. Die Ersparnisse, die wir an Anbieter und Verbraucher weitergeben, hängen davon ab, dass wir die Stückkosten jeder Transaktion nahe Null halten.

    Domänenanpassung. Eine „Unterkunft-Check-in-Bestätigung” ist kein Standard-Oracle-Primitiv. Ebenso wenig wie „Streitschlichtung bei einer teilweisen Rückerstattung”. Diese auf einem generischen Feed-Netzwerk aufzubauen ist möglich, aber man endet damit, so viel benutzerdefinierte Logik um das Oracle herum zu schreiben, dass man effektiv bereits die Hälfte von einem betreibt. Wir haben uns entschieden, das Ganze einfach selbst zu schreiben.

    Was wir stattdessen gebaut haben: GHOST

    GHOST ist unser proprietäres Oracle-Protokoll, speziell für Hospitality- und Reisendaten entwickelt. Der Name steht für nichts Präseliges; er ist kurz und unser Backend-Team mochte ihn.

    Ein paar Dinge, die GHOST uns bringt, die Allzweck-Oracles nicht können:

    Was wir aufgegeben haben

    Ich möchte hier ehrlich sein. Proprietär zu gehen ist nicht kostenlos. Wir haben drei echte Kosten akzeptiert:

    Wir erhalten nicht die netzwerkeffektbasierte Sicherheit eines großen dezentralen Validator-Sets standardmäßig. Wir kompensieren mit Audits, Multi-Signatur-Governance auf dem Protokoll und einem kontinuierlich aktualisierten Bug-Bounty-Programm, aber es ist ein anderes Vertrauensmodell. Wir acknowledge es offen.

    Wir tragen die technische Last. Jedes Protokoll-Upgrade, jeder Sicherheits-Patch, jeder neue Datentyp. Das liegt in der Verantwortung unseres Teams. Bei Chainlink wird ein großer Teil dieser schweren Arbeit vom Ökosystem getragen.

    Wir erhalten keine kostenlose Interoperabilität mit dem breiteren DeFi-Ökosystem. Wenn wir ein DeFi-Protokoll integrieren möchten, das Chainlink-Feeds erwartet, müssen wir Brücken bauen. Wir haben bereits einige davon getan und werden mehr tun.

    Die Wette, in einem Satz

    Für eine Plattform, deren Kernwertversprechen von Transaktionskosten nahe null und millisekundengleichen Buchungsentscheidungen abhängt, war der Besitz der Datenschicht der richtige Handel. Selbst mit der technischen Belastung, die damit einhergeht.

    Diese Wette könnte nicht für jedes Blockchain-Projekt richtig sein. Für ein DeFi-Protokoll oder eine synthetische Asset-Plattform ist die Antwort fast immer Chainlink. Aber Gastfreundschaft ist ein Bereich mit so spezifischen Datenanforderungen und so spezifischem wirtschaftlichem Druck, die Stückkosten niedrig zu halten, dass sich die Rechnung ändert.

    Wenn Sie an etwas arbeiten, bei dem Sie eine ähnliche Entscheidung abwägen, würden wir uns freuen, unsere Erfahrungen auszutauschen. Das Krypto-Ökosystem spricht nicht genug über diesen Kompromiss.

    Möchten Sie die technische Vertiefung?

    Die vollständige Architektur, einschließlich des Datenmodells, Sicherheitsmodells und Aggregationslogik von GHOST, ist im Tratok-Whitepaper beschrieben.

    Das Whitepaper lesen →

    — Carol

    Community-Managerin, Tratok

    Never miss an update

    Get new Tratok articles by email — the moment they publish, or as one weekly digest.

    Delivery frequency