Tomando Particle Network como ejemplo, la tecnología interpreta los problemas de experiencia de los productos Web3 actuales

Autor: Wuyue, Geek Web3

Introducción: Aunque la billetera AA ha reducido el umbral para los usuarios en gran medida e inicialmente realizó el pago de gas y el inicio de sesión de la cuenta web2, el diseño relacionado con la adopción masiva, como el inicio de sesión de privacidad: transacción privada, cuenta AA unificada de cadena completa y arquitectura dedicada a la intención, aún debe agregarse sobre la base de AA.

Aunque podemos ver muchas soluciones de optimización de UX, como billeteras MPC como ZenGo o billeteras de contratos inteligentes como Argent, que efectivamente reducen el umbral para los usuarios, solo resuelven algunos de los problemas anteriores y no cubren completamente la facilidad de uso del producto.

Obviamente, la mayoría de los monederos AA o productos similares aún no son capaces de soportar la adopción masiva de Web3. Por otro lado, desde un punto de vista ecológico, el lado del desarrollador es un nivel muy importante, que solo es atractivo para los usuarios comunes en términos de productos, pero es difícil formar una escala debido a su insuficiente influencia en el lado del desarrollador. ** La aparición de más y más soluciones de optimización de la experiencia de desarrollo ha demostrado la importancia del lado del desarrollador para el ecosistema de productos.

Tomaremos Particle Network como ejemplo para explicar en detalle los problemas de experiencia actual de los productos Web3, y cómo diseñar una solución técnica integral, que puede ser una condición necesaria para la adopción masiva. Al mismo tiempo, la estrategia de negocio BtoBtoC de Particle es una idea de la que muchas partes del proyecto necesitan aprender. **

Solución completa de la estructura del producto de partículas

Con el núcleo de resolver el umbral de uso, Particle Network propone un conjunto completo de soluciones para la adopción a gran escala de Web3 con la idea de la construcción de productos B2B2C y el desarrollo ecológico. Sus módulos principales son tres:

**zkWaaS, un servicio de billetera como servicio (WaaS) basado en pruebas de conocimiento cero. ** Los desarrolladores pueden integrar rápidamente el módulo de billetera inteligente en su propia dApp basada en el SDK proporcionado por Particle. La billetera es una billetera de contrato inteligente sin llave basada en la abstracción de cuentas, que no solo puede realizar escenarios básicos de AA, como el pago de gas, sino que también proporciona métodos de inicio de sesión de privacidad OAuth al estilo Web2 y transacciones privadas y otras funciones.

Particle Chain - Una solución de abstracción de cuentas de Omnichain dedicada a Particle, dedicada a resolver el despliegue, el mantenimiento y la invocación de carteras de contratos inteligentes entre cadenas. También hay un Token de Gas Unificado (Unified Gas Token) para resolver el problema de usar diferentes monedas de gas para transacciones multicadena.

** Intent Fusion Protocol, que incluye un lenguaje DSL (Domain Specific Language) conciso, Intent Framework, Intent Solver Network, etc., se utiliza para crear un conjunto de marcos de interacción Web3 basados en Intent. Los usuarios declaran directamente la intención de su transacción en lugar de realizar cada acción específica, lo que libera a los usuarios del engorroso pensamiento de ruta y reduce su comprensión de la compleja infraestructura subyacente.

zkWaaS – Billetera inteligente como servicio combinada con ZK

En el lado de la billetera, Particle proporciona principalmente SDK para desarrolladores de dApp en forma de WaaS (Smart Contract Wallet-as-a-Service), con el fin de permitir a los desarrolladores acceder a su marco completo de opciones masivas Web3. Esta solución BtoBtoC tiene varias ventajas desde el punto de vista empresarial y ecológico:

** La competencia de las billeteras C-end puras se ha vuelto candente, y las funciones son relativamente similares, y las billeteras C-end ya no son un buen punto de entrada. Por otro lado, los desarrolladores de dApps están cada vez más inclinados a crear billeteras en dApps para evitar la pérdida de experiencia cuando los usuarios necesitan cambiar de billetera al conectar billeteras y transacciones, y proporcionar funciones más personalizables.

** El costo de adquisición de clientes es alto en el lado C, pero es diferente en el lado B. **El crecimiento de los usuarios de WaaS está impulsado principalmente por las dApps integradas con los SDK. Siempre que la relación entre BD y los desarrolladores sea buena, todo el ecosistema puede expandirse en un estilo de “ciudad que rodea el campo”.

**En la actualidad, las billeteras C-end se centran principalmente en finanzas y activos, y es difícil para nosotros decir que este es el escenario principal de Web3 en el futuro. Para lograr realmente la adopción masiva de Web3, debe haber proyectos que abstraigan las características más básicas: la identidad del usuario (cuenta) y la operación del usuario (envío de transacciones/transacciones) como un servicio de bajo nivel, y entreguen los escenarios más ricos de la capa superior a la dApp.

Desde la entrada de conexión de dApp anterior, puede observar la estrecha relación de enlace entre la billetera y la dApp. ** Es muy importante aumentar la participación de mercado de las billeteras tanto como sea posible en el lado de las dApp. Esta es la primera prioridad para el modelo B2B2C. **

La creación de una WaaS que satisfaga las necesidades de los usuarios, reduzca la barrera de entrada y sea de fácil acceso para los desarrolladores es otro pilar del éxito de la solución. El zkWaaS de Particle tiene tres núcleos:

**1. Inicio de sesión de privacidad. ** Utilizando métodos tradicionales de inicio de sesión Web2 en billeteras de contratos, como Twitter, Google, inicio de sesión WeChat y otros métodos de verificación OAuth, los usuarios pueden deshacerse por completo de los grilletes de la gestión de claves privadas e ingresar a Web3 de la manera más familiar y sencilla. Al mismo tiempo, las pruebas de conocimiento cero se utilizan para ocultar las identidades de los usuarios.

2. Transacciones de privacidad. ** Implemente transferencias privadas universales peer-to-peer a través del mecanismo Smart Stealth Address, y use ERC4337 Paymaster para permitir que Stealth Address use activos (patrocinadores de gas) sin gas.

**3. Función completa de billetera AA. ** El módulo de billetera de Particle cumple completamente con los requisitos básicos de ERC-4337, incluidos Bundler, EntryPoint, Paymaster, Smart Wallet Account y otras partes importantes de los flujos de trabajo de ERC-4337, ventanilla única para cumplir con los requisitos funcionales de DAPP o usuarios para billeteras inteligentes.

Inicio de sesión de privacidad de billetera en cadena basado en cuentas web2

La solución de inicio de sesión privado de Particle hace uso de JWT (Json Web Token), que se puede utilizar para la autenticación de identidad Web2 y el funcionamiento de la billetera dentro del contrato.

JWT es un tipo de certificado de identidad emitido por el servidor al cliente que se usa ampliamente en la Internet tradicional, y el cliente confía en esta prueba para autenticarse cada vez que interactúa con el servidor.

Hay varios campos clave en el JWT que son la base para que el contrato verifique la identidad:

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

·" aud" (Audiencia) indica el servicio o la aplicación utilizada por el JWT, si inicia sesión en Medium con Twitter, este campo indicará que el JWT se aplica a Medium cuando Twitter emite el JWT.

·" sub" (Asunto) se refiere a la identidad del usuario que acepta el JWT, que generalmente está marcado por un UID.

En la práctica, la ISS y el submarino no cambiarán en la gran mayoría de los casos, de lo contrario traerá un gran lío de sistemas internos y referencias externas. Por lo tanto, estos parámetros pueden ser utilizados por el contrato para determinar la identidad del usuario,** de modo que el usuario no necesite generar y mantener la clave privada en absoluto. **

El concepto correspondiente a JWT es JWK (JSON Web Key), que es un conjunto de pares de claves en el lado del servidor. Cuando el servidor emite un JWT, firmará con la clave privada del JWK, y la clave pública correspondiente es pública y se utiliza para verificar su firma para otros servicios.

Por ejemplo, si inicias sesión en Twitter en Medium, Medium verificará el JWT con la clave pública de JWK que Google ha hecho pública para confirmar que el JWT es auténtico, es decir, que realmente fue emitido por Google. JWK también se utiliza para la validación de contratos de JWT.

El flujo de solución de inicio de sesión privado de Particle se muestra en la siguiente figura:

Entre ellos, aquí nos saltaremos el circuito específico de ZK. Enumere solo algunos de los puntos clave en el proceso:

** El contrato de verificación que verifica la información de inicio de sesión solo percibirá una prueba ZK relacionada con la identidad del usuario-JWT, así como un eph \ _pk inocuo, y no puede obtener directamente la clave pública de la billetera correspondiente o la información de JWT, para proteger la privacidad del usuario, y el mundo exterior no puede conocer la identidad de la persona de inicio de sesión a partir de los datos en cadena. **

Eph_pk (par de claves efímeras) es un par de claves que se usa en una sola sesión, no la clave pública o privada de la billetera, y al usuario no le importa.

Este sistema también se puede utilizar para la verificación fuera de la cadena y se puede utilizar para carteras de contratos que utilizan lógica como MPC.

Dado que se trata de un verdadero esquema de verificación de contratos basado en inicios de sesión tradicionales, los usuarios también pueden designar a otros contactos sociales como sus guardianes en caso de situaciones muy extremas, como la cancelación de la cuenta Web2.

Transacciones privadas basadas en el método de intercambio de claves DH

Antes de hablar de la solución de transacciones privadas de Particle, examinemos primero cómo lograr transacciones privadas al destinatario dentro del sistema EVM existente, es decir, ocultar la dirección del destinatario.

Supongamos que Alice es el emisor y Bob es el receptor, y tenemos algo de conocimiento común:

1. Bob genera la clave de gasto raíz m y la meta-dirección sigilosa M. M puede ser generado por m, y la relación entre los dos es M = G * m, lo que representa una relación matemática en operaciones criptográficas.

2. Alice obtiene la metadirección sigilosa M de Bob de cualquier manera.

3. Alice genera una clave privada temporal r y utiliza generate_address algorítmicos (r,M) para generar una dirección oculta A. **Esta dirección es la dirección sigilosa exclusiva de Bob, y Bob tiene el control de la dirección después de recibir los activos. **

4. A continuación, Alice genera una clave pública temporal R basada en la clave privada temporal r y la envía al contrato de registro de clave pública temporal (o a cualquier ubicación mutuamente acordada, sea cual sea el canal, siempre que Bob pueda obtenerla).

5. Bob debe escanear periódicamente el contrato de registro de clave pública temporal y registrar cada clave pública temporal actualizada. Dado que el contrato de clave pública efímera es público y contiene claves relacionadas con transacciones privadas enviadas por otros, Bob no sabe cuál le envió Alice.

6. Bob escanea cada registro actualizado y realiza generate_address (R,m) para calcular la dirección redactada. Si hay un activo en la dirección, es generado por Alice y autorizado para ser controlado por Bob, de lo contrario no tiene nada que ver con Bob.

7. Bob ejecuta el generate_spending_key(R,m) para generar la clave privada del consumidor para la dirección sigilosa, es decir, p = m + hash(A), y luego puede controlar la dirección A generada por Alice.

La descripción del proceso anterior en realidad simplifica muchas operaciones matemáticas complejas,** Todo el proceso de intercambio de inteligencia es como dos espías que escriben algunas palabras clave que solo pueden ser descifradas entre sí en un tablón de anuncios público,** Aunque los métodos de generación y descifrado de palabras clave son públicos, solo dos espías conocen los datos importantes necesarios en el medio, por lo que incluso si el mundo exterior conoce los métodos de generación y descifrado de palabras clave, aún no se pueden descifrar sin problemas.

Este proceso de intercambio es muy similar al conocido método de intercambio de claves Diffie-Hellman, en el que ambas partes pueden calcular el secreto compartido, la dirección oculta A anterior, sin revelar sus respectivos secretos (la clave privada del consumidor raíz de Bob, m, y la clave privada temporal de Alice, r). **Si no conoces el intercambio DH, puedes usar el siguiente diagrama de tinción para entenderlo metafóricamente.

Un paso adicional en comparación con DH es que después de que cada uno de ellos haya descubierto la dirección secreta compartida redactada A, no pueden usarla como clave privada, porque Alice también conoce A. Es necesario construir la clave privada del consumidor p = m + hash(A) y tratar A como una clave pública. Como se mencionó anteriormente, la clave privada del consumidor raíz m solo es conocida por Bob, por lo que Bob se convierte en el único controlador de la dirección oculta. **

Obviamente, con este método de transferencias privadas, cada vez que el destinatario recibe una nueva transacción, los fondos de esa transacción fluirán a una nueva dirección EOA. El receptor puede usar la clave privada de consumo raíz para calcular la clave privada de consumo de cada dirección por separado para ver cuál está realmente relacionada con él.

Pero ahora hay otro problema, esta dirección sigilosa recién generada sigue siendo una cuenta EOA al principio, es posible que no haya tokens de gas como ETH en ella, Bob no tiene forma de iniciar transacciones directamente, ** necesita usar la función Paymaster de la billetera de contrato inteligente para el pago de gas, con el fin de lograr transacciones privadas. **Por lo tanto, es necesario realizar algunos cambios en la dirección de recepción:

Calcule una dirección contrafactual utilizando el método de cálculo de direcciones en el método CREATE2 cuando se implementa el contrato, con los parámetros correspondientes (establecer la dirección oculta A como propietaria del contrato, etc.). Esta es una dirección de contrato calculada, pero el contrato aún no se ha implementado y, por el momento, sigue siendo EOA.

**Alice transferirá dinero directamente a la dirección contrafactual. ** Cuando Bob quiera usarlo, puede crear una billetera de contrato directamente en esta dirección, para que pueda llamar al servicio de pago de gas (este paso también lo puede hacer Alice o Particle network en su nombre).

Podemos llamar a la dirección contrafáctica anterior una dirección sigilosa inteligente. Bob utiliza el siguiente proceso para utilizar de forma anónima los recursos de la dirección de Smart Cloak:

Recargue Paymaster a través de cualquiera de sus propias direcciones, y Paymaster le devolverá un comprobante de fondos (ZK).

Con el mecanismo AA, envíe una UserOperation al nodo Bundler con cualquier otra dirección (no puede tener saldo) para llamar a los recursos en la dirección oculta anterior. Bob simplemente proporciona un comprobante de fondos a Paymaster con una nueva dirección, y Paymaster paga la transacción de empaquetado de Bundler.

En realidad, esto es similar a cómo funciona Tornado Cash, a través de la prueba de fondos (ZK), que puede demostrar que hubo una recarga en el conjunto de nodos hoja en el árbol de Merkle, y nadie puede saber qué nodo hoja se consumió cuando se gastó, para cortar la conexión entre el consumidor y el depositante.

En resumen, Particle combina AA y direcciones ocultas, y realiza inteligentemente transferencias privadas en forma de billeteras ocultas inteligentes.

Abstracción de la cuenta de cadena de partículas y cadena completa

Particle Chain es una cadena POS diseñada para la abstracción de cuentas Omnichain. Centrándonos en la situación actual y en el futuro, es imposible ser un mundo de una sola cadena, y es crucial mejorar la experiencia del usuario en un entorno de trabajo multicadena.

En la actualidad, ERC4337 sistema de abstracción de cuentas tendrá ciertos problemas en el caso de la multicadena:

La dirección de un mismo usuario en diferentes cadenas puede no ser uniforme, dependiendo del diseño del contrato.

Los usuarios deben repetir manualmente las operaciones de administración entre varias cadenas para administrar billeteras de contratos en diferentes cadenas, como cambiar de administrador. Peor aún, si los privilegios de administrador se actualizan en una cadena y luego se descarta el antiguo método de autenticación de administrador, la billetera no se puede cambiar en otras cadenas.

Para usar diferentes cadenas, debe tener monedas de gas en cada cadena o tener fondos predepositados en Paymaster en cada cadena. También hay una cierta cantidad de problemas para los desarrolladores, si quieren que los usuarios usen o implementen otras funciones a costo cero bajo ciertas condiciones, también deben implementar su propio Paymaster personalizado en cada cadena y depositar fondos en ella.

La abstracción de la cuenta de cadena completa de Particle Chain aborda los puntos débiles anteriores:

Construya una billetera AA en Particle Chain.

A través del protocolo de cadena cruzada AMB (Puente de mensajes arbitrarios) como LayerZero, varias operaciones, como la nueva creación, la actualización, los permisos de cambio, etc., se sincronizan con otras cadenas. ** Se puede entender que otras billeteras en la cadena son referencias a las billeteras en la cadena, y solo se necesita modificar el cuerpo principal para sincronizarse con todas las billeteras.

**Contrato de implementador con parámetros consistentes para garantizar que la dirección de la billetera en cada cadena sea la misma. **

Las billeteras entre cadenas también pueden llamarse entre sí a través de AMB, no todas las cuales se inician desde Particle Chain.

**Emisión de Unified Gas Token, una moneda de gas de cadena completa. **ERC20 es implementado por el mecanismo Paymaster como una tarifa de gas. Incluso si no hay gas o fondos predepositados por Paymaster en una determinada cadena, puede iniciar una transacción entre cadenas en una cadena elegible para consumir Unified Gas Token.

Además de los usos anteriores, la cadena de partículas también se puede utilizar en el futuro:

Una red descentralizada generada por Proof y Salt de zkWaaS.

La capa de incentivos de cada cadena Bundler ayuda a Bundler a lograr una mejor descentralización.

Una red Solver como protocolo de fusión de intenciones.

En la narrativa de Particle Chain, Unified Gas Token es el valor central de todo el ecosistema:

La función de pagar las tarifas de gas es una fuerte lógica de demanda y captura de valor que se ha verificado repetidamente en las criptomonedas.

Unified Gas Token abstrae el concepto de capa de gas de la ecología de la cadena pública existente, y esta abstracción no se puede lograr sin Particle Chain y la billetera, por lo que Unified Gas Token es un retiro de valor de toda la ecología de Particle. Con la capa de gas, la interacción del usuario y el crecimiento de cada cadena y el valor de la moneda local son mutuamente beneficiosos y simbióticos con el Token de Gas Unificado.

El gas unificado también es uno de los factores impulsores para la realización de Chainless. Para los usuarios, pagar en una sola moneda simplifica enormemente el proceso y la comprensión de los costos. En el futuro, incluso en el escenario multicadena, es probable que los usuarios sean insensibles y no tengan que preocuparse por el funcionamiento de la infraestructura subyacente. Al igual que actualmente en Web2, no nos importa en qué región se encuentra la sala de ordenadores, qué configuración, qué idioma se utiliza y qué base de datos funciona.

Los usuarios importados por la dApp potencian directamente el token de gas unificado y los escenarios de uso son muy ricos.

Protocolo de fusión de intención

Por lo general, debemos pensar constantemente en la ruta de uso cuando usamos varias dApps:

Si no hay liquidez en un DEX, debe buscar otro DEX.

No sé qué dApp de la misma categoría debería elegir para completar mejor la transacción o transacción.

· Aprobar entonces tiene muchas características para usar, y ¿qué es aprobar?

Desempolvando la billetera, múltiples tokens pequeños en una determinada moneda, el proceso es engorroso.

Para lograr el objetivo final, se necesitan múltiples aplicaciones. Como los préstamos de alto apalancamiento: intercambiar, pignorar, pedir prestado, obtener Token y luego intercambiar, pignorar, pedir prestado…

Lo anterior es solo la punta del iceberg en nuestro mundo DeFi actual, y en la era de la adopción masiva de Web3, donde las dApps son cada vez más diversas, las interacciones pueden ser mucho más complejas de lo que crees.

Por lo tanto, reemplazar pasos de operación específicos con intent intent puede ser muy diferente para la experiencia del usuario. La intención es más que operativa, al igual que la programación declarativa lo es a la programación funcional. Las declaraciones declarativas tienden a parecer simples y directas, solo declaro lo que voy a hacer y no me importan los detalles, y esto requiere una variedad de declaraciones de programación funcional que se encapsulan en la parte inferior.

Entonces, el uso de Intents no es una excepción, y también debe ser respaldado por una variedad de instalaciones. Echemos un vistazo a todo el proceso:

**1. El usuario se somete a la red Solver en forma de RFS (Request For Solver), como lenguaje natural. **Solver es un intérprete de la intención, y hay agregadores como 1inch que pueden encontrar el mejor dex para los usuarios, pero no son lo suficientemente genéricos y potentes en comparación con nuestra visión.

**2. Varios solucionadores responden entre sí y compiten. Estas respuestas se escriben en el lenguaje DSL de intención y el cliente las analiza en un formulario que es fácil de entender para el usuario. Estas respuestas consisten en restricciones de entrada y restricciones de salida, que definen los límites entre la entrada y la salida. Los usuarios también pueden especificar sus propias restricciones. Un ejemplo simple para entender: al usar Swap, se le pedirá al usuario la cantidad mínima que se puede obtener después del intercambio, lo cual es una restricción. El usuario elige entre las respuestas de varios solucionadores por su cuenta.

3. Firma la intención.

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

5. Reactor recopila la entrada requerida (como un activo) de la cuenta de usuario, envía una intención a utor y, a continuación, llama al contrato lógico correspondiente para devolver el resultado de la transacción a Reactor. El reactor comprueba las restricciones y devuelve la salida al usuario si es correcta.

Podemos pensar en este proceso como le dices a ChatGPT sobre los requisitos, no importa cuán complejos sean los requisitos, él puede generar un resultado final para ti, siempre que estés satisfecho con los resultados, puedes usarlo directamente, sin preocuparte por el proceso.

Resumen

Particle Network propone una solución integral: a través de la trinidad de zkWaaS, Particle Chain y Intent Fusion Protocol, se realizan los paradigmas de inicio de sesión de privacidad Web2 OAuth, transacciones privadas, abstracción de cuentas de cadena completa y transacciones de intención. Cada característica cubrirá algunos de los puntos débiles del uso de Web3, y estos avances y optimizaciones se convertirán en la base del producto y la tecnología para la adopción masiva de Web3 en el futuro. En términos de ecología y modelo de negocio, se adopta el paradigma B2B2C, WaaS se utiliza como entrada para impulsar la estandarización a gran escala de toda la cadena de productos, y el ecosistema se construye con desarrolladores de dApp para crear conjuntamente un mundo Web3 con bajo umbral y alta experiencia para los usuarios.

Por supuesto, los diferentes proyectos tienen diferentes interpretaciones de la ruta de implementación de la adopción masiva de Web3. Además de la revisión de proyectos específicos, esperamos que conduzca a una comprensión de la fricción a bordo a la que se enfrenta actualmente la Web3, una reflexión sobre las necesidades y los puntos débiles de los usuarios, y una consideración para la conexión conjunta y el desarrollo de todo el ecosistema.