La importancia de las billeteras componibles

Una vez expliqué la componibilidad del producto de las aplicaciones centralizadas (dApps) en el pasado. Por supuesto, usé un diagrama apilado muy simple: de hecho, hay dos niveles que omití, a saber, la billetera y el SDK; agregue una capa sobre "cadenas ": En este artículo voy a hablar sobre por qué esta complejidad adicional conduce a un cambio de perspectiva: las billeteras componibles tendrán un impacto cada vez más importante tanto en los usuarios como en los desarrolladores. En términos generales, cuando se alcanza la "última milla" del desarrollo del producto, es decir, cuando el equipo de desarrollo decide conectar tantas billeteras como sea posible, la gente pensará en las billeteras (suponiendo que el equipo sea responsable de ambos productos). también responsable de la interfaz). Esto no es un gran problema en este momento, ya que la mayoría de las dApps son simples en términos de interacción con el usuario (es decir, autorización + depósito, subasta/compra e intercambio). No hay mucho que gestionar o representar en el antes/después de la interacción. Pero nuestra ecología se volverá más complicada, entonces, ¿qué debemos hacer entonces? En el futuro previsible, todos administraremos nuestras propias identidades digitales en forma de tokens, como habilidades, puntajes de crédito, círculos sociales, etc. Esto generará un paso de interacción adicional antes de acceder a los protocolos estándar que usamos hoy en día, para administrar relaciones de red y de usuario más complejas, y el mercado correspondiente. Pensando en este prospecto, nos preguntamos: ¿Es razonable que cada producto gestione por sí mismo un prospecto específico? La forma de hacerlo en la era de la Web 2.0 es crear otro mercado/sitio web de aplicaciones, pero no creo que me gustaría tener otro sitio web para realizar un seguimiento de cómo administro mi identidad y las redes que uso. En mi opinión, este tipo de cosas privadas deben hacerse en la capa de la billetera, porque en este entorno, la autonomía personal y la privacidad son lo primero. Si bien no me importa saltar a diferentes sitios web para usar diferentes protocolos, tampoco quiero usar múltiples billeteras para administrar diferentes partes de mis interacciones en cadena. Eso es estúpido, y cada extra es un riesgo de seguridad. Pero si solo uso un tipo de billetera, entonces me ato al riesgo inherente del equipo de desarrollo detrás de esa billetera, sin mencionar que siempre habrá nuevas características que aún no han desarrollado. Recuerde, ya estamos en un mundo en rápida evolución donde ningún equipo puede ser el maestro de todo. Es por eso que necesitamos componibilidad de billetera. Aunque quiero saltar directamente, no he cubierto de qué partes está hecha una billetera. Ya tenemos el término "bloques de construcción de moneda" cuando hablamos de DeFi y muchas dApps de Ethereum; por lo tanto, llamaré a los módulos de compatibilidad de la billetera "legos de acceso". Cada uno de los cuatro niveles debe permitir a los usuarios elegir productos de manera flexible, y cada nivel debe proporcionar componentes básicos personalizados por parte de los proveedores de productos. Hay mucho en lo que profundizar aquí, así que echemos un vistazo rápido a la historia de las billeteras de criptomonedas para comprender mejor estos componentes básicos y cómo surgieron los servicios de billetera avanzada que usamos hoy. La primera billetera Ethereum se inspiró en la billetera Bitcoin Qt, creada por el equipo de Mist. Gemini Singapur lanzó 20 tipos de tokens, incluidos YFI, UNI y otros tokens DeFi: según las noticias oficiales, Gemini lanzó 20 tipos de transacciones de tokens para usuarios de Singapur, incluidos BAL, CRV, REN, SNX, UMA, UNI, YFI y otros DeFi fichas moneda. [2021/1/26 13:31:49] Fuente de la imagen La billetera Mist se parece mucho a Qt, es un software que debe descargarse y luego se pueden exportar los datos de la transacción, y también admite la sincronización de bloques/exploración de bloques: Esta billetera es en realidad, quiero empaquetar todo lo que un nodo Ethereum puede hacer en una pieza de software; luego se deben instalar muchas dependencias y la experiencia general del usuario no es buena. Para 2016, surgió MetaMask, una de las primeras billeteras basadas en navegador. Desde entonces, dApp se puede desacoplar de la billetera y solo necesita integrarse en el método de conexión de la billetera. Esto se vuelve muy importante a medida que crece el ecosistema, ya que era (y sigue siendo) difícil para un solo equipo rastrear el progreso de todos los EIP y tokens/protocolos desarrollados. Me gustaría señalar que, si bien esto aumenta la componibilidad de los productos dApp, aún no es la integración del contrato inteligente dentro de la billetera a la que se hace referencia en el "Diagrama de bloques de creación de canales" anterior. Esta parte no cambió hasta que aparecieron nuevos métodos de integración como WalletConnect. Ejemplo integrado de conexión de billetera De esta manera, se elimina parte de la responsabilidad y la carga de la billetera, y su enfoque ahora se convierte en la creación de transacciones, la firma y el mantenimiento de la conexión a la cadena de bloques. No quiero entrar en detalles, pero la construcción de la transacción significa que algunos parámetros de la transacción se reciben de la dApp y otros parámetros se mantienen completamente bajo el control de la billetera. Esto nos lleva a las llamadas RPC disponibles para las billeteras (también llamadas "proveedores"), definidas por primera vez por EIP-1193. dApp puede enviar algunos parámetros, como la dirección de destino, los datos, el límite/precio de gas y el valor a la billetera, pero no puede controlar la identificación de la cadena, la dirección del remitente, el nonce y otros parámetros relacionados con la seguridad de la billetera. Con este nuevo tipo de billetera, tenemos dos experiencias de usuario más complicadas: es difícil recordar la dirección de otros usuarios/amigos, no es segura y es propensa a errores humanos El código de bytes adjunto a la transacción es ilegible Sí, a menos que esté muy familiarizado con los selectores de funciones y el hash de datos/argumentos. Si no tiene un ABI para su contrato, está de enhorabuena. Para abordar el primer punto, se lanzó ENS en 2016/2017 junto con EIP-137, que se convirtió en nuestro primer componente social. Ahora, todos pueden usar el nombre de dominio de un sitio web para representar su dirección de Ethereum (como vitalik.eth) y usarlo en mensajes/transferencias para evitar ingresar direcciones largas. Esto es solo una parte de la capa de contrato inteligente social; el resto requiere más esfuerzo para desacoplar/habilitar la componibilidad. Con respecto al segundo punto, Parity ha creado un "registro de métodos" que los usuarios utilizan ampliamente para brindar información legible por humanos en la interfaz de firma de la billetera. EIP-712 ha jugado un papel importante aquí, aunque solo recientemente ha ganado más atención. Sin embargo, incluso con estas configuraciones, es difícil garantizar que su navegador no haya sido pirateado o engañado para mostrar transacciones/información falsa. Este es uno de los mayores problemas con el uso de una billetera caliente (es decir, un servicio de billetera que siempre está conectado a Internet y no está aislado del resto de su entorno informático). Liu Changyong: La apertura y la no subjetividad de POW son la base para la supervivencia a largo plazo de los sistemas descentralizados: Liu Changyong, Ph. El juicio de los pros y los contras de POW es correcto. Insisto en elegir POW, principalmente porque valoro más la apertura y la no subjetividad de POW. A saber: si no crees en las criptomonedas, también puedes participar en la minería para ganar dinero en cualquier momento; la ecología es más resistente a la influencia de tendencias culturales y políticas subjetivas. Estos dos puntos son la base para la supervivencia a largo plazo de los sistemas descentralizados. [2020/11/6 11:53:04] Una solución común es una billetera de hardware, iniciada por Ledger, que comenzó en 2014. MetaMask agregó soporte de billetera de hardware el primer día de 2018, desvinculando oficialmente la capa de seguridad y la capa de transacción/capa de conexión. Volveremos a esto más adelante, porque Ledger es excelente como una billetera de almacenamiento en frío, pero algunos productos nuevos también han mejorado mucho. Directamente arriba hay una billetera Ledger Mientras tanto, vimos que muchos protocolos complejos comenzaron a despegar en el mundo DeFi en el verano de 2020 (la mayoría de los cuales se desarrollaron durante más de 2-3 años). Esto nos da más y más tokens, y se vuelve cada vez más importante aprender a administrar la seguridad. Para ayudar a todos a mantenerse al día con el progreso del círculo, se creó un nuevo punto final de RPC que permite a las dApps agregar variedades a la lista de tokens rastreados por sus billeteras. Se crearon más herramientas para la gestión de activos, como las bóvedas Argent y las cajas fuertes multisig de Gnosis (también creo que estos dos productos están relacionados con la capa social, porque tienen mecanismos multiusuario y mecanismos DAO). La gente también creó un estándar de "conexión autorizada" (EIP-2255) para compartir datos de dApp para evitar el acceso malicioso a las billeteras. Los administradores de activos/agregadores de activos, los analizadores, también están desvinculados de la billetera debido a Zerion y Zapper (volveremos a explicar estos dos productos en el próximo capítulo). Las billeteras móviles también han experimentado un crecimiento desde 2019. Rainbow wallet es uno de los mejores ejemplos, su experiencia de usuario está muy bien diseñada. Pero cuando se trata de una integración perfecta, apenas están comenzando. La mayoría de las otras billeteras móviles (como MetaMask Mobile y Coinbase Wallet) han probado y desarrollado un navegador dApp dentro de la aplicación, basándose en enlaces profundos en lugar de integración directa. Estos enlaces profundos no pueden brindar una buena experiencia de usuario, pero hay tantos productos desarrollados en Ethereum que el equipo de la billetera no puede diseñar una interfaz unificada que pueda interactuar con todos los productos. Suponiendo que cada equipo de aplicación de billetera se optimiza para un escenario de aplicación (mensajes, NFT/mercado, DeFi, etc.), entonces, mi riesgo de seguridad es proporcional a la cantidad de billeteras que uso. Tal vez todos sean mínimos porque los módulos de seguridad están completamente desacoplados, pero debido a que el mercado se ha fragmentado, los desarrolladores deben priorizar el acceso a diferentes sistemas. El equipo de Rainbow Wallet originalmente quería ser un agregador/administrador de billeteras (basado en un repositorio de GitHub inicial que comenzaron a construir en 2019), así que creo que lo han pensado. En otras palabras, podemos ver que la interfaz del contrato inteligente ya está semidesacoplada, pero esta integración no se puede combinar libremente, porque el equipo de la billetera es el cuello de botella. En otras palabras, todas las dApps se pueden enviar a una billetera para su uso, pero una billetera no garantiza que todas las dApps las admitan. Ahora que hemos entendido más o menos todas las capas de una billetera, volvamos a los componentes básicos del canal. Estos componentes básicos y el siguiente análisis se basan en parte en mi propia creencia: avanzaremos hacia el uso de dApp directamente en productos de billetera en el futuro, como el intercambio de moneda proporcionado por MetaMask y la función de visualización de Rainbow. Estos análisis son el resumen de mi experiencia personal y varias semanas de trabajo de investigación, es muy posible que haya confundido la línea de tiempo de algunos proyectos. Si hay algún error u omisión, comuníquese conmigo, puedo editar el artículo y hacer las correcciones/suplementos necesarios. Con un poco más de comprensión de las billeteras Ethereum, podemos hablar sobre lo que quiero decir con "acceso". "Acceso" aquí generalmente representa el plan del usuario para fondos y acuerdos, y también significa que el acuerdo (a modo de permiso) accede a los usuarios y los datos que devuelven. Con los componentes básicos del canal, podemos imaginar cinco propiedades clave que nos ayuden a definir mejor los requisitos básicos de componibilidad de la billetera: La seguridad se puede desacoplar de la interfaz de usuario y colocarse en cualquier solución de hardware o software sin sacrificar las funciones de personalización; los usuarios pueden acceder a cualquier aplicación sin preocuparse por el reemplazo y el tiempo de integración; los protocolos pueden acceder a los usuarios sin preocuparse por quedar obsoletos y sin necesidad de empujar manualmente las billeteras para integrar sus propios productos. Nadie puede controlar todo el mercado de integración No es necesario sacrificar la experiencia del usuario y del desarrollador uno por uno:) Creo que las conexiones de servicio de billetera de hardware se volverán cada vez más estándar, y esto es cierto para casi todas las billeteras que he visto, ya sea que el método de conexión sea una interfaz USB, una conexión inalámbrica o una conexión bluetooth. Por lo tanto, el desacoplamiento generalmente no es el problema; más bien, el problema está en la billetera de hardware en sí. El almacenamiento, la generación y la recuperación mnemotécnicos son temas que vale la pena leer, pero son solo una parte de las billeteras de hardware cuando todos comenzamos a usar "almacenamiento en frío" puro. La ABI del contrato, la firma del mensaje decodificado y la restricción/flexibilidad de la transacción brindan espacio de personalización (y legibilidad) al usuario, y mencioné su importancia al presentar cada capa anterior. Un buen ejemplo de producto es Lattice1 del equipo de GridPlus; esta billetera de hardware debe usarse con una SafeCard especial, y la dirección se puede cambiar usando la SafeCard. El hardware de la billetera tiene un entorno de firmware de 64 GB y puede importar el ABI de cualquier contrato para ayudar a decodificar los datos de la transacción que está firmando. Desde https://wallet.gridplus.io/, enseña a los usuarios a administrar Lattice1. Podría decirse que este enfoque es más seguro que los "registros de métodos" (especialmente cuando el propietario del contrato inteligente no ha registrado su contrato). Creo que este tipo de método de integración será cada vez más importante, porque con su billetera El valor y la identidad/reputación del bono aumentará día a día. Los atributos segundo, tercero y cuarto se reducen a un solo concepto: crear un mercado de dApps integradas para la billetera que usa. En cierto sentido, la "billetera" principal aquí es una plataforma a la que se pueden conectar todos los módulos de seguridad y las integraciones. Casi siempre la capa de "transacciones y conexiones". Creo que las instantáneas de MetaMask son un paso en la dirección correcta: todos los desarrolladores de dApp pueden acceder a la interfaz de usuario de la billetera MetaMask existente, solo necesitan desarrollar su propia interfaz y método de integración; y los usuarios pueden elegir la combinación de estas piezas por sí mismos, formando así un mercado. dentro de la billetera. Si me gusta un determinado conjunto de productos en los que los usuarios invierten, marcan o socializan, puedo obtener el producto del equipo de dApp y usarlo de forma privada en mi billetera. El equipo de la billetera tampoco necesita desarrollar soporte manualmente para el próximo ENS, BrightID o token de prueba, ni necesita servir docenas de nuevos protocolos DeFi que aparecen cada mes. Este mercado también es importante para las comunidades de nicho y los DAO, que pueden tener su propia lista de dApps/productos de uso común (o más probablemente desarrollar los suyos propios)

Tags：

OKX Exchange