Nästan varje tekniskt nyfikna investerare som vi har satt oss ner med ställer någon variant av samma fråga under de första tio minuterna.

“Ni använder era egna orakel? Varför inte bara koppla in i Chainlink?”

Det är en rättvis fråga. Chainlink är utan tvekan det dominerande decentraliserade orakelnätverket. De har ett starkt rykte, en seriös säkerhetshistorik och ett brett utvecklarekosystem. Att avvika från skriptet kostar oss något. Så varför gjorde vi det?

Det korta svaret: hotellbranschen har behov som generalistiska orakelnätverk inte byggdes för att betjäna väl.

En snabb introduktion, för alla som inte lever i den här grejen

Ett smart kontrakt är kod som körs på en blockchain. Det kan hålla tillgångar, upprätthålla regler och frigöra betalningar baserat på villkor. Vad det inte kan göra, naturligt, är att veta något om omvärlden. Det kan inte läsa ett hotells tillgänglighetskalender. Det kan inte se den aktuella växelkursen. Det kan inte verifiera att en gäst faktiskt checkade in.

Ett orakel är bron mellan blockchain och verkligheten. Det matar extern data (priser, händelser, verifiering, identitet) in i smarta kontrakt så att de kan agera på den. Om oraklet ljuger eller går sönder, agerar kontraktet på dålig information. Vilket är varför orakeldesign är ett av de högsta insatsproblem inom blockchainteknik.

Vad vi behövde våra orakel att göra

Tratoks smarta kontrakt hanterar många beslut varje dag. Återbetalningar, bokningsbekräftelser, dynamisk prissättning, tvistlösning. Var och en behöver betrodd extern data:

Avvägningen, ärligt framställd

Oracle-nätverk för generellt ändamål är utformade för data för generellt ändamål. De optimerar för bredd (prisflöden för varje tillgång, varje kedja) och de har gjort ett briljant arbete med det. Men den bredden innebär att de nödvändigtvis är ett eller två abstraktionslager över den specifika domänlogik vi behövde.

För oss blev den luckan tre verkliga problem:

Latens. Ett bokningsbeslut sker på sekunder. En gäst är på en sida, de klickar, de förväntar sig en bekräftelse. Att skicka data fram och tillbaka genom ett oracle-nätverk för generellt ändamål lade till latens som vi inte hade råd med för heta sökvägsoperationer. Vi behövde svarstider under en sekund för tillgänglighets- och prisförfrågningar.

Kostnad vid skala. Varje oracle-anrop har en kostnad. För en plattform som siktar på miljontals transaktioner per månad skulle det att betala per-fråga-avgifter till ett tredjepartsnätverk ha inverterat vår ekonomi. Besparingarna vi ger tillbaka till leverantörer och konsumenter beror på att hålla enhetskostnaden för varje transaktion nära noll.

Domänanpassning. En “bekräftelse på fastighetsincheckning” är ingen standard oracle-primitiv. Inte heller “tvistmedling vid partiell återbetalning.” Att bygga dessa ovanpå ett generiskt flödesnätverk är möjligt, men du slutar med att skriva så mycket anpassad logik runt oraclet att du i praktiken kör halva ett ändå. Vi beslutade att helt enkelt skriva hela grejen.

Vad vi byggde istället: GHOST

GHOST är vårt proprietära oracle-protokoll, specifikt byggt för gästfrihets- och resedata. Namnet står inte för något pretentiöst; det är kort och vårt backend-team gillade det.

Några saker GHOST ger oss som generella oracle-orakel inte kan:

• Heta sökvägar under en sekund. Tillgänglighets- och prisförfrågningar returneras på millisekunder eftersom de är integrerade i systemet, inte bryggade.
• Domänmedvetna datastrukturer. Protokollet talar “bokning,” “prisschema,” “avbokningspolicy,” “incheckningshändelse,” inte bara generiska numeriska flöden.
• Kostnadsskalan. Marginal oracle-kostnad närmar sig noll vid hög volym, vilket är det enda sättet för att leverantörsbesparingar på 28 till 36 procent ska vara hållbara.
• Aggregering från flera källor. GHOST sammanställer inventering och prissättning från vårt nätverk som sträcker sig över tusentals fastigheter. Aggregeringslogiken är specifikt finjusterad för hotellbranschens användningsfall.
• Oberoende revision. Hela systemet har genomgått oberoende säkerhetsrevisioner som en del av vår bredare process för granskning av smarta kontrakt.

Vad vi gav upp

Jag vill vara ärlig med detta. Att bli proprietär är inte gratis. Vi accepterade tre verkliga kostnader:

Vi får inte nätverkseffektsäkerheten för en stor decentraliserad valideringsuppsättning direkt. Vi kompenserar med revisioner, flersignaturstyrning på protokollet och ett kontinuerligt uppdaterat bug bounty-program, men det är en annan förtroendemodell. Vi erkänner det öppet.

Vi tar det tekniska ansvaret. Varje protokolluppgradering, varje säkerhetskorrigering, varje ny datatyp. Det ligger på vårt team. Med Chainlink delas en stor del av det tunga lyftet över ekosystemet.

Vi får inte gratis interoperabilitet med det bredare DeFi-ekosystemet. Om vi vill integrera med ett DeFi-protokoll som förväntar sig Chainlink-flöden, måste vi bygga broar. Vi har redan gjort en del av detta och kommer att göra mer.

Vadslagningen, i en mening

För en plattform vars kärnvärdeproposition är beroende av nästan noll marginal transaktionskostnad och millisekundklassiga bokningsbeslut, var det rätt att äga dataskiktet. Även med den tekniska belastning som följer med det.

Detta spel kanske inte är rätt för varje blockchain-projekt. För ett DeFi-protokoll eller en syntetisk tillgångsplattform är svaret nästan alltid Chainlink. Men gästfrihet är ett område med så specifika databehov, och så specifikt ekonomiskt tryck att hålla enhetskostnaderna låga, att kalkylen förändras.

Om du arbetar med något där du väger ett liknande beslut, skulle vi vara glada att jämföra synpunkter. Kryptoekosystemet pratar inte tillräckligt om denna avvägning.

— Carol

Gemenskapsansvarig, Tratok