Visão do Carteira Ethereum ideal: uma atualização abrangente da experiência de cadeia cruzada à proteção de privacidade

A camada da carteira na pilha de infraestrutura do Ethereum é crucial, mas muitas vezes subestimada por pesquisadores e desenvolvedores principais. Como a janela do usuário para o mundo do Ethereum, a carteira deve possuir características como descentralização, resistência à censura, segurança e privacidade, para que os usuários possam realmente desfrutar dessas propriedades oferecidas pelo Ethereum e suas aplicações.

Recentemente, as carteiras Ethereum tiveram avanços significativos em termos de 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, mas reflete mais a minha tendência de criptopunks, focando em segurança e privacidade, podendo não ser tão abrangente em termos de experiência do usuário. No entanto, acredito que, em vez de simplesmente otimizar a experiência do usuário com base em feedbacks, focar nas propriedades de segurança e privacidade pode ser mais valioso.

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

Atualmente, já existe um roteiro em constante aprimoramento para melhorar a experiência do usuário entre cadeias cruzadas L2, incluindo partes de curto e longo prazo. Aqui, vou discutir ideias que podem ser implementadas a curto prazo.

A ideia central é: (1) funcionalidade de envio integrada de cadeia cruzada L2, (2) endereços específicos da cadeia e solicitações de pagamento. A carteira deve ser capaz de fornecer aos usuários um endereço que siga o estilo do rascunho ERC.

Quando o usuário recebe um endereço neste formato, basta colá-lo no campo "destinatário" da Carteira e clicar em "enviar", a Carteira deve processar automaticamente o envio:

• Se já houver tokens suficientes na cadeia de destino, envie diretamente.
• Se outros tokens necessários estiverem em outras cadeias, use o protocolo DEX de cadeia cruzada para enviar.
• Se houver diferentes tipos de tokens, converta-os para o tipo correto usando o DEX antes de enviar (, requer confirmação do usuário ).

Para cenários em que dapps solicitam depósitos, a prática ideal é expandir a API web3, permitindo que dapps emitam pedidos de pagamento específicos da cadeia. A Carteira precisa padronizar o pedido getAvailableBalance e 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. Nos cenários de pagamento presencial ou online, o código QR ou a chamada de API emitida pelo recebedor indica "Quero Y unidades do token Z na cadeia X, ID de referência W", e 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 autorizado, sendo o recebedor responsável pela retirada dos fundos.

O pagamento de gas também é um tópico relevante. Se o usuário receber ativos em um determinado L2, mas não tiver ETH, a carteira deve ser capaz de usar automaticamente o protocolo para pagar o gas na cadeia onde o usuário tem ETH. Se a carteira prever que o usuário fará mais transações naquele L2 no futuro, também pode usar um DEX para enviar uma certa quantidade de ETH como reserva de gas.

Segurança da Conta

Acredito que a chave para a segurança da conta reside em proteger simultaneamente os usuários contra ataques de hackers ou comportamentos maliciosos dos desenvolvedores de carteiras, bem como os erros dos próprios usuários.

A solução que eu tenho tendência a usar há muito tempo é uma carteira com controle de acesso em camadas, recuperação social e múltiplas assinaturas. As contas dos usuários têm duas camadas de chaves: uma 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 design básico pode ser expandido ainda mais. As chaves de sessão e os mecanismos de permissão podem suportar diferentes aplicações na obtenção de um equilíbrio entre conveniência e segurança. Estruturas de guardião mais complexas, como a definição de vários períodos de bloqueio de tempo sob diferentes limiares, ajudam a maximizar a taxa de sucesso na recuperação de contas legítimas, ao mesmo tempo que minimizam o risco de roubo.

Para a escolha do tutor, existem várias opções:

1. Para usuários experientes de criptomoedas, é possível escolher as chaves de amigos e familiares.
2. Guardião institucional: empresas que oferecem serviços de assinatura especializados, necessitam de confirmação adicional de informações.
3. Vários dispositivos pessoais (, como telemóveis, computadores, carteiras de hardware ), mas novos usuários podem achar difícil configurar e gerenciar.
4. A solução baseada em gerenciador de senhas pode fazer backup local ou na nuvem, mas apenas confiar neles não é suficiente para proteger todos os ativos do usuário.
5. ID centralizado empacotado em ZK: como zk-email, Anon Aadhaar, etc., pode converter ID centralizado em endereço Ethereum.

A ID centralizada empacotada em ZK é mais amigável para novos usuários. A carteira deve fornecer uma interface de usuário simplificada para integração, permitindo que os usuários especifiquem diretamente o e-mail como guardião, gerando automaticamente o endereço zk-email Ethereum correspondente. Usuários avançados devem ser capazes de verificar a correção do endereço gerado.

Para novos utilizadores, a carteira pode oferecer opções simples, como a solução 2-de-3 baseada em zk-email, armazenamento local de chaves e chaves de backup do fornecedor. À medida que a experiência do utilizador aumenta ou os ativos aumentam, deve-se sugerir a adição de mais guardiões.

A integração da carteira dentro da aplicação é inevitável, mas os usuários devem poder vincular todas as carteiras juntas, gerindo o controle de acesso de forma unificada. Uma maneira simples é adotar um esquema em camadas, permitindo que os usuários definam a carteira principal como o 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, a carteira atual tem feito um grande trabalho na identificação de endereços falsos, phishing, fraudes, entre outros. No entanto, muitas das contramedidas ainda são bastante primárias, como exigir que se clique em confirmar para enviar tokens para novos endereços, independentemente do valor. Isso requer melhorias contínuas para diferentes categorias de ameaças; não há uma solução única e definitiva.

Privacidade

É hora de levar a privacidade do Ethereum mais a sério. A tecnologia ZK-SNARK está bastante avançada, não dependendo de tecnologias de privacidade com portas dos fundos como o Privacy Pool (, que está se tornando cada vez mais madura, e a infraestrutura de segundo nível, como Waku e as mempools ERC-4337, também estão se estabilizando gradualmente. No entanto, realizar transferências privadas atualmente requer que os usuários baixem e utilizem uma "Carteira de Privacidade", o que aumenta a inconveniência e reduz o número de usuários. A solução é integrar transferências privadas diretamente nas carteiras.

Uma implementação simples é: a carteira armazena uma parte dos ativos do usuário como "saldo privado" na piscina de privacidade. Ao transferir, sai automaticamente da piscina de privacidade, e ao receber fundos, gera automaticamente um endereço invisível.

![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-2439f49163d0212333ea4207f34cdbef.webp(

Além disso, a carteira pode gerar automaticamente um novo endereço para cada aplicativo em que o usuário participa. Os depósitos vêm do fundo de privacidade, e os saques entram diretamente no fundo de privacidade. Isso permite que os usuários desacoplem suas atividades em diferentes aplicativos.

Isto não é apenas uma forma natural de proteger a privacidade da transferência de ativos, mas também uma maneira de proteger a privacidade da identidade. A identidade em cadeia já existe, como aplicações que utilizam prova de identidade, chats com controle de tokens, etc. Esperamos que este ecossistema também possa proteger a privacidade, ou seja, as atividades em cadeia dos usuários não devem estar concentradas em um só lugar: cada projeto deve ser armazenado separadamente, e apenas a carteira do usuário deve ser capaz de ver todas as provas ao mesmo tempo. Um ecossistema que suporte múltiplas contas por usuário ajuda a alcançar este objetivo, assim como protocolos de prova fora da cadeia como EAS e Zupass.

Isto representa a visão pragmática de médio prazo para a privacidade do Ethereum. Embora seja possível introduzir algumas funcionalidades no L1 e L2 para tornar as transmissões de proteção de privacidade mais eficientes e fiáveis, isso pode ser realizado agora. Alguns defensores da privacidade acreditam que apenas a privacidade total é aceitável, como a criptografia de todo o EVM. Este pode ser o resultado ideal a longo prazo, mas requer uma reconsideração mais fundamental do modelo de programação, que ainda não alcançou a maturidade necessária para ser implementada. Precisamos realmente de privacidade por defeito para obter um conjunto anônimo suficientemente grande. No entanto, concentrar-se primeiro nas transferências entre contas ), identidade e casos de uso relacionados (, como provas privadas ), é um primeiro passo pragmático, mais fácil de concretizar, e as carteiras podem começar a usá-las agora.

Carteira Ethereum também precisa se tornar uma carteira de dados

Qualquer solução de privacidade válida gera a necessidade de os usuários armazenarem dados fora da cadeia, seja para pagamentos, identificação ou outros casos de uso. Protocolos de privacidade modernos às vezes mantêm dados criptografados na cadeia, usando uma única chave privada para decriptar. Isso apresenta riscos, pois se a chave vazar ou se os computadores quânticos se tornarem viáveis, todos os dados ficarão públicos. A prova fora da cadeia requer de forma mais significativa o armazenamento de dados fora da cadeia.

A carteira não só precisa armazenar permissões de acesso na cadeia, como também precisa armazenar dados privados dos usuários. O mundo não criptografado também está cada vez mais ciente disso. Precisamos construir garantias robustas em torno da acessibilidade dos dados e da prevenção de vazamentos. Talvez possamos sobrepor essas soluções: se houver N guardiões, use o compartilhamento secreto M-of-N entre esses N guardiões para armazenar dados. Os dados são essencialmente mais difíceis de proteger, pois não é possível revogar a participação de dados de alguém, mas devemos propor soluções de custódia descentralizada que sejam o mais seguras possível.

Acesso seguro à cadeia

Atualmente, a carteira depende de fornecedores RPC para obter informações da cadeia, o que apresenta duas vulnerabilidades:

1. O fornecedor de RPC pode roubar fundos fornecendo informações falsas (, como preços de mercado ).
2. Os provedores de RPC podem obter informações privadas sobre a interação do usuário com o aplicativo.

Idealmente, gostaríamos de fechar essas duas vulnerabilidades. Resolver o primeiro problema requer a padronização de clientes leves L1 e L2, que validam diretamente o consenso da blockchain. A Helios já implementou isso para L1 e começou a dar suporte a alguns L2. Para cobrir todos os L2, precisamos de um padrão que obtenha a raiz de estado mais recente e valide a lógica de prova de estado e recibo através de contratos de configuração que representam L2. Assim, pode haver um cliente leve genérico que permita que a carteira valide com segurança qualquer estado ou evento em L1 e L2.

Para privacidade, atualmente a única maneira viável é operar seu próprio nó completo. Mas com a popularidade do L2, torna-se cada vez mais difícil operar nós completos que executem tudo. O equivalente a um cliente leve aqui é a recuperação de informações privadas (PIR). A PIR envolve servidores que mantêm cópias de todos os dados e clientes que enviam pedidos criptografados para os servidores. Os servidores realizam cálculos em todos os dados, retornando os dados criptografados necessários ao cliente, sem saber qual dado o cliente acessou.

Para garantir a honestidade do servidor, cada item do banco de dados é uma ramificação Merkle, e o cliente pode validar usando um cliente leve.

O cálculo de PIR é muito grande. As soluções incluem:

• Força bruta: melhorias em algoritmos ou hardware dedicado podem fazer com que o PIR funcione rápido o suficiente.
• Reduzir os requisitos de privacidade: como cada pesquisa tem apenas 1 milhão de "mixins".
• PIR de múltiplos servidores: ao usar vários servidores, assumindo que 1-of-N é honesto, o algoritmo PIR é geralmente mais rápido.
• Anonimato em vez de confidencialidade: Enviar solicitações através de uma rede de mistura, ocultando o remetente em vez do conteúdo. Mas isso aumentará a latência.

Encontrar a combinação técnica correta para maximizar a privacidade enquanto se mantém a utilidade no ambiente Ethereum é uma questão de pesquisa em aberto.

Carteira Ideal de Chaves

No contexto da cadeia cruzada L2, outro processo importante que precisa funcionar sem problemas é a alteração da validação da conta.