• About Us
  • The Value Of Tourism
  • Why Tratok?
  • Tratok Features
  • Tokenomics
  • Buy Tratok
  • Buy TRAT → Explore Platform →

    De ce ne-am construit propriile oracole în loc să folosim Chainlink

    SUB CAPOTĂ

    De ce ne-am construit propriile oracole în loc să folosim Chainlink

    Prima întrebare pe care o pune fiecare persoană familiarizată cu criptomonede când vede arhitectura noastră. Iată răspunsul sincer.

    Aproape fiecare investitor tehnic curios cu care ne-am așezat la masă pune o variantă a aceleiași întrebări în primele zece minute.

    „Folosiți propriile oracole? De ce să nu vă conectați pur și simplu la Chainlink?”

    Este o întrebare corectă. Chainlink este de departe rețeaua dominantă de oracle descentralizată. Au o reputație puternică, un istoric de securitate serios și un ecosistem vast de dezvoltatori. A ne abate de la script ne costă ceva. Deci de ce am făcut-o?

    Răspunsul scurt: industria ospitalității are nevoi pe care rețelele oracle de uz general nu au fost create să le deservească bine.

    O scurtă introducere, pentru oricine nu este familiarizat cu acest domeniu

    Un contract inteligent este cod care rulează pe o blockchain. Poate deține active, impune reguli și eliberează plăți pe baza condițiilor. Ceea ce nu poate face în mod nativ este să știe ceva despre lumea exterioară. Nu poate citi calendarul de disponibilitate al unui hotel. Nu poate vedea cursul de schimb actual. Nu poate verifica că un oaspete s-a cazat efectiv.

    Un oracol este puntea dintre blockchain și realitate. Introduce date externe (prețuri, evenimente, verificare, identitate) în contractele inteligente astfel încât acestea să poată acționa pe baza lor. Dacă oracolul minte sau se defectează, contractul acționează pe baza unor informații eronate. De aceea proiectarea oracolelor este una dintre problemele cu cele mai mari mize în ingineria blockchain.

    Ce aveam nevoie ca oracolele noastre să facă

    Contractele inteligente Tratok gestionează multe decizii în fiecare zi. Rambursări, confirmări de rezervare, prețuri dinamice, soluționarea disputelor. Fiecare are nevoie de date externe de încredere:

    Inventar și disponibilitate în timp real
    Este această cameră disponibilă chiar acum? A fost rezervată chiar acum? S-a schimbat tariful de când utilizatorul a deschis pagina? Latența sub o secundă contează aici.
    Evenimente din ciclul de viață al rezervării
    Oaspetele s-a cazat efectiv? Proprietatea a raportat un neprezentare? Anularea a venit înainte sau după fereastra de politică? Acestea declanșează logica contractelor inteligente și sunt specifice ospitalității.
    Prețuri din surse multiple și schimb valutar
    Avem nevoie de rata de piață corectă a TRAT, conversie fiat în peste 50 de valute și semnale de prețuri dinamice din piața ospitalității. Streaming, nu instantaneu.
    Atestare a identității verificate
    Pentru ca sistemul nostru de recenzii să funcționeze, oracolul trebuie să confirme că un portofel verificat a finalizat o rezervare verificată. Această logică de atestare este personalizată pentru modul în care facem KYC și pentru modul în care este structurată arhitectura de recenzii.

    Compromisul, prezentat sincer

    Rețelele oracle de uz general sunt concepute pentru date de uz general. Acestea optimizează pentru lățime (fluxuri de prețuri pentru fiecare activ, fiecare lanț) și au făcut o treabă strălucită în această privință. Dar acea lățime înseamnă că sunt neapărat la unul sau două niveluri de abstractizare deasupra logicii specifice domeniului de care aveam nevoie.

    Pentru noi, acel decalaj s-a transformat în trei probleme reale:

    Latență. O decizie de rezervare se întâmplă în secunde. Un oaspete este pe o pagină, face clic, se așteaptă la o confirmare. Trimiterea datelor dus-întors printr-o rețea oracle de uz general adaugă latență pe care nu ne-o permiteam pentru operațiunile pe path-ul fierbinte. Aveam nevoie de timpi de răspuns sub o secundă pentru interogările de disponibilitate și preț.

    Cost la scară. Fiecare apel oracle are un cost. Pentru o platformă care vizează milioane de tranzacții pe lună, plătind tarife per-interogare către o rețea terță parte ne-ar fi inversat economia. Economiile pe care le oferim înapoi furnizorilor și consumatorilor depind de menținerea costului unitar al fiecărei tranzacții aproape de zero.

    Personalizare de domeniu. O „confirmare de check-in la proprietate” nu este o primitivă oracle standard. Nici „arbitrajul disputelor pentru o rambursare parțială”. Construirea acestora deasupra unei rețele generice de fluxuri este posibilă, dar ajungi să scrii atâta logică personalizată în jurul oracle-ului că efectiv rulezi jumătate dintr-unul oricum. Am decis să scriem întreaga soluție.

    Ce am construit în schimb: GHOST

    GHOST este protocolul nostru oracle proprietar, construit special pentru datele de ospitalitate și călătorii. Numele nu înseamnă nimic pretențios; este scurt și echipa noastră backend i-a plăcut.

    Câteva lucruri pe care GHOST ni le oferă pe care oracle-urile de uz general nu le pot:

    Ce am renunțat

    Vreau să fiu sincer despre asta. A merge proprietar nu este gratuit. Am acceptat trei costuri reale:

    Nu obținem securitatea efectului de rețea al unui set mare de validatori decentralizați din start. Compensăm cu audituri, guvernanță multi-semnătură pe protocol și un program de recompense pentru bug-uri actualizat continuu, dar este un model de încredere diferit. Îl recunoaștem deschis.

    Noi purtăm greul ingineresc. Fiecare actualizare de protocol, fiecare patch de securitate, fiecare tip nou de date. Asta revine echipei noastre. Cu Chainlink, o mare parte din această muncă grea este distribuită în întregul ecosistem.

    Nu obținem interoperabilitate gratuită cu ecosistemul DeFi mai larg. Dacă vrem să ne integrăm cu un protocol DeFi care așteaptă fluxuri Chainlink, trebuie să construim poduri. Am făcut deja o parte din asta și vom face mai mult.

    Pariul, într-o propoziție

    Pentru o platformă a cărei propunere de valoare fundamentală depinde de costul marginal de tranzacție aproape zero și de deciziile de rezervare în clasă de milisecunde, deținerea stratului de date a fost alegerea corectă. Chiar și cu sarcina de inginerie care vine odată cu aceasta.

    Această pariuri s-ar putea să nu fie corectă pentru fiecare proiect blockchain. Pentru un protocol DeFi sau o platformă de active sintetice, răspunsul este aproape întotdeauna Chainlink. Dar ospitalitatea este un domeniu cu astfel de nevoi de date atât de specifice și cu o astfel de presiune economică specifică de a menține costurile unitare scăzute, încât calculul se schimbă.

    Dacă lucrați la ceva unde cântăriți o decizie similară, am fi bucuroși să schimbăm impresii. Ecosistemul crypto nu vorbește suficient despre acest compromis.

    Vrei analiza tehnică detaliată?

    Arhitectura completă, inclusiv modelul de date GHOST, modelul de securitate și logica de agregare, este acoperită în whitepaper-ul Tratok.

    Citiți documentul informativ →

    — Carol

    Community Manager, Tratok

    Never miss an update

    Get new Tratok articles by email — the moment they publish, or as one weekly digest.

    Delivery frequency