TL;DR

Desde 2022, la abstracción de cuentas ha sido ampliamente discutida en el campo, y el marco centrado en EIP-4337 parece haberse convertido en un consenso general en la industria. La popularidad del concepto de abstracción ha llevado a las personas a prestar más atención a componentes de interacción de usuario de umbral bajo.

Sin embargo, EIP-4337 todavía enfrenta puntos dolorosos como la fragmentación de cuentas inteligentes y experiencias de usuario altamente fragmentadas en todas las cadenas. Este artículo toma proyectos como Biconomy, Safe Core y Particle Network como ejemplos para explorar cómo promover aún más el desarrollo del campo de abstracción de cuentas dentro del marco de EIP-4337.

Desde la perspectiva de la abstracción del proceso de transacción, comprender el concepto de “abstracción de cuentas”

En cuanto a la abstracción de cuentas, Vitalik ha señalado en repetidas ocasiones que es una condición necesaria para reducir el umbral de usuario de Ethereum y lograr una adopción masiva. Su visión principal es permitir a los usuarios personalizar los métodos de verificación de firmas + disfrutar del pago de gas e iniciar transacciones en cadena sin ningún activo (comúnmente conocido como transacciones sin gas). Solo al lograr estos requisitos previos se puede mejorar la tasa de conversión de nuevos usuarios a aplicaciones Web3.

Propuestas anteriores a la abstracción de cuentas o billeteras inteligentes, aunque pueden lograr experiencias similares, todavía no son lo suficientemente flexibles y eficientes. Por ejemplo, Gnosis Safe todavía requiere una dirección EOA para activar transacciones, y el costo de gas es extremadamente alto.

La abstracción de cuentas tiene la intención de optimizar desde la estructura subyacente de las cuentas de contratos inteligentes, allanando el camino para la próxima generación de sistemas de cuentas inteligentes.

Sin embargo, si observamos las propuestas de abstracción de cuentas reales, encontraremos que su enfoque no está en el modelo de cuenta en sí mismo. Por ejemplo, propuestas relacionadas con la abstracción de cuentas como EIP-86, EIP-4337 y EIP-6900 se centran en abstraer/modularizar el flujo de procesamiento completo de una transacción desde su inicio hasta su recepción por los nodos, verificación de firma, pago de gas, etc., en lugar de centrarse realmente en la abstracción de la estructura de la cuenta. Por lo tanto, parece más apropiado referirse a estas diversas propuestas como “abstracción de transacciones”.

Si entendemos las conocidas propuestas de abstracción de cuentas desde la perspectiva de la “abstracción del flujo de procesamiento de transacciones”, podemos entender más fácilmente sus puntos clave: este tipo de abstracción de transacciones realmente tiene como objetivo llevar la experiencia de los usuarios de nivel Web2 al ingresar y usar productos en el sistema Ethereum, como listas negras/listas blancas, transacciones iniciadas dentro de un período sin verificación de identidad, transacciones sin costo de gas, pago en moneda fiduciaria de tarifas, etc.

Algunos pueden preguntar: ¿No podrían estas funcionalidades lograrse en el pasado con las carteras de contratos inteligentes existentes? ¿Cuál es el valor de los esquemas de abstracción de cuentas como EIP-4337?

La Esencia de EIP-4337: Abstracción de Cuentas como una Solución Óptima Local en el Ecosistema de Ethereum

Como sugiere la pregunta, si bien las billeteras inteligentes pasadas podían lograr de hecho las funcionalidades mencionadas, sus métodos de implementación a menudo eran rudimentarios y dependían con frecuencia de instalaciones de terceros altamente centralizadas. Por ejemplo, los esquemas de pago de gas anteriores requerían la introducción de nodos de retransmisión de terceros (EIP-2771). Además, la falta de normas unificadas entre las diferentes implementaciones de billeteras inteligentes obstaculizaba el desarrollo y despliegue de componentes complementarios.

El objetivo principal de varios EIP relacionados con la abstracción de cuentas es abordar estas deficiencias presentes en diferentes proyectos de monederos al introducir un marco estandarizado diseñado específicamente para monederos de contratos inteligentes. Este marco tiene como objetivo transicionar la estructura de cuentas dentro del ecosistema de Ethereum de una estructura funcional básica a una estructura inteligente más sofisticada, mejorando así la eficiencia y escalabilidad del ecosistema en general.

Esto es análogo a la situación antes de que surgieran ERC-20 o ERC-721, donde los métodos de implementación, funcionalidades y funciones/interfaces proporcionadas de muchos tokens eran inconsistentes. Tal inconsistencia no era propicia para el desarrollo de instalaciones de terceros complementarias y auditorías de código (es difícil imaginar hasta qué punto las aplicaciones DeFi podrían haber prosperado sin el protocolo ERC-20).

Los protocolos estandarizados/las normas de implementación funcional son requisitos previos para las narrativas modulares, y los enfoques de desarrollo modular son casi requisitos previos para un desarrollo vibrante en cualquier campo (la división del trabajo siendo el primer principio de mejora de eficiencia).

Al final, EIP-4337 surgió.

EIP-4337 es una solución óptima local, pero hay múltiples ángulos dentro de su marco que necesitan optimización urgente.

EIP-4337 define un conjunto completo de normas de interfaz, aclarando qué módulos debe tener una billetera inteligente que siga el protocolo 4337, y qué funciones/interfaces debe implementar cada módulo, como el Bundler, el EntryPoint y el Paymaster, y qué funciones invocables deben proporcionar estos componentes.

Una vez que estas especificaciones estén claramente definidas, la interacción entre los diferentes componentes se vuelve más clara, lo que facilita la introducción del pensamiento de diseño modular en el diseño de la abstracción de cuentas y las billeteras inteligentes, beneficiando en gran medida a los desarrolladores de módulos de billetera.

Por supuesto, desde la perspectiva del usuario, el valor aportado por el paradigma de desarrollo modular de la billetera inteligente aún no está claro porque los usuarios pueden no sentir muchos cambios en la billetera de abstracción de cuentas en el corto plazo. Sin embargo, a mediano y largo plazo, el valor de protocolos como EIP-4337 es similar al de ERC-20 y ERC-721. Sienta las bases para el desarrollo a largo plazo de las billeteras de abstracción de cuentas y es un hito de importancia revolucionaria.

Sin embargo, EIP-4337 todavía tiene muchos problemas sin resolver, como:

1. La funcionalidad de abstracción de cuentas no es lo suficientemente plug-and-play, lo que facilita que diferentes desarrolladores reinventen la rueda.

2. La compatibilidad deficiente de los módulos de cuenta conduce a un ecosistema fragmentado de sistemas de cuenta.

3. El ecosistema altamente fragmentado de abstracción de cuentas entre diferentes cadenas hace que sea difícil proporcionar a los usuarios finales y desarrolladores una experiencia unificada y de alta calidad para lograr una mejor UX.

En las siguientes secciones, discutiremos soluciones a estos problemas.

Dirección de optimización uno: la modularización de la abstracción de cuentas se convertirá en una configuración básica de funcionalidad plug-and-play

Se puede decir que uno de los puntos principales de discusión actuales relacionados con la abstracción de cuentas es cómo lograr mejor la modularización de las carteras de abstracción de cuentas y hacer que la división de cada módulo sea más refinada.

Por ejemplo, Biconomy, basado en EIP-4337 (y presentará el EIP-6900 más detallado en el futuro), propone la narrativa de la modularización de la funcionalidad de plug-and-play de la abstracción de cuentas para promover aún más el desarrollo modular del ecosistema de abstracción de cuentas.

La funcionalidad de plug-and-play de modularización de la abstracción de cuentas, esencialmente se logra a través de un protocolo que describe explícitamente los módulos clave involucrados en las carteras inteligentes de contratos, qué interfaces/funciones deben implementar estos módulos, y cómo se nombran y llaman estas interfaces. Posteriormente, los desarrolladores de terceros desarrollarán componentes con diferentes detalles según sus propias ideas, pero todos estos componentes cumplirán con los requisitos descritos en el protocolo.

La versión V2 de Biconomy, basada en el EIP-4337 como marco del protocolo, ha establecido estándares más detallados y ha añadido un lote de interfaces no mencionadas en el 4337. Al especificar las funcionalidades que deben tener el Bundler, el Smart Contract Wallet, el Paymaster y otros módulos, Biconomy permite a desarrolladores de terceros implementar módulos con detalles de código diferentes pero con características similares y distintas versiones, siempre y cuando cumplan con las reglas del protocolo predefinidas por Biconomy (compatibles con el EIP-4337).

Mientras tanto, Biconomy también ha introducido el lema de la “Tienda de Módulos.” Mientras lanza activamente el SDK del módulo de abstracción de cuentas, Biconomy anima a los desarrolladores a enviar sus propios módulos de abstracción de cuentas diseñados e inicia el “Módulo como un Servicio,” permitiendo que todos los proyectos de monedero que cumplan con el protocolo EIP-4337 adopten directamente estos módulos de abstracción de cuentas escritos por terceros. Cuando los usuarios crean cuentas inteligentes a través de la interfaz frontal, también tendrán una selección más diversa de módulos para elegir.

La modularización no solo facilita la división del trabajo, sino que también permite a los usuarios cambiar, agregar o eliminar rápidamente características específicas en las billeteras inteligentes (en términos más simples, descompone la granularidad en componentes más finos).

Biconomy señala que cuanto mayor sea el grado de modularización en las carteras de contratos inteligentes, menos cambios serán necesarios al actualizar o mejorar (no es necesario actualizar los contratos de cartera de contratos inteligentes existentes de los usuarios o usar DelegateCall, solo ciertos módulos externos necesitan ser actualizados), lo que facilita a diferentes usuarios o desarrolladores reemplazar ciertos componentes.

En la futura versión de la nueva solución de abstracción de cuentas de Biconomy, también hará referencia a EIP-6900, que es más propicio para la modularización que EIP-4337.

Dirección de optimización dos: Segmentación de módulos más finos para abordar problemas de fragmentación de cuentas

En cuanto a la propuesta EIP-6900, Safe (anteriormente Gnosis Safe) en realidad publicó un whitepaper del Protocolo Central de Safe relacionado con ella en agosto de este año, que se basa en gran medida en EIP-6900.

EIP-6900 señala que un problema actual con la abstracción de cuentas modularizada es el problema de “fragmentación” o “isla” de cuentas. Por ejemplo, aunque diferentes proveedores de módulos de abstracción de cuentas o diferentes aplicaciones DApp pueden ser compatibles con EIP-4337, el nivel de abstracción de EIP-4337 para diferentes módulos no es lo suficientemente alto y la granularidad es relativamente gruesa. Esto deja una libertad "excesiva" a los desarrolladores de módulos de Cuentas Inteligentes (las cuentas inteligentes almacenan información de usuario y registran la parte principal de la lógica de verificación de transacciones personalizadas y el pago de gas).

Como resultado, diferentes proyectos de monederos tienden a diseñar módulos de Cuenta Inteligente con atributos únicos. Con el tiempo, otros proveedores de módulos de abstracción de cuentas deben priorizar la compatibilidad con el módulo de Cuenta Inteligente que se proporciona, lo que lleva a la aparición de una cadena de suministro fija aguas arriba y aguas abajo. Esto conduce inevitablemente a la fragmentación y desconexión en el ecosistema de módulos de abstracción de cuentas. (Esto es similar a los primeros días de la industria informática cuando los desarrolladores de sistemas operativos tenían que considerar la compatibilidad con dispositivos de hardware de diferentes fabricantes de hardware de computadoras.)

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 diferentes proveedores, el mejor enfoque es abstraer aún más las cuentas de monedero de contratos inteligentes y hacer que la granularidad de segmentación del módulo sea más fina.

Después de basarse en las ideas de EIP-6900, el libro blanco del Protocolo Safe Core realizó optimizaciones más detalladas para la Cuenta Inteligente (cuentas de billetera de contrato inteligente de usuarios). El Protocolo Safe Core divide cada módulo llamable de una cuenta de billetera de contrato inteligente en varias categorías como Plugins, Hooks, validadores de firma y procesadores de funciones.

Los módulos de cuenta inteligente están hechos lo más ligeros posible, con el contrato de cuenta almacenando solo los datos y funciones más básicos, mientras que las funciones que pueden ser trasladadas fuera son implementadas por módulos especializados como "procesadores de funciones" o "plugins". Esto se adhiere al principio de la navaja de Occam: "Las entidades no deben ser multiplicadas innecesariamente."

Si la cuenta inteligente en sí es lo suficientemente liviana y no implica demasiados detalles intrincados, las cuentas inteligentes desarrolladas por diferentes fabricantes serán más similares en estructura interna, y la compatibilidad también será mayor.

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 procesarse a través del contrato Manger.

En general, la UserOperation primero activará un Plugin específico, y luego el contrato Manager verificará si el estado del Plugin es normal (registrado en el registro). Si es normal, el contrato Manager permitirá que la solicitud del Plugin continúe. Si es necesario, el Plugin puede llamar a ciertas funcionalidades proporcionadas por algunos Hooks, o puede que no. Posteriormente, el estado de la cuenta inteligente involucrada en la UserOperation será modificado.

A través del proceso de segmentación y programación de módulos detallados mencionado anteriormente, el Protocolo Core Seguro intenta promover un protocolo de interoperabilidad de módulos de abstracción de cuentas de código abierto. Su idea principal es aligerar las Cuentas Inteligentes tanto como sea posible, haciéndolas tan simples como las cuentas EOA, con el fin de mejorar la compatibilidad entre los módulos de Cuentas Inteligentes desarrollados por diferentes fabricantes.

Optimizar Dirección Tres: Abstracción de Cuentas Unificada en Todas las Cadenas, Logrando Cuentas Consistentes en Diferentes Cadenas

Sin embargo, incluso con las soluciones mencionadas anteriormente, todavía existe un problema importante sin resolver: diferentes cadenas y diferentes soluciones de Capa 2 están avanzando diversos esquemas de implementación de abstracción de cuentas con formas conflictivas, muchos de los cuales entran en conflicto con EIP-4337, como zkSync Era, Starknet, Flow, etc. Esta fragmentación en la experiencia de la cartera, por ejemplo, hace imposible unificar la dirección de la billetera inteligente de un usuario en Starknet con la de Arbitrum.

Además, en un entorno de múltiples cadenas, los usuarios han desplegado de forma independiente Cuentas Inteligentes en diferentes cadenas, y sus datos de usuario correspondientes a menudo se almacenan en estos contratos. Si los datos del usuario, como las claves, necesitan ser actualizados, las transacciones deben repetirse en varias cadenas, lo que dificulta asegurar la consistencia de las Cuentas Inteligentes.

Vitalik mismo propuso anteriormente una solución de cuenta inteligente unificada y fácil de gestionar en todas las cadenas. Esta solución utiliza Ethereum o un ZKRollup altamente seguro como cadena fuente, despliega un contrato de Keystore para almacenar las claves globales de los usuarios, y luego todas las cuentas de contratos inteligentes en la Capa 2 comparten las claves globales almacenadas en el contrato Keystore。

Sin embargo, esta solución conlleva costos extremadamente altos. Cada vez que hay un cambio en las claves globales registradas por el contrato de Keystore en la cadena de origen, cada cuenta en la cadena L2/objetivo necesita sincronizar las nuevas claves a través de interacciones entre cadenas. Sin embargo, el costo de las interacciones entre Ethereum y L2 es demasiado alto para que los usuarios lo puedan asumir. Además, es importante tener en cuenta que las cuentas de contratos inteligentes son diferentes de las cuentas EOA. Mientras que estas últimas, debido a su método único de generación de direcciones, están naturalmente unificadas en múltiples cadenas (dentro del ecosistema EVM), las cuentas de contratos inteligentes son completamente diferentes, lo que hace que sea difícil para los usuarios obtener cuentas de contratos inteligentes con la misma dirección en diferentes cadenas.

En respuesta a esto, Particle Network ha propuesto su propio enfoque. Aunque la idea general se alinea con el concepto de Vitalik de separar el Almacenamiento y el Código de cuentas inteligentes, Particle Network planea utilizar una cadena separada, la Cadena de Particle Network, como base de datos de Almacenamiento de cadena completa para cuentas inteligentes. A través de soluciones de mensajería entre cadenas de terceros (como LayerZero, CCIP, Axelar, Connext, etc.), Particle Network tiene la intención de sincronizar los cambios en el Almacenamiento de una cuenta a las Cuentas locales de otras cadenas.

(Estructura de abstracción de cuentas Multi-Chain de Particle Network)

Específicamente, el sistema de abstracción de cuentas completo de la Red de Partículas tiene como objetivo proporcionar a los usuarios una dirección de cuenta de contrato inteligente unificada en diferentes cadenas EVM. Esto requiere implementar un conjunto de Contratos de Despliegue en diferentes cadenas. Los usuarios deben desencadenar la generación de una nueva cuenta en la Cadena de la Red de Partículas, después de lo cual la Cadena de Partículas desencadenará todos los Contratos de Despliegue en diversas cadenas para garantizar que las direcciones de cuenta de contrato inteligente generadas para los usuarios en diferentes cadenas sean consistentes. Alternativamente, los usuarios pueden completar 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 de tarifas unificado.

La abstracción de cuentas de cadena completa también permite Operaciones de Usuario entre Cadenas, lo que permite a los usuarios desencadenar transacciones en la cadena de destino a través de Operaciones de Usuario y pagar el gas correspondiente en la cadena de origen. Por ejemplo, permite la compra de NFT en Base utilizando USDC de Polygon.

Sin embargo, la solución de la Red de Partículas requiere esfuerzos altamente coordinados entre los Contratos de Despliegue y los componentes de mensajería entre cadenas para sincronizar cuentas multi-cadena y almacenamiento de la cadena fuente. Esto impone altas demandas en el oráculo o puente de mensajería entre cadenas utilizado (un desafío que parece existir en todas las soluciones relacionadas con la interoperabilidad de cadenas completas).

Sin embargo, la sincronización de cuentas entre cadenas de usuarios puede configurarse de forma flexible con diferentes combinaciones de Puentes de Mensajes, en lugar de depender de un solo Puente. Por ejemplo, se puede configurar con una política 2/3, donde los cambios en el almacenamiento en la cadena de destino solo se confirman después de que dos de LayerZero, Axelar o Connext confirmen el cambio, lo que puede mitigar el problema de la dependencia de un solo punto.

La interoperabilidad perfecta en todas las cadenas EVM y no EVM representa un paso adicional en la abstracción de cuentas completas en el ecosistema de Ethereum. A pesar de los avances en la gestión de claves y cuentas unificadas en las cadenas EVM, todavía hay margen para la optimización en la abstracción de cuentas completas en todas las cadenas. Las cadenas que no son compatibles con EVM, como Aptos, Solana y Sui, no pueden garantizar la consistencia de las direcciones de cuentas de contratos inteligentes generadas por los usuarios con las de las cadenas EVM. Además, las cadenas no EVM pueden tener dificultades para adoptar el concepto de abstracción de cuentas completa propuesto por Vitalik y Particle Network sin implementar soluciones equivalentes al protocolo EIP-4337.

Además, hay margen de mejora en los proyectos de monedero compatibles con EIP-4337. La mayoría de los monederos inteligentes utilizan nodos de agrupación operados de forma independiente por las plataformas respectivas, que a menudo no están interconectados. Este aislamiento plantea riesgos como la resistencia a la censura y la disponibilidad. Construir una interfaz frontal unificada en la mayoría de las cadenas sería extremadamente desafiante. Un enfoque para abordar esto es introducir un diseño centrado en la intención, agregando una capa sobre la abstracción de cuentas completa de la cadena, tratando al ecosistema EIP-4337 de Ethereum u otras facilidades de abstracción de cuentas nativas de otras cadenas (como zkSync) como instancias específicas bajo la categoría de Solver/Reactor, siendo la selección de Solvers adecuados una tarea de nivel superior.

Tomando la Red de Partículas como ejemplo, propone una abstracción concisa de la implementación centrada en la intención, donde diferentes proyectos de abstracción de cuentas son simplemente instancias incluidas en la categoría Solver dentro del esquema de intención.

Primero, la interfaz de usuario es responsable de traducir solicitudes en lenguaje natural o cualquier interacción del usuario en descripciones programáticas específicas, que incluyen restricciones de entrada y restricciones de salida (es decir, condiciones para entradas aceptables y rangos para resultados de salida aceptables). Posteriormente, uno o más Solvers en la red de Solvers enviarán la Transacción que contiene restricciones específicas de entrada-salida a los contratos Solver desplegados en la cadena (Solver abarca no solo las instalaciones de nodos sino también componentes de contratos en cadena). El contrato Solver luego pasará las instrucciones de Intención al contrato Reactor (que gestiona las cuentas en cadena del usuario), delegando la ejecución para completar la interacción final.

La solicitud del usuario es recibida inicialmente por la red Solver, lo que permite a los usuarios no tener que preocuparse demasiado por las cadenas subyacentes o la construcción de diferentes esquemas de abstracción de cuentas, ya que esta parte es manejada por el Solver para construir soluciones específicas.

Por supuesto, estas ideas son actualmente solo un marco teórico, y los detalles de implementación todavía están pendientes de despliegue oficial por parte de Particle Network. Lo que está claro es que inevitablemente surgirá un mercado competitivo de Solvers en el futuro, donde los usuarios pueden iniciar subastas para múltiples Solvers para proponer diferentes soluciones. A través de transacciones locales simuladas, se puede seleccionar la solución óptima y se puede recompensar al Solver correspondiente. En cuanto a la forma de incentivos, depende de las consideraciones de los diseñadores del protocolo de la red Solver (Particle Network tiene la intención de utilizar tokens PNT como incentivos para su mercado de subastas de Solver).

La intención actual básicamente protege los detalles complejos subyacentes y abstrae una capa superior. Un diseño en capas que se asemeja al protocolo TCP/IP es necesario tanto para la experiencia del usuario como del desarrollador en la interoperabilidad fluida entre cadenas.

Abrazando la adopción generalizada de la abstracción de cuentas

Cuando optimizamos el marco 4337 dentro del ecosistema de Ethereum desde varios ángulos y promovemos simultáneamente la interoperabilidad sin problemas en los ecosistemas de Ethereum y no Ethereum, con el fin de apoyar la amplia adopción de la abstracción de cuentas, creemos que todavía hay necesidad de un producto que abarque tanto la oferta como la demanda. No solo debería reducir las barreras para que los usuarios finales utilicen varios servicios de productos Web3, sino también enfocarse en los desarrolladores de servicios para reducir su umbral.

Uno de los mejores productos para desempeñar este papel es el producto Modular Smart Wallet-as-a-Service (Modular Smart Wallet-as-a-Service) de Particle Network:

El servicio proporciona una API fácil de usar que permite a los desarrolladores integrar de forma transparente la funcionalidad de abstracción de cuentas modular en sus aplicaciones. Los desarrolladores pueden utilizar este servicio para crear y gestionar cuentas en diferentes cadenas, realizar interacciones entre cadenas y utilizar un método unificado de pago de comisiones. Este tipo de servicio ofrecerá a los desarrolladores una forma más flexible y conveniente de construir aplicaciones multi-cadena, promoviendo así 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 significativo es que el producto Modular Smart Wallet-as-a-Service (Modular Smart Wallet-as-a-Service) de Particle Network ha construido un ecosistema abierto para la abstracción de cuentas en la comunidad de desarrolladores, basado en la computación de firmas. Además de proporcionar módulos de productos de abstracción de cuentas auto-desarrollados, integra varios tipos de productos y servicios de abstracción de cuentas, facilitando la adopción rápida de productos y servicios de diversos desarrolladores en todo el dominio de abstracción de cuentas.

Al alinear la tecnología con la demanda y abordar las limitaciones del marco ERC-4337 desde todos los ángulos, la mejora en la experiencia del desarrollador catalizará la aparición de más productos con experiencias de usuario sobresalientes. Esto acelerará la transición de la industria Web3 de ser amigable para los entusiastas de las criptomonedas y orientada a las finanzas a ser amigable para el consumidor y mainstream.

Descargo de responsabilidad:

1. Este artículo es reimpreso de[Tencent Website], Todos los derechos de autor pertenecen al autor original [Peter Pan, cofundador y CTO de Particle Network &Faust，极客Web3]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo manejarán rápidamente.
2. Descargo 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 indique lo contrario, está prohibido copiar, distribuir o plagiar los artículos traducidos.