#dusk $DUSK @Dusk Something about Dusk's storage design bugs me, in a good way. A Piecrust, a VM deles, grava estado em blocos de 64KB, páginas inteiras de memória WASM. O Ethereum grava em slots de 32 bytes. Isso é uma diferença de granularidade de cerca de 2.000x, só para atualizar um único valor.
Por que tão grosseiro? A Dusk ignora completamente a API de armazenamento de valor-chave. A memória inteira de um contrato é o estado dele. Escreva uma struct Rust simples, use um BTreeMap, e ele persiste automaticamente — sem aquele controle manual estilo SSTORE. Para equipes vindas das finanças tradicionais em vez do Solidity, isso realmente é mais fácil de construir.
Mas persistência de memória inteira não escala de graça, e o time claramente bateu nesse limite. Eles construíram um rastreamento de páginas sujas para que apenas as páginas alteradas sejam reescritas, em vez do snapshot inteiro a cada vez. Correção inteligente. Ainda assim, a unidade de "alterado" é uma página de 64KB, não alguns bytes. Um ledger com milhares de entradas, tocado por uma única transação, ainda pode acabar sujando várias páginas espalhadas só por causa de como o alocador organiza a memória. Parece um tradeoff real, não um problema resolvido.
Ainda não vi benchmarks de carga sobre isso. Então, de verdade, curiosidade: alguém já fez um teste de estresse da Piecrust sob tráfego real de liquidação de alta frequência?
Por que tão grosseiro? A Dusk ignora completamente a API de armazenamento de valor-chave. A memória inteira de um contrato é o estado dele. Escreva uma struct Rust simples, use um BTreeMap, e ele persiste automaticamente — sem aquele controle manual estilo SSTORE. Para equipes vindas das finanças tradicionais em vez do Solidity, isso realmente é mais fácil de construir.
Mas persistência de memória inteira não escala de graça, e o time claramente bateu nesse limite. Eles construíram um rastreamento de páginas sujas para que apenas as páginas alteradas sejam reescritas, em vez do snapshot inteiro a cada vez. Correção inteligente. Ainda assim, a unidade de "alterado" é uma página de 64KB, não alguns bytes. Um ledger com milhares de entradas, tocado por uma única transação, ainda pode acabar sujando várias páginas espalhadas só por causa de como o alocador organiza a memória. Parece um tradeoff real, não um problema resolvido.
Ainda não vi benchmarks de carga sobre isso. Então, de verdade, curiosidade: alguém já fez um teste de estresse da Piecrust sob tráfego real de liquidação de alta frequência?
