A escolha do Miden por não ser compatível com EVM é fundamentalmente uma consideração de arquitetura — e não uma questão específica do EVM em si.
A diferença chave está aqui: o Miden move a lógica de execução do blockchain para o lado do usuário, mantendo os dados de estado fora da cadeia, e apenas enviando a prova para serem verificadas na cadeia.
Comparando com a abordagem do EVM, podemos perceber a diferença. O EVM realiza a validação e execução na cadeia, com cada nó precisando executar a lógica. Essas duas abordagens arquitetônicas são completamente diferentes — uma é o usuário responsável pelo cálculo e a cadeia valida o resultado, a outra é uma validação coletiva por toda a rede.
Não se trata de uma disputa ideológica, mas sim de um equilíbrio entre eficiência e escalabilidade. Diferentes objetivos de design levam a escolhas tecnológicas distintas.
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
10 gostos
Recompensa
10
6
Republicar
Partilhar
Comentar
0/400
GasFeeTherapist
· 5h atrás
Ok, entendo essa lógica, mas a questão é: os utilizadores realmente querem fazer a prova por conta própria?
---
Mais uma vez, design de arquitetura... basicamente, é uma questão de apostas diferentes, quem consegue passar primeiro é que ganha.
---
proofs on user side soa bem, mas e se o custo de geração da prova for mais caro do que a validação na cadeia?
---
Só quero saber se a experiência do utilizador do Miden será melhor do que a do EVM, não basta falar só de visão técnica.
---
Essa abordagem na verdade lembra um pouco a ideia de rollup? De qualquer forma, tudo é movido para fora da cadeia.
---
Fazer a etapa de incompatibilidade com o EVM foi um grande erro, a ecologia não vai se desenvolver, meu amigo.
---
Espera aí, como garantir que o estado fora da cadeia não seja adulterado? Parece que é uma nova armadilha.
Ver originalResponder0
ILCollector
· 01-05 18:33
Como é que parece que estão a passar a culpa para o design da arquitetura... Em resumo, é porque não querem ser compatíveis com o EVM, transferir o poder de processamento para o lado do utilizador parece mais fácil, mas será que assim a experiência do utilizador não vai ficar prejudicada?
Ver originalResponder0
CantAffordPancake
· 01-04 16:52
Hmm, essa lógica eu entendo, em resumo é apenas uma questão de diferentes formas de distribuição de poder de hashing.
A incompatibilidade com EVM não é um grande problema, o mais importante é se o mecanismo de prova do Miden é confiável.
Executar cálculos localmente pelos usuários realmente alivia a pressão na cadeia, mas e se houver uma vulnerabilidade na prova...
Embora o sistema EVM seja redundante, pelo menos toda a rede verifica uma vez, o que traz tranquilidade.
Se essa abordagem do Miden realmente for bem-sucedida, será incrível, só tenho medo de algo inesperado acontecer no meio do caminho.
Ver originalResponder0
GateUser-0717ab66
· 01-04 16:50
Nossa, agora entendi o que é inovação verdadeira em arquitetura, não é preciso ser compatível com EVM para sobreviver
Mas falando nisso, a carga de computação dos usuários é grande... Essa abordagem realmente pode se popularizar?
A ideia do Miden é um pouco agressiva, economiza bastante trabalho, mas e a experiência do usuário?
Mesmo que teoricamente não haja problemas, na implementação ainda há riscos
Parece uma aposta na capacidade do ZK proof de rodar suavemente no final, uma aposta forte
Entendi toda a ideia, mas como fazer o efeito de rede...
Na verdade, no final das contas, tudo depende se o ecossistema vai decolar, por mais elegante que seja o design da arquitetura, não adianta
Ser compatível ou não com EVM realmente não é o ponto principal, o que importa é que funcione
Gostaria de ver se o Miden consegue realmente dar certo... por enquanto ainda está um pouco incerto
Ver originalResponder0
GateUser-e87b21ee
· 01-04 16:47
Ai, mais uma vez aquela abordagem de prova ZK, que, para dizer de forma elegante, deixa o trabalho para o utilizador calcular, enquanto na cadeia apenas verifica. Mas pensando bem, isso realmente é completamente diferente da abordagem de vários nós do EVM que executam lógica repetida.
Ver originalResponder0
GateUser-74b10196
· 01-04 16:35
Nossa, finalmente alguém explicou isso claramente, não é que a EVM seja ruim, é que as duas abordagens são basicamente opostas
Essa argumentação do irmão é excelente, poder de processamento do lado do usuário vs validação na rede, essa diferença é de nível de infraestrutura
Droga, finalmente não preciso mais ver aquelas discussões de preto no branco
A abordagem do Miden é realmente forte, terceirizar o cálculo e validar na cadeia, essa é uma verdadeira mentalidade de escalabilidade
Mas surge a questão, como garantir a segurança do cálculo do lado do usuário?
É por isso que o Miden definitivamente não depende da EVM, são duas lógicas completamente diferentes
Só quero saber até que ponto esse sistema pode ficar rápido quando for realmente lançado
Enfim, não é tão complicado, basicamente é uma escolha diferente entre poder de processamento e validação
A escolha do Miden por não ser compatível com EVM é fundamentalmente uma consideração de arquitetura — e não uma questão específica do EVM em si.
A diferença chave está aqui: o Miden move a lógica de execução do blockchain para o lado do usuário, mantendo os dados de estado fora da cadeia, e apenas enviando a prova para serem verificadas na cadeia.
Comparando com a abordagem do EVM, podemos perceber a diferença. O EVM realiza a validação e execução na cadeia, com cada nó precisando executar a lógica. Essas duas abordagens arquitetônicas são completamente diferentes — uma é o usuário responsável pelo cálculo e a cadeia valida o resultado, a outra é uma validação coletiva por toda a rede.
Não se trata de uma disputa ideológica, mas sim de um equilíbrio entre eficiência e escalabilidade. Diferentes objetivos de design levam a escolhas tecnológicas distintas.