📅17 de agosto
Hoje o TGE do $DGAI acabou fracassando, mas vamos ver se amanhã acontece. Estou acompanhando continuamente para vocês.
Tenho acompanhado de perto o projeto Dusk. O Wang Taiyu me disse que há dois bugs fatais, enterrados na camada de sandbox da VM do Piecrust. Eu achei meio improvável, então fui olhar o whitepaper e, quando vi “7 descobertas de nível Critical”, fiquei pensando.
Sinceramente, o Dusk realmente investiu em segurança. O Piecrust é a camada de sandbox de VM que sustenta contratos de privacidade RWA. Eles contrataram estudiosos de criptografia de ponta, como Porter Adams, para auditorias, e antes do lançamento na mainnet já foram concluídas mais de 10 auditorias independentes. Mas “muitas auditorias” e “sem vulnerabilidades” são coisas diferentes.
Entre os 39 problemas corrigidos na hard fork do AEGIS, 7 foram classificados como severos. Desses, dois dos mais fatais vieram diretamente da camada de sandbox da VM do Piecrust. A essência da vulnerabilidade é que o modelo de ownership do Rust é contornado—o estado de session e de instance pode ser referenciado por alias, causando múltiplas referências mutáveis existirem simultaneamente. Em execução na blockchain, isso significa que dois nós honestos executando o mesmo trecho de código podem obter resultados diferentes, destruindo a determinística do limite de execução. Um contrato malicioso só precisa empurrar o runtime para um estado específico para fazer o sistema de tipos falhar completamente.
Há também uma vulnerabilidade de desserialização insegura—ao desserializar o parâmetro de host query, não havia checagem de segurança; um atacante pode explorar essa falha para escapar do sandbox do contrato e atingir memória do processo do host.
A resposta do Dusk merece reconhecimento: a hard fork do AEGIS reescreveu o modelo de ownership do Piecrust e fechou a brecha de alias. O time também declarou publicamente que ainda não encontrou evidências de que as vulnerabilidades tenham sido exploradas.
Mas essas 7 vulnerabilidades classificadas como Critical—sendo duas diretamente na camada de sandbox da VM—mostram que, por mais alta que seja a qualidade do código do Piecrust, a nova VM de privacidade feita do zero ainda precisa de um ciclo suficientemente longo de validação em cenário real.
Se já existe uma plataforma de contratos de privacidade que disparou uma hard fork de emergência por causa de uma vulnerabilidade na sandbox da VM, você tem certeza de que, na próxima vez, um bug de ownership semelhante não estará escondido em um caminho de código ainda mais profundo?
O que foi dito acima são apenas opiniões pessoais e não constituem recomendação de investimento. Sinta-se à vontade para conversar na seção de comentários—quanto ao design da sandbox da VM do Piecrust, você acha que é um compromisso de engenharia ou uma bomba-relógio?
#dusk $DUSK @Dusk
Hoje o TGE do $DGAI acabou fracassando, mas vamos ver se amanhã acontece. Estou acompanhando continuamente para vocês.
Tenho acompanhado de perto o projeto Dusk. O Wang Taiyu me disse que há dois bugs fatais, enterrados na camada de sandbox da VM do Piecrust. Eu achei meio improvável, então fui olhar o whitepaper e, quando vi “7 descobertas de nível Critical”, fiquei pensando.
Sinceramente, o Dusk realmente investiu em segurança. O Piecrust é a camada de sandbox de VM que sustenta contratos de privacidade RWA. Eles contrataram estudiosos de criptografia de ponta, como Porter Adams, para auditorias, e antes do lançamento na mainnet já foram concluídas mais de 10 auditorias independentes. Mas “muitas auditorias” e “sem vulnerabilidades” são coisas diferentes.
Entre os 39 problemas corrigidos na hard fork do AEGIS, 7 foram classificados como severos. Desses, dois dos mais fatais vieram diretamente da camada de sandbox da VM do Piecrust. A essência da vulnerabilidade é que o modelo de ownership do Rust é contornado—o estado de session e de instance pode ser referenciado por alias, causando múltiplas referências mutáveis existirem simultaneamente. Em execução na blockchain, isso significa que dois nós honestos executando o mesmo trecho de código podem obter resultados diferentes, destruindo a determinística do limite de execução. Um contrato malicioso só precisa empurrar o runtime para um estado específico para fazer o sistema de tipos falhar completamente.
Há também uma vulnerabilidade de desserialização insegura—ao desserializar o parâmetro de host query, não havia checagem de segurança; um atacante pode explorar essa falha para escapar do sandbox do contrato e atingir memória do processo do host.
A resposta do Dusk merece reconhecimento: a hard fork do AEGIS reescreveu o modelo de ownership do Piecrust e fechou a brecha de alias. O time também declarou publicamente que ainda não encontrou evidências de que as vulnerabilidades tenham sido exploradas.
Mas essas 7 vulnerabilidades classificadas como Critical—sendo duas diretamente na camada de sandbox da VM—mostram que, por mais alta que seja a qualidade do código do Piecrust, a nova VM de privacidade feita do zero ainda precisa de um ciclo suficientemente longo de validação em cenário real.
Se já existe uma plataforma de contratos de privacidade que disparou uma hard fork de emergência por causa de uma vulnerabilidade na sandbox da VM, você tem certeza de que, na próxima vez, um bug de ownership semelhante não estará escondido em um caminho de código ainda mais profundo?
O que foi dito acima são apenas opiniões pessoais e não constituem recomendação de investimento. Sinta-se à vontade para conversar na seção de comentários—quanto ao design da sandbox da VM do Piecrust, você acha que é um compromisso de engenharia ou uma bomba-relógio?
#dusk $DUSK @Dusk
