Qual é o custo mais doloroso no desenvolvimento de aplicações on-chain? Não é a dificuldade de programar, mas a taxa de combustível que se perde constantemente sempre que os dados são chamados. Especialmente quando o mercado oscila violentamente e exige atualizações de preço de alta frequência, é realmente desconfortável ver o ETH a ser consumido pouco a pouco.

Mas alguma vez pensou que, muitas vezes, os 80% do consumo de gás são, na verdade, um desperdício de dinheiro? A sua aplicação precisa mesmo de enviar novos dados on-chain a cada segundo? Este é o problema que a solução de extração de dados APRO vai resolver hoje – subverte o tradicional "modelo push" com um novo "modelo pull".

A ideia central é, na verdade, muito simples: não se trata de deixar que os dados cheguem à sua porta, mas sim quando precisa de os retomar. Por exemplo, é como pedir comida para levar — uma é que o estafeta entrega uma refeição à sua porta a cada 5 minutos (modo push), e a outra é que faz a sua própria encomenda quando está com muita fome (pull mode). Para a grande maioria dos cenários de aplicação, este último é mais eficiente e tem um custo menor.

Antes de mais, isto é de facto uma "arma para poupar gás".

Para manter os dados sempre atualizados, os oráculos tradicionais enviam regularmente atualizações on-chain, quer precise ou não delas no momento. O modelo de pull da APRO permite que o seu contrato inteligente obtenha proativamente os dados mais recentes apenas em momentos verdadeiramente críticos — como quando um utilizador executa uma transação, liquida ou liquida o contrato no prazo de expiração. O resultado direto disto é uma queda significativa no volume de transações on-chain e no consumo de gás. Para protocolos DeFi com elevada atividade diária, isto pode significar poupar dezenas ou até centenas de ETH em custos operacionais por mês. Não é apenas uma otimização, é uma atualização radical da estrutura de custos operacionais.

Em segundo lugar, pode controlar com que frequência os seus dados são atualizados.

Diferentes cenários de aplicação têm requisitos muito distintos quanto à frescura dos dados. Alguns cenários exigem dados em tempo real, enquanto outros só precisam de ser atualizados a cada hora.