Ethereum tiene dos tipos de cuentas: Cuenta de Propiedad Externa (EOA) y Cuenta de Contrato (CA). Las EOA son controladas por una clave privada mientras que las CA son controladas por el código de contrato inteligente contenido en ellas. Las EOA siempre han tenido más privilegios que las CA porque solo las EOA pueden iniciar la ejecución de transacciones pagando gas. La Abstracción de Cuenta (AA) es una propuesta que permite que un contrato sea una cuenta "de nivel superior", como una EOA, que puede pagar tarifas e iniciar la ejecución de transacciones.

La motivación para AA es mejorar significativamente la experiencia del usuario en cómo interactúan los usuarios con la cadena de bloques de Ethereum hoy en día en varios escenarios como billeteras, mezcladoras, ÐApps y DeFi. AA proporciona una funcionalidad de capa base en Ethereum para decidir cuándo se puede pagar por el gas, lo que también tiene implicaciones sobre quién paga por el gas y cómo lo paga.

La aplicación Status Messenger incluye un mensajero centrado en la privacidad junto con una billetera Ethereum y un navegador Web3 ÐApp. La billetera de Status actualmente es una billetera EOA que nos limita de ofrecer una experiencia de usuario rica que solo una billetera de contrato inteligente puede ofrecer, como seguridad multi-firma, recuperación social, limitación de tasas, lista de direcciones permitidas/prohibidas y meta-transacciones sin gas. Sin embargo, la experiencia de usuario de las billeteras de contratos inteligentes hoy en día se ve gravemente obstaculizada por los precios fluctuantes del gas, lo cual no se resuelve de manera eficiente por intermediarios de terceros. AA tiene como objetivo abordar este problema.

En este artículo, motivamos la necesidad de Abstracción de Cuenta en el contexto de las carteras de contratos inteligentes. Luego nos adentramos en los aspectos clave de AA describiendo los cambios de protocolo y el impacto en los nodos. Finalmente, discutimos algunas de las extensiones propuestas y concluimos racionalizando la hoja de ruta planificada para los proyectos de Status que interactúan con Ethereum y, por lo tanto, podrían verse afectados por AA.

Historia y motivación

La Abstracción de Cuenta fue inicialmente propuesta como EIP-86en 2017 para implementar la “Abstracción del origen y la firma de la transacción” pero los orígenes de la idea motivadora se remontan aún más atrás aprincipios de 2016, donde se sugirió que: “En lugar de tener un mecanismo en el protocolo donde ECDSA y el esquema de nonce predeterminado estén consagrados como la única forma “estándar” de asegurar una cuenta, damos los primeros pasos hacia un modelo en el que a largo plazo todas las cuentas sean contratos, los contratos puedan pagar por gas y los usuarios sean libres de definir su propio modelo de seguridad.”

Las propuestas iniciales se consideraron difíciles de implementar debido a los numerosos cambios de protocolo requeridos y las garantías de seguridad que se deben cumplir. Más recientemente, Vitalik y otros propusieron un borrador para EIP-2938que describe una implementación mucho más simple al mantener los cambios en el protocolo/consenso mínimos y hacer cumplir las garantías de seguridad requeridas a través de las reglas del mempool del nodo. Vitalik’sPresentación del grupo de ingeniería de Ethereum Meetup y Presentación de ETHOnline(junto con los artículos acompañantes@SamWilsn/ryhxoGp4D">1 & @SamWilsn/S1UQDOzBv">2) de Sam Wilson & Ansgar Dietrichs (dos de los otros autores de EIP) ofrecen excelentes introducciones al tema. Este artículo destaca aspectos clave de todas estas fuentes.

Motivación: La razón motivadora detrás de AA es muy simple pero fundamental: las transacciones de Ethereum hoy tienen efectos programables (logrados a través de llamadas a contratos inteligentes) pero tienen una validez fija en el sentido de que las transacciones son válidas solo si tienen una firma ECDSA válida con un nonce válido y tienen un saldo de cuenta suficiente. AA actualiza las transacciones de una validez fija a una validez programable al introducir un nuevo tipo de transacción de AA que siempre se origina desde una dirección especial para la cual el protocolo no requiere firma, nonce o verificación de saldo. La validez de tales transacciones de AA es determinada por un contrato inteligente objetivo que puede hacer cumplir sus propias reglas de validez después de lo cual puede decidir pagar por tales transacciones.

Entonces, ¿por qué es esto útil? Tomemos el ejemplo de las carteras de Ethereum para resaltar el beneficio de AA.

Carteras de Contratos Inteligentes: La mayoría de las carteras de Ethereum hoy en día son carteras EOA que están protegidas por una clave privada generada a partir de una frase semilla. (A BIP-39La frase semilla o mnemotécnico es una lista ordenada de 12-24 palabras que se eligen al azar de una lista de 2048 palabras. Esto proporciona la entropía necesaria para obtener una semilla binaria que se genera utilizando la función PBKDF2. La semilla binaria se utiliza luego para generar los pares de claves asimétricas para el BIP-32 wallet.) Se espera que el usuario anote la frase semilla en un lugar seguro porque podría ser necesaria más tarde para restaurar las claves en otro monedero. Sin embargo, estos monederos son vulnerables al robo de claves privadas o a la pérdida de frases semilla, lo que resulta en la pérdida de fondos del usuario.

Las carteras de contratos inteligentes se implementan en la cadena a través de contratos inteligentes (como su nombre lo sugiere). Estas carteras ofrecen mitigación de riesgos programable y una experiencia fácil de usar mediante la implementación de funciones como seguridad multinivel, recuperación social o basada en el tiempo, limitación de la tasa de transacciones o montos, lista de direcciones permitidas/prohibidas, meta-transacciones sin gas y transacciones agrupadas.

Si bien las carteras de contratos inteligentes están expuestas a riesgos de seguridad debido a contratos inteligentes vulnerables, este riesgo puede mitigarse mediante pruebas de seguridad y revisiones realizadas por el proveedor de la cartera. El riesgo en las carteras EOA recae enteramente en el usuario de la cartera, quien está encargado de la seguridad de la frase semilla sin ninguno de los salvaguardas programables que son posibles con contratos inteligentes.

Ejemplos de billeteras de contratos inteligentes son Argent, Authereum, Dapper, Dharma, Gnosis Safe, Monolito y MYKEY. La adopción de tales billeteras parece estar aumentando, como lo indica lo siguiente gráfico.

Argent implementa la recuperación social sin semilla con su concepto de Guardianes que son personas o dispositivos de confianza del usuario que pueden ayudar a recuperar la billetera del usuario. Argent también tiene como objetivo habilitar una seguridad similar a la bancaria (a través de funciones como límites de transacción diarios, bloqueo de cuenta y contactos de confianza) combinada con una usabilidad similar a Venmo (a través del uso de nombres de ENS en lugar de direcciones y soporte para meta-transacciones).

Gnosis Safe es una cartera inteligente multi-firma que se centra en la gestión del equipo de fondos que requiere un número mínimo (m-de-n) de miembros del equipo para aprobar una transacción antes de que pueda ocurrir. También permite firmas sin gas a través de meta-transacciones.

Todas estas capacidades avanzadas de la cartera requieren el uso de contratos inteligentes no triviales. Los usuarios de la cartera necesitan un EOA con gas para interactuar con ellos o dependen del proveedor de la cartera para admitir meta-transacciones a través de los retransmisores del proveedor o redes de retransmisión de terceros como Red de Estaciones de Gas. Mientras que el primero se basa típicamente en ETH comprado en intercambios centralizados después de KYC, el último tiene como objetivo reducir esta fricción de incorporación de UX transfiriendo la carga del usuario a los relayers por un costo que es compensado por el proveedor de billetera en cadena o fuera de ella y/o por el usuario fuera de cadena.

Sin embargo, las arquitecturas basadas en relayers tienen tres inconvenientes principales: (1) Pueden ser considerados como intermediarios centralizados con potencial para censurar transacciones (2) Son técnicamente/económicamente ineficientes debido a la tarifa base adicional de 21000 gas necesaria para la transacción del relayer y a su necesidad empresarial de obtener beneficios además de las tarifas de gas (3) El uso de protocolos específicos de relayers obliga a las aplicaciones a depender de infraestructuras de Ethereum que no son de capa base con bases de usuarios más pequeñas y garantías de disponibilidad inciertas.

La Abstracción de Cuenta permitirá a las carteras de contratos inteligentes aceptar meta-transacciones sin gas del usuario y pagar por su gas sin depender de las redes de retransmisión. Esta capacidad de capa base mejorará significativamente la experiencia de incorporación de dichas carteras sin sacrificar las garantías de descentralización de Ethereum.

Tornado Cash: Una aplicación motivadora relacionada es la de un mezclador como tornado.cashdonde@tornado.cash/introducing-private-transactions-on-ethereum-now-42ee915babe0">Tornado mejora la privacidad de las transacciones al romper el vínculo en cadena entre direcciones utilizando un contrato inteligente que acepta depósitos de ETH que luego pueden ser retirados por una dirección diferente. Se espera que el usuario proporcione el hash de un secreto durante el depósito y luego proporcione una prueba zkSnark durante el retiro para mostrar el conocimiento del secreto sin revelar el secreto o el depósito anterior en sí mismo. Esto desvincula el retiro del depósito.

Pero hay un problema del huevo y la gallina con la retirada. Para ejecutar una transacción de retiro desde una dirección recién generada, el usuario necesita tener algo de ETH en ella para pagar por el gas. La fuente de este ETH (típicamente un intercambio) puede comprometer la privacidad de Tornado. La alternativa preferida es volver a utilizar una red de retransmisión que tiene los inconvenientes descritos anteriormente.

La Abstracción de Cuenta resolverá este problema al permitir que el contrato Tornado acepte la transacción de retiro del usuario AA, valide el zkSnark, deduzca algunas tarifas de gas (del monto de depósito anterior) y luego transfiera el resto del monto de depósito a la dirección de retiro.

Abstracción de cuenta

La Abstracción de Cuenta, según lo propuesto en EIP-2938, permite que un contrato sea la cuenta de nivel superior que paga las tarifas y comienza la ejecución de transacciones. Esto se logra mediante la introducción de cambios en el protocolo con un nuevo tipo de transacción AA que requiere dos nuevos opcodes: NONCE y PAYGAS, cambios en las reglas de la mempool y extensiones para admitir usos avanzados. Los tipos de cuentas siguen siendo dos (EOA y Cuenta de Contrato) y todos los cambios propuestos son compatibles con las transacciones actuales, los contratos inteligentes y el protocolo.

Las aplicaciones de AA se consideran en dos categorías: 1) Aplicaciones de un solo inquilino como billeteras de contratos inteligentes, que crean un nuevo contrato para cada usuario 2) Aplicaciones de varios inquilinos como tornado.cash o Uniswap, donde varios usuarios interactúan con el mismo conjunto de contratos inteligentes.

El soporte AA para aplicaciones multiinquilino requiere más investigación y se propone como trabajo futuro. Por lo tanto, nos centraremos en el soporte AA para inquilinos únicos en este artículo.

Cambios de Protocolo

Se ha introducido un nuevo tipo de transacción junto con dos opcodes de soporte NONCE y PAYGAS. Estos son los únicos cambios en el protocolo.

Transacción AA: Se introduce un nuevo tipo de transacción AA_AA_TX_TYPE. Su carga útil se interpreta como RLP([nonce, target, data]) en lugar del tipo de transacción existente cuya carga útil es RLP([nonce, gas_price, gas_limit, to, value, data, v, r, s]).

El gas_price y gas_limit omitidos en la transacción AA son especificados por el contrato AA de destino durante la ejecución. La firma ECDSA v, r, s omitida en la transacción AA es reemplazada por verificaciones de contrato específicas en los datos. La dirección de destino es reemplazada por la dirección de contrato de destino. El valor se omite porque la dirección de origen para todas las transacciones AA es una dirección de PUNTO DE ENTRADA especial (0xFFFF…FFFF) y no una EOA que tenga un valor asociado a ella.

Los 'nonces' se procesan de manera análoga a las transacciones existentes mediante la comprobación de si tx.nonce == tx.target.nonce. Si esta comprobación falla, entonces la transacción se considera inválida, de lo contrario, tx.target.nonce se incrementa y la transacción continúa.

El costo base de gas de una transacción AA se propone que sea de 15000 en lugar de los actuales 21000 (para reflejar el ahorro de costos por la falta de firma ECDSA intrínseca). Además, las transacciones AA no tienen un límite de gas intrínseco. Al comenzar la ejecución, el límite de gas simplemente se establece en el gas restante en el bloque.

La instrucción NONCE: La instrucción NONCE (0x48) empuja el nonce del destinatario, es decir, el contrato de destino AA, a la pila EVM. Los nonces se exponen así a la EVM para permitir que la verificación de firma se realice sobre todos los campos de transacción (incluido el nonce) como parte de la validación en el contrato AA.

La operación PAYGAS: la operación PAYGAS (0x49) toma dos argumentos de la pila: (superior) número_de_versión, (segundo desde arriba) inicio_de_memoria. El número_de_versión permite a las implementaciones futuras cambiar la semántica de la operación. Actualmente, la operación tiene la siguiente semántica:

1. Compruebe version_number == 0 (de lo contrario, lance una excepción)
2. Lea gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])
3. Lea gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])
4. Verificar contrato.balance >= gas_price * gas_limit (si no, lanzar excepción)
5. Verifique globals.transaction_fee_paid == False (de lo contrario, lance una excepción)
6. Compruebe si el marco de ejecución de AA es igual al marco de nivel superior, es decir, si la ejecución actual de EVM sale o revierte, la ejecución de EVM de toda la transacción se termina (de lo contrario, se produce una excepción)
7. Establecer contrato.balance -= gas_price * gas_limit
8. Establecer globals.transaction_fee_paid = Verdadero
9. Establecer globals.gas_price = gas_price y globals.gas_limit = gas_limit
10. Establecer el contexto de ejecución actual remaining_gas = gas_limit - gas ya consumido

Al final de la ejecución de la transacción AA, (globals.gas_limit - remaining_gas)globals.gas_price se transfiere al minero y el contrato AA se reembolsa con remaining_gasglobals.gas_price.

PAYGAS actúa como un punto de control de ejecución de EVM. Cualquier reversión después de este punto solo se revertirá hasta aquí y luego el contrato no recibe reembolso y globals.gas_limit * globals.gas_price se transfiere al minero.

El nuevo tipo de transacción y los dos nuevos códigos de operación constituyen los cambios a nivel de protocolo/consenso y su semántica es relativamente sencilla de analizar.

Reglas de la mempool

"La mempoolse refiere al conjunto de estructuras de datos en memoria dentro de un nodo Ethereum que almacena transacciones candidatas antes de ser minadas. Geth lo llama la “pool de transacciones”; Parity lo llama la “cola de transacciones.” Independientemente del nombre, es una pool de transacciones que están en memoria esperando ser incluidas en un bloque. Piénselo como un “área de espera” para las transacciones que serán aceptadas en un bloque.

Actualmente, con reglas fijas de validez de transacción, los mineros y otros nodos necesitan un esfuerzo mínimo para validar transacciones en su mempool y así evitar ataques DoS. Por ejemplo, un minero puede estar seguro de que una transacción realmente pagará la tarifa si tiene una firma ECDSA válida, un nonce válido y un saldo de cuenta suficiente. Otras transacciones en la mempool de ese minero pueden invalidar esta transacción pendiente solo si son de la misma dirección y, o bien aumentan el nonce o reducen suficientemente el saldo de la cuenta. Estas condiciones son mínimas computacionalmente para dar a los mineros y nodos suficiente confianza en sus mempools para la consideración o rebroadcasting de bloques respectivamente.

Las transacciones AA introducen más complejidad con su validez programable. Las transacciones AA no pagan gas por adelantado y dependen de sus contratos AA objetivo para pagar el gas (a través de PAYGAS). Conceptualmente, el procesamiento de transacciones AA se divide en dos fases: la fase de verificación más corta (antes de PAYGAS) y la fase de ejecución más larga (después de PAYGAS). Si la fase de verificación falla (o arroja una excepción), la transacción es inválida (igual que una transacción no-AA con una firma inválida hoy), no se incluye en un bloque y el minero no recibe tarifas.

Por lo tanto, los mineros y nodos necesitan un mecanismo predecible para evitar la dependencia de la validez de una transacción AA pendiente en otras transacciones pendientes en el mempool. De lo contrario, la ejecución de una transacción podría invalidar muchas o todas las transacciones AA en el mempool, lo que conduciría a ataques de denegación de servicio (DoS). Para evitar este escenario, existen dos reglas propuestas que deben ser aplicadas (por los mineros y nodos, pero no en el propio protocolo) a las transacciones AA en los mempools:

Restricción de la operación de código

Para evitar que la validez de la transacción AA dependa de cualquier estado externo al contrato AA en sí, se consideran inválidos los siguientes opcodes en la fase de verificación (es decir, antes de PAYGAS): opcodes del entorno (BLOCKHASH, COINBASE, TIMESTAMP, NUMBER, DIFFICULTY, GASLIMIT), BALANCE (de cualquier cuenta, incluida la propia cuenta de destino), una llamada/creación externa a cualquier cosa que no sea el destino o un precompilado (CALL, CALLCODE, STATICCALL, CREATE, CREATE2) y el acceso al estado externo que lee el código (EXTCODESIZE, EXTCODEHASH, EXTCODECOPY, DELEGATECALL) a menos que la dirección sea el destino.

Se espera que los nodos eliminen las transacciones AA en el mempool que apunten a contratos AA que rompan esta regla de restricción de opcodes. Esto asegura que las transacciones AA válidas en el mempool seguirán siendo válidas siempre que el estado del contrato AA no cambie.

Restricción de prefijo de bytecode

Si las transacciones no-AA pueden afectar el estado de los contratos AA, eso afectará la validez de las transacciones AA en el mempool. Para evitar esto, las transacciones AA solo deben poder apuntar a contratos que tengan un AA_PREFIX al principio de su bytecode, donde AA_PREFIX implementa una verificación de que msg.sender es la dirección especial ENTRY_POINT de las transacciones AA. Esto previene efectivamente que las transacciones no-AA interactúen con los contratos AA.

Se espera que los nodos descarten transacciones AA a contratos AA que no tengan este AA_PREFIX en sus puntos de entrada de bytecode.

Estas dos restricciones impuestas en los contratos de AA juntos aseguran que: (1) el único estado accesible para la lógica de validez de una transacción de AA es el estado interno del contrato de AA y (2) este estado solo puede ser modificado por otras transacciones de AA que apunten a este contrato de AA específico.

Una transacción AA pendiente a un contrato AA solo puede ser invalidada por un bloque que contenga otra transacción AA dirigida al mismo contrato AA. Sin embargo, dado que no se trata de cambios en el protocolo/consenso, los mineros pueden incluir transacciones en un bloque que rompan estas reglas.

Extensiones

Los cambios de protocolo anteriores y las reglas de la mempool permiten que los contratos AA básicos implementen de manera suficiente y segura aplicaciones de inquilinos únicos como billeteras de contratos inteligentes. Otros usos avanzados que necesitan relajación de las reglas anteriores o necesitan implementar aplicaciones de inquilinos múltiples requieren un mayor apoyo de AA en forma de extensiones como:

1. El opcode SET_INDESTRUCTIBLE, que deshabilita SELFDESTRUCT y permite a los contratos AA llamar a bibliotecas con DELEGATECALL de forma segura en la fase de verificación.
2. El opcode IS_STATIC, que devuelve true si el contexto actual es estático y permite a los llamadores de transacciones no-AA anular la restricción de prefijo de bytecode anterior y leer valores de contratos AA de forma segura.
3. El opcode RESERVE_GAS, que establece un límite inferior en el gas consumido por el contrato AA cuando es invocado desde una transacción no AA que intenta escribir el estado del contrato. Esto sirve para obligar a los atacantes a gastar una cantidad mínima de gas para desincentivar los intentos de invalidar cualquier transacción AA en el mempool.

Hay otros como múltiples transacciones pendientes, resultados en caché de validación, límites de gas dinámicos para validación y transacciones patrocinadas que son necesarios para soportar aplicaciones multiinquilino y pruebas zk como Tornado Cash. Su discusión está fuera del alcance de este artículo.

Próximos Pasos

La Propuesta de Mejora de la Abstracción de Cuentas EIP-2938 está actualmente en modo de borrador y se está discutiendo en los foros de investigación de Ethereum. El próximo paso para la EIP es ser considerada para su inclusión en uno de los próximos hard forks. Al parecer, los autores de la EIP están apuntando al hard fork después de Berlín (Berlín está programado tentativamente para algún momento enprincipios de 2021) cuya línea temporal no está muy clara en este momento. Por lo tanto, todavía es temprano en el proceso para EIP-2938.

Además, tampoco está claro que sea necesario incluir EIP-2938 en la capa base de Ethereum 1 (L1). Dada la flexibilidad relativa de las soluciones de Capa 2 (L2) (como se describe en nuestro anterior artículo) La Abstracción de Cuentas puede implementarse en L2 específicos sin necesidad de actualizar todo el L1. Sin embargo, existen beneficios en el soporte uniforme de AA en L1 incluso si algunos L2 implementan sus propias versiones de AA. Por lo tanto, queda por ver dónde y cómo se implementa AA.

"La abstracción de la cuenta es algo menos importante, porque se puede implementar en L2 independientemente de si L1 lo admite o no." — Vitalik sobre las cosas que seguirían siendo importantes en la capa base (en su publicaren la hoja de ruta centrada en rollup de Ethereum).

Estado: La billetera de Status actualmente es una billetera EOA que se diferencia por la inclusión de un mensajero centrado en la privacidad y la habilitación de integraciones como pagos en el chat o seguridad mejorada con Tarjeta claveLas funciones de billetera de contrato inteligente como multisig y recuperación social se están considerando para las cuales el soporte AA EIP-2938 ayudará al eliminar la dependencia de arquitecturas centralizadas e ineficientes basadas en relayers, como se describió anteriormente.

Status también está evaluando soluciones L2 tanto para soportar múltiples cadenas en su billetera como para proporcionar la escalabilidad requerida para varios casos de uso, como se describe en nuestro anterior.artículoPor ejemplo, Keycard está explorando un red de pagoscuyos requisitos de diseño de escalabilidad a nivel de tarjeta de crédito y finalidad casi instantánea no son cumplidos por la red Ethereum hoy. Además, existen numerosas otras iniciativas como el Programa de referidos, reacciones SNT, Tributo-a-Hablarynombres ENS, todos los cuales se beneficiarían de la escalabilidad L2 para una implementación factible y una experiencia de usuario razonable. Si una solución L2 viable implementa AA, entonces los proyectos que se basen en esa L2 podrán aprovechar los beneficios de AA sin tener que depender de L1.

Resumen

Un aspecto fundamental del protocolo de Ethereum es que solo las Cuentas de Propiedad Externa (EOAs, por sus siglas en inglés) pueden pagar tarifas de gas y comenzar la ejecución de transacciones. Las Cuentas de Contrato (CAs) no pueden hacerlo. La Abstracción de Cuenta (AA) es una propuesta que tiene como objetivo cambiar esta distinción y permitir que las CAs especialmente construidas verifiquen programáticamente la validez de un nuevo tipo de transacciones de AA, decidan pagar las tarifas de gas en su nombre y así comenzar efectivamente su ejecución sin la necesidad de un EOA.

AA tiene implicaciones para mejorar significativamente la experiencia del usuario en diversos escenarios, como billeteras, mezcladores, ÐApps y DeFi, sin depender de arquitecturas centralizadas e ineficientes basadas en relayers. Escenarios básicos de un único inquilino, como las billeteras de contratos inteligentes, pueden ser admitidos de forma segura por AA con la introducción de un nuevo tipo de transacción, dos nuevas opcodes y dos reglas de mempool. Las aplicaciones avanzadas de varios inquilinos, como Tornado Cash, requieren extensiones a estos cambios de protocolo y reglas de nodo.

En este artículo, motivamos la necesidad de AA en el contexto de las carteras de contratos inteligentes. Destacamos aspectos clave de AA describiendo los cambios de protocolo y el impacto en los nodos. Tocamos algunas de las extensiones propuestas para usos avanzados y finalmente concluimos posicionando AA en el contexto de los mapas actuales de Ethereum y las prioridades en Status.

Reducir la fricción y mejorar la experiencia del usuario en Web3 es una prioridad principal para todos los proyectos en este ecosistema. La Abstracción de Cuenta, en alguna forma, ciertamente puede desempeñar un papel importante en este esfuerzo en el futuro.

Descargo de responsabilidad：

1. Este artículo ha sido reimpreso de [estado], Reenviar el Título Original 'Abstracción de Cuenta (EIP-2938): ¿Por qué y qué?', Todos los derechos de autor pertenecen al autor original [Rajeev Gopalakrishna]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo y lo resolverán rápidamente.

2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente del autor y no constituyen consejos 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 lo contrario, está prohibido copiar, distribuir o plagiar los artículos traducidos.