Introducción: Si bien las billeteras AA han reducido significativamente las barreras de entrada de usuarios y han logrado pagos de gas e inicios de sesión de cuentas web2, los aspectos relacionados con la adopción masiva, como el inicio de sesión confidencial, las transacciones confidenciales, el AA omnichain y el protocolo de fusión de intenciones, aún requieren un mayor desarrollo sobre la base de AA.

Aunque vemos varias soluciones de optimización de UX, como la billetera MPC de ZenGo o billeteras de contratos inteligentes como Argent, que reducen efectivamente las barreras de los usuarios, solo abordan una parte de los problemas antes mencionados, sin cubrir completamente las preocupaciones generales de usabilidad del producto.

Claramente, la mayoría de las billeteras AA o productos similares aún no pueden respaldar la adopción generalizada de Web3. Por otro lado, desde la perspectiva del ecosistema, el lado del desarrollador es un aspecto crucial. Es poco probable que el atractivo para los usuarios habituales por sí solo, sin un impacto suficiente en el lado del desarrollador, logre la escalabilidad. La aparición de más soluciones de optimización de la experiencia del desarrollador indica la creciente importancia del lado del desarrollador en el ecosistema de productos.

Tomando Particle Network como ejemplo, profundizaremos en los desafíos actuales de UX a los que se enfrentan los productos Web3 y discutiremos cómo diseñar una solución técnica integral y específica. Este tipo de solución integrada puede ser una condición necesaria para la adopción masiva. Además, la estrategia empresarial BtoBtoC de Particle sirve como un enfoque digno de mención que muchos equipos de proyecto pueden encontrar beneficioso.

Desglose de la estructura del producto de partículas

Particle Network, con su enfoque principal en la reducción de las barreras de uso, adopta un enfoque de construcción de productos y desarrollo ecológico B2B2C, proporcionando una solución integral para la adopción generalizada de Web3. Sus módulos principales constan de tres componentes clave:

zkWaaS se refiere a la billetera como servicio de conocimiento cero. Los desarrolladores pueden integrar rápidamente módulos de billetera inteligente en sus dApps utilizando el SDK de Particle. La billetera es una billetera de contrato inteligente sin llave basada en la abstracción de cuentas, que permite pagos de gas y ofrece inicio de sesión confidencial OAuth al estilo Web2 y transacciones confidenciales.

Particle Chain: el esquema dedicado de abstracción de cuentas Omnichain diseñado para Particle tiene como objetivo abordar los desafíos de implementación, mantenimiento e invocación entre cadenas para billeteras de contratos inteligentes. También incluye el Token de Gas Unificado, lo que simplifica el uso de diferentes tokens de gas en transacciones multicadena.

Protocolo de fusión de intenciones: incluye un lenguaje específico de dominio (DSL) conciso, un marco de intenciones, una red de solucionadores de intenciones, etc., para construir un marco de interacción Web3 basado en la intención. Los usuarios declaran sus intenciones de transacción directamente en lugar de ejecutar cada operación específica, lo que los libera de las intrincadas consideraciones de ruta y reduce la necesidad de comprender la compleja infraestructura subyacente.

zkWaaS - Billetera como servicio de conocimiento cero

En cuanto a la billetera, Particle proporciona principalmente SDK para desarrolladores de dApp en forma de billetera como servicio (WaaS). El objetivo es permitir que los desarrolladores se integren en su marco integral de adopción masiva de Web3. Este enfoque BtoBtoC tiene varias ventajas tanto desde el punto de vista empresarial como del ecosistema:

El mercado de billeteras de consumo es altamente competitivo y las funcionalidades son cada vez más similares. Las billeteras de los consumidores ya no son el punto de entrada óptimo. Por otro lado, los desarrolladores de dApps prefieren integrar billeteras dentro de sus aplicaciones para mejorar la experiencia del usuario y proporcionar funciones más personalizables.

La adquisición de usuarios por parte del consumidor es costosa, pero la parte empresarial difiere. El crecimiento de usuarios de WaaS se debe principalmente a las dApps integradas con el SDK. Con un desarrollo empresarial eficaz y relaciones con los desarrolladores, el ecosistema puede expandirse orgánicamente.

Las carteras de consumo actuales se centran principalmente en las finanzas y los activos, lo que puede no representar los principales escenarios para el futuro de la Web3. Para lograr una adopción generalizada de la Web3, las características fundamentales como la identidad del usuario (cuentas) y las operaciones del usuario (inicio de transacciones) deben abstraerse como un servicio fundamental, dejando escenarios más ricos para que las dApps las manejen.

Históricamente, el punto de entrada de las dApps ha mostrado una estrecha relación entre las billeteras y las dApps. Aumentar la cuota de mercado de la billetera en el lado de la dApp es crucial. Esto es particularmente ventajoso para el modelo B2B2C.

Para construir una solución que satisfaga las necesidades de los usuarios, reduzca las barreras de entrada y facilite la integración de los desarrolladores, el zkWaaS de Particle sirve como un componente fundamental con tres características principales:

1. Inicio de sesión confidencial: Aprovechar los métodos tradicionales de inicio de sesión Web2, como la verificación OAuth de plataformas como Twitter, Google, WeChat, etc., en la billetera de contratos inteligentes. Esto permite a los usuarios liberarse por completo de las limitaciones de la gestión de claves privadas, entrando en Web3 de la manera más familiar y sencilla. Al mismo tiempo, la identidad del usuario se oculta mediante pruebas de conocimiento cero.

2. Transacciones confidenciales: Implementación de transferencias de privacidad punto a punto a través del mecanismo Smart Stealth Address, asegurando la privacidad universal en las transacciones. Además, el uso de Paymaster de ERC-4337 permite el uso sin gas de los activos para las direcciones inteligentes ocultas (patrocinio de gas).

3. Funcionalidad completa de billetera AA: El módulo de billetera de Particle cumple completamente con los requisitos fundamentales de ERC-4337. Incluye componentes esenciales como Bundler, EntryPoint, Paymaster, Smart Wallet Account y más, cubriendo todos los aspectos críticos del flujo de trabajo ERC-4337. Esta solución integral satisface eficazmente las demandas funcionales de las DApps o de los usuarios de billeteras inteligentes.

Inicio de sesión confidencial para billeteras on-chain basadas en cuentas Web2

La solución de inicio de sesión confidencial de Particle utiliza JSON Web Tokens (JWT), lo que permite la autenticación de identidad Web2 y las operaciones de billetera dentro del contrato inteligente.

JWT es una forma ampliamente utilizada de prueba de identidad en las aplicaciones tradicionales de Internet, emitida por el servidor al cliente. El cliente utiliza esta prueba para la autenticación de identidad en cada interacción con el servidor.

(Fuente: FlutterFlow Docs)

Hay varios campos clave en JWT que son la base para la verificación de identidad por parte del contrato:

·" iss" (Emisor) indica el emisor de JWT, es decir, el servidor, como Google, Twitter, etc.

·" aud" (Audiencia): Especifica el servicio o la aplicación para la que está destinado el JWT. Por ejemplo, al iniciar sesión en Medium usando Twitter, el JWT emitido por Twitter incluirá este campo que indica su aplicabilidad a Medium.

·" sub" (Asunto): Se refiere a la identidad del usuario que recibe el JWT, normalmente identificada por UID.

En la práctica, "iss" y "sub" generalmente permanecen constantes para evitar confusiones sustanciales entre los sistemas internos y las referencias externas. Por lo tanto, estos parámetros pueden ser utilizados por el contrato para determinar la identidad del usuario, eliminando la necesidad de que los usuarios generen y protejan claves privadas.

Correspondiente a JWT es el concepto de JSON Web Key (JWK), un conjunto de pares de claves en el servidor. Al emitir JWT, el servidor lo firma con la clave privada de JWK, mientras que la clave pública correspondiente se hace pública para que otros servicios verifiquen la firma.

Por ejemplo, cuando Medium usa Twitter para iniciar sesión, Medium validará el JWT utilizando el JWK público de Google para confirmar su autenticidad, es decir, que realmente fue emitido por Google. La verificación de JWT en el contrato también implicará el uso de JWK.

El proceso de la solución de inicio de sesión confidencial de Particle se muestra en el siguiente diagrama:

Omitiremos aquí el circuito específico de ZK, solo destacando algunos puntos clave en el proceso:

El contrato del verificador que valida la información de inicio de sesión solo percibirá una prueba ZK relacionada con la identidad del usuario JWT y un eph_pk. No puede adquirir directamente la clave pública de la billetera correspondiente o la información de JWT, lo que garantiza la privacidad del usuario y evita que entidades externas identifiquen al usuario de inicio de sesión a partir de los datos en la cadena.

eph_pk (par de claves efímeras) es un par de claves que se utiliza en una sola sesión y no es el par de claves público-privado de la billetera. Los usuarios no tienen que preocuparse por ello.

Este sistema admite la verificación fuera de la cadena y se puede utilizar para billeteras de contratos que emplean lógica como MPC (Multiparty Computation).

Como se trata de una solución de verificación de contratos basada realmente en los métodos tradicionales de inicio de sesión, los usuarios también pueden designar a otros contactos sociales como guardianes en casos extremos, como la desactivación de la cuenta Web2.

Transacciones confidenciales basadas en el intercambio de claves DH

Antes de hablar de las transacciones confidenciales de Particle, examinemos cómo lograr transacciones confidenciales para el destinatario dentro del sistema EVM existente, ocultando específicamente la dirección del destinatario.

Suponiendo que Alice es el remitente y Bob es el destinatario, ambas partes comparten algunos conocimientos comunes:

1. Bob genera una clave de gasto raíz (m) y una metadirección sigilosa (M). M puede ser generado por m, y su relación está representada por M = G * m, lo que indica una relación matemática en operaciones criptográficas.

2. Alice obtiene la meta-dirección sigilosa M de Bob a través de cualquier medio.

3. Alice genera una clave privada efímera (r) y utiliza el algoritmo generate_address(r, M) para crear una dirección sigilosa (A). Esta dirección sirve como una dirección sigilosa dedicada preparada para Bob, y Bob obtiene el control una vez que se reciben los activos.

4. Alice genera una clave pública efímera (R) basada en la clave privada efímera r y la envía al contrato de grabación de clave pública efímera (o a cualquier ubicación mutuamente acordada a la que Bob pueda acceder).

5. Bob escanea periódicamente el contrato de grabación de pubkey efímero, registrando cada pubkey efímero actualizado. Dado que el contrato de pubkey efímero es público y contiene claves relacionadas con transacciones de privacidad enviadas por otros, Bob no sabe cuál Alice envió para que lo viera.

6. Bob escanea cada registro actualizado y ejecuta generate_address(R, m) para calcular la dirección oculta. Si hay activos en esa dirección, significa que Alice los generó y autorizó para el control de Bob; de lo contrario, es irrelevante para Bob.

7. Bob ejecuta generate_spending_key(R, m) para generar la clave de gasto para esa dirección oculta, es decir, p = m + hash(A). A continuación, Bob puede controlar la dirección A generada por Alice.

El proceso descrito simplifica muchas operaciones matemáticas complejas. Todo el proceso de intercambio de información es similar a dos agentes secretos que escriben mensajes crípticos en un tablón de anuncios público, mensajes que solo pueden descifrarse entre sí. Aunque los métodos de generación y descifrado de estos mensajes son públicos, los datos cruciales necesarios para ambos agentes solo son conocidos por ellos. En consecuencia, incluso si los extraños entienden los métodos, el descifrado exitoso sigue siendo difícil de alcanzar.

Este proceso de intercambio es algo análogo al conocido método de intercambio de claves Diffie-Hellman. Sin revelar sus secretos (la clave de gasto raíz de Bob (m) y la clave privada efímera de Alice (r)), ambas partes pueden calcular un secreto compartido: la dirección sigilosa (A) mencionada anteriormente. Si no está familiarizado con el intercambio de DH, la comprensión metafórica se puede facilitar utilizando el siguiente diagrama.

Un paso añadido en comparación con DH es que, después de calcular el secreto compartido: dirección sigilosa (A), no se puede utilizar como clave privada directamente porque Alice también conoce A. Es necesario construir la clave de gasto (p = m + hash(A)) tratando A como una clave pública. Como se mencionó anteriormente, solo Bob conoce la tecla de gasto raíz (m), lo que convierte a Bob en el único controlador de esta dirección sigilosa.

Claramente, en este método de transferencia de privacidad, por cada nueva transacción recibida, los fondos fluirán a una nueva dirección EOA. El destinatario puede usar la clave de gasto raíz para calcular de forma iterativa la clave de gasto para cada dirección, experimentando para encontrar la que realmente está asociada con ellos.

Sin embargo, todavía hay un problema. Inicialmente, esta dirección sigilosa recién generada sigue siendo una cuenta EOA y puede carecer de ETH u otros tokens de gas. Bob no puede iniciar transacciones directamente y necesita usar el Paymaster de una billetera de contrato inteligente para el pago de gas para lograr transacciones confidenciales. Por lo tanto, se requieren algunas modificaciones para la dirección del destinatario:

Utilizando el método de cálculo de direcciones de la función CREATE2 durante la implementación del contrato, junto con los parámetros correspondientes (establecer la dirección oculta A como propietaria del contrato, etc.), calcule una dirección contrafactual. Se trata de una dirección de contrato calculada que aún no se ha implementado, actualmente una EOA.

Alice transfiere fondos directamente a esta dirección contrafactual. Cuando Bob quiere usarlo, crea directamente una billetera de contrato en esta dirección, lo que permite la invocación del servicio de pago de gas (este paso también puede ser manejado por Alice o la red Particle por adelantado).

Podemos referirnos a la dirección contrafactual antes mencionada como una dirección sigilosa inteligente. Bob utiliza de forma anónima los activos de esta dirección sigilosa inteligente a través del siguiente proceso:

· Deposite a Paymaster desde cualquiera de sus direcciones, y Paymaster le devolverá un comprobante de fondo (basado en ZK).

· Con el mecanismo AA, utilice cualquier otra dirección, que puede no tener saldo, para enviar UserOperation al nodo Bundler, invocando los activos bajo la dirección oculta mencionada. Bob solo necesita proporcionar una prueba de fondo a Paymaster usando una nueva dirección, y Paymaster paga al Bundler por el empaquetado de la transacción.

Este proceso es similar a la forma en que opera Tornado Cash. La prueba de fondo (basada en ZK) puede demostrar que se produjo una recarga en el conjunto de nodos hoja en el árbol de Merkle. Sin embargo, al gastar, nadie puede determinar qué fondos específicos del nodo hoja se consumieron, cortando así la conexión entre el consumidor y el cargador.

En resumen, Particle combina AA con direcciones sigilosas de manera inteligente, logrando transferencias confidenciales a través de billeteras sigilosas inteligentes.

Abstracción de cuentas de cadena de partículas y omnicadena

Particle Chain es una cadena POS diseñada para la abstracción de cuentas Omnichain. Teniendo en cuenta tanto el presente como el futuro, es poco probable que se produzca un dominio de una sola cadena. Mejorar la experiencia del usuario en un escenario multicadena es crucial.

Actualmente, el sistema de abstracción de cuentas ERC4337 puede encontrar ciertos problemas en una situación multicadena:

• Es posible que las direcciones de los mismos usuarios en diferentes cadenas no sean uniformes, dependiendo del diseño del contrato.
• La gestión de diferentes carteras de contratos de cadena requiere operaciones manuales en varias cadenas, como el cambio de administradores. En el peor de los casos, si los permisos de administrador se actualizan en una cadena, seguido de descartar el antiguo método de validación de administrador, se vuelve imposible realizar cambios en otras cadenas, lo que hace que la billetera sea inutilizable.
• El uso de diferentes cadenas requiere tener tokens de gas para cada cadena, o fondos prealmacenados en el Paymaster de cada cadena. Para los desarrolladores, esto puede ser problemático. Si quieren que los usuarios utilicen ciertas condiciones a coste cero o implementen otras funciones, deben desplegar sus Paymasters personalizados en cada cadena y prefinanciarlos.

La abstracción de cuentas Omnichain de Particle Chain aborda los puntos débiles anteriores:

• Establecer billeteras AA en Particle Chain.
• Utilice LayerZero y otros protocolos de cadena cruzada de puente de mensajes arbitrarios (AMB) para sincronizar varias operaciones, como crear, actualizar y cambiar permisos, con otras cadenas. Se puede entender como que las billeteras en otras cadenas son referencias a la billetera en esa cadena, con modificaciones en el cuerpo principal que se sincronizan con todas las billeteras.
• Garantice direcciones uniformes para las billeteras en cada cadena a través de un parámetro coherente Contrato de implementador.
• Las billeteras en diferentes cadenas también pueden llamarse entre sí a través de AMB, no necesariamente iniciadas desde Particle Chain.
• Emitir Token de Gas Unificado. El mecanismo Paymaster implementa ERC20 como tarifas de gas. Incluso en una cadena sin gas o fondos prealmacenados en Paymaster, las transacciones entre cadenas que consumen tokens de gas unificados pueden iniciarse en cadenas compatibles.

Además de los casos de uso mencionados anteriormente, la cadena de partículas también se puede utilizar para:

• La red descentralizada para las pruebas de zkWaaS y la generación de sal.
• Capas de incentivos para los Bundlers en diferentes cadenas, lo que ayuda a los Bundlers a lograr una mayor descentralización.
• Sirve como red de solucionadores para el protocolo de fusión de intenciones.

En la narrativa de Particle Chain, el token de gas unificado sirve como una propuesta de valor central para todo el ecosistema:

• La funcionalidad de pagar las tarifas de gas es una fuerte lógica de demanda y captura de valor validada repetidamente en el espacio de las criptomonedas.
• El Token de Gas Unificado abstrae el concepto de capas de gas de los ecosistemas de cadenas públicas existentes. Esta abstracción, sin Particle Chain y billeteras, no se puede lograr. Por lo tanto, el token de gas unificado representa una realización de valor para todo el ecosistema de partículas. Con la capa de gas, la interacción del usuario, el crecimiento y el valor del token nativo a través de diferentes cadenas están en una relación mutuamente beneficiosa con el token de gas unificado.
• El gas unificado también es uno de los factores impulsores para lograr Chainless. Para los usuarios, el uso de una moneda única simplifica enormemente el proceso de uso y la comprensión de los costos. En el futuro, incluso en un escenario multicadena, es posible que los usuarios no sean conscientes y no tengan que preocuparse por el funcionamiento de la infraestructura subyacente. De forma similar a cómo, actualmente en la Web2, interactuamos con los servidores sin importarnos la ubicación de los centros de datos, sus configuraciones o los lenguajes y bases de datos que utilizan.
• Los usuarios importados por dApps potencian directamente el token de gas unificado, ofreciendo una amplia gama de casos de uso.

Protocolo de fusión de intenciones

Normalmente, cuando se utilizan varias dApps, los usuarios deben tener en cuenta constantemente las rutas de uso:

• Si no hay liquidez en un DEX, es necesario verificar otro DEX.
• Elegir la dApp más adecuada dentro de la misma categoría para una transacción o tarea.
• Entender el concepto de "Aprobar" antes de poder utilizar muchas funcionalidades.
• Desempolvar billeteras, convertir múltiples cantidades de tokens pequeños en un token específico: un proceso tedioso.
• Completar varios pasos en diferentes aplicaciones para lograr un objetivo final. Por ejemplo, en los préstamos de alto apalancamiento: intercambio, staking, préstamo, obtención de tokens, luego swapping de nuevo, staking y préstamo.

El contenido anterior representa solo un vistazo al panorama actual de DeFi, y a medida que avanzamos hacia la era de la adopción generalizada de diversas dApps en Web3, la complejidad de las interacciones puede superar con creces nuestra imaginación.

Por lo tanto, reemplazar pasos operativos específicos con intenciones brinda una experiencia muy diferente para los usuarios. Las intenciones, en comparación con las operaciones, son similares a la programación declarativa frente a la programación funcional. Las declaraciones declarativas a menudo dan una sensación directa, requiriendo solo una declaración de lo que se debe hacer sin preocuparse por los detalles posteriores. Esto requiere varios niveles de instrucciones de programación funcional encapsuladas en las capas subyacentes.

Del mismo modo, el uso de intenciones requiere la compatibilidad de una serie de instalaciones. Examinemos todo el proceso:

1. Los usuarios envían sus intenciones, describiéndolas de alguna manera, como lenguaje natural, en forma de RFS (Request For Solver), enviadas a la red Solver. El solucionador es un intérprete de intenciones y solucionadores comunes como 1inch, un agregador, que busca el DEX óptimo para los usuarios. Sin embargo, estos solucionadores, en comparación con nuestra visión, pueden no ser lo suficientemente versátiles y potentes.

2. Varios solucionadores responden, compitiendo entre sí. Estas respuestas se escriben en el lenguaje DSL de intención, y luego el cliente las analiza en un formato que es fácil de entender para los usuarios. Estas respuestas incluyen restricciones de entrada y restricciones de salida, definiendo los límites de las entradas y salidas. Los usuarios también pueden especificar restricciones por sí mismos. Un ejemplo sencillo para entenderlo: cuando se utiliza Swap, se le pide al usuario la cantidad mínima que puede recibir después del intercambio, lo cual es una forma de restricción. Los usuarios eligen entre las respuestas proporcionadas por varios solucionadores.

3. Firma la intención.

4. El Solver especifica un ejecutor de contrato de ejecución específico y envía la intención al reactor del contrato de respuesta.

5. El Reactor recopila las entradas necesarias (como un activo específico) de la cuenta del usuario, envía la intención al Ejecutor y, después de llamar al contrato lógico correspondiente, devuelve el resultado de la transacción al Reactor. El reactor comprueba las restricciones y, si es correcto, devuelve la salida al usuario.

Podemos imaginar este proceso como si estuvieras explicando tus requisitos a ChatGPT. Independientemente de lo complejos que sean los requisitos, puede generar un resultado final para usted. Siempre que esté satisfecho con el resultado, puede usarlo directamente sin preocuparse por el proceso subyacente.

Conclusión

Particle Network ha propuesto una solución integral: a través de la forma integrada de zkWaaS, Particle Chain y Intent Fusion Protocol, logra el inicio de sesión de privacidad Web2 OAuth, las transacciones de privacidad, la abstracción de cuentas omnichain y un paradigma de transacciones basado en la intención. Cada característica aborda una parte de los puntos débiles en el uso de Web3. Estos avances y optimizaciones servirán de base para la futura adopción generalizada de productos y tecnologías Web3. En términos de ecosistema y modelos de negocio, adoptar el paradigma B2B2C, utilizar WaaS como punto de entrada para impulsar la escalabilidad y estandarización de toda la cadena de productos, coconstruir el ecosistema con los desarrolladores de dApps y crear conjuntamente un mundo Web3 de bajo umbral y alta experiencia para los usuarios.

Por supuesto, los diferentes proyectos tienen diferentes interpretaciones de la ruta de implementación para la adopción masiva de Web3. Además de examinar proyectos específicos, esperamos utilizar diferentes soluciones para destacar la comprensión de la fricción de incorporación a la que se enfrenta la Web3 actualmente, la contemplación de las necesidades y los puntos débiles de los usuarios, y las consideraciones para la conexión colectiva y el desarrollo de todo el ecosistema.

Renuncia:

1. Este artículo es una reimpresión de [极客 Web3], Todos los derechos de autor pertenecen al autor original [雾月,极客Web3]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.