tl;dr: este artículo enmarca la discusión en torno a la asignación de derechos en Ethereum, proporciona una visión rápida (opinada) del discurso actual y destaca algunas preguntas abiertas al final.
El objetivo de prevenir la centralización impulsada por MEV que socava las propiedades centrales de Ethereum ha dado lugar a una variedad de esquemas propuestos que cambian la forma en que se construyen y proponen los bloques en la red. Estos esquemas como ePBS, MCP o tickets de ejecución reemplazarían el mercado basado en MEV-Boost que tenemos hoy en día (aunque el software MEV-Boost aún puede desempeñar un papel).
Todos estos diseños tienen dos objetivos en común: Como objetivo principal, queremos evitar cualquier incentivo para que los atestiguadores se comporten estratégicamente. Las recompensas en habilidad y los beneficios para la colocación crean presiones centralizadoras en la red que queremos evitar. Como objetivo secundario, queremos mantener el "buen" mercado de constructores. Por "mercado de constructores" nos referimos al mercado que surge en torno al servicio del papel adicional que todos estos esquemas crean además del papel de atestiguador. "Bueno" implica navegar en un espacio de compensación entre descentralización, eficiencia y ingresos del protocolo.
Durante las exploraciones iniciales de este espacio de soluciones, la posición de consenso fue que queremos un gran grado de descentralización entre los atestiguantes, incluso si esto significa que el mercado constructor es bastante "malo" (por ejemplo, el post de la fase final 2). Sin embargo, nunca ha quedado claro en qué punto trazamos la línea y estamos dispuestos a tener menos descentralización entre los atestiguadores para un mejor mercado de constructores. Esta publicación no intenta tomar una postura aquí, sino simplemente hacer accesible el panorama de compensaciones. Este es un problema complejo y hay pocos argumentos que realmente podamos tomar como herméticos y perfectamente predictivos, por lo que esta publicación debe verse como una interpretación del trabajo que se ha realizado pero que ciertamente está sujeta a cambios.
Desde la familia de diseños de Propositor Múltiple Concurrente (MCP), de los cuales TRENZA 3es el esfuerzo de diseño más importante, todavía es bastante nuevo y debe ser desarrollado primero, el artículo discute diseños de único proponente en mayor profundidad y dedica una breve sección a la discusión de MCP al final.
Nota: Se usa "attester" en lugar de "validador" para enfatizar el papel de consenso relativamente simple de atestiguar bloques y participar en la capa p2p en contraste con el papel más complejo de producción y propuesta de bloques que la red asigna técnicamente al mismo actor en la actualidad. Atestador y validador pueden tratarse de manera flexible como intercambiables.
Los Attesters se benefician más del comportamiento estratégico cuando son seleccionados como líderes de consenso para proponer bloques al resto del conjunto de Attesters para un determinado slot. Por lo tanto, la mayoría de los diseños que hemos desarrollado para proteger a los Attesters se han centrado en el papel de proponente. Cada uno de ellos utiliza alguna combinación de tres técnicas:
Cada uno de ellos tiene sus propias limitaciones:
Este bucle de retroalimentación puede no socavar mucho nuestro objetivo principal, pero tiene el potencial de afectar al mercado constructor, por ejemplo, cuando las decisiones de inversión no se toman con mucha antelación y el valor correcto propuesto cambia rápidamente con el tiempo.
La magnitud de tal efecto aún no se comprende bien y bien puede no ser significativa.
Por otro lado, tenemos la dirección MCP menos desarrollada, que sí lleva a cabo una reformulación fundamental del protocolo de consenso para que el rol del proponente se distribuya completamente a un comité (cada miembro del comité ahora siendo referido como un "proponente"), sin privilegiar explícitamente a un actor singular. Si bien MCP promete fortalecer significativamente las garantías proporcionadas por el enfoque de comité para restringir, los cambios en el uso de un comité de esta manera probablemente constituyen un cambio fundamental y aún dejan muchos detalles sin especificar. Por lo tanto, no se puede asumir que el comportamiento circundante permanezca fijo y se requiere un análisis adicional considerable sobre los incentivos temporales, los incentivos de spam, el rendimiento de la red y otros aspectos similares. Para más información, ver esta publicación compara BRAID y FOCIL 2, este análisis 1, este panel 1y la sección al final de la publicación para más.
Además, se puede señalar la mayor importancia de las características del constructor no comercializadas, como la predicción de precios y la tolerancia al riesgo, para hacer argumentos similares sobre la centralización debido a la oferta anticipada.
Al analizar estos compromisos, podemos hacer algunas recomendaciones generales. En primer lugar, el uso de un comité para limitar a los proponentes no parece tener un compromiso profundo (quizás incentivos temporales y complejidad amplios, pero estos parecen menos significativos que otras dinámicas mencionadas), al tiempo que proporciona el beneficio de resistencia a la censura y reduce el impacto de los bucles de retroalimentación eprop o bprop MEV, dependiendo de qué actor elijamos para ejecutar el mecanismo de asignación. Por lo tanto, deberíamos utilizar algo como FOCIL en cualquier esquema. En el futuro, esperamos que la dirección de MCP dé sus frutos en un diseño basado en comités aún más atractivo que pueda tomar el lugar de FOCIL.
La introducción del papel de eprop también parece inevitable. Hay varias razones para esto. Aparte de la mayoría de las propuestas que implican un papel de eprop, podemos observar el protocolo actual que no introduce explícitamente este papel, sino que lo hizo emerger orgánicamente en un mercado fuera del protocolo (MEV-Boost), lo que indica que los incentivos conducen a la aparición de un papel especializado incluso si el diseño del protocolo no lo pretende. Esto nos deja con tres opciones importantes para crear este rol de eprop: ¿quién asigna los derechos de eprop (eprop o bprop), cuándo los participantes tienen que tomar "decisiones de inversión" (pujar, apostar, comprar boletos, etc.) y cómo se elige el eprop?
Al observar quién y cuándo tomamos decisiones, llegamos a los siguientes diagramas
eprop maneja el mecanismo de asignación
bprop maneja el mecanismo de asignación
La primera opción indicada a la izquierda muestra un mundo en el que dejamos tantos roles como sea posible hasta el eprop. La opción restante gira en torno al tiempo, en particular el momento de las decisiones de inversión en relación con los espacios asignados. Ajustar el tiempo nos permitirá naveGar dos fuerzas que impactan negativamente en la estructura del mercado constructor. Ampliar las cosas con más antelación trae los mencionados impactos negativos en el mercado constructor (como la concentración y la pérdida de ingresos), mientras que menos retraso corre el riesgo de crear bucles de retroalimentación positiva para los incumbentes, aunque no está claro cuál sería la magnitud de tal ventaja. Basándonos en los factores que hemos destacado anteriormente, este espacio de diseño eprop pesado hace mejor para aislar el bprop. Por supuesto, puede haber otras interacciones relevantes que aún no hemos explorado.
Alternativamente, podríamos dejar la asignación de los derechos de eprop al bprop. En este mundo, el bprop asumiría roles como determinar la oferta más alta en una subasta o incluir mensajes de compra de tickets de ejecución. Ajustar el tiempo en dicho mundo nos permite elegir entre sacrificar la "estrategia-libertad" del bprop (es decir, descentralización del atestador) en favor de la concentración del mercado constructor.
Subastas de Bloques vs Subastas de Ranuras
La discusión de subastas de bloques vs. espacios en ePBS 1se puede ver como una discusión sobre cómo ejecutar el mecanismo de asignación sin demora (subasta de bloque) vs con una pequeña demora (subasta de ranura). El artículo vinculado proporciona una visión general relativamente completa, pero queríamos agregar dos puntos sobre esta 'transición de fase'
Los diagramas anteriores solo capturan la dirección de los diferentes efectos predichos, pero el grado en que estos efectos están presentes naturalmente depende del tipo de mecanismo de asignación. El veredicto ciertamente aún está en el aire, pero hay algunos trabajos relevantes que nos permiten discriminar entre los muchos diseños posibles.
(Flashbots) argumenta que los mecanismos de asignación que tienen una mayor elasticidad en la oferta de derechos de propuesta permiten un mercado más diverso. Esto explicaría por qué los modelos que asumen un número fijo de tickets...como este 3predice un único propietario de todos los boletos mientras que el sistema de PoS de Ethereum actualmente admite una diversidad de actores.
Nuestra conclusión es que si se desea que el mercado de constructores sea mínimamente concentrado, se puede tener éxito al distribuir lo más ampliamente posible la asignación de derechos de propuesta, pero esto conlleva un costo en eficiencia y ingresos. Contar con un mecanismo de asignación que favorezca la descentralización del mercado, con suerte, suavizaría el costo de requerir que las decisiones de inversión se tomen con más antelación.
En términos generales, hemos argumentado que queremos evitar la concentración del mercado y emplear comités para reducir la capacidad de cualquier actor individual de socavar la neutralidad del mercado de espacio de bloque (por ejemplo, censurando o anticipándose a las operaciones comerciales de la competencia). Una preocupación más específica es que si un actor sabe que tiene derechos de propuesta en bloques consecutivos, podrá y estará incentivado para tomar acciones adicionales que afecten negativamente el funcionamiento de los mercados. Por ejemplo, si un minero sabe que va a producir dos bloques seguidos (con alta probabilidad), puede censurar algunas operaciones en el primer bloque sabiendo que puede ejecutarlas de manera más rentable en el siguiente (ver aquí 1para más detalles).
Queremos evitar este tipo de dinámica por dos razones:
Podríamos tratar de abordar este problema de la siguiente manera:
Los puntos 1 y 3 ya se discuten arriba y la implementación del 2 dejaría en gran medida sin cambios otras discusiones.
Como se mencionó anteriormente, se puede considerar a los Proposers Múltiples Concurrentes como una propiedad de diseño que lleva el uso de los comités a su máxima expresión. En lugar de tener un comité que restrinja a un solo actor como intentan hacer los diseños de inclusion list (o, como se dice de otra manera, dejar a un actor especial con "última mirada"), MCP tendría un comité de actores construyendo un bloque "equitativamente" o al menos tomando acción al mismo tiempo. El diseño principal de MCP es .TRENZA 3que todavía se encuentra en la fase de determinar los detalles del consenso sin que se haya propuesto aún un esquema de ordenación específico.
En cierto sentido, MCP encaja perfectamente en lo que se ha discutido anteriormente. El MCP exige la posibilidad de elegir múltiples proponentes por bloque, pero no estipula cuándo se deben tomar las decisiones de inversión por parte de los constructores o cómo se deben asignar los derechos de propuesta. La separación entre eprops y bprops tampoco debe darse necesariamente por sentada en este modelo. Algunos pueden argumentar que la distribución de propuestas dentro de un espacio entre los actores puede reducir lo suficiente los incentivos de MEV como para que la asignación de certificados a esta tarea no conduzca a un mercado secundario. \
Como se discutió con respecto a los comités anteriormente, la utilización de comités reduce el impacto de los incentivos MEV, salvo la colusión total, por lo que es probable que se reduzcan las consecuencias de pedir a los constructores que tomen decisiones de inversión más cerca de la ranura y no tengamos que comer tanta de la "maldad del mercado" que estamos argumentando que viene con la toma de decisiones de inversión con mucha anticipación. Un beneficio adicional de MCP sobre las soluciones basadas en comités que restringen a los proponentes es que MCP mejora las garantías de vida, ya que ningún proponente por sí solo puede causar una ranura perdida.
Dicho esto, MCP/BRAID es un cambio fundamental y actualmente no especificado con muchas incógnitas que deben abordarse. Por ejemplo, ser el último proponente en actuar puede proporcionar algunas ventajas informativas que podrían crear nuevos incentivos de juego temporal y una (intencional) falta de coordinación entre los proponentes concurrentes puede llevar a ineficiencias como la inclusión de transacciones duplicadas en los espacios. Algunos de estos puntos se discutieron con más detalle en un.panel reciente 1.
El objetivo principal de esta publicación fue establecer el espacio de compromiso. Esto se puede resumir de la siguiente manera:
Naturalmente, hay muchas preguntas abiertas y quizás las mejores preguntas no me son conocidas. Aquí hay algunas preguntas que me parecen importantes, sin embargo.
Este artículo es reimpreso de [colectivo]. Todos los derechos de autor pertenecen al autor original [Quintusy@Christophrobot]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo manejarán rápidamente.
Renuncia de responsabilidad: Las opiniones y puntos de vista expresados en este artículo son exclusivamente los del autor y no constituyen ningún consejo de inversión.
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.
Compartir
tl;dr: este artículo enmarca la discusión en torno a la asignación de derechos en Ethereum, proporciona una visión rápida (opinada) del discurso actual y destaca algunas preguntas abiertas al final.
El objetivo de prevenir la centralización impulsada por MEV que socava las propiedades centrales de Ethereum ha dado lugar a una variedad de esquemas propuestos que cambian la forma en que se construyen y proponen los bloques en la red. Estos esquemas como ePBS, MCP o tickets de ejecución reemplazarían el mercado basado en MEV-Boost que tenemos hoy en día (aunque el software MEV-Boost aún puede desempeñar un papel).
Todos estos diseños tienen dos objetivos en común: Como objetivo principal, queremos evitar cualquier incentivo para que los atestiguadores se comporten estratégicamente. Las recompensas en habilidad y los beneficios para la colocación crean presiones centralizadoras en la red que queremos evitar. Como objetivo secundario, queremos mantener el "buen" mercado de constructores. Por "mercado de constructores" nos referimos al mercado que surge en torno al servicio del papel adicional que todos estos esquemas crean además del papel de atestiguador. "Bueno" implica navegar en un espacio de compensación entre descentralización, eficiencia y ingresos del protocolo.
Durante las exploraciones iniciales de este espacio de soluciones, la posición de consenso fue que queremos un gran grado de descentralización entre los atestiguantes, incluso si esto significa que el mercado constructor es bastante "malo" (por ejemplo, el post de la fase final 2). Sin embargo, nunca ha quedado claro en qué punto trazamos la línea y estamos dispuestos a tener menos descentralización entre los atestiguadores para un mejor mercado de constructores. Esta publicación no intenta tomar una postura aquí, sino simplemente hacer accesible el panorama de compensaciones. Este es un problema complejo y hay pocos argumentos que realmente podamos tomar como herméticos y perfectamente predictivos, por lo que esta publicación debe verse como una interpretación del trabajo que se ha realizado pero que ciertamente está sujeta a cambios.
Desde la familia de diseños de Propositor Múltiple Concurrente (MCP), de los cuales TRENZA 3es el esfuerzo de diseño más importante, todavía es bastante nuevo y debe ser desarrollado primero, el artículo discute diseños de único proponente en mayor profundidad y dedica una breve sección a la discusión de MCP al final.
Nota: Se usa "attester" en lugar de "validador" para enfatizar el papel de consenso relativamente simple de atestiguar bloques y participar en la capa p2p en contraste con el papel más complejo de producción y propuesta de bloques que la red asigna técnicamente al mismo actor en la actualidad. Atestador y validador pueden tratarse de manera flexible como intercambiables.
Los Attesters se benefician más del comportamiento estratégico cuando son seleccionados como líderes de consenso para proponer bloques al resto del conjunto de Attesters para un determinado slot. Por lo tanto, la mayoría de los diseños que hemos desarrollado para proteger a los Attesters se han centrado en el papel de proponente. Cada uno de ellos utiliza alguna combinación de tres técnicas:
Cada uno de ellos tiene sus propias limitaciones:
Este bucle de retroalimentación puede no socavar mucho nuestro objetivo principal, pero tiene el potencial de afectar al mercado constructor, por ejemplo, cuando las decisiones de inversión no se toman con mucha antelación y el valor correcto propuesto cambia rápidamente con el tiempo.
La magnitud de tal efecto aún no se comprende bien y bien puede no ser significativa.
Por otro lado, tenemos la dirección MCP menos desarrollada, que sí lleva a cabo una reformulación fundamental del protocolo de consenso para que el rol del proponente se distribuya completamente a un comité (cada miembro del comité ahora siendo referido como un "proponente"), sin privilegiar explícitamente a un actor singular. Si bien MCP promete fortalecer significativamente las garantías proporcionadas por el enfoque de comité para restringir, los cambios en el uso de un comité de esta manera probablemente constituyen un cambio fundamental y aún dejan muchos detalles sin especificar. Por lo tanto, no se puede asumir que el comportamiento circundante permanezca fijo y se requiere un análisis adicional considerable sobre los incentivos temporales, los incentivos de spam, el rendimiento de la red y otros aspectos similares. Para más información, ver esta publicación compara BRAID y FOCIL 2, este análisis 1, este panel 1y la sección al final de la publicación para más.
Además, se puede señalar la mayor importancia de las características del constructor no comercializadas, como la predicción de precios y la tolerancia al riesgo, para hacer argumentos similares sobre la centralización debido a la oferta anticipada.
Al analizar estos compromisos, podemos hacer algunas recomendaciones generales. En primer lugar, el uso de un comité para limitar a los proponentes no parece tener un compromiso profundo (quizás incentivos temporales y complejidad amplios, pero estos parecen menos significativos que otras dinámicas mencionadas), al tiempo que proporciona el beneficio de resistencia a la censura y reduce el impacto de los bucles de retroalimentación eprop o bprop MEV, dependiendo de qué actor elijamos para ejecutar el mecanismo de asignación. Por lo tanto, deberíamos utilizar algo como FOCIL en cualquier esquema. En el futuro, esperamos que la dirección de MCP dé sus frutos en un diseño basado en comités aún más atractivo que pueda tomar el lugar de FOCIL.
La introducción del papel de eprop también parece inevitable. Hay varias razones para esto. Aparte de la mayoría de las propuestas que implican un papel de eprop, podemos observar el protocolo actual que no introduce explícitamente este papel, sino que lo hizo emerger orgánicamente en un mercado fuera del protocolo (MEV-Boost), lo que indica que los incentivos conducen a la aparición de un papel especializado incluso si el diseño del protocolo no lo pretende. Esto nos deja con tres opciones importantes para crear este rol de eprop: ¿quién asigna los derechos de eprop (eprop o bprop), cuándo los participantes tienen que tomar "decisiones de inversión" (pujar, apostar, comprar boletos, etc.) y cómo se elige el eprop?
Al observar quién y cuándo tomamos decisiones, llegamos a los siguientes diagramas
eprop maneja el mecanismo de asignación
bprop maneja el mecanismo de asignación
La primera opción indicada a la izquierda muestra un mundo en el que dejamos tantos roles como sea posible hasta el eprop. La opción restante gira en torno al tiempo, en particular el momento de las decisiones de inversión en relación con los espacios asignados. Ajustar el tiempo nos permitirá naveGar dos fuerzas que impactan negativamente en la estructura del mercado constructor. Ampliar las cosas con más antelación trae los mencionados impactos negativos en el mercado constructor (como la concentración y la pérdida de ingresos), mientras que menos retraso corre el riesgo de crear bucles de retroalimentación positiva para los incumbentes, aunque no está claro cuál sería la magnitud de tal ventaja. Basándonos en los factores que hemos destacado anteriormente, este espacio de diseño eprop pesado hace mejor para aislar el bprop. Por supuesto, puede haber otras interacciones relevantes que aún no hemos explorado.
Alternativamente, podríamos dejar la asignación de los derechos de eprop al bprop. En este mundo, el bprop asumiría roles como determinar la oferta más alta en una subasta o incluir mensajes de compra de tickets de ejecución. Ajustar el tiempo en dicho mundo nos permite elegir entre sacrificar la "estrategia-libertad" del bprop (es decir, descentralización del atestador) en favor de la concentración del mercado constructor.
Subastas de Bloques vs Subastas de Ranuras
La discusión de subastas de bloques vs. espacios en ePBS 1se puede ver como una discusión sobre cómo ejecutar el mecanismo de asignación sin demora (subasta de bloque) vs con una pequeña demora (subasta de ranura). El artículo vinculado proporciona una visión general relativamente completa, pero queríamos agregar dos puntos sobre esta 'transición de fase'
Los diagramas anteriores solo capturan la dirección de los diferentes efectos predichos, pero el grado en que estos efectos están presentes naturalmente depende del tipo de mecanismo de asignación. El veredicto ciertamente aún está en el aire, pero hay algunos trabajos relevantes que nos permiten discriminar entre los muchos diseños posibles.
(Flashbots) argumenta que los mecanismos de asignación que tienen una mayor elasticidad en la oferta de derechos de propuesta permiten un mercado más diverso. Esto explicaría por qué los modelos que asumen un número fijo de tickets...como este 3predice un único propietario de todos los boletos mientras que el sistema de PoS de Ethereum actualmente admite una diversidad de actores.
Nuestra conclusión es que si se desea que el mercado de constructores sea mínimamente concentrado, se puede tener éxito al distribuir lo más ampliamente posible la asignación de derechos de propuesta, pero esto conlleva un costo en eficiencia y ingresos. Contar con un mecanismo de asignación que favorezca la descentralización del mercado, con suerte, suavizaría el costo de requerir que las decisiones de inversión se tomen con más antelación.
En términos generales, hemos argumentado que queremos evitar la concentración del mercado y emplear comités para reducir la capacidad de cualquier actor individual de socavar la neutralidad del mercado de espacio de bloque (por ejemplo, censurando o anticipándose a las operaciones comerciales de la competencia). Una preocupación más específica es que si un actor sabe que tiene derechos de propuesta en bloques consecutivos, podrá y estará incentivado para tomar acciones adicionales que afecten negativamente el funcionamiento de los mercados. Por ejemplo, si un minero sabe que va a producir dos bloques seguidos (con alta probabilidad), puede censurar algunas operaciones en el primer bloque sabiendo que puede ejecutarlas de manera más rentable en el siguiente (ver aquí 1para más detalles).
Queremos evitar este tipo de dinámica por dos razones:
Podríamos tratar de abordar este problema de la siguiente manera:
Los puntos 1 y 3 ya se discuten arriba y la implementación del 2 dejaría en gran medida sin cambios otras discusiones.
Como se mencionó anteriormente, se puede considerar a los Proposers Múltiples Concurrentes como una propiedad de diseño que lleva el uso de los comités a su máxima expresión. En lugar de tener un comité que restrinja a un solo actor como intentan hacer los diseños de inclusion list (o, como se dice de otra manera, dejar a un actor especial con "última mirada"), MCP tendría un comité de actores construyendo un bloque "equitativamente" o al menos tomando acción al mismo tiempo. El diseño principal de MCP es .TRENZA 3que todavía se encuentra en la fase de determinar los detalles del consenso sin que se haya propuesto aún un esquema de ordenación específico.
En cierto sentido, MCP encaja perfectamente en lo que se ha discutido anteriormente. El MCP exige la posibilidad de elegir múltiples proponentes por bloque, pero no estipula cuándo se deben tomar las decisiones de inversión por parte de los constructores o cómo se deben asignar los derechos de propuesta. La separación entre eprops y bprops tampoco debe darse necesariamente por sentada en este modelo. Algunos pueden argumentar que la distribución de propuestas dentro de un espacio entre los actores puede reducir lo suficiente los incentivos de MEV como para que la asignación de certificados a esta tarea no conduzca a un mercado secundario. \
Como se discutió con respecto a los comités anteriormente, la utilización de comités reduce el impacto de los incentivos MEV, salvo la colusión total, por lo que es probable que se reduzcan las consecuencias de pedir a los constructores que tomen decisiones de inversión más cerca de la ranura y no tengamos que comer tanta de la "maldad del mercado" que estamos argumentando que viene con la toma de decisiones de inversión con mucha anticipación. Un beneficio adicional de MCP sobre las soluciones basadas en comités que restringen a los proponentes es que MCP mejora las garantías de vida, ya que ningún proponente por sí solo puede causar una ranura perdida.
Dicho esto, MCP/BRAID es un cambio fundamental y actualmente no especificado con muchas incógnitas que deben abordarse. Por ejemplo, ser el último proponente en actuar puede proporcionar algunas ventajas informativas que podrían crear nuevos incentivos de juego temporal y una (intencional) falta de coordinación entre los proponentes concurrentes puede llevar a ineficiencias como la inclusión de transacciones duplicadas en los espacios. Algunos de estos puntos se discutieron con más detalle en un.panel reciente 1.
El objetivo principal de esta publicación fue establecer el espacio de compromiso. Esto se puede resumir de la siguiente manera:
Naturalmente, hay muchas preguntas abiertas y quizás las mejores preguntas no me son conocidas. Aquí hay algunas preguntas que me parecen importantes, sin embargo.
Este artículo es reimpreso de [colectivo]. Todos los derechos de autor pertenecen al autor original [Quintusy@Christophrobot]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo manejarán rápidamente.
Renuncia de responsabilidad: Las opiniones y puntos de vista expresados en este artículo son exclusivamente los del autor y no constituyen ningún consejo de inversión.
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.