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

    Por qué construimos nuestros propios oráculos en lugar de usar Chainlink

    BAJO EL CAPÓ

    Por qué construimos nuestros propios oráculos en lugar de usar Chainlink

    La primera pregunta que hace toda persona nativa de las criptomonedas cuando ve nuestra arquitectura. Aquí está la respuesta honesta.

    Casi todos los inversores técnicamente curiosos con los que nos hemos sentado preguntan alguna variante de la misma pregunta en los primeros diez minutos.

    “¿Estás usando tus propios oráculos? ¿Por qué no simplemente conectarse a Chainlink?”

    Es una pregunta justa. Chainlink es, con diferencia, la red de oráculos descentralizada dominante. Tienen una sólida reputación, un historial de seguridad serio y un amplio ecosistema de desarrolladores. Desviarse del guion nos cuesta algo. Entonces, ¿por qué lo hicimos?

    La respuesta corta: la industria hotelera tiene necesidades que las redes de oráculos de propósito general no fueron construidas para servir bien.

    Una breve introducción, para cualquiera que no viva en este mundo

    Un contrato inteligente es código que se ejecuta en una blockchain. Puede almacenar activos, hacer cumplir reglas y liberar pagos basados en condiciones. Lo que no puede hacer, de forma nativa, es conocer nada sobre el mundo exterior. No puede leer el calendario de disponibilidad de un hotel. No puede ver el tipo de cambio actual. No puede verificar que un huésped realmente se registró.

    Un oráculo es el puente entre la blockchain y la realidad. Alimenta datos externos (precios, eventos, verificación, identidad) en los contratos inteligentes para que puedan actuar en consecuencia. Si el oráculo miente o se rompe, el contrato actúa sobre información incorrecta. Es por eso que el diseño de oráculos es uno de los problemas de mayor riesgo en la ingeniería de blockchain.

    Lo que necesitábamos que hicieran nuestros oráculos

    Los contratos inteligentes de Tratok manejan muchas decisiones todos los días. Reembolsos, confirmaciones de reservas, precios dinámicos, resolución de disputas. Cada uno necesita datos externos confiables:

    Inventario y disponibilidad en tiempo real
    ¿Está esta habitación disponible ahora mismo? ¿Acaba de ser reservada? ¿Ha cambiado la tarifa desde que el usuario abrió la página? Aquí importa la latencia inferior al segundo.
    Eventos del ciclo de vida de la reserva
    ¿El huésped realmente hizo el check-in? ¿La propiedad reportó una no presentación? ¿La cancelación llegó antes o después de la ventana de la política? Estos activan la lógica del contrato inteligente y son específicos del sector de la hospitalidad.
    Precios multifuente y tipo de cambio
    Necesitamos la tasa de mercado justo de TRAT, conversión de moneda fiduciaria en más de 50 monedas, y señales de precios dinámicos del mercado de hospitalidad. En flujo continuo, no una instantánea.
    Atestación de identidad verificada
    Para que nuestro sistema de reseñas funcione, el oráculo tiene que confirmar que una billetera verificada completó una reserva verificada. Esa lógica de atestación es personalizada según cómo hacemos KYC y cómo está estructurada la arquitectura de reseñas.

    La compensación, presentada honestamente

    Las redes oráculo de propósito general están diseñadas para datos de propósito general. Optimizan para amplitud (feeds de precios para cada activo, cada cadena) y han hecho un trabajo brillante con ello. Pero esa amplitud significa que están necesariamente una o dos capas de abstracción por encima de la lógica de dominio específica que necesitábamos.

    Para nosotros, esa brecha se convirtió en tres problemas reales:

    Latencia. Una decisión de reserva ocurre en segundos. Un huésped está en una página, hace clic, espera una confirmación. Devolver datos a través de una red oráculo de propósito general añade latencia que no podíamos permitirnos para las operaciones de ruta activa. Necesitábamos tiempos de respuesta inferiores al segundo en consultas de disponibilidad y precios.

    Costo a escala. Cada llamada al oráculo tiene un costo. Para una plataforma que apunta a millones de transacciones por mes, pagar tarifas por consulta a una red de terceros habría invertido nuestra economía. Los ahorros que devolvemos a proveedores y consumidores dependen de mantener el costo unitario de cada transacción cerca de cero.

    Personalización de dominio. Una “confirmación de check-in de propiedad” no es un primitivo oráculo estándar. Tampoco lo es “arbitraje de disputas en un reembolso parcial”. Construir eso encima de una red de feed genérica es posible, pero terminas escribiendo tanta lógica personalizada alrededor del oráculo que esencialmente estás ejecutando la mitad de uno de todos modos. Decidimos simplemente escribir todo el sistema.

    Lo que construimos en su lugar: GHOST

    GHOST es nuestro protocolo oráculo propietario, construido específicamente para datos de hospitalidad y viajes. El nombre no significa nada pretencioso; es corto y a nuestro equipo de backend le gustó.

    Unas cosas que GHOST nos da que los oráculos de propósito general no pueden:

    Lo que cedimos

    Quiero ser honesto al respecto. Ir propietario no es gratis. Aceptamos tres costos reales:

    No obtenemos el efecto de red de seguridad de un gran conjunto de validadores descentralizados de fábrica. Compensamos con auditorías, gobernanza de multi-firma en el protocolo, y un programa de bug bounty continuamente actualizado, pero es un modelo de confianza diferente. Lo reconocemos abiertamente.

    Nosotros cargamos con el peso de la ingeniería. Cada actualización de protocolo, cada parche de seguridad, cada nuevo tipo de datos. Eso recae en nuestro equipo. Con Chainlink, mucho de ese pesado trabajo se comparte en todo el ecosistema.

    No obtenemos interoperabilidad gratuita con el ecosistema DeFi más amplio. Si queremos integrarnos con un protocolo DeFi que espera feeds de Chainlink, tenemos que construir puentes. Ya hemos hecho algo de esto y haremos más.

    La apuesta, en una oración

    Para una plataforma cuya propuesta de valor central depende de un costo marginal de transacción casi nulo y de decisiones de reserva en milisegundos, poseer la capa de datos fue la decisión correcta. Incluso con la carga de ingeniería que esto implica.

    Esa apuesta podría no ser adecuada para cada proyecto blockchain. Para un protocolo DeFi o una plataforma de activos sintéticos, la respuesta casi siempre es Chainlink. Pero la hospitalidad es un dominio con necesidades de datos tan específicas, y con una presión económica tan específica para mantener bajos los costos unitarios, que el cálculo cambia.

    Si estás trabajando en algo donde estás sopesando una decisión similar, nos encantaría comparar notas. El ecosistema cripto no habla lo suficiente sobre este compromiso.

    ¿Quieres la inmersión técnica profunda?

    La arquitectura completa, incluyendo el modelo de datos de GHOST, el modelo de seguridad y la lógica de agregación, se encuentra detallada en el whitepaper de Tratok.

    Leer el documento técnico →

    — Carol

    Gerente de Comunidad, Tratok

    Never miss an update

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

    Delivery frequency