#dusk $DUSK @Dusk
Ehsan me perguntou algo durante o jantar que me fez repensar um detalhe de Dusk
Por que um desenvolvedor deveria presumir que tempo suficiente passou significa que um estado econômico está pronto para uso?
Isso parece simples, mas se torna importante quando execução e liquidação são separadas. O DuskDS fornece a base de liquidação, finalidade e disponibilidade de dados, enquanto o DuskVM executa contratos Rust/WASM diretamente na L1 e o DuskEVM fornece execução EVM liquidada via DuskDS.
A parte interessante é que a ponte da Dusk não trata o tempo como o primitivo de segurança.
Uma retirada do DuskEVM passa por estágios distintos: iniciação, prova e finalização. Se a próxima ação está pronta depende do estado de rede publicado, da maturidade da prova e das verificações do dispute-game. A documentação diz explicitamente para os desenvolvedores não calcularem prontidão apenas a partir do tempo decorrido.
Esse detalhe tem uma implicação maior do que a própria ponte.
Em infraestrutura financeira, desenvolvedores muitas vezes transformam processos assíncronos em lógica de aplicação simples: esperar X minutos e, então, presumir que o estado está seguro para consumir. Mas se a prontidão do protocolo depende do estado e das provas em vez de um relógio fixo, esse atalho pode criar um risco de integração oculto.
A aplicação pode estar perfeitamente correta sobre a transação que enviou, enquanto está errada sobre quando a consequência econômica dela se tornou utilizável.
Essa é a distinção que considero valiosa em Dusk. A finalidade não é apenas um carimbo de data/hora anexado a uma transação. Para sistemas entre ambientes, ela se torna um estado definido pelo Protocolo que as aplicações precisam ler e respeitar.
À medida que a Dusk expande suas camadas de execução, acho que isso se torna um princípio importante para desenvolvedores
Os estados de prontidão definidos pelo Protocolo deveriam se tornar uma interface de primeira classe para aplicações financeiras, em vez de deixar integradores inferirem a finalidade a partir do tempo e do status da transação? ⚙️
@Binance Square Official $SOL
Ehsan me perguntou algo durante o jantar que me fez repensar um detalhe de Dusk
Por que um desenvolvedor deveria presumir que tempo suficiente passou significa que um estado econômico está pronto para uso?
Isso parece simples, mas se torna importante quando execução e liquidação são separadas. O DuskDS fornece a base de liquidação, finalidade e disponibilidade de dados, enquanto o DuskVM executa contratos Rust/WASM diretamente na L1 e o DuskEVM fornece execução EVM liquidada via DuskDS.
A parte interessante é que a ponte da Dusk não trata o tempo como o primitivo de segurança.
Uma retirada do DuskEVM passa por estágios distintos: iniciação, prova e finalização. Se a próxima ação está pronta depende do estado de rede publicado, da maturidade da prova e das verificações do dispute-game. A documentação diz explicitamente para os desenvolvedores não calcularem prontidão apenas a partir do tempo decorrido.
Esse detalhe tem uma implicação maior do que a própria ponte.
Em infraestrutura financeira, desenvolvedores muitas vezes transformam processos assíncronos em lógica de aplicação simples: esperar X minutos e, então, presumir que o estado está seguro para consumir. Mas se a prontidão do protocolo depende do estado e das provas em vez de um relógio fixo, esse atalho pode criar um risco de integração oculto.
A aplicação pode estar perfeitamente correta sobre a transação que enviou, enquanto está errada sobre quando a consequência econômica dela se tornou utilizável.
Essa é a distinção que considero valiosa em Dusk. A finalidade não é apenas um carimbo de data/hora anexado a uma transação. Para sistemas entre ambientes, ela se torna um estado definido pelo Protocolo que as aplicações precisam ler e respeitar.
À medida que a Dusk expande suas camadas de execução, acho que isso se torna um princípio importante para desenvolvedores
Os estados de prontidão definidos pelo Protocolo deveriam se tornar uma interface de primeira classe para aplicações financeiras, em vez de deixar integradores inferirem a finalidade a partir do tempo e do status da transação? ⚙️
@Binance Square Official $SOL