Nesten enhver teknisk nysgjerrig investor vi har satt oss ned med stiller en variant av det samme spørsmålet i løpet av de første ti minuttene.

“Du bruker dine egne orakler? Hvorfor ikke bare koble til Chainlink?”

Det er et rettferdig spørsmål. Chainlink er på langt nær det dominerende desentraliserte orakelnettverket. De har et sterkt omdømme, en solid sikkerhetshistorikk og et bredt utviklerøkosystem. Å gå utenfor manus koster oss noe. Så hvorfor gjorde vi det?

Det korte svaret: hotellbransjen har behov som generiske orakelnettverk ikke ble bygget for å betjene godt.

En rask innføring, for alle som ikke lever i dette

En smart kontrakt er kode som kjører på en blockchain. Den kan holde eiendeler, håndheve regler og utbetale betalinger basert på betingelser. Det den ikke kan gjøre nativt, er å vite noe som helst om omverdenen. Den kan ikke lese et hotells tilgjengelighetskalender. Den kan ikke se den nåværende valutakursen. Den kan ikke verifisere at en gjest faktisk sjekket inn.

Et orakel er broen mellom blockchain og virkeligheten. Det mater eksterne data (priser, hendelser, verifisering, identitet) inn i smarte kontrakter slik at de kan handle på det. Hvis orakelet lyver eller bryter sammen, handler kontrakten på dårlig informasjon. Det er grunnen til at orakeldesign er et av de høyest prioriterte problemene i blockchain-ingeniørfaget.

Det vi trengte at våre orakler skulle gjøre

Tratoks smarte kontrakter håndterer mange beslutninger hver dag. Refusjoner, bestillingsbekreftelser, dynamisk prising, tvisteløsning. Hver av dem trenger pålitelige eksterne data:

Avveiningen, fremstilt ærlig

Generelle orakelnettverk er designet for generelle data. De optimaliserer for bredde (prisstrømmer for hver eiendel, hver kjede) og de har gjort en strålende jobb med det. Men denne bredden betyr at de nødvendigvis er én eller to abstraksjonsnivåer over den spesifikke domenelogikken vi trengte.

For oss ble dette gapet til tre reelle problemer:

Latens. En bestillingsbeslutning skjer på sekunder. En gjest er på en side, de klikker, de forventer en bekreftelse. Å sende data tur-retur gjennom et generelt orakelnettverk legger til latens vi ikke hadde råd til for kritiske operasjoner. Vi trengte responstider under ett sekund på tilgjengelighets- og prisforespørsler.

Kostnad ved skala. Hver orakelkall har en kostnad. For en plattform som sikter mot millioner av transaksjoner per måned, ville det å betale per-forespørsel-gebyrer til et tredjepartsnettverk ha snudd økonomien vår på hodet. Besparelsene vi gir tilbake til leverandører og forbrukere avhenger av å holde enhetskostnaden for hver transaksjon nær null.

Domenetilpasning. En “eiendomsinnsjekkingsbekreftelse” er ikke en standard orakelprimitiv. Heller ikke “tvistavgjørelse ved delvis refusjon.” Å bygge disse oppå et generisk strømnettverk er mulig, men du ender opp med å skrive så mye egendefinert logikk rundt orakelet at du i praksis kjører halvparten av ett uansett. Vi bestemte oss for bare å skrive hele greia.

Det vi bygde i stedet: GHOST

GHOST er vårt proprietære orakelprotokoll, formålsbygget for gjestfrihet- og reisedata. Navnet står ikke for noe pretensiøst; det er kort og backend-teamet vårt likte det.

Noen få ting GHOST gir oss som generelle orakler ikke kan:

• Kritisk bane under ett sekund. Tilgjengelighets- og prisforespørsler returnerer på millisekunder fordi de er native til systemet, ikke brobygd.
• Domene-bevisste datastrukturer. Protokollen snakker “bestilling,” “prisplan,” “kanselleringspolicy,” “innsjekkshendelse,” ikke bare generiske numeriske datastrømmer.
• Kostnadsskalering. Marginale orakelkostnader nærmer seg null ved høy volum, som er den eneste måten leverandørbesparelser på 28 til 36 prosent er bærekraftige.
• Aggregering fra flere kilder. GHOST aggregerer beholdning og priser fra vårt nettverk som strekker seg over tusenvis av eiendommer. Aggregeringslogikken er spesifikt tilpasset hotellbransjens brukstilfelle.
• Uavhengig revisjon. Hele systemet har gjennomgått uavhengige sikkerhetsrevisjoner som en del av vår bredere smarte kontrakt-gjennomgangsprosess.

Det vi ga avkall på

Jeg vil være ærlig om dette. Å gå proprietært er ikke gratis. Vi aksepterte tre reelle kostnader:

Vi får ikke nettverkseffektsikkerheten til et stort desentralisert validatorsett ut av boksen. Vi kompenserer med revisjoner, flersignaturstyring på protokollen, og et kontinuerlig oppdatert bug bounty-program, men det er en annen tillitsmodell. Vi erkjenner det åpent.

Vi tar den tekniske byrden. Hver protokolloppgradering, hver sikkerhetsfiks, hver nye datatype. Det er vårt teams ansvar. Med Chainlink deles mye av den tunge løftingen på tvers av økosystemet.

Vi får ikke gratis interoperabilitet med det bredere DeFi-økosystemet. Hvis vi vil integrere med en DeFi-protokoll som forventer Chainlink-datastrømmer, må vi bygge broer. Vi har allerede gjort noe av dette og vil gjøre mer.

Innsatsen, i én setning

For en plattform hvis kjerneverdiproposisjon avhenger av nesten-null marginale transaksjonskostnader og millisekundklasse bestillingsbeslutninger, var det å eie datalaget den riktige avveiningen. Selv med ingeniørarbeidsbelastningen som følger med det.

Den innsatsen er kanskje ikke riktig for alle blockchain-prosjekter. For en DeFi-protokoll eller en syntetisk aktivaplattform er svaret nesten alltid Chainlink. Men vertskap er et domene med så spesifikke databehov, og så spesifikk økonomisk press for å holde enhetskostnadene lave, at kalkylen endres.

Hvis du arbeider med noe der du veier en lignende avgjørelse, ville vi vært glade for å sammenligne erfaringer. Kryptoøkosystemet snakker ikke nok om denne avveiningen.

— Carol

Samfunnsleder, Tratok