#dusk $DUSK
Nestes dois dias continuei a olhar para o Hedger de @Dusk , e há um ponto que eu tinha entendido de forma simples demais antes.
Eu achava que, se já tem ZK, não seria suficiente?
Se ZK consegue provar que “esta transação está correta”, por que o Hedger ainda precisaria adicionar uma camada de Homomorphic Encryption?
Depois de rever a documentação várias vezes, percebi que, na verdade, eles estão resolvendo duas coisas diferentes.
ZK é mais como responder:
“Como você prova que não trapaceou?”
HE responde:
“Sem tornar os dados públicos, ainda dá para continuar usando-os no próximo cálculo?”
Essa diferença fica bem clara quando colocada no contexto financeiro.
O saldo é confidential, a posição é confidential, e o estado deixado pela transação anterior também é confidential.
Mas a próxima transação ainda precisa usar esses estados.
Se a cada atualização for preciso primeiro descriptografar, então a privacidade perde o sentido.
Por isso, a ideia do Hedger não é simplesmente “colocar uma camada de ZK na transação”.
É fazer com que parte do estado encrypted ainda possa participar de cálculos subsequentes, e então usar ZK para provar que a mudança de estado obedece às regras.
Acho que esse também é o ponto que faz o Hedger valer mais a pena observar do que muitas narrativas de “ZK Privacy”.
Ele não busca full anonymity.
A própria equipe admite que o account model do EVM tem limites.
O que ele realmente quer é:
permitir que o confidential state permaneça dentro do fluxo financeiro do EVM, sem abrir mão de verificação e auditoria.
Claro, também não dá para imaginar HE como uma chave mágica.
O Hedger não é uma FHE VM em que “todo o logic do Solidity pode rodar livremente em ciphertext”; atualmente ele ainda está em Testnet.
Então, o que eu realmente vou acompanhar daqui para frente não é “quantos termos de criptografia foram usados”, mas até que ponto esses encrypted balances, ownership e transfers conseguem funcionar em aplicações reais.
Isso é muito mais importante do que dizer apenas “privacidade no EVM”.
Nestes dois dias continuei a olhar para o Hedger de @Dusk , e há um ponto que eu tinha entendido de forma simples demais antes.
Eu achava que, se já tem ZK, não seria suficiente?
Se ZK consegue provar que “esta transação está correta”, por que o Hedger ainda precisaria adicionar uma camada de Homomorphic Encryption?
Depois de rever a documentação várias vezes, percebi que, na verdade, eles estão resolvendo duas coisas diferentes.
ZK é mais como responder:
“Como você prova que não trapaceou?”
HE responde:
“Sem tornar os dados públicos, ainda dá para continuar usando-os no próximo cálculo?”
Essa diferença fica bem clara quando colocada no contexto financeiro.
O saldo é confidential, a posição é confidential, e o estado deixado pela transação anterior também é confidential.
Mas a próxima transação ainda precisa usar esses estados.
Se a cada atualização for preciso primeiro descriptografar, então a privacidade perde o sentido.
Por isso, a ideia do Hedger não é simplesmente “colocar uma camada de ZK na transação”.
É fazer com que parte do estado encrypted ainda possa participar de cálculos subsequentes, e então usar ZK para provar que a mudança de estado obedece às regras.
Acho que esse também é o ponto que faz o Hedger valer mais a pena observar do que muitas narrativas de “ZK Privacy”.
Ele não busca full anonymity.
A própria equipe admite que o account model do EVM tem limites.
O que ele realmente quer é:
permitir que o confidential state permaneça dentro do fluxo financeiro do EVM, sem abrir mão de verificação e auditoria.
Claro, também não dá para imaginar HE como uma chave mágica.
O Hedger não é uma FHE VM em que “todo o logic do Solidity pode rodar livremente em ciphertext”; atualmente ele ainda está em Testnet.
Então, o que eu realmente vou acompanhar daqui para frente não é “quantos termos de criptografia foram usados”, mas até que ponto esses encrypted balances, ownership e transfers conseguem funcionar em aplicações reais.
Isso é muito mais importante do que dizer apenas “privacidade no EVM”.