#dusk $DUSK @Dusk
Tenho estado a mexer na configuração da Dusk Network ultimamente e um detalhe continuou a chamar-me a atenção mais do que a habitual apresentação da “cadeia de privacidade”. É a forma como o Piecrust, a VM deles baseada em WASM, lida com as partes caras.
Aqui está o que as pessoas não falam o suficiente sobre execução de contratos inteligentes. Cada instrução custa computação real e, na maioria das cadeias, se um contrato precisa fazer hash de alguma coisa ou verificar uma prova, ele faz esse trabalho dentro da própria VM, linha por linha, em bytecode WASM. Isso funciona bem para lógica simples. Fica brutal quando você lida com provas de conhecimento zero, que é basicamente a razão de existir da Dusk. O que me chamou atenção foi a abordagem do Piecrust de empurrar esse trabalho pesado — hashing, checagens de assinatura, validação de prova PLONK e Groth16 — para funções nativas do host, em vez de fazer o contrato calcular isso dentro do WASM. O host executa isso uma vez, de forma nativa, e devolve o resultado.
Fico me perguntando o quanto isso realmente importa na prática versus no papel. Mas a lógica faz sentido. Código nativo para operações criptográficas é mais rápido do que o WASM interpretando a mesma matemática, às vezes por uma margem bem grande, dependendo da operação. Para uma cadeia construída em torno de transações confidenciais e do modelo de privacidade UTXO da Phoenix, onde a verificação de provas não é opcional, mas constante, essa diferença se acumula rapidamente em cada bloco.
O que ainda me parece não resolvido é como isso escala quando a complexidade dos contratos cresce além dos casos de uso atuais. Funções nativas do host resolvem o gargalo de hoje, mas não estou totalmente convencido de que continue elegante à medida que começam a ser solicitados mais primitivos criptográficos personalizados. Alguém que esteja construindo com o Piecrust já sentiu algum atrito aí?
$ONG
$AMP
Tenho estado a mexer na configuração da Dusk Network ultimamente e um detalhe continuou a chamar-me a atenção mais do que a habitual apresentação da “cadeia de privacidade”. É a forma como o Piecrust, a VM deles baseada em WASM, lida com as partes caras.
Aqui está o que as pessoas não falam o suficiente sobre execução de contratos inteligentes. Cada instrução custa computação real e, na maioria das cadeias, se um contrato precisa fazer hash de alguma coisa ou verificar uma prova, ele faz esse trabalho dentro da própria VM, linha por linha, em bytecode WASM. Isso funciona bem para lógica simples. Fica brutal quando você lida com provas de conhecimento zero, que é basicamente a razão de existir da Dusk. O que me chamou atenção foi a abordagem do Piecrust de empurrar esse trabalho pesado — hashing, checagens de assinatura, validação de prova PLONK e Groth16 — para funções nativas do host, em vez de fazer o contrato calcular isso dentro do WASM. O host executa isso uma vez, de forma nativa, e devolve o resultado.
Fico me perguntando o quanto isso realmente importa na prática versus no papel. Mas a lógica faz sentido. Código nativo para operações criptográficas é mais rápido do que o WASM interpretando a mesma matemática, às vezes por uma margem bem grande, dependendo da operação. Para uma cadeia construída em torno de transações confidenciais e do modelo de privacidade UTXO da Phoenix, onde a verificação de provas não é opcional, mas constante, essa diferença se acumula rapidamente em cada bloco.
O que ainda me parece não resolvido é como isso escala quando a complexidade dos contratos cresce além dos casos de uso atuais. Funções nativas do host resolvem o gargalo de hoje, mas não estou totalmente convencido de que continue elegante à medida que começam a ser solicitados mais primitivos criptográficos personalizados. Alguém que esteja construindo com o Piecrust já sentiu algum atrito aí?
$ONG
$AMP
