Bijna elke technisch nieuwsgierige investeerder bij wie we zijn gaan zitten stelt een variant van dezelfde vraag in de eerste tien minuten.

“Jullie gebruiken jullie eigen orakels? Waarom niet gewoon inpluggen op Chainlink?”

Het is een eerlijke vraag. Chainlink is verreweg het dominante gedecentraliseerde oracle-netwerk. Ze hebben een sterke reputatie, een serieus beveiligingsdossier en een breed ontwikkelaars-ecosysteem. Van het standaardpad afwijken kost ons iets. Dus waarom deden we het?

Het korte antwoord: de hospitality-sector heeft behoeften waarvoor algemene oracle-netwerken niet goed zijn gebouwd om te dienen.

Een snelle inleiding, voor iedereen die hier niet in leeft

Een smart contract is code die draait op een blockchain. Het kan activa vasthouden, regels afdwingen en betalingen vrijgeven op basis van voorwaarden. Wat het niet kan doen, van nature, is iets weten over de buitenwereld. Het kan de beschikbaarheidskalender van een hotel niet lezen. Het kan het huidige wisselkoers niet zien. Het kan niet verifiëren dat een gast daadwerkelijk is ingecheckt.

Een orakel is de brug tussen de blockchain en de realiteit. Het voedt externe data (prijzen, gebeurtenissen, verificatie, identiteit) in smart contracts zodat ze erop kunnen acteren. Als het orakel liegt of breekt, handelt het contract op slechte informatie. Daarom is orakelontwerp een van de hoogste-inzetproblemen in blockchain-engineering.

Wat we nodig hadden van onze oracles om te doen

Tratok’s slimme contracten verwerken veel beslissingen elke dag. Restituties, boekingsbevestigingen, dynamische prijsstelling, geschillenbeslechting. Elk van deze heeft vertrouwde externe data nodig:

De afweging, eerlijk gepresenteerd

Algemene oracle-netwerken zijn ontworpen voor algemene gegevens. Ze optimaliseren voor breedte (prijsfeeds voor elk activum, elke keten) en ze hebben er briljant werk van geleverd. Maar die breedte betekent dat ze noodzakelijkerwijs een of twee abstractielagen boven de specifieke domeinlogica staan die we nodig hadden.

Voor ons werd die kloof drie echte problemen:

Latentie. Een booringsbeslissing gebeurt in seconden. Een gast is op een pagina, ze klikken, ze verwachten een bevestiging. Het heen en weer sturen van gegevens via een algemeen oracle-netwerk voegt latentie toe die we ons niet konden veroorloven voor de hot-path operaties. We hadden sub-seconde reactietijden nodig bij beschikbaarheids- en prijsqueries.

Kosten op schaal. Elke oracle-aanroep heeft een kost. Voor een platform dat mikt op miljoenen transacties per maand, zou het betalen van per-query vergoedingen aan een netwerk van derden onze economie hebben omgekeerd. De besparingen die we teruggeven aan aanbieders en consumenten zijn afhankelijk van het bijna nul houden van de eenheidskosten van elke transactie.

Domeinpersonalisatie. Een “eigendoms inchekbevestiging” is geen standaard oracle primitief. Evenmin als “geschillenbeslechting bij een gedeeltelijke terugbetaling”. Die bouwen op een generiek feed-netwerk is mogelijk, maar je eindigt met zoveel aangepaste logica rond de oracle dat je effectief de helft van er een draait. We hebben besloten om gewoon het hele ding te schrijven.

Wat we in plaats daarvan bouwden: GHOST

GHOST is ons eigen oracle-protocol, speciaal gebouwd voor gastvrijheids- en reisgegevens. De naam staat nergens voor pretentieus; het is kort en ons backend-team vond het leuk.

Een paar dingen die GHOST ons geeft die algemene oracles niet kunnen:

• Sub-seconde hot path. Beschikbaarheids- en prijsqueries worden in milliseconden geretourneerd omdat ze native zijn aan het systeem, niet gebridged.
• Domeinbewuste datastructuren. Het protocol spreekt over “boeking”, “tariefplan”, “annuleringsbeleid”, “incheckevenement”, niet alleen generieke numerieke feeds.
• Kostenschaalbaarheid. Marginale orakelkosten naderen nul bij hoog volume, wat de enige manier is waarop aanbiedersbesparingen van 28 tot 36 procent duurzaam zijn.
• Aggregatie uit meerdere bronnen. GHOST aggregeert inventaris en prijzen uit ons netwerk dat duizenden eigendommen omvat. De aggregatielogica is specifiek afgestemd op het hospitality gebruiksscenario.
• Onafhankelijke audit. Het hele systeem heeft onafhankelijke beveiligingsaudits doorlopen als onderdeel van ons bredere smart-contractreviewproces.

Wat we hebben opgegeven

Ik wil hier eerlijk over zijn. Proprietary worden is niet gratis. We hebben drie echte kosten geaccepteerd:

We krijgen niet de netwerkeffectbeveiliging van een groot gedecentraliseerd validatorset uit de doos. We compenseren met audits, multi-signature governance op het protocol, en een continu bijgewerkt bug bounty-programma, maar het is een ander vertrouwensmodel. We erkennen het openlijk.

Wij dragen de technische last. Elk protocol-upgrade, elke beveiligingspatch, elk nieuw gegevenstype. Dat is voor ons team. Met Chainlink wordt een groot deel van dat zware tillen gedeeld binnen het ecosysteem.

We krijgen geen gratis interoperabiliteit met het bredere DeFi-ecosysteem. Als we willen integreren met een DeFi-protocol dat Chainlink-feeds verwacht, moeten we bruggen bouwen. We hebben hier al wat van gedaan en zullen meer doen.

De gok, in één zin

Voor een platform waarvan de kernwaardepropositie afhankelijk is van bijna-nihil marginale transactiekosten en milliseconde-boekingsbeslissingen, was het bezitten van de datalaag de juiste afweging. Zelfs met de engineeringbelasting die daarbij komt kijken.

Die gok is misschien niet juist voor elk blockchainproject. Voor een DeFi-protocol of een synthetisch activa-platform is het antwoord bijna altijd Chainlink. Maar hospitality is een domein met zulke specifieke databehoeften, en zulke specifieke economische druk om eenheidskosten laag te houden, dat de berekening verandert.

Als je werkt aan iets waar je een vergelijkbare beslissing afweegt, zouden we graag aantekeningen vergelijken. Het crypto-ecosysteem praat niet genoeg over deze afweging.

— Carol

Community Manager, Tratok