En el ecosistema de blockchain, las billeteras de extensión del navegador son aplicaciones de billetera que existen en forma de complementos del navegador. Permiten a los usuarios interactuar de manera conveniente con cuentas de blockchain directamente dentro de aplicaciones descentralizadas (dApps), como enviar transacciones, firmar mensajes o interactuar con contratos inteligentes. El ejemplo más típico es MetaMask, que casi se ha convertido en una herramienta estándar para usar dApps en el ecosistema de Ethereum. A diferencia de las aplicaciones tradicionales, las billeteras de extensión del navegador están integradas en el entorno del navegador. Este método simplifica el proceso de interacción del usuario con la blockchain y elimina las barreras técnicas de operaciones de nodos complejas o gestión de claves privadas. Los usuarios solo necesitan instalar la extensión para comenzar rápidamente a usar la red blockchain.
En este contexto, un "proveedor de servicios" se refiere a la tecnología subyacente o la interfaz que respalda estas funciones de billetera. Por ejemplo, las billeteras se comunican con los nodos de la cadena de bloques a través del protocolo JSON-RPC de Ethereum, mientras que el proveedor de servicios ofrece la interfaz RPC correspondiente para permitir que la billetera maneje de forma segura las interacciones en cadena.
Imagina que quieres usar un exchange descentralizado (DEX) o un mercado de tokens no fungibles (NFT). Abres el sitio web de la dApp, emocionado por empezar a interactuar. Sin embargo, surge un problema: tu navegador tiene instaladas múltiples extensiones de billetera, como MetaMask, Coinbase Wallet y Brave Wallet, pero la dApp no logra identificar correctamente qué billetera estás utilizando en ese momento e incluso muestra un mensaje de error: 'No se detectó ninguna billetera, por favor instala una extensión de billetera'. Intentas refrescar la página y reiniciar el navegador, pero el problema persiste. Este escenario común destaca un problema práctico: los mecanismos de identificación e interacción de las extensiones de billetera del navegador son inadecuados. A medida que surgen más extensiones de billetera y proveedores de servicios, la experiencia del usuario se vuelve más complicada y confusa.
Para abordar los problemas de interacción entre las billeteras y las dApps, la comunidad introdujo EIP-1193 (API del Proveedor de JavaScript de Ethereum), un estándar universal que define cómo las dApps pueden comunicarse con las billeteras a través del entorno del navegador. La idea principal de EIP-1193 es manejar las funciones de la cadena de bloques proporcionadas por la billetera a través de una interfaz estandarizada. Por ejemplo, una dApp se comunica con la billetera a través del objeto window.ethereum, enviando solicitudes o recibiendo eventos de la cadena de bloques.
Aunque EIP-1193 aborda parcialmente los problemas de compatibilidad entre billeteras y dApps, aún tiene algunas limitaciones obvias:
Para resolver este problema, la comunidad propuso EIP-6963 (Estándar de Descubrimiento de Billetera de Extensión del Navegador), un plan de mejora para las billeteras de extensión del navegador destinado a optimizar los mecanismos de descubrimiento e interacción de la billetera. La solución tiene como objetivo reducir la barrera de entrada para nuevos proveedores de billeteras, promover una competencia más justa y mejorar la experiencia del usuario en la red Ethereum. Específicamente, introduce un conjunto de eventos de ventana y proporciona un protocolo de comunicación bidireccional, permitiendo que las bibliotecas de Ethereum y los scripts inyectados por las extensiones del navegador interactúen. Esto permitirá a los usuarios seleccionar su billetera preferida según sus necesidades, mejorando la experiencia general.
La inversa de DNS (RDNS) garantiza la estabilidad de los identificadores del proveedor de billeteras mientras previene conflictos de espacio de nombres. El EIP-6963 enfatiza las reglas que las convenciones RDNS deben seguir, como los formatos de dominio válidos y las partes del dominio controladas por el proveedor. También destaca que las dApps no deben depender del valor de RDNS para la detección de funciones para evitar la posibilidad de incentivos falsificados o maliciosos. La interfaz ProviderDetail de EIP-6963 proporciona a las dApps metadatos del proveedor de billeteras, lo que ayuda en la interacción con la billetera.
El EIP6963ProviderDetail es una interfaz utilizada para declarar y describir información del proveedor de billetera. Al incluir propiedades como info (metadatos de billetera) y provider (interfaz de proveedor de billetera), permite a las dApps obtener información detallada sobre las billeteras e interactuar con ellas a través de interfaces estandarizadas. Esta interfaz sirve como base para lograr compatibilidad e interoperabilidad entre aplicaciones descentralizadas y diversas billeteras.
El mecanismo de eventos garantiza que las dApps y las billeteras puedan descubrir e interactuar entre sí sin depender de un orden de ejecución fijo. Esto permite que el descubrimiento y la interacción entre dApps y billeteras no se vean afectados por el orden de ejecución, evitando así conflictos y errores.
AnunciarEventoProveedorEIP6963: Este evento es utilizado por billeteras para anunciar su presencia. Contiene información sobre la billetera (DetalleProveedorEIP6963) y la interfaz de la billetera (ProveedorEIP1193). La propiedad de detalle de este evento contiene los metadatos congelados de la billetera (usando Object.freeze()) para garantizar la inmutabilidad.
Evento EIP6963RequestProviderEvent: Este evento es utilizado por dApps para solicitar un proveedor de billetera. La dApp utiliza este evento para notificar a la billetera que está lista y solicita interacción.
Debido al orden de ejecución indeterminado del código de dApp y billetera, pueden surgir condiciones de carrera. El mecanismo de evento está diseñado específicamente para garantizar que las dApps y billeteras puedan manejar correctamente los eventos cuando se descubren mutuamente. Una billetera puede emitir primero el evento de anuncio, mientras que la dApp puede no estar lista para escucharlo hasta más tarde. Para evitar errores, la billetera volverá a activar el evento de anuncio después del inicial, asegurando que la dApp lo reciba de manera oportuna.
Las dApps deben escuchar el evento EIP6963AnnounceProviderEvent y no deben eliminar el escuchador de eventos durante la carga de la página. Esto garantiza que la dApp pueda escuchar y responder continuamente al evento de anuncio de la billetera durante su ciclo de vida. Después de manejar el evento de anuncio, la dApp debe desencadenar el evento EIP6963RequestProviderEvent para solicitar una mayor interacción con la billetera.
Las dApps pueden almacenar múltiples objetos EIP6963ProviderDetail para varias billeteras, lo que permite a los usuarios elegir entre diferentes billeteras para interactuar dentro de la dApp. Esto proporciona una mayor flexibilidad a los usuarios, permitiéndoles cambiar de billetera sin necesidad de recargar la página.
Este diseño logra un descubrimiento e interacción perfectos entre dApps y billeteras a través de EIP6963AnnounceProviderEvent y EIP6963RequestProviderEvent. Al utilizar escuchas de eventos y desencadenadores de eventos, las dApps y las billeteras pueden coordinar sus acciones a pesar del orden de ejecución indeterminado, evitar condiciones de carrera y garantizar un comportamiento estable. Además, las dApps pueden cambiar de billetera según las preferencias del usuario, mejorando la experiencia del usuario y la interoperabilidad de la billetera.
Este EIP no requiere reemplazar window.ethereum, lo que significa que no romperá directamente las aplicaciones existentes que no pueden actualizarse para usar este método de descubrimiento de billetera. Sin embargo, se recomienda encarecidamente que las dApps implementen este EIP para asegurarse de que puedan descubrir varios proveedores de billeteras y que deshabiliten el uso de window.ethereum, a menos que se utilice como método de respaldo cuando falla el descubrimiento. De manera similar, los proveedores de billeteras deben mantener la compatibilidad con window.ethereum para garantizar la compatibilidad con las dApps que no implementan este EIP. Para evitar problemas de conflictos de nombres anteriores, se recomienda que las billeteras inyecten su objeto proveedor en un espacio de nombres de billetera específico y luego proxy el objeto al espacio de nombres de window.ethereum.
Las extensiones del navegador, especialmente las extensiones de billetera, tienen la capacidad de modificar el contenido de la página y los objetos proveedores, lo cual es una característica central de su diseño. Los objetos proveedores de varias billeteras se consideran interfaces altamente confiables para transmitir datos de transacción. Para evitar modificaciones no deseadas de la interacción entre la dApp y la billetera por parte de la página u otras extensiones, la mejor práctica es congelar el objeto EIP1193Provider usando Object.freeze() antes de que la billetera despache el evento eip6963:announceProvider. Esto asegura que el objeto no se pueda modificar. Sin embargo, en algunos casos, la compatibilidad web puede requerir la modificación de este objeto. En tales casos, los implementadores de billeteras necesitan encontrar un equilibrio entre la seguridad y la compatibilidad web.
Las dApps deben detectar activamente si las propiedades o funciones del objeto proveedor de billetera han sido manipuladas para evitar la falsificación o alteración de otras billeteras. Una forma de detectar la falsificación es comprobando si la propiedad uuid en los dos objetos EIP6963ProviderInfo es consistente. Las dApps y sus bibliotecas de descubrimiento deben considerar otros posibles métodos de manipulación y tomar medidas protectoras adicionales para prevenir dicho comportamiento, garantizando la seguridad del usuario.
El uso de imágenes SVG puede provocar ataques de scripting entre sitios (XSS), ya que los SVG pueden contener código JavaScript. Este código se ejecuta en el contexto de la página y potencialmente podría modificar el contenido de la página o afectar otras billeteras. Por lo tanto, al representar iconos, las dApps necesitan considerar cómo manejar dichos riesgos de seguridad para prevenir que se utilicen imágenes maliciosas como técnicas de obfuscación, ocultando así modificaciones maliciosas en la página o billetera.
Una ventaja del mecanismo de bucle de eventos concurrentes utilizado en este diseño es que tanto la dApp como la billetera pueden iniciar el proceso para anunciar el proveedor. Por lo tanto, los implementadores de billeteras pueden elegir si anunciarse a todas las páginas o tomar otras medidas para reducir la probabilidad de que los usuarios sean identificados mediante el objeto window.ethereum inyectado. Una posible alternativa es que la billetera retrase la inyección del objeto proveedor hasta que la dApp anuncie el evento eip6963:requestProvider. En este punto, la billetera puede iniciar un flujo de consentimiento de interfaz de usuario, preguntando al usuario si está dispuesto a compartir su dirección de billetera. Este enfoque permite a la billetera habilitar una función de “conexión privada”. Sin embargo, al seguir este enfoque, la billetera también debe considerar cómo garantizar la compatibilidad hacia atrás con las dApps que no admiten este EIP.
EIP-6963, propuesto en mayo de 2023 como un nuevo estándar de Ethereum y aprobado en octubre del mismo año, tiene como objetivo abordar la falta de estándares claramente definidos como window.ethereum. El estándar introduce un mecanismo de descubrimiento de proveedores de inyección múltiple, permitiendo a las dApps descubrir y conectarse de manera confiable a todas las billeteras instaladas en el navegador del usuario. Esto supera las limitaciones y conflictos presentados por los métodos tradicionales. En comparación con el enfoque tradicional de window.ethereum, EIP-6963 simplifica el proceso de descubrimiento de billeteras, admitiendo la coexistencia de múltiples extensiones de billetera en el mismo navegador. Esta innovación mejora en gran medida la interoperabilidad del ecosistema de Ethereum y mejora la experiencia del usuario.
EIP-6963 no es solo una mejora funcional; también mejora la reconocibilidad de las billeteras y la experiencia del usuario al permitir que las billeteras inyecten información como nombre, logotipo, UUID y DNS inverso (RDNS). Las dApps pueden mostrar esta información, lo que permite a los usuarios comprender claramente con qué billetera están interactuando, evitando así confusiones y malas operaciones. Esto resulta en una interfaz más clara, confiable y amigable para el usuario. De esta manera, EIP-6963 proporciona a los usuarios una experiencia más fluida, reduce disputas potenciales y dificultades operativas innecesarias, al tiempo que contribuye positivamente al ecosistema general de Ethereum.
El diseño de EIP-6963 presenta posibles vulnerabilidades de seguridad. Al proporcionar una lista de todas las billeteras registradas, facilita la interacción entre dApps y usuarios, pero también podría ser mal utilizada por aplicaciones maliciosas. Las dApps maliciosas podrían leer la lista de billeteras instaladas por los usuarios, deduciendo sus actividades en la cadena de bloques o distribuciones de activos. Si el mecanismo de registro del servicio carece de una verificación estricta, las billeteras maliciosas podrían hacerse pasar por proveedores de servicios legítimos, engañando a los usuarios para que concedan acceso y roben activos. Por lo tanto, son necesarias medidas de seguridad adicionales (como el consentimiento del usuario y la validación del registro).
En cuanto a la experiencia del usuario, el soporte de múltiples billeteras de EIP-6963, si bien es una mejora significativa, también puede aumentar la complejidad. Por ejemplo, después de que un usuario instala múltiples billeteras, la dApp puede presentar demasiadas opciones, lo que confunde al usuario sobre qué billetera elegir. Además, algunas billeteras pueden tener nombres o logotipos que no son intuitivos, lo que aumenta la dificultad de identificación. Para los usuarios que necesitan cambiar de billetera con frecuencia, esta flexibilidad podría convertirse en una carga en lugar de un beneficio.
EIP-6963 introduce un enfoque basado en eventos para abordar problemas como la coexistencia de múltiples billeteras, conflictos de espacio de nombres y protección de la privacidad del usuario en aplicaciones Web3, mejorando significativamente la experiencia del usuario. Este mecanismo estandarizado permite a las dApps descubrir y conectar automáticamente múltiples billeteras sin necesidad de cambiar manualmente, evitando la competencia y conflictos entre billeteras, mejorando la fluidez y estabilidad de las conexiones. EIP-6963 también refuerza la seguridad al congelar los objetos del proveedor de billeteras para evitar manipulaciones, reduciendo los posibles riesgos de seguridad. En términos de privacidad, los usuarios pueden elegir si compartir su dirección de billetera, evitando filtraciones de identidad y huellas dactilares. EIP-6963 mantiene la compatibilidad con interfaces antiguas, garantizando una transición fluida para los sistemas existentes, al tiempo que simplifica el trabajo para los desarrolladores de dApps y mejora el soporte entre plataformas y dispositivos múltiples. En general, EIP-6963 mejora la interoperabilidad, la seguridad y la protección de la privacidad en Web3 y brinda a los desarrolladores herramientas más eficientes, fomentando el desarrollo adicional del ecosistema Web3.
Partilhar
En el ecosistema de blockchain, las billeteras de extensión del navegador son aplicaciones de billetera que existen en forma de complementos del navegador. Permiten a los usuarios interactuar de manera conveniente con cuentas de blockchain directamente dentro de aplicaciones descentralizadas (dApps), como enviar transacciones, firmar mensajes o interactuar con contratos inteligentes. El ejemplo más típico es MetaMask, que casi se ha convertido en una herramienta estándar para usar dApps en el ecosistema de Ethereum. A diferencia de las aplicaciones tradicionales, las billeteras de extensión del navegador están integradas en el entorno del navegador. Este método simplifica el proceso de interacción del usuario con la blockchain y elimina las barreras técnicas de operaciones de nodos complejas o gestión de claves privadas. Los usuarios solo necesitan instalar la extensión para comenzar rápidamente a usar la red blockchain.
En este contexto, un "proveedor de servicios" se refiere a la tecnología subyacente o la interfaz que respalda estas funciones de billetera. Por ejemplo, las billeteras se comunican con los nodos de la cadena de bloques a través del protocolo JSON-RPC de Ethereum, mientras que el proveedor de servicios ofrece la interfaz RPC correspondiente para permitir que la billetera maneje de forma segura las interacciones en cadena.
Imagina que quieres usar un exchange descentralizado (DEX) o un mercado de tokens no fungibles (NFT). Abres el sitio web de la dApp, emocionado por empezar a interactuar. Sin embargo, surge un problema: tu navegador tiene instaladas múltiples extensiones de billetera, como MetaMask, Coinbase Wallet y Brave Wallet, pero la dApp no logra identificar correctamente qué billetera estás utilizando en ese momento e incluso muestra un mensaje de error: 'No se detectó ninguna billetera, por favor instala una extensión de billetera'. Intentas refrescar la página y reiniciar el navegador, pero el problema persiste. Este escenario común destaca un problema práctico: los mecanismos de identificación e interacción de las extensiones de billetera del navegador son inadecuados. A medida que surgen más extensiones de billetera y proveedores de servicios, la experiencia del usuario se vuelve más complicada y confusa.
Para abordar los problemas de interacción entre las billeteras y las dApps, la comunidad introdujo EIP-1193 (API del Proveedor de JavaScript de Ethereum), un estándar universal que define cómo las dApps pueden comunicarse con las billeteras a través del entorno del navegador. La idea principal de EIP-1193 es manejar las funciones de la cadena de bloques proporcionadas por la billetera a través de una interfaz estandarizada. Por ejemplo, una dApp se comunica con la billetera a través del objeto window.ethereum, enviando solicitudes o recibiendo eventos de la cadena de bloques.
Aunque EIP-1193 aborda parcialmente los problemas de compatibilidad entre billeteras y dApps, aún tiene algunas limitaciones obvias:
Para resolver este problema, la comunidad propuso EIP-6963 (Estándar de Descubrimiento de Billetera de Extensión del Navegador), un plan de mejora para las billeteras de extensión del navegador destinado a optimizar los mecanismos de descubrimiento e interacción de la billetera. La solución tiene como objetivo reducir la barrera de entrada para nuevos proveedores de billeteras, promover una competencia más justa y mejorar la experiencia del usuario en la red Ethereum. Específicamente, introduce un conjunto de eventos de ventana y proporciona un protocolo de comunicación bidireccional, permitiendo que las bibliotecas de Ethereum y los scripts inyectados por las extensiones del navegador interactúen. Esto permitirá a los usuarios seleccionar su billetera preferida según sus necesidades, mejorando la experiencia general.
La inversa de DNS (RDNS) garantiza la estabilidad de los identificadores del proveedor de billeteras mientras previene conflictos de espacio de nombres. El EIP-6963 enfatiza las reglas que las convenciones RDNS deben seguir, como los formatos de dominio válidos y las partes del dominio controladas por el proveedor. También destaca que las dApps no deben depender del valor de RDNS para la detección de funciones para evitar la posibilidad de incentivos falsificados o maliciosos. La interfaz ProviderDetail de EIP-6963 proporciona a las dApps metadatos del proveedor de billeteras, lo que ayuda en la interacción con la billetera.
El EIP6963ProviderDetail es una interfaz utilizada para declarar y describir información del proveedor de billetera. Al incluir propiedades como info (metadatos de billetera) y provider (interfaz de proveedor de billetera), permite a las dApps obtener información detallada sobre las billeteras e interactuar con ellas a través de interfaces estandarizadas. Esta interfaz sirve como base para lograr compatibilidad e interoperabilidad entre aplicaciones descentralizadas y diversas billeteras.
El mecanismo de eventos garantiza que las dApps y las billeteras puedan descubrir e interactuar entre sí sin depender de un orden de ejecución fijo. Esto permite que el descubrimiento y la interacción entre dApps y billeteras no se vean afectados por el orden de ejecución, evitando así conflictos y errores.
AnunciarEventoProveedorEIP6963: Este evento es utilizado por billeteras para anunciar su presencia. Contiene información sobre la billetera (DetalleProveedorEIP6963) y la interfaz de la billetera (ProveedorEIP1193). La propiedad de detalle de este evento contiene los metadatos congelados de la billetera (usando Object.freeze()) para garantizar la inmutabilidad.
Evento EIP6963RequestProviderEvent: Este evento es utilizado por dApps para solicitar un proveedor de billetera. La dApp utiliza este evento para notificar a la billetera que está lista y solicita interacción.
Debido al orden de ejecución indeterminado del código de dApp y billetera, pueden surgir condiciones de carrera. El mecanismo de evento está diseñado específicamente para garantizar que las dApps y billeteras puedan manejar correctamente los eventos cuando se descubren mutuamente. Una billetera puede emitir primero el evento de anuncio, mientras que la dApp puede no estar lista para escucharlo hasta más tarde. Para evitar errores, la billetera volverá a activar el evento de anuncio después del inicial, asegurando que la dApp lo reciba de manera oportuna.
Las dApps deben escuchar el evento EIP6963AnnounceProviderEvent y no deben eliminar el escuchador de eventos durante la carga de la página. Esto garantiza que la dApp pueda escuchar y responder continuamente al evento de anuncio de la billetera durante su ciclo de vida. Después de manejar el evento de anuncio, la dApp debe desencadenar el evento EIP6963RequestProviderEvent para solicitar una mayor interacción con la billetera.
Las dApps pueden almacenar múltiples objetos EIP6963ProviderDetail para varias billeteras, lo que permite a los usuarios elegir entre diferentes billeteras para interactuar dentro de la dApp. Esto proporciona una mayor flexibilidad a los usuarios, permitiéndoles cambiar de billetera sin necesidad de recargar la página.
Este diseño logra un descubrimiento e interacción perfectos entre dApps y billeteras a través de EIP6963AnnounceProviderEvent y EIP6963RequestProviderEvent. Al utilizar escuchas de eventos y desencadenadores de eventos, las dApps y las billeteras pueden coordinar sus acciones a pesar del orden de ejecución indeterminado, evitar condiciones de carrera y garantizar un comportamiento estable. Además, las dApps pueden cambiar de billetera según las preferencias del usuario, mejorando la experiencia del usuario y la interoperabilidad de la billetera.
Este EIP no requiere reemplazar window.ethereum, lo que significa que no romperá directamente las aplicaciones existentes que no pueden actualizarse para usar este método de descubrimiento de billetera. Sin embargo, se recomienda encarecidamente que las dApps implementen este EIP para asegurarse de que puedan descubrir varios proveedores de billeteras y que deshabiliten el uso de window.ethereum, a menos que se utilice como método de respaldo cuando falla el descubrimiento. De manera similar, los proveedores de billeteras deben mantener la compatibilidad con window.ethereum para garantizar la compatibilidad con las dApps que no implementan este EIP. Para evitar problemas de conflictos de nombres anteriores, se recomienda que las billeteras inyecten su objeto proveedor en un espacio de nombres de billetera específico y luego proxy el objeto al espacio de nombres de window.ethereum.
Las extensiones del navegador, especialmente las extensiones de billetera, tienen la capacidad de modificar el contenido de la página y los objetos proveedores, lo cual es una característica central de su diseño. Los objetos proveedores de varias billeteras se consideran interfaces altamente confiables para transmitir datos de transacción. Para evitar modificaciones no deseadas de la interacción entre la dApp y la billetera por parte de la página u otras extensiones, la mejor práctica es congelar el objeto EIP1193Provider usando Object.freeze() antes de que la billetera despache el evento eip6963:announceProvider. Esto asegura que el objeto no se pueda modificar. Sin embargo, en algunos casos, la compatibilidad web puede requerir la modificación de este objeto. En tales casos, los implementadores de billeteras necesitan encontrar un equilibrio entre la seguridad y la compatibilidad web.
Las dApps deben detectar activamente si las propiedades o funciones del objeto proveedor de billetera han sido manipuladas para evitar la falsificación o alteración de otras billeteras. Una forma de detectar la falsificación es comprobando si la propiedad uuid en los dos objetos EIP6963ProviderInfo es consistente. Las dApps y sus bibliotecas de descubrimiento deben considerar otros posibles métodos de manipulación y tomar medidas protectoras adicionales para prevenir dicho comportamiento, garantizando la seguridad del usuario.
El uso de imágenes SVG puede provocar ataques de scripting entre sitios (XSS), ya que los SVG pueden contener código JavaScript. Este código se ejecuta en el contexto de la página y potencialmente podría modificar el contenido de la página o afectar otras billeteras. Por lo tanto, al representar iconos, las dApps necesitan considerar cómo manejar dichos riesgos de seguridad para prevenir que se utilicen imágenes maliciosas como técnicas de obfuscación, ocultando así modificaciones maliciosas en la página o billetera.
Una ventaja del mecanismo de bucle de eventos concurrentes utilizado en este diseño es que tanto la dApp como la billetera pueden iniciar el proceso para anunciar el proveedor. Por lo tanto, los implementadores de billeteras pueden elegir si anunciarse a todas las páginas o tomar otras medidas para reducir la probabilidad de que los usuarios sean identificados mediante el objeto window.ethereum inyectado. Una posible alternativa es que la billetera retrase la inyección del objeto proveedor hasta que la dApp anuncie el evento eip6963:requestProvider. En este punto, la billetera puede iniciar un flujo de consentimiento de interfaz de usuario, preguntando al usuario si está dispuesto a compartir su dirección de billetera. Este enfoque permite a la billetera habilitar una función de “conexión privada”. Sin embargo, al seguir este enfoque, la billetera también debe considerar cómo garantizar la compatibilidad hacia atrás con las dApps que no admiten este EIP.
EIP-6963, propuesto en mayo de 2023 como un nuevo estándar de Ethereum y aprobado en octubre del mismo año, tiene como objetivo abordar la falta de estándares claramente definidos como window.ethereum. El estándar introduce un mecanismo de descubrimiento de proveedores de inyección múltiple, permitiendo a las dApps descubrir y conectarse de manera confiable a todas las billeteras instaladas en el navegador del usuario. Esto supera las limitaciones y conflictos presentados por los métodos tradicionales. En comparación con el enfoque tradicional de window.ethereum, EIP-6963 simplifica el proceso de descubrimiento de billeteras, admitiendo la coexistencia de múltiples extensiones de billetera en el mismo navegador. Esta innovación mejora en gran medida la interoperabilidad del ecosistema de Ethereum y mejora la experiencia del usuario.
EIP-6963 no es solo una mejora funcional; también mejora la reconocibilidad de las billeteras y la experiencia del usuario al permitir que las billeteras inyecten información como nombre, logotipo, UUID y DNS inverso (RDNS). Las dApps pueden mostrar esta información, lo que permite a los usuarios comprender claramente con qué billetera están interactuando, evitando así confusiones y malas operaciones. Esto resulta en una interfaz más clara, confiable y amigable para el usuario. De esta manera, EIP-6963 proporciona a los usuarios una experiencia más fluida, reduce disputas potenciales y dificultades operativas innecesarias, al tiempo que contribuye positivamente al ecosistema general de Ethereum.
El diseño de EIP-6963 presenta posibles vulnerabilidades de seguridad. Al proporcionar una lista de todas las billeteras registradas, facilita la interacción entre dApps y usuarios, pero también podría ser mal utilizada por aplicaciones maliciosas. Las dApps maliciosas podrían leer la lista de billeteras instaladas por los usuarios, deduciendo sus actividades en la cadena de bloques o distribuciones de activos. Si el mecanismo de registro del servicio carece de una verificación estricta, las billeteras maliciosas podrían hacerse pasar por proveedores de servicios legítimos, engañando a los usuarios para que concedan acceso y roben activos. Por lo tanto, son necesarias medidas de seguridad adicionales (como el consentimiento del usuario y la validación del registro).
En cuanto a la experiencia del usuario, el soporte de múltiples billeteras de EIP-6963, si bien es una mejora significativa, también puede aumentar la complejidad. Por ejemplo, después de que un usuario instala múltiples billeteras, la dApp puede presentar demasiadas opciones, lo que confunde al usuario sobre qué billetera elegir. Además, algunas billeteras pueden tener nombres o logotipos que no son intuitivos, lo que aumenta la dificultad de identificación. Para los usuarios que necesitan cambiar de billetera con frecuencia, esta flexibilidad podría convertirse en una carga en lugar de un beneficio.
EIP-6963 introduce un enfoque basado en eventos para abordar problemas como la coexistencia de múltiples billeteras, conflictos de espacio de nombres y protección de la privacidad del usuario en aplicaciones Web3, mejorando significativamente la experiencia del usuario. Este mecanismo estandarizado permite a las dApps descubrir y conectar automáticamente múltiples billeteras sin necesidad de cambiar manualmente, evitando la competencia y conflictos entre billeteras, mejorando la fluidez y estabilidad de las conexiones. EIP-6963 también refuerza la seguridad al congelar los objetos del proveedor de billeteras para evitar manipulaciones, reduciendo los posibles riesgos de seguridad. En términos de privacidad, los usuarios pueden elegir si compartir su dirección de billetera, evitando filtraciones de identidad y huellas dactilares. EIP-6963 mantiene la compatibilidad con interfaces antiguas, garantizando una transición fluida para los sistemas existentes, al tiempo que simplifica el trabajo para los desarrolladores de dApps y mejora el soporte entre plataformas y dispositivos múltiples. En general, EIP-6963 mejora la interoperabilidad, la seguridad y la protección de la privacidad en Web3 y brinda a los desarrolladores herramientas más eficientes, fomentando el desarrollo adicional del ecosistema Web3.