A Origem do EIP-6963

No ecossistema blockchain, as carteiras de extensão do navegador são aplicações de carteira que existem na forma de plugins de navegador. Permitem aos utilizadores interagir 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 no ecossistema Ethereum. Ao contrário das aplicações tradicionais, as carteiras de extensão do navegador estão integradas no ambiente do navegador. Este método simplifica o processo de interação do utilizador com a blockchain e elimina as barreiras técnicas das operações de nós complexas ou gestão de chaves privadas. Os utilizadores apenas precisam de instalar a extensão para começar rapidamente a usar a rede blockchain.

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

Imagine que deseja usar uma bolsa de valores descentralizada (DEX) ou um mercado de NFT. Abre o site do dApp, entusiasmado para começar a interagir. No entanto, surge um problema - o seu navegador tem várias extensões de carteira instaladas, como MetaMask, Carteira Coinbase e Carteira Brave, mas o dApp falha em identificar corretamente qual carteira está a utilizar e até mesmo lança uma mensagem de erro: 'Nenhuma carteira detetada, por favor instale uma extensão de carteira.' 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 surgem mais extensões de carteira e fornecedores de serviços, a experiência do utilizador torna-se mais complicada e confusa.

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

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

1. Conflito de várias carteiras: Quando os utilizadores têm várias carteiras de extensão para navegadores instaladas, o EIP-1193 vincula por padrão o window.ethereum à primeira carteira carregada. Como resultado, outras carteiras podem não ser reconhecidas corretamente e, em alguns casos, a dApp pode nem funcionar.
2. Falta de Suporte a Múltiplos Serviços: Muitas dApps querem suportar várias carteiras, mas o EIP-1193 não fornece um mecanismo claro para distinguir ou escolher entre diferentes prestadores de serviços. Isso obriga os desenvolvedores de dApp a projetar lógica complexa para lidar com a adaptação da carteira.
3. Experiência do utilizador não intuitiva: Para utilizadores regulares, é difícil compreender as razões técnicas por trás de mensagens de erro como "Nenhuma carteira detetada" ou "Não conectado corretamente", o que aumenta o limiar de utilização e leva à frustração.

Para resolver este problema, a comunidade propôs EIP-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 carteiras, promover uma competição mais justa e melhorar a experiência do usuário na rede Ethereum. Especificamente, 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á aos usuários selecionar 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 fornecedor da carteira, ao mesmo tempo que previne conflitos de namespace. O EIP-6963 enfatiza as regras que as convenções RDNS devem seguir, tais como formatos de domínio válidos e partes de domínio controladas pelo fornecedor. Também enfatiza que os dApps não devem depender do valor RDNS para detecção de recursos, para evitar a possibilidade de incentivos forjados ou maliciosos. A interface ProviderDetail do EIP-6963 fornece aos dApps metadados do fornecedor da carteira, auxiliando na interação com a carteira.

Detalhes do Fornecedor EIP6963

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 as dApps obtenham informações detalhadas sobre as carteiras e interajam com elas por meio de interfaces padronizadas. Esta interface serve como base para alcançar compatibilidade e interoperabilidade entre aplicações descentralizadas e várias carteiras.

Mecanismo de Eventos

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

Tipos de Eventos

Evento EIP6963AnnounceProviderEvent: Este evento é usado pelas carteiras para anunciar a sua presença. Contém informações sobre a carteira (EIP6963ProviderDetail) e a interface da carteira (EIP1193Provider). A propriedade de detalhe deste evento manté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. A dApp usa este evento para notificar a carteira de que está pronta e solicita interação.

Concorrência de Eventos

Devido à ordem de execução indeterminada do código dApp e da carteira, podem surgir condições de corrida. 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á reativar o evento de anúncio após o inicial, garantindo que o dApp o receba de forma oportuna.

Manipulação de Eventos da dApp

As dApps devem ouvir o EIP6963AnnounceProviderEvent e não devem remover o ouvinte de eventos durante o carregamento da página. Isso garante que o dApp possa ouvir continuamente e responder 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 EIP6963RequestProviderEvent para solicitar uma interação adicional com a carteira.

Descoberta e Troca de Carteira

As dApps podem armazenar vários objetos EIP6963ProviderDetail para várias carteiras, permitindo aos utilizadores escolher entre diferentes carteiras para interação dentro da dApp. Isto proporciona uma maior flexibilidade aos utilizadores, permitindo-lhes alternar entre carteiras 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 utilizar ouvintes de eventos e acionadores 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, as 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 EIP não requer a substituição de window.ethereum, o que significa que não irá quebrar diretamente as aplicações existentes que não podem ser atualizadas para utilizar este método de descoberta de carteira. No entanto, é altamente recomendável que as dApps implementem este EIP para garantir que possam descobrir vários fornecedores de carteiras e que desativem a utilização de window.ethereum, a menos que seja utilizado como método de fallback quando a descoberta falha. Da mesma forma, os fornecedores de carteiras devem manter a compatibilidade com window.ethereum para garantir a compatibilidade com as dApps que não implementam este EIP. Para evitar problemas de conflito de namespace anteriores, recomenda-se que as carteiras injetem seu objeto de provedor em um namespace de carteira específico e, em seguida, façam proxy do objeto 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 fornecedores, que é um recurso central do seu design. Os objetos fornecedores 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 da carteira disparar o evento eip6963:announceProvider. Isso garante que o objeto não possa ser modificado. No entanto, em alguns casos, a compatibilidade com a web pode exigir a modificação desse objeto. Nessas situações, os implementadores da carteira precisam encontrar um equilíbrio entre segurança e compatibilidade com a web.

Falsificação e Adulteração de Carteiras

As dApps devem detetar ativamente se as propriedades ou funções do objeto fornecedor de carteiras foram adulteradas para prevenir a falsificação ou alteração de outras carteiras. Uma forma de detetar falsificações é verificar se a propriedade uuid nos dois objetos EIP6963ProviderInfo é consistente. As dApps e as suas bibliotecas de descoberta devem considerar outros métodos potenciais de adulteração e tomar medidas de proteção adicionais para prevenir tal comportamento, garantindo a segurança do utilizador.

Prevenção da Execução de JavaScript em SVGs

O uso de imagens SVG pode levar a ataques de script entre sites (XSS), uma vez que os SVGs podem conter código JavaScript. Este código é executado no contexto da página e poderia 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, escondendo modificações maliciosas na página ou na carteira.

Prevenção de Impressão Digital 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 anúncio do provedor. Portanto, os implementadores de carteiras podem escolher se anunciam a si mesmos para todas as páginas ou tomam outras medidas para reduzir a probabilidade de os usuários serem identificados através do objeto window.ethereum injetado. Uma possível alternativa é 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 da interface do usuário, perguntando se o usuário está disposto a compartilhar seu endereço da carteira. Esta abordagem permite à carteira ativar um recurso de "conexão privada". No entanto, ao adotar esta abordagem, a carteira também precisa considerar como garantir a compatibilidade com dApps que não suportam este EIP.

Recursos das Melhorias do EIP-6963

Simplificação do Processo de Descoberta da Carteira

A EIP-6963, proposta em maio de 2023 como um novo padrão Ethereum e aprovada 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, a EIP-6963 simplifica o processo de descoberta da carteira, suportando a coexistência de várias extensões de carteira no mesmo navegador. Essa inovação melhora significativamente a interoperabilidade do ecossistema Ethereum e aprimora a experiência do usuário.

Definição clara e experiência do utilizador melhorada

EIP-6963 não é apenas uma melhoria funcional; também melhora 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). As dApps podem exibir essas informações, permitindo que os usuários entendam claramente com qual carteira estão interagindo, evitando assim confusão e erros de operação. Isso resulta em uma interface mais clara, confiável e amigável. Dessa forma, o EIP-6963 oferece aos usuários uma experiência mais suave, reduzindo disputas potenciais e dificuldades operacionais desnecessárias, contribuindo positivamente para o ecossistema geral do Ethereum.

Potenciais Riscos de Segurança

O design do EIP-6963 introduz potenciais vulnerabilidades de segurança. Ao fornecer uma lista de todas as carteiras registadas, facilita a interação entre dApps e utilizadores, mas também pode ser mal utilizada por aplicações maliciosas. dApps maliciosas podem ler a lista de carteiras instaladas pelos utilizadores, inferindo as suas atividades na blockchain ou distribuições de ativos. Se o mecanismo de registo de serviços carecer de verificação rigorosa, as carteiras maliciosas podem mascarar-se como fornecedores de serviços legítimos, enganando os utilizadores para conceder acesso e roubar ativos. Portanto, medidas de segurança adicionais (como consentimento do utilizador e validação de registo) são necessárias.

Complexidade na Experiência do Utilizador

Em termos de experiência do usuário, o suporte a várias carteiras do EIP-6963, embora seja 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 os usuários que precisam alternar entre carteiras com frequência, essa flexibilidade pode se tornar um fardo em vez de um benefício.

Resumo

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