Crypto knowledge P
164 Publicações
Crypto knowledge P
15 A seguir
1.4K+ Seguidores
518 Gostaram
Publicações
🎁🎁Resgate de envelope rápido 🎁🎁
Uma conexão da carteira Dusk parece ser um simples clique. Mas quando comecei a ver o que existe por trás disso, percebi que há bastante coisa acontecendo.
Passei primeiro pelo fluxo de descoberta da carteira. Uma dApp não simplesmente pega qualquer carteira Dusk que esteja na página. As carteiras se anunciam, a dApp as descobre e, se houver mais de uma instalada, um provedor precisa ser selecionado. Cada uma também carrega sua própria identidade. É um detalhe pequeno, mas importa porque o site precisa saber com qual carteira ele está realmente falando.
Depois olhei para o lado das permissões. Uma solicitação de perfil, um endereço de recebimento protegido, uma transação, uma chamada de contrato ou uma assinatura não são todas a mesma coisa. Elas passam por diferentes solicitações da carteira, e a carteira também pode reportar alterações de perfil, de chain e do nó selecionado enquanto a conexão está ativa. Então “conectado” não significa, de fato, que a dApp tenha acesso ilimitado.
A parte de assinatura foi a que achei mais interessante. A Dusk coloca a origem e o ID da chain no contexto da mensagem assinada. A assinatura de autenticação também leva um nonce e timestamps. Portanto, a assinatura não é apenas “esta conta assinou algo” — existe também um contexto ao redor da solicitação.
Também verifiquei as mudanças recentes na carteira relacionadas a isso. Mensagens de provider foram restringidas para que outro provedor Dusk instalado não consiga receber a mesma solicitação da dApp. O tratamento de origem e permissões foi reforçado, e conexões da RPC da dApp e de nós personalizados foram restritas a endpoints HTTPS ou de desenvolvimento local. As próprias notas de segurança da Dusk também mencionam limites como a memória do JavaScript não ser apagável de forma confiável.
Para mim, isso muda como o pequeno botão “Conectar carteira” parece. Na prática, não é uma única permissão. Existe uma camada inteira entre o site e a chave decidindo qual carteira está sendo usada, o que a dApp pode solicitar e o que o usuário realmente assina.
$DUSK @Dusk #dusk
Passei primeiro pelo fluxo de descoberta da carteira. Uma dApp não simplesmente pega qualquer carteira Dusk que esteja na página. As carteiras se anunciam, a dApp as descobre e, se houver mais de uma instalada, um provedor precisa ser selecionado. Cada uma também carrega sua própria identidade. É um detalhe pequeno, mas importa porque o site precisa saber com qual carteira ele está realmente falando.
Depois olhei para o lado das permissões. Uma solicitação de perfil, um endereço de recebimento protegido, uma transação, uma chamada de contrato ou uma assinatura não são todas a mesma coisa. Elas passam por diferentes solicitações da carteira, e a carteira também pode reportar alterações de perfil, de chain e do nó selecionado enquanto a conexão está ativa. Então “conectado” não significa, de fato, que a dApp tenha acesso ilimitado.
A parte de assinatura foi a que achei mais interessante. A Dusk coloca a origem e o ID da chain no contexto da mensagem assinada. A assinatura de autenticação também leva um nonce e timestamps. Portanto, a assinatura não é apenas “esta conta assinou algo” — existe também um contexto ao redor da solicitação.
Também verifiquei as mudanças recentes na carteira relacionadas a isso. Mensagens de provider foram restringidas para que outro provedor Dusk instalado não consiga receber a mesma solicitação da dApp. O tratamento de origem e permissões foi reforçado, e conexões da RPC da dApp e de nós personalizados foram restritas a endpoints HTTPS ou de desenvolvimento local. As próprias notas de segurança da Dusk também mencionam limites como a memória do JavaScript não ser apagável de forma confiável.
Para mim, isso muda como o pequeno botão “Conectar carteira” parece. Na prática, não é uma única permissão. Existe uma camada inteira entre o site e a chave decidindo qual carteira está sendo usada, o que a dApp pode solicitar e o que o usuário realmente assina.
$DUSK @Dusk #dusk
Verificado
Acho que geralmente estamos fazendo a pergunta errada quando uma transação Dusk “falha”.
Uma resposta 202 Accepted só significa que o nó aceitou a solicitação para roteamento. Isso não quer dizer que a transação já esteja no mempool ou em um bloco. Um exemplo que achei interessante é um nonce futuro. Se uma transação Moonlight chegar com um nonce futuro enquanto um nonce anterior ainda está faltando, o Dusk pode mantê-la fora do mempool real e esperar o intervalo de nonce ser fechado em vez de rejeitá-la imediatamente. Nesse período, ela fica em um estado adiado.
Isso é apenas uma parte da história. Depois que uma transação passa pela admissão, ela entra no mempool local daquele nó. Outros nós mantêm seus próprios mempools e executam suas próprias verificações de admissão também. Mais tarde, uma transação pode ser selecionada para um bloco, executada e, eventualmente, finalizada. Ela também pode sair do mempool local sem que isso automaticamente signifique que falhou. Expiração, substituição, limites de capacidade e conflitos podem levar à remoção.
É aqui que acho que a diferença importa para carteiras e exchanges. A orientação de integração do próprio Dusk diz para manter a transação assinada exata, tratar 202 Accepted apenas como roteamento bem-sucedido e reenviar os mesmos bytes assinados após um timeout de transporte, em vez de criar uma nova transação de forma cega. Uma retirada deve ser marcada como concluída somente depois que a execução for verificada e o bloco for finalizado.
Quanto mais eu olhava para isso, menos “transação enviada” parecia um status útil por si só. Uma transação pode estar esperando um nonce, parada no mempool de um nó, executada com erro, ou parada em um bloco que ainda não é final. Essas são situações bem diferentes, mesmo que todas possam parecer “ainda está pendente” do lado de fora.
Para mim, esse é o aprendizado útil do fluxo de transações do Dusk: enviada é só o começo. O que importa é o estado que você realmente consegue comprovar que a transação chegou.
$DUSK @Dusk #dusk
Uma resposta 202 Accepted só significa que o nó aceitou a solicitação para roteamento. Isso não quer dizer que a transação já esteja no mempool ou em um bloco. Um exemplo que achei interessante é um nonce futuro. Se uma transação Moonlight chegar com um nonce futuro enquanto um nonce anterior ainda está faltando, o Dusk pode mantê-la fora do mempool real e esperar o intervalo de nonce ser fechado em vez de rejeitá-la imediatamente. Nesse período, ela fica em um estado adiado.
Isso é apenas uma parte da história. Depois que uma transação passa pela admissão, ela entra no mempool local daquele nó. Outros nós mantêm seus próprios mempools e executam suas próprias verificações de admissão também. Mais tarde, uma transação pode ser selecionada para um bloco, executada e, eventualmente, finalizada. Ela também pode sair do mempool local sem que isso automaticamente signifique que falhou. Expiração, substituição, limites de capacidade e conflitos podem levar à remoção.
É aqui que acho que a diferença importa para carteiras e exchanges. A orientação de integração do próprio Dusk diz para manter a transação assinada exata, tratar 202 Accepted apenas como roteamento bem-sucedido e reenviar os mesmos bytes assinados após um timeout de transporte, em vez de criar uma nova transação de forma cega. Uma retirada deve ser marcada como concluída somente depois que a execução for verificada e o bloco for finalizado.
Quanto mais eu olhava para isso, menos “transação enviada” parecia um status útil por si só. Uma transação pode estar esperando um nonce, parada no mempool de um nó, executada com erro, ou parada em um bloco que ainda não é final. Essas são situações bem diferentes, mesmo que todas possam parecer “ainda está pendente” do lado de fora.
Para mim, esse é o aprendizado útil do fluxo de transações do Dusk: enviada é só o começo. O que importa é o estado que você realmente consegue comprovar que a transação chegou.
$DUSK @Dusk #dusk
Verificado
As 280 transferências chamaram minha atenção, mas acabei prestando mais atenção em tudo ao redor delas.
Revisei o trabalho mais recente de aprovação (sign off) da Dusk Hyperlane e os testes até agora parecem sólidos. A reprodução limpa mais recente passou nas builds do contrato, nos testes de VM, nos testes de transações e nas verificações dos agentes Hyperlane. Em seguida, o soak de alto volume rodou por 7 ciclos, com 20 transferências de EVM para Dusk e 20 de Dusk para EVM em cada ciclo. Isso totalizou 280 transferências ao longo de 7.282 segundos antes de a janela de teste de 120 minutos terminar.
O que considerei mais importante foi a lista de verificação de produção ao lado desses resultados. A custódia do signer de produção ainda está sendo decidida. Também há uma decisão em aberto sobre a recuperação do escrow pendente, por quanto tempo o soak deve rodar e como a configuração de CI e reprodutibilidade deve funcionar. Isso é fácil de ignorar quando o número principal é um teste bem-sucedido, mas são exatamente as coisas que eu gostaria de entender antes de haver liquidez real.
A questão do signer é especialmente difícil de ignorar depois do que aconteceu com a antiga ponte Dusk para EVM em janeiro. Um atacante obteve acesso à carteira de assinatura da ponte, roubou DUSK dela e moveu parte dos fundos roubados pela ponte para a BNB Smart Chain. A Dusk deixou claro que o incidente foi uma falha na carteira da ponte, não um problema de consenso do Dusk nem uma exploração do protocolo. A ponte foi redesenhada depois, com uma separação mais forte entre assinatura, tratamento de eventos e liberação de fundos, além de controles mais rígidos de saldo e recuperação.
Então eu não estou vendo as 280 transferências como um sinal verde ou uma bandeira vermelha. Elas mostram que o sistema está sendo testado com seriedade. O que importa para mim agora é como o sistema deve se comportar quando algo dá errado, quem controla as partes sensíveis e como a recuperação é tratada.
É isso que eu gostaria de ter definido antes de tratar a Dusk Hyperlane como infraestrutura para uma liquidez relevante.
$DUSK @Dusk #dusk
Revisei o trabalho mais recente de aprovação (sign off) da Dusk Hyperlane e os testes até agora parecem sólidos. A reprodução limpa mais recente passou nas builds do contrato, nos testes de VM, nos testes de transações e nas verificações dos agentes Hyperlane. Em seguida, o soak de alto volume rodou por 7 ciclos, com 20 transferências de EVM para Dusk e 20 de Dusk para EVM em cada ciclo. Isso totalizou 280 transferências ao longo de 7.282 segundos antes de a janela de teste de 120 minutos terminar.
O que considerei mais importante foi a lista de verificação de produção ao lado desses resultados. A custódia do signer de produção ainda está sendo decidida. Também há uma decisão em aberto sobre a recuperação do escrow pendente, por quanto tempo o soak deve rodar e como a configuração de CI e reprodutibilidade deve funcionar. Isso é fácil de ignorar quando o número principal é um teste bem-sucedido, mas são exatamente as coisas que eu gostaria de entender antes de haver liquidez real.
A questão do signer é especialmente difícil de ignorar depois do que aconteceu com a antiga ponte Dusk para EVM em janeiro. Um atacante obteve acesso à carteira de assinatura da ponte, roubou DUSK dela e moveu parte dos fundos roubados pela ponte para a BNB Smart Chain. A Dusk deixou claro que o incidente foi uma falha na carteira da ponte, não um problema de consenso do Dusk nem uma exploração do protocolo. A ponte foi redesenhada depois, com uma separação mais forte entre assinatura, tratamento de eventos e liberação de fundos, além de controles mais rígidos de saldo e recuperação.
Então eu não estou vendo as 280 transferências como um sinal verde ou uma bandeira vermelha. Elas mostram que o sistema está sendo testado com seriedade. O que importa para mim agora é como o sistema deve se comportar quando algo dá errado, quem controla as partes sensíveis e como a recuperação é tratada.
É isso que eu gostaria de ter definido antes de tratar a Dusk Hyperlane como infraestrutura para uma liquidez relevante.
$DUSK @Dusk #dusk
Parcialmente verdadeiro
Uma coisinha sobre as transações do Dusk que vinha me incomodando.
Eu estava lendo o fluxo de transações do Dusk e descobri que, atualmente, uma transação carrega uma única operação. Para algo básico, isso faz bastante sentido. Facilita validar e entender. Mas aí pensei em um fluxo DeFi mais complexo, como preparar fundos, fazer uma troca e depois fazer staking. Para o usuário, isso parece uma única ação. No Dusk, isso vira várias transações separadas, cada uma com seu próprio nonce, assinatura e chance de ser incluída.
Foi aí que comecei a me perguntar o que acontece se apenas parte da sequência for concluída. Não existe rollback no nível do protocolo entre essas transações, então você pode acabar no meio de um fluxo maior. Para uma negociação normal, provavelmente não é um grande problema. Mas para DeFi, liquidações ou operações de tesouraria, eu consigo ver isso se tornando um verdadeiro incômodo.
O que achei interessante é que o Dusk já tem uma issue aberta no GitHub, #4058, discutindo transações em lote (batch). Uma ideia é ter um contrato agregador que coloca várias chamadas em uma única transação, mas contratos que usam caller() poderiam ver o agregador em vez do usuário original. A outra opção é um batch no nível do protocolo, em que múltiplas operações permanecem sob a identidade do usuário, mas isso exigiria mudanças no formato da transação, suporte no consenso, ativação de hard fork e SDKs.
Então eu não substituiria o modelo atual de uma única operação. Acho que ele faz sentido como padrão simples. Eu preferiria ver um batch atômico opcional para fluxos complexos, em que as operações rodem em ordem, o lote inteiro possa reverter se uma falhar, e o usuário original permaneça visível para cada chamada.
Esse seria o equilíbrio certo para o Dusk, ou a complexidade extra no protocolo não vale a pena?
$DUSK @Dusk #dusk
Eu estava lendo o fluxo de transações do Dusk e descobri que, atualmente, uma transação carrega uma única operação. Para algo básico, isso faz bastante sentido. Facilita validar e entender. Mas aí pensei em um fluxo DeFi mais complexo, como preparar fundos, fazer uma troca e depois fazer staking. Para o usuário, isso parece uma única ação. No Dusk, isso vira várias transações separadas, cada uma com seu próprio nonce, assinatura e chance de ser incluída.
Foi aí que comecei a me perguntar o que acontece se apenas parte da sequência for concluída. Não existe rollback no nível do protocolo entre essas transações, então você pode acabar no meio de um fluxo maior. Para uma negociação normal, provavelmente não é um grande problema. Mas para DeFi, liquidações ou operações de tesouraria, eu consigo ver isso se tornando um verdadeiro incômodo.
O que achei interessante é que o Dusk já tem uma issue aberta no GitHub, #4058, discutindo transações em lote (batch). Uma ideia é ter um contrato agregador que coloca várias chamadas em uma única transação, mas contratos que usam caller() poderiam ver o agregador em vez do usuário original. A outra opção é um batch no nível do protocolo, em que múltiplas operações permanecem sob a identidade do usuário, mas isso exigiria mudanças no formato da transação, suporte no consenso, ativação de hard fork e SDKs.
Então eu não substituiria o modelo atual de uma única operação. Acho que ele faz sentido como padrão simples. Eu preferiria ver um batch atômico opcional para fluxos complexos, em que as operações rodem em ordem, o lote inteiro possa reverter se uma falhar, e o usuário original permaneça visível para cada chamada.
Esse seria o equilíbrio certo para o Dusk, ou a complexidade extra no protocolo não vale a pena?
$DUSK @Dusk #dusk
#dusk $DUSK @Dusk
Tenho observado recentemente o lado das PME da Dusk e uma coisa tem voltado para mim.
Tokenizar uma PME parece simples quando você diz isso em uma linha.
Coloque o ativo onchain.
Permita que investidores acessem.
Pronto.
Mas não é tão simples.
Ainda é alguém quem precisa decidir quem pode investir, como a propriedade é tratada, como as transferências funcionam, que informações precisam ser divulgadas e como o dinheiro em si é efetivamente liquidado.
E é aqui que eu acho que às vezes as pessoas subestimam o problema de RWA.
O token em si é apenas uma parte do processo. O mercado ao redor dele ainda precisa funcionar.
É aí que a abordagem da Dusk fica interessante para mim.
O foco recente deles em mercados privados e PMEs não é, na verdade, sobre colocar mais um ativo em uma blockchain apenas por colocar.
É mais sobre conectar as diferentes partes do processo.
Porque a parte difícil não é criar o token.
A parte difícil é tornar o token utilizável.
Uma PME pode ter uma segurança tokenizada, mas se os investidores não conseguirem acessá-la corretamente, se as transferências forem complicadas ou se não houver um mercado real ao redor disso, então não muda muita coisa.
É também por isso que estou curioso para ver como o lado Dusk Trade evolui.
Se ele puder tornar o processo mais simples tanto para as empresas quanto para os investidores, então isso passa a ser mais interessante do que apenas mais uma narrativa de RWA.
Ainda é cedo.
Para mim, o teste real é simples:
A Dusk consegue tornar os mercados privados realmente mais fáceis de usar, ou estamos apenas colocando um processo antigo onchain e chamando isso de novo?
É essa a parte que vou observar de perto enquanto o Dusk Trade começa a ganhar forma.
Tenho observado recentemente o lado das PME da Dusk e uma coisa tem voltado para mim.
Tokenizar uma PME parece simples quando você diz isso em uma linha.
Coloque o ativo onchain.
Permita que investidores acessem.
Pronto.
Mas não é tão simples.
Ainda é alguém quem precisa decidir quem pode investir, como a propriedade é tratada, como as transferências funcionam, que informações precisam ser divulgadas e como o dinheiro em si é efetivamente liquidado.
E é aqui que eu acho que às vezes as pessoas subestimam o problema de RWA.
O token em si é apenas uma parte do processo. O mercado ao redor dele ainda precisa funcionar.
É aí que a abordagem da Dusk fica interessante para mim.
O foco recente deles em mercados privados e PMEs não é, na verdade, sobre colocar mais um ativo em uma blockchain apenas por colocar.
É mais sobre conectar as diferentes partes do processo.
Porque a parte difícil não é criar o token.
A parte difícil é tornar o token utilizável.
Uma PME pode ter uma segurança tokenizada, mas se os investidores não conseguirem acessá-la corretamente, se as transferências forem complicadas ou se não houver um mercado real ao redor disso, então não muda muita coisa.
É também por isso que estou curioso para ver como o lado Dusk Trade evolui.
Se ele puder tornar o processo mais simples tanto para as empresas quanto para os investidores, então isso passa a ser mais interessante do que apenas mais uma narrativa de RWA.
Ainda é cedo.
Para mim, o teste real é simples:
A Dusk consegue tornar os mercados privados realmente mais fáceis de usar, ou estamos apenas colocando um processo antigo onchain e chamando isso de novo?
É essa a parte que vou observar de perto enquanto o Dusk Trade começa a ganhar forma.
Tenho olhado mais a fundo para como o Dusk lida com transações, e percebi algo que eu não tinha pensado antes.
Moonlight e Phoenix não são apenas duas versões da mesma coisa.
Moonlight é baseado em contas. Você tem uma conta, saldo, nonce e chaves, e a rede verifica a transação com base nesse estado.
Phoenix adota uma abordagem diferente.
Ele usa notas armazenadas em uma árvore de Merkle. Quando uma nota é gasta, é criado um nullifier para que a mesma nota não possa ser gasta de novo.
O que chamou minha atenção é que a rede não precisa revelar qual nota específica foi gasta.
É aí que entram as provas ZK — a transação pode ser verificada sem expor os detalhes privados subjacentes. As chaves das notas de uso único também ajudam a reduzir a vinculabilidade das transações.
Também existe um mecanismo de delegação para coisas como varredura e geração de prova, sem dar ao delegado acesso para gastar os fundos.
Então eu não descreveria isso apenas como “Moonlight é transparente e Phoenix é privado”.
Eles são modelos de transação diferentes, criados para atender requisitos distintos, enquanto operam na mesma rede do Dusk.
E, honestamente, acho que essa é uma escolha de design bem interessante.
Qual você preferiria no Dusk?
@Dusk $DUSK #dusk
Moonlight e Phoenix não são apenas duas versões da mesma coisa.
Moonlight é baseado em contas. Você tem uma conta, saldo, nonce e chaves, e a rede verifica a transação com base nesse estado.
Phoenix adota uma abordagem diferente.
Ele usa notas armazenadas em uma árvore de Merkle. Quando uma nota é gasta, é criado um nullifier para que a mesma nota não possa ser gasta de novo.
O que chamou minha atenção é que a rede não precisa revelar qual nota específica foi gasta.
É aí que entram as provas ZK — a transação pode ser verificada sem expor os detalhes privados subjacentes. As chaves das notas de uso único também ajudam a reduzir a vinculabilidade das transações.
Também existe um mecanismo de delegação para coisas como varredura e geração de prova, sem dar ao delegado acesso para gastar os fundos.
Então eu não descreveria isso apenas como “Moonlight é transparente e Phoenix é privado”.
Eles são modelos de transação diferentes, criados para atender requisitos distintos, enquanto operam na mesma rede do Dusk.
E, honestamente, acho que essa é uma escolha de design bem interessante.
Qual você preferiria no Dusk?
@Dusk $DUSK #dusk
🔥 Phoenix
50%
🌙 Moonlight
10%
⚡ Both
20%
🤔 Depends on the use case
20%
10 Votos • Votação encerrada
Estar um token na cadeia é apenas o começo.
A verdadeira questão é: as regras em torno desse ativo também podem ser movidas para a cadeia?
Pense em um título regulado.
Transformá-lo em um token talvez seja a parte mais fácil. Mas um mercado financeiro de verdade precisa de mais:
• Apenas investidores elegíveis devem poder mantê-lo
• As transferências podem precisar de restrições embutidas
• Posições sensíveis não devem ser públicas por padrão
• As partes certas precisam ter acesso às informações certas
• O pagamento e a entrega do ativo precisam ser liquidados juntos
É aí que a tokenização se torna mais do que uma simples embalagem digital.
Ela se torna infraestrutura de mercado.
Por isso, @Dusk se destaca para mim. Seu foco não é apenas colocar ativos na cadeia, mas habilitar fluxos regulados em torno deles — transferências controladas, divulgação seletiva, privacidade, elegibilidade e liquidação como partes conectadas de um único sistema.
A grande oportunidade não é apenas ativos tokenizados.
É mercados programáveis:
Regras que seguem o ativo.
Privacidade que pode coexistir com responsabilização.
Liquidação que acontece como parte da transação.
Mudanças de propriedade que não quebram requisitos de conformidade.
Se esse modelo funcionar em escala, as finanças on-chain podem parecer menos com mercados tradicionais com um novo banco de dados — e mais como um sistema financeiro redesenhado.
O que você acha que é a maior barreira para as finanças do mundo real migrarem para a cadeia: identidade, privacidade, negociação, liquidação ou administração do ativo?
$DUSK #dusk @Dusk
A verdadeira questão é: as regras em torno desse ativo também podem ser movidas para a cadeia?
Pense em um título regulado.
Transformá-lo em um token talvez seja a parte mais fácil. Mas um mercado financeiro de verdade precisa de mais:
• Apenas investidores elegíveis devem poder mantê-lo
• As transferências podem precisar de restrições embutidas
• Posições sensíveis não devem ser públicas por padrão
• As partes certas precisam ter acesso às informações certas
• O pagamento e a entrega do ativo precisam ser liquidados juntos
É aí que a tokenização se torna mais do que uma simples embalagem digital.
Ela se torna infraestrutura de mercado.
Por isso, @Dusk se destaca para mim. Seu foco não é apenas colocar ativos na cadeia, mas habilitar fluxos regulados em torno deles — transferências controladas, divulgação seletiva, privacidade, elegibilidade e liquidação como partes conectadas de um único sistema.
A grande oportunidade não é apenas ativos tokenizados.
É mercados programáveis:
Regras que seguem o ativo.
Privacidade que pode coexistir com responsabilização.
Liquidação que acontece como parte da transação.
Mudanças de propriedade que não quebram requisitos de conformidade.
Se esse modelo funcionar em escala, as finanças on-chain podem parecer menos com mercados tradicionais com um novo banco de dados — e mais como um sistema financeiro redesenhado.
O que você acha que é a maior barreira para as finanças do mundo real migrarem para a cadeia: identidade, privacidade, negociação, liquidação ou administração do ativo?
$DUSK #dusk @Dusk
Parcialmente verdadeiro
Todo mundo fala sobre escalabilidade em blockchain.
Quase ninguém fala sobre o custo de lembrar.
Uma rede pode processar enormes quantidades de atividade, mas cada bloco, evento e transição de estado também cria dados históricos que, eventualmente, precisam ser armazenados e mantidos.
Por isso achei a atualização recente de infraestrutura da Dusk mais interessante do que mais um título sobre TPS.
A Dusk reduziu o armazenamento de eventos no nó de arquivo de 310,7 MB para 27,7 MB — mais de 90% de redução — preservando resultados históricos.
A parte interessante não é apenas o número.
É o que isso diz sobre a infraestrutura do blockchain.
Se, no futuro, as redes vão suportar ativos financeiros e aplicações que podem precisar de anos de verificação histórica, a eficiência de armazenamento se torna parte da própria arquitetura.
Escalabilidade não é só sobre processar mais. Também é sobre carregar menos dados sem perder o histórico que torna a rede verificável.
Essas melhorias provavelmente não vão gerar as manchetes mais barulhentas.
Mas o trabalho de infraestrutura, por mais “chato” que seja, é frequentemente o que torna possível a adoção em larga escala.
A Dusk não está trabalhando apenas no que acontece on-chain.
Ela também está melhorando o quão eficientemente a rede consegue lembrar o que aconteceu.
@Dusk $DUSK #dusk
Quase ninguém fala sobre o custo de lembrar.
Uma rede pode processar enormes quantidades de atividade, mas cada bloco, evento e transição de estado também cria dados históricos que, eventualmente, precisam ser armazenados e mantidos.
Por isso achei a atualização recente de infraestrutura da Dusk mais interessante do que mais um título sobre TPS.
A Dusk reduziu o armazenamento de eventos no nó de arquivo de 310,7 MB para 27,7 MB — mais de 90% de redução — preservando resultados históricos.
A parte interessante não é apenas o número.
É o que isso diz sobre a infraestrutura do blockchain.
Se, no futuro, as redes vão suportar ativos financeiros e aplicações que podem precisar de anos de verificação histórica, a eficiência de armazenamento se torna parte da própria arquitetura.
Escalabilidade não é só sobre processar mais. Também é sobre carregar menos dados sem perder o histórico que torna a rede verificável.
Essas melhorias provavelmente não vão gerar as manchetes mais barulhentas.
Mas o trabalho de infraestrutura, por mais “chato” que seja, é frequentemente o que torna possível a adoção em larga escala.
A Dusk não está trabalhando apenas no que acontece on-chain.
Ela também está melhorando o quão eficientemente a rede consegue lembrar o que aconteceu.
@Dusk $DUSK #dusk
Verificado
Uma atualização do One Dusk que eu acho que merece mais atenção é a entrada no ar do testnet DuskEVM.
À primeira vista, “mais um ambiente EVM” não parece particularmente interessante. Mas a arquitetura conta uma história diferente.
DuskEVM traz Solidity, Hardhat e as ferramentas padrão do ecossistema Ethereum para o Dusk, enquanto a execução é liquidada via DuskDS. Essa separação importa porque os desenvolvedores podem usar uma pilha de aplicações familiar sem abrir mão da camada nativa do Dusk de liquidação e disponibilidade de dados.
A parte mais interessante é o que existe ao redor disso.
O Dusk também está construindo o Dusk Trade como uma camada de aplicação para ativos financeiros tokenizados, com fluxos em torno de onboarding de investidores, vinculação de carteira, transferências controladas, coordenação de pagamentos e liquidação em conformidade.
Então o desenvolvimento recente não é apenas sobre adicionar compatibilidade com EVM.
Parece mais que o Dusk está caminhando para uma pilha completa em que diferentes partes lidam com problemas diferentes:
→ DuskDS: consenso, liquidação e disponibilidade de dados
→ DuskEVM: execução EVM familiar
→ DuskVM: execução nativa em Rust/WASM com acesso direto às capacidades de privacidade do Dusk
→ Dusk Trade: infraestrutura em nível de aplicação para mercados tokenizados
E é aqui que a tese de RWA fica mais interessante.
Tokenizar um ativo é relativamente fácil de descrever. Construir a infraestrutura real para emissão, elegibilidade, transferências, privacidade, divulgação e liquidação é o problema mais difícil.
Com o DuskEVM agora disponível para testes e o Dusk Trade sendo construído em torno de fluxos reais de mercado, a próxima coisa que vou observar não é outro anúncio.
É o que desenvolvedores e aplicações financeiras realmente constroem em cima dessa pilha.
@Dusk $DUSK #dusk
À primeira vista, “mais um ambiente EVM” não parece particularmente interessante. Mas a arquitetura conta uma história diferente.
DuskEVM traz Solidity, Hardhat e as ferramentas padrão do ecossistema Ethereum para o Dusk, enquanto a execução é liquidada via DuskDS. Essa separação importa porque os desenvolvedores podem usar uma pilha de aplicações familiar sem abrir mão da camada nativa do Dusk de liquidação e disponibilidade de dados.
A parte mais interessante é o que existe ao redor disso.
O Dusk também está construindo o Dusk Trade como uma camada de aplicação para ativos financeiros tokenizados, com fluxos em torno de onboarding de investidores, vinculação de carteira, transferências controladas, coordenação de pagamentos e liquidação em conformidade.
Então o desenvolvimento recente não é apenas sobre adicionar compatibilidade com EVM.
Parece mais que o Dusk está caminhando para uma pilha completa em que diferentes partes lidam com problemas diferentes:
→ DuskDS: consenso, liquidação e disponibilidade de dados
→ DuskEVM: execução EVM familiar
→ DuskVM: execução nativa em Rust/WASM com acesso direto às capacidades de privacidade do Dusk
→ Dusk Trade: infraestrutura em nível de aplicação para mercados tokenizados
E é aqui que a tese de RWA fica mais interessante.
Tokenizar um ativo é relativamente fácil de descrever. Construir a infraestrutura real para emissão, elegibilidade, transferências, privacidade, divulgação e liquidação é o problema mais difícil.
Com o DuskEVM agora disponível para testes e o Dusk Trade sendo construído em torno de fluxos reais de mercado, a próxima coisa que vou observar não é outro anúncio.
É o que desenvolvedores e aplicações financeiras realmente constroem em cima dessa pilha.
@Dusk $DUSK #dusk
Quanto mais eu analiso a tokenização, mais acho que estamos fazendo a pergunta errada.
Todo mundo pergunta: “Esse ativo pode ser colocado na blockchain?”
Mas imagine que o ativo já esteja lá.
Agora, um investidor quer comprá-lo. Outro quer vendê-lo. A entidade emissora precisa definir quem pode mantê-lo. Um regulador pode precisar de evidências mais tarde. E, em algum lugar no meio disso, informações sensíveis ainda não deveriam virar dados públicos.
Essa é a parte mais interessante da @Dusk para mim. A infraestrutura de mercado está sendo projetada em torno de todo o fluxo de trabalho — elegibilidade, transferências controladas, privacidade, divulgação e liquidação — em vez de tratar um token como o produto final.
Talvez o verdadeiro avanço em RWA não seja criar mais tokens.
Talvez seja fazer com que esses tokens realmente se comportem como ativos financeiros.
Qual parte desse fluxo de trabalho você acha que é a mais difícil de resolver?
$DUSK #dusk @Dusk
Todo mundo pergunta: “Esse ativo pode ser colocado na blockchain?”
Mas imagine que o ativo já esteja lá.
Agora, um investidor quer comprá-lo. Outro quer vendê-lo. A entidade emissora precisa definir quem pode mantê-lo. Um regulador pode precisar de evidências mais tarde. E, em algum lugar no meio disso, informações sensíveis ainda não deveriam virar dados públicos.
Essa é a parte mais interessante da @Dusk para mim. A infraestrutura de mercado está sendo projetada em torno de todo o fluxo de trabalho — elegibilidade, transferências controladas, privacidade, divulgação e liquidação — em vez de tratar um token como o produto final.
Talvez o verdadeiro avanço em RWA não seja criar mais tokens.
Talvez seja fazer com que esses tokens realmente se comportem como ativos financeiros.
Qual parte desse fluxo de trabalho você acha que é a mais difícil de resolver?
$DUSK #dusk @Dusk
Há alguns dias eu estava pensando sobre o que “tokenizar um ativo” realmente significa. No começo, parece simples — pegar uma ação, um título ou um ativo financeiro e colocar na blockchain. Mas criar o token provavelmente é a parte mais fácil.
As perguntas mais difíceis começam depois disso. Quem pode realmente mantê-lo? O que acontece quando alguém tenta transferi-lo para a carteira errada? Quais informações precisam ficar visíveis para fins de conformidade e o que deve permanecer privado?
É aí que o $DUSK fica interessante para mim. Ativos financeiros reais exigem mais do que apenas transferências rápidas — eles precisam de regras, privacidade, verificação e liquidação para funcionarem em conjunto, sem transformar tudo em uma planilha pública.
Talvez o verdadeiro desafio da RWA não seja colocar ativos na blockchain. Talvez seja construir um sistema em que os mercados financeiros consigam realmente operar ali sem abrir mão da privacidade e dos controles dos quais eles já dependem. Qual você acha que é a peça que mais falta? 👀
@Dusk $DUSK #Dusk
As perguntas mais difíceis começam depois disso. Quem pode realmente mantê-lo? O que acontece quando alguém tenta transferi-lo para a carteira errada? Quais informações precisam ficar visíveis para fins de conformidade e o que deve permanecer privado?
É aí que o $DUSK fica interessante para mim. Ativos financeiros reais exigem mais do que apenas transferências rápidas — eles precisam de regras, privacidade, verificação e liquidação para funcionarem em conjunto, sem transformar tudo em uma planilha pública.
Talvez o verdadeiro desafio da RWA não seja colocar ativos na blockchain. Talvez seja construir um sistema em que os mercados financeiros consigam realmente operar ali sem abrir mão da privacidade e dos controles dos quais eles já dependem. Qual você acha que é a peça que mais falta? 👀
@Dusk $DUSK #Dusk
#dusk $DUSK
A história de segurança de uma blockchain não é “nunca encontramos um bug”.
É o que acontece depois que uma auditoria séria encontra um.
Por isso, me aprofundei no caminho da AEGIS em @Dusk .
A remediação AEGIS de 2026 da Dusk entregou 39 correções de segurança, incluindo 7 achados críticos.
A parte interessante? Elas não eram apenas problemas superficiais.
A auditoria chegou fundo na pilha:
→ Execução em sandbox da VM
→ Desserialização no lado do host
→ Lógica de taxa e reembolso do Phoenix &
→ Segurança de assinatura BLS
→ Componentes de consenso, rede e criptografia
Um problema na taxa do Phoenix poderia afetar a integridade da oferta, a disponibilidade da cadeia e a segurança do reembolso. O problema BLS envolveu a construção criptográfica usada para verificação de assinaturas.
A AEGIS não apenas corrigiu uma linha e seguiu em frente. A Dusk diz que ela reestruturou o modelo de propriedade afetado, reforçou os limites de confiança, adicionou verificações de consistência de taxas em múltiplas camadas, fortaleceu o caminho BLS e incluiu testes de regressão em formato de exploração.
E, de acordo com a Dusk, não houve evidências de que os achados críticos tivessem sido explorados antes da AEGIS.
Para mim, essa é a principal lição.
Em finanças regulamentadas, privacidade é importante.
Mas privacidade sem segurança não serve.
A infraestrutura precisa sobreviver a uma postura adversarial antes que as instituições possam confiar nela.
É desse lado de @Dusk que eu acho vale a pena ficar de olho:
não apenas no que o protocolo promete,
mas em quão seriamente ele responde quando alguém tenta quebrá-lo.
$DUSK #dusk @Dusk
A história de segurança de uma blockchain não é “nunca encontramos um bug”.
É o que acontece depois que uma auditoria séria encontra um.
Por isso, me aprofundei no caminho da AEGIS em @Dusk .
A remediação AEGIS de 2026 da Dusk entregou 39 correções de segurança, incluindo 7 achados críticos.
A parte interessante? Elas não eram apenas problemas superficiais.
A auditoria chegou fundo na pilha:
→ Execução em sandbox da VM
→ Desserialização no lado do host
→ Lógica de taxa e reembolso do Phoenix &
→ Segurança de assinatura BLS
→ Componentes de consenso, rede e criptografia
Um problema na taxa do Phoenix poderia afetar a integridade da oferta, a disponibilidade da cadeia e a segurança do reembolso. O problema BLS envolveu a construção criptográfica usada para verificação de assinaturas.
A AEGIS não apenas corrigiu uma linha e seguiu em frente. A Dusk diz que ela reestruturou o modelo de propriedade afetado, reforçou os limites de confiança, adicionou verificações de consistência de taxas em múltiplas camadas, fortaleceu o caminho BLS e incluiu testes de regressão em formato de exploração.
E, de acordo com a Dusk, não houve evidências de que os achados críticos tivessem sido explorados antes da AEGIS.
Para mim, essa é a principal lição.
Em finanças regulamentadas, privacidade é importante.
Mas privacidade sem segurança não serve.
A infraestrutura precisa sobreviver a uma postura adversarial antes que as instituições possam confiar nela.
É desse lado de @Dusk que eu acho vale a pena ficar de olho:
não apenas no que o protocolo promete,
mas em quão seriamente ele responde quando alguém tenta quebrá-lo.
$DUSK #dusk @Dusk
Verificado
#dusk $DUSK
A maioria das blockchains foi projetada em torno de uma única ideia:
Transparência.
Mas os mercados financeiros reais precisam de algo mais nuançado.
Você não pode esperar que instituições disponibilizem cada saldo, posição e detalhe de transação em um livro-razão público para que todos vejam.
É aí que @Dusk fica interessante.
A Dusk está construindo infraestrutura para finanças onchain regulamentadas, onde privacidade, conformidade e liquidação determinística podem funcionar juntas.
→ Moonlight para fluxos públicos transparentes
→ Phoenix para transferências sigilosas com shield confidencial
→ Divulgação seletiva quando uma parte autorizada precisa de informações específicas
→ DuskVM para smart contracts nativos em Rust/WASM + ZK
→ DuskEVM para um caminho de desenvolvimento compatível com EVM
E a ideia maior vai além de simplesmente “tokenizar um ativo”.
Para valores mobiliários regulamentados, você precisa que elegibilidade do investidor, transferências controladas, privacidade, divulgação, relatórios e liquidação funcionem em conjunto.
É essa a parte que eu acho mais interessante na Dusk.
Tokenização é fácil de descrever.
Construir a infraestrutura financeira ao redor disso é a parte difícil.
A Dusk aposta que o futuro das finanças onchain precisa de ambos:
Privacidade quando importa.
Transparência quando é útil.
Conformidade quando é exigida.
Liquidação que possa ser confiável.
Essa é uma tese que vale a pena acompanhar. 👀
@Dusk $DUSK #dusk
A maioria das blockchains foi projetada em torno de uma única ideia:
Transparência.
Mas os mercados financeiros reais precisam de algo mais nuançado.
Você não pode esperar que instituições disponibilizem cada saldo, posição e detalhe de transação em um livro-razão público para que todos vejam.
É aí que @Dusk fica interessante.
A Dusk está construindo infraestrutura para finanças onchain regulamentadas, onde privacidade, conformidade e liquidação determinística podem funcionar juntas.
→ Moonlight para fluxos públicos transparentes
→ Phoenix para transferências sigilosas com shield confidencial
→ Divulgação seletiva quando uma parte autorizada precisa de informações específicas
→ DuskVM para smart contracts nativos em Rust/WASM + ZK
→ DuskEVM para um caminho de desenvolvimento compatível com EVM
E a ideia maior vai além de simplesmente “tokenizar um ativo”.
Para valores mobiliários regulamentados, você precisa que elegibilidade do investidor, transferências controladas, privacidade, divulgação, relatórios e liquidação funcionem em conjunto.
É essa a parte que eu acho mais interessante na Dusk.
Tokenização é fácil de descrever.
Construir a infraestrutura financeira ao redor disso é a parte difícil.
A Dusk aposta que o futuro das finanças onchain precisa de ambos:
Privacidade quando importa.
Transparência quando é útil.
Conformidade quando é exigida.
Liquidação que possa ser confiável.
Essa é uma tese que vale a pena acompanhar. 👀
@Dusk $DUSK #dusk
⚡ PESQUISA DE TRADERS DE FUTUROS ⚡
RSI acima de 78 = zona de sobrecompra 📊
Esses principais ganhadores estão subindo... qual é a sua jogada em futuros? 👇
Alto risco, alta recompensa — não seja liquidado!
💬 Comente sua entrada & alavancagem#CryptoPoll #SKLUSDT #CryptoPatience #FutureTradingSignals #MOVR/USDT $ZBT $KERNEL $SKL
RSI acima de 78 = zona de sobrecompra 📊
Esses principais ganhadores estão subindo... qual é a sua jogada em futuros? 👇
Alto risco, alta recompensa — não seja liquidado!
💬 Comente sua entrada & alavancagem#CryptoPoll #SKLUSDT #CryptoPatience #FutureTradingSignals #MOVR/USDT $ZBT $KERNEL $SKL
Short KERNEL
57%
Short SKL
13%
Short MOVR
27%
Short ZBT
3%
104 Votos • Votação encerrada
Qual tipo de cripto você está apostando para a próxima alta? 👇
💬 Comente sua escolha + por quê
#BTC #solana #MEME #CryptoPoll #Dogecoin $NOM $ON $KAT
💬 Comente sua escolha + por quê
#BTC #solana #MEME #CryptoPoll #Dogecoin $NOM $ON $KAT
Store of Value — Bitcoin (BTC)
22%
Oracle Power— Chainlink (LINK)
14%
High-Speed Chains— Solana(SOL)
33%
Memecoins — Dogecoin (DOGE)
31%
36 Votos • Votação encerrada
Pesquisa de Gems Ocultos em Alta (Binance) 💎
Todos assistem BTC & ETH…
Mas os verdadeiros ganhos vêm de gems ocultos 👀
Qual altcoin em alta tem o maior potencial de 10x?$FET $RNDR $TIA
📊 Vote agora & comente sua gem oculta
O melhor alfa está sempre nos comentários 👇
#crypto #CryptoPoll #BTC #BinanceSquareTalks #CryptoPoll
Todos assistem BTC & ETH…
Mas os verdadeiros ganhos vêm de gems ocultos 👀
Qual altcoin em alta tem o maior potencial de 10x?$FET $RNDR $TIA
📊 Vote agora & comente sua gem oculta
O melhor alfa está sempre nos comentários 👇
#crypto #CryptoPoll #BTC #BinanceSquareTalks #CryptoPoll
FET (AI narrative)
63%
RNDR (GPU / AI infrastructure)
10%
TIA (Modular blockchain)
24%
SEI (High-speed DeFi chain)
3%
71 Votos • Votação encerrada
Qual memecoin você está acumulando agora?
💬 Comente a memecoin na qual você está otimista
Vamos ver qual comunidade é a mais forte 👀
#MemecoinArmy #CryptoPoll #BinanceSquare #PEPE #memecoin🚀🚀🚀
$PEPE $DOGE $FLOKI
💬 Comente a memecoin na qual você está otimista
Vamos ver qual comunidade é a mais forte 👀
#MemecoinArmy #CryptoPoll #BinanceSquare #PEPE #memecoin🚀🚀🚀
$PEPE $DOGE $FLOKI
DOGE
43%
SHIB
7%
PEPE
39%
OTHER (COMMENT IT)
11%
87 Votos • Votação encerrada
🚨 Seja honesto... a maioria das pessoas vai errar isso.
qual ativo realmente lidera o PRÓXIMO ciclo de alta? 📈
#CryptoPoll #Binance #BTC #Web3 #Ethereum
$KITE $DENT $SENT
qual ativo realmente lidera o PRÓXIMO ciclo de alta? 📈
#CryptoPoll #Binance #BTC #Web3 #Ethereum
$KITE $DENT $SENT
₿ Bitcoin – The king
23%
Ξ Ethereum – Smart contracts
19%
🟡BNB – Exchange+ real utility
13%
🚀 Altcoins
45%
31 Votos • Votação encerrada
Inicia sessão para explorar mais conteúdos