Certo, desenhei uma imagem de como isso funciona e por que é diferente // um modelo totalmente novo. Preços o mais frescos possível, iniciação de transações eficiente (feita apenas quando necessário) e composabilidade onchain. Vitórias em todos os lugares. Para referência, é assim que os oráculos pull tradicionais funcionam com o mesmo trabalho delineado sendo necessário: - [1] Deve incluir o trabalho feito de [2] - [2] O trabalho é adicionado à carga de trabalho do desenvolvedor - [4] não é possível ou disponível para contratos não-Euphoria, pois os dados de preços são conhecidos apenas pelo aplicativo iniciador de [1] - [5] depende da implementação do aplicativo, enquanto é ~sempre ótimo para uma implementação nativa Como @ChainLinkGod chamou, isso é "frontrunning com valor agregado." Poucas equipes estão se inclinando para o superpoder de uma construção de sequenciador. Vamos maximizar isso.

Para uma completude visual, aqui está como um oracle de pull funciona de outra forma: