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.
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 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.
Tratoks Smart Contracts treffen täglich viele Entscheidungen. Rückerstattungen, Buchungsbestätigungen, dynamische Preisgestaltung, Streitbeilegung. Jede einzelne benötigt vertrauenswürdige externe Daten:
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.
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:
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.
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.
Die vollständige Architektur, einschließlich des Datenmodells, Sicherheitsmodells und Aggregationslogik von GHOST, ist im Tratok-Whitepaper beschrieben.
— Carol
Community-Managerin, Tratok
Get new Tratok articles by email — the moment they publish, or as one weekly digest.
Get new Tratok articles by email — the moment they publish, or as one weekly digest.