Recentemente, com o aumento do interesse pelo mercado de previsões, decidi estudar as várias soluções de oráculos disponíveis. Afinal, a precisão dos dados on-chain influencia diretamente o sucesso das transações e é crucial para a gestão de posições. Depois de experimentar a solução APRO por um tempo, percebi que há pontos notáveis, e hoje quero compartilhar minhas impressões após usá-la na prática.
O motivo pelo qual comecei a prestar atenção nela é bastante realista — anteriormente, utilizava um serviço de oráculo líder no setor. Honestamente, como padrão da indústria, é estável e confiável, mas o custo é realmente insuportável. Cada chamada de dado exige pagamento, e se as transações forem frequentes, a curva de custos dispara. Depois descobri que a APRO suporta um modelo pull, com uma mecânica de chamadas sob demanda, cuja estrutura de custos é claramente mais amigável, então decidi testar.
No dia de integração, tenho que dizer que a documentação técnica deles é bastante boa, muito mais clara do que esperava. A API ao vivo foi projetada de forma bastante direta, permitindo puxar dados de preços e assinaturas, e fazer a validação na cadeia. Testei um contrato na BNB Chain, chamando a função verifyAndReadLatestPrice, e todo o processo funcionou sem problemas. A latência também foi bastante satisfatória, atendendo às exigências de atualidade de dados de DEXs e protocolos de empréstimo.
Porém, preciso reclamar de uma coisa: embora anunciem suporte para mais de 40 blockchains, na prática, algumas informações de endereços de contratos nessas chains estão incompletas. Por exemplo, para implantar na Base, levei um tempo até conseguir, perguntando na comunidade, o endereço correto do VerifierProxy. Essa parte da documentação realmente precisa de melhorias rápidas, caso contrário, a experiência do desenvolvedor será bastante prejudicada.
Do ponto de vista funcional, a compatibilidade multi-chain da APRO e sua direção de otimização de custos estão corretas, especialmente para cenários de alta frequência de transações. No entanto, a integridade da documentação e a ferramenta de desenvolvimento ainda podem ser aprimoradas.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
9 gostos
Recompensa
9
6
Republicar
Partilhar
Comentar
0/400
BoredApeResistance
· 1h atrás
O custo realmente é a maior parte, aqueles oráculos tradicionais de antes realmente não aguentam
---
A questão da falta de informações de endereço do Base é um pouco chata, o documento precisa ser atualizado rapidamente
---
A abordagem do modelo pull é boa, o pagamento por uso é muito melhor para traders de alta frequência
---
O desempenho na questão da latência é bom, dados confiáveis nos momentos críticos são essenciais, caso contrário, a gestão de posições fica toda bagunçada
---
Suporte a mais de quarenta blockchains soa muito bem, mas se os detalhes não forem completos, a experiência de desenvolvimento vai ser um desastre
---
O design da API ao vivo é bastante simples, esse ponto merece um elogio à APRO
---
Ainda é aquele problema antigo, a divulgação inicial foi forte, mas só ao usar de verdade é que se descobrem várias armadilhas
---
Oráculos estão bastante competitivos agora, mas a acessibilidade de custos realmente é um ponto de entrada interessante
Ver originalResponder0
RektButSmiling
· 8h atrás
A otimização de custos realmente vai ao cerne da questão, as principais instituições estão a comportar-se de forma bastante feia
Falando nisso, as informações de endereço do Base têm que ser descobertas por si próprio, o que é realmente muito Web3
Neste cenário de negociação de alta frequência, este conjunto de modelos de atração ainda é um pouco interessante
A documentação incompleta, na verdade, é uma oportunidade, o ecossistema ainda está na fase inicial
Ver originalResponder0
MidnightGenesis
· 9h atrás
Os dados na cadeia mostram que o custo do modelo pull realmente pode ser reduzido, mas a questão de não ter informações completas de endereços em 40 cadeias é interessante... Pelo código, parece que a equipe oficial talvez não tenha planejado uma implantação completa de ponta a ponta
Ver originalResponder0
MemeCoinSavant
· 9h atrás
Portanto, basicamente pagar por chamada no antigo oracle era apenas coping, e o modelo de pull da APRO é diferente... mas a documentação de implantação do Base sendo ruim é o auge da energia de "40 cadeias suportadas" sinceramente 💀
Ver originalResponder0
ResearchChadButBroke
· 9h atrás
A otimização de custos realmente tocou na dor, mas o assunto do Base mostra que ainda é preciso pisar no próprio calo
Ver originalResponder0
gaslight_gasfeez
· 9h atrás
Os custos podem ser reduzidos à metade, isso é suficiente para eu investir, tudo o mais é negociável
Recentemente, com o aumento do interesse pelo mercado de previsões, decidi estudar as várias soluções de oráculos disponíveis. Afinal, a precisão dos dados on-chain influencia diretamente o sucesso das transações e é crucial para a gestão de posições. Depois de experimentar a solução APRO por um tempo, percebi que há pontos notáveis, e hoje quero compartilhar minhas impressões após usá-la na prática.
O motivo pelo qual comecei a prestar atenção nela é bastante realista — anteriormente, utilizava um serviço de oráculo líder no setor. Honestamente, como padrão da indústria, é estável e confiável, mas o custo é realmente insuportável. Cada chamada de dado exige pagamento, e se as transações forem frequentes, a curva de custos dispara. Depois descobri que a APRO suporta um modelo pull, com uma mecânica de chamadas sob demanda, cuja estrutura de custos é claramente mais amigável, então decidi testar.
No dia de integração, tenho que dizer que a documentação técnica deles é bastante boa, muito mais clara do que esperava. A API ao vivo foi projetada de forma bastante direta, permitindo puxar dados de preços e assinaturas, e fazer a validação na cadeia. Testei um contrato na BNB Chain, chamando a função verifyAndReadLatestPrice, e todo o processo funcionou sem problemas. A latência também foi bastante satisfatória, atendendo às exigências de atualidade de dados de DEXs e protocolos de empréstimo.
Porém, preciso reclamar de uma coisa: embora anunciem suporte para mais de 40 blockchains, na prática, algumas informações de endereços de contratos nessas chains estão incompletas. Por exemplo, para implantar na Base, levei um tempo até conseguir, perguntando na comunidade, o endereço correto do VerifierProxy. Essa parte da documentação realmente precisa de melhorias rápidas, caso contrário, a experiência do desenvolvedor será bastante prejudicada.
Do ponto de vista funcional, a compatibilidade multi-chain da APRO e sua direção de otimização de custos estão corretas, especialmente para cenários de alta frequência de transações. No entanto, a integridade da documentação e a ferramenta de desenvolvimento ainda podem ser aprimoradas.