#dusk Na semana passada aconteceu uma coisa constrangedora: fui ao banco para tratar de um serviço, mas o atendente ficou “travado” numa página de verificação de identidade — como se estivesse morto, e atrás de mim a fila só aumentava cada vez mais. No fim, o gerente resolveu de um jeito bem simples: desligou o novo sistema que estava dando erro e voltou para o software interno antigo. Esse episódio me fez enxergar uma realidade: os profissionais da ponta nunca se importam com o quão avançada é a tecnologia do backend. Se isso atrasar a operação no local, por mais bonito que seja o instrumento, ele acaba sendo descartado na hora. $RE
O caminho de conformidade na cadeia (on-chain) na prática também pisa no mesmo buraco. Muitos projetos anunciam em voz alta proteção de privacidade, mas quando chega na geração, na etapa do front-end, de uma prova de Zero-Knowledge, o ventilador do computador começa a girar sem parar e a página fica travada por alguns minutos. A equipe de controle de risco prefere continuar usando relatórios tradicionais offline, em vez de ficar esperando o carregamento lento do navegador.
Recentemente, ao revisar a proposta técnica do @Dusk , vi que eles tentaram reescrever esse beco sem saída desde a origem. Eles substituem a camada de execução tradicional por um Piecrust VM feito especificamente para provas de conhecimento zero, reduzindo o custo de computação — e só assim o proving no navegador passa a ter possibilidade real de ser implantado. Além disso, ao combinar a prova de identidade Zero-Knowledge do protocolo Citadel, tentam concluir a validação de conformidade com os dados sem precisar sair do domínio.
Mas abandonar a rota genérica do EVM para desenvolver uma máquina virtual própria é uma espada de dois gumes. Embora aumente a eficiência de execução criptográfica, também eleva muito a barreira para conectar aplicações externas e para migração de liquidez. E nem vamos falar do cenário de alta concorrência em condições extremas de mercado: se equipamentos comuns de escritório aguentam, ou se a compilação dos circuitos vai realmente “morrer”/travar, ainda falta suporte de dados de testes em escala na rede. $BTC
Ao observar $DUSK , eu nunca fico preso ao quanto o texto de marketing é sofisticado; só me importa se ele aguenta o teste de operações financeiras reais. Se a arquitetura subjacente for impecável, mas no final o usuário não conseguir esperar — seja por barreiras de acesso às aplicações ou por demora no terminal — então qual é a diferença essencial em relação ao sistema do banco daquele dia, que precisou voltar às pressas para o software antigo? Será que a mesa de negociação, tão cheia de transações, realmente compraria a promessa de “elegância” tecnológica, pagando o custo de esperar vários segundos, mesmo que isso custe tempo?
O caminho de conformidade na cadeia (on-chain) na prática também pisa no mesmo buraco. Muitos projetos anunciam em voz alta proteção de privacidade, mas quando chega na geração, na etapa do front-end, de uma prova de Zero-Knowledge, o ventilador do computador começa a girar sem parar e a página fica travada por alguns minutos. A equipe de controle de risco prefere continuar usando relatórios tradicionais offline, em vez de ficar esperando o carregamento lento do navegador.
Recentemente, ao revisar a proposta técnica do @Dusk , vi que eles tentaram reescrever esse beco sem saída desde a origem. Eles substituem a camada de execução tradicional por um Piecrust VM feito especificamente para provas de conhecimento zero, reduzindo o custo de computação — e só assim o proving no navegador passa a ter possibilidade real de ser implantado. Além disso, ao combinar a prova de identidade Zero-Knowledge do protocolo Citadel, tentam concluir a validação de conformidade com os dados sem precisar sair do domínio.
Mas abandonar a rota genérica do EVM para desenvolver uma máquina virtual própria é uma espada de dois gumes. Embora aumente a eficiência de execução criptográfica, também eleva muito a barreira para conectar aplicações externas e para migração de liquidez. E nem vamos falar do cenário de alta concorrência em condições extremas de mercado: se equipamentos comuns de escritório aguentam, ou se a compilação dos circuitos vai realmente “morrer”/travar, ainda falta suporte de dados de testes em escala na rede. $BTC
Ao observar $DUSK , eu nunca fico preso ao quanto o texto de marketing é sofisticado; só me importa se ele aguenta o teste de operações financeiras reais. Se a arquitetura subjacente for impecável, mas no final o usuário não conseguir esperar — seja por barreiras de acesso às aplicações ou por demora no terminal — então qual é a diferença essencial em relação ao sistema do banco daquele dia, que precisou voltar às pressas para o software antigo? Será que a mesa de negociação, tão cheia de transações, realmente compraria a promessa de “elegância” tecnológica, pagando o custo de esperar vários segundos, mesmo que isso custe tempo?
绝对不为它买单
80%
勉强硬着头皮用
0%
卡在开发者这关
20%
10 Votos • Votação encerrada