Visão ideal da Carteira Ethereum: atualização abrangente da experiência de cadeia cruzada à proteção da privacidade
Uma camada chave da pilha de infraestrutura do Ethereum é a Carteira, mas frequentemente é subestimada pelos pesquisadores e desenvolvedores principais de L1. A Carteira é a janela entre os usuários e o mundo do Ethereum, onde os usuários podem se beneficiar de quaisquer atributos descentralizados, de resistência à censura, segurança, privacidade ou outros que o Ethereum e suas aplicações oferecem, desde que a própria Carteira também possua esses atributos.
Recentemente, a carteira Ethereum fez grandes progressos na melhoria da experiência do usuário, segurança e funcionalidades. O objetivo deste artigo é apresentar algumas características que uma carteira Ethereum ideal deve ter. Esta não é uma lista completa; reflete as tendências dos ciberpunks, focando na segurança e privacidade, e quase certamente está incompleta em termos de experiência do usuário. No entanto, a lista de desejos não é tão eficaz na otimização da experiência do usuário quanto simplesmente implantar e iterar com base no feedback, portanto, focar nas propriedades de segurança e privacidade é o mais valioso.
Experiência do usuário em transações inter-cadeia L2
Agora há um roteiro cada vez mais detalhado para melhorar a experiência do usuário entre cadeias cruzadas L2, que tem partes de curto prazo e de longo prazo. Aqui vamos falar sobre a parte de curto prazo: ideias que teoricamente ainda podem ser implementadas hoje.
A ideia central é (i) enviar dentro da cadeia cruzada L2, assim como (ii) endereços específicos da cadeia e pedidos de pagamento. A carteira deve ser capaz de fornecer um endereço ao usuário, seguindo o estilo do rascunho ERC relevante.
Quando alguém ( ou algumas aplicações ) fornecem a este formato de endereço, o utilizador 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 enviados de qualquer maneira possível:
Se o usuário já tiver tokens do tipo necessário na cadeia de destino, envie os tokens diretamente.
Se o usuário tiver o tipo de token necessário em outra cadeia ( ou em várias outras cadeias ), usar o protocolo relevante ( é na verdade um DEX de cadeia cruzada ) para enviar tokens.
Se os usuários tiverem diferentes tipos de tokens na mesma cadeia ou em outras cadeias, use uma exchange descentralizada para convertê-los na moeda correta do tipo correto na cadeia correta e envie-os. Isso deve exigir a permissão explícita do usuário: o usuário verá quanto pagou em taxas e quanto o destinatário recebeu em taxas.
O conteúdo acima aplica-se ao caso de uso "o usuário copia e cola o endereço ( ou ENS, por exemplo, vitalik.eth @ optimism.eth) alguém faz um pagamento ao usuário". Se o dapp solicitar um depósito, o fluxo ideal é expandir a API web3 e permitir que o dapp emita solicitações de pagamento específicas da cadeia. Então, a Carteira poderá 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 precisa considerar cuidadosamente em quais cadeias armazenar os ativos do usuário por padrão, a fim de maximizar a segurança e a conveniência da transferência.
Os pedidos de pagamento específicos da cadeia também podem ser inseridos em códigos QR, e as carteiras móveis podem escanear os códigos QR. Em cenários de pagamento do consumidor, seja pessoalmente ( ou online ), o receptor emitirá um código QR ou uma chamada de API web3, indicando "Eu quero X unidades do token YZ na cadeia, com referência ID ou callback W", e a carteira poderá atender a esse pedido de qualquer forma. 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, e o trabalho do receptor é descobrir como transferir esses fundos para sua própria carteira.
Outro tema relevante é o pagamento de gas. Se um usuário receber ativos em uma L2 sem ETH e precisar enviar uma transação nessa L2, 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 deseja que o usuário faça mais transações no futuro na L2, ela também deve usar apenas DEX para enviar, por exemplo, ETH no valor de milhões de Gas, para que transações futuras possam gastar Gas diretamente lá, porque isso é mais barato (.
![Vitalik novo artigo: A visão da carteira ideal, uma atualização abrangente da experiência em cadeia cruzada à proteção de privacidade])https://img-cdn.gateio.im/webp-social/moments-66ec52b10d00460414381b99c15622ee.webp(
Segurança da Conta
Uma forma de conceitualizar o desafio da segurança da conta é que uma boa carteira deve funcionar em duas frentes: )i( proteger os usuários contra ataques de hackers ou ataques maliciosos por parte dos desenvolvedores da carteira, e )ii( proteger os usuários contra os impactos de seus próprios erros.
A solução preferida para isso, ao longo de mais de uma década, tem sido a recuperação social e carteiras de múltiplas assinaturas, com controle de acesso em camadas. As contas dos usuários possuem duas camadas de chaves: chave principal e N guardiões ), por exemplo, N = 5(. A chave principal é capaz de realizar operações de baixo valor e não financeiras. A maioria dos guardiões precisa ser envolvida para realizar operações de alto valor )i(, 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 realizar operações de alto valor através de um bloqueio de tempo.
Acima está o design básico, que pode ser expandido. As chaves de sessão e os mecanismos de permissão relacionados podem ajudar a suportar o equilíbrio entre a conveniência e a segurança de 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 recuperar contas legítimas com sucesso, ao mesmo tempo que minimizam o risco de roubo.
![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-6e92b6b051653e68d5f93ed0d91891eb.webp(
Quem ou o que deve ser o guardião?
Para a comunidade de usuários de criptomoedas experientes, uma opção viável é que amigos e familiares do usuário tenham as chaves. Se o usuário pedir a todos que forneçam um novo endereço, então ninguém precisa saber quem eles são - de fato, os guardiães do usuário nem precisam saber quem são uns aos outros. Se eles não se avisarem, a probabilidade de estarem em conluio é muito pequena. No entanto, para a maioria dos novos usuários, esta opção não está disponível.
A segunda opção é o guardião institucional: empresas que oferecem serviços de assinatura de transações apenas quando recebem informações de confirmação adicionais a pedido do usuário: por exemplo, códigos de confirmação ou chamadas de vídeo para usuários de alto valor. As pessoas têm tentado criar isso há muito tempo, como a introdução da CryptoCorp em 2013. No entanto, até agora, essas empresas ainda não tiveram muito sucesso.
A terceira opção são múltiplos dispositivos pessoais ), como telefones, computadores de secretária e carteiras de hardware (. Isso pode funcionar, mas pode ser difícil de configurar e gerenciar para usuários sem experiência. Também existe o risco de perda ou roubo simultâneo dos dispositivos, especialmente quando estão localizados no mesmo lugar.
Recentemente, começamos a ver mais baseados em chave universal. A chave pode ser apenas salva no dispositivo do usuário, tornando-se uma solução de dispositivo pessoal, e também pode ser armazenada na nuvem, fazendo sua segurança depender de uma complexa mistura de segurança de senha, suposições institucionais e de hardware confiável. Na verdade, a chave é um ganho de segurança valioso para o usuário comum, mas somente com ela não é suficiente para proteger as economias de uma vida inteira do usuário.
Felizmente, com o ZK-SNARK, temos uma quarta opção: ID centralizado envolvido em ZK. Este tipo inclui zk-email, Anon Aadhaar, Myna Wallet, entre outros. Basicamente, os usuários podem adotar várias formas de ID centralizado de empresas ou governos ) e convertê-las em endereços Ethereum, os usuários só podem enviar transações gerando uma prova de posse do ID centralizado através do ZK-SNARK.
Com este suplemento, agora temos uma ampla escolha, e a ID centralizada empacotada em ZK possui uma "amigabilidade com iniciantes" única.
Para isso, é necessário implementar uma UI simplificada e integrada: os usuários devem ser capazes de especificar apenas que desejam "example@gmail.com" como guardião, e isso deve gerar automaticamente o endereço zk-email Ethereum correspondente sob o capô. Usuários avançados devem ser capazes de inserir seu e-mail ( e os possíveis valores de sal de privacidade armazenados nesse e-mail ) 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.
Por favor, note que um desafio prático que o zk-email enfrenta atualmente é a sua dependência da assinatura DKIM, que utiliza chaves que são rotacionadas a cada poucos meses, e essas chaves em si não são assinadas por nenhuma outra entidade. Isso significa que o zk-email de hoje tem um certo grau de requisitos de confiança que vão além do próprio provedor; se o zk-email usar o 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. Hoje, recomenda-se que um tutor use o zk-email, mas não se recomenda a maioria dos tutores: não armazene fundos no zk-email, pois isso significa que os usuários não podem acessar os fundos.
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. 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 ), e a 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, em algum momento, eles devem ser convidados a adicionar mais guardiões.
A integração da carteira em aplicativos é inevitável, pois os aplicativos que tentam atrair usuários não criptográficos não desejam que os usuários baixem dois novos aplicativos ao mesmo tempo, ( o próprio aplicativo, além da carteira Ethereum ), o que traz uma experiência de usuário confusa. No entanto, muitos usuários de carteiras de aplicativos deveriam ser capazes de conectar todas as suas carteiras, assim eles só precisam se preocupar com um "problema de controle de acesso". A maneira mais simples é adotar um esquema hierárquico, onde há um rápido processo de "linkagem" que permite ao usuário definir sua carteira principal como a guardiã de todas as carteiras dentro do aplicativo. Certos clientes já suportam isso.
Por padrão, a recuperação de algumas contas dentro da aplicação pode ser controlada pela equipe de desenvolvimento da aplicação. No entanto, o usuário pode "assumir" a conta do usuário e alterar a recuperação para o seu próprio endereço.
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 contra essas ameaças. 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 de o usuário estar enviando 100 dólares ou (.
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.
13 gostos
Recompensa
13
6
Partilhar
Comentar
0/400
HackerWhoCares
· 07-28 09:01
A segurança e a experiência devem ser consideradas em conjunto.
Ver originalResponder0
BoredWatcher
· 07-28 08:33
A carteira já devia ter sido atualizada!
Ver originalResponder0
TokenUnlocker
· 07-25 09:53
Carteira é a primeira força de produção!
Ver originalResponder0
BottomMisser
· 07-25 09:53
Segurança? Atualizações iterativas? Primeiro, não deixe a Carteira ser roubada antes de falar.
Carteira ideal de Ethereum: experiência em cadeia cruzada, segurança e privacidade totalmente aprimoradas
Visão ideal da Carteira Ethereum: atualização abrangente da experiência de cadeia cruzada à proteção da privacidade
Uma camada chave da pilha de infraestrutura do Ethereum é a Carteira, mas frequentemente é subestimada pelos pesquisadores e desenvolvedores principais de L1. A Carteira é a janela entre os usuários e o mundo do Ethereum, onde os usuários podem se beneficiar de quaisquer atributos descentralizados, de resistência à censura, segurança, privacidade ou outros que o Ethereum e suas aplicações oferecem, desde que a própria Carteira também possua esses atributos.
Recentemente, a carteira Ethereum fez grandes progressos na melhoria da experiência do usuário, segurança e funcionalidades. O objetivo deste artigo é apresentar algumas características que uma carteira Ethereum ideal deve ter. Esta não é uma lista completa; reflete as tendências dos ciberpunks, focando na segurança e privacidade, e quase certamente está incompleta em termos de experiência do usuário. No entanto, a lista de desejos não é tão eficaz na otimização da experiência do usuário quanto simplesmente implantar e iterar com base no feedback, portanto, focar nas propriedades de segurança e privacidade é o mais valioso.
Experiência do usuário em transações inter-cadeia L2
Agora há um roteiro cada vez mais detalhado para melhorar a experiência do usuário entre cadeias cruzadas L2, que tem partes de curto prazo e de longo prazo. Aqui vamos falar sobre a parte de curto prazo: ideias que teoricamente ainda podem ser implementadas hoje.
A ideia central é (i) enviar dentro da cadeia cruzada L2, assim como (ii) endereços específicos da cadeia e pedidos de pagamento. A carteira deve ser capaz de fornecer um endereço ao usuário, seguindo o estilo do rascunho ERC relevante.
Quando alguém ( ou algumas aplicações ) fornecem a este formato de endereço, o utilizador 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 enviados de qualquer maneira possível:
O conteúdo acima aplica-se ao caso de uso "o usuário copia e cola o endereço ( ou ENS, por exemplo, vitalik.eth @ optimism.eth) alguém faz um pagamento ao usuário". Se o dapp solicitar um depósito, o fluxo ideal é expandir a API web3 e permitir que o dapp emita solicitações de pagamento específicas da cadeia. Então, a Carteira poderá 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 precisa considerar cuidadosamente em quais cadeias armazenar os ativos do usuário por padrão, a fim de maximizar a segurança e a conveniência da transferência.
Os pedidos de pagamento específicos da cadeia também podem ser inseridos em códigos QR, e as carteiras móveis podem escanear os códigos QR. Em cenários de pagamento do consumidor, seja pessoalmente ( ou online ), o receptor emitirá um código QR ou uma chamada de API web3, indicando "Eu quero X unidades do token YZ na cadeia, com referência ID ou callback W", e a carteira poderá atender a esse pedido de qualquer forma. 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, e o trabalho do receptor é descobrir como transferir esses fundos para sua própria carteira.
Outro tema relevante é o pagamento de gas. Se um usuário receber ativos em uma L2 sem ETH e precisar enviar uma transação nessa L2, 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 deseja que o usuário faça mais transações no futuro na L2, ela também deve usar apenas DEX para enviar, por exemplo, ETH no valor de milhões de Gas, para que transações futuras possam gastar Gas diretamente lá, porque isso é mais barato (.
![Vitalik novo artigo: A visão da carteira ideal, uma atualização abrangente da experiência em cadeia cruzada à proteção de privacidade])https://img-cdn.gateio.im/webp-social/moments-66ec52b10d00460414381b99c15622ee.webp(
Segurança da Conta
Uma forma de conceitualizar o desafio da segurança da conta é que uma boa carteira deve funcionar em duas frentes: )i( proteger os usuários contra ataques de hackers ou ataques maliciosos por parte dos desenvolvedores da carteira, e )ii( proteger os usuários contra os impactos de seus próprios erros.
A solução preferida para isso, ao longo de mais de uma década, tem sido a recuperação social e carteiras de múltiplas assinaturas, com controle de acesso em camadas. As contas dos usuários possuem duas camadas de chaves: chave principal e N guardiões ), por exemplo, N = 5(. A chave principal é capaz de realizar operações de baixo valor e não financeiras. A maioria dos guardiões precisa ser envolvida para realizar operações de alto valor )i(, 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 realizar operações de alto valor através de um bloqueio de tempo.
Acima está o design básico, que pode ser expandido. As chaves de sessão e os mecanismos de permissão relacionados podem ajudar a suportar o equilíbrio entre a conveniência e a segurança de 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 recuperar contas legítimas com sucesso, ao mesmo tempo que minimizam o risco de roubo.
![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-6e92b6b051653e68d5f93ed0d91891eb.webp(
Quem ou o que deve ser o guardião?
Para a comunidade de usuários de criptomoedas experientes, uma opção viável é que amigos e familiares do usuário tenham as chaves. Se o usuário pedir a todos que forneçam um novo endereço, então ninguém precisa saber quem eles são - de fato, os guardiães do usuário nem precisam saber quem são uns aos outros. Se eles não se avisarem, a probabilidade de estarem em conluio é muito pequena. No entanto, para a maioria dos novos usuários, esta opção não está disponível.
A segunda opção é o guardião institucional: empresas que oferecem serviços de assinatura de transações apenas quando recebem informações de confirmação adicionais a pedido do usuário: por exemplo, códigos de confirmação ou chamadas de vídeo para usuários de alto valor. As pessoas têm tentado criar isso há muito tempo, como a introdução da CryptoCorp em 2013. No entanto, até agora, essas empresas ainda não tiveram muito sucesso.
A terceira opção são múltiplos dispositivos pessoais ), como telefones, computadores de secretária e carteiras de hardware (. Isso pode funcionar, mas pode ser difícil de configurar e gerenciar para usuários sem experiência. Também existe o risco de perda ou roubo simultâneo dos dispositivos, especialmente quando estão localizados no mesmo lugar.
Recentemente, começamos a ver mais baseados em chave universal. A chave pode ser apenas salva no dispositivo do usuário, tornando-se uma solução de dispositivo pessoal, e também pode ser armazenada na nuvem, fazendo sua segurança depender de uma complexa mistura de segurança de senha, suposições institucionais e de hardware confiável. Na verdade, a chave é um ganho de segurança valioso para o usuário comum, mas somente com ela não é suficiente para proteger as economias de uma vida inteira do usuário.
Felizmente, com o ZK-SNARK, temos uma quarta opção: ID centralizado envolvido em ZK. Este tipo inclui zk-email, Anon Aadhaar, Myna Wallet, entre outros. Basicamente, os usuários podem adotar várias formas de ID centralizado de empresas ou governos ) e convertê-las em endereços Ethereum, os usuários só podem enviar transações gerando uma prova de posse do ID centralizado através do ZK-SNARK.
Com este suplemento, agora temos uma ampla escolha, e a ID centralizada empacotada em ZK possui uma "amigabilidade com iniciantes" única.
Para isso, é necessário implementar uma UI simplificada e integrada: os usuários devem ser capazes de especificar apenas que desejam "example@gmail.com" como guardião, e isso deve gerar automaticamente o endereço zk-email Ethereum correspondente sob o capô. Usuários avançados devem ser capazes de inserir seu e-mail ( e os possíveis valores de sal de privacidade armazenados nesse e-mail ) 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.
Por favor, note que um desafio prático que o zk-email enfrenta atualmente é a sua dependência da assinatura DKIM, que utiliza chaves que são rotacionadas a cada poucos meses, e essas chaves em si não são assinadas por nenhuma outra entidade. Isso significa que o zk-email de hoje tem um certo grau de requisitos de confiança que vão além do próprio provedor; se o zk-email usar o 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. Hoje, recomenda-se que um tutor use o zk-email, mas não se recomenda a maioria dos tutores: não armazene fundos no zk-email, pois isso significa que os usuários não podem acessar os fundos.
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. 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 ), e a 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, em algum momento, eles devem ser convidados a adicionar mais guardiões.
A integração da carteira em aplicativos é inevitável, pois os aplicativos que tentam atrair usuários não criptográficos não desejam que os usuários baixem dois novos aplicativos ao mesmo tempo, ( o próprio aplicativo, além da carteira Ethereum ), o que traz uma experiência de usuário confusa. No entanto, muitos usuários de carteiras de aplicativos deveriam ser capazes de conectar todas as suas carteiras, assim eles só precisam se preocupar com um "problema de controle de acesso". A maneira mais simples é adotar um esquema hierárquico, onde há um rápido processo de "linkagem" que permite ao usuário definir sua carteira principal como a guardiã de todas as carteiras dentro do aplicativo. Certos clientes já suportam isso.
Por padrão, a recuperação de algumas contas dentro da aplicação pode ser controlada pela equipe de desenvolvimento da aplicação. No entanto, o usuário pode "assumir" a conta do usuário e alterar a recuperação para o seu próprio endereço.
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 contra essas ameaças. 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 de o usuário estar enviando 100 dólares ou (.