Visão da Carteira Ideal: Uma atualização abrangente da experiência de cadeia cruzada à proteção de privacidade
Uma camada fundamental na pilha de infraestrutura do Ethereum é a Carteira, mas os principais pesquisadores e desenvolvedores de L1 tendem a subestimar a sua importância. A Carteira é a janela através da qual os usuários interagem com o mundo do Ethereum; os usuários só podem realmente se beneficiar das características de descentralização, resistência à censura, segurança e privacidade que o Ethereum e suas aplicações oferecem, se a Carteira em si possuir as propriedades correspondentes.
Recentemente, as carteiras Ethereum fizeram progressos significativos na melhoria da experiência do usuário, segurança e funcionalidade. 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 criptopunk, focando na segurança e privacidade, podendo carecer na experiência do usuário. No entanto, acredito que otimizar a experiência do usuário simplesmente implementando e iterando com base no feedback é mais eficaz do que uma lista de desejos, por isso considero que focar nas propriedades de segurança e privacidade é o mais valioso.
Experiência do usuário em transações de cadeia cruzada L2
Atualmente, já existe um roteiro de melhoria da experiência do usuário entre L2 que está cada vez mais aprimorado, incluindo partes de curto e longo prazo. Aqui, discutimos principalmente a parte de curto prazo: ideias que podem ser implementadas teoricamente agora.
A ideia principal é: (i) envio embutido cadeia cruzada L2, assim como (ii) endereço específico da cadeia e pedido de pagamento. A sua Carteira deve ser capaz de fornecer um endereço que siga o estilo do rascunho ERC.
Quando alguém ( ou alguns aplicativos ) lhe fornecerem um endereço neste formato, você deve ser capaz de colá-lo no campo "recipiente" da Carteira e, em seguida, clicar em "enviar". A Carteira deve processar automaticamente os dados enviados de qualquer maneira possível:
Se você já tiver a quantidade suficiente do tipo de token necessário na cadeia de destino, envie os tokens diretamente.
Se você tiver o tipo de token desejado em outra cadeia ( ou em várias outras cadeias ), usar protocolos como ERC-7683 ( é, na verdade, um DEX de cadeia cruzada ) para enviar tokens.
Se você tiver 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 enviá-los. 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 "Você copia e cola o endereço ( ou ENS, por exemplo, vitalik.eth @ optimism.eth ) para alguém fazer um pagamento a você". 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 para a cadeia. Então, sua Carteira será capaz de 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 seriamente 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 colocados em códigos QR, e a carteira móvel pode escanear o código QR. Em cenários de pagamento entre consumidores ( 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 ID de referência ou callback W", e a carteira poderá satisfazer esse pedido de qualquer maneira. 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 quantia de fundos de seu contrato na cadeia, e o trabalho do receptor é descobrir como transferir esses fundos para sua própria carteira.
Outro tema relacionado é o pagamento de gas. Se você receber ativos em um L2 que ainda não possui ETH, e precisar enviar uma transação nesse L2, a Carteira deve ser capaz de usar automaticamente o protocolo (, por exemplo, RIP-7755), para pagar o Gas na cadeia onde você tem ETH. Se a Carteira deseja que você faça mais transações no L2 no futuro, ela também deve usar apenas DEX para enviar, por exemplo, ETH no valor de milhões de Gas, para que as transações futuras possam gastar Gas diretamente lá, (, pois isso é mais barato ).
Segurança da conta
Uma maneira de conceituar os desafios de segurança da conta é que uma boa Carteira deve atuar em duas frentes: (i) proteger os usuários contra ataques maliciosos ou de hackers por parte dos desenvolvedores da Carteira, e (ii) proteger os usuários contra os efeitos de seus próprios erros.
A minha solução preferida para isto, durante mais de dez anos, tem sido a recuperação social e a Carteira multiassinada, com controlo de acesso em camadas. As contas dos utilizadores possuem duas camadas de chaves: uma 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 de executar 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, pode permitir que a chave principal execute operações de alto valor através de um bloqueio de tempo.
Acima está o design básico, que pode ser expandido. Mecanismos de permissã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 múltiplas durações de bloqueio de tempo sob diferentes limiares, podem ajudar a maximizar as chances de recuperação bem-sucedida de contas legítimas, ao mesmo tempo que minimizam o risco de roubo.
Quem ou o que deve ser o guardião?
Para os usuários experientes da comunidade de criptomoedas, uma opção viável é a chave de seus amigos e familiares. Se você pedir a todos para lhe fornecer um novo endereço, então ninguém precisa saber quem eles são - na verdade, seus guardiões nem precisam saber quem são uns aos outros. Se eles não se comunicarem com você, a probabilidade de eles 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 solicitadas por você: como um código de confirmação ou uma chamada de vídeo para usuários de alto valor. As pessoas têm tentado criar isso há muito tempo, como eu apresentei a CryptoCorp em 2013. No entanto, até agora, essas empresas ainda não têm sido muito bem-sucedidas.
A terceira opção é ter vários dispositivos pessoais (, como telefones, desktops e Carteiras ). Isso pode funcionar, mas pode ser difícil de configurar e gerenciar para usuários sem experiência. Também há o risco de perder ou ter os dispositivos roubados ao mesmo tempo, especialmente quando estão localizados no mesmo lugar.
Recentemente, começamos a ver mais baseados em chave universal. A chave pode ser apenas copiada no seu dispositivo, tornando-se uma solução de dispositivo pessoal, e também pode ser copiada na nuvem, fazendo com que sua segurança dependa de uma complexa mistura de segurança de senha, suposições institucionais e hardware confiável. Na verdade, a chave é um ganho de segurança valioso para o usuário comum, mas apenas contar com elas 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 centralizada empacotada em ZK. Este tipo inclui zk-email, Anon Aadhaar, Myna Wallet, entre outros. Basicamente, você pode adotar várias formas de ID centralizada de empresas ou governos ( e convertê-las em um endereço Ethereum, e você só pode enviar transações gerando uma prova de posse do ID centralizado através do ZK-SNARK.
Com este complemento, agora temos uma ampla gama de opções, e a ID centralizada embrulhada em ZK possui uma "amigabilidade para iniciantes" única.
![Novo artigo do Vitalik: 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(
Para isso, precisa ser alcançado através de uma UI simplificada e integrada: você deve ser capaz de especificar apenas que deseja "example@gmail.com" como guardião, e ele 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 possivelmente o valor de privacidade salgado ( que pode estar armazenado nesse e-mail em aplicações de terceiros de código aberto, e confirmar que o endereço gerado está correto. Isso também deve ser verdade para qualquer outro tipo de guardião suportado.
Por favor, note que hoje o zk-email enfrenta um desafio real, que é a sua dependência da assinatura DKIM, cuja chave é rotacionada a cada poucos meses, e essas chaves não são assinadas por nenhuma outra entidade. Isso significa que o zk-email de hoje tem um certo grau de exigência de confiança que vai 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, eu recomendo a um guardião usar o zk-email, mas não recomendo a maioria dos guardiões: não armazene fundos no zk-email, pois uma falha significa que você não pode usar os fundos.
![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-2439f49163d0212333ea4207f34cdbef.webp(
Novos usuários e Carteira dentro da aplicação
Os novos usuários na verdade não desejam inserir uma quantidade grande de guardiões na primeira inscrição. 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, e a chave armazenada localmente no dispositivo do usuário ) pode ser a chave universal (, juntamente com 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 deve-se sugerir que adicionem mais guardiões.
A integração da Carteira na aplicação é inevitável, pois as aplicações que tentam atrair utilizadores não cripto não desejam que os utilizadores tenham que descarregar duas novas aplicações ao mesmo tempo: a aplicação em si, mais a Carteira Ethereum, o que traz uma experiência de utilizador confusa. No entanto, muitos utilizadores de carteiras de aplicações devem ser capazes de ligar todas as suas carteiras, de modo que só tenham que se preocupar com um "problema de controlo de acesso". A forma mais simples é adotar um esquema hierárquico, onde há um rápido processo de "ligação" que permite aos utilizadores definir a sua carteira principal como a guardiã de todas as carteiras dentro da aplicação.
![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(
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, esforçando-se para proteger os usuários contra essas ameaças. Ao mesmo tempo, muitas das medidas ainda são bastante primitivas: por exemplo, a exigência de um clique para enviar ETH ou outros tokens para qualquer novo endereço, independentemente de você estar enviando 100 dólares ou 100.000 dólares. Aqui, não existe uma solução única e mágica. Trata-se de uma série de correções e melhorias lentas e contínuas, voltadas para diferentes categorias de ameaças. No entanto, continuar a trabalhar para melhorar aqui tem muito valor.
![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-ab5913a80a4549d9fec805c19442956b.webp(
Privacidade
Agora é hora de começar a levar o Ethereum mais a sério.
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.
10 Curtidas
Recompensa
10
8
Repostar
Compartilhar
Comentário
0/400
HalfIsEmpty
· 07-20 04:01
A primeira vez que vejo alguém falar sobre a importância da carteira.
Ver originalResponder0
Layer2Arbitrageur
· 07-19 12:59
lmao imagina chamar-lhe "privacidade" quando os teus dados de tx ainda vazam como uma peneira
Ver originalResponder0
BearMarketMonk
· 07-18 17:20
Cada Carteira está a falar de segurança. Aprender a gerir bem a Chave privada é que é realmente seguro.
Ver originalResponder0
LightningClicker
· 07-17 18:50
A carteira dispersa é tão insegura, não é?
Ver originalResponder0
MysteriousZhang
· 07-17 18:47
cadeia cruzada segurança yyds
Ver originalResponder0
DataPickledFish
· 07-17 18:43
Carteira, salve os daltónicos!
Ver originalResponder0
DefiPlaybook
· 07-17 18:38
Para ser sincero, a segurança dessas carteiras não está a um nível adequado agora. Tenham cuidado ao entrar numa posição.
Visão ideal da Carteira: atualização abrangente da cadeia cruzada, segurança e privacidade
Visão da Carteira Ideal: Uma atualização abrangente da experiência de cadeia cruzada à proteção de privacidade
Uma camada fundamental na pilha de infraestrutura do Ethereum é a Carteira, mas os principais pesquisadores e desenvolvedores de L1 tendem a subestimar a sua importância. A Carteira é a janela através da qual os usuários interagem com o mundo do Ethereum; os usuários só podem realmente se beneficiar das características de descentralização, resistência à censura, segurança e privacidade que o Ethereum e suas aplicações oferecem, se a Carteira em si possuir as propriedades correspondentes.
Recentemente, as carteiras Ethereum fizeram progressos significativos na melhoria da experiência do usuário, segurança e funcionalidade. 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 criptopunk, focando na segurança e privacidade, podendo carecer na experiência do usuário. No entanto, acredito que otimizar a experiência do usuário simplesmente implementando e iterando com base no feedback é mais eficaz do que uma lista de desejos, por isso considero que focar nas propriedades de segurança e privacidade é o mais valioso.
Experiência do usuário em transações de cadeia cruzada L2
Atualmente, já existe um roteiro de melhoria da experiência do usuário entre L2 que está cada vez mais aprimorado, incluindo partes de curto e longo prazo. Aqui, discutimos principalmente a parte de curto prazo: ideias que podem ser implementadas teoricamente agora.
A ideia principal é: (i) envio embutido cadeia cruzada L2, assim como (ii) endereço específico da cadeia e pedido de pagamento. A sua Carteira deve ser capaz de fornecer um endereço que siga o estilo do rascunho ERC.
Quando alguém ( ou alguns aplicativos ) lhe fornecerem um endereço neste formato, você deve ser capaz de colá-lo no campo "recipiente" 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 "Você copia e cola o endereço ( ou ENS, por exemplo, vitalik.eth @ optimism.eth ) para alguém fazer um pagamento a você". 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 para a cadeia. Então, sua Carteira será capaz de 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 seriamente 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 colocados em códigos QR, e a carteira móvel pode escanear o código QR. Em cenários de pagamento entre consumidores ( 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 ID de referência ou callback W", e a carteira poderá satisfazer esse pedido de qualquer maneira. 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 quantia de fundos de seu contrato na cadeia, e o trabalho do receptor é descobrir como transferir esses fundos para sua própria carteira.
Outro tema relacionado é o pagamento de gas. Se você receber ativos em um L2 que ainda não possui ETH, e precisar enviar uma transação nesse L2, a Carteira deve ser capaz de usar automaticamente o protocolo (, por exemplo, RIP-7755), para pagar o Gas na cadeia onde você tem ETH. Se a Carteira deseja que você faça mais transações no L2 no futuro, ela também deve usar apenas DEX para enviar, por exemplo, ETH no valor de milhões de Gas, para que as transações futuras possam gastar Gas diretamente lá, (, pois isso é mais barato ).
Segurança da conta
Uma maneira de conceituar os desafios de segurança da conta é que uma boa Carteira deve atuar em duas frentes: (i) proteger os usuários contra ataques maliciosos ou de hackers por parte dos desenvolvedores da Carteira, e (ii) proteger os usuários contra os efeitos de seus próprios erros.
A minha solução preferida para isto, durante mais de dez anos, tem sido a recuperação social e a Carteira multiassinada, com controlo de acesso em camadas. As contas dos utilizadores possuem duas camadas de chaves: uma 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 de executar 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, pode permitir que a chave principal execute operações de alto valor através de um bloqueio de tempo.
Acima está o design básico, que pode ser expandido. Mecanismos de permissã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 múltiplas durações de bloqueio de tempo sob diferentes limiares, podem ajudar a maximizar as chances de recuperação bem-sucedida de contas legítimas, ao mesmo tempo que minimizam o risco de roubo.
Quem ou o que deve ser o guardião?
Para os usuários experientes da comunidade de criptomoedas, uma opção viável é a chave de seus amigos e familiares. Se você pedir a todos para lhe fornecer um novo endereço, então ninguém precisa saber quem eles são - na verdade, seus guardiões nem precisam saber quem são uns aos outros. Se eles não se comunicarem com você, a probabilidade de eles 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 solicitadas por você: como um código de confirmação ou uma chamada de vídeo para usuários de alto valor. As pessoas têm tentado criar isso há muito tempo, como eu apresentei a CryptoCorp em 2013. No entanto, até agora, essas empresas ainda não têm sido muito bem-sucedidas.
A terceira opção é ter vários dispositivos pessoais (, como telefones, desktops e Carteiras ). Isso pode funcionar, mas pode ser difícil de configurar e gerenciar para usuários sem experiência. Também há o risco de perder ou ter os dispositivos roubados ao mesmo tempo, especialmente quando estão localizados no mesmo lugar.
Recentemente, começamos a ver mais baseados em chave universal. A chave pode ser apenas copiada no seu dispositivo, tornando-se uma solução de dispositivo pessoal, e também pode ser copiada na nuvem, fazendo com que sua segurança dependa de uma complexa mistura de segurança de senha, suposições institucionais e hardware confiável. Na verdade, a chave é um ganho de segurança valioso para o usuário comum, mas apenas contar com elas 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 centralizada empacotada em ZK. Este tipo inclui zk-email, Anon Aadhaar, Myna Wallet, entre outros. Basicamente, você pode adotar várias formas de ID centralizada de empresas ou governos ( e convertê-las em um endereço Ethereum, e você só pode enviar transações gerando uma prova de posse do ID centralizado através do ZK-SNARK.
Com este complemento, agora temos uma ampla gama de opções, e a ID centralizada embrulhada em ZK possui uma "amigabilidade para iniciantes" única.
![Novo artigo do Vitalik: 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(
Para isso, precisa ser alcançado através de uma UI simplificada e integrada: você deve ser capaz de especificar apenas que deseja "example@gmail.com" como guardião, e ele 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 possivelmente o valor de privacidade salgado ( que pode estar armazenado nesse e-mail em aplicações de terceiros de código aberto, e confirmar que o endereço gerado está correto. Isso também deve ser verdade para qualquer outro tipo de guardião suportado.
Por favor, note que hoje o zk-email enfrenta um desafio real, que é a sua dependência da assinatura DKIM, cuja chave é rotacionada a cada poucos meses, e essas chaves não são assinadas por nenhuma outra entidade. Isso significa que o zk-email de hoje tem um certo grau de exigência de confiança que vai 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, eu recomendo a um guardião usar o zk-email, mas não recomendo a maioria dos guardiões: não armazene fundos no zk-email, pois uma falha significa que você não pode usar os fundos.
![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-2439f49163d0212333ea4207f34cdbef.webp(
Novos usuários e Carteira dentro da aplicação
Os novos usuários na verdade não desejam inserir uma quantidade grande de guardiões na primeira inscrição. 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, e a chave armazenada localmente no dispositivo do usuário ) pode ser a chave universal (, juntamente com 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 deve-se sugerir que adicionem mais guardiões.
A integração da Carteira na aplicação é inevitável, pois as aplicações que tentam atrair utilizadores não cripto não desejam que os utilizadores tenham que descarregar duas novas aplicações ao mesmo tempo: a aplicação em si, mais a Carteira Ethereum, o que traz uma experiência de utilizador confusa. No entanto, muitos utilizadores de carteiras de aplicações devem ser capazes de ligar todas as suas carteiras, de modo que só tenham que se preocupar com um "problema de controlo de acesso". A forma mais simples é adotar um esquema hierárquico, onde há um rápido processo de "ligação" que permite aos utilizadores definir a sua carteira principal como a guardiã de todas as carteiras dentro da aplicação.
![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(
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, esforçando-se para proteger os usuários contra essas ameaças. Ao mesmo tempo, muitas das medidas ainda são bastante primitivas: por exemplo, a exigência de um clique para enviar ETH ou outros tokens para qualquer novo endereço, independentemente de você estar enviando 100 dólares ou 100.000 dólares. Aqui, não existe uma solução única e mágica. Trata-se de uma série de correções e melhorias lentas e contínuas, voltadas para diferentes categorias de ameaças. No entanto, continuar a trabalhar para melhorar aqui tem muito valor.
![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-ab5913a80a4549d9fec805c19442956b.webp(
Privacidade
Agora é hora de começar a levar o Ethereum mais a sério.