Reenviar el Título Original '系统解读Fiber：把闪电网络嫁接到CKB上的宏大实验'

El 23 de agosto, CKB lanzó oficialmente Fiber Network, una solución Lightning Network basada en CKB. Esta noticia provocó rápidamente un intenso debate en la comunidad, lo que llevó a un aumento de casi el 30% en el precio de CKB en un solo día. La fuerte reacción se puede atribuir a la narrativa convincente de Lightning Network y al hecho de que Fiber ofrece una solución mejorada sobre la Lightning Network tradicional con numerosas mejoras. Por ejemplo, Fiber admite múltiples tipos de activos de forma nativa, incluidos CKB, BTC y stablecoins, y se beneficia de las tarifas de transacción más bajas de CKB y los tiempos de respuesta más rápidos, lo que permite avances significativos en UX. Además, Fiber ha realizado varias optimizaciones en términos de privacidad y seguridad. Además, Fiber y BTC Lightning Network pueden interconectarse, formando una red P2P más grande. Los funcionarios de CKB incluso mencionaron que planean establecer 100,000 nodos físicos en Fiber y Lightning Network durante eventos fuera de línea para mejorar y avanzar en la red de pagos P2P. Esto, sin duda, representa una historia grandiosa y sin precedentes

Si la visión oficial de CKB se realiza en el futuro, sería un gran impulso para Lightning Network, CKB y el ecosistema Bitcoin en general. Según los datos de la mempool, la Lightning Network BTC actualmente tiene más de $300 millones en fondos, con aproximadamente 12,000 nodos y casi 50,000 canales de pago establecidos entre ellos.

En spendmybtc.com, podemos observar que un número cada vez mayor de comerciantes están aceptando pagos de la Red Lightning. A medida que crece el reconocimiento de BTC, es probable que el aumento de las soluciones de pago fuera de la cadena, como la Red Lightning y Fiber, cobren impulso. Para analizar sistemáticamente la solución técnica de Fiber, 'Geek Web3' ha producido este informe de investigación sobre la solución general de Fiber. Como una implementación de la Red Lightning basada en CKB, los principios de Fiber son en gran medida consistentes con la Red Lightning de Bitcoin, pero incluyen optimizaciones en muchos detalles. La arquitectura general de Fiber consta de cuatro componentes principales: canales de pago, WatchTower, enrutamiento de varios saltos y pagos entre dominios. Comencemos explicando el componente más importante: los canales de pago.

La Fundación de la Red Lightning y Fiber: Canales de Pago

Básicamente, los canales de pago mueven las transacciones fuera de la cadena, y el estado final se liquida en la cadena después de un tiempo. Dado que las transacciones se completan fuera de la cadena, a menudo eluden las limitaciones de rendimiento de la cadena principal, como BTC. Por ejemplo, si Alice y Bob abren un canal juntos, primero crean una cuenta multifirma en la cadena y depositan algunos fondos, digamos 100 unidades cada uno, como saldo en el canal fuera de la cadena. A continuación, pueden realizar múltiples transacciones dentro del canal y, cuando cierran el canal, sincronizan los saldos finales en la cadena, y la cuenta multifirma realiza pagos a ambas partes: esta es la "liquidación".

Por ejemplo, si ambas partes comienzan con 100 unidades cada una, y Alice transfiere 50 unidades a Bob, seguido de otra transferencia de 10 unidades, y luego Bob transfiere 30 unidades de vuelta a Alice, sus saldos finales serían: Alice - 70 unidades, Bob - 130 unidades. El balance total permanece sin cambios, como se ilustra en el ejemplo de cuentas del ábaco. Si una de las partes sale del canal, los saldos finales (Alice: 70, Bob: 130) se sincronizan en la cadena, y las 200 unidades de la cuenta multi-firma se distribuyen de acuerdo a estos saldos finales para completar el acuerdo.

Aunque este proceso parece sencillo, en la práctica implica consideraciones complejas. No se puede predecir cuándo la otra parte elegirá salir del canal. Por ejemplo, Bob podría salir después de la segunda transacción o incluso después de la primera, ya que el canal permite a los participantes salir libremente. Para abordar esto, el sistema asume que cualquier persona podría salir en cualquier momento, y cualquiera de las partes podría enviar el saldo final a la cadena para liquidación. Esto se gestiona a través de 'transacciones de compromiso', que registran los saldos más recientes en el canal. Cada transacción genera una transacción de compromiso correspondiente. Para salir del canal, debes enviar la transacción de compromiso más reciente a la cadena para retirar tu parte de la cuenta multi-firma.

Podemos concluir que las transacciones de compromiso se utilizan para liquidar los saldos de ambas partes en el canal en la cadena, y cualquiera de las partes puede enviar la última transacción de compromiso para salir del canal. Sin embargo, hay un escenario malicioso crucial: Bob podría enviar una transacción de saldo y compromiso obsoleta a la cadena. Por ejemplo, después de generar Commit Tx3, el saldo de Bob es de 130 unidades. Pero para su ventaja, Bob podría presentar el obsoleto Commit Tx2, que muestra un saldo de 160 unidades. Este saldo obsoleto representa un clásico ataque de "doble gasto".

Para evitar estos escenarios de doble gasto, deben existir medidas de penalización apropiadas. El diseño de estas medidas de penalización es fundamental en el sistema de canal de pago uno a uno, y comprender esto es esencial para entender cómo funcionan los canales de pago. En el diseño del canal, si cualquiera de las partes envía un estado y una transacción de compromiso desactualizados a la cadena, en lugar de beneficiarse, descubrirán que la otra parte puede retirar todos los fondos. Esto utiliza los conceptos de "transacciones de compromiso asimétricas" y "claves de revocación," que son cruciales. Primero expliquemos "transacciones de compromiso asimétricas" utilizando Commit Tx3 como ejemplo.

En este escenario, Bob crea una transacción de compromiso y la envía a Alice para que la maneje. Como se muestra, esta transacción implica una transferencia de Bitcoin, declarando que 70 unidades de la cuenta multi-firma se asignan a Alice y 130 unidades a Bob. Sin embargo, las condiciones de desbloqueo son 'asimétricas', imponiendo restricciones más estrictas a Alice y beneficiando a Bob.

Cuando Alice recibe la transacción de compromiso de Bob, puede agregar su firma para cumplir con el requisito de multi-firma 2/2. Alice luego puede optar por enviar esta transacción de compromiso en la cadena para salir del canal. Alternativamente, ella puede continuar haciendo transacciones dentro del canal si no la envía.

Es crucial tener en cuenta que esta transacción de compromiso está construida por Bob y tiene condiciones desfavorables para Alice. Alice tiene la opción de aceptar o rechazarla, pero necesitamos asegurarnos de que ella conserve cierta autonomía. En el diseño de los canales de pago, solo Alice puede enviar la transacción de compromiso "desfavorable" a la cadena porque las transacciones de compromiso requieren una multi-firma 2/2. Después de que Bob construye la transacción localmente, solo tiene su firma y carece de la firma de Alice.

Alicia puede "aceptar la firma de Bob, pero retener la suya". Esto es similar a un contrato que requiere firmas dobles. Si Bob firma primero y envía el contrato a Alice, ella puede optar por no proporcionar su firma. Para hacer efectivo el contrato, Alice tendría que firmarlo y luego presentarlo; de lo contrario, puede abstenerse de firmarlo o presentarlo. Por lo tanto, en este caso, Alice tiene los medios para limitar las acciones de Bob.

Aquí está el punto clave: Cada vez que ocurre una transacción dentro del canal, se generan un par de transacciones de compromiso, con dos versiones reflejadas, como se ilustra a continuación. Alice y Bob pueden crear cada uno transacciones de compromiso favorables a sí mismos, especificando sus respectivos saldos o cantidades a recibir al salir, y luego enviar estas transacciones entre sí para su manejo.

Curiosamente, si bien las dos transacciones de compromiso declaran la misma 'cantidad a recibir al salir', sus condiciones de retiro son diferentes. Esto ilustra el concepto de 'transacciones de compromiso asimétricas' mencionado anteriormente.

Como se explicó anteriormente, cada transacción de compromiso requiere una firma múltiple 2/2 para ser válida. La transacción de compromiso creada por Bob que favorece a sí mismo no cumple con el requisito de firma múltiple 2/2, mientras que la transacción de compromiso que cumple con este requisito es mantenida por Alice y solo puede ser enviada por ella, creando un mecanismo de control y equilibrio. La misma lógica se aplica en sentido inverso.

Así, Alice y Bob solo pueden enviar transacciones de compromiso desfavorables para ellos mismos. Si cualquiera de las partes envía una transacción de compromiso a la cadena y esta se hace efectiva, el canal se cierra.

En cuanto al escenario de "doble gasto" discutido anteriormente, si alguien envía una transacción de compromiso desactualizada a la cadena, entra en juego el concepto de "claves de revocación". Por ejemplo, si Bob envía la Tx2 desactualizada a la cadena, Alice puede usar la clave de revocación asociada con Tx2 para retirar los fondos que Bob debía recibir.

En el diagrama de ejemplo, asumiendo que la última transacción de compromiso es Commit Tx3 y Tx2 está desactualizada, si Bob presenta la Tx2 desactualizada, Alice puede actuar dentro del período de bloqueo de tiempo utilizando la clave de revocación de Tx2 para retirar los fondos de Bob.

En cuanto a la última Tx3, Alice no posee su clave de revocación y solo la recibirá después de que se cree Tx4 en el futuro. Esto se debe a la naturaleza de la criptografía de clave pública/privada y las propiedades de UTXO. Por brevedad, no se discuten aquí los detalles de implementación de las claves de revocación.

La conclusión clave es que si Bob se atreve a enviar una transacción de compromiso desactualizada a la cadena, Alice puede usar la clave de revocación para retirar los fondos de Bob como penalización. De manera similar, si Alice actúa maliciosamente, Bob puede aplicar la misma penalización contra ella. Este mecanismo garantiza que los canales de pago uno a uno eviten efectivamente el doble gasto, ya que los participantes racionales evitarían acciones maliciosas.

En este contexto, Fiber, basado en CKB, ofrece mejoras sustanciales sobre la Red Lightning de Bitcoin. Admite nativamente transacciones y transferencias de varios tipos de activos, incluyendo CKB, BTC y stablecoins RGB++, mientras que la Red Lightning admite nativamente solo Bitcoin. Incluso con la actualización de activos Taproot, la Red Lightning de Bitcoin aún no puede admitir nativamente activos que no sean BTC y solo puede admitir stablecoins de forma indirecta.

(Imágenes fuente: Dapangdun) Además, como Fiber se basa en CKB como su cadena principal de Capa 1, las tarifas para abrir y cerrar canales son significativamente más bajas en comparación con la Red Lightning de BTC. Esto reduce los costos de transacción del usuario, lo que representa una clara ventaja en términos de experiencia del usuario (UX).

Seguridad 24/7: WatchTower

Un desafío con las claves de revocación es que los participantes del canal deben monitorearse constantemente para evitar la presentación de transacciones de compromiso obsoletas. Sin embargo, nadie puede estar en línea las 24 horas del día, los 7 días de la semana, ¿entonces qué sucede si una parte actúa maliciosamente mientras la otra está desconectada? Tanto Fiber como la Red Lightning de Bitcoin abordan este problema con el diseño de WatchTowers.

Los WatchTowers están diseñados para monitorear las actividades en la cadena las 24 horas del día. Si alguien envía una transacción de compromiso desactualizada, el WatchTower tomará medidas oportunas para proteger el canal y los fondos. Así es como funciona:

Después de la creación de una transacción de compromiso protegida por el tiempo, Alice o Bob pueden preparar una transacción de penalización correspondiente por adelantado (usando la clave de revocación para manejar la transacción de compromiso obsoleta, con el beneficiario declarado como ellos mismos). Luego proporcionan el texto sin cifrar de esta transacción de penalización al WatchTower.

Cuando WatchTower detecta una transacción de compromiso desactualizada que se envía a la cadena, también enviará la transacción de penalización preparada, haciendo cumplir la penalización y salvaguardando la integridad del canal.

Fiber protege la privacidad de los participantes al requerir que los usuarios envíen solo el “hash de la transacción de compromiso obsoleta + texto sin formato de la transacción de penalización” al WatchTower. De esta manera, el WatchTower inicialmente solo conoce el hash de la transacción de compromiso, no su texto sin formato. El WatchTower solo ve el texto sin formato si alguien realmente envía la transacción de compromiso obsoleta en la cadena, momento en el cual también enviará la transacción de penalización. Esto asegura que el WatchTower solo verá el registro de transacciones de un participante si hay una conducta indebida real, y aún así, solo verá una sola transacción.

En términos de optimización, Fiber mejora el enfoque de Bitcoin Lightning Network con respecto a los mecanismos de penalización. La "penalización de LN" de Lightning Network tiene un inconveniente notable: las WatchTowers deben almacenar todos los hashes de transacciones de compromiso obsoletos y las claves de revocación correspondientes, lo que genera una presión de almacenamiento significativa. En 2018, la comunidad Bitcoin propuso una solución llamada "eltoo" para abordar este problema. Eltoo permitiría que la última transacción de compromiso penalizara a las obsoletas, reduciendo la necesidad de almacenar todas las transacciones anteriores. Sin embargo, esta solución requiere la activación del código de operación SIGHASH_ANYPREVOUT, que aún no se ha implementado.

Por otro lado, Fiber emplea el protocolo Daric, que modifica el diseño de la clave de revocación para que una única clave de revocación sea aplicable a múltiples transacciones de compromiso obsoletas. Este enfoque reduce enormemente las demandas de almacenamiento para WatchTowers y clientes de usuario.

En cuanto a los sistemas de tráfico de red: los canales de pago son adecuados para transacciones de uno a uno, pero la Red Lightning admite pagos multi-salto, lo que permite transacciones entre partes que no tienen un canal directo mediante el enrutamiento a través de nodos intermediarios. Por ejemplo, si Alice y Ken no tienen un canal directo pero Ken y Bob sí tienen, y Bob y Alice también lo tienen, Bob puede actuar como intermediario para facilitar las transacciones entre Alice y Ken.

La "enrutamiento de múltiples saltos" mejora la flexibilidad y cobertura de la red. Sin embargo, los remitentes deben estar al tanto del estado de todos los nodos y canales públicos. En Fiber, toda la estructura de la red, incluidos todos los canales públicos, es completamente transparente, lo que permite a cualquier nodo acceder a la información de la red de otros nodos. Dado que el estado de la red en Lightning Network está cambiando constantemente, Fiber utiliza el algoritmo de Dijkstra para encontrar la ruta de enrutamiento más corta, minimizando el número de intermediarios y estableciendo una ruta de transacción entre las dos partes.

Para abordar el problema de confianza con los intermediarios: ¿Cómo puedes asegurarte de que sean honestos? Por ejemplo, si Alice necesita hacer un pago de 100 unidades a Ken, pero Bob, que es un intermediario entre ellos, podría retener los fondos. HTLC y PTLC se utilizan para prevenir este tipo de comportamiento malicioso. Supongamos que Alice quiere pagarle a Daniel 100 unidades, pero no tienen un canal directo. Alice descubre que puede enrutar el pago a través de los intermediarios Bob y Carol. HTLC se introduce como el canal de pago: primero Alice inicia la solicitud a Daniel, quien luego proporciona a Alice un hash r, pero Alice no conoce la preimagen R correspondiente a r.

Luego, Alice construye los términos de pago con Bob a través de HTLC: Alice está dispuesta a pagarle a Bob 102 unidades, pero Bob debe revelar la clave R en un plazo de 30 minutos; de lo contrario, Alice retirará el dinero. De manera similar, Bob crea un HTLC con Carol: Bob le pagará a Carol 101 unidades, pero Carol debe revelar la clave R en un plazo de 25 minutos; de lo contrario, Bob retirará el dinero. Carol hace lo mismo con Daniel: Carol está dispuesta a pagarle a Daniel 100 unidades, pero Daniel debe revelar la clave R en un plazo de 20 minutos; de lo contrario, Carol retirará el dinero.

Daniel entiende que la clave R solicitada por Carol es en realidad lo que Alice quiere, ya que solo Alice está interesada en el valor de R. Entonces, Daniel coopera con Carol, proporciona la clave R y recibe 100 unidades de Carol. De esta manera, Alice logra su objetivo de pagarle a Daniel 100 unidades.

Posteriormente, Carol le da la llave R a Bob y recibe 101 unidades. Bob luego le da la llave R a Alice y recibe 102 unidades. Observando las ganancias y pérdidas de todos, Alice pierde 102 unidades, Bob y Carol ganan cada uno un neto de 1 unidad, y Daniel recibe 100 unidades. La 1 unidad ganada por Bob y Carol es su tarifa extraída de Alice.

Incluso si alguien en la ruta de pago, como Carol, no proporciona la clave R al receptor Bob, no resulta en una pérdida para Bob: después del tiempo de espera, Bob puede retirar el HTLC que construyó. Lo mismo se aplica a Alice. Sin embargo, la Red Lightning tiene sus problemas: las rutas no deben ser demasiado largas. Si la ruta es demasiado larga con demasiados intermediarios, puede reducir la confiabilidad del pago. Algunos intermediarios pueden estar desconectados o tener un saldo insuficiente para construir un HTLC específico (por ejemplo, cada intermediario en el ejemplo anterior necesita tener más de 100 unidades). Por lo tanto, agregar más intermediarios aumenta la probabilidad de errores.

Además, los HTLC pueden filtrar la privacidad. Aunque el enrutamiento de cebolla puede proporcionar cierta protección de privacidad al cifrar la información de enrutamiento en cada salto, de modo que cada participante solo conoce a sus vecinos inmediatos y no el camino completo, los HTLC siguen siendo susceptibles a la inferencia de relaciones. Desde una perspectiva más amplia, el camino completo de enrutamiento aún puede ser deducido.

Suponga que Bob y Daniel están controlados por la misma entidad y reciben muchos HTLC todos los días. Observan que la clave R solicitada por Alice y Carol siempre es la misma, y que el nodo descendente Eve, conectado a Daniel, siempre conoce el contenido de la clave R. Por lo tanto, Daniel y Bob pueden inferir que hay un camino de pago entre Alice y Eve, ya que siempre manejan la misma clave y pueden monitorear su relación. Para abordar esto, Fiber utiliza PTLC, que mejora la privacidad sobre HTLC mediante el uso de claves diferentes para desbloquear cada PTLC en el camino de pago. Observar solo PTLC no puede determinar las relaciones entre los nodos. Al combinar PTLC con enrutamiento cebolla, Fiber se convierte en una solución ideal para pagos que preservan la privacidad.

Además, la red Lightning tradicional es vulnerable a un "ataque de ciclo de reemplazo," que puede resultar en el robo de activos de intermediarios en la ruta de pago. Este problema llevó al desarrollador Antoine Riard a retirarse del desarrollo de la red Lightning. Hasta el momento, la red Lightning de Bitcoin carece de una solución fundamental a este problema, convirtiéndolo en un punto doloroso. Actualmente, CKB aborda este escenario de ataque a través de mejoras a nivel de la piscina de transacciones, lo que permite a Fiber mitigar el problema. Dado que el ataque de ciclo de reemplazo y sus soluciones son bastante complejos, este artículo no profundizará más en ello. Los lectores interesados pueden consultar artículos relacionados de BTCStudy y recursos oficiales de CKB para obtener más información.

En general, Fiber representa una mejora significativa sobre la tradicional Red Lightning tanto en aspectos de privacidad como de seguridad. Fiber mejora los pagos atómicos entre dominios cruzados entre sí y la Red Lightning de Bitcoin.

Usando HTLC y PTLC, Fiber puede lograr pagos entre dominios con Bitcoin Lightning Network, lo que garantiza la "atomicidad de las acciones entre dominios", lo que significa que todos los pasos de la transacción entre dominios tienen éxito o fracasan por completo, sin éxito o fracaso parcial. Con la atomicidad entre dominios asegurada, el riesgo de pérdida de activos es mínimo. Esto permite que Fiber se interconecte con la Lightning Network de Bitcoin, lo que permite pagos directos de Fiber a los usuarios de la Lightning Network de BTC (con el receptor limitado a BTC) y permite conversiones de CK

B y RGB++ en Bitcoin equivalente dentro de la BTC Lightning Network.

Aquí tienes una explicación simplificada del proceso: Supongamos que Alice opera un nodo dentro de la red Fiber, y Bob opera un nodo dentro de la Red Lightning de Bitcoin. Si Alice quiere transferir dinero a Bob, puede hacerlo a través de un intermediario de dominio cruzado, Ingrid. Ingrid ejecutará nodos tanto en las redes Fiber como en la Red Lightning de BTC, actuando como intermediario en la ruta de pago.

Si Bob quiere recibir 1 BTC, Alice puede negociar una tasa de cambio con Ingrid, estableciendo 1 CKB igual a 1 BTC. Luego, Alice enviaría 1.1 CKB a Ingrid dentro de la red Fiber, e Ingrid enviaría 1 BTC a Bob en la Red de Relámpagos de Bitcoin, manteniendo 0.1 CKB como tarifa.

El proceso implica establecer una ruta de pago entre Alice, Ingrid y Bob, utilizando HTLC. Bob debe proporcionar a Ingrid la clave R para recibir los fondos. Una vez que Ingrid tenga la clave R, puede desbloquear los fondos que Alice bloqueó en el HTLC.

Las acciones entre la Red Lightning de BTC y Fiber son atómicas, lo que significa que ambos HTLC se desbloquean y el pago entre dominios se ejecuta correctamente, o ninguno se desbloquea y el pago falla. Esto garantiza que Alice no pierda dinero si Bob no lo recibe.

Ingrid podría potencialmente no desbloquear la HTLC de Alice después de conocer la clave R, pero esto perjudicaría a Ingrid, no a Alice. Por lo tanto, el diseño de Fiber garantiza la seguridad para los usuarios y no requiere confianza en terceros, lo que permite transferencias entre diferentes redes P2P con modificaciones mínimas.

Otras ventajas de Fiber en comparación con la Red Lightning de BTC

Anteriormente, mencionamos que Fiber admite activos nativos CKB y activos RGB++ (especialmente stablecoins), lo que le brinda un potencial significativo para pagos en tiempo real y lo hace adecuado para transacciones diarias pequeñas.

En contraste, un problema importante con la Red Lightning de Bitcoin es la gestión de liquidez. Como discutimos al principio, el saldo total en un canal de pago es fijo. Si el saldo de una de las partes se agota, no puede transferir fondos a la otra parte a menos que la otra parte envíe dinero primero. Esto requiere recargar fondos o abrir un nuevo canal.

Además, en una red compleja de múltiples saltos, si algunos nodos intermedios tienen un saldo insuficiente y no pueden reenviar los pagos, puede provocar que todo el camino de pago falle. Este es uno de los puntos problemáticos de la Lightning Network. La solución típica implica proporcionar mecanismos eficientes de inyección de liquidez para garantizar que la mayoría de los nodos puedan inyectar fondos según sea necesario.

Sin embargo, en la Red Lightning de Bitcoin, la inyección de liquidez, así como la apertura o cierre de canales, ocurren en la cadena de bloques de Bitcoin. Si las tarifas de la red de Bitcoin son muy altas, impacta negativamente la experiencia del usuario de los canales de pago. Por ejemplo, si quieres abrir un canal con una capacidad de $100 pero la tarifa de configuración es de $10, esto significa que el 10% de tus fondos se consumen solo para configurar el canal, lo cual es inaceptable para la mayoría de los usuarios. El mismo problema se aplica a la inyección de liquidez.

En contraste, Fiber ofrece ventajas significativas. En primer lugar, el TPS (transacciones por segundo) de CKB es mucho más alto que el de Bitcoin, con tarifas que alcanzan costos de nivel de centavos. En segundo lugar, para abordar el problema de la escasez de liquidez y garantizar transacciones fluidas, Fiber planea colaborar con Mercury Layer para introducir nuevas soluciones que eliminen la necesidad de operaciones en cadena para la inyección de liquidez, solucionando así los problemas de UX y costos.

Ahora hemos esbozado sistemáticamente la arquitectura técnica general de Fiber, con un resumen que lo compara con la Red Lightning de Bitcoin como se muestra en la imagen de arriba. Dada la complejidad y amplitud de los temas cubiertos por Fiber y la Red Lightning, es posible que un solo artículo no pueda abordar todos los aspectos. Publicaremos una serie de artículos en el futuro centrados en varios aspectos tanto de la Red Lightning como de Fiber. Estén atentos para más actualizaciones.

Descargo de responsabilidad:

1. Este artículo es una reimpresión de [极客web3]. Reenviar el título original '系统解读Fiber：把闪电网络嫁接到CKB上的宏大实验'. Todos los derechos de autor pertenecen al autor original [Faust & Nickqiao，极客web3]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo y ellos lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.