Quasi ogni investitore tecnicamente curioso con cui ci siamo seduti chiede qualche variante della stessa domanda nei primi dieci minuti.

“State usando i vostri oracoli? Perché non collegarvi semplicemente a Chainlink?”

È una domanda legittima. Chainlink è di gran lunga la rete oracle decentralizzata dominante. Hanno una forte reputazione, un serio track record di sicurezza e un ampio ecosistema di sviluppatori. Deviare dal copione ci costa qualcosa. Allora perché l’abbiamo fatto?

La risposta breve: il settore dell’ospitalità ha esigenze che le reti oracle general-purpose non sono state costruite per soddisfare bene.

Una rapida introduzione, per chi non vive in questo settore

Un smart contract è codice che viene eseguito su una blockchain. Può detenere asset, applicare regole e rilasciare pagamenti basati su condizioni. Ciò che non può fare, nativamente, è conoscere qualsiasi cosa sul mondo esterno. Non può leggere il calendario di disponibilità di un hotel. Non può vedere il tasso di cambio attuale. Non può verificare che un ospite abbia effettivamente effettuato il check-in.

Un oracolo è il ponte tra la blockchain e la realtà. Fornisce dati esterni (prezzi, eventi, verifica, identità) ai contratti intelligenti in modo che possano agire su di essi. Se l’oracolo mente o si rompe, il contratto agisce su informazioni errate. Ecco perché la progettazione degli oracoli è uno dei problemi più ad alto rischio nell’ingegneria blockchain.

Ciò di cui i nostri oracoli avevano bisogno per fare

I contratti intelligenti di Tratok gestiscono molte decisioni ogni giorno. Rimborsi, conferme di prenotazione, prezzi dinamici, risoluzione delle controversie. Ognuno di essi ha bisogno di dati esterni affidabili:

Il compromesso, presentato onestamente

Le reti oracle general-purpose sono progettate per dati general-purpose. Ottimizzano per ampiezza (feed di prezzi per ogni asset, ogni chain) e hanno fatto un lavoro eccellente. Ma quella ampiezza significa che sono necessariamente uno o due livelli di astrazione sopra la logica di dominio specifica di cui avevamo bisogno.

Per noi, quel divario si è trasformato in tre problemi reali:

Latenza. Una decisione di prenotazione avviene in pochi secondi. Un ospite è su una pagina, clicca, si aspetta una conferma. Il routing di andata e ritorno dei dati attraverso una rete oracle general-purpose aggiungeva una latenza che non potevamo permetterci per le operazioni del hot-path. Avevamo bisogno di tempi di risposta inferiori al secondo per le query di disponibilità e prezzi.

Costo su scala. Ogni chiamata oracle ha un costo. Per una piattaforma che mira a milioni di transazioni al mese, pagare tariffe per query a una rete di terze parti avrebbe invertito la nostra economia. I risparmi che restituiamo ai fornitori e ai consumatori dipendono dal mantenere il costo unitario di ogni transazione vicino allo zero.

Personalizzazione del dominio. Una “conferma di check-in della proprietà” non è una primitiva oracle standard. Neanche “arbitrato delle controversie su un rimborso parziale”. Costruire quelle sopra una rete di feed generica è possibile, ma finisci per scrivere così tanta logica personalizzata intorno all’oracle che di fatto stai già eseguendo metà di uno. Abbiamo deciso di scrivere semplicemente l’intera cosa.

Quello che abbiamo costruito invece: GHOST

GHOST è il nostro protocollo oracle proprietario, costruito specificamente per i dati dell’hospitality e dei viaggi. Il nome non significa nulla di pretensioso; è breve e al nostro team backend è piaciuto.

Alcune cose che GHOST ci offre che gli oracle general-purpose non possono:

• Hot path sub-secondo. Le query di disponibilità e prezzi restituiscono in millisecondi perché sono native del sistema, non bridge.
• Strutture di dati consapevoli del dominio. Il protocollo parla di “prenotazione,” “tariffa,” “politica di cancellazione,” “evento di check-in,” non solo flussi numerici generici.
• Scalabilità dei costi. Il costo marginale dell’oracolo si avvicina a zero ad alto volume, che è l’unico modo in cui i risparmi del provider dal 28 al 36 percento sono sostenibili.
• Aggregazione multi-sorgente. GHOST aggrega disponibilità e prezzi dalla nostra rete che si estende su migliaia di proprietà. La logica di aggregazione è ottimizzata specificamente per il caso d’uso dell’ospitalità.
• Audit indipendente. L’intero sistema è stato sottoposto a audit di sicurezza indipendenti come parte del nostro più ampio processo di revisione degli smart contract.

Ciò a cui abbiamo rinunciato

Voglio essere onesto riguardo a questo. Passare a proprietario non è gratuito. Abbiamo accettato tre costi reali:

Non otteniamo la sicurezza dell’effetto rete di un ampio insieme di validatori decentralizzati out of the box. Compensiamo con audit, governance multi-firma sul protocollo e un programma di bug bounty continuamente aggiornato, ma è un modello di fiducia diverso. Lo riconosciamo apertamente.

Ci prendiamo carico del lavoro di ingegneria. Ogni aggiornamento del protocollo, ogni patch di sicurezza, ogni nuovo tipo di dati. È compito del nostro team. Con Chainlink, molto di questo pesado lavoro è condiviso attraverso l’ecosistema.

Non otteniamo interoperabilità gratuita con l’ecosistema DeFi più ampio. Se vogliamo integrare con un protocollo DeFi che si aspetta feed di Chainlink, dobbiamo costruire ponti. Ne abbiamo già fatto parte e ne faremo altri.

La scommessa, in una frase

Per una piattaforma la cui proposta di valore fondamentale dipende da un costo marginale di transazione prossimo allo zero e da decisioni di prenotazione nell’ordine dei millisecondi, possedere il livello dei dati è stata la scelta giusta. Anche con il carico di ingegneria che ne consegue.

Questa scommessa potrebbe non essere quella giusta per ogni progetto blockchain. Per un protocollo DeFi o una piattaforma di asset sintetici, la risposta è quasi sempre Chainlink. Ma l’ospitalità è un settore con esigenze di dati così specifiche, e con una pressione economica così specifica per mantenere bassi i costi unitari, che il calcolo cambia.

Se stai lavorando su qualcosa dove stai valutando una decisione simile, saremmo felici di confrontarci. L’ecosistema crypto non parla abbastanza di questo compromesso.

— Carol

Community Manager, Tratok