A Origem do PEI-6963

No ecossistema blockchain, as carteiras de extensão do navegador são aplicativos de carteira que existem na forma de plugins de navegador. Eles permitem que os usuários interajam convenientemente com contas blockchain diretamente dentro de dApps, como enviar transações, assinar mensagens ou interagir com contratos inteligentes. O exemplo mais típico é o MetaMask, que quase se tornou uma ferramenta padrão para usar dApps do ecossistema Ethereum. Ao contrário de aplicativos tradicionais, as carteiras de extensão do navegador são integradas ao ambiente do navegador. Esse método simplifica o processo de interação do usuário com a blockchain e elimina as barreiras técnicas de operações de nós complexas ou gerenciamento de chaves privadas. Os usuários só precisam instalar a extensão para começar rapidamente a usar a rede blockchain.

Neste contexto, um “provedor de serviços” refere-se à tecnologia subjacente ou interface que suporta essas funções de carteira. Por exemplo, as carteiras comunicam com nós de blockchain através do protocolo JSON-RPC Ethereum, enquanto o provedor de serviço oferece a interface RPC correspondente para permitir à carteira lidar de forma segura com interações on-chain.

Imagine que você queira usar uma bolsa de câmbio descentralizada (DEX) ou um mercado NFT. Você abre o site do dApp, animado para começar a interagir. No entanto, surge um problema - seu navegador tem várias extensões de carteira instaladas, como MetaMask, Carteira da Coinbase e Brave Wallet, mas o dApp falha em identificar corretamente qual carteira você está usando no momento e até mesmo lança uma mensagem de erro: "Nenhuma carteira detectada, por favor instale uma extensão de carteira." Você tenta atualizar a página e reiniciar o navegador, mas o problema persiste. Este cenário comum destaca um problema prático: os mecanismos de identificação e interação das extensões de carteira do navegador são inadequados. À medida que mais extensões de carteira e provedores de serviços surgem, a experiência do usuário se torna mais complicada e confusa.

Para resolver os problemas de interação entre as carteiras e dApps, a comunidade introduziu o PEI-1193 (API Provedora JavaScript Ethereum), um padrão universal que define como dApps podem se comunicar com carteiras via o ambiente do navegador. A ideia central do PEI-1193 é lidar com as funções blockchain fornecidas pela carteira por meio de uma interface padronizada. Por exemplo, um dApp se comunica com a carteira por meio do objeto window.ethereum, enviando solicitações ou recebendo eventos blockchain.

Embora o EIP-1193 aborde parcialmente problemas de compatibilidade entre carteiras e dApps, ainda possui algumas limitações óbvias:

1. Conflito de várias carteiras: Quando os usuários têm várias carteiras de extensão do navegador instaladas, o PEI-1193 por padrão vincula o window.ethereum à primeira carteira que é carregada. Como resultado, outras carteiras podem não ser reconhecidas corretamente e, em alguns casos, o dApp pode não funcionar de forma alguma.
2. Falta de Suporte a Múltiplos Serviços: Muitos dApps desejam oferecer suporte a várias carteiras, mas o PEI-1193 não fornece um mecanismo claro para distinguir ou escolher entre diferentes provedores de serviços. Isso força os desenvolvedores de dApp a projetar lógica complexa para lidar com a adaptação de carteiras.
3. Experiência do Usuário Pouco Intuitiva: Para usuários comuns, é difícil entender as razões técnicas por trás de mensagens de erro como "Nenhuma carteira detectada" ou "Conexão incorreta", o que aumenta o limiar de uso e leva à frustração.

Para resolver esse problema, a comunidade propôs o PEI-6963 (Padrão de Descoberta de Carteira de Extensão do Navegador), um plano de melhoria para carteiras de extensão do navegador com o objetivo de otimizar os mecanismos de descoberta e interação da carteira. A solução visa reduzir a barreira de entrada para novos provedores de carteira, promover uma competição mais justa e aprimorar a experiência do usuário na rede Ethereum. Especificamente, ela introduz um conjunto de eventos de janela e fornece um protocolo de comunicação bidirecional, permitindo que bibliotecas Ethereum e scripts injetados por extensões de navegador interajam. Isso permitirá que os usuários selecionem sua carteira preferida com base em suas necessidades, melhorando a experiência geral.

Análise de Código

DNS reverso (RDNS)

O DNS reverso (RDNS) garante a estabilidade dos identificadores do provedor de carteira, ao mesmo tempo que evita conflitos de espaço de nome. O EIP-6963 enfatiza as regras que as convenções do RDNS devem seguir, como formatos de domínio válidos e partes de domínio controladas pelo provedor. Também destaca que os dApps não devem depender do valor do RDNS para detecção de recursos, a fim de evitar a possibilidade de incentivos forjados ou maliciosos. A interface ProviderDetail do EIP-6963 fornece aos dApps metadados do provedor de carteira, auxiliando na interação com a carteira.

PEI6963DetalheDoFornecedor

O EIP6963ProviderDetail é uma interface usada para declarar e descrever informações do fornecedor da carteira. Ao incluir propriedades como info (metadados da carteira) e provider (interface do fornecedor da carteira), permite que dApps obtenham informações detalhadas sobre carteiras e interajam com elas por meio de interfaces padronizadas. Esta interface serve como base para alcançar compatibilidade e interoperabilidade entre aplicativos descentralizados e várias carteiras.

Mecanismo de Eventos

O mecanismo de evento garante que os dApps e carteiras possam descobrir e interagir entre si sem depender de uma ordem de execução fixa. Isso permite que a descoberta e interação entre dApps e carteiras não sejam afetadas pela ordem de execução, evitando assim conflitos e erros.

Tipos de Eventos

PEI6963AnunciarEventoProvedor: Este evento é usado pelas carteiras para anunciar sua presença. Ele contém informações sobre a carteira (DetalheProvedorPEI6963) e a interface da carteira (ProvedorPEI1193). A propriedade de detalhe deste evento contém os metadados congelados da carteira (usando Object.freeze()) para garantir imutabilidade.

Evento EIP6963RequestProviderEvent: Este evento é usado por dApps para solicitar um provedor de carteira. O dApp usa este evento para notificar a carteira de que está pronto e solicita interação.

Concorrência de Eventos

Devido à ordem de execução indeterminada do código dApp e da carteira, condições de corrida podem surgir. O mecanismo de evento é especificamente projetado para garantir que dApps e carteiras possam lidar corretamente com eventos quando se descobrem mutuamente. Uma carteira pode emitir o evento de anúncio primeiro, enquanto o dApp pode não estar pronto para ouvi-lo até mais tarde. Para prevenir erros, a carteira irá re-disparar o evento de anúncio após o inicial, garantindo que o dApp o receba de maneira oportuna.

Tratamento de Eventos do dApp

Os dApps devem escutar o evento EIP6963AnnounceProviderEvent e não devem remover o ouvinte de eventos durante o carregamento da página. Isso garante que o dApp possa continuar escutando e respondendo continuamente ao evento de anúncio da carteira durante seu ciclo de vida. Após lidar com o evento de anúncio, o dApp deve acionar o evento EIP6963RequestProviderEvent para solicitar uma interação adicional com a carteira.

Descoberta e Troca de Carteira

dApps podem armazenar vários objetos de detalhes do Provedor EIP6963 para várias carteiras, permitindo que os usuários escolham entre diferentes carteiras para interação dentro do dApp. Isso proporciona maior flexibilidade para os usuários, permitindo que eles troquem de carteira sem recarregar a página.

Este design alcança uma descoberta e interação contínuas entre dApps e carteiras através do EIP6963AnnounceProviderEvent e EIP6963RequestProviderEvent. Ao usar ouvintes de eventos e gatilhos de eventos, dApps e carteiras podem coordenar suas ações apesar da ordem de execução indeterminada, evitar condições de corrida e garantir um comportamento estável. Além disso, dApps podem trocar de carteiras com base nas preferências do usuário, melhorando a experiência do usuário e a interoperabilidade das carteiras.

Compatibilidade com Versões Anteriores

Este PEI não requer a substituição de window.ethereum, o que significa que não quebrará diretamente as aplicações existentes que não podem ser atualizadas para usar este método de descoberta da carteira. No entanto, é altamente recomendável que os dApps implementem este PEI para garantir que possam descobrir vários provedores de carteira e que desativem o uso de window.ethereum, a menos que seja usado como um método de fallback quando a descoberta falhar. Da mesma forma, os provedores de carteira devem manter a compatibilidade com window.ethereum para garantir a compatibilidade com os dApps que não implementam este PEI. Para evitar problemas anteriores de conflito de namespace, é recomendável que as carteiras injetem seu objeto provedor em um namespace de carteira específico e depois o encaminhem para o namespace window.ethereum.

Design de segurança

Poluição de Protótipo do Objeto Fornecedor de Carteira

As extensões do navegador, especialmente as extensões da carteira, têm a capacidade de modificar o conteúdo da página e os objetos do provedor, que é um recurso essencial do seu design. Os objetos do provedor de várias carteiras são considerados interfaces altamente confiáveis para transmitir dados de transação. Para evitar modificações não intencionais na interação entre o dApp e a carteira pela página ou outras extensões, a melhor prática é congelar o objeto EIP1193Provider usando Object.freeze() antes que a carteira despache o evento eip6963:announceProvider. Isso garante que o objeto não possa ser modificado. No entanto, em alguns casos, a compatibilidade web pode exigir a modificação desse objeto. Em tais casos, os implementadores da carteira precisam equilibrar a segurança e a compatibilidade web.

Carteira Falsificação e Manipulação

Os dApps devem detectar ativamente se as propriedades ou funções do objeto fornecedor de carteira foram adulteradas para evitar a falsificação ou alteração de outras carteiras. Uma maneira de detectar falsificações é verificando se a propriedade uuid nos dois objetos EIP6963ProviderInfo é consistente. Os dApps e suas bibliotecas de descoberta devem considerar outros métodos potenciais de adulteração e tomar medidas protetoras adicionais para evitar esse comportamento, garantindo a segurança do usuário.

Prevenindo a Execução de JavaScript em SVGs

O uso de imagens SVG pode levar a ataques de script entre sites (XSS), pois os SVGs podem conter código JavaScript. Esse código é executado no contexto da página e pode potencialmente modificar o conteúdo da página ou afetar outras carteiras. Portanto, ao renderizar ícones, os dApps precisam considerar como lidar com esses riscos de segurança para evitar que imagens maliciosas sejam usadas como técnicas de ofuscação, ocultando modificações maliciosas na página ou na carteira.

Prevenindo a Identificação da Carteira

Uma vantagem do mecanismo de loop de eventos concorrente usado neste design é que tanto o dApp quanto a carteira podem iniciar o processo de anunciar o provedor. Portanto, os implementadores de carteiras podem escolher se querem se anunciar para todas as páginas ou tomar outras medidas para reduzir a probabilidade de os usuários serem identificados por meio do objeto window.ethereum injetado. Uma possível alternativa é para a carteira atrasar a injeção do objeto provedor até que o dApp anuncie o evento eip6963:requestProvider. Neste ponto, a carteira pode iniciar um fluxo de consentimento de UI, perguntando ao usuário se estão dispostos a compartilhar seu endereço da carteira. Esta abordagem permite que a carteira habilite um recurso de “conexão privada”. No entanto, ao adotar esta abordagem, a carteira também precisa considerar como garantir a compatibilidade com aplicativos descentralizados que não suportam este PEI.

Recursos de Melhorias do PEI-6963

Simplificação do Processo de Descoberta da Carteira

PEI-6963, proposto em maio de 2023 como um novo padrão Ethereum e aprovado em outubro do mesmo ano, tem como objetivo abordar a falta de padrões claramente definidos como window.ethereum. O padrão introduz um mecanismo de descoberta de provedor de injeção múltipla, permitindo que dApps descubram e se conectem de forma confiável a todas as carteiras instaladas no navegador do usuário. Isso supera as limitações e conflitos apresentados pelos métodos tradicionais. Comparado à abordagem tradicional window.ethereum, o PEI-6963 simplifica o processo de descoberta da carteira, suportando a coexistência de múltiplas extensões de carteira no mesmo navegador. Essa inovação aprimora significativamente a interoperabilidade do ecossistema Ethereum e melhora a experiência do usuário.

Definição clara e melhor experiência do usuário

O EIP-6963 não é apenas uma melhoria funcional; ele também aprimora a reconhecibilidade das carteiras e a experiência do usuário, permitindo que as carteiras injetem informações como nome, logotipo, UUID e DNS reverso (RDNS). Os dApps podem exibir essas informações, permitindo que os usuários compreendam claramente com qual carteira estão interagindo, evitando assim confusões e erros de operação. Isso resulta em uma interface mais clara, confiável e amigável ao usuário. Dessa forma, o EIP-6963 proporciona aos usuários uma experiência mais suave, reduzindo disputas potenciais e dificuldades operacionais desnecessárias, contribuindo positivamente para o ecossistema geral do Ethereum.

Riscos Potenciais de Segurança

O design do PEI-6963 introduz potenciais vulnerabilidades de segurança. Ao fornecer uma lista de todas as carteiras registradas, ele facilita a interação entre dApps e usuários, mas também pode ser mal utilizado por aplicativos maliciosos. Os dApps maliciosos podem ler a lista de carteiras instaladas pelos usuários, inferindo suas atividades em blockchain ou distribuições de ativos. Se o mecanismo de registro de serviços carece de verificação rigorosa, as carteiras maliciosas podem se passar por provedores de serviços legítimos, enganando os usuários para conceder acesso e roubar ativos. Portanto, medidas adicionais de segurança (como consentimento do usuário e validação de registro) são necessárias.

Complexidade na Experiência do Usuário

Em termos de experiência do usuário, o suporte a várias carteiras do PEI-6963, embora uma melhoria significativa, também pode aumentar a complexidade. Por exemplo, depois que um usuário instala várias carteiras, o dApp pode apresentar muitas opções, confundindo o usuário sobre qual carteira escolher. Além disso, algumas carteiras podem ter nomes ou logotipos que não são intuitivos, aumentando a dificuldade de identificação. Para usuários que precisam alternar frequentemente entre carteiras, essa flexibilidade pode se tornar um fardo em vez de um benefício.

Resumo

O EIP-6963 introduz uma abordagem baseada em eventos para resolver questões como coexistência de várias carteiras, conflitos de namespace e proteção de privacidade do usuário em aplicativos Web3, melhorando significativamente a experiência do usuário. Esse mecanismo padronizado permite que os dApps descubram e conectem automaticamente várias carteiras sem a necessidade de comutação manual, evitando competição e conflitos entre as carteiras, melhorando a fluidez e estabilidade das conexões. O EIP-6963 também fortalece a segurança congelando objetos do provedor de carteiras para evitar adulterações, reduzindo os riscos de segurança potenciais. Em termos de privacidade, os usuários podem escolher se desejam compartilhar seu endereço de carteira, prevenindo vazamentos de identidade e fingerprinting. O EIP-6963 mantém a compatibilidade com interfaces mais antigas, garantindo uma transição suave para sistemas existentes, simplificando o trabalho dos desenvolvedores de dApp e aprimorando o suporte multiplataforma e multi-dispositivo. Em geral, o EIP-6963 melhora a interoperabilidade, segurança e proteção de privacidade em Web3 e fornece aos desenvolvedores ferramentas mais eficientes, promovendo o desenvolvimento adicional do ecossistema Web3.