Visão da Carteira Ethereum Ideal: Atualização abrangente da experiência de cadeia cruzada à proteção da privacidade

A camada da carteira na infraestrutura do Ethereum é crucial, mas frequentemente subestimada por pesquisadores e desenvolvedores principais do L1. A carteira é a janela através da qual os usuários interagem com o mundo do Ethereum, e os usuários só podem realmente se beneficiar das propriedades de descentralização, resistência à censura, segurança e privacidade que o Ethereum e suas aplicações oferecem quando a carteira em si possui as características correspondentes.

Recentemente, as carteiras Ethereum fizeram progressos significativos na melhoria da experiência do usuário, segurança e funcionalidades. Este artigo tem como objetivo expor algumas características que uma carteira Ethereum ideal deve possuir. Esta não é uma lista completa, mas reflete a tendência do autor em relação ao ciberpunk, com foco na segurança e privacidade, podendo ter algumas deficiências na experiência do usuário. No entanto, em comparação com a simples implementação e iteração com base no feedback, uma lista de desejos pode ser menos eficaz na otimização da experiência do usuário, portanto, focar nas propriedades de segurança e privacidade pode ser mais valioso.

Experiência do usuário em transações cross-L2

O roteiro para melhorar a experiência do usuário entre L2 está cada vez mais claro, incluindo partes de curto e longo prazo. Este artigo discutirá ideias que podem ser implementadas a curto prazo.

A ideia central é: (1) funcionalidade de envio interno de cadeia cruzada L2, (2) endereços específicos da cadeia e pedidos de pagamento. A Carteira deve ser capaz de fornecer ao usuário um endereço que esteja em conformidade com um estilo específico do rascunho ERC.

Quando os usuários recebem um endereço neste formato, podem colá-lo no campo "destinatário" da Carteira e clicar em "enviar". A Carteira deve processar automaticamente o processo de envio:

• Se já houver tokens suficientes na cadeia de destino, envie diretamente.
• Se houver tokens necessários em outras cadeias, use um protocolo DEX de cadeia cruzada semelhante ao ERC-7683 para enviar
• Se houver diferentes tipos de tokens na mesma cadeia ou em outras cadeias, use DEX para converter para o tipo correto e enviar, é necessário o consentimento explícito do usuário.

Isto aplica-se ao cenário de "pagamento por copiar e colar o endereço". Para os casos em que o dapp solicita um depósito, a prática ideal é expandir a API web3, permitindo que o dapp emita pedidos de pagamento específicos da cadeia. A Carteira pode atender a esse pedido de forma flexível. Para proporcionar uma boa experiência ao usuário, também é necessário padronizar o pedido getAvailableBalance, e a Carteira deve considerar cuidadosamente em quais cadeias os ativos dos usuários são armazenados por padrão, a fim de equilibrar segurança e conveniência nas transferências.

Os pedidos de pagamento específicos da cadeia também podem ser colocados em códigos QR para serem escaneados por carteiras móveis. Em cenários de pagamento presenciais ou online, o receptor pode emitir um código QR ou chamar uma API web3 que indica "Eu preciso de Y unidades do token Z na cadeia X, com ID de referência W", e a carteira pode atender a esse pedido de forma flexível. Outra opção é o protocolo de link de reivindicação, onde a carteira do usuário gera um código QR ou URL que contém a autorização de reivindicação, e o receptor é responsável por transferir os fundos para sua própria carteira.

Outro tópico relacionado é o pagamento de gas. Se um usuário receber ativos em um L2 sem ETH e precisar enviar uma transação, a Carteira deve ser capaz de usar automaticamente o protocolo ( como o RIP-7755) para pagar gas de outras cadeias que tenham ETH. Se a Carteira prever que o usuário fará mais transações nesse L2 no futuro, também pode usar uma DEX para enviar ETH suficiente para pagar centenas de vezes de gas, para que as transações futuras possam pagar gas diretamente no L2 (, pois isso é mais barato ).

Segurança da conta

Uma boa forma de conceber a segurança da conta é que uma excelente carteira deve atuar em duas frentes: (1) proteger os usuários contra ataques ou comportamentos maliciosos dos desenvolvedores da carteira, (2) proteger os usuários contra os efeitos de seus próprios erros.

A solução preferencial é uma carteira de recuperação social e múltiplas assinaturas com controle de acesso em camadas. As contas dos usuários têm duas camadas de chaves: chave principal e N guardiões ( onde N=5). A chave principal pode ser usada para operações de baixo valor e não financeiras. A maioria dos guardiões precisa ser acionada para executar: (1) operações de alto valor, como enviar todos os fundos da conta, (2) 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 de tempo.

Este é o design básico, que pode ser expandido. Mecanismos de permissão, como a chave de sessão e ERC-7715, podem ajudar a equilibrar conveniência e segurança entre diferentes aplicações. Estruturas de guardião mais complexas, como múltiplos períodos de bloqueio temporal sob diferentes limiares, podem maximizar as chances de recuperação bem-sucedida de contas legítimas, enquanto minimizam o risco de roubo.

escolha do guardião

Para os usuários experientes da comunidade cripto, é possível escolher as chaves de amigos e familiares como guardiães. Se for exigido que cada um forneça um novo endereço, nem é necessário conhecer a identidade uns dos outros. No entanto, isso não se aplica à maioria dos novos usuários.

A segunda opção é o guardião institucional: um serviço que só assina transações quando recebe informações de confirmação adicionais solicitadas pelo usuário, como um código de confirmação ou uma videochamada de um usuário de alto valor, (. Embora haja tentativas de estabelecer esse tipo de serviço há muito tempo, ele ainda não teve muito sucesso.

A terceira opção é múltiplos dispositivos pessoais ), como telemóveis, desktops e carteiras de hardware (. Isso é viável, mas é mais difícil de configurar e gerenciar para usuários iniciantes. 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 chave universal. A chave pode ser apenas feita backup no dispositivo, tornando-se uma solução de dispositivo pessoal, ou pode ser feita backup na nuvem, com a segurança dependendo de uma combinação complexa de segurança de senha, premissas institucionais e hardware confiável. Embora seja um ganho de segurança valioso para o usuário comum, depender apenas delas 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. Este tipo inclui zk-email, Anon Aadhaar, Myna Wallet, entre outros. Basicamente, pode-se adotar várias formas de ID centralizado de empresas ou governos ) e convertê-las em endereços Ethereum, onde os usuários só podem enviar transações gerando provas ZK-SNARK que possuam ID centralizado.

O ID centralizado empacotado em ZK possui uma "amigabilidade para iniciantes" única. Para isso, é necessário implementar uma UI simplificada e integrada: o usuário só precisa especificar que deseja "example@gmail.com" como guardião, e isso deve gerar automaticamente o endereço zk-email Ethereum correspondente em segundo plano. Usuários avançados devem ser capazes de inserir seu e-mail ( e o valor de sal de privacidade que podem ter salvo ) em aplicativos de terceiros de código aberto, e confirmar que o endereço gerado está correto. O mesmo deve se aplicar a qualquer outro tipo de guardião suportado.

É importante notar que o zk-email enfrenta um desafio prático, pois depende da assinatura DKIM, que utiliza uma chave que é trocada a cada poucos meses, e essas chaves não são assinadas por nenhuma outra entidade. Isso significa que o zk-email de hoje precisa confiar, até certo ponto, no próprio provedor; se o zk-email usar TLSNotary em hardware confiável para verificar as chaves atualizadas, 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, recomenda-se usar um zk-email como guardião, mas não se recomenda que a maioria dos guardiões o utilize: não armazene fundos em um zk-email, pois um dano significa que os fundos não poderão ser acessados.

( Novos usuários e Carteira dentro da aplicação

Os novos usuários na verdade não desejam inserir muitos guardiões no momento do registro. Portanto, a Carteira deve oferecer uma opção muito simples para eles. Uma maneira 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 mestra ### e uma chave de backup mantida pelo provedor, realizando uma escolha de 2 de 3. À medida que os usuários acumulam mais experiência ou ativos, deve-se em algum momento sugerir que eles adicionem mais guardiões.

A integração da carteira na aplicação é inevitável, pois as aplicações que tentam atrair utilizadores não criptográficos não desejam que os utilizadores tenham de descarregar duas novas aplicações: ( a própria aplicação, mais a carteira Ethereum ), o que traz uma experiência de utilizador confusa. No entanto, muitos utilizadores de carteiras dentro da aplicação devem ser capazes de ligar todas as carteiras, assim só precisam de se concentrar numa "questão de controlo de acesso". A maneira mais simples é adotar um esquema em camadas, através de um rápido processo de "ligação", permitindo que os utilizadores definam a carteira principal como guardião de todas as carteiras dentro da aplicação.

( proteger os usuários contra fraudes e outras ameaças externas

Além da segurança da conta, as carteiras modernas também realizam muitos trabalhos 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 contramedidas ainda são bastante primitivas: por exemplo, exigir um clique para enviar ETH ou outros tokens para qualquer novo endereço, independentemente do valor enviado. Não existe uma única solução mágica aqui, mas sim uma série de melhorias contínuas direcionadas a diferentes categorias de ameaças. Continuar a trabalhar para melhorar essa área é muito valioso.

![Vitalik novo artigo: 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-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 depende de backdoors para reduzir os riscos de conformidade com a privacidade (, como os pools de privacidade ) estão se tornando cada vez mais maduros, e a infraestrutura de segundo nível, como Waku e os mempools 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.

Uma implementação simples é a seguinte. A Carteira pode armazenar uma parte dos ativos do usuário como "saldo privado" em um pool de privacidade. Quando o usuário realiza uma transferência, ele sai automaticamente do pool 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 aplicativo em que o usuário participa (, como o protocolo defi ). Os depósitos virão do pool de privacidade, e os saques irão diretamente para o pool de privacidade. Isso permite que as atividades do usuário em qualquer aplicativo sejam desconectadas de suas atividades em outros aplicativos.

Esta tecnologia não é apenas um meio natural de proteger a transferência de ativos de privacidade, mas também um meio natural de proteger a identidade de privacidade. A identidade já está presente na cadeia: qualquer aplicação que utilize controle de prova de identidade (, como o Gitcoin Grants ), qualquer chat com controle de token, 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 na cadeia do usuário não devem ser coletadas em um único lugar: cada projeto deve ser armazenado separadamente, a carteira do usuário deve ser a única coisa que possui uma "visão global" e pode ver todas as provas ao mesmo tempo. Um ecossistema nativo onde cada usuário possui várias contas ajuda a alcançar esse 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 de privacidade mais eficientes e fiáveis, isto já pode ser alcançado agora. Alguns defensores da privacidade acreditam que a única coisa aceitável é a privacidade total de tudo: criptografar toda a EVM. Este pode ser o resultado ideal a longo prazo, mas requer uma reconsideração mais fundamental do modelo de programação,