Esplora la piattaforma →

Perché abbiamo costruito i nostri oracoli invece di usare Chainlink

SOTTO IL COFANO

Perché abbiamo costruito i nostri oracoli invece di usare Chainlink

La prima domanda che si pone ogni appassionato di crypto quando vede la nostra architettura. Ecco la risposta sincera.

Quasi tutti gli investitori tecnicamente curiosi con cui ci siamo seduti a parlare fanno una variante della stessa domanda nei primi dieci minuti.

«Usate i vostri oracle? Perché non vi collegate semplicemente a Chainlink?»

È una domanda giusta. Chainlink è di gran lunga la rete di oracle decentralizzati dominante. Ha una solida reputazione, un serio curriculum in fatto di sicurezza e un ampio ecosistema di sviluppatori. Andare fuori dagli schemi ci costa qualcosa. E allora perché l’abbiamo fatto?

In breve: il settore alberghiero ha esigenze che le reti di oracle generiche non sono state pensate per soddisfare al meglio.

Un breve ripasso, per chi non vive di queste cose

Uno smart contract è codice che gira su una blockchain. Può detenere asset, far rispettare regole e sbloccare pagamenti in base a condizioni. Ciò che non può fare, in modo nativo, è sapere nulla del mondo esterno. Non può leggere il calendario della disponibilità di un hotel. Non può vedere il tasso di cambio attuale. Non può verificare che un ospite abbia davvero effettuato il check-in.

Un oracle è il ponte tra la blockchain e la realtà. Porta dati esterni (prezzi, eventi, verifiche, identità) negli smart contract, così che possano agire di conseguenza. Se l’oracle mente o si guasta, il contratto agisce su informazioni sbagliate. Ecco perché la progettazione degli oracle è uno dei problemi più critici nell’ingegneria della blockchain.

Cosa dovevano fare i nostri oracle

Gli smart contract di Tratok gestiscono ogni giorno moltissime decisioni. Rimborsi, conferme di prenotazione, prezzi dinamici, risoluzione di controversie. Ognuna richiede dati esterni affidabili:

Disponibilità e inventario in tempo reale
Questa camera è disponibile proprio ora? È stata appena prenotata? La tariffa è cambiata da quando l’utente ha aperto la pagina? In questo caso, conta una latenza inferiore al secondo.
Eventi del ciclo di vita della prenotazione
L’ospite ha davvero effettuato il check-in? La struttura ha segnalato un no-show? La cancellazione è arrivata prima o dopo la finestra della policy? Questi eventi attivano la logica dello smart contract e sono specifici del settore alberghiero.
Prezzi e cambi da più fonti
Ci servono il tasso di mercato equo di TRAT, la conversione in fiat su oltre 50 valute e segnali di prezzo dinamici dal mercato alberghiero. In streaming, non come semplice istantanea.
Attestazione d’identità verificata
Perché il nostro sistema di recensioni funzioni, l’oracolo deve confermare che un wallet verificato abbia completato una prenotazione verificata. Quella logica di attestazione è personalizzata in base al nostro processo di KYC e alla nostra architettura delle recensioni.

Il compromesso, presentato in modo onesto

Le reti di oracoli generiche sono progettate per dati generici. Puntano all’ampiezza (feed di prezzi per ogni asset, ogni catena) e lo fanno in modo brillante. Ma quella ampiezza le porta inevitabilmente a trovarsi uno o due livelli di astrazione sopra la logica di dominio specifica di cui avevamo bisogno.

Per noi, quel divario si è tradotto in tre problemi concreti:

Latenza. La decisione su una prenotazione avviene in pochi secondi. Un ospite è su una pagina, clicca e si aspetta una conferma. Inoltrare i dati attraverso una rete di oracoli generica aggiunge una latenza che non potevamo permetterci per le operazioni del percorso caldo. Avevamo bisogno di tempi di risposta inferiori al secondo per le query su disponibilità e prezzi.

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

Personalizzazione di dominio. Una «conferma di check-in della struttura» non è una primitiva standard di un oracolo. E non lo è nemmeno l’«arbitraggio delle controversie su un rimborso parziale». Costruirle sopra una rete di feed generica è possibile, ma finisci per scrivere così tanta logica personalizzata attorno all’oracolo che di fatto stai già gestendo metà di un oracolo tu stesso. Abbiamo deciso di scrivere tutto da noi.

Cosa abbiamo costruito al suo posto: GHOST

GHOST è il nostro protocollo di oracolo proprietario, progettato su misura per i dati dell’ospitalità e dei viaggi. Il nome non sta per nulla di pretenzioso; è corto e al nostro team di backend piaceva.

Alcune cose che GHOST ci permette di fare e che gli oracoli generici non possono:

  • Percorso caldo sotto il secondo. Le query su disponibilità e prezzi tornano in millisecondi perché sono native del sistema, non collegate tramite bridge.
  • Strutture dati consapevoli del dominio. Il protocollo parla di «prenotazione», «piano tariffario», «politica di cancellazione», «evento di check-in», non solo feed numerici generici.
  • Riduzione dei costi. Il costo marginale dell’oracolo tende a zero ad alti volumi, che è l’unico modo per rendere sostenibili risparmi per i fornitori dal 28 al 36 percento.
  • Aggregazione da più fonti. GHOST aggrega inventario e prezzi dalla nostra rete che copre migliaia di strutture. La logica di aggregazione è ottimizzata appositamente per il settore dell’ospitalità.
  • Revisione indipendente. L’intero sistema è stato sottoposto a verifiche di sicurezza indipendenti come parte del nostro più ampio processo di revisione degli smart contract.

Cosa abbiamo sacrificato

Voglio essere sincero su questo punto. Passare a una soluzione proprietaria non è gratis. Abbiamo accettato tre costi reali:

Non otteniamo automaticamente la sicurezza data dall’effetto di rete di un ampio set di validatori decentralizzati. Compensiamo con verifiche, governance multi-firma sul protocollo e un programma di bug bounty in continuo aggiornamento, ma è un modello di fiducia diverso. Lo riconosciamo apertamente.

Ci facciamo carico del lavoro ingegneristico. Ogni aggiornamento del protocollo, ogni patch di sicurezza, ogni nuovo tipo di dato. Ricade sul nostro team. Con Chainlink, gran parte di questo peso è condiviso nell’ecosistema.

Non otteniamo gratuitamente l’interoperabilità con l’ecosistema DeFi più ampio. Se vogliamo integraci con un protocollo DeFi che si aspetta feed Chainlink, dobbiamo costruire ponti. Lo abbiamo già fatto in parte e faremo di più.

La scommessa, in una frase

Per una piattaforma la cui proposta di valore fondamentale dipende da un costo marginale di transazione vicino allo zero e da decisioni di prenotazione nell’ordine dei millisecondi, possedere il livello dei dati era lo scambio giusto. Anche con il carico ingegneristico che ne deriva.

Quella scommessa potrebbe non essere adatta a ogni progetto blockchain. Per un protocollo DeFi o una piattaforma di asset sintetici, la risposta è quasi sempre Chainlink. Ma il settore alberghiero è un ambito con esigenze di dati così specifiche, e una pressione economica così forte a contenere i costi unitari, che il calcolo cambia.

Se stai lavorando a un progetto in cui devi valutare una decisione simile, saremmo felici di confrontare le nostre idee. L’ecosistema crypto non parla abbastanza di questo compromesso.

Vuoi l’approfondimento tecnico?

L’architettura completa, compresi il modello di dati, il modello di sicurezza e la logica di aggregazione di GHOST, è trattata nel whitepaper di Tratok.

Leggi il whitepaper →

Carol

Community Manager, Tratok

Ti è piaciuto? Condividi il viaggio.

Non perdere nessun aggiornamento

Ricevi i nuovi articoli di Tratok via email: appena vengono pubblicati o in un unico riepilogo settimanale.

Frequenza di invio