Desde 2022, la abstracción de cuentas ha sido un tema ampliamente discutido, y el marco en el campo de la abstracción de cuentas centrado en EIP-4337 parece haberse convertido en un consenso de la industria. La popularidad del concepto de intención ha subrayado la importancia de estos componentes de interacción de usuarios de umbral bajo.

Sin embargo, EIP-4337 todavía tiene los puntos críticos como la fragmentación de cuentas inteligentes y una experiencia de usuario altamente fragmentada de la abstracción de cuentas entre cadenas. Este artículo explora cómo promover aún más el desarrollo del campo de abstracción de cuentas bajo el marco de EIP-4337, tomando proyectos como Biconomy, Safe Core y Particle Network como ejemplos.

Comprender el concepto de Abstracción de cuenta desde la perspectiva de la Abstracción del flujo de transacciones

En cuanto a la abstracción de cuentas, Vitalik ha señalado muchas veces que es una condición necesaria para bajar el umbral de usuarios de Ethereum y lograr una adopción masiva. Su visión principal es permitir a los usuarios personalizar el método de verificación de la firma y disfrutar del pago de gas, y pueden iniciar una transacción en la cadena sin ningún activo (comúnmente conocida como transacción sin gas). Sólo teniendo en cuenta estos requisitos previos, las aplicaciones Web3 pueden mejorar sus tasas de conversión de usuarios. Aunque las propuestas abstractas anteriores que no son cuentas o las billeteras de contratos inteligentes pueden lograr experiencias similares, están lejos de ser lo suficientemente flexibles y eficientes. Por ejemplo, Gnosis Safe todavía requiere una dirección EOA para activar las transacciones, y los costos de gas que implica son extremadamente altos. La abstracción de cuentas tiene como objetivo optimizar la estructura subyacente de las cuentas de contratos inteligentes, allanando el camino para la próxima generación de sistemas de cuentas inteligentes. Pero si nos fijamos en las propuestas reales de abstracción de cuentas, encontraremos que su enfoque no está en el modelo de cuenta en sí. Por ejemplo, las propuestas relacionadas con la abstracción de cuentas, como EIP-86, EIP-4337 y EIP-6900, se centran en la abstracción/modularización de todo el proceso de procesamiento de una transacción, desde el inicio hasta la recepción por parte de los nodos, así como en la verificación de la firma, el pago de gas, etc., en lugar de centrarse en la abstracción de la estructura de la cuenta per se. Una abstracción de la estructura de la cuenta. Por lo tanto, parece más apropiado llamar a las diversas propuestas actuales "abstracciones de flujo de transacciones". Si entendemos esas conocidas propuestas de abstracción de cuentas desde la perspectiva de la abstracción del flujo de transacciones, podemos comprender más fácilmente sus puntos principales: este tipo de abstracción de transacciones en realidad tiene como objetivo llevar la experiencia del usuario de la entrada a nivel Web2 y el uso del producto al sistema Ethereum. Esto puede tomar la forma de listas negras/listas blancas, iniciar transacciones sin verificación de identidad dentro de un cierto período de tiempo, transacciones sin gas, pagos en moneda fiduciaria, etc.

(Fuente de la imagen: Zengo)

Sin embargo, algunos podrían preguntar: ¿No podrían lograrse estas cosas con las carteras de contratos inteligentes existentes en el pasado? ¿Cuál es el valor de las soluciones de abstracción de cuentas como EIP-4337?

Esencia de EIP-4337: Soluciones óptimas locales para la abstracción de cuentas en el ecosistema Ethereum

Como señala la pregunta anterior, si bien las billeteras inteligentes anteriores podían lograr las funcionalidades mencionadas, los métodos de implementación eran generalmente rudimentarios y a menudo dependían en gran medida de infraestructuras de terceros altamente centralizadas. Por ejemplo, en el pasado, la solución de retransmisión de gas requería la introducción de nodos de retransmisión de terceros (EIP-2771). Además, existía una falta de estándares unificados entre diferentes billeteras inteligentes, lo que dificultaba el desarrollo y la implementación de componentes complementarios. La demanda principal de varios EIP relacionados con la abstracción de cuentas es abordar estas deficiencias presentes en diferentes proyectos de billeteras mediante la introducción de un marco estandarizado diseñado específicamente para billeteras de contratos inteligentes. Este avance tiene como objetivo cambiar la estructura de cuentas dentro del ecosistema de Ethereum de una estructura funcional básica a una estructura inteligente más sofisticada con capacidades superiores.

(Fuente de la imagen: Springer Link)

Esto es similar a la situación antes de ERC-20 o ERC-721, donde los métodos de implementación, funcionalidades y funciones/interfaces proporcionadas de muchos tokens eran inconsistentes. Tales inconsistencias obstaculizaron el desarrollo de infraestructuras de terceros complementarias y auditorías de código (es difícil imaginar cómo las aplicaciones DeFi podrían haber prosperado hasta su nivel actual sin el protocolo ERC-20).

Los estándares de implementación para protocolos/características estandarizados son requisitos previos para el diseño modular, y el desarrollo modular es casi un requisito previo para cualquier campo que aspire a un crecimiento vibrante (la división del trabajo siendo el primer principio para mejorar la eficiencia).

En última instancia, EIP-4337 se destaca.

EIP-4337 es una solución óptima local, pero varias perspectivas dentro de su marco necesitan ser optimizadas

EIP-4337 define un conjunto completo de estándares de interfaz, aclarando los módulos esperados en las billeteras inteligentes que se adhieren al protocolo 4337 y las funciones/interfaces que cada módulo debe implementar. Por ejemplo, qué funciones invocables deben ofrecer externamente componentes como bundler, entrypoints y paymaster. Con estas pautas implementadas, las interacciones entre los diferentes componentes se vuelven más claras, lo que facilita la integración de ideas de diseño modular en el diseño de la abstracción de cuentas y billeteras inteligentes. Los desarrolladores que trabajan en módulos de billetera también se benefician significativamente. Sin embargo, mirando puramente desde el punto de vista del usuario, el valor aportado por el paradigma de desarrollo de billeteras inteligentes modulares podría no ser evidente de inmediato, ya que los cambios en las billeteras de abstracción de cuentas en sí mismas podrían no ser palpables a corto plazo. Sin embargo, mirando a medio y largo plazo, el valor de protocolos como EIP-4337 se asemeja al de ERC-20 y ERC-721. Sienta las bases para el desarrollo a largo plazo de billeteras de abstracción de cuentas, marcando un hito significativo. Sin embargo, EIP-4337 todavía tiene numerosos problemas sin resolver, tales como:

1. La abstracción de cuentas no es lo suficientemente fácil de integrar, lo que lleva a diferentes desarrolladores a reinventar involuntariamente la rueda.

2. Compatibilidad deficiente entre los módulos de cuenta, lo que resulta en un ecosistema fragmentado.

3. Alta fragmentación de los ecosistemas de abstracción de cuentas en diferentes cadenas, lo que dificulta ofrecer una experiencia unificada y de alta calidad para los usuarios finales y los desarrolladores.

A continuación, profundizaremos en soluciones para estos problemas.

Solución de optimización 1: El complemento de abstracción de cuentas se convertirá en la configuración básica

Uno de los puntos focales principales en las discusiones actuales sobre la abstracción de cuentas es mejorar la modularización de las carteras de abstracción de cuentas y refinar aún más la granularidad de cada módulo. Por ejemplo, Biconomy, basado en EIP-4337 (el EIP-6900 más detallado se introducirá en el futuro), propone la abstracción de cuentas plug-and-play para impulsar aún más el desarrollo modular del ecosistema de abstracción de cuentas.

(Fuente de la imagen: Biconomy)

El llamado complemento de abstracción de cuenta en realidad es establecer un protocolo que define explícitamente los módulos clave involucrados en una billetera de contrato inteligente, describiendo las interfaces/funciones que estos módulos deben implementar, y especificando los nombres y métodos de llamada de estas interfaces. Los desarrolladores de terceros crearán componentes con detalles variables basados en sus ideas, asegurando que estos componentes cumplan con los requisitos establecidos en el protocolo.

La v2 de Biconomy, basada en EIP-4337 como marco del protocolo, ha ideado estándares más detallados e introducido un conjunto de interfaces no mencionadas en EIP-4337. Al declarar las funcionalidades que deben poseer los agrupadores, carteras de contratos inteligentes, pagadores y otros módulos, Biconomy permite a los desarrolladores de terceros implementar módulos con las mismas características pero versiones diferentes utilizando detalles de código diferentes, siempre y cuando se adhieran a las pautas del protocolo establecidas por Biconomy (compatibles con EIP-4337).

(Los estándares de interfaz propuestos por Biconomy indican qué funciones deben implementar los desarrolladores de módulos de terceros dentro de sus módulos para llamadas externas). Además, Biconomy introdujo el lema de “Module Store”, promoviendo activamente el lanzamiento de un SDK de módulo de abstracción de cuenta mientras anima a los desarrolladores a enviar sus propios módulos de abstracción de cuenta diseñados. Esta iniciativa tiene como objetivo promover el “módulo como servicio”, permitiendo que todos los proyectos de billetera que sigan el protocolo EIP-4337 adopten directamente estos módulos de abstracción de cuenta desarrollados externamente. Los usuarios ahora tienen opciones más diversas sobre qué módulos utilizar al crear cuentas inteligentes a través del frontend.

La modularidad no solo facilita la división del trabajo, sino que también permite a los usuarios cambiar o agregar/eliminar rápidamente ciertas funciones en una billetera inteligente. Dicho de manera directa, permite refinar la granularidad de los componentes. Biconomy señala que cuanto mayor sea el grado de modularidad en una billetera de contrato inteligente, menos cambios necesitará hacer al actualizarlo o mejorarlo. No es necesario actualizar el contrato de la billetera de contrato inteligente existente del usuario o usar DelegateCall, solo algunos módulos externos deben actualizarse, lo que facilita a diferentes usuarios o desarrolladores reemplazar ciertos componentes.

En el próximo esquema de abstracción de cuentas actualizado de Biconomy, también considerarán EIP-6900, que es más propicio para la modularización que EIP-4337.

Solución de optimización 2: Segmentación de módulos más granular para abordar problemas de fragmentación de cuentas

En relación con EIP-6900, Safe (anteriormente Gnosis Safe) publicó un whitepaper del Protocolo Core de Safe en agosto de este año, el cual se basa en gran medida en EIP-6900.

(Esquema EIP-6900) EIP-6900 destaca un problema prevalente en la abstracción de cuentas modulares actuales, es decir, la "fragmentación" de las cuentas, o el problema de la isla. Por ejemplo, si bien diferentes proveedores de módulos de abstracción de cuentas o varias DApps pueden ser compatibles con EIP-4337, su nivel de abstracción en diferentes módulos es insuficiente, con una granularidad relativamente baja. Este escenario permite una libertad "excesiva" para los desarrolladores de módulos de cuentas inteligentes (la cuenta inteligente es el componente central que almacena la información del usuario, registra la validación de transacciones personalizadas y maneja la lógica de pago de gas) para crear módulos con atributos únicos. Como resultado, con el tiempo, los diferentes proyectos de billetera tienden a diseñar módulos de cuentas inteligentes con propiedades distintas. Esta tendencia obliga a otros proveedores de módulos de abstracción de cuentas a priorizar la compatibilidad con proveedores específicos de módulos de cuentas inteligentes, formando gradualmente cadenas de suministro fijas ascendentes y descendentes. Esto conduce inevitablemente a la fragmentación y el aislamiento del ecosistema del módulo de abstracción de cuentas (similar a los primeros días en la industria informática, donde los desarrolladores de sistemas operativos tenían que considerar la compatibilidad con hardware de diferentes fabricantes). Para abordar el problema de la fragmentación del ecosistema y mejorar la compatibilidad entre los módulos de abstracción de cuentas desarrollados por varios proveedores, el enfoque óptimo es abstraer aún más las cuentas de billetera de contratos inteligentes y refinar la granularidad de la segmentación de módulos. Siguiendo los principios descritos en EIP-6900, el documento técnico del Protocolo Núcleo Seguro ha realizado optimizaciones detalladas en las cuentas inteligentes (cuentas de billetera inteligente de los usuarios). El protocolo Safe Core divide los módulos invocables dentro de cada cuenta de billetera inteligente en varias categorías, como complementos, ganchos, validadores de firmas, procesadores de funciones y más. Los módulos de cuentas inteligentes tienen como objetivo ser lo más livianos posible, almacenando solo datos y funciones esenciales, al tiempo que delegan funciones móviles a "procesadores de funciones" o módulos segmentados similares. Este enfoque se alinea con el principio de la Navaja de Occam: "las entidades no deben multiplicarse innecesariamente". Si las cuentas inteligentes en sí mismas son lo suficientemente ligeras y no implican detalles demasiado complicados, las cuentas inteligentes desarrolladas por diferentes proveedores exhibirán estructuras internas más cercanas y una mayor compatibilidad.

El protocolo Safe Core también introduce un registro (similar a la App Store de iPhone), que contiene todos los módulos aprobados y disponibles. Los usuarios pueden elegir qué módulos activar, y cada vez que se activa un nuevo módulo, debe ser procesado a través del Manger.

Generalmente, UserOperation primero activará un complemento, y luego el Manger verificará si el estado del complemento es normal (registrado en el registro). Si es normal, se permitirá la solicitud del complemento. Si es necesario, el complemento llamará a algunas funciones proporcionadas por Hook o elegirá no hacerlo. Más tarde, se cambiará el estado de la cuenta inteligente involucrada en UserOperation.

A través del método de segmentación de módulos de grano fino y del proceso de programación mencionado anteriormente, el Protocolo Central Seguro intenta implementar un conjunto de protocolos de interoperabilidad de módulos de abstracción de cuentas de código abierto. La idea principal es hacer que la cuenta inteligente sea liviana y tan simple como una cuenta EOA para mejorar la compatibilidad entre los módulos de cuentas inteligentes de diferentes proveedores.

Solución de optimización 3: Abstracción de cuentas omnichain para cuentas unificadas en diferentes cadenas

Sin embargo, a pesar de las soluciones mencionadas anteriormente, queda un problema significativo por resolver: las diferentes cadenas y las diversas soluciones de Capa 2 están avanzando en detalles de implementación divergentes de abstracción de cuenta, muchos de los cuales entran en conflicto con EIP-4337, como zkSync Era, Starknet, Flow, etc. Esto fragmenta la experiencia de la cartera para los usuarios. Por ejemplo, las direcciones de billetera inteligente en Starknet no pueden unificarse con las de Arbitrum. Además, en un entorno multi-cadena, los usuarios han implementado de forma independiente cuentas inteligentes en diferentes cadenas, y sus datos de usuario correspondientes a menudo están dispersos en estos contratos. Si se necesitan actualizar datos de usuario como claves, las transacciones deben iniciarse repetidamente en múltiples cadenas, lo que dificulta garantizar la consistencia de la Cuenta Inteligente. Vitalik ha propuesto anteriormente una solución de cuenta inteligente que es unificada en toda la cadena y fácil de gestionar. Esta solución utiliza Ethereum o un ZK-Rollup altamente seguro como cadena fuente y despliega el contrato de Almacenamiento para almacenar la clave global del usuario. Luego, todas las cuentas de contrato inteligente en la Capa 2 comparten la clave global almacenada en el contrato de Almacenamiento.

(Fuente de la imagen: https://vitalik.ca/general/2023/06/20/deeperdive.html)

Sin embargo, esta solución conlleva costos significativos. Cada vez que las claves globales registradas en el contrato de Keystore en la cadena fuente cambian, cada cuenta en L2/la cadena de destino debe sincronizar las nuevas claves a través de interacciones entre cadenas. El costo operativo de las interacciones entre cadenas entre Ethereum y la Capa 2 es demasiado alto para que los usuarios lo soporten. Además, es crucial tener en cuenta que las cuentas de contratos inteligentes difieren de las EOAs. Estas últimas, debido a su enfoque único de generación de direcciones, están inherentemente unificadas en varias cadenas EVM. Pero las cuentas de contratos inteligentes son completamente diferentes, lo que dificulta que los usuarios obtengan cuentas de contratos inteligentes con las mismas direcciones en diferentes cadenas. En respuesta, Particle Network ha propuesto su propio método. Si bien la idea general de su método se alinea con el concepto de Vitalik, centrándose en separar el Almacenamiento y el Código de las cuentas inteligentes, Particle Network tiene la intención de utilizar una cadena independiente—Particle Network Chain—como la base de datos de Almacenamiento completa para las cuentas inteligentes. Planean sincronizar los cambios en el Almacenamiento de una cuenta al almacenamiento local de la cuenta en otras cadenas a través de soluciones de mensajería entre cadenas de terceros (como LayerZero, CCIP, Axelar, Connext, etc.).

(Estructura de Abstracción de Cuenta Multi-cadena de Particle Network)

En particular, el sistema de Abstracción de Cuentas Omnicanal de la Red de Partículas permite a los usuarios tener una dirección de cuenta de contrato inteligente unificada en diferentes cadenas EVM. Esto requiere implementar un conjunto de Contratos de Implementación en diferentes cadenas; los usuarios deben activar la generación de nuevas cuentas en la Cadena de Red de Partículas, y luego la Cadena de Partículas activará los Contratos de Implementación en todas las cadenas para garantizar que las direcciones de cuenta de contrato inteligente generadas para los usuarios en diferentes cadenas sean consistentes. Alternativamente, los usuarios pueden participar en interacciones multi-cadena a través de contratos en la cadena de Partículas sin ser conscientes de otras cadenas, y pueden utilizar el Token de Gas Unificado como método de pago universal para las tarifas de transacción.

La Abstracción de Cuenta Omnicanal también permite operaciones de usuarios entre cadenas al iniciar transacciones en la cadena de destino a través de operaciones de usuarios y pagar el gas correspondiente en la cadena de origen. Por ejemplo, esto permite a los usuarios comprar NFT en Base usando $USDC de Polygon.

Sin embargo, la solución de Particle Network requiere un alto grado de colaboración entre el Contrato de Implementación y el componente de mensajería entre cadenas para lograr la sincronización de cuentas multi-cadena y el almacenamiento de la cadena fuente. Esto realmente coloca mayores requisitos en el oráculo o puente de mensajes entre cadenas utilizado (lo cual parece ser un problema común en todas las soluciones relacionadas con la interoperabilidad omnicanal). Sin embargo, la sincronización de cuentas entre cadenas del usuario puede configurar de manera flexible la combinación de diferentes Puentes de Mensajes, en lugar de depender de un solo puente. Por ejemplo, se puede configurar como una estrategia 2/3, dependiendo de la confirmación de cualquier par de LayerZero, Axelar y Connext para confirmar cambios de almacenamiento en la cadena de destino. Esta podría ser una solución potencial para el problema de dependencia de un solo punto.

La interoperabilidad sin fisuras de Omnichain a través de EVM y no EVM es un paso adicional hacia la abstracción de cuentas Omnichain dentro del ecosistema Ethereum

A pesar de tener una gestión clave y cuentas unificadas en todas las cadenas de EVM, todavía hay áreas de optimización dentro de la abstracción de cuentas omnichain. Las cadenas no compatibles con EVM, como Aptos, Solana, Sui, etc., no pueden garantizar que las direcciones de las cuentas de los contratos inteligentes sean coherentes con las de las cadenas EVM. Además, a las cadenas que no son EVM les resultaría difícil adoptar el concepto de abstracción de cuentas entre cadenas propuesto en la discusión anterior si no implementan el protocolo ERC-4337 con una solución equivalente. Además, hay margen de mejora dentro de los proyectos de billeteras compatibles con EIP-4337. Los nodos Bundler utilizados por la mayoría de las billeteras inteligentes se ejecutan oficialmente de forma independiente, a veces incluso de forma aislada entre sí, lo que crea varios riesgos (como los riesgos relacionados con la resistencia a la censura y la disponibilidad). La construcción de una interfaz frontend unificada que abarque la mayoría de las cadenas resulta ser un gran desafío. Una posible solución es introducir un diseño centrado en la intención, añadiendo una capa adicional a la abstracción de la cuenta omnichain. Esta capa incorpora el ecosistema EIP-4337 de Ethereum o las instalaciones de abstracción de cuentas nativas de otras cadenas (por ejemplo, zkSync) como instancias específicas bajo el tipo Solver/Reactor, siendo la tarea de seleccionar el Solver apropiado una responsabilidad de nivel superior. Tomando Particle Network como ejemplo, propone una implementación concisa y abstracta centrada en la intención. Los diferentes proyectos de abstracción de cuentas son simplemente instancias incluidas en la categoría Solver dentro del esquema de intención. En primer lugar, el frontend del usuario transforma las solicitudes de lenguaje natural o cualquier interacción del usuario en descripciones programáticas específicas que abarcan restricciones de entrada y salida (en otras palabras, estas son condiciones que permiten entradas que satisfacen los requisitos del usuario y resultados de salida que se encuentran dentro de un rango específico). Posteriormente, dentro de la red de Solver, los Solver específicos reenvían transacciones que contienen restricciones precisas de entrada y salida a los contratos de Solver implementados en la cadena (los Solvers abarcan no solo la infraestructura de nodos, sino también los componentes del contrato en la cadena). El contrato Solver transmite la directiva Intent al contrato Reactor (gestionando las cuentas de usuario en la cadena), delegando a este último para llamar a otros módulos para cumplir con la interacción final. Este marco permite que las solicitudes de los usuarios sean procesadas inicialmente por la red Solver, lo que alivia la necesidad de que los usuarios comprendan las cadenas subyacentes o los diferentes esquemas de abstracción de cuentas, una tarea delegada al Solver para construir soluciones específicas. Sin embargo, estas conceptualizaciones siguen siendo marcos teóricos, con detalles de implementación a la espera de una mayor elaboración por parte de Particle Network. Es evidente que en el futuro surgirá un mercado competitivo de solucionadores, lo que permitirá a los usuarios iniciar ofertas en las que varios solucionadores propongan soluciones distintas. A través de transacciones simuladas localmente, se puede seleccionar la solución óptima y se pueden proporcionar los incentivos correspondientes a su Solver. La estructura de incentivos será moldeada por los diseñadores de protocolos de la red Solver (Particle Network tiene como objetivo utilizar tokens PNT como tokens de incentivo para su mercado de subastas Solver). En la actualidad, la esencia de la intención oculta los detalles complejos de las capas inferiores y abstrae una capa superior. Este diseño en capas, que se asemeja al protocolo TCP/IP, es esencial para mejorar tanto la experiencia del usuario como la del desarrollador en una interoperabilidad perfecta entre cadenas.

Abrazando la Adopción Masiva de la Abstracción de Cuentas

Tras optimizar el marco EIP-4337 dentro del ecosistema de Ethereum desde varios aspectos y avanzar hacia la interoperabilidad perfecta entre los ecosistemas de Ethereum y no Ethereum, creemos que, para apoyar la adopción masiva de la abstracción de cuentas, todavía necesitamos un producto que abarque los lados de la oferta y la demanda. Este producto debería reducir la complejidad para los usuarios finales que utilizan varios servicios de productos Web3, centrándose en la reducción de las barreras de entrada de los desarrolladores. Uno de los productos óptimos que cumple este papel es la Pila de Servicios de Billetera Inteligente Modular de Particle Network:

Arquitectura de Smart Wallet-as-a-Service de Particle Network

• El servicio ofrece una API fácil de usar, lo que permite a los desarrolladores integrar de forma fluida funcionalidades modulares de abstracción de cuentas en sus aplicaciones.
• Los desarrolladores pueden usar este servicio para crear y gestionar cuentas omnichain, realizar interacciones entre cadenas y utilizar un método de pago de tarifa unificado.
• Estos servicios proporcionarán a los desarrolladores una forma más flexible y conveniente de construir aplicaciones multi-cadena y promover la adopción generalizada de la abstracción de cuentas.

Además de las características amigables para los desarrolladores mencionadas anteriormente, el aspecto más crucial de la pila de servicios de billetera inteligente modular de Particle Network es que construyó un ecosistema abierto para el dominio de abstracción de cuentas, basado en el cálculo de firmas y orientado hacia los desarrolladores. Junto con sus módulos de producto de abstracción de cuenta internos, Particle Network integra varios tipos de productos y servicios de abstracción de cuenta. Esta integración acelera la adopción de productos y servicios en todo el dominio de abstracción de cuentas para los desarrolladores.

(Diseño modular de la Cartera Inteligente como Servicio de la Red de Partículas) Que la tecnología sirva a las necesidades de los usuarios. Tras resolver las limitaciones del marco ERC-4337, la mejora de la experiencia del desarrollador llevará a la aparición de más productos con excelentes experiencias de usuario, acelerando la transición de Web3 de una industria financiera amigable para los cripto-punks a una industria amigable para el consumidor en masa.

Descargo de responsabilidad：

1. Este artículo está reimpreso de [Web3 de Geek]. Todos los derechos de autor pertenecen al autor original [Peter Pan, cofundador y director de tecnología de Particle Network y Faust,极客Web3]. Si hay objeciones a esta reimpresión, por favor póngase en contacto con elGate Learnequipo y lo resolverán rápidamente.
2. Renuncia de responsabilidad: Las opiniones expresadas en este artículo son únicamente las 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.