A visão da carteira ideal de Ethereum: uma atualização abrangente da experiência de cadeia cruzada à proteção de privacidade
A camada de carteira na pilha de infraestrutura do Ethereum é crucial, mas frequentemente subestimada por pesquisadores e desenvolvedores do núcleo L1. A carteira é a janela através da qual os usuários interagem com o mundo do Ethereum, e se os usuários podem desfrutar das características de descentralização, resistência à censura, segurança e privacidade que o Ethereum e suas aplicações oferecem, depende se a própria carteira possui essas propriedades.
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 algumas das minhas opiniões sobre as características que uma carteira Ethereum ideal deve ter. Esta não é uma lista completa, reflete a minha tendência de criptoanarquista, com foco na segurança e privacidade, podendo carecer em termos de experiência do usuário. Acredito que, ao otimizar a experiência do usuário, simplesmente implementar e iterar com base no feedback é mais eficaz do que uma lista de desejos, portanto, considero que focar nas propriedades de segurança e privacidade é o mais valioso.
Experiência do usuário em transações跨L2
Agora existe um roteiro cada vez mais detalhado para melhorar a experiência do usuário entre cadeias cruzadas L2, incluindo partes de curto e longo prazo. Aqui, discutimos principalmente a parte de curto prazo: ideias que ainda podem ser implementadas teoricamente mesmo hoje.
A ideia central é: (1) funcionalidade de envio integrada de cadeia cruzada L2, (2) endereço específico da cadeia e solicitação de pagamento. Sua carteira deve fornecer um endereço específico da cadeia, seguindo o estilo do rascunho ERC relevante.
Quando alguém ( ou algum aplicativo ) lhe fornecer um endereço neste formato, você deve ser capaz de colá-lo no campo "destinatário" da carteira e, em seguida, clicar em "enviar". A carteira deve processar automaticamente os dados de envio de qualquer forma possível:
Se você já tiver tokens do tipo necessário na cadeia de destino, envie diretamente.
Se você tiver o tipo de token necessário em outras cadeias, usar protocolos como ERC-7683 ( é na verdade um DEX de cadeia cruzada ).
Se você tiver diferentes tipos de tokens na mesma cadeia ou em outras cadeias, use o DEX para convertê-los na moeda correta do tipo correto na cadeia e envie. Isso requer a autorização explícita do usuário: o usuário verá as taxas pagas e o montante recebido pelo destinatário.
O acima aplica-se ao cenário de "copiar e colar o endereço ( ou ENS, como vitalik.eth@optimism.eth), se alguém lhe enviar um pagamento". Para o caso de dapp solicitar depósitos, o fluxo ideal é expandir a API web3, permitindo que a dapp emita solicitações de pagamento específicas da cadeia. Sua Carteira poderá atender a essa solicitação de qualquer forma necessária. Para proporcionar uma boa experiência ao usuário, também é necessário padronizar a solicitação getAvailableBalance; a Carteira precisa considerar cuidadosamente em quais cadeias os ativos dos usuários serão armazenados 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 de consumidor, seja presencial ( ou online ), o recebedor emitirá um código QR ou uma chamada de API web3, indicando "Eu quero Y unidades do token Z na cadeia X, referência ID ou callback W", a carteira pode escolher livremente a forma de atender a esse pedido. Outra opção é o protocolo de link de reivindicação, onde a carteira do usuário gera um código QR ou URL contendo a autorização de reivindicação, para obter uma certa quantidade de fundos de seu contrato na cadeia, o recebedor precisa descobrir como transferir os fundos para sua própria carteira.
Outro tema relacionado é o pagamento de gas. Se você receber ativos em um L2 onde ainda não tem ETH, ao enviar uma transação nesse L2, a carteira deve ser capaz de usar automaticamente o protocolo ( como RIP-7755) para pagar o gas a partir de uma cadeia onde você possui ETH. Se a carteira antecipa que você terá mais transações no L2 no futuro, ela também deve usar apenas DEX para enviar ETH no valor de centenas de transações de gas, para que as transações futuras possam pagar o gas diretamente lá ( porque é mais barato ).
Segurança da conta
Uma forma de conceitualizar os desafios de segurança da conta é que uma boa carteira deve atuar em duas frentes: (1) proteger os usuários contra ataques de hackers ou comportamentos maliciosos dos desenvolvedores da carteira, (2) proteger os usuários contra os efeitos de seus próprios erros.
A minha solução preferida é a recuperação social e a Carteira de múltiplas assinaturas, com controlo de acesso em camadas. As contas dos utilizadores têm duas camadas de chaves: a chave principal e N tutores (, onde N=5). A chave principal pode executar operações de baixo valor e não financeiras. A maioria dos tutores precisa de executar: (1) operações de alto valor, como enviar todo o valor da conta, (2) mudar a chave principal ou qualquer tutor. Se necessário, pode-se permitir que a chave principal execute operações de alto valor através de um bloqueio temporal.
Este é o design básico, que pode ser expandido. Mecanismos de autorização como a chave de sessão e o ERC-7715 podem ajudar a equilibrar a conveniência e a segurança entre diferentes aplicações. Estruturas de guardião mais complexas, como ter várias durações de bloqueio de tempo sob diferentes limiares, podem ajudar a maximizar as chances de recuperação bem-sucedida de contas legítimas, enquanto minimizam o risco de roubo.
Seleção de 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 quem são - na verdade, os guardiões nem precisam conhecer a identidade uns dos outros. Se eles não trocarem mensagens, a possibilidade de conluio é muito pequena. No entanto, para a maioria dos novos usuários, essa opção não está disponível.
A segunda opção é um guardião institucional: empresas que oferecem serviços que assinam transações apenas quando recebem outras informações de confirmação a seu pedido, como códigos de confirmação, ou chamadas de vídeo para usuários de alto valor. Há muito tempo as pessoas tentam criar isso, como minha apresentação à CryptoCorp em 2013. No entanto, até agora essas empresas não tiveram muito sucesso.
A terceira opção é ter vários dispositivos pessoais (, como telemóveis, desktops e Carteiras ). Isso é viável, mas pode ser difícil de configurar e gerenciar para usuários sem experiência. Também existe o risco de perda ou roubo dos dispositivos ao mesmo tempo, especialmente quando estão localizados no mesmo lugar.
Recentemente, começamos a ver mais soluções baseadas em chaves universais. As chaves podem ser apenas copiadas no seu dispositivo, tornando-se uma solução de dispositivo pessoal, ou podem ser copiadas na nuvem, fazendo com que a sua segurança dependa de complexas suposições de segurança de senhas híbridas, instituições e hardware confiável. Na verdade, as chaves universais são um ganho de segurança valioso para o usuário comum, mas apenas elas não são suficientes para proteger as economias de uma vida inteira do usuário.
Felizmente, com ZK-SNARK, temos uma quarta opção: ID centralizado empacotado em ZK. Este tipo inclui zk-email, Anon Aadhaar, Myna Wallet, entre outros. Basicamente, você pode adotar várias formas de ID centralizado de empresas ou governos ( e convertê-las em endereços Ethereum; você só pode enviar transações gerando uma prova de posse do ID centralizado usando ZK-SNARK.
Com este suplemento, agora temos uma ampla escolha, com IDs centralizados empacotados em ZK que têm uma "amigabilidade para novatos" única.
Para isso, é necessário implementar uma UI simplificada e integrada: você deve poder especificar apenas o que deseja "example@gmail.com" como guardião, e ela deve gerar automaticamente o endereço zk-email Ethereum correspondente. Usuários avançados devem ser capazes de inserir o e-mail ) e o possível valor de sal de privacidade armazenado ( em uma aplicação de terceiros de código aberto e confirmar que o endereço gerado está correto. O mesmo deve ser aplicado a qualquer outro tipo de guardião suportado.
É importante notar que o zk-email enfrenta um desafio prático atual, pois depende da assinatura DKIM, que usa chaves que são rotacionadas a cada poucos meses e essas chaves não são assinadas por nenhuma outra entidade. Isso significa que o zk-email atual tem um certo nível de exigência de confiança que vai além do próprio provedor; se o zk-email usar a validação TLSNotary dentro de hardware confiável para atualizar as chaves, isso pode reduzir essa situação, mas não é ideal. Espera-se que os provedores de e-mail comecem a assinar diretamente suas chaves DKIM. Atualmente, eu sugiro usar um guardião zk-email, mas não recomendo o uso da maioria dos guardiões: não armazene fundos em um zk-email danificado, o que significa que os fundos se tornam inacessíveis.
![Vitalik novo artigo: 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-6e92b6b051653e68d5f93ed0d91891eb.webp(
Novos usuários e Carteira dentro da aplicação
Os novos usuários, na verdade, não desejam inserir muitos guardiões durante o registro pela primeira vez. Portanto, a carteira deve oferecer a eles uma opção muito simples. Um caminho natural é usar zk-email em seu endereço de e-mail, uma chave armazenada localmente no dispositivo do usuário ) que pode ser a chave universal (, além de uma chave de backup mantida pelo provedor, para uma escolha de 2 de 3. À medida que os usuários se tornam mais experientes ou acumulam mais ativos, eles devem ser solicitados em algum momento a adicionar mais guardiões.
A integração da carteira na aplicação é inevitável, pois as aplicações que tentam atrair usuários não criptográficos não desejam que os usuários baixem simultaneamente duas novas aplicações ), a própria aplicação, juntamente com a carteira Ethereum (, o que traz uma experiência do usuário confusa. No entanto, muitos usuários de carteiras dentro da aplicação devem conseguir conectar todas as carteiras, assim só precisam se preocupar com um "problema de controle de acesso". A maneira mais simples é adotar um esquema hierárquico, com um rápido processo de "linkagem" que permite aos usuários definir a carteira principal como o guardião de todas as carteiras dentro da aplicação. O cliente Farcaster Warpcast já suporta isso.
![Vitalik nova publicação: a visão de uma carteira ideal, uma atualização abrangente da experiência de cadeia cruzada à proteção de privacidade])https://img-cdn.gateio.im/webp-social/moments-2439f49163d0212333ea4207f34cdbef.webp(
Proteger os utilizadores contra fraudes e outras ameaças externas
Além da segurança da conta, as carteiras de hoje também fazem muito trabalho 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 primitivas: 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 única solução mágica. Trata-se de uma série de correções e melhorias lentas e contínuas contra diferentes categorias de ameaças. No entanto, o esforço contínuo para melhorar é valioso.
![Vitalik novo artigo: 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-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 o risco regulatório, enquanto as tecnologias de privacidade ), como o pool de privacidade (, estão se tornando cada vez mais maduras, e infraestruturas secundárias como Waku e mempools ERC-4337 também estão se estabilizando gradualmente. No entanto, atualmente, realizar transferências privadas no Ethereum exige que os usuários baixem e utilizem explicitamente uma "Carteira de Privacidade", como a Railway ) ou a Umbra ( para endereços invisíveis. Isso aumenta consideravelmente o incômodo e reduz o número de pessoas dispostas a realizar transferências privadas. A solução é integrar transferências privadas diretamente nas carteiras.
Uma implementação simples é a seguinte. A carteira pode armazenar uma parte dos ativos do usuário como "saldo privado" na piscina de privacidade. Quando o usuário faz uma transferência, ele 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 um novo endereço ) para cada aplicação em que o usuário participa, como o protocolo defi (. Os depósitos vêm de um pool de privacidade, e os saques vão diretamente para o pool de privacidade. Isso permite que as atividades do usuário em uma aplicação sejam desvinculadas das atividades em outras aplicações.
Esta tecnologia não é apenas uma forma natural de proteger a transferência de ativos de privacidade, mas também uma forma natural de proteger identidades de privacidade. A identidade já ocorreu na cadeia: qualquer aplicação controlada por identificação ), como Gitcoin Grants (, qualquer chat controlado 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 as atividades dos usuários na cadeia não devem estar centralizadas em um só lugar: cada projeto deve ser armazenado separadamente, e a carteira do usuário deve ser a única que tenha uma "visão global", podendo ser.
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.
23 Curtidas
Recompensa
23
6
Compartilhar
Comentário
0/400
SandwichDetector
· 07-16 06:01
A privacidade é a primeira produção!
Ver originalResponder0
MiningDisasterSurvivor
· 07-13 07:07
18 anos de lições do desastre na mina ainda não foram esquecidas, primeiro mantenha a carteira segura antes de falar sobre outras coisas.
Ver originalResponder0
HappyToBeDumped
· 07-13 07:06
É só olhar para um número e já fica tudo verde. Que carteira é essa?
Ver originalResponder0
DeepRabbitHole
· 07-13 06:48
Esta carteira é tão boa, por que é que andam sempre a perder a chave privada?
Ver originalResponder0
HalfBuddhaMoney
· 07-13 06:45
Não consigo ver, companheiro. Apenas estou de olho na privacidade.
Ver originalResponder0
Rugpull幸存者
· 07-13 06:45
Em termos de privacidade, ainda é bastante irrelevante.
Ethereum Carteira evolução: da experiência de cadeia cruzada à atualização abrangente da proteção de privacidade
A visão da carteira ideal de Ethereum: uma atualização abrangente da experiência de cadeia cruzada à proteção de privacidade
A camada de carteira na pilha de infraestrutura do Ethereum é crucial, mas frequentemente subestimada por pesquisadores e desenvolvedores do núcleo L1. A carteira é a janela através da qual os usuários interagem com o mundo do Ethereum, e se os usuários podem desfrutar das características de descentralização, resistência à censura, segurança e privacidade que o Ethereum e suas aplicações oferecem, depende se a própria carteira possui essas propriedades.
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 algumas das minhas opiniões sobre as características que uma carteira Ethereum ideal deve ter. Esta não é uma lista completa, reflete a minha tendência de criptoanarquista, com foco na segurança e privacidade, podendo carecer em termos de experiência do usuário. Acredito que, ao otimizar a experiência do usuário, simplesmente implementar e iterar com base no feedback é mais eficaz do que uma lista de desejos, portanto, considero que focar nas propriedades de segurança e privacidade é o mais valioso.
Experiência do usuário em transações跨L2
Agora existe um roteiro cada vez mais detalhado para melhorar a experiência do usuário entre cadeias cruzadas L2, incluindo partes de curto e longo prazo. Aqui, discutimos principalmente a parte de curto prazo: ideias que ainda podem ser implementadas teoricamente mesmo hoje.
A ideia central é: (1) funcionalidade de envio integrada de cadeia cruzada L2, (2) endereço específico da cadeia e solicitação de pagamento. Sua carteira deve fornecer um endereço específico da cadeia, seguindo o estilo do rascunho ERC relevante.
Quando alguém ( ou algum aplicativo ) lhe fornecer um endereço neste formato, você deve ser capaz de colá-lo no campo "destinatário" da carteira e, em seguida, clicar em "enviar". A carteira deve processar automaticamente os dados de envio de qualquer forma possível:
O acima aplica-se ao cenário de "copiar e colar o endereço ( ou ENS, como vitalik.eth@optimism.eth), se alguém lhe enviar um pagamento". Para o caso de dapp solicitar depósitos, o fluxo ideal é expandir a API web3, permitindo que a dapp emita solicitações de pagamento específicas da cadeia. Sua Carteira poderá atender a essa solicitação de qualquer forma necessária. Para proporcionar uma boa experiência ao usuário, também é necessário padronizar a solicitação getAvailableBalance; a Carteira precisa considerar cuidadosamente em quais cadeias os ativos dos usuários serão armazenados 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 de consumidor, seja presencial ( ou online ), o recebedor emitirá um código QR ou uma chamada de API web3, indicando "Eu quero Y unidades do token Z na cadeia X, referência ID ou callback W", a carteira pode escolher livremente a forma de atender a esse pedido. Outra opção é o protocolo de link de reivindicação, onde a carteira do usuário gera um código QR ou URL contendo a autorização de reivindicação, para obter uma certa quantidade de fundos de seu contrato na cadeia, o recebedor precisa descobrir como transferir os fundos para sua própria carteira.
Outro tema relacionado é o pagamento de gas. Se você receber ativos em um L2 onde ainda não tem ETH, ao enviar uma transação nesse L2, a carteira deve ser capaz de usar automaticamente o protocolo ( como RIP-7755) para pagar o gas a partir de uma cadeia onde você possui ETH. Se a carteira antecipa que você terá mais transações no L2 no futuro, ela também deve usar apenas DEX para enviar ETH no valor de centenas de transações de gas, para que as transações futuras possam pagar o gas diretamente lá ( porque é mais barato ).
Segurança da conta
Uma forma de conceitualizar os desafios de segurança da conta é que uma boa carteira deve atuar em duas frentes: (1) proteger os usuários contra ataques de hackers ou comportamentos maliciosos dos desenvolvedores da carteira, (2) proteger os usuários contra os efeitos de seus próprios erros.
A minha solução preferida é a recuperação social e a Carteira de múltiplas assinaturas, com controlo de acesso em camadas. As contas dos utilizadores têm duas camadas de chaves: a chave principal e N tutores (, onde N=5). A chave principal pode executar operações de baixo valor e não financeiras. A maioria dos tutores precisa de executar: (1) operações de alto valor, como enviar todo o valor da conta, (2) mudar a chave principal ou qualquer tutor. Se necessário, pode-se permitir que a chave principal execute operações de alto valor através de um bloqueio temporal.
Este é o design básico, que pode ser expandido. Mecanismos de autorização como a chave de sessão e o ERC-7715 podem ajudar a equilibrar a conveniência e a segurança entre diferentes aplicações. Estruturas de guardião mais complexas, como ter várias durações de bloqueio de tempo sob diferentes limiares, podem ajudar a maximizar as chances de recuperação bem-sucedida de contas legítimas, enquanto minimizam o risco de roubo.
Seleção de 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 quem são - na verdade, os guardiões nem precisam conhecer a identidade uns dos outros. Se eles não trocarem mensagens, a possibilidade de conluio é muito pequena. No entanto, para a maioria dos novos usuários, essa opção não está disponível.
A segunda opção é um guardião institucional: empresas que oferecem serviços que assinam transações apenas quando recebem outras informações de confirmação a seu pedido, como códigos de confirmação, ou chamadas de vídeo para usuários de alto valor. Há muito tempo as pessoas tentam criar isso, como minha apresentação à CryptoCorp em 2013. No entanto, até agora essas empresas não tiveram muito sucesso.
A terceira opção é ter vários dispositivos pessoais (, como telemóveis, desktops e Carteiras ). Isso é viável, mas pode ser difícil de configurar e gerenciar para usuários sem experiência. Também existe o risco de perda ou roubo dos dispositivos ao mesmo tempo, especialmente quando estão localizados no mesmo lugar.
Recentemente, começamos a ver mais soluções baseadas em chaves universais. As chaves podem ser apenas copiadas no seu dispositivo, tornando-se uma solução de dispositivo pessoal, ou podem ser copiadas na nuvem, fazendo com que a sua segurança dependa de complexas suposições de segurança de senhas híbridas, instituições e hardware confiável. Na verdade, as chaves universais são um ganho de segurança valioso para o usuário comum, mas apenas elas não são suficientes para proteger as economias de uma vida inteira do usuário.
Felizmente, com ZK-SNARK, temos uma quarta opção: ID centralizado empacotado em ZK. Este tipo inclui zk-email, Anon Aadhaar, Myna Wallet, entre outros. Basicamente, você pode adotar várias formas de ID centralizado de empresas ou governos ( e convertê-las em endereços Ethereum; você só pode enviar transações gerando uma prova de posse do ID centralizado usando ZK-SNARK.
Com este suplemento, agora temos uma ampla escolha, com IDs centralizados empacotados em ZK que têm uma "amigabilidade para novatos" única.
Para isso, é necessário implementar uma UI simplificada e integrada: você deve poder especificar apenas o que deseja "example@gmail.com" como guardião, e ela deve gerar automaticamente o endereço zk-email Ethereum correspondente. Usuários avançados devem ser capazes de inserir o e-mail ) e o possível valor de sal de privacidade armazenado ( em uma aplicação de terceiros de código aberto e confirmar que o endereço gerado está correto. O mesmo deve ser aplicado a qualquer outro tipo de guardião suportado.
É importante notar que o zk-email enfrenta um desafio prático atual, pois depende da assinatura DKIM, que usa chaves que são rotacionadas a cada poucos meses e essas chaves não são assinadas por nenhuma outra entidade. Isso significa que o zk-email atual tem um certo nível de exigência de confiança que vai além do próprio provedor; se o zk-email usar a validação TLSNotary dentro de hardware confiável para atualizar as chaves, isso pode reduzir essa situação, mas não é ideal. Espera-se que os provedores de e-mail comecem a assinar diretamente suas chaves DKIM. Atualmente, eu sugiro usar um guardião zk-email, mas não recomendo o uso da maioria dos guardiões: não armazene fundos em um zk-email danificado, o que significa que os fundos se tornam inacessíveis.
![Vitalik novo artigo: 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-6e92b6b051653e68d5f93ed0d91891eb.webp(
Novos usuários e Carteira dentro da aplicação
Os novos usuários, na verdade, não desejam inserir muitos guardiões durante o registro pela primeira vez. Portanto, a carteira deve oferecer a eles uma opção muito simples. Um caminho natural é usar zk-email em seu endereço de e-mail, uma chave armazenada localmente no dispositivo do usuário ) que pode ser a chave universal (, além de uma chave de backup mantida pelo provedor, para uma escolha de 2 de 3. À medida que os usuários se tornam mais experientes ou acumulam mais ativos, eles devem ser solicitados em algum momento a adicionar mais guardiões.
A integração da carteira na aplicação é inevitável, pois as aplicações que tentam atrair usuários não criptográficos não desejam que os usuários baixem simultaneamente duas novas aplicações ), a própria aplicação, juntamente com a carteira Ethereum (, o que traz uma experiência do usuário confusa. No entanto, muitos usuários de carteiras dentro da aplicação devem conseguir conectar todas as carteiras, assim só precisam se preocupar com um "problema de controle de acesso". A maneira mais simples é adotar um esquema hierárquico, com um rápido processo de "linkagem" que permite aos usuários definir a carteira principal como o guardião de todas as carteiras dentro da aplicação. O cliente Farcaster Warpcast já suporta isso.
![Vitalik nova publicação: a visão de uma carteira ideal, uma atualização abrangente da experiência de cadeia cruzada à proteção de privacidade])https://img-cdn.gateio.im/webp-social/moments-2439f49163d0212333ea4207f34cdbef.webp(
Proteger os utilizadores contra fraudes e outras ameaças externas
Além da segurança da conta, as carteiras de hoje também fazem muito trabalho 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 primitivas: 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 única solução mágica. Trata-se de uma série de correções e melhorias lentas e contínuas contra diferentes categorias de ameaças. No entanto, o esforço contínuo para melhorar é valioso.
![Vitalik novo artigo: 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-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 o risco regulatório, enquanto as tecnologias de privacidade ), como o pool de privacidade (, estão se tornando cada vez mais maduras, e infraestruturas secundárias como Waku e mempools ERC-4337 também estão se estabilizando gradualmente. No entanto, atualmente, realizar transferências privadas no Ethereum exige que os usuários baixem e utilizem explicitamente uma "Carteira de Privacidade", como a Railway ) ou a Umbra ( para endereços invisíveis. Isso aumenta consideravelmente o incômodo e reduz o número de pessoas dispostas a realizar transferências privadas. A solução é integrar transferências privadas diretamente nas carteiras.
Uma implementação simples é a seguinte. A carteira pode armazenar uma parte dos ativos do usuário como "saldo privado" na piscina de privacidade. Quando o usuário faz uma transferência, ele 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 um novo endereço ) para cada aplicação em que o usuário participa, como o protocolo defi (. Os depósitos vêm de um pool de privacidade, e os saques vão diretamente para o pool de privacidade. Isso permite que as atividades do usuário em uma aplicação sejam desvinculadas das atividades em outras aplicações.
Esta tecnologia não é apenas uma forma natural de proteger a transferência de ativos de privacidade, mas também uma forma natural de proteger identidades de privacidade. A identidade já ocorreu na cadeia: qualquer aplicação controlada por identificação ), como Gitcoin Grants (, qualquer chat controlado 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 as atividades dos usuários na cadeia não devem estar centralizadas em um só lugar: cada projeto deve ser armazenado separadamente, e a carteira do usuário deve ser a única que tenha uma "visão global", podendo ser.