#dusk $DUSK Eu segui uma linha de um Issue oficial do Dusk e, ao desmontar o que estava por trás, encontrei um risco bem anormal: o contrato consegue executar normalmente, mas a carteira e a exchange podem, de repente, não conseguir interpretá-lo.
O problema está no Data Driver. Ele é um “tradutor” WASM, responsável por pegar os binários que o contrato cospe e transformá-los em valores, saldos, eventos e ações clicáveis. Sem ele, as contas na cadeia continuam lá, mas o front-end recebe apenas uma sequência de bytes de máquina.
A forma de integração reportada é um pouco tortuosa: primeiro conecta ao W3sper para obter informações de sessão; depois sai do SDK e faz uma requisição própria ao endpoint de download do Driver do nó; além disso, precisa checar o arquivo WASM por conta própria. Mesmo com chamadas comuns já lidando com alternância entre múltiplos nós, esse caminho de download ainda precisa ser complementado separadamente com nó reserva e cache.
Ao chegar aqui, eu fiquei meio sem cabeça. Se a cadeia de fato parar, o operador do nó verá a altura não subir; a exchange e a carteira vão acusar timeout. Quando o Driver é perdido, expira ou a versão não bate, a monitoração usual pode ficar toda “normal” até que o saldo fique anormal, o status de saque não consiga ser lido e o resultado da liquidação não dê para conciliar — só então o dinheiro é forçado a parar.
Por isso, eu sugiro o seguinte: não basta testar se contratos Dusk funcionam apenas para verificar se a transação conclui. Também é preciso, de propósito, cortar o principal RPC durante o download do Driver e ver se consegue alternar para o nó reserva; depois verificar se o Driver está vinculado à versão do contrato, se após uma queda a leitura volta a funcionar, e se caches antigos podem continuar interpretando incorretamente um contrato novo.
Quanto a $DUSK , por enquanto eu não vou elevar a avaliação só porque aumentou o número de contratos. Disponibilidade do Driver, compatibilidade entre versão e hash do contrato, taxa de sucesso da recuperação em nó reserva, e quanto tempo leva após uma falha para voltar a ler os dados — tudo isso está mais perto da receita real.
A máquina executa as regras e isso só prova que a entrega técnica foi concluída. O mercado paga Gas a longo prazo porque conta que todos os pontos de entrada consigam pegar a mesma sequência de bytes e interpretá-la como a mesma quantia de dinheiro.
@Dusk_Foundation
$BTC
O problema está no Data Driver. Ele é um “tradutor” WASM, responsável por pegar os binários que o contrato cospe e transformá-los em valores, saldos, eventos e ações clicáveis. Sem ele, as contas na cadeia continuam lá, mas o front-end recebe apenas uma sequência de bytes de máquina.
A forma de integração reportada é um pouco tortuosa: primeiro conecta ao W3sper para obter informações de sessão; depois sai do SDK e faz uma requisição própria ao endpoint de download do Driver do nó; além disso, precisa checar o arquivo WASM por conta própria. Mesmo com chamadas comuns já lidando com alternância entre múltiplos nós, esse caminho de download ainda precisa ser complementado separadamente com nó reserva e cache.
Ao chegar aqui, eu fiquei meio sem cabeça. Se a cadeia de fato parar, o operador do nó verá a altura não subir; a exchange e a carteira vão acusar timeout. Quando o Driver é perdido, expira ou a versão não bate, a monitoração usual pode ficar toda “normal” até que o saldo fique anormal, o status de saque não consiga ser lido e o resultado da liquidação não dê para conciliar — só então o dinheiro é forçado a parar.
Por isso, eu sugiro o seguinte: não basta testar se contratos Dusk funcionam apenas para verificar se a transação conclui. Também é preciso, de propósito, cortar o principal RPC durante o download do Driver e ver se consegue alternar para o nó reserva; depois verificar se o Driver está vinculado à versão do contrato, se após uma queda a leitura volta a funcionar, e se caches antigos podem continuar interpretando incorretamente um contrato novo.
Quanto a $DUSK , por enquanto eu não vou elevar a avaliação só porque aumentou o número de contratos. Disponibilidade do Driver, compatibilidade entre versão e hash do contrato, taxa de sucesso da recuperação em nó reserva, e quanto tempo leva após uma falha para voltar a ler os dados — tudo isso está mais perto da receita real.
A máquina executa as regras e isso só prova que a entrega técnica foi concluída. O mercado paga Gas a longo prazo porque conta que todos os pontos de entrada consigam pegar a mesma sequência de bytes e interpretá-la como a mesma quantia de dinheiro.
@Dusk_Foundation
$BTC