Introducción

Lo que almacenan y a lo que se refieren las blockchains mientras procesan transacciones se llama estado. En Ethereum, el estado es la propiedad que facilita el consenso de los nodos. Cada nodo completo necesita almacenar y actualizar este estado durante cada período de bloques válidos. El estado, por importante que sea para las blockchains, tiene un inconveniente: crece con el tiempo. Son un problema importante en las blockchains, como Bitcoin y Ethereum, porque el aumento de tamaño conlleva un aumento igual en los requisitos de hardware para los nodos. El umbral de espacio elimina algunos nodos con el tiempo, lo que lleva a la centralización.EIP-2935propone llevar la falta de estado a Ethereum, aliviando a los nodos de la carga de tamaño. EIP-2935 es una propuesta de mejora que intenta lograr la falta de estado almacenando y sirviendo los últimos 8192 hash de bloque del estado para la ejecución sin estado en Ethereum.

Breve visión general de la estructura actual de Ethereum

Bloques

Los bloques son lotes de transacciones con una referencia (hash) del bloque anterior incluido en la cadena. Los hashes en cada bloque se derivan criptográficamente de los datos del bloque en sí. Esta inclusión enlaza las cadenas con hashes y la agrupación implica que todos los participantes en la red estén de acuerdo y sincronicen el estado al mismo tiempo. Además, el acuerdo sobre los bloques agrupados señala a Ethereum que actualice su estado global en cada participante en la red como un nodo.

Alt: Cambio de estado en Ethereum

Una vez que un nuevo bloque es manejado y difundido con un validador en la red, el resto de los participantes lo añaden a su almacenamiento y actualizan su estado global. El validador de cada bloque es seleccionado al azar por el Organización Autónoma Descentralizada Aleatoria (RANDAO)El parámetro. La estructura del bloque está estrictamente ordenada, y la creación de bloques y los procesos de consenso están especificados bajo el protocolo de prueba de participación de Ethereum.

Un bloque contiene varios campos en su encabezado y cuerpo. Por ejemplo, el encabezado del bloque incluye los campos de slot, proposer_index, parent_root, state_root y body. El cuerpo del bloque incluye randao_reveal, eth1_data, graffiti, proposer_slashings, attester_slashings, attestations, deposits, voluntary_exits, sync_aggregate y execution_payload. Cada campo tiene diferentes parámetros en él y maneja diferentes necesidades.

Ethereum’s 12 segundosEl período de creación de bloques, también llamado un “slot”, proviene de permitir suficiente tiempo para que los participantes de la red se sincronicen con los nuevos bloques y acuerden el consenso. Durante este período:

1. El proponente de bloque selecciona aleatoriamente un validador,
2. El validador agrupa las transacciones y las ejecuta para determinar un nuevo estado global,
3. Incluyen esta información en un nuevo bloque y la transmiten al resto del conjunto de validadores a través de un protocolo de chismes,
4. Otros validadores vuelven a ejecutar las transacciones para asegurar la validez y estar de acuerdo con el cambio de estado global como consenso,
5. Si el validador verifica el nuevo bloque como válido, lo agregan a su almacenamiento.

La finalidad de un bloque y una transacción significa que no se puede cambiar sin una quema significativa de ETH en una red distribuida. Ethereum tiene un enfoque de "bloques de control" para gestionar la finalización. Se asume que el primer bloque en cada época es el punto de control de esa franja. Los validadores votan por esta suposición para que sea un punto de control válido. Si dos tercios del ETH total apostado con votos de validadores eligen un par de puntos de control, los puntos de control se actualizan a justificados. Los puntos de control justificados anteriores se actualizan después de la próxima actualización de puntos de control, y se vuelven finalizados. Si un actor malicioso quiere revertir un bloque finalizado, necesita comprometerse a perder al menos un tercio del suministro total de ETH apostado. Aunque existe un mecanismo llamadofuga de inactividadexiste para restaurar la finalidad imponiendo grandes penalizaciones a los fondos del validador y reduciendo las recompensas del validador en caso de un fallo permanente de un gran número de validadores.

Al procesar el bloque, Ethereum aplica una función hash para tomar los datos de los bloques y reducirlos a cadenas únicas. En la función hash, cada entrada produce una salida única. Los valores hash en los bloques son la única parte inmutable. Es modificable con un tercio del ETH total apostado quemado. Sin embargo, esta cantidad proviene de recalcular los hashes del árbol de Merkle hasta un punto de control. La salida del proceso de hash para cada bloque se devuelve con el parámetro blockHash. El parámetro blockHash incluye todos los datos en el bloque.

Los valores hash de los bloques y otros parámetros necesarios se almacenan en árboles de Merkle. Ethereum utiliza la arquitectura de árbol de Merkle con diferentes versiones, como el árbol de Merkle Patricia.

Tries de Merkle y Merkle Patricia

Las estructuras de árboles, especialmente los árboles de Merkle, son fundamentales para el almacenamiento en la cadena de bloques. Sin los árboles de Merkle, las cadenas de bloques se convierten en bloques individuales que son difíciles de procesar cada vez. Con los árboles de Merkle, o en general las arquitecturas de árboles, las cadenas de bloques logran completitud con fragmentos básicos. Esto les permite convertirse en participantes de la red con bajos requisitos de hardware.

Los árboles de Merkle son una forma estructurada de hashear grandes cantidades de trozos y dividirlos en partes. Con la Merkleización, los datos se organizan en pares; cada uno se hashea juntos. El proceso de Merkleización se repite hasta obtener una única raíz de Merkle.

Ethereum prefiere Merkle Patricia Tries, una estructura de árbol de Merkle dual. Utiliza Binary Tries para el manejo de datos básicos, como datos de transacciones, ya que este enfoque es más eficiente para tales situaciones. Sin embargo, Ethereum utiliza los más complejos Merkle Patricia Tries en casos más complejos, como el manejo de estado.

En un escenario de almacenamiento de datos del árbol de estado, Ethereum utiliza un mapa de clave-valor. Las claves representan direcciones y los valores representan declaraciones de cuenta. Los árboles de estado son más dinámicos que los árboles binarios. Por lo tanto, se pueden insertar con frecuencia nuevas cuentas, y las claves se pueden insertar y eliminar con frecuencia. Este proceso requiere una estructura de datos que se pueda actualizar rápidamente sin necesidad de recalcular todo el conjunto de datos.

La raíz del trie depende solo de los datos, no del orden. Hacer actualizaciones a los datos en diferentes órdenes no cambiará la raíz en sí misma.

Alt: Árbol de Prueba Merkle Binario

Ethereum utiliza un árbol de Patricia Merkle modificado, que tiene algunas características dePATRICIA (Algoritmo Práctico para Recuperar Información Codificada en Alfanumérico)y Merkle Trie con modificaciones a lo largo de él. Esta arquitectura es determinista y criptográficamente verificable. La única forma de generar una raíz de estado en esta estructura es calculándola a partir de cada pieza individual de estado. Dos estados idénticos pueden ser fácilmente demostrados comparando el hash de raíz y los hashes que lo llevaron a él.

En última instancia, modificar el estado con diferentes valores es imposible porque resultará en un hash de raíz de estado diferente. Todas las estructuras de árbol en la capa de ejecución de Ethereum utilizan un árbol de Patricia de Merkle. La red tiene tres árboles: Árbol de Estado, Árbol de Almacenamiento y Árbol de Transacciones. Además, cada bloque tiene su propio Árbol de Recepciones. Si bien los árboles de Patricia de Merkle son eficientes de muchas maneras, Ethereum está motivado a sustituirlos por Árboles de Verkle para lograr la ausencia de estado.

Alt: Árbol Patricia Merkle

Gas

El gas es la propiedad necesaria en EVM para la ejecución. Dado que EVM utiliza y necesita recursos computacionales para ejecutarse, el retorno de estos esfuerzos se paga con gas para garantizar la seguridad de EVM. La tarifa de gas se calcula como la cantidad requerida de gas multiplicada por el costo por unidad. Es un valor dinámico y depende del tipo de operación.

Alt: https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf

EIP-1559introdujo algunos cambios significativos en el mecanismo de tarifas de transacción. Pagar por gas para incluir transacciones en los bloques trabajó con un método tipo subasta en el pasado. Con EIP-1559, hay un límite mínimo llamado tarifa base y una propina llamada tarifa de prioridad introducida. Se propone que los bloques comiencen desde la transacción con la tarifa de prioridad más alta. Después del proceso de bloque, la tarifa base se quema y la tarifa de prioridad se utiliza para incentivar a los validadores.

Estado

El estado de la cadena de bloques se puede definir como un conjunto de datos (o variables) que describen un cierto sistema en un periodo específico. Internet tiene estado casi desde el principio, pero estaba almacenado en un único servidor. Con Web3, se introdujo un estado global mantenido en una red abierta y distribuida asegurada a través de métodos descentralizados. Todos pueden ver y verificar el estado de la red distribuida en cualquier momento que deseen.

Ethereum incluye cuentas, saldos, contratos inteligentes desplegados y almacenamiento asociado en el estado global. El estado de Ethereum crece con las adiciones y cambios en estos parámetros. El crecimiento del estado se vuelve problemático cuando el costo del hardware para alojar un nodo completo se vuelve prohibitivo. Ante estos desafíos, Vitalik Buterin introducidoel concepto de Ethereum sin estado en 2017. Los métodos propuestos para solucionar el crecimiento del estado en Ethereum incluyen la expiración de datos y estado.

Diferencias entre la caducidad de datos y la caducidad de estado

Caducidad de datos

La expiración de datos o historial significa deshacerse de los datos innecesarios de los clientes después de cierto período. Con los "puntos de control de subjetividad débil", los clientes podrían encontrar su camino para sincronizarse desde el génesis y podar los datos históricos de desecho.

La subjetividad se refiere a los nodos de una red que dependen de la información social para llegar a un consenso sobre el estado actual. En este sentido, la subjetividad débil se refiere a una cadena que puede progresar objetivamente con alguna semilla inicial de información recuperada socialmente. Sin embargo, los puntos de control de subjetividad débil implican que todos los nodos en la red responsables del consenso pertenecen a la cadena canónica. Los puntos de control de subjetividad débil ayudan a Ethereum PoS a tener el estado reciente (punto de control de subjetividad débil) de una fuente confiable para sincronizarse desde.

EIP-4444proporciona el camino práctico hacia@hBXHLw_9Qq2va4pRtI4bIA/ryzBaf7fJx?ref=ghost-2077.arvensis.systems">alcanzar la expiración de datos a través de la debilidad-subjetividad. La propuesta no tiene como objetivo cambiar cómo los nodos de Ethereum manejan los datos de estado; más bien, modifica el acceso a los datos históricos.

Expiración del estado

State Expiry busca eliminar el estado de los nodos individuales si no ha sido accedido recientemente. La expiración puede ser implementada mediante la terminación siendo un factor de alquiler o tiempo. La expiración por alquiler significa imponer un recargo a las cuentas por almacenar el estado. Por otro lado, la expiración por tiempo significa desactivar las cuentas si permanecen inactivas durante un cierto período.

Tanto la Caducidad de Datos como la Caducidad de Estado son áreas de investigación abiertas. Los enfoques actuales para lograr estos estados propuestos implican pasarlos a través de redes/proveedores centralizados. Hasta ahora, la falta de estado sin estado y la caducidad de estado se han logrado parcialmente en Ethereum.

Ethereum sin estado

Introducción a la Falta de Estado y Ethereum sin Estado

Ethereum sin estado introduce nuevos conceptos en el protocolo central. Idealmente, la falta de estado no implica que el estado no exista. Más bien, significa que los clientes pueden elegir el estado que desean mantener. Cuando los clientes reciben bloques validados, también reciben el testigo correspondiente a ese bloque. Los testigos de cada bloque consisten en todos los datos necesarios para ejecutar las transacciones contenidas en ese bloque.

EIP-161introdujo el primer enfoque de reducción de estado. Ethereum sufrió un ataque de DoS (Denegación de Servicio) y esta vulnerabilidad le permitió crear cuentas vacías que aumentaron el estado global de Ethereum. EIP-161 propuso eliminar las cuentas vacías con valor cero (0) en su nonce que provenían de este ataque, con bajos costos. La propuesta se ejecutó, lo que resultó en una reversión de estado.

Otro esfuerzo hacia la falta de estado fue propuesto a través de EIP-4788. Esta propuesta buscaba exponer las raíces de los bloques de la cadena de faros en el EVM. Similar al enfoque del Puente Eth1-Eth2conectando la cadena Beacon (capa de consenso) y la capa de ejecución, esta propuesta permite acceso con minimización de confianza entre EVM y la capa de consenso.

Porque cada bloque de ejecución contiene la raíz del bloque de referencia principal, los eventos de ranura perdidos no necesitarían cambiar la raíz del bloque anterior. Por lo tanto, los requisitos previos de ejecución se reducen a reservar un pequeño espacio para un oráculo minimizado de confianza en cada bloque de ejecución. La propuesta sugiere almacenar un pequeño historial de raíces de bloque en un contrato raíz para mejorar la eficiencia del oráculo.

La falta de estado en Ethereum es posible ya sea como una falta de estado débil o fuerte.

Estado de debilidad

La debilidad de la falta de estado es un estado que no elimina la necesidad de almacenamiento de estado en todos los nodos. En cambio, difiere en cómo los nodos verifican los cambios en el estado de Ethereum. Coloca la responsabilidad del almacenamiento de estado en los proponentes de bloques y requiere que otros nodos verifiquen los bloques sin almacenar los datos de estado completos.

Los proponentes de bloques necesitan almacenar datos de estado completos. Sin embargo, los clientes verificadores no tienen que almacenar los datos de estado en la red. En su lugar, pueden almacenar la raíz del estado (un hash de todo el estado). La falta de estado débil requiere Separación de proponente-Constructor (PBS)yVerkle intentaimplementación.

Los proponentes crean testigos utilizando los datos del estado para demostrar los cambios de estado, y los validadores verifican las pruebas contra el hash raíz del estado.

Fuerte Ausencia de Estado

La fuerte falta de estado elimina la necesidad de que cualquier nodo almacene los datos de estado. Funciona incorporando transacciones enviadas y testigos agregados por los proponentes de bloque. Los proponentes de bloque almacenan el único estado en el que están trabajando, generando testigos para las cuentas relevantes. La propuesta aún necesita más desarrollo e incluye requisitos como Listas de Acceso o EIP-2930.

Sin embargo, algunos cambios y propiedades pueden ser utilizados para lograr la falta de estado. EIP-2935 propone servir hashes de bloques históricos desde el estado para permitir la ejecución sin estado.

Introducción a EIP-2935

EIP-2935 tiene como objetivo guardar los hash de bloque históricos en el estado de la cadena de bloques en espacios de almacenamiento especiales llamados HISTORY_STORAGE_ADDRESS. Este proceso permitirá la ejecución sin estado al facilitar el acceso fácil a la información histórica necesaria en los clientes sin estado.

EIP-2935 propone almacenar los últimos 8192 hash de bloques históricos en un contrato del sistema para utilizarlos como parte de la lógica de procesamiento de bloques. El problema que esta propuesta intenta resolver es la suposición de la EVM de que el cliente tiene el hash de bloque reciente. Este enfoque basado en suposiciones no se aplica a Ethereum futuro y especialmente a los clientes sin estado.

Incluir los hashes de bloques anteriores en el estado permitirá agrupar estos hashes con funciones hash a la vista de un testigo. Posteriormente, se proporcionará un testigo al cliente sin estado para verificar la ejecución y lograr una ejecución sin estado. Esta propuesta se llama especiación previa a Verkle porque se puede implementar antes de la adaptación a los intentos de Verkle en el protocolo central, y facilita la falta parcial de estado.

Extender el rango de bloques que blockHash sirve a 8192 bloques permitirá una transición suave a los métodos de ejecución. Los Rollups pueden beneficiarse de esta ventana de historial más larga consultando directamente este contrato porque los datos de blockHash se almacenan en este contrato. Además, este EIP facilitará la validación de pruebas relacionadas con la cantidad de 8192 bloques de HISTORY_SERVE_WINDOW contra el estado actual.

Comprendiendo EIP-2935

EIP-2935 permite a los clientes de Ethereum, especialmente a los sin estado, acceder fácilmente a los hashes de bloques recientes. Para que esto funcione, introduce cuatro nuevos parámetros:

• BLOCKHASH_SERVE_WINDOW: Indica a los clientes cuántos hashes de bloque pasados deberían conservar. El valor predeterminado es 256.
• HISTORY_SERVE_WINDOW: Este parámetro define cuántos bloques de hashes se almacenan. El valor predeterminado es 8191.
• SYSTEM_ADDRESS: Una dirección especial (originalmente introducida en EIP-4788) que actúa como el “llamante” para escribir los hashes de bloque en el almacenamiento.
• HISTORY_STORAGE_ADDRESS: La dirección del contrato donde se almacenan estos hashes de bloque.

Las especificaciones de la propuesta indican que los últimos hashes de bloques de HISTORY_SERVE_WINDOW deben almacenarse en un almacenamiento de búfer de anillo con una longitud de HISTORY_SERVE_WINDOW.

Búfer en Anillo

EIP-2935 utiliza una característica adicional llamada un buffer circular para el almacenamiento temporal. Un buffer circular es una propiedad que permite a una red reutilizar el mismo almacenamiento para diferentes datos. El almacenamiento está limitado en el buffer circular a la misma ubicación de almacenamiento cada vez. El buffer circular en EIP-2935 se utiliza solo para servir la ventana de servicio de HISTORIA requerida, ya que EIP-4788 y los acumuladores de estado de beacon permiten la prueba contra cualquier ancestro.

Reglas de elección de bifurcación y especificaciones

Después del fork, cuando la red comience con estas consideraciones de EIP, el parámetro HISTORY_STORAGE_ADDRESS se referirá como SYSTEM_ADDRESS con la entrada block.parent.hash (predeterminado de 32 bytes), límite de gas de 30.000.000 y valor 0. Este proceso activará la función set() del contrato de historial.

El proceso de bifurcación posterior a la propuesta difiere del proceso de bifurcación regular. Esta operación set() es una operación del sistema general, pero la llamada sigue estas convenciones:

• Debe ejecutarse hasta completarse
• No cuenta en el límite de gas del bloque
• No sigue el mecanismo de quemado EIP-1559
• Si no existe código en HISTORY_STORAGE_ADDRESS, la llamada debe fallar sin errores fatales.

Este proceso debe llenar el período de bloque de la ventana de servicio de HISTORIA para cumplir con el período de activación del búfer de anillo. El contrato de historial solo contendrá el hash principal del bloque bifurcado, que sirve como un hash de referencia y el nuevo punto de inicio de hash.

Un contrato de historial de hash de bloque tendrá dos operaciones: get() y set(). La operación set() se activa si el llamante del contrato en una transacción es igual a la DIRECCIÓN_DEL_SISTEMA que se introdujo con EIP-4788. Si el llamante y la DIRECCIÓN_DEL_SISTEMA no son iguales o no cumplen las condiciones, se activa la operación get().

La operación get() se utiliza en EVM para localizar los hash de bloque. Permite a los llamadores proporcionar el número de bloque que están consultando, si la entrada de calldata no es de 32 bytes (lo que significa que es un hash válido de block.parent) y si la solicitud está fuera del rango ([número de bloque-VENTANA_SERVICIO_HISTÓRICO, número de bloque-1]), revierte la transacción.

set() toma block.parent.hash como calldata cuando un llamante llama al contrato con una transacción. También establece el valor de almacenamiento como calldata[0:32] en el block.number-1 % HISTORY_SERVE_WINDOW.

HISTORY_STORAGE_ADDRESS será implementada a través de EIP-4788, que se menciona arriba como la forma de acceder directamente a los hashes de bloque en EVM a través de la capa de consenso. HISTORY_STORAGE_ADDRESS tendrá el valor de nonce como 1 y estará exenta del estándar de limpieza de nonce cero de EIP-161.

Lógica de transición de BLOCKHASH

Una preocupación sobre este EIP es cómo hacer la transición óptima de la lógica de resolución de BLOCKHASH después del fork. Se están considerando dos enfoques principales:

• Espera que HISTORY_SERVE_WINDOW bloques para que toda la historia relevante persista,
• Almacene todos los últimos hashes de bloques HISTORY_SERVE_WINDOW en el bloque de bifurcación.

Los desarrolladores eligen la primera opción. Es más práctica porque no requiere ningún cambio temporal.

¿Cuál es la diferencia entre EIP-2935 y EIPs similares?

Se han propuesto EIP similares anteriormente para permitir y lograr la ejecución sin estado. EIP-2935 difiere de estas propuestas anteriores porque se centra en las complejidades resaltadas a continuación.

• Enfoque de Estructura Trie: EIP-2935 no utiliza una estructura tipo trie con múltiples capas y en su lugar opta por una lista única. Por el contrario, EIP-4444 propuso podar datos históricos en clientes de ejecución más antiguos de un año. Otros EIPs con ambiciones similares tienen tries Verkle como requisitos.
• Escribir el EIP en el código EVM: EIP-2935 no requiere un cambio en el EVM.
• Almacenamiento Serial Ilimitado de Hashes: El almacenamiento serial ilimitado de hash es ineficiente. Este EIP supera este problema al agrupar los hashes.

Consideraciones de seguridad

Dado que EIP-2935 utiliza contratos inteligentes, corre el riesgo de sufrir ataques de envenenamiento de rama. Sin embargo, el tamaño de la raíz del estado hace que cualquier intento de actualización sea lento y un ataque de envenenamiento considerablemente más costoso.

¿Qué podría traer?

• Hacer que los sistemas de oráculos sin confianza sean más rápidos: en los oráculos basados en Uniswap v2, cualquier persona con acceso al nodo Ethereum puede generar una prueba del almacenamiento de Uniswap y enviarla para su validación en la cadena. El precio promedio se determina entre el bloque actual y el bloque de la prueba suministrada, con una prueba validada de hasta 256 bloques, ya que el blockHash admite hasta 256 bloques. Beneficiándose de EIP-2935, este proceso puede mejorarse permitiendo el acceso a hashes de bloques más antiguos, lo que significa que las pruebas pueden validarse durante un período más largo.
• Permitir que los contratos consideren afirmaciones de estados pasados, sin necesidad de confianza: la mejora EIP-2935 crea la posibilidad de examinar los datos de la cadena de bloques desde dentro del EVM, sin requerir confianza. Un cliente puede consultar el historial, obtener su hash y verificarlo con otros nodos. La solución podría hacer que los clientes ligeros sean eficientes y fáciles de implementar.
• Conexión entre L1 <> L2: Para verificar un mensaje de L2, L1 necesita conocer las raíces de estado y los hashes de bloques de L2. Sin embargo, L1 en su estado actual no puede acceder a hashes de bloques arbitrarios debido a límites de gas y limitaciones arquitectónicas. EIP-2935 permite a L1 verificar los datos históricos arbitrarios con la capacidad de sondear pruebas de inclusión para eventos antiguos. El acceso y la potencia de verificación mejorarán, y el rendimiento del puente.

Conclusión

EIP-2935 representa un paso crucial hacia la consecución del objetivo a largo plazo de Ethereum sin estado. Almacenar los últimos 8192 hashes de bloque en un contrato dedicado dentro de las direcciones del estado aborda una limitación fundamental en el diseño actual. La suposición de Ethereum de que los clientes tienen inherentemente acceso a los hashes de bloque recientes. En el contexto de la ejecución sin estado, donde los clientes ya no mantienen el estado completo, esta suposición se vuelve obsoleta. EIP-2935 resuelve esto al introducir un mecanismo ligero, eficiente y no intrusivo que permite a los clientes sin estado acceder a datos históricos necesarios sin modificar el EVM o depender de estructuras de datos complejas como los intentos de Verkle.

Más allá de la ejecución sin estado, esta propuesta desbloquea beneficios más amplios en todo el ecosistema de Ethereum. Mejora las capacidades de los oráculos sin confianza, extiende la usabilidad de los clientes ligeros y fortalece la interoperabilidad entre las soluciones de Capa 1 y Capa 2 al permitir la verificación confiable de datos de estado antiguos. Su implementación se basa en un diseño limpio y eficiente en gas, utilizando almacenamiento de búfer de anillo y contratos a nivel de sistema que evitan la necesidad de codificación rígida en el EVM, ofreciendo tanto simplicidad como escalabilidad.

A medida que Ethereum continúa su evolución hacia una mayor descentralización, escalabilidad y accesibilidad, EIP-2935 sirve como una mejora fundamental. Conecta la brecha entre la arquitectura actual con estado y el futuro sin estado previsto, y sienta las bases para una infraestructura más sólida, eficiente y sin permisos en todo el ecosistema de blockchain.

Descargo de responsabilidad:

1. Este artículo es un reimpreso de [2077investigación]. Todos los derechos de autor pertenecen al autor original [Yiğit Yektin]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo y lo resolverán rápidamente.
2. Descargo de responsabilidad por responsabilidad: Las opiniones y puntos de vista expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. El equipo de Gate Learn realiza traducciones del artículo a otros idiomas. Está prohibido copiar, distribuir o plagiar los artículos traducidos a menos que se mencione.