Recentemente, foi descoberto um fenómeno doloroso: uma série de desenvolvedores de contratos inteligentes, ao integrar oráculos de topo como o Apro, pensam apenas "é só conectar e pronto" — como se um problema na fonte de dados pudesse ser facilmente transferido para outro.
Sonho. A verdade é muito mais dura: no momento em que você conecta à fonte de dados, você se torna a última linha de defesa. O oráculo fornece "fatos verificados na cadeia", mas como esses fatos são usados, em que forma, tudo depende de você.
Para usar uma metáfora: um hospital compra uma faca cirúrgica estéril importada, a própria faca não tem defeito, mas se o paciente morrer na mesa de cirurgia, você pode culpar a faca? Claramente, não. O problema está na habilidade do médico, não na ferramenta.
Os desenvolvedores devem lembrar-se destas quatro regras de ferro:
**Primeira: Dados são apenas matéria-prima, o desenvolvedor é o verdadeiro capitão**
O Apro fornece matéria-prima de alta qualidade, validada de forma descentralizada. Mas se você tornar a comida salgada demais, queimar, ou os usuários enfrentarem problemas ao consumi-la — isso é sua responsabilidade. É necessário montar um sistema de monitoramento da qualidade dos dados.
Por exemplo, se o preço subir ou despencar repentinamente, ultrapassando a faixa de volatilidade teórica, seu contrato tem mecanismo de circuit breaker? Ou você deixa esse preço anormal disparar liquidações em massa? Quando a rede apresenta problemas ou há atraso nos dados, sua aplicação fica esperando passivamente, ou muda automaticamente para um plano de segurança de backup? Essas coisas o fonte de dados não cobre.
**Segunda: A qualidade do código decide tudo**
A melhor das fontes de dados, se for acompanhada de código cheio de vulnerabilidades, resulta em desastre. Você não pode usar uma função que não passou por testes rigorosos, com risco de estouro de memória, para lidar com informações de preços envolvendo dinheiro de verdade.
Resumindo, o nível do seu código deve estar à altura da fonte de dados que você escolheu. Isso não é opcional, é fundamental.
Ver original
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.
Recentemente, foi descoberto um fenómeno doloroso: uma série de desenvolvedores de contratos inteligentes, ao integrar oráculos de topo como o Apro, pensam apenas "é só conectar e pronto" — como se um problema na fonte de dados pudesse ser facilmente transferido para outro.
Sonho. A verdade é muito mais dura: no momento em que você conecta à fonte de dados, você se torna a última linha de defesa. O oráculo fornece "fatos verificados na cadeia", mas como esses fatos são usados, em que forma, tudo depende de você.
Para usar uma metáfora: um hospital compra uma faca cirúrgica estéril importada, a própria faca não tem defeito, mas se o paciente morrer na mesa de cirurgia, você pode culpar a faca? Claramente, não. O problema está na habilidade do médico, não na ferramenta.
Os desenvolvedores devem lembrar-se destas quatro regras de ferro:
**Primeira: Dados são apenas matéria-prima, o desenvolvedor é o verdadeiro capitão**
O Apro fornece matéria-prima de alta qualidade, validada de forma descentralizada. Mas se você tornar a comida salgada demais, queimar, ou os usuários enfrentarem problemas ao consumi-la — isso é sua responsabilidade. É necessário montar um sistema de monitoramento da qualidade dos dados.
Por exemplo, se o preço subir ou despencar repentinamente, ultrapassando a faixa de volatilidade teórica, seu contrato tem mecanismo de circuit breaker? Ou você deixa esse preço anormal disparar liquidações em massa? Quando a rede apresenta problemas ou há atraso nos dados, sua aplicação fica esperando passivamente, ou muda automaticamente para um plano de segurança de backup? Essas coisas o fonte de dados não cobre.
**Segunda: A qualidade do código decide tudo**
A melhor das fontes de dados, se for acompanhada de código cheio de vulnerabilidades, resulta em desastre. Você não pode usar uma função que não passou por testes rigorosos, com risco de estouro de memória, para lidar com informações de preços envolvendo dinheiro de verdade.
Resumindo, o nível do seu código deve estar à altura da fonte de dados que você escolheu. Isso não é opcional, é fundamental.