Visão da carteira Ethereum ideal: uma atualização abrangente da experiência de cadeia cruzada à proteção da privacidade
Na pilha de infraestrutura do Ethereum, a carteira é uma camada chave, mas frequentemente subestimada por pesquisadores e desenvolvedores do núcleo L1. A carteira é a janela pela qual os usuários se comunicam com o mundo Ethereum, e os usuários só podem beneficiar-se das características de descentralização, resistência à censura, segurança e privacidade oferecidas pelo Ethereum e suas aplicações quando a carteira possui as propriedades adequadas.
Recentemente, as carteiras Ethereum fizeram progressos significativos na melhoria da experiência do usuário, segurança e funcionalidades. Este artigo tem como objetivo compartilhar a visão sobre as características que uma carteira Ethereum ideal deve ter. Esta não é uma lista completa, reflete a inclinação do autor para o ciberpunk, com foco em segurança e privacidade, podendo não ser abrangente em termos de experiência do usuário. No entanto, o autor acredita que, ao otimizar a experiência do usuário, é mais eficaz implantar e iterar com base em feedback do que seguir uma lista de desejos, e, portanto, considera que se concentrar nas propriedades de segurança e privacidade é o mais valioso.
experiência do usuário em transações cadeia cruzada L2
Agora existe um roteiro cada vez mais detalhado para melhorar a experiência do usuário entre L2, incluindo partes de curto e longo prazo. Aqui discutimos a parte de curto prazo: ideias que podem ser implementadas teoricamente agora.
A ideia central é: (i) envio cruzado de L2 embutido, bem como (ii) endereço específico da cadeia e pedido de pagamento. A Carteira deve ser capaz de fornecer ao usuário um endereço que siga o estilo do rascunho ERC.
Quando o usuário recebe um endereço neste formato, deve ser capaz de colá-lo no campo "Destinatário" da Carteira e clicar em "Enviar". A Carteira deve processar automaticamente os dados de envio:
Se houver tokens do tipo necessário suficientes na cadeia de destino, envie diretamente
Se precisar de tipos de token em outras cadeias, envie usando um protocolo semelhante ao ERC-7683.
Se houver tokens de diferentes tipos, use o DEX para converter para o tipo correto e envie.
Isso se aplica ao cenário de "pagamento por copiar e colar o endereço". Para situações em que o aplicativo solicita um depósito, o fluxo ideal é expandir a API web3 e permitir que o aplicativo emita solicitações de pagamento específicas da cadeia. A Carteira pode atender a essa solicitação de qualquer maneira necessária. Para proporcionar uma boa experiência ao usuário, também é necessário padronizar a solicitação getAvailableBalance, e a Carteira deve considerar cuidadosamente em quais cadeias armazenar os ativos dos usuários por padrão, a fim de maximizar a segurança e a conveniência das transferências.
Os pedidos de pagamento específicos da cadeia também podem ser inseridos em códigos QR para serem escaneados por carteiras móveis. Em cenários de pagamento presenciais ou online, o destinatário emitirá um código QR ou uma chamada de API web3, indicando "Eu quero Y unidades do token Z na cadeia X, com ID de referência ou callback W", a carteira pode atender a esse pedido livremente. Outra opção é o protocolo de link de reclamação, onde a carteira do usuário gera um código QR ou URL contendo a autorização de reclamação, e o destinatário é responsável por transferir os fundos para sua própria carteira.
Outro tema relacionado é o pagamento de gas. Se ativos forem recebidos em um L2 sem ETH e for necessário enviar uma transação, a carteira deve ser capaz de usar automaticamente o protocolo ( como o RIP-7755) para pagar gas a partir de uma cadeia com ETH. Se a carteira prever que o usuário realizará mais transações no L2 no futuro, ela também deve usar apenas DEX para enviar uma quantidade suficiente de ETH, para que as transações futuras possam pagar gas diretamente lá, pois é mais barato (.
![Vitalik nova postagem: A visão da carteira ideal, uma atualização abrangente da experiência de cadeia cruzada à proteção da privacidade])https://img-cdn.gateio.im/webp-social/moments-e340d9eff581bff30a541c8aac3178af.webp(
) Segurança da conta
A forma de conceituação dos desafios à segurança das contas é que uma boa carteira deve atuar em duas dimensões: ###i( proteger os usuários contra ataques de hackers ou comportamentos maliciosos por parte dos desenvolvedores da carteira, )ii( proteger os usuários contra os impactos de seus próprios erros.
A solução preferencial é a recuperação social e carteiras multiassinatura, com controle de acesso em camadas. As contas dos usuários possuem duas camadas de chaves: chave principal e N guardiões ) onde N=5(. A chave principal pode realizar operações de baixo valor e não financeiras. A maioria dos guardiões precisa executar )i( operações de alto valor, como enviar todo o valor da conta, ou )ii( alterar a chave principal ou qualquer guardião. Se necessário, a chave principal pode ser autorizada a executar operações de alto valor através de um bloqueio temporal.
O design básico pode ser expandido. Mecanismos de autorização, como chaves de sessão e ERC-7715, podem ajudar a apoiar o equilíbrio entre a conveniência e a segurança de diferentes aplicações. Estruturas de guardião mais complexas, como aquelas com múltiplas durações de bloqueio de tempo em diferentes limiares, podem ajudar a maximizar as chances de recuperação bem-sucedida de contas legítimas, enquanto minimizam o risco de roubo.
![Vitalik Novo Artigo: A Visão da Carteira Ideal, Atualização Abrangente da Experiência de Cadeia Cruzada à Proteção de Privacidade])https://img-cdn.gateio.im/webp-social/moments-66ec52b10d00460414381b99c15622ee.webp(
) Escolha do Guardião
Para usuários experientes em criptomoedas, uma opção viável é a chave de amigos e familiares. Se cada pessoa for solicitada a fornecer um novo endereço, ninguém precisa saber a identidade um do outro, tornando a possibilidade de conluio muito pequena. Mas para a maioria dos novos usuários, essa opção não está disponível.
A segunda opção é o guardião institucional: um serviço que assina transações apenas após receber outras informações de confirmação. Há muito tempo que se tenta criar esse tipo de serviço, mas até agora com pouco sucesso.
A terceira opção é múltiplos dispositivos pessoais ### como telemóveis, computadores e carteiras de hardware (. Isso é viável, mas difícil de configurar e gerenciar para iniciantes. Existe o risco de perda ou roubo dos dispositivos simultaneamente, especialmente quando estão localizados no mesmo local.
Recentemente, surgiram mais soluções baseadas em chaves universais. As chaves podem ser armazenadas em dispositivos ou na nuvem, e a segurança depende de uma combinação complexa de segurança de senhas, suposições institucionais e de hardware confiável. Para o usuário comum, isso representa um ganho de segurança valioso, mas apenas com essas medidas não é suficiente para proteger as economias de uma vida inteira dos usuários.
Felizmente, com o ZK-SNARK, temos uma quarta opção: ID centralizado empacotado em ZK. Esses tipos de soluções incluem zk-email, Anon Aadhaar, Myna Wallet, entre outros. Basicamente, várias formas de ID centralizado de empresas ou governos ) podem ser utilizadas e convertidas em um endereço Ethereum, e as transações só podem ser enviadas gerando uma prova de posse do ID centralizado através do ZK-SNARK.
Com este suplemento, agora temos uma ampla escolha, e o ID centralizado empacotado em ZK possui uma "amigabilidade para iniciantes" única.
Para isso, é necessário implementar uma UI simplificada e integrada: deve ser possível especificar apenas "example@gmail.com" como guardião, gerando automaticamente o correspondente endereço zk-email Ethereum. Usuários avançados devem ser capazes de inserir o e-mail ( e o possível valor de sal de privacidade ) em aplicativos de terceiros de código aberto, para confirmar que o endereço gerado está correto. O mesmo deve ser aplicado a outros tipos de guardião suportados.
Atenção, os desafios práticos que o zk-email enfrenta atualmente são a dependência da assinatura DKIM, usando chaves que são trocadas a cada poucos meses, e essas chaves não são assinadas por outras entidades. Isso significa que o zk-email atual tem um certo nível de requisitos de confiança que vai além do próprio provedor; o uso de TLSNotary para validar chaves atualizadas dentro de hardware confiável pode reduzir essa situação, mas não é ideal. Espera-se que os provedores de email comecem a assinar diretamente as chaves DKIM. Atualmente, recomenda-se que um guardião utilize zk-email, mas não se recomenda que a maioria dos guardiões o faça: não armazene fundos em zk-email, pois isso significa que a configuração em que os fundos não podem ser utilizados está comprometida.
( Novos usuários e Carteira dentro do aplicativo
Os novos usuários, na verdade, não desejam inserir muitos guardiões ao se registrarem pela primeira vez. Assim, a carteira deve oferecer uma opção muito simples. O caminho natural é usar zk-email no endereço de e-mail, a chave armazenada localmente no dispositivo do usuário ) pode ser a chave mestra ### e a chave de backup mantida pelo provedor, realizando a escolha de 2 de 3. À medida que os usuários se tornam mais experientes ou acumulam mais ativos, deve-se em algum momento sugerir a adição de mais guardiões.
A integração da Carteira nas aplicações é inevitável, pois as aplicações que tentam atrair utilizadores não cripto não desejam que os utilizadores tenham de baixar duas novas aplicações, o que gera uma experiência de utilizador confusa. No entanto, muitos utilizadores de carteiras de aplicações devem ser capazes de ligar todas as carteiras, de modo a que se concentrem apenas em um "problema de controlo de acesso". A forma mais simples é adotar uma solução hierárquica, com um processo rápido de "ligação" que permita aos utilizadores definir a carteira principal como guardião de todas as carteiras internas da aplicação. O cliente Farcaster Warpcast já suporta isso.
( Proteger os usuários contra fraudes e outras ameaças externas
Além da segurança da conta, as carteiras de hoje em dia também têm realizado muitas tarefas para identificar endereços falsos, phishing, fraudes e outras ameaças externas, e se esforçam para proteger os usuários. Ao mesmo tempo, muitas medidas ainda são bastante primárias: como exigir um clique para enviar ETH ou outros tokens para qualquer novo endereço, independentemente de enviar 100 dólares ou 100.000 dólares. Não existe uma solução única para isso, mas sim uma série de melhorias contínuas para diferentes categorias de ameaças. É muito valioso continuar a trabalhar para melhorar nesta área.
![Vitalik novo artigo: a visão da carteira ideal, uma atualização abrangente da experiência de cadeia cruzada à proteção de privacidade])https://img-cdn.gateio.im/webp-social/moments-9852b894445658cf6d25e8e105ea1445.webp###
( privacidade
Agora é hora de levar a privacidade do Ethereum mais a sério. A tecnologia ZK-SNARK está muito avançada, não dependendo de portas dos fundos para reduzir os riscos regulatórios, a tecnologia de privacidade ), como o pool de privacidade ###, está se tornando cada vez mais madura, e a infraestrutura secundária, como os mempools do Waku e ERC-4337, também está se tornando mais estável. No entanto, atualmente, para realizar transferências privadas no Ethereum, os usuários precisam baixar e usar explicitamente uma "Carteira de Privacidade". Isso aumenta imensamente o inconveniente e reduz o número de pessoas dispostas a realizar transferências privadas. A solução é integrar transferências privadas diretamente na carteira.
A implementação simples é a seguinte: a Carteira pode armazenar uma parte dos ativos do usuário como "saldo privado" na piscina de privacidade. Ao realizar uma transferência, o usuário sai automaticamente da piscina de privacidade. Se o usuário precisar receber fundos, a Carteira pode gerar automaticamente um endereço invisível.
Além disso, a Carteira pode gerar automaticamente novos endereços para cada aplicativo em que o usuário participa. Os depósitos vêm do pool de privacidade, e os saques vão diretamente para o pool de privacidade. Isso permite que as atividades do usuário em qualquer aplicativo sejam desconectadas das atividades em outros aplicativos.
Esta tecnologia não só é uma forma natural de proteger a transferência de ativos privados, mas também é uma forma natural de proteger a identidade privada. A identidade já ocorreu na cadeia: qualquer aplicação que utilize provas de identidade controladas por portas, como Gitcoin Grants(, chats controlados por tokens, protocolos que seguem Ethereum, etc., são identidades na cadeia. Esperamos que este ecossistema também possa proteger a privacidade. Isso significa que a atividade do usuário na cadeia não deve estar concentrada em um só lugar: cada projeto deve ser armazenado separadamente, e a carteira do usuário deve ser a única coisa com "visão global", podendo ver todas as provas ao mesmo tempo. Um ecossistema nativo onde cada usuário possui várias contas ajuda a alcançar este objetivo, assim como protocolos de prova fora da cadeia como EAS e Zupass.
Isto representa uma visão pragmática da privacidade do Ethereum a médio prazo. Embora algumas funcionalidades possam ser introduzidas no L1 e L2 para tornar as transmissões de proteção da privacidade mais eficientes e fiáveis, isso pode ser alcançado agora. Alguns defensores da privacidade acreditam que a única aceitação é a privacidade total de todas as coisas: a criptografia completa da EVM. Isso pode ser o resultado ideal a longo prazo, mas requer uma reavaliação mais fundamental do modelo de programação, que ainda não está pronto para o nível de maturidade necessário para ser implementado no Ethereum. Precisamos realmente de privacidade padrão para obter um conjunto anónimo suficientemente grande. No entanto, primeiro focar nas transferências entre contas )i(, bem como )ii( identidade e casos de uso relacionados com a identidade ), como provas privadas (, é um primeiro passo pragmático, mais fácil de realizar, e as carteiras podem começar a usá-lo agora.
![Vitalik novo artigo: a visão da carteira ideal, uma atualização abrangente da experiência de cadeia cruzada à proteção de privacidade])https://img-cdn.gateio.im/webp-social/moments-ab5913a80a4549d9fec805c19442956b.webp(
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
11 Curtidas
Recompensa
11
8
Repostar
Compartilhar
Comentário
0/400
GateUser-ccc36bc5
· 07-08 14:33
É possível resolver o problema de lentidão da carteira?
Ver originalResponder0
OnChainArchaeologist
· 07-08 03:57
Adivinhação cega vai causar confusão. Quem é mais importante, a privacidade ou a experiência?
Ver originalResponder0
AirDropMissed
· 07-08 00:39
cadeia cruzada Carteira é só uma armadilha
Ver originalResponder0
BasementAlchemist
· 07-05 21:17
A privacidade é o mais importante, vamos lá!
Ver originalResponder0
BlockchainTalker
· 07-05 21:17
na verdade meio baseado ngl... a privacidade é a verdadeira MV aqui
Ver originalResponder0
RektRecorder
· 07-05 21:17
Chave privada não protegida é como correr nu.
Ver originalResponder0
PanicSeller
· 07-05 21:16
Pedir dinheiro emprestado para alavancar não é tão bom quanto tomar remédios tradicionais chineses.
Ver originalResponder0
NFTArchaeologist
· 07-05 21:10
A velocidade é o mais importante na cadeia cruzada.
Visão ideal da carteira Ethereum: experiência de cadeia cruzada, proteção de privacidade e atualização de segurança
Visão da carteira Ethereum ideal: uma atualização abrangente da experiência de cadeia cruzada à proteção da privacidade
Na pilha de infraestrutura do Ethereum, a carteira é uma camada chave, mas frequentemente subestimada por pesquisadores e desenvolvedores do núcleo L1. A carteira é a janela pela qual os usuários se comunicam com o mundo Ethereum, e os usuários só podem beneficiar-se das características de descentralização, resistência à censura, segurança e privacidade oferecidas pelo Ethereum e suas aplicações quando a carteira possui as propriedades adequadas.
Recentemente, as carteiras Ethereum fizeram progressos significativos na melhoria da experiência do usuário, segurança e funcionalidades. Este artigo tem como objetivo compartilhar a visão sobre as características que uma carteira Ethereum ideal deve ter. Esta não é uma lista completa, reflete a inclinação do autor para o ciberpunk, com foco em segurança e privacidade, podendo não ser abrangente em termos de experiência do usuário. No entanto, o autor acredita que, ao otimizar a experiência do usuário, é mais eficaz implantar e iterar com base em feedback do que seguir uma lista de desejos, e, portanto, considera que se concentrar nas propriedades de segurança e privacidade é o mais valioso.
experiência do usuário em transações cadeia cruzada L2
Agora existe um roteiro cada vez mais detalhado para melhorar a experiência do usuário entre L2, incluindo partes de curto e longo prazo. Aqui discutimos a parte de curto prazo: ideias que podem ser implementadas teoricamente agora.
A ideia central é: (i) envio cruzado de L2 embutido, bem como (ii) endereço específico da cadeia e pedido de pagamento. A Carteira deve ser capaz de fornecer ao usuário um endereço que siga o estilo do rascunho ERC.
Quando o usuário recebe um endereço neste formato, deve ser capaz de colá-lo no campo "Destinatário" da Carteira e clicar em "Enviar". A Carteira deve processar automaticamente os dados de envio:
Isso se aplica ao cenário de "pagamento por copiar e colar o endereço". Para situações em que o aplicativo solicita um depósito, o fluxo ideal é expandir a API web3 e permitir que o aplicativo emita solicitações de pagamento específicas da cadeia. A Carteira pode atender a essa solicitação de qualquer maneira necessária. Para proporcionar uma boa experiência ao usuário, também é necessário padronizar a solicitação getAvailableBalance, e a Carteira deve considerar cuidadosamente em quais cadeias armazenar os ativos dos usuários por padrão, a fim de maximizar a segurança e a conveniência das transferências.
Os pedidos de pagamento específicos da cadeia também podem ser inseridos em códigos QR para serem escaneados por carteiras móveis. Em cenários de pagamento presenciais ou online, o destinatário emitirá um código QR ou uma chamada de API web3, indicando "Eu quero Y unidades do token Z na cadeia X, com ID de referência ou callback W", a carteira pode atender a esse pedido livremente. Outra opção é o protocolo de link de reclamação, onde a carteira do usuário gera um código QR ou URL contendo a autorização de reclamação, e o destinatário é responsável por transferir os fundos para sua própria carteira.
Outro tema relacionado é o pagamento de gas. Se ativos forem recebidos em um L2 sem ETH e for necessário enviar uma transação, a carteira deve ser capaz de usar automaticamente o protocolo ( como o RIP-7755) para pagar gas a partir de uma cadeia com ETH. Se a carteira prever que o usuário realizará mais transações no L2 no futuro, ela também deve usar apenas DEX para enviar uma quantidade suficiente de ETH, para que as transações futuras possam pagar gas diretamente lá, pois é mais barato (.
![Vitalik nova postagem: A visão da carteira ideal, uma atualização abrangente da experiência de cadeia cruzada à proteção da privacidade])https://img-cdn.gateio.im/webp-social/moments-e340d9eff581bff30a541c8aac3178af.webp(
) Segurança da conta
A forma de conceituação dos desafios à segurança das contas é que uma boa carteira deve atuar em duas dimensões: ###i( proteger os usuários contra ataques de hackers ou comportamentos maliciosos por parte dos desenvolvedores da carteira, )ii( proteger os usuários contra os impactos de seus próprios erros.
A solução preferencial é a recuperação social e carteiras multiassinatura, com controle de acesso em camadas. As contas dos usuários possuem duas camadas de chaves: chave principal e N guardiões ) onde N=5(. A chave principal pode realizar operações de baixo valor e não financeiras. A maioria dos guardiões precisa executar )i( operações de alto valor, como enviar todo o valor da conta, ou )ii( alterar a chave principal ou qualquer guardião. Se necessário, a chave principal pode ser autorizada a executar operações de alto valor através de um bloqueio temporal.
O design básico pode ser expandido. Mecanismos de autorização, como chaves de sessão e ERC-7715, podem ajudar a apoiar o equilíbrio entre a conveniência e a segurança de diferentes aplicações. Estruturas de guardião mais complexas, como aquelas com múltiplas durações de bloqueio de tempo em diferentes limiares, podem ajudar a maximizar as chances de recuperação bem-sucedida de contas legítimas, enquanto minimizam o risco de roubo.
![Vitalik Novo Artigo: A Visão da Carteira Ideal, Atualização Abrangente da Experiência de Cadeia Cruzada à Proteção de Privacidade])https://img-cdn.gateio.im/webp-social/moments-66ec52b10d00460414381b99c15622ee.webp(
) Escolha do Guardião
Para usuários experientes em criptomoedas, uma opção viável é a chave de amigos e familiares. Se cada pessoa for solicitada a fornecer um novo endereço, ninguém precisa saber a identidade um do outro, tornando a possibilidade de conluio muito pequena. Mas para a maioria dos novos usuários, essa opção não está disponível.
A segunda opção é o guardião institucional: um serviço que assina transações apenas após receber outras informações de confirmação. Há muito tempo que se tenta criar esse tipo de serviço, mas até agora com pouco sucesso.
A terceira opção é múltiplos dispositivos pessoais ### como telemóveis, computadores e carteiras de hardware (. Isso é viável, mas difícil de configurar e gerenciar para iniciantes. Existe o risco de perda ou roubo dos dispositivos simultaneamente, especialmente quando estão localizados no mesmo local.
Recentemente, surgiram mais soluções baseadas em chaves universais. As chaves podem ser armazenadas em dispositivos ou na nuvem, e a segurança depende de uma combinação complexa de segurança de senhas, suposições institucionais e de hardware confiável. Para o usuário comum, isso representa um ganho de segurança valioso, mas apenas com essas medidas não é suficiente para proteger as economias de uma vida inteira dos usuários.
Felizmente, com o ZK-SNARK, temos uma quarta opção: ID centralizado empacotado em ZK. Esses tipos de soluções incluem zk-email, Anon Aadhaar, Myna Wallet, entre outros. Basicamente, várias formas de ID centralizado de empresas ou governos ) podem ser utilizadas e convertidas em um endereço Ethereum, e as transações só podem ser enviadas gerando uma prova de posse do ID centralizado através do ZK-SNARK.
Com este suplemento, agora temos uma ampla escolha, e o ID centralizado empacotado em ZK possui uma "amigabilidade para iniciantes" única.
Para isso, é necessário implementar uma UI simplificada e integrada: deve ser possível especificar apenas "example@gmail.com" como guardião, gerando automaticamente o correspondente endereço zk-email Ethereum. Usuários avançados devem ser capazes de inserir o e-mail ( e o possível valor de sal de privacidade ) em aplicativos de terceiros de código aberto, para confirmar que o endereço gerado está correto. O mesmo deve ser aplicado a outros tipos de guardião suportados.
Atenção, os desafios práticos que o zk-email enfrenta atualmente são a dependência da assinatura DKIM, usando chaves que são trocadas a cada poucos meses, e essas chaves não são assinadas por outras entidades. Isso significa que o zk-email atual tem um certo nível de requisitos de confiança que vai além do próprio provedor; o uso de TLSNotary para validar chaves atualizadas dentro de hardware confiável pode reduzir essa situação, mas não é ideal. Espera-se que os provedores de email comecem a assinar diretamente as chaves DKIM. Atualmente, recomenda-se que um guardião utilize zk-email, mas não se recomenda que a maioria dos guardiões o faça: não armazene fundos em zk-email, pois isso significa que a configuração em que os fundos não podem ser utilizados está comprometida.
( Novos usuários e Carteira dentro do aplicativo
Os novos usuários, na verdade, não desejam inserir muitos guardiões ao se registrarem pela primeira vez. Assim, a carteira deve oferecer uma opção muito simples. O caminho natural é usar zk-email no endereço de e-mail, a chave armazenada localmente no dispositivo do usuário ) pode ser a chave mestra ### e a chave de backup mantida pelo provedor, realizando a escolha de 2 de 3. À medida que os usuários se tornam mais experientes ou acumulam mais ativos, deve-se em algum momento sugerir a adição de mais guardiões.
A integração da Carteira nas aplicações é inevitável, pois as aplicações que tentam atrair utilizadores não cripto não desejam que os utilizadores tenham de baixar duas novas aplicações, o que gera uma experiência de utilizador confusa. No entanto, muitos utilizadores de carteiras de aplicações devem ser capazes de ligar todas as carteiras, de modo a que se concentrem apenas em um "problema de controlo de acesso". A forma mais simples é adotar uma solução hierárquica, com um processo rápido de "ligação" que permita aos utilizadores definir a carteira principal como guardião de todas as carteiras internas da aplicação. O cliente Farcaster Warpcast já suporta isso.
( Proteger os usuários contra fraudes e outras ameaças externas
Além da segurança da conta, as carteiras de hoje em dia também têm realizado muitas tarefas para identificar endereços falsos, phishing, fraudes e outras ameaças externas, e se esforçam para proteger os usuários. Ao mesmo tempo, muitas medidas ainda são bastante primárias: como exigir um clique para enviar ETH ou outros tokens para qualquer novo endereço, independentemente de enviar 100 dólares ou 100.000 dólares. Não existe uma solução única para isso, mas sim uma série de melhorias contínuas para diferentes categorias de ameaças. É muito valioso continuar a trabalhar para melhorar nesta área.
![Vitalik novo artigo: a visão da carteira ideal, uma atualização abrangente da experiência de cadeia cruzada à proteção de privacidade])https://img-cdn.gateio.im/webp-social/moments-9852b894445658cf6d25e8e105ea1445.webp###
( privacidade
Agora é hora de levar a privacidade do Ethereum mais a sério. A tecnologia ZK-SNARK está muito avançada, não dependendo de portas dos fundos para reduzir os riscos regulatórios, a tecnologia de privacidade ), como o pool de privacidade ###, está se tornando cada vez mais madura, e a infraestrutura secundária, como os mempools do Waku e ERC-4337, também está se tornando mais estável. No entanto, atualmente, para realizar transferências privadas no Ethereum, os usuários precisam baixar e usar explicitamente uma "Carteira de Privacidade". Isso aumenta imensamente o inconveniente e reduz o número de pessoas dispostas a realizar transferências privadas. A solução é integrar transferências privadas diretamente na carteira.
A implementação simples é a seguinte: a Carteira pode armazenar uma parte dos ativos do usuário como "saldo privado" na piscina de privacidade. Ao realizar uma transferência, o usuário sai automaticamente da piscina de privacidade. Se o usuário precisar receber fundos, a Carteira pode gerar automaticamente um endereço invisível.
Além disso, a Carteira pode gerar automaticamente novos endereços para cada aplicativo em que o usuário participa. Os depósitos vêm do pool de privacidade, e os saques vão diretamente para o pool de privacidade. Isso permite que as atividades do usuário em qualquer aplicativo sejam desconectadas das atividades em outros aplicativos.
Esta tecnologia não só é uma forma natural de proteger a transferência de ativos privados, mas também é uma forma natural de proteger a identidade privada. A identidade já ocorreu na cadeia: qualquer aplicação que utilize provas de identidade controladas por portas, como Gitcoin Grants(, chats controlados por tokens, protocolos que seguem Ethereum, etc., são identidades na cadeia. Esperamos que este ecossistema também possa proteger a privacidade. Isso significa que a atividade do usuário na cadeia não deve estar concentrada em um só lugar: cada projeto deve ser armazenado separadamente, e a carteira do usuário deve ser a única coisa com "visão global", podendo ver todas as provas ao mesmo tempo. Um ecossistema nativo onde cada usuário possui várias contas ajuda a alcançar este objetivo, assim como protocolos de prova fora da cadeia como EAS e Zupass.
Isto representa uma visão pragmática da privacidade do Ethereum a médio prazo. Embora algumas funcionalidades possam ser introduzidas no L1 e L2 para tornar as transmissões de proteção da privacidade mais eficientes e fiáveis, isso pode ser alcançado agora. Alguns defensores da privacidade acreditam que a única aceitação é a privacidade total de todas as coisas: a criptografia completa da EVM. Isso pode ser o resultado ideal a longo prazo, mas requer uma reavaliação mais fundamental do modelo de programação, que ainda não está pronto para o nível de maturidade necessário para ser implementado no Ethereum. Precisamos realmente de privacidade padrão para obter um conjunto anónimo suficientemente grande. No entanto, primeiro focar nas transferências entre contas )i(, bem como )ii( identidade e casos de uso relacionados com a identidade ), como provas privadas (, é um primeiro passo pragmático, mais fácil de realizar, e as carteiras podem começar a usá-lo agora.
![Vitalik novo artigo: a visão da carteira ideal, uma atualização abrangente da experiência de cadeia cruzada à proteção de privacidade])https://img-cdn.gateio.im/webp-social/moments-ab5913a80a4549d9fec805c19442956b.webp(
) Éter