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.
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.
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.
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:
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.
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:
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.
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.
Arhitectura completă, inclusiv modelul de date GHOST, modelul de securitate și logica de agregare, este acoperită în whitepaper-ul Tratok.
— Carol
Community Manager, Tratok
Get new Tratok articles by email — the moment they publish, or as one weekly digest.
Get new Tratok articles by email — the moment they publish, or as one weekly digest.