O DuskEVM roda sobre a OP Stack, o que me pegou de surpresa enquanto eu revirava os $DUSK docs dos quais eu assumia que #Dusk @Dusk tinha construído sua camada EVM do zero, dada a ênfase que @DuskFoundation coloca em ferramentas de privacidade customizadas. #DuskEVM Em vez disso, eles optaram por um framework de rollup já existente e acoplaram o settlement ao DuskDS, sua camada separada de disponibilidade de dados. A parte que eu continuo repensando é a ponte: ela é descrita como nativa e sem confiança, sem ativos “wrapped”, sem um custodiante no meio quando a DUSK se move entre DuskDS e DuskEVM. Os validadores apenas executam a nova versão e os saldos continuam automaticamente. Isso é uma alegação maior do que parece — a maioria das “pontes nativas” neste espaço ainda depende de algum multisig ou de um conjunto de relayers quando você olha de perto. Ainda não encontrei o código real do contrato da ponte para ver como as premissas de confiança são aplicadas on-chain; só vi a documentação descrevendo o comportamento. Alguém aqui está rodando um nó validador na atualização do DuskEVM e que realmente acompanhou esse processo de ponte de ponta a ponta? Estou curioso para saber se “sem confiança” se sustenta em condições reais ou se existe alguma etapa de quorum escondida em algum lugar no cliente.