Abstracción de cuentas: clave para mejorar la experiencia de interacción de la cadena de bloques

AvanzadoJun 18, 2024
Además de las soluciones de abstracción de cuentas propuestas por Ethereum, como ERC-4337, EIP-3074 y EIP-7702, otras cadenas de bloques también tienen esquemas de abstracción de cuentas similares. Por ejemplo, las direcciones derivadas del programa (PDA) de Solana, x/authz de Cosmos y otros diseños similares. Este artículo presentará y comparará las soluciones antes mencionadas, dilucidará los ingeniosos elementos de diseño de diferentes esquemas e ilustrará las compensaciones consideradas en diferentes soluciones.
Abstracción de cuentas: clave para mejorar la experiencia de interacción de la cadena de bloques

Por qué necesitamos la abstracción de cuentas?

Todavía hay muchos problemas sin resolver en el campo actual de la cadena de bloques. Entre ellas, la dificultad de utilizar blockchain, es decir, la experiencia de usuario (UX) de interactuar con la cadena, debe ser el área más criticada por el público.

Por ejemplo, muchas personas piensan que usar claves es más complicado que usar el correo electrónico para administrar cuentas; la administración de claves es difícil e insegura; y cada transferencia (como USDC) requiere el consumo de tokens nativos (como Ether y Sol), lo cual es contrario a la intuición.

En este contexto, cada vez más personas están dirigiendo su atención al campo de la abstracción de cuentas para mejorar la experiencia del usuario de las interacciones on-chain y facilitar la adopción masiva.

En el proceso de exploración, Ethereum propuso soluciones de abstracción de cuentas como ERC-4337, EIP-3074 y EIP-7702. Otros L1 como Solana tienen características que permiten la abstracción de cuentas a nivel de protocolo, como direcciones derivadas de programa (PDA), y Cosmos también tiene diseños similares como x/authz y Fee Abstraction Module. En este artículo, presentaremos y compararemos las soluciones mencionadas anteriormente, clasificaremos las sutilezas del diseño de diferentes soluciones y demostraremos las compensaciones y consideraciones de las diferentes soluciones.

Background

h2 id="h2-eoa-vs-contract-cuenta">EOA frente a cuenta de contrato

La cuenta de propiedad externa (EOA) y la cuenta de contrato son dos tipos de cuenta definidos en el documento técnico Ethereum. Las cuentas EOA están controladas por claves privadas, y los usuarios pueden firmar varias transacciones a través de las claves privadas para controlar los activos en la cuenta. La cuenta del contrato está controlada por el código de la propia cuenta, y otras cuentas pueden hacer que la cuenta del contrato ejecute una lógica específica llamando al código de la cuenta del contrato.

Account Abstracción

El concepto de cuentas abstractas se remonta a 2016 (https://github.com/ethereum/EIPs/issues/86). La abstracción de cuentas se basa y se basa en los dos tipos de cuentas actuales en Ethereum: EOA y cuentas de contrato. Esto mejorará la experiencia interactiva de los usuarios de Ethereum a través de las siguientes formas:

  1. Permite a los usuarios utilizar múltiples firmas, como Schnorr, BLS, firmas poscuánticas, etc.;
  2. Permite a los usuarios pagar tarifas de gas utilizando tokens ERC20 o lógica de pago personalizada;
  3. Permite a los usuarios recuperar sus cuentas mediante correo electrónico, redes sociales, etc.;
  4. Permite a los usuarios administrar los fondos en sus cuentas con permisos detallados, como establecer un límite de retiro diario;
  5. Permite realizar múltiples operaciones on-chain en una transacción atómica. Por ejemplo, un usuario puede completar las operaciones de aprobación e intercambio en una transacción DEX con una firma.

Ethereum Hoja

de ruta La hoja de ruta de Ethereum (https://ethereum.org/en/roadmap/) destaca la futura ruta de actualización de Ethereum. Actualmente, la mayor parte de la investigación en la comunidad de Ethereum gira en torno a la hoja de ruta de Ethereum. La abstracción de cuentas es una parte imperativa de esto:

Fuente: https://x.com/VitalikButerin/status/1741190491578810445

La comunidad Ethereum espera construir sobre ERC-4337 e implementar soluciones de abstracción de cuentas dentro del protocolo, a través de propuestas como EIP-3074 o EIP-7702, y finalmente llegar a la abstracción de cuentas de Endgame.

A pesar de la mejora de la experiencia del usuario, la abstracción de cuentas de Endgame también es crucial para la computación anticuántica de Ethereum, porque el algoritmo ECDSA utilizado por la cuenta EOA actual no es seguro en la era de la computación cuántica. La adopción de la abstracción de cuentas admite firmas poscuánticas que protegen las cuentas de usuario contra las amenazas cambiantes de la computación cuántica.

EIP-3074 frente a ERC-4337

Para entender cuenta cuentas abstractas, necesitamos entender cómo funciona EOA. La siguiente imagen es el proceso de compra y venta de tokens más común en la cadena:

En términos generales, los usuarios deben emitir dos transacciones al comprar y vender: primero autorizar a Uniswap a transferir su USDC para el intercambio y luego enviar otra solicitud de transacción para que Uniswap ejecute la acción. Uniswap transfiere el USDC de la cuenta del usuario y envía la cantidad correspondiente de ETH al usuario de acuerdo con el precio actual.

ERC-4337 fusiona las dos transacciones anteriores en una sola:

Como se puede ver en la figura anterior, el usuario debe firmar dos veces para autorizar al empaquetador a operar los activos del usuario en la cuenta 4337, que es diferente de la cuenta EOA del usuario. Una vez que el empaquetador obtiene la autorización, fusiona el contenido autorizado en un paquete y lo emite para completar la transacción. Al mismo tiempo, si el usuario no tiene tokens Ethereum para las tarifas de gas, también se puede introducir el papel de paymaster, lo que permite al paymaster pagar las tarifas de gas y obtener tokens ERC20 de igual valor del usuario.

EIP-3074 y ERC-4337 tienen algunas similitudes, pero el método de implementación de EIP-3074 está en el protocolo de Ethereum:

En ERC-4337, autorizamos a Bundler a manejar activos en nuestra billetera de contratos inteligentes on-chain a través de firmas. En EIP-3074, bundler está autorizado a manejar directamente los activos en nuestra billetera EOA a través de firmas. En orden para hacer esto, la comunidad de Ethereum necesita agregar dos nuevos códigos de operación al Ethereum protocolo: AUTH y AUTHCALL.

AUTH se usa para verificar si el comportamiento del empaquetador de procesar los activos de cuenta EOA del usuario está autorizado, y AUTHCALL se usa para "engañar" al contrato inteligente de interacción del usuario (en nuestro ejemplo, USDC y Uniswap), haciendo que el contrato inteligente piense que la transacción es del cuenta EOA del usuario. La ventaja de esto es que los mantenedores de Uniswap y USDC no necesitan actualizar los contratos inteligentes desplegados y, al mismo tiempo, las cuentas EOA pueden disfrutar de las funciones de abstracción de cuentas.

Una comparación entre EIP-3074 y ERC-4337

En la comunidad Ethereum, EIP generalmente se refiere a propuestas que requieren actualizaciones Ethereum para ser compatibles, mientras que ERC se refiere a especificaciones que se pueden admitir sin actualizaciones Ethereum.

Por lo tanto, se puede ver en la nomenclatura de los dos esquemas de abstracción de cuentas que ERC-4337 es más fácil de implementar que EIP-3074, porque ERC-4337 no requiere una fork dura de la red Ethereum. Esta es también una de las razones por las que ERC-4337 se ha lanzado y se usa cada vez más en polígonos y bases, pero EIP-3074 acaba de ser aceptado por la 183ª Ethereum All Core Developers Execution Call (ACDE).

Fuente: https://dune.com/niftytable/account-abstraction

Además, ERC-4337 requiere que los usuarios migren sus cuentas actuales a nuevas cuentas de contrato y requiere DApp soporte para que EIP-1271 funcione. EIP-3074 no requiere estos apoyos adicionales. Esta es una de las principales razones de la baja tasa de adopción de ERC-4337. Al mismo tiempo, ERC-4337 no puede soportar una firma para autorizar múltiples operaciones on-chain sin introducir un contrato intermedio de múltiples llamadas, pero EIP-3074 sí, lo que también causa las limitaciones de ERC-4337.

Sin embargo, EIP-3074 también tiene sus propios problemas. El más importante es que el código de operación AUTH tiene permisos demasiado altos, lo que puede permitir al atacante controlar completamente las cuentas EOA del usuario. Después de todo, tan largo como un hacker defrauda su firma AUTH, puede disponer de los activos en su billetera EOA. Teniendo en cuenta que los ataques de phishing son actualmente desenfrenados, y la mayoría de ellos engañan las firmas de los usuarios, una vez que se implemente EIP-3074, esto se convertirá en un problema más grave.

En este sentido, lightclient, uno de los autores de EIP-3074, ha propuesto un método de mitigación para interceptar firmas maliciosas a nivel de billetera. Para obtener más información, consulte: https://x.com/lightclients/status/1778823652584120497. ERC-4337 no tiene este problema, aunque los piratas informáticos aún pueden engañar a los usuarios para que firmen UserOps maliciosos. Esto se debe a la dificultad de un UserOp para obtener autoridad de eliminación sobre todos los activos en la cuenta de usuario. En el momento de escribir este artículo, los desarrolladores de ACDE acordaron eliminar EIP-3704 de Pectra Devent 0 e incluir EIP-7702 en el próximo Pectra Devnet 1.

Qué cambió en EIP-7702?

EIP-7702 intenta integrar los beneficios de EIP-3074 y ERC-4337 para formar un camino intermedio. El usuario envía la operación firmada al empaquetador. Cuando el empaquetador envía la transacción a la cadena, la cuenta EOA del usuario se convertirá temporalmente en una cuenta de contrato inteligente como la cuenta 4337. A continuación, de manera similar al progreso de AUTH en EIP-3074, la cuenta de contrato inteligente validará la operación de empaquetado autorizada del usuario. A continuación, al igual que AUTHCALL, realice las operaciones autorizadas por el usuario. Después de ejecutar la transacción, la cuenta de usuario se revertirá a una cuenta EOA ordinaria.

Los beneficios de EIP-7702 son los siguientes:

  1. Hereda todas las ventajas de EIP-3074: no requiere que los usuarios cambien de cuentas EOA a cuentas de contratos inteligentes con nuevas direcciones; puede realizar múltiples operaciones en una transacción atómica;
  2. El código de cuentas del contrato inteligente y la infraestructura de ERC-4337 se pueden reutilizar;
  3. La abstracción de cuentas de contratos inteligentes representada por ERC-4337 y la solución de abstracción de cuentas EOA representada por EIP-3074 se pueden fusionar para evitar que Ethereum se divida en dos sistemas de abstracción de cuentas diferentes y allanar el camino para la cuenta de abstracción final en la hoja de ruta de Ethereum;
  4. Los dos códigos de operación AUTH y AUTHCALL no se agregarán a la EVM de Ethereum: teniendo en cuenta la hoja de ruta de Ethereum, las cuentas EOA se convertirán en abstracción de cuentas en el futuro, y estos dos códigos de operación se volverán redundantes.

Más allá de eso, EIP-7702 hereda todos los riesgos de seguridad de EIP-3074.

Community decidió incluir EIP-7702 en la próxima actualización de Pectra en 2025. Si se implementa, cambiará en gran medida el ecosistema de Ethereum y traerá mejoras incrementales a la versión actual ERC-4337 de la infraestructura de abstracción de cuentas.

Solana's Program Derived DIRECCIÓN

Account La abstracción en

la

abstracción de cuentas de Solana Solana es similar a la ERC-4337 de Ethereum. Son cuentas derivadas de cuentas originales (similares a las cuentas EOA), similares a las cuentas de contrato 4337. Antes de comprender la abstracción de cuentas de Solana, es necesario comprender el modelo de cuentas utilizado por Solana.

En términos generales, las cuentas se pueden clasificar como cuentas ejecutables que pueden ejecutar código o cuentas no ejecutables que no pueden hacerlo. Examinando esto más a fondo, hay tres tipos de cuentas en Solana: Programa nativo, Cuenta de programa y Cuenta de datos.

Los programas nativos son parte de la implementación del validador y proporcionan funciones básicas para la red Solana, como la creación de nuevas cuentas de datos y programas personalizados. Las cuentas de programa son programas personalizados que contienen código ejecutable. Las cuentas de datos pueden almacenar datos y administrar el estado del programa según lo definido por su cuenta de programa propietaria.

Este modelo de cuentas permite de forma nativa que las cuentas de programa creen y administren cuentas específicas, lo que ofrece a los desarrolladores la capacidad de definir reglas personalizadas y lógica para administrarlas. Habilitado por este modelo de cuentas, la DIRECCIÓN Derivada del Programa (PDA), un tipo de cuenta de datos, amplía las posibilidades de las capacidades de abstracción de cuentas en Solana, desde mejorar la seguridad del usuario a través de billeteras multisig y autenticación de dos factores hasta habilitar mecanismos de recuperación social, entre otros.

Program Derived DIRECCIÓN

Para contextualizar, todas las cuentas se encuentran en la curva Ed25519 y tienen un par de claves públicas y privadas. PDA, que se encuentra fuera de la curva Ed25519, es una cadena de 32 bytes derivada de forma determinista que parece una clave pública y no viene con una clave privada correspondiente. Las PDA permiten a los desarrolladores crear reglas personalizadas y mecanismos de firma de transacciones que pueden permitir al propietario de la cuenta del programa de PDA realizar transacciones de forma autónoma en nombre de las PDA, totalmente reconocidas y respaldadas por la red Solana.

PDA y abstracción de cuentas

Bien, ahora que entendemos cómo se derivan las PDA, es posible que se pregunte cómo se vinculan estos conceptos con abstracción de cuentas. La abstracción de cuentas ocurre bajo el capó a través de la realización de una función conocida como la Invocación de Programa Cruzado (CPI).

Los CPI son funciones que permiten a un programa invocar las instrucciones de otro programa, lo que permite la componibilidad de los programas de Solana. Cuando un programa inicia una CPI ya sea a través de invoke_signed, los programas pueden firmar en nombre de las PDA derivadas.

Fuente: Solana

Para verificar la legitimidad de las transacciones que involucran PDA, Solana tiempo de ejecución llama internamente al create_program_address utilizando el signers_seeds y el program_id del programa de llamada. Si se encuentra una PDA válida, el tiempo de ejecución asociará la PDA con el programa que realiza la llamada y reconocerá el programa como un firmante autorizado.

Actualmente, Squads está desarrollando una solución de abstracción de cuentas en Solana basada en PDA. Sin embargo, el producto proporcionado por Squads es actualmente más parecido a la solución de cuentas de contratos inteligentes de Gnosis Safe y aún no ha desarrollado completamente su funcionalidad de abstracción de cuentas.

Beneficios de las PDAs

  1. Ejecución automatizada de contratos inteligentes: Las PDA permiten diseños de contratos inteligentes más complejos que pueden realizar de forma autónoma múltiples operaciones en nombre del usuario a través de invocaciones entre programas.
  2. Experiencia de usuario mejorada: los usuarios no necesitan administrar múltiples transacciones ni estar expuestos a la complejidad técnica.
  3. Mayor seguridad y flexibilidad: Sin una clave privada, esto reduce el riesgo de que la clave se vea comprometida. Las PDA se pueden usar para billeteras multifirma o adaptarse a otros modelos de gobernanza flexibles que reducen un único punto de riesgo y son especialmente útiles para las organizaciones que administran grandes recursos compartidos.

Limitaciones de las PDAs

  1. Las PDA, aunque beneficiosas para sentar las bases de las capacidades de abstracción de cuentas, pueden ser complejas de implementar en comparación con una cuenta de pares de claves.
  2. Y al igual que ERC-4337, requiere que los usuarios realicen cuenta migración a un nuevo cuenta lo que puede suprimir la tasa de adopción de Solana abstracción de cuentas.

Account Abstraction on Cosmos (Authz & Fee Grant)

Cosmos x/authz

Con abstracción de cuentas ocupando cada vez más la atención de los desarrolladores, se lanzó authz, parte del SDK principal de Cosmos, para permitir que un cuenta realice ciertas acciones en nombre de otro cuenta mediante el uso de concesiones de autorización, que es similar a EIP-3074 y EIP-7702.

Authz viene con varios tipos de autorización predefinidos que delegan la realización de ciertas acciones, como el staking, a un beneficiario, lo que mejora la experiencia del usuario como resultado.

Con authz, se pueden dar 3 tipos de autorizaciones:

  1. GenericAuthorization. Esta concesión de autorización concede permiso sin restricciones para que el receptor ejecute el mensaje en nombre del concedente.
  2. SendAuthorization. Esta autorización, al igual que la aprobación en ERC20, busca dar al concesionario acceso a un límite de gasto positivo que define la cantidad máxima que se puede gastar en nombre del otorgante.
  3. StakeAuthorization. Esta subvención permite a los concesionarios gestionar acciones de participación como delegar, desdelegar o redelegar en nombre del otorgante.

Una concesión consta de los bytes de dirección del otorgante, los bytes de dirección de los concesionarios y los tipos de autorización. El período de tiempo también se puede definir para limitar los permisos dentro de un período de tiempo específico. Al final de cada bloque, la red eliminará las concesiones vencidas a través de un proceso llamado poda.

Comprender el marco operativo

Authz se puede usar para otorgar autorizaciones para una variedad de acciones, sin embargo, para simplificar, examinaremos cómo funciona authz para habilitar transacciones de voto genérico.

  1. Implementa la interfaz de autorización antes de que se puedan ejecutar las autorizaciones. En esta fase, también se definirá el tipo de mensaje, que en este caso será MsgVote. Aquí, vemos una autorización de subvención de Alice para una acción de votación de gobernanza.
  2. Bob genera una transacción de voto sin firmar.
  3. Bob genera una transacción firmada y ejecutada del voto del concesionario. La transacción se ha completado y la autorización se eliminará si ha caducado.

¿Beneficios que aporta authz?

  1. Seguridad operativa: los validadores y otros usuarios pueden otorgar permisos a una cuenta separada para votar sobre propuestas de gobernanza o realizar ciertas acciones, mejorando la seguridad de la cuenta y reduciendo la carga de seguridad.
  2. Operaciones optimizadas: las transacciones se pueden realizar con la necesidad de acceso a las claves de validación, las transacciones de billetera multifirma también se pueden agilizar utilizando una sola transacción para otorgar Authz a la cuenta del concesionario.
  3. Sin necesidad de migración: Al igual que EIP-3074 y EIP-7702, las operaciones de autorización se producen en la cuenta original del usuario. Los usuarios no necesitan transferir sus activos de la cuenta original a una nueva cuenta para habilitar la abstracción de cuentas.
  4. Eficiencia operativa y flexibilidad de DAO: Se puede otorgar un subconjunto de derechos de ejecución a miembros individuales de DAO para acciones específicas.
  5. Staking Reward Compounding: Authz facilita el uso de retaking y servicios equivalentes para la capitalización automatizada de recompensas de staking.

Limitaciones y riesgos para Authz:

Preste atención a los tipos de transacciones que está autorizando a través de Authz. Una autorización maliciosa puede ejecutar varios tipos de autorizaciones que podrían ser perjudiciales para el usuario.

  1. GenericAuthorization: concede permiso sin restricciones para ejecutar el mensaje proporcionado en nombre del otorgante. A menos que sea plenamente consciente de lo que está firmando, se recomienda encarecidamente evitar firmar dichos tipos de autorización. Es posible que algunas billeteras tampoco proporcionen advertencias al firmar transacciones de Authz.
  2. SendAuthorization: permite al concesionario enviar la cantidad máxima de tokens que el concesionario puede gastar si el concesionario no lo especifica. También es importante verificar la lista de permitidos, que especifica la dirección específica a la que el beneficiario puede enviar los tokens.

Módulo de concesión de tarifas

Otro obstáculo para la experiencia del usuario que frustró a muchos es la necesidad de que los usuarios de blockchains tengan varios tokens nativos en orden para interactuar con estos diferentes ecosistemas. Esto contaminó la experiencia general del usuario, especialmente para las personas no nativas de criptomonedas que estuvieron expuestas por primera vez a una miríada de cadenas existentes en el ecosistema de Cosmos.

Sin embargo, este obstáculo ha supuesto un gran avance con la integración del módulo de concesión de tasas. Al igual que el contrato paymaster que permite la abstracción de cuentas en Ethereum, el módulo de concesión de tarifas en Cosmos permite al otorgante otorgar asignaciones de tarifas al beneficiario, pagando algunas o todas las tarifas de transacción. Los fondos permanecen bajo el control del otorgante y puede revocar la asignación de la subvención en cualquier momento.

Tipos de Becas de Pago

La asignación de tarifas se puede clasificar en dos tipos: BasicAllowance y PeriodicAllowance.

BasicAllowance permite al concesionario usar las tarifas de la cuenta del otorgante hasta que se alcance el límite de gasto o el tiempo de vencimiento. La subvención será cancelada por el estado. Es importante tener en cuenta que BasicAllowance implementa una concesión única de tarifas. Si el límite de gasto y el tiempo están vacíos, no hay límite de vencimiento ni de gasto en la asignación de tarifas.

PeriodicAllowance permite que las concesiones de tasas se renueven periódicamente después de cada período de tiempo especificado. Period_spend_limit especifica el número máximo de monedas que se pueden gastar en el período. Period_reset realiza un seguimiento de cuándo debe ocurrir el próximo período y period_can_spend la cantidad de monedas que quedan antes de que comience un nuevo período.

Comprender el marco operativo

El uso de AllowedMsgAllowance crea una asignación para los tipos de mensaje especificados. La asignación puede ser BasicAllowance o PeriodicAllowance. Si se establece el tiempo de expiración, FeeAllowance se pondrá en cola en el estado con el prefijo de expiración anexado a la concesión y Endblocker comprueba el estado de FeeAllowanceQueue en busca de concesiones expiradas, eliminando cualquiera si se encuentra. Además de MsgGrantAllowance, también se puede revocar una asignación de tarifas mediante MsgRevokeAllowance.

En conjunto, los módulos Authz y Fee Grant desbloquean casos de uso innovadores y diversos que, en última instancia, crean una mejor experiencia de usuario en el ecosistema de Cosmos.

Conclusión

Resumen de la cuenta A 27 de mayo de 2024, las cifras son estimadas.

Con la aprobación de los ETF de BTC al contado y los ETF de ETH, la demanda institucional y minorista ha aumentado significativamente, lo que promete marcar el comienzo de una nueva ola de usuarios que buscan obtener exposición a la industria. La abstracción de cuentas se convertirá en una narrativa importante este año, ya que los protocolos y las dapps buscan crear una experiencia fluida para expandir sus comunidades.

DISCLAIMER

Este material es solo para información general y no constituye, ni debe interpretarse como, ninguna forma de resultado de investigación, asesoramiento profesional, solicitud, oferta, recomendación o estrategia comercial. No se ofrece ninguna garantía, representación, aval o compromiso, expreso o implícito, en cuanto a la imparcialidad, exactitud, puntualidad, integridad o corrección de cualquier información financiera y de mercado general, análisis y/u opiniones proporcionadas en este informe, y HashKey Capital no acepta ninguna responsabilidad en relación con el uso o la confianza en dicha información. Cualquier información en este informe está sujeta a cambios sin previo aviso. Este informe no ha sido revisado por la Comisión de Valores y Futuros de Hong Kong, la Autoridad Monetaria de Singapur ni ninguna autoridad reguladora de Hong Kong o Singapur.

Tenga en cuenta que los activos digitales, incluidas las criptomonedas, son muy volátiles y están sujetos a riesgos de mercado. El valor de los activos digitales puede fluctuar significativamente y no hay garantía de ganancias o preservación del capital. Debe considerar cuidadosamente su propia tolerancia al riesgo y su situación financiera antes de tomar cualquier decisión.

La distribución de este informe puede estar restringida en ciertas jurisdicciones. Este material no constituye la distribución de ninguna información ni la realización de ninguna oferta o solicitud por parte de ninguna jurisdicción en la que dicha acción no esté autorizada o a cualquier persona a la que sea ilegal distribuir dicho informe.

Manténgase actualizado con las últimas noticias de HashKey Capital -

Sitio web — https://hashkey.capital/

Twitter — https://twitter.com/HashKey_Capital

LinkedIn — https://www.linkedin.com/company/hashkeycapital/

Disclaimer:

  1. Este artículo es una reimpresión de [Medium]. Todos los derechos de autor pertenecen al autor original [HashKey Capital]. Si hay objeciones a esta reimpresión, póngase en contacto con el equipo de Gate Learn, y ellos se encargarán de ello con prontitud.

  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.

Abstracción de cuentas: clave para mejorar la experiencia de interacción de la cadena de bloques

AvanzadoJun 18, 2024
Además de las soluciones de abstracción de cuentas propuestas por Ethereum, como ERC-4337, EIP-3074 y EIP-7702, otras cadenas de bloques también tienen esquemas de abstracción de cuentas similares. Por ejemplo, las direcciones derivadas del programa (PDA) de Solana, x/authz de Cosmos y otros diseños similares. Este artículo presentará y comparará las soluciones antes mencionadas, dilucidará los ingeniosos elementos de diseño de diferentes esquemas e ilustrará las compensaciones consideradas en diferentes soluciones.
Abstracción de cuentas: clave para mejorar la experiencia de interacción de la cadena de bloques

Por qué necesitamos la abstracción de cuentas?

Todavía hay muchos problemas sin resolver en el campo actual de la cadena de bloques. Entre ellas, la dificultad de utilizar blockchain, es decir, la experiencia de usuario (UX) de interactuar con la cadena, debe ser el área más criticada por el público.

Por ejemplo, muchas personas piensan que usar claves es más complicado que usar el correo electrónico para administrar cuentas; la administración de claves es difícil e insegura; y cada transferencia (como USDC) requiere el consumo de tokens nativos (como Ether y Sol), lo cual es contrario a la intuición.

En este contexto, cada vez más personas están dirigiendo su atención al campo de la abstracción de cuentas para mejorar la experiencia del usuario de las interacciones on-chain y facilitar la adopción masiva.

En el proceso de exploración, Ethereum propuso soluciones de abstracción de cuentas como ERC-4337, EIP-3074 y EIP-7702. Otros L1 como Solana tienen características que permiten la abstracción de cuentas a nivel de protocolo, como direcciones derivadas de programa (PDA), y Cosmos también tiene diseños similares como x/authz y Fee Abstraction Module. En este artículo, presentaremos y compararemos las soluciones mencionadas anteriormente, clasificaremos las sutilezas del diseño de diferentes soluciones y demostraremos las compensaciones y consideraciones de las diferentes soluciones.

Background

h2 id="h2-eoa-vs-contract-cuenta">EOA frente a cuenta de contrato

La cuenta de propiedad externa (EOA) y la cuenta de contrato son dos tipos de cuenta definidos en el documento técnico Ethereum. Las cuentas EOA están controladas por claves privadas, y los usuarios pueden firmar varias transacciones a través de las claves privadas para controlar los activos en la cuenta. La cuenta del contrato está controlada por el código de la propia cuenta, y otras cuentas pueden hacer que la cuenta del contrato ejecute una lógica específica llamando al código de la cuenta del contrato.

Account Abstracción

El concepto de cuentas abstractas se remonta a 2016 (https://github.com/ethereum/EIPs/issues/86). La abstracción de cuentas se basa y se basa en los dos tipos de cuentas actuales en Ethereum: EOA y cuentas de contrato. Esto mejorará la experiencia interactiva de los usuarios de Ethereum a través de las siguientes formas:

  1. Permite a los usuarios utilizar múltiples firmas, como Schnorr, BLS, firmas poscuánticas, etc.;
  2. Permite a los usuarios pagar tarifas de gas utilizando tokens ERC20 o lógica de pago personalizada;
  3. Permite a los usuarios recuperar sus cuentas mediante correo electrónico, redes sociales, etc.;
  4. Permite a los usuarios administrar los fondos en sus cuentas con permisos detallados, como establecer un límite de retiro diario;
  5. Permite realizar múltiples operaciones on-chain en una transacción atómica. Por ejemplo, un usuario puede completar las operaciones de aprobación e intercambio en una transacción DEX con una firma.

Ethereum Hoja

de ruta La hoja de ruta de Ethereum (https://ethereum.org/en/roadmap/) destaca la futura ruta de actualización de Ethereum. Actualmente, la mayor parte de la investigación en la comunidad de Ethereum gira en torno a la hoja de ruta de Ethereum. La abstracción de cuentas es una parte imperativa de esto:

Fuente: https://x.com/VitalikButerin/status/1741190491578810445

La comunidad Ethereum espera construir sobre ERC-4337 e implementar soluciones de abstracción de cuentas dentro del protocolo, a través de propuestas como EIP-3074 o EIP-7702, y finalmente llegar a la abstracción de cuentas de Endgame.

A pesar de la mejora de la experiencia del usuario, la abstracción de cuentas de Endgame también es crucial para la computación anticuántica de Ethereum, porque el algoritmo ECDSA utilizado por la cuenta EOA actual no es seguro en la era de la computación cuántica. La adopción de la abstracción de cuentas admite firmas poscuánticas que protegen las cuentas de usuario contra las amenazas cambiantes de la computación cuántica.

EIP-3074 frente a ERC-4337

Para entender cuenta cuentas abstractas, necesitamos entender cómo funciona EOA. La siguiente imagen es el proceso de compra y venta de tokens más común en la cadena:

En términos generales, los usuarios deben emitir dos transacciones al comprar y vender: primero autorizar a Uniswap a transferir su USDC para el intercambio y luego enviar otra solicitud de transacción para que Uniswap ejecute la acción. Uniswap transfiere el USDC de la cuenta del usuario y envía la cantidad correspondiente de ETH al usuario de acuerdo con el precio actual.

ERC-4337 fusiona las dos transacciones anteriores en una sola:

Como se puede ver en la figura anterior, el usuario debe firmar dos veces para autorizar al empaquetador a operar los activos del usuario en la cuenta 4337, que es diferente de la cuenta EOA del usuario. Una vez que el empaquetador obtiene la autorización, fusiona el contenido autorizado en un paquete y lo emite para completar la transacción. Al mismo tiempo, si el usuario no tiene tokens Ethereum para las tarifas de gas, también se puede introducir el papel de paymaster, lo que permite al paymaster pagar las tarifas de gas y obtener tokens ERC20 de igual valor del usuario.

EIP-3074 y ERC-4337 tienen algunas similitudes, pero el método de implementación de EIP-3074 está en el protocolo de Ethereum:

En ERC-4337, autorizamos a Bundler a manejar activos en nuestra billetera de contratos inteligentes on-chain a través de firmas. En EIP-3074, bundler está autorizado a manejar directamente los activos en nuestra billetera EOA a través de firmas. En orden para hacer esto, la comunidad de Ethereum necesita agregar dos nuevos códigos de operación al Ethereum protocolo: AUTH y AUTHCALL.

AUTH se usa para verificar si el comportamiento del empaquetador de procesar los activos de cuenta EOA del usuario está autorizado, y AUTHCALL se usa para "engañar" al contrato inteligente de interacción del usuario (en nuestro ejemplo, USDC y Uniswap), haciendo que el contrato inteligente piense que la transacción es del cuenta EOA del usuario. La ventaja de esto es que los mantenedores de Uniswap y USDC no necesitan actualizar los contratos inteligentes desplegados y, al mismo tiempo, las cuentas EOA pueden disfrutar de las funciones de abstracción de cuentas.

Una comparación entre EIP-3074 y ERC-4337

En la comunidad Ethereum, EIP generalmente se refiere a propuestas que requieren actualizaciones Ethereum para ser compatibles, mientras que ERC se refiere a especificaciones que se pueden admitir sin actualizaciones Ethereum.

Por lo tanto, se puede ver en la nomenclatura de los dos esquemas de abstracción de cuentas que ERC-4337 es más fácil de implementar que EIP-3074, porque ERC-4337 no requiere una fork dura de la red Ethereum. Esta es también una de las razones por las que ERC-4337 se ha lanzado y se usa cada vez más en polígonos y bases, pero EIP-3074 acaba de ser aceptado por la 183ª Ethereum All Core Developers Execution Call (ACDE).

Fuente: https://dune.com/niftytable/account-abstraction

Además, ERC-4337 requiere que los usuarios migren sus cuentas actuales a nuevas cuentas de contrato y requiere DApp soporte para que EIP-1271 funcione. EIP-3074 no requiere estos apoyos adicionales. Esta es una de las principales razones de la baja tasa de adopción de ERC-4337. Al mismo tiempo, ERC-4337 no puede soportar una firma para autorizar múltiples operaciones on-chain sin introducir un contrato intermedio de múltiples llamadas, pero EIP-3074 sí, lo que también causa las limitaciones de ERC-4337.

Sin embargo, EIP-3074 también tiene sus propios problemas. El más importante es que el código de operación AUTH tiene permisos demasiado altos, lo que puede permitir al atacante controlar completamente las cuentas EOA del usuario. Después de todo, tan largo como un hacker defrauda su firma AUTH, puede disponer de los activos en su billetera EOA. Teniendo en cuenta que los ataques de phishing son actualmente desenfrenados, y la mayoría de ellos engañan las firmas de los usuarios, una vez que se implemente EIP-3074, esto se convertirá en un problema más grave.

En este sentido, lightclient, uno de los autores de EIP-3074, ha propuesto un método de mitigación para interceptar firmas maliciosas a nivel de billetera. Para obtener más información, consulte: https://x.com/lightclients/status/1778823652584120497. ERC-4337 no tiene este problema, aunque los piratas informáticos aún pueden engañar a los usuarios para que firmen UserOps maliciosos. Esto se debe a la dificultad de un UserOp para obtener autoridad de eliminación sobre todos los activos en la cuenta de usuario. En el momento de escribir este artículo, los desarrolladores de ACDE acordaron eliminar EIP-3704 de Pectra Devent 0 e incluir EIP-7702 en el próximo Pectra Devnet 1.

Qué cambió en EIP-7702?

EIP-7702 intenta integrar los beneficios de EIP-3074 y ERC-4337 para formar un camino intermedio. El usuario envía la operación firmada al empaquetador. Cuando el empaquetador envía la transacción a la cadena, la cuenta EOA del usuario se convertirá temporalmente en una cuenta de contrato inteligente como la cuenta 4337. A continuación, de manera similar al progreso de AUTH en EIP-3074, la cuenta de contrato inteligente validará la operación de empaquetado autorizada del usuario. A continuación, al igual que AUTHCALL, realice las operaciones autorizadas por el usuario. Después de ejecutar la transacción, la cuenta de usuario se revertirá a una cuenta EOA ordinaria.

Los beneficios de EIP-7702 son los siguientes:

  1. Hereda todas las ventajas de EIP-3074: no requiere que los usuarios cambien de cuentas EOA a cuentas de contratos inteligentes con nuevas direcciones; puede realizar múltiples operaciones en una transacción atómica;
  2. El código de cuentas del contrato inteligente y la infraestructura de ERC-4337 se pueden reutilizar;
  3. La abstracción de cuentas de contratos inteligentes representada por ERC-4337 y la solución de abstracción de cuentas EOA representada por EIP-3074 se pueden fusionar para evitar que Ethereum se divida en dos sistemas de abstracción de cuentas diferentes y allanar el camino para la cuenta de abstracción final en la hoja de ruta de Ethereum;
  4. Los dos códigos de operación AUTH y AUTHCALL no se agregarán a la EVM de Ethereum: teniendo en cuenta la hoja de ruta de Ethereum, las cuentas EOA se convertirán en abstracción de cuentas en el futuro, y estos dos códigos de operación se volverán redundantes.

Más allá de eso, EIP-7702 hereda todos los riesgos de seguridad de EIP-3074.

Community decidió incluir EIP-7702 en la próxima actualización de Pectra en 2025. Si se implementa, cambiará en gran medida el ecosistema de Ethereum y traerá mejoras incrementales a la versión actual ERC-4337 de la infraestructura de abstracción de cuentas.

Solana's Program Derived DIRECCIÓN

Account La abstracción en

la

abstracción de cuentas de Solana Solana es similar a la ERC-4337 de Ethereum. Son cuentas derivadas de cuentas originales (similares a las cuentas EOA), similares a las cuentas de contrato 4337. Antes de comprender la abstracción de cuentas de Solana, es necesario comprender el modelo de cuentas utilizado por Solana.

En términos generales, las cuentas se pueden clasificar como cuentas ejecutables que pueden ejecutar código o cuentas no ejecutables que no pueden hacerlo. Examinando esto más a fondo, hay tres tipos de cuentas en Solana: Programa nativo, Cuenta de programa y Cuenta de datos.

Los programas nativos son parte de la implementación del validador y proporcionan funciones básicas para la red Solana, como la creación de nuevas cuentas de datos y programas personalizados. Las cuentas de programa son programas personalizados que contienen código ejecutable. Las cuentas de datos pueden almacenar datos y administrar el estado del programa según lo definido por su cuenta de programa propietaria.

Este modelo de cuentas permite de forma nativa que las cuentas de programa creen y administren cuentas específicas, lo que ofrece a los desarrolladores la capacidad de definir reglas personalizadas y lógica para administrarlas. Habilitado por este modelo de cuentas, la DIRECCIÓN Derivada del Programa (PDA), un tipo de cuenta de datos, amplía las posibilidades de las capacidades de abstracción de cuentas en Solana, desde mejorar la seguridad del usuario a través de billeteras multisig y autenticación de dos factores hasta habilitar mecanismos de recuperación social, entre otros.

Program Derived DIRECCIÓN

Para contextualizar, todas las cuentas se encuentran en la curva Ed25519 y tienen un par de claves públicas y privadas. PDA, que se encuentra fuera de la curva Ed25519, es una cadena de 32 bytes derivada de forma determinista que parece una clave pública y no viene con una clave privada correspondiente. Las PDA permiten a los desarrolladores crear reglas personalizadas y mecanismos de firma de transacciones que pueden permitir al propietario de la cuenta del programa de PDA realizar transacciones de forma autónoma en nombre de las PDA, totalmente reconocidas y respaldadas por la red Solana.

PDA y abstracción de cuentas

Bien, ahora que entendemos cómo se derivan las PDA, es posible que se pregunte cómo se vinculan estos conceptos con abstracción de cuentas. La abstracción de cuentas ocurre bajo el capó a través de la realización de una función conocida como la Invocación de Programa Cruzado (CPI).

Los CPI son funciones que permiten a un programa invocar las instrucciones de otro programa, lo que permite la componibilidad de los programas de Solana. Cuando un programa inicia una CPI ya sea a través de invoke_signed, los programas pueden firmar en nombre de las PDA derivadas.

Fuente: Solana

Para verificar la legitimidad de las transacciones que involucran PDA, Solana tiempo de ejecución llama internamente al create_program_address utilizando el signers_seeds y el program_id del programa de llamada. Si se encuentra una PDA válida, el tiempo de ejecución asociará la PDA con el programa que realiza la llamada y reconocerá el programa como un firmante autorizado.

Actualmente, Squads está desarrollando una solución de abstracción de cuentas en Solana basada en PDA. Sin embargo, el producto proporcionado por Squads es actualmente más parecido a la solución de cuentas de contratos inteligentes de Gnosis Safe y aún no ha desarrollado completamente su funcionalidad de abstracción de cuentas.

Beneficios de las PDAs

  1. Ejecución automatizada de contratos inteligentes: Las PDA permiten diseños de contratos inteligentes más complejos que pueden realizar de forma autónoma múltiples operaciones en nombre del usuario a través de invocaciones entre programas.
  2. Experiencia de usuario mejorada: los usuarios no necesitan administrar múltiples transacciones ni estar expuestos a la complejidad técnica.
  3. Mayor seguridad y flexibilidad: Sin una clave privada, esto reduce el riesgo de que la clave se vea comprometida. Las PDA se pueden usar para billeteras multifirma o adaptarse a otros modelos de gobernanza flexibles que reducen un único punto de riesgo y son especialmente útiles para las organizaciones que administran grandes recursos compartidos.

Limitaciones de las PDAs

  1. Las PDA, aunque beneficiosas para sentar las bases de las capacidades de abstracción de cuentas, pueden ser complejas de implementar en comparación con una cuenta de pares de claves.
  2. Y al igual que ERC-4337, requiere que los usuarios realicen cuenta migración a un nuevo cuenta lo que puede suprimir la tasa de adopción de Solana abstracción de cuentas.

Account Abstraction on Cosmos (Authz & Fee Grant)

Cosmos x/authz

Con abstracción de cuentas ocupando cada vez más la atención de los desarrolladores, se lanzó authz, parte del SDK principal de Cosmos, para permitir que un cuenta realice ciertas acciones en nombre de otro cuenta mediante el uso de concesiones de autorización, que es similar a EIP-3074 y EIP-7702.

Authz viene con varios tipos de autorización predefinidos que delegan la realización de ciertas acciones, como el staking, a un beneficiario, lo que mejora la experiencia del usuario como resultado.

Con authz, se pueden dar 3 tipos de autorizaciones:

  1. GenericAuthorization. Esta concesión de autorización concede permiso sin restricciones para que el receptor ejecute el mensaje en nombre del concedente.
  2. SendAuthorization. Esta autorización, al igual que la aprobación en ERC20, busca dar al concesionario acceso a un límite de gasto positivo que define la cantidad máxima que se puede gastar en nombre del otorgante.
  3. StakeAuthorization. Esta subvención permite a los concesionarios gestionar acciones de participación como delegar, desdelegar o redelegar en nombre del otorgante.

Una concesión consta de los bytes de dirección del otorgante, los bytes de dirección de los concesionarios y los tipos de autorización. El período de tiempo también se puede definir para limitar los permisos dentro de un período de tiempo específico. Al final de cada bloque, la red eliminará las concesiones vencidas a través de un proceso llamado poda.

Comprender el marco operativo

Authz se puede usar para otorgar autorizaciones para una variedad de acciones, sin embargo, para simplificar, examinaremos cómo funciona authz para habilitar transacciones de voto genérico.

  1. Implementa la interfaz de autorización antes de que se puedan ejecutar las autorizaciones. En esta fase, también se definirá el tipo de mensaje, que en este caso será MsgVote. Aquí, vemos una autorización de subvención de Alice para una acción de votación de gobernanza.
  2. Bob genera una transacción de voto sin firmar.
  3. Bob genera una transacción firmada y ejecutada del voto del concesionario. La transacción se ha completado y la autorización se eliminará si ha caducado.

¿Beneficios que aporta authz?

  1. Seguridad operativa: los validadores y otros usuarios pueden otorgar permisos a una cuenta separada para votar sobre propuestas de gobernanza o realizar ciertas acciones, mejorando la seguridad de la cuenta y reduciendo la carga de seguridad.
  2. Operaciones optimizadas: las transacciones se pueden realizar con la necesidad de acceso a las claves de validación, las transacciones de billetera multifirma también se pueden agilizar utilizando una sola transacción para otorgar Authz a la cuenta del concesionario.
  3. Sin necesidad de migración: Al igual que EIP-3074 y EIP-7702, las operaciones de autorización se producen en la cuenta original del usuario. Los usuarios no necesitan transferir sus activos de la cuenta original a una nueva cuenta para habilitar la abstracción de cuentas.
  4. Eficiencia operativa y flexibilidad de DAO: Se puede otorgar un subconjunto de derechos de ejecución a miembros individuales de DAO para acciones específicas.
  5. Staking Reward Compounding: Authz facilita el uso de retaking y servicios equivalentes para la capitalización automatizada de recompensas de staking.

Limitaciones y riesgos para Authz:

Preste atención a los tipos de transacciones que está autorizando a través de Authz. Una autorización maliciosa puede ejecutar varios tipos de autorizaciones que podrían ser perjudiciales para el usuario.

  1. GenericAuthorization: concede permiso sin restricciones para ejecutar el mensaje proporcionado en nombre del otorgante. A menos que sea plenamente consciente de lo que está firmando, se recomienda encarecidamente evitar firmar dichos tipos de autorización. Es posible que algunas billeteras tampoco proporcionen advertencias al firmar transacciones de Authz.
  2. SendAuthorization: permite al concesionario enviar la cantidad máxima de tokens que el concesionario puede gastar si el concesionario no lo especifica. También es importante verificar la lista de permitidos, que especifica la dirección específica a la que el beneficiario puede enviar los tokens.

Módulo de concesión de tarifas

Otro obstáculo para la experiencia del usuario que frustró a muchos es la necesidad de que los usuarios de blockchains tengan varios tokens nativos en orden para interactuar con estos diferentes ecosistemas. Esto contaminó la experiencia general del usuario, especialmente para las personas no nativas de criptomonedas que estuvieron expuestas por primera vez a una miríada de cadenas existentes en el ecosistema de Cosmos.

Sin embargo, este obstáculo ha supuesto un gran avance con la integración del módulo de concesión de tasas. Al igual que el contrato paymaster que permite la abstracción de cuentas en Ethereum, el módulo de concesión de tarifas en Cosmos permite al otorgante otorgar asignaciones de tarifas al beneficiario, pagando algunas o todas las tarifas de transacción. Los fondos permanecen bajo el control del otorgante y puede revocar la asignación de la subvención en cualquier momento.

Tipos de Becas de Pago

La asignación de tarifas se puede clasificar en dos tipos: BasicAllowance y PeriodicAllowance.

BasicAllowance permite al concesionario usar las tarifas de la cuenta del otorgante hasta que se alcance el límite de gasto o el tiempo de vencimiento. La subvención será cancelada por el estado. Es importante tener en cuenta que BasicAllowance implementa una concesión única de tarifas. Si el límite de gasto y el tiempo están vacíos, no hay límite de vencimiento ni de gasto en la asignación de tarifas.

PeriodicAllowance permite que las concesiones de tasas se renueven periódicamente después de cada período de tiempo especificado. Period_spend_limit especifica el número máximo de monedas que se pueden gastar en el período. Period_reset realiza un seguimiento de cuándo debe ocurrir el próximo período y period_can_spend la cantidad de monedas que quedan antes de que comience un nuevo período.

Comprender el marco operativo

El uso de AllowedMsgAllowance crea una asignación para los tipos de mensaje especificados. La asignación puede ser BasicAllowance o PeriodicAllowance. Si se establece el tiempo de expiración, FeeAllowance se pondrá en cola en el estado con el prefijo de expiración anexado a la concesión y Endblocker comprueba el estado de FeeAllowanceQueue en busca de concesiones expiradas, eliminando cualquiera si se encuentra. Además de MsgGrantAllowance, también se puede revocar una asignación de tarifas mediante MsgRevokeAllowance.

En conjunto, los módulos Authz y Fee Grant desbloquean casos de uso innovadores y diversos que, en última instancia, crean una mejor experiencia de usuario en el ecosistema de Cosmos.

Conclusión

Resumen de la cuenta A 27 de mayo de 2024, las cifras son estimadas.

Con la aprobación de los ETF de BTC al contado y los ETF de ETH, la demanda institucional y minorista ha aumentado significativamente, lo que promete marcar el comienzo de una nueva ola de usuarios que buscan obtener exposición a la industria. La abstracción de cuentas se convertirá en una narrativa importante este año, ya que los protocolos y las dapps buscan crear una experiencia fluida para expandir sus comunidades.

DISCLAIMER

Este material es solo para información general y no constituye, ni debe interpretarse como, ninguna forma de resultado de investigación, asesoramiento profesional, solicitud, oferta, recomendación o estrategia comercial. No se ofrece ninguna garantía, representación, aval o compromiso, expreso o implícito, en cuanto a la imparcialidad, exactitud, puntualidad, integridad o corrección de cualquier información financiera y de mercado general, análisis y/u opiniones proporcionadas en este informe, y HashKey Capital no acepta ninguna responsabilidad en relación con el uso o la confianza en dicha información. Cualquier información en este informe está sujeta a cambios sin previo aviso. Este informe no ha sido revisado por la Comisión de Valores y Futuros de Hong Kong, la Autoridad Monetaria de Singapur ni ninguna autoridad reguladora de Hong Kong o Singapur.

Tenga en cuenta que los activos digitales, incluidas las criptomonedas, son muy volátiles y están sujetos a riesgos de mercado. El valor de los activos digitales puede fluctuar significativamente y no hay garantía de ganancias o preservación del capital. Debe considerar cuidadosamente su propia tolerancia al riesgo y su situación financiera antes de tomar cualquier decisión.

La distribución de este informe puede estar restringida en ciertas jurisdicciones. Este material no constituye la distribución de ninguna información ni la realización de ninguna oferta o solicitud por parte de ninguna jurisdicción en la que dicha acción no esté autorizada o a cualquier persona a la que sea ilegal distribuir dicho informe.

Manténgase actualizado con las últimas noticias de HashKey Capital -

Sitio web — https://hashkey.capital/

Twitter — https://twitter.com/HashKey_Capital

LinkedIn — https://www.linkedin.com/company/hashkeycapital/

Disclaimer:

  1. Este artículo es una reimpresión de [Medium]. Todos los derechos de autor pertenecen al autor original [HashKey Capital]. Si hay objeciones a esta reimpresión, póngase en contacto con el equipo de Gate Learn, y ellos se encargarán de ello con prontitud.

  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.

Comece agora
Inscreva-se e ganhe um cupom de
$100
!