Agora existe uma roadmap cada vez mais detalhada para melhorar a experiência do usuário entre L2, que possui uma parte de curto prazo e uma parte de longo prazo. Aqui, vou falar sobre a parte de curto prazo: ideias que teoricamente podem ser implementadas ainda hoje.
As ideias centrais são (i) envios L2 cruzados integrados e (ii) endereços e pedidos de pagamento específicos da cadeia. Sua carteira deve ser capaz de lhe dar um endereço que (seguindo o estilo de este rascunho ERC) parece com isto:
0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth
Quando alguém (ou alguma aplicação) lhe der um endereço neste formato, deve ser capaz de o colar no campo "para" de uma carteira e clicar em "enviar". A carteira deve processar automaticamente esse envio da melhor forma que puder:
Mockup de possível interface de carteira com suporte a endereço cross-chain
O acima é para o “you copy-paste an address (or ENS, eg. vitalik.eth@optimism.eth) para alguém lhe pagar" caso de uso. Se um dapp está solicitando um depósito (por exemplo, ver este exemplo do Polymarket) então o fluxo ideal é estender a API web3 e permitir que o dapp faça um pedido de pagamento específico da cadeia. Sua carteira então seria capaz de satisfazer esse pedido da maneira que precisa. Fazer com que a experiência do usuário funcione bem também exigiria padronizar um pedido de getAvailableBalance, e as carteiras precisariam pensar cuidadosamente em quais cadeias armazenam os ativos dos usuários por padrão para maximizar a segurança e facilidade de transferências.
Os pedidos de pagamento específicos da cadeia também podem ser colocados em códigos QR, que as carteiras móveis podem digitalizar. Em um cenário de pagamentos ao consumidor pessoalmente (ou online), o destinatário faria uma chamada de API QR code ou web3 que diz 'Eu quero X unidades do token Y na cadeia Z, com ID de referência ou retorno de chamada W', e a carteira estaria livre para atender a esse pedido da maneira que puder. Outra opção é um protocolo de link de reivindicação, onde a carteira do usuário gera um código QR ou URL que contém uma autorização para reivindicar uma determinada quantidade de fundos de seu contrato na cadeia, e é trabalho do destinatário descobrir como mover esses fundos para sua própria carteira.
Outro tópico relacionado são os pagamentos de gás. Se você receber ativos em um L2 onde ainda não tem ETH e precisar enviar uma transação nesse L2, uma carteira deve ser capaz de usar automaticamente um protocolo (por ex. RIP-7755) para pagar o gás em uma cadeia onde você tem ETH. Se a carteira espera que você faça mais transações naquele L2 no futuro, ela também deve usar um DEX para enviar, por exemplo, alguns milhões de gás em ETH, para que as transações futuras possam gastar gás diretamente lá (já que isso é mais barato).
Uma forma como eu conceptualizo o desafio da segurança da conta é que uma boa carteira deve ser simultaneamente boa em duas áreas: (i) proteger o usuário de o desenvolvedor da carteira ser hackeado ou malicioso e (ii) proteger o usuário de seus próprios erros.
O erro de digitação "mistakles" à esquerda foi involuntário. No entanto, ao vê-lo, percebi que é perfeitamente adequado para o contexto, então decidi mantê-lo.
Minha solução preferida para isso é, parasobredezanosfoi a recuperação social e carteiras multisig, com controle de acesso graduado. A conta do usuário tem duas camadas de chaves: uma chave primária e N guardiões (por exemplo, N = 5). A chave primária é capaz de realizar operações de baixo valor e não financeiras. A maioria dos guardiões é necessária para realizar qualquer uma das seguintes operações: (i) operações de alto valor, como enviar o valor total da conta, ou (ii) alterar a chave primária ou qualquer um dos guardiões. Se desejar, a chave primária pode ser autorizada a realizar operações de alto valor com uma trava de tempo.
O acima é um design básico e pode ser aumentado. Chaves de sessão e mecanismos de permissão como ERC-7715pode ajudar a apoiar diferentes equilíbrios entre conveniência e segurança para diferentes aplicações. Arquiteturas de guardião mais complicadas, como ter várias durações de bloqueio temporal em diferentes limiares, podem ajudar a maximizar a chance de recuperação bem-sucedida de contas legítimas, minimizando o risco de roubo.
Para um usuário experiente de criptomoeda que está dentro de uma comunidade de usuários experientes de criptomoeda, uma opção viável são as chaves dos seus amigos e familiares. Se você pedir para cada um fornecer um endereço novo, então ninguém precisa saber quem são eles - na verdade, seus guardiões nem precisam saber quem são uns dos outros. A chance deles conspirarem sem um deles lhe dar um aviso é muito pequena. No entanto, para a maioria dos novos usuários, essa opção não está disponível.
Uma segunda opção são guardiões institucionais: empresas que se especializam em realizar o serviço de apenas assinar uma transação se receberem alguma outra confirmação de que um pedido está vindo de você: por exemplo, um código de confirmação, ou para usuários de alto valor um chamada de vídeo. As pessoas têm tentado fazer isso por muito tempo, por exemplo, Eu perfilava a CryptoCorp em 2013. No entanto, até agora essas empresas não têm sido muito bem-sucedidas.
Uma terceira opção é ter vários dispositivos pessoais (por exemplo, telefone, desktop, carteira de hardware). Isso pode funcionar, mas também é difícil de configurar e gerenciar para usuários inexperientes. Existe também o risco de os dispositivos serem perdidos ou roubados ao mesmo tempo, especialmente se estiverem no mesmo local.
Recentemente, começamos a ver mais carteiras baseadas em passkeys. As passkeys podem ser armazenadas apenas em seus dispositivos, tornando-as uma solução de dispositivo pessoal, ou armazenadas na nuvem, tornando sua segurança dependente de uma complicado híbridode segurança de senha, pressupostos de hardware institucional e confiável. Realisticamente, as chaves de acesso são um ganho de segurança valioso para os usuários comuns, mas por si só não são suficientemente fortes para proteger as economias de uma vida de um usuário.
Felizmente, com ZK-SNARKs, temos uma quarta opção: ID centralizado envolto em ZK. Este género inclui zk-email, Anon Aadhaar, Carteira Myna, e muitos outros. Basicamente, você pode transformar muitas formas de identificação centralizada (corporativa ou governamental) e transformá-la em um endereço Ethereum, do qual só pode enviar transações gerando uma prova ZK-SNARK de posse da identificação centralizada.
Com esta adição, agora temos uma ampla gama de opções, e o ID centralizado ZK-wrapped é exclusivamente "amigável para novatos".
Para que isto funcione, precisa de ser implementado com uma interface de utilizador simplificada e integrada: deverá ser capaz de especificar apenas que quer “example@gmail.com” como guardião e deve gerar automaticamente o endereço Ethereum zk-email correspondente por baixo. Utilizadores avançados devem ser capazes de introduzir o seu email (juntamente com talvez um valor de salt para privacidade, que seria guardado nesse email) numa aplicação de terceiros de código aberto, e confirmar que o endereço gerado está correto. O mesmo deve ser verdade para qualquer outro tipo de guardião suportado.
Mockup da possível interface Safe
Note que hoje, um desafio prático com o zk-email especificamente é que depende deassinaturas DKIM, que usam chaves que são alteradas a cada poucos meses, e essas chaves não são assinadas por nenhuma outra autoridade. Isso significa que o zk-email hoje possui algum nível de requisito de confiança além do próprio provedor; isso poderia ser reduzido se o zk-email usasse TLSNotarydentro de hardware confiável para verificar chaves atualizadas, mas não é ideal. Esperançosamente, os provedores de e-mail começarão a assinar diretamente suas chaves DKIM. Hoje, eu recomendaria usar e-mail zk para um guardião, mas não para a maioria dos seus guardiões: não armazene fundos em um ambiente onde a quebra do e-mail zk significa que você perde o acesso aos seus fundos.
Novos utilizadores realisticamente não vão querer ter de inserir um grande número de guardiões na sua primeira experiência de registo. Por isso, as carteiras devem oferecer-lhes uma opção muito simples. Uma rota natural é um 2-de-3 usando zk-email no seu endereço de email, uma chave armazenada localmente no dispositivo do utilizador (que poderia ser uma chave de acesso), e uma chave de backup mantida pelo fornecedor. À medida que um utilizador ganha mais experiência ou acumula mais ativos, em algum momento deve ser solicitado que adicione mais guardiões.
As carteiras integradas em aplicações são inevitáveis, porque as aplicações que tentam atrair utilizadores não criptográficos não querem a experiência de utilizador confusa de pedir aos seus utilizadores para descarregarem duas novas aplicações (a própria aplicação, mais uma carteira Ethereum) ao mesmo tempo. No entanto, um utilizador de muitas carteiras de aplicações deve ser capaz de ligar todas as suas carteiras juntas, para que só tenham uma "coisa de controlo de acesso" com que se preocupar. A maneira mais simples de fazer isso é um esquema hierárquico, onde existe um processo de "ligação" rápido que permite a um utilizador definir a sua carteira principal como guardiã de todas as suas carteiras de aplicações. O cliente Farcaster Warpcast já suporta isto:
Por predefinição, a recuperação da sua conta Warpcast é controlada pela equipa Warpcast. No entanto, pode 'tomar a soberania' da sua conta Farcaster e alterar a recuperação para o seu próprio endereço.
Além da segurança da conta, as carteiras hoje fazem muito para identificar endereços falsos, phishing, golpes e outras ameaças externas, e tentam proteger seus usuários dessas ameaças. Ao mesmo tempo, muitos dos contra-ataques ainda são bastante primitivos: por exemplo, exigindo um clique para enviar ETH ou outros tokens para qualquer novo endereço, independentemente de você estar enviando $100 ou $100.000. Aqui, não há uma solução mágica única; é uma série de correções lentas e melhorias contínuas em diferentes categorias de ameaças. No entanto, há muito valor em continuar trabalhando duro para melhorar aqui.
Agora é a hora de começar a levar a privacidade no Ethereum muito mais a sério. A tecnologia ZK-SNARK está agora muito avançada, tecnologias de privacidade que mitigam riscos regulatórios sem depender de portas dos fundos, como Piscinas de Privacidade, estão cada vez mais maduros, e infraestruturas secundárias como Wakue as mempools ERC-4337 estão lentamente se tornando mais estáveis. No entanto, até agora, fazer transferências privadas no Ethereum exigia que os usuários fizessem o download e usassem explicitamente uma "carteira de privacidade", como Ferrovia (ou Umbraparaendereços ocultos). Isso adiciona grande inconveniência e reduz o número de pessoas que estão dispostas a fazer transferências privadas. A solução é que as transferências privadas precisam ser integradas diretamente nas carteiras.
Uma implementação simples é a seguinte. Uma carteira poderia armazenar uma parte dos ativos do usuário como um “saldo privado” numa pool de privacidade. Quando um usuário faz uma transferência, a carteira retiraria automaticamente da pool de privacidade primeiro. Se um usuário precisa receber fundos, a carteira poderia gerar automaticamente um endereço oculto.
Além disso, uma carteira poderia gerar automaticamente um novo endereço para cada aplicação em que um usuário participa (por exemplo, um protocolo defi). Os depósitos viriam do pool de privacidade e as retiradas iriam diretamente para o pool de privacidade. Isso permite que a atividade de um usuário em qualquer aplicação seja desvinculada de sua atividade em outras aplicações.
Uma vantagem desta técnica é que ela é um caminho natural não apenas para transferência de ativos que preservam a privacidade, mas também para identidade que preserva a privacidade. A identidade já ocorre na cadeia: qualquer aplicativo que utiliza o bloqueio de prova de pessoa (por exemplo, Gitcoin Grants), qualquer chat bloqueado por token, o Protocolo de Seguimento Ethereum, e muito mais são todas identidades onchain. Queremos que esse ecossistema também seja preservador de privacidade. Isso significa que a atividade de um usuário onchain não deve ser coletada em um só lugar: cada item deve ser armazenado separadamente, e a carteira do usuário deve ser a única coisa com uma "visão global" que vê todas as suas comprovações ao mesmo tempo. Um ecossistema nativamente com muitas contas por usuário ajuda a alcançar isso, assim como os protocolos de comprovação offchain, como EASeZupass.
Esta representa uma visão pragmática para a privacidade do Ethereum no futuro de médio prazo. Pode ser implementada hoje, embora existam recursos que possam ser introduzidos em L1 e L2 para tornar as transferências preservadoras de privacidade mais eficientes e confiáveis. Alguns defensores da privacidade argumentam que a única coisa aceitável é a total privacidade de tudo: criptografando toda a EVM. Eu argumentaria que isso pode ser ideal como um resultado de longo prazo, mas requer uma reflexão muito mais fundamental dos modelos de programação, e atualmente não está no nível de maturidade em que está pronto para ser implantado em toda a plataforma Ethereum. Precisamos de privacidade-por-padrão para obter conjuntos de anonimato suficientemente grandes. No entanto, concentrar-se primeiro em tornar (i) as transferências entre contas e (ii) casos de uso de identidade e identidade-adjacentes, como atestações, privados, é um primeiro passo pragmático que é muito mais fácil de implementar e em que as carteiras podem começar hoje em dia.
Uma consequência de qualquer solução de privacidade eficaz, seja para pagamentos, identidade ou outros casos de uso, é que ela cria uma necessidade para o usuário armazenar dados offchain. Isso era óbvio no Tornado Cash, que exigia que os usuários salvassem cada "nota" individual representando um depósito de 0,1-100 ETH. Protocolos de privacidade mais modernos às vezes salvam os dados criptografados onchain e usam uma única chave privada para descriptografá-los. Isso é arriscado, porque se a chave for vazada, ou se os computadores quânticos se tornarem viáveis, todos os dados se tornam públicos. Atestados offchain como EAS e Zupass têm uma necessidade ainda mais óbvia de armazenamento de dados offchain.
As carteiras precisam não apenas se tornar software para armazenar permissões de acesso onchain, mas também software para armazenar seus dados privados. Isso é algo que o mundo não cripto está reconhecendo cada vez mais, por exemplo, veja Tim Berners-Lee’s trabalho recente em armazenamento de dados pessoais. Todos os problemas que precisamos resolver em torno da garantia robusta do controle de permissões de acesso, também precisamos resolver em torno da garantia robusta da acessibilidade e não vazamento de dados. Talvez as soluções possam ser sobrepostas: se você tiver N guardiões, use compartilhamento de segredos M-de-N entre esses mesmos N guardiões para armazenar seus dados. Os dados são inerentemente mais difíceis de proteger, porque não pode revogar a parte de alguém, mas deveríamos criar soluções de custódia descentralizadas que sejam o mais seguras possível.
Atualmente, as carteiras confiam nos seus fornecedores RPC para lhes transmitir qualquer informação sobre uma cadeia. Isso representa uma vulnerabilidade em dois aspectos:
Idealmente, queremos tapar ambos estes buracos. Para tapar o primeiro, precisamos de clientes leves padronizados para L1 e L2s, que verifiquem diretamente o consenso da blockchain.Heliosjá o faz para L1 e tem feito algum trabalho preliminar para suportar alguns L2s específicos. Para cobrir adequadamente todos os L2s, o que precisamos é de um padrão pelo qual um contrato de configuração representando um L2 (também usado para endereços específicos da cadeia) possa declarar uma função, talvez de maneira semelhante a,ERC-3668, contendo a lógica para obter raízes de estado recentes e verificar provas de estado e recibos em relação a essas raízes de estado. Dessa forma, poderíamos ter um cliente leve universal, permitindo que as carteiras verifiquem com segurança qualquer estado ou eventos na L1 e L2.
Para privacidade, hoje a única abordagem realista é executar seu próprio nó completo. No entanto, agora que L2s estão entrando em cena, executar um nó completo de tudo está se tornando cada vez mais difícil. O equivalente a um cliente leve aqui é recuperação de informação privada (PIR). PIR envolve um servidor que possui uma cópia de todos os dados e um cliente que envia ao servidor uma solicitação criptografada. O servidor realiza um cálculo sobre todos os dados, o que retorna os dados desejados do cliente, criptografados para a chave do cliente, sem revelar ao servidor qual parte dos dados o cliente acessou.
Para manter o servidor honesto, os itens individuais do banco de dados seriam eles próprios ramos de Merkle, para que o cliente possa verificá-los usando seu cliente leve.
PIR é muito computacionalmente caro. Existem várias maneiras de contornar esse problema:
Encontrar a combinação certa de técnicas para maximizar a privacidade ao mesmo tempo que se mantém a praticidade no contexto do Ethereum é um problema de pesquisa aberto, e eu saúdo os criptógrafos que tentam resolvê-lo.
Além de transferências e acesso ao estado, outro fluxo de trabalho importante que precisa funcionar sem problemas em um contexto cruzado de L2 é alterar a configuração de validação de uma conta: seja alterando suas chaves (por exemplo, recuperação), ou uma mudança mais profunda em toda a lógica da conta. Aqui, existem três camadas de soluções, em ordem crescente de dificuldade:
A solução (3) é particularmente poderosa porque combina bem com a privacidade. Em uma "solução de privacidade" normal, um usuário tem um segredo s , um "valor folha" L é publicado em cadeia, e um usuário prova que L = hash(s, 1) e N = hash(s, 2) para algum segredo (nunca revelado) que eles controlam. O anulador N é publicado, certificando-se de que gastos futuros da mesma folha falham, sem nunca revelar L. Isso depende de o usuário se manter seguro. Em vez disso, uma solução de privacidade amigável para recuperação diria: s é um local (por exemplo, endereço e slot de armazenamento) onchain, e o usuário deve provar uma consulta de estado: L = hash(sload(s), 1) .
O elo mais fraco na segurança de um usuário é frequentemente o dapp. Na maioria das vezes, um usuário interage com uma aplicação indo para um site, que implicitamente faz o download do código da interface do usuário em tempo real a partir de um servidor e depois o executa no navegador. Se o servidor for hackeado, ou se o DNS for hackeado, o usuário receberá uma cópia falsa da interface, que poderia enganar o usuário a fazer coisas arbitrárias. Recursos da carteira como simulações de transações são muito úteis para mitigar os riscos, mas estão longe de serem perfeitos.
Idealmente, moveríamos o ecossistema para a versão de conteúdo on-chain: o usuário acessaria um dapp através do seu nome ENS, que conteria o hash IPFS da interface. Seria necessária uma transação on-chain de um multisig ou DAO para atualizar a interface. As carteiras mostrariam aos usuários se estão interagindo com uma interface on-chain mais segura ou uma interface web2 menos segura. As carteiras também podem mostrar aos usuários se estão interagindo com uma chain segura (por exemplo, estágio 1+, várias auditorias de segurança).
Para usuários preocupados com a privacidade, as carteiras também podem adicionar um modo paranoico, que exige que os usuários cliquem para aceitar solicitações HTTP, e não apenas operações web3:
Mockup de possível interface para o modo paranóico
Uma abordagem mais avançada seria ir além do HTML + Javascript e escrever a lógica de negócios dos dapps numa linguagem dedicada, talvez uma sobreposição relativamente fina sobre Solidity ou Vyper. Os navegadores poderiam então gerar automaticamente uma interface do usuário para qualquer funcionalidade necessária.OKContractjá está a fazer isso.
Outra direção é a info-defesa cripto-econômica: os desenvolvedores de dapp, empresas de segurança, implementadores de blockchain e outros podem constituir uma garantia que seria paga aos usuários afetados se um dapp fosse hackeado ou prejudicasse os usuários de alguma forma altamente enganosa, conforme determinado por algum DAO de adjudicação onchain. A carteira poderia mostrar ao usuário uma pontuação baseada no valor da garantia.
Tudo acima foi no contexto de interfaces convencionais, que envolvem apontar e clicar em coisas e inserir coisas em campos de texto. No entanto, também estamos à beira de paradigmas que mudam muito mais profundamente:
Estas três tendências em conjunto levarão a uma reformulação muito mais profunda da forma como as interfaces funcionam. Através da entrada de linguagem natural, rastreamento ocular ou, eventualmente, BCI mais direto, juntamente com o conhecimento do seu histórico (talvez incluindo mensagens de texto, desde que todos os dados sejam processados localmente), uma "carteira" pode ter uma ideia intuitiva clara do que você quer fazer. Isso poderia reduzir consideravelmente a necessidade de interfaces de usuário de terceiros. Se um usuário interagir com um aplicativo de terceiros (ou outro usuário), a IA deve pensar negativamente em nome do usuário e identificar quaisquer ameaças e sugerir planos de ação para evitá-las. Idealmente, haveria um ecossistema aberto dessas IAs, produzido por diferentes grupos com diferentes vieses e estruturas de incentivo.
Essas ideias mais radicais dependem de tecnologia extremamente imatura hoje, portanto, não colocaria meus ativos hoje em uma carteira que depende delas. No entanto, algo assim parece ser claramente o futuro, então vale a pena começar a explorar mais ativamente nessa direção.
Agora existe uma roadmap cada vez mais detalhada para melhorar a experiência do usuário entre L2, que possui uma parte de curto prazo e uma parte de longo prazo. Aqui, vou falar sobre a parte de curto prazo: ideias que teoricamente podem ser implementadas ainda hoje.
As ideias centrais são (i) envios L2 cruzados integrados e (ii) endereços e pedidos de pagamento específicos da cadeia. Sua carteira deve ser capaz de lhe dar um endereço que (seguindo o estilo de este rascunho ERC) parece com isto:
0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth
Quando alguém (ou alguma aplicação) lhe der um endereço neste formato, deve ser capaz de o colar no campo "para" de uma carteira e clicar em "enviar". A carteira deve processar automaticamente esse envio da melhor forma que puder:
Mockup de possível interface de carteira com suporte a endereço cross-chain
O acima é para o “you copy-paste an address (or ENS, eg. vitalik.eth@optimism.eth) para alguém lhe pagar" caso de uso. Se um dapp está solicitando um depósito (por exemplo, ver este exemplo do Polymarket) então o fluxo ideal é estender a API web3 e permitir que o dapp faça um pedido de pagamento específico da cadeia. Sua carteira então seria capaz de satisfazer esse pedido da maneira que precisa. Fazer com que a experiência do usuário funcione bem também exigiria padronizar um pedido de getAvailableBalance, e as carteiras precisariam pensar cuidadosamente em quais cadeias armazenam os ativos dos usuários por padrão para maximizar a segurança e facilidade de transferências.
Os pedidos de pagamento específicos da cadeia também podem ser colocados em códigos QR, que as carteiras móveis podem digitalizar. Em um cenário de pagamentos ao consumidor pessoalmente (ou online), o destinatário faria uma chamada de API QR code ou web3 que diz 'Eu quero X unidades do token Y na cadeia Z, com ID de referência ou retorno de chamada W', e a carteira estaria livre para atender a esse pedido da maneira que puder. Outra opção é um protocolo de link de reivindicação, onde a carteira do usuário gera um código QR ou URL que contém uma autorização para reivindicar uma determinada quantidade de fundos de seu contrato na cadeia, e é trabalho do destinatário descobrir como mover esses fundos para sua própria carteira.
Outro tópico relacionado são os pagamentos de gás. Se você receber ativos em um L2 onde ainda não tem ETH e precisar enviar uma transação nesse L2, uma carteira deve ser capaz de usar automaticamente um protocolo (por ex. RIP-7755) para pagar o gás em uma cadeia onde você tem ETH. Se a carteira espera que você faça mais transações naquele L2 no futuro, ela também deve usar um DEX para enviar, por exemplo, alguns milhões de gás em ETH, para que as transações futuras possam gastar gás diretamente lá (já que isso é mais barato).
Uma forma como eu conceptualizo o desafio da segurança da conta é que uma boa carteira deve ser simultaneamente boa em duas áreas: (i) proteger o usuário de o desenvolvedor da carteira ser hackeado ou malicioso e (ii) proteger o usuário de seus próprios erros.
O erro de digitação "mistakles" à esquerda foi involuntário. No entanto, ao vê-lo, percebi que é perfeitamente adequado para o contexto, então decidi mantê-lo.
Minha solução preferida para isso é, parasobredezanosfoi a recuperação social e carteiras multisig, com controle de acesso graduado. A conta do usuário tem duas camadas de chaves: uma chave primária e N guardiões (por exemplo, N = 5). A chave primária é capaz de realizar operações de baixo valor e não financeiras. A maioria dos guardiões é necessária para realizar qualquer uma das seguintes operações: (i) operações de alto valor, como enviar o valor total da conta, ou (ii) alterar a chave primária ou qualquer um dos guardiões. Se desejar, a chave primária pode ser autorizada a realizar operações de alto valor com uma trava de tempo.
O acima é um design básico e pode ser aumentado. Chaves de sessão e mecanismos de permissão como ERC-7715pode ajudar a apoiar diferentes equilíbrios entre conveniência e segurança para diferentes aplicações. Arquiteturas de guardião mais complicadas, como ter várias durações de bloqueio temporal em diferentes limiares, podem ajudar a maximizar a chance de recuperação bem-sucedida de contas legítimas, minimizando o risco de roubo.
Para um usuário experiente de criptomoeda que está dentro de uma comunidade de usuários experientes de criptomoeda, uma opção viável são as chaves dos seus amigos e familiares. Se você pedir para cada um fornecer um endereço novo, então ninguém precisa saber quem são eles - na verdade, seus guardiões nem precisam saber quem são uns dos outros. A chance deles conspirarem sem um deles lhe dar um aviso é muito pequena. No entanto, para a maioria dos novos usuários, essa opção não está disponível.
Uma segunda opção são guardiões institucionais: empresas que se especializam em realizar o serviço de apenas assinar uma transação se receberem alguma outra confirmação de que um pedido está vindo de você: por exemplo, um código de confirmação, ou para usuários de alto valor um chamada de vídeo. As pessoas têm tentado fazer isso por muito tempo, por exemplo, Eu perfilava a CryptoCorp em 2013. No entanto, até agora essas empresas não têm sido muito bem-sucedidas.
Uma terceira opção é ter vários dispositivos pessoais (por exemplo, telefone, desktop, carteira de hardware). Isso pode funcionar, mas também é difícil de configurar e gerenciar para usuários inexperientes. Existe também o risco de os dispositivos serem perdidos ou roubados ao mesmo tempo, especialmente se estiverem no mesmo local.
Recentemente, começamos a ver mais carteiras baseadas em passkeys. As passkeys podem ser armazenadas apenas em seus dispositivos, tornando-as uma solução de dispositivo pessoal, ou armazenadas na nuvem, tornando sua segurança dependente de uma complicado híbridode segurança de senha, pressupostos de hardware institucional e confiável. Realisticamente, as chaves de acesso são um ganho de segurança valioso para os usuários comuns, mas por si só não são suficientemente fortes para proteger as economias de uma vida de um usuário.
Felizmente, com ZK-SNARKs, temos uma quarta opção: ID centralizado envolto em ZK. Este género inclui zk-email, Anon Aadhaar, Carteira Myna, e muitos outros. Basicamente, você pode transformar muitas formas de identificação centralizada (corporativa ou governamental) e transformá-la em um endereço Ethereum, do qual só pode enviar transações gerando uma prova ZK-SNARK de posse da identificação centralizada.
Com esta adição, agora temos uma ampla gama de opções, e o ID centralizado ZK-wrapped é exclusivamente "amigável para novatos".
Para que isto funcione, precisa de ser implementado com uma interface de utilizador simplificada e integrada: deverá ser capaz de especificar apenas que quer “example@gmail.com” como guardião e deve gerar automaticamente o endereço Ethereum zk-email correspondente por baixo. Utilizadores avançados devem ser capazes de introduzir o seu email (juntamente com talvez um valor de salt para privacidade, que seria guardado nesse email) numa aplicação de terceiros de código aberto, e confirmar que o endereço gerado está correto. O mesmo deve ser verdade para qualquer outro tipo de guardião suportado.
Mockup da possível interface Safe
Note que hoje, um desafio prático com o zk-email especificamente é que depende deassinaturas DKIM, que usam chaves que são alteradas a cada poucos meses, e essas chaves não são assinadas por nenhuma outra autoridade. Isso significa que o zk-email hoje possui algum nível de requisito de confiança além do próprio provedor; isso poderia ser reduzido se o zk-email usasse TLSNotarydentro de hardware confiável para verificar chaves atualizadas, mas não é ideal. Esperançosamente, os provedores de e-mail começarão a assinar diretamente suas chaves DKIM. Hoje, eu recomendaria usar e-mail zk para um guardião, mas não para a maioria dos seus guardiões: não armazene fundos em um ambiente onde a quebra do e-mail zk significa que você perde o acesso aos seus fundos.
Novos utilizadores realisticamente não vão querer ter de inserir um grande número de guardiões na sua primeira experiência de registo. Por isso, as carteiras devem oferecer-lhes uma opção muito simples. Uma rota natural é um 2-de-3 usando zk-email no seu endereço de email, uma chave armazenada localmente no dispositivo do utilizador (que poderia ser uma chave de acesso), e uma chave de backup mantida pelo fornecedor. À medida que um utilizador ganha mais experiência ou acumula mais ativos, em algum momento deve ser solicitado que adicione mais guardiões.
As carteiras integradas em aplicações são inevitáveis, porque as aplicações que tentam atrair utilizadores não criptográficos não querem a experiência de utilizador confusa de pedir aos seus utilizadores para descarregarem duas novas aplicações (a própria aplicação, mais uma carteira Ethereum) ao mesmo tempo. No entanto, um utilizador de muitas carteiras de aplicações deve ser capaz de ligar todas as suas carteiras juntas, para que só tenham uma "coisa de controlo de acesso" com que se preocupar. A maneira mais simples de fazer isso é um esquema hierárquico, onde existe um processo de "ligação" rápido que permite a um utilizador definir a sua carteira principal como guardiã de todas as suas carteiras de aplicações. O cliente Farcaster Warpcast já suporta isto:
Por predefinição, a recuperação da sua conta Warpcast é controlada pela equipa Warpcast. No entanto, pode 'tomar a soberania' da sua conta Farcaster e alterar a recuperação para o seu próprio endereço.
Além da segurança da conta, as carteiras hoje fazem muito para identificar endereços falsos, phishing, golpes e outras ameaças externas, e tentam proteger seus usuários dessas ameaças. Ao mesmo tempo, muitos dos contra-ataques ainda são bastante primitivos: por exemplo, exigindo um clique para enviar ETH ou outros tokens para qualquer novo endereço, independentemente de você estar enviando $100 ou $100.000. Aqui, não há uma solução mágica única; é uma série de correções lentas e melhorias contínuas em diferentes categorias de ameaças. No entanto, há muito valor em continuar trabalhando duro para melhorar aqui.
Agora é a hora de começar a levar a privacidade no Ethereum muito mais a sério. A tecnologia ZK-SNARK está agora muito avançada, tecnologias de privacidade que mitigam riscos regulatórios sem depender de portas dos fundos, como Piscinas de Privacidade, estão cada vez mais maduros, e infraestruturas secundárias como Wakue as mempools ERC-4337 estão lentamente se tornando mais estáveis. No entanto, até agora, fazer transferências privadas no Ethereum exigia que os usuários fizessem o download e usassem explicitamente uma "carteira de privacidade", como Ferrovia (ou Umbraparaendereços ocultos). Isso adiciona grande inconveniência e reduz o número de pessoas que estão dispostas a fazer transferências privadas. A solução é que as transferências privadas precisam ser integradas diretamente nas carteiras.
Uma implementação simples é a seguinte. Uma carteira poderia armazenar uma parte dos ativos do usuário como um “saldo privado” numa pool de privacidade. Quando um usuário faz uma transferência, a carteira retiraria automaticamente da pool de privacidade primeiro. Se um usuário precisa receber fundos, a carteira poderia gerar automaticamente um endereço oculto.
Além disso, uma carteira poderia gerar automaticamente um novo endereço para cada aplicação em que um usuário participa (por exemplo, um protocolo defi). Os depósitos viriam do pool de privacidade e as retiradas iriam diretamente para o pool de privacidade. Isso permite que a atividade de um usuário em qualquer aplicação seja desvinculada de sua atividade em outras aplicações.
Uma vantagem desta técnica é que ela é um caminho natural não apenas para transferência de ativos que preservam a privacidade, mas também para identidade que preserva a privacidade. A identidade já ocorre na cadeia: qualquer aplicativo que utiliza o bloqueio de prova de pessoa (por exemplo, Gitcoin Grants), qualquer chat bloqueado por token, o Protocolo de Seguimento Ethereum, e muito mais são todas identidades onchain. Queremos que esse ecossistema também seja preservador de privacidade. Isso significa que a atividade de um usuário onchain não deve ser coletada em um só lugar: cada item deve ser armazenado separadamente, e a carteira do usuário deve ser a única coisa com uma "visão global" que vê todas as suas comprovações ao mesmo tempo. Um ecossistema nativamente com muitas contas por usuário ajuda a alcançar isso, assim como os protocolos de comprovação offchain, como EASeZupass.
Esta representa uma visão pragmática para a privacidade do Ethereum no futuro de médio prazo. Pode ser implementada hoje, embora existam recursos que possam ser introduzidos em L1 e L2 para tornar as transferências preservadoras de privacidade mais eficientes e confiáveis. Alguns defensores da privacidade argumentam que a única coisa aceitável é a total privacidade de tudo: criptografando toda a EVM. Eu argumentaria que isso pode ser ideal como um resultado de longo prazo, mas requer uma reflexão muito mais fundamental dos modelos de programação, e atualmente não está no nível de maturidade em que está pronto para ser implantado em toda a plataforma Ethereum. Precisamos de privacidade-por-padrão para obter conjuntos de anonimato suficientemente grandes. No entanto, concentrar-se primeiro em tornar (i) as transferências entre contas e (ii) casos de uso de identidade e identidade-adjacentes, como atestações, privados, é um primeiro passo pragmático que é muito mais fácil de implementar e em que as carteiras podem começar hoje em dia.
Uma consequência de qualquer solução de privacidade eficaz, seja para pagamentos, identidade ou outros casos de uso, é que ela cria uma necessidade para o usuário armazenar dados offchain. Isso era óbvio no Tornado Cash, que exigia que os usuários salvassem cada "nota" individual representando um depósito de 0,1-100 ETH. Protocolos de privacidade mais modernos às vezes salvam os dados criptografados onchain e usam uma única chave privada para descriptografá-los. Isso é arriscado, porque se a chave for vazada, ou se os computadores quânticos se tornarem viáveis, todos os dados se tornam públicos. Atestados offchain como EAS e Zupass têm uma necessidade ainda mais óbvia de armazenamento de dados offchain.
As carteiras precisam não apenas se tornar software para armazenar permissões de acesso onchain, mas também software para armazenar seus dados privados. Isso é algo que o mundo não cripto está reconhecendo cada vez mais, por exemplo, veja Tim Berners-Lee’s trabalho recente em armazenamento de dados pessoais. Todos os problemas que precisamos resolver em torno da garantia robusta do controle de permissões de acesso, também precisamos resolver em torno da garantia robusta da acessibilidade e não vazamento de dados. Talvez as soluções possam ser sobrepostas: se você tiver N guardiões, use compartilhamento de segredos M-de-N entre esses mesmos N guardiões para armazenar seus dados. Os dados são inerentemente mais difíceis de proteger, porque não pode revogar a parte de alguém, mas deveríamos criar soluções de custódia descentralizadas que sejam o mais seguras possível.
Atualmente, as carteiras confiam nos seus fornecedores RPC para lhes transmitir qualquer informação sobre uma cadeia. Isso representa uma vulnerabilidade em dois aspectos:
Idealmente, queremos tapar ambos estes buracos. Para tapar o primeiro, precisamos de clientes leves padronizados para L1 e L2s, que verifiquem diretamente o consenso da blockchain.Heliosjá o faz para L1 e tem feito algum trabalho preliminar para suportar alguns L2s específicos. Para cobrir adequadamente todos os L2s, o que precisamos é de um padrão pelo qual um contrato de configuração representando um L2 (também usado para endereços específicos da cadeia) possa declarar uma função, talvez de maneira semelhante a,ERC-3668, contendo a lógica para obter raízes de estado recentes e verificar provas de estado e recibos em relação a essas raízes de estado. Dessa forma, poderíamos ter um cliente leve universal, permitindo que as carteiras verifiquem com segurança qualquer estado ou eventos na L1 e L2.
Para privacidade, hoje a única abordagem realista é executar seu próprio nó completo. No entanto, agora que L2s estão entrando em cena, executar um nó completo de tudo está se tornando cada vez mais difícil. O equivalente a um cliente leve aqui é recuperação de informação privada (PIR). PIR envolve um servidor que possui uma cópia de todos os dados e um cliente que envia ao servidor uma solicitação criptografada. O servidor realiza um cálculo sobre todos os dados, o que retorna os dados desejados do cliente, criptografados para a chave do cliente, sem revelar ao servidor qual parte dos dados o cliente acessou.
Para manter o servidor honesto, os itens individuais do banco de dados seriam eles próprios ramos de Merkle, para que o cliente possa verificá-los usando seu cliente leve.
PIR é muito computacionalmente caro. Existem várias maneiras de contornar esse problema:
Encontrar a combinação certa de técnicas para maximizar a privacidade ao mesmo tempo que se mantém a praticidade no contexto do Ethereum é um problema de pesquisa aberto, e eu saúdo os criptógrafos que tentam resolvê-lo.
Além de transferências e acesso ao estado, outro fluxo de trabalho importante que precisa funcionar sem problemas em um contexto cruzado de L2 é alterar a configuração de validação de uma conta: seja alterando suas chaves (por exemplo, recuperação), ou uma mudança mais profunda em toda a lógica da conta. Aqui, existem três camadas de soluções, em ordem crescente de dificuldade:
A solução (3) é particularmente poderosa porque combina bem com a privacidade. Em uma "solução de privacidade" normal, um usuário tem um segredo s , um "valor folha" L é publicado em cadeia, e um usuário prova que L = hash(s, 1) e N = hash(s, 2) para algum segredo (nunca revelado) que eles controlam. O anulador N é publicado, certificando-se de que gastos futuros da mesma folha falham, sem nunca revelar L. Isso depende de o usuário se manter seguro. Em vez disso, uma solução de privacidade amigável para recuperação diria: s é um local (por exemplo, endereço e slot de armazenamento) onchain, e o usuário deve provar uma consulta de estado: L = hash(sload(s), 1) .
O elo mais fraco na segurança de um usuário é frequentemente o dapp. Na maioria das vezes, um usuário interage com uma aplicação indo para um site, que implicitamente faz o download do código da interface do usuário em tempo real a partir de um servidor e depois o executa no navegador. Se o servidor for hackeado, ou se o DNS for hackeado, o usuário receberá uma cópia falsa da interface, que poderia enganar o usuário a fazer coisas arbitrárias. Recursos da carteira como simulações de transações são muito úteis para mitigar os riscos, mas estão longe de serem perfeitos.
Idealmente, moveríamos o ecossistema para a versão de conteúdo on-chain: o usuário acessaria um dapp através do seu nome ENS, que conteria o hash IPFS da interface. Seria necessária uma transação on-chain de um multisig ou DAO para atualizar a interface. As carteiras mostrariam aos usuários se estão interagindo com uma interface on-chain mais segura ou uma interface web2 menos segura. As carteiras também podem mostrar aos usuários se estão interagindo com uma chain segura (por exemplo, estágio 1+, várias auditorias de segurança).
Para usuários preocupados com a privacidade, as carteiras também podem adicionar um modo paranoico, que exige que os usuários cliquem para aceitar solicitações HTTP, e não apenas operações web3:
Mockup de possível interface para o modo paranóico
Uma abordagem mais avançada seria ir além do HTML + Javascript e escrever a lógica de negócios dos dapps numa linguagem dedicada, talvez uma sobreposição relativamente fina sobre Solidity ou Vyper. Os navegadores poderiam então gerar automaticamente uma interface do usuário para qualquer funcionalidade necessária.OKContractjá está a fazer isso.
Outra direção é a info-defesa cripto-econômica: os desenvolvedores de dapp, empresas de segurança, implementadores de blockchain e outros podem constituir uma garantia que seria paga aos usuários afetados se um dapp fosse hackeado ou prejudicasse os usuários de alguma forma altamente enganosa, conforme determinado por algum DAO de adjudicação onchain. A carteira poderia mostrar ao usuário uma pontuação baseada no valor da garantia.
Tudo acima foi no contexto de interfaces convencionais, que envolvem apontar e clicar em coisas e inserir coisas em campos de texto. No entanto, também estamos à beira de paradigmas que mudam muito mais profundamente:
Estas três tendências em conjunto levarão a uma reformulação muito mais profunda da forma como as interfaces funcionam. Através da entrada de linguagem natural, rastreamento ocular ou, eventualmente, BCI mais direto, juntamente com o conhecimento do seu histórico (talvez incluindo mensagens de texto, desde que todos os dados sejam processados localmente), uma "carteira" pode ter uma ideia intuitiva clara do que você quer fazer. Isso poderia reduzir consideravelmente a necessidade de interfaces de usuário de terceiros. Se um usuário interagir com um aplicativo de terceiros (ou outro usuário), a IA deve pensar negativamente em nome do usuário e identificar quaisquer ameaças e sugerir planos de ação para evitá-las. Idealmente, haveria um ecossistema aberto dessas IAs, produzido por diferentes grupos com diferentes vieses e estruturas de incentivo.
Essas ideias mais radicais dependem de tecnologia extremamente imatura hoje, portanto, não colocaria meus ativos hoje em uma carteira que depende delas. No entanto, algo assim parece ser claramente o futuro, então vale a pena começar a explorar mais ativamente nessa direção.