Quase todo investidor tecnicamente curioso com quem conversamos faz alguma variante da mesma pergunta nos primeiros dez minutos.

“Vocês estão usando seus próprios oráculos? Por que não simplesmente conectar ao Chainlink?”

É uma pergunta justa. O Chainlink é de longe a rede de oráculos descentralizada dominante. Eles têm uma forte reputação, um histórico sério de segurança e um amplo ecossistema de desenvolvedores. Sair do script nos custa algo. Então por que fizemos isso?

A resposta curta: a hotelaria tem necessidades que redes de oráculos de propósito geral não foram construídas para atender bem.

Um breve manual, para quem não vive isso

Um contrato inteligente é código que é executado em uma blockchain. Ele pode manter ativos, impor regras e liberar pagamentos com base em condições. O que ele não pode fazer, nativamente, é saber qualquer coisa sobre o mundo exterior. Ele não pode ler o calendário de disponibilidade de um hotel. Ele não pode ver a taxa de câmbio atual. Ele não pode verificar que um hóspede realmente fez check-in.

Um oráculo é a ponte entre a blockchain e a realidade. Ele alimenta dados externos (preços, eventos, verificação, identidade) em contratos inteligentes para que eles possam agir com base nisso. Se o oráculo mentir ou quebrar, o contrato agirá com base em informações ruins. É por isso que o design de oráculos é um dos problemas de maior risco na engenharia de blockchain.

O que precisávamos que nossos oráculos fizessem

Os contratos inteligentes da Tratok lidam com muitas decisões todos os dias. Reembolsos, confirmações de reservas, precificação dinâmica, resolução de disputas. Cada um precisa de dados externos confiáveis:

O trade-off, apresentado honestamente

Redes oráculo de propósito geral são projetadas para dados de propósito geral. Elas otimizam para amplitude (feeds de preços para cada ativo, cada cadeia) e fizeram um trabalho brilhante nisso. Mas essa amplitude significa que elas estão necessariamente uma ou duas camadas de abstração acima da lógica de domínio específica que precisávamos.

Para nós, essa lacuna se transformou em três problemas reais:

Latência. Uma decisão de reserva acontece em segundos. Um hóspede está em uma página, ele clica, ele espera uma confirmação. O round-tripping de dados através de uma rede oráculo de propósito geral adiciona latência que não podíamos custear para as operações de caminho crítico. Precisávamos de tempos de resposta sub-segundo em consultas de disponibilidade e preços.

Custo em escala. Cada chamada de oráculo tem um custo. Para uma plataforma que está mirando milhões de transações por mês, pagar taxas por consulta a uma rede de terceiros teria invertido nossa economia. As economias que estamos devolvendo aos provedores e consumidores dependem de manter o custo unitário de cada transação próximo de zero.

Personalização de domínio. Uma “confirmação de check-in de propriedade” não é uma primitiva de oráculo padrão. Nem é “arbitragem de disputa em um reembolso parcial.” Construir isso em cima de uma rede de feed genérica é possível, mas você acaba escrevendo tanta lógica personalizada ao redor do oráculo que você está efetivamente executando metade de um de qualquer forma. Decidimos simplesmente escrever a coisa inteira.

O que construímos em vez disso: GHOST

GHOST é nosso protocolo de oráculo proprietário, construído especificamente para dados de hospitalidade e viagem. O nome não significa nada pretensioso; é curto e nossa equipe de backend gostou dele.

Algumas coisas que GHOST nos proporciona que oráculos de propósito geral não podem:

• Sub-caminho crítico em sub-segundo. Consultas de disponibilidade e preços retornam em milissegundos porque são nativas do sistema, não roteadas.
• Estruturas de dados com reconhecimento de domínio. O protocolo fala “reserva,” “plano de tarifa,” “política de cancelamento,” “evento de check-in,” não apenas feeds numéricos genéricos.
• Escalonamento de custos. O custo marginal do oráculo se aproxima de zero em alto volume, que é a única maneira pela qual as economias do provedor de 28 a 36 por cento são sustentáveis.
• Agregação de múltiplas fontes. GHOST agrega inventário e precificação de nossa rede que abrange milhares de propriedades. A lógica de agregação é ajustada especificamente para o caso de uso da hotelaria.
• Auditoria independente. Todo o sistema passou por auditorias de segurança independentes como parte de nosso processo mais amplo de revisão de contratos inteligentes.

O que abrimos mão

Quero ser honesto sobre isso. Tornar-se proprietária não é gratuito. Aceitamos três custos reais:

Não obtemos a segurança de efeito de rede de um grande conjunto de validadores descentralizados fora da caixa. Compensamos com auditorias, governança multi-assinatura no protocolo e um programa de bug bounty continuamente atualizado, mas é um modelo de confiança diferente. Reconhecemos abertamente.

Nós carregamos o peso da engenharia. Cada atualização de protocolo, cada patch de segurança, cada novo tipo de dado. Isso fica por nossa conta. Com o Chainlink, muito desse carregamento pesado é compartilhado em todo o ecossistema.

Não obtemos interoperabilidade gratuita com o ecossistema DeFi mais amplo. Se queremos integrar com um protocolo DeFi que espera feeds da Chainlink, temos que construir pontes. Já fizemos parte disso e faremos mais.

A aposta, em uma frase

Para uma plataforma cuja proposição de valor central depende de custo marginal de transação quase zero e decisões de reserva em milissegundos, possuir a camada de dados foi a escolha certa. Mesmo com a carga de engenharia que isso traz.

Essa aposta pode não ser a certa para todo projeto de blockchain. Para um protocolo DeFi ou uma plataforma de ativos sintéticos, a resposta quase sempre é Chainlink. Mas hotelaria é um domínio com necessidades de dados tão específicas, e tão específica pressão econômica para manter os custos unitários baixos, que o cálculo muda.

Se você está trabalhando em algo onde está ponderando uma decisão semelhante, ficaríamos felizes em comparar notas. O ecossistema de cripto não fala o suficiente sobre essa troca.

— Carol

Gerente de Comunidade, Tratok