Ethereum EIP-8479 explicado: PeerDAS post-cuántico y blobs de tamaño variable
¿Qué pasaría si Ethereum pudiera hacer su infraestructura de disponibilidad de datos más resistente a futuras computadoras cuánticas, al mismo tiempo que brinda a las redes de Layer 2 mayor flexibilidad sobre cómo publican los datos de las transacciones? Una nueva propuesta presentada por el investigador de la Ethereum Foundation Francesco Risitano el 1 de noviembre de 2026 explora exactamente esa posibilidad. El borrador, originalmente numerado como EIP-9999, propone reemplazar los compromisos KZG en PeerDAS con compromisos Merkle de Keccak-256 y pruebas LeanDA STARK. También introduce blobs de tamaño variable que van desde 2 KiB hasta 512 KiB, permitiendo a los rollups seleccionar capacidad de datos más alineada con sus necesidades. El hilo de discusión de Ethereum Magicians utiliza la designación EIP-8479, lo que hace importante la distinción en la numeración al seguir la propuesta. Aunque el diseño aún se encuentra en una etapa temprana de revisión, conecta tres prioridades clave del desarrollo de Ethereum: criptografía post-cuántica, disponibilidad de datos y escalabilidad de Layer 2. Su potencial importancia trasciende la ingeniería del protocolo, planteando preguntas sobre los costos de los rollups, la competitividad de la infraestructura de Ethereum y el valor a largo plazo del ecosistema de ETH.
Principales conclusiones
-
Una nueva propuesta post-cuántica: El borrador explora reemplazar los compromisos PeerDAS basados en KZG con compromisos Merkle de Keccak-256 y pruebas LeanDA STARK.
-
Bloques de tamaño variable: el diseño permite tamaños de blob potencias de dos, desde 2 KiB hasta 512 KiB, manteniendo 128 columnas por blob.
-
Implicaciones de la capa 2: Los rollups podrían seleccionar capacidades de datos más alineadas con lotes de transacciones, potencialmente mejorando la utilización de datos.
-
Cambios criptográficos: Las rutas de autenticación Merkle reemplazarían las pruebas de celda KZG, mientras que las pruebas STARK verificarían la codificación Reed-Solomon y la derivación del compromiso.
-
Etapa temprana de desarrollo: La propuesta sigue siendo un borrador, y los parámetros del sistema de prueba, la integración del cliente y los umbrales de rendimiento aún requieren trabajo.
-
Relevancia del mercado de ETH: La propuesta puede fortalecer la narrativa de infraestructura a largo plazo de Ethereum, pero no establece un catalizador inmediato para los precios de ETH ni garantiza tarifas de transacción más bajas.
¿Qué es Ethereum EIP-8479 y por qué se propuso?
La propuesta aborda dos desafíos relacionados: la seguridad criptográfica a largo plazo de la capa de disponibilidad de datos de Ethereum y la necesidad de una capacidad de datos más flexible para rollups. Su especificación original lleva el título EIP-9999, y el hilo de discusión de noviembre 1 utiliza el título EIP-8479. Fue escrita por Francesco Risitano, Thomas Coratger y Tom Wambsgans, y su borrador inicial data del 26 de octubre de 2026. La propuesta es un EIP de Core, Standards Track y actualmente tiene estado de Draft. Hace referencia a varias propuestas relacionadas, incluyendo EIP-4844, EIP-7594, EIP-7892, EIP-8141 y EIP-8288.
Por qué PeerDAS existente necesita un enfoque criptográfico diferente
PeerDAS, o Muestreo de Disponibilidad de Datos entre Pares, permite que los nodos de ethereum verifiquen si los datos de blob están disponibles sin descargar cada byte de un blob completo. El mecanismo distribuye los datos en columnas, asigna responsabilidades de custodia a los nodos y permite a los participantes muestrear porciones seleccionadas. Esto reduce los requisitos de datos para validadores comunes mientras conserva un método para verificar la disponibilidad de datos.
El diseño actual utiliza compromisos KZG y pruebas de celda para autenticar los datos muestreados. KZG se basa en criptografía de emparejamiento de curvas elípticas, que es vulnerable en principio a computadoras cuánticas tolerantes a fallas suficientemente capaces que ejecuten el algoritmo de Shor. Aunque actualmente no están disponibles computadoras cuánticas prácticas capaces de romper las suposiciones criptográficas de ethereum, los investigadores del protocolo están evaluando alternativas antes de que esta amenaza se vuelva operativa. La discusión de la EIP-8479 refleja por lo tanto una estrategia de seguridad prospectiva, no una respuesta a un ataque cuántico inmediato.
Por qué la flexibilidad de Blob importa para ethereum
La segunda motivación se refiere a la forma en que los rollups compran y publican capacidad de datos. Las estructuras de datos de tamaño fijo pueden generar ineficiencias cuando el lote de transacciones de un rollup no coincide con la capacidad disponible. Un lote más pequeño puede dejar espacio sin usar, mientras que esperar para acumular un lote más grande puede introducir retrasos adicionales en la publicación.
Los blobs de tamaño variable buscan dar a los operadores de rollup un mayor control sobre este equilibrio. En lugar de tratar cada envío como una unidad de capacidad fija, el diseño propuesto permite que los tamaños de blob admitidos aumenten en potencias de dos. Esto podría hacer que la publicación de datos sea más adaptable a diferentes volúmenes de transacciones y requisitos operativos.
¿Cómo reemplaza EIP-8479 KZG con STARKs post-cuánticos?
El cambio criptográfico central es la sustitución de los compromisos KZG y las pruebas de celda por compromisos Merkle de Keccak-256, rutas de autenticación Merkle y pruebas LeanDA STARK. El diseño separa la tarea de autenticar muestras individuales de datos de la tarea de demostrar que el blob completo fue codificado y comprometido correctamente. Esto tiene como objetivo eliminar la dependencia de suposiciones de emparejamiento de curvas elípticas y eliminar la configuración de confianza requerida por la construcción KZG existente.
Compromisos Merkle Keccak-256
Un árbol Merkle organiza los datos mediante hash repetidos. Los elementos de datos individuales se hash primero en nodos hoja, tras lo cual los pares de hashes se combinan para crear nodos de niveles superiores. El proceso continúa hasta que una única raíz Merkle representa la estructura de datos subyacente.
En el diseño propuesto de PeerDAS, cada blob recibe un compromiso Merkle basado en Keccak-256. Cuando un nodo muestrea una celda de datos específica, puede recibir la ruta de autenticación Merkle correspondiente y verificar independientemente que la celda pertenece al blob comprometido. Esto proporciona una forma de autenticar los datos muestreados sin depender de las pruebas de celda KZG.
Keccak-256 es particularmente relevante porque las construcciones criptográficas basadas en funciones hash generalmente se consideran más adecuadas para la seguridad post-cuántica que los esquemas basados en logaritmos discretos de curva elíptica. Los algoritmos de búsqueda cuántica aún pueden reducir la seguridad efectiva de las funciones hash, por lo que los parámetros de seguridad y los detalles de implementación siguen siendo importantes. Por lo tanto, la propuesta debe entenderse como un paso hacia suposiciones criptográficas resistentes a la computación cuántica, no como una garantía contra todos los ataques cuánticos futuros.
¿Qué verifica realmente LeanDA STARK?
La autenticación de Merkle establece que una celda muestreada pertenece a una estructura de datos comprometida específica, pero el protocolo también debe establecer que la codificación de los datos del blob y la generación del compromiso son correctas. Aquí es donde LeanDA STARK adquiere importancia.
La prueba STARK propuesta demuestra dos propiedades centrales: que el blob satisface su relación de codificación Reed-Solomon y que el compromiso Merkle asociado ha sido derivado correctamente. La codificación Reed-Solomon introduce redundancia que permite reconstruir porciones de datos faltantes cuando suficientes porciones válidas siguen disponibles. La prueba permite a la red verificar las relaciones de codificación y compromiso relevantes sin requerir que cada verificador repita por completo el cálculo de forma independiente.
La propuesta también conecta las pruebas LeanDA con EIP-8288, que proporciona un marco de agregación recursiva STARK a nivel de bloque. En lugar de tratar cada prueba como una tarea de verificación aislada, el diseño introduce marcos de dependencia de disponibilidad de datos cuyas pruebas pueden integrarse en la agregación a nivel de bloque más amplia. Esta integración es técnicamente significativa porque los costos de generación, agregación y verificación de pruebas influirán en si el diseño es práctico para los clientes de ethereum.
¿Cómo cambian los blobs de tamaño variable la disponibilidad de datos en ethereum?
La propuesta introduce tamaños de blob que van desde 2 KiB hasta 512 KiB, con longitudes de bytes admitidas restringidas a potencias de dos. Cada blob conserva 128 columnas, lo que significa que la longitud en bytes de las unidades de datos individuales cambia mientras la estructura general de columnas permanece consistente. Esto representa un alejamiento significativo del modelo tradicional de blob de tamaño fijo utilizado por la infraestructura existente de disponibilidad de datos de ethereum.
De Capacidad Fija a Publicación de Datos Flexible
Bajo el diseño propuesto, un rollup podría seleccionar un tamaño de blob que se ajuste más de cerca a la cantidad de datos que necesita publicar. Un lote de transacciones pequeño podría usar un blob más pequeño, mientras que un lote más grande podría seleccionar una mayor capacidad. El objetivo es reducir el relleno innecesario y brindar a los rollups mayor flexibilidad para equilibrar los costos de disponibilidad de datos contra la frecuencia de publicación.
Los siguientes ejemplos ilustran el rango de capacidad propuesto:
-
2 KiB: Una pequeña entrega de datos que requiere capacidad limitada.
-
8 KiB–64 KiB: Tamaños intermedios para lotes de transacciones relativamente compactos.
-
128 KiB: Un punto de referencia familiar que corresponde a la capacidad tradicional de blob.
-
256 KiB–512 KiB: Envíos más grandes que requieren capacidad adicional de datos.
La propuesta también especifica cambios en las transacciones que transportan blobs. En lugar de depender únicamente de la representación de hash versionado existente, la estructura de transacción propuesta utiliza una raíz Merkle y un campo de longitud en bytes explícito. Las transacciones que transportan blobs se representan mediante transacciones de marco EIP-8141, vinculando la nueva estructura de datos al diseño general del formato de transacción.
¿Cómo podrían afectar los bloques de tamaño variable los costos de gas?
La capacidad flexible de blobs podría mejorar la utilización de datos, pero la relación entre el tamaño del blob y las tarifas no es tan sencilla como elegir un blob más pequeño y pagar automáticamente menos. La propuesta también cambia los requisitos de red y la contabilidad de gas, incluyendo los costos asociados con la autenticación Merkle y el nuevo proceso de verificación.
Para los operadores de rollup, el cálculo relevante implica más que la capacidad de datos en bruto. Deben considerar el tamaño de los lotes de transacciones, la frecuencia de publicación de blobs, los gastos de generación de pruebas, la propagación de la red y el precio de mercado del gas de blob. Un blob más pequeño puede ser más eficiente para una carga de trabajo, mientras que una entrega más grande puede ser preferible para otra.
Por lo tanto, el diseño introduce la oportunidad de optimizar la publicación de datos en lugar de prometer una reducción universal de tarifas. Los ahorros reales dependerán de los umbrales de implementación y de cómo los desarrolladores de rollup adapten sus estrategias de agrupamiento después de que la propuesta sea sometida a una revisión adicional.
¿Qué podría significar EIP-8479 para las redes de capa 2 de ethereum?
La propuesta podría hacer que la infraestructura de disponibilidad de datos de Ethereum sea más adaptable a las necesidades de Layer 2 networks, especialmente los rollups que publican datos de transacciones en lotes. Arbitrum, Optimism y Base son ejemplos de importantes ecosistemas de escalado de Ethereum cuyos operadores tienen interés en una publicación de datos eficiente y predecible. Sin embargo, EIP-8479 no cambia directamente sus entornos de ejecución ni garantiza reducciones inmediatas en las tarifas de transacción de los usuarios.
Beneficios potenciales para los operadores de Rollup
Los rollups deben equilibrar la frecuencia de envío de lotes de transacciones con el costo de publicar datos en ethereum. Los blobs de capacidad fija pueden crear una desconexión entre los requisitos reales de datos y la capacidad adquirida. Los blobs de tamaño variable podrían brindar a los operadores más opciones al diseñar tamaños de lote y horarios de publicación.
Por ejemplo, un rollup con una actividad de transacciones relativamente baja podría preferir publicar lotes más pequeños sin esperar a acumular suficientes datos para llenar una estructura de capacidad fija más grande. Un rollup de alto volumen podría usar blobs más grandes para consolidar más datos en cada envío. Estas decisiones podrían mejorar la flexibilidad operativa y ayudar a los desarrolladores a optimizar la relación entre los costos de disponibilidad de datos y la latencia de las transacciones.
El beneficio no necesariamente será idéntico en todas las redes. Los rollups difieren en volumen de transacciones, técnicas de compresión, modelos de secuenciación y estrategias de publicación de datos. En consecuencia, los desarrolladores deberán evaluar si la flexibilidad adicional supera los costos de implementación y generación de pruebas.
Implicaciones para la competencia de Layer 2 de Ethereum
Ethereum compite con otros ecosistemas de cadena de bloques que ofrecen enfoques distintos para la ejecución, el asentamiento de transacciones y la disponibilidad de datos. Mejorar la eficiencia de su infraestructura de blobs podría respaldar la posición de Ethereum como capa de asentamiento y disponibilidad de datos para aplicaciones basadas en rollup.
Sin embargo, la competitividad de la red depende de más que la capacidad de blobs. Los desarrolladores y usuarios también consideran las tarifas de transacción, el rendimiento de las aplicaciones, la liquidez, la interoperabilidad, la seguridad y el soporte del ecosistema. EIP-8479 aborda una parte importante de esta ecuación más amplia: la infraestructura criptográfica y de disponibilidad de datos que sustenta el escalado mediante rollups.
Su contribución potencial se evalúa mejor como una mejora en la infraestructura que podría fortalecer el entorno de desarrollo de Layer 2 de Ethereum con el tiempo, en lugar de como una ventaja competitiva inmediata que ya se ha demostrado.
¿Cómo encaja EIP-8479 en la hoja de ruta post-cuántica de ethereum?
EIP-8479 aborda el componente de disponibilidad de datos de la agenda de investigación post-cuántica más amplia de Ethereum. No reemplaza cada primitiva criptográfica utilizada por la red, ni hace que Ethereum sea completamente resistente a la computación cuántica. Las firmas de consenso, la autenticación de cuentas y otros sistemas criptográficos requieren sus propias estrategias de migración.
Tres áreas criptográficas requieren atención
La arquitectura criptográfica de ethereum incluye varios componentes con diferentes suposiciones de seguridad:
Firmas de consenso: Los validadores de Ethereum utilizan firmas BLS para participar en el consenso y agrupar atestaciones. Dado que BLS depende de la criptografía de emparejamiento de curvas elípticas, los investigadores están explorando sistemas de firma alternativos que puedan ofrecer propiedades de seguridad post-cuántica más robustas.
Firmas de cuenta: Las cuentas externas propiedad estándar utilizan firmas ECDSA. Una computadora cuántica suficientemente potente podría teóricamente utilizar el algoritmo de Shor para derivar información de la clave privada a partir de claves públicas expuestas bajo las suposiciones relevantes de curva elíptica. La abstracción de cuenta y los mecanismos alternativos de verificación de firmas son algunas de las aproximaciones que podrían respaldar una migración futura.
Compromisos de disponibilidad de datos: Los compromisos KZG son el componente directamente objetivo de esta propuesta. Reemplazarlos con compromisos Merkle basados en hashes y pruebas STARK abordaría una parte específica de la exposición criptográfica del protocolo.
Estas áreas están relacionadas, pero no pueden actualizarse mediante un solo cambio. La transición post-cuántica de ethereum requerirá trabajo coordinado en consenso, ejecución, redes e infraestructura de aplicaciones.
Por qué importan los diseños basados en STARK
Los sistemas STARK utilizan funciones hash y construcciones de prueba transparentes en lugar de depender de emparejamientos de curvas elípticas y una configuración de confianza convencional. Sus propiedades los convierten en candidatos para aplicaciones post-cuánticas, aunque aún se deben evaluar el tamaño de la prueba, el rendimiento de verificación, la complejidad de implementación y los parámetros de seguridad del hash.
EIP-8479 también demuestra la importancia de conectar la investigación criptográfica con la ingeniería de protocolos. Un sistema de prueba teóricamente seguro no es suficiente por sí solo: debe funcionar dentro de los límites de tiempo de bloque, ancho de banda, recursos del validador y compatibilidad con clientes de Ethereum. La integración de la propuesta con EIP-8288 refleja este requisito de considerar la verificación de pruebas a nivel de bloque más amplio.
¿Cuál es el estado actual de EIP-8479?
Al 2 de noviembre de 2026, la propuesta sigue siendo un borrador en etapa inicial en lugar de una actualización aprobada de la red Ethereum. Su discusión del 1 de noviembre y la solicitud de extracción en GitHub invitan a comentarios de desarrolladores de rollups, equipos de consenso y cliente de ejecución, contribuyentes de redes e investigadores en criptografía. La especificación identifica explícitamente varias cuestiones sin resolver, lo que significa que queda un trabajo sustancial de diseño e implementación antes de que se pueda considerar cualquier despliegue en mainnet.
Desafíos técnicos destacados
El primer problema es la finalización del programa invitado LeanDA y su hash de clave de verificación. Estos componentes son importantes porque definen el cálculo que se está probando y los parámetros utilizados por los verificadores para comprobar la prueba STARK resultante.
El segundo problema es la implementación del cliente. La propuesta requiere cambios coordinados en los componentes de la capa de ejecución, la capa de consenso y la red. Los desarrolladores deben asegurar que diferentes clientes interpreten de manera consistente los compromisos de blobs, los campos de transacción y los procedimientos de autenticación de datos.
El tercer problema concierne al rendimiento. La generación de pruebas, la agregación recursiva, las rutas de autenticación Merkle y el ancho de banda de PeerDAS deben ser evaluados en diferentes configuraciones de nodo. Un diseño que funcione en un entorno de investigación controlado también debe seguir siendo práctico para la red de validadores en general.
Finalmente, los operadores de rollup deben confirmar si la distribución propuesta del tamaño de los blobs coincide con la demanda del mundo real. Los comentarios sobre las capacidades preferidas ayudarán a determinar si los blobs de tamaño variable ofrecen beneficios significativos más allá de la complejidad adicional del protocolo.
¿Qué deberían vigilar los desarrolladores e inversores a continuación?
Los desarrollos más importantes serán el avance en la especificación, la publicación de un prototipo funcional, una revisión criptográfica independiente y los resultados de rendimiento. Los comentarios de los equipos de rollup también ayudarán a determinar si el rango de capacidad propuesto es útil para cargas de trabajo reales de publicación de datos.
El estado de las propuestas relacionadas también importa. EIP-8288 proporciona el marco de agregación de pruebas recursivas referenciado por LeanDA, mientras que EIP-8141 suministra la estructura propuesta de transacción de marco. Su progreso de implementación podría influir en la ruta de integración para el nuevo diseño.
Para los inversores, la distinción entre una propuesta de investigación y una actualización programada es esencial. Una Draft EIP puede influir en la narrativa de desarrollo a largo plazo de Ethereum, pero no debe considerarse como evidencia de que una función específica llegará al mainnet o producirá una variación medible en la demanda de ETH.
¿Podría EIP-8479 afectar el precio de ETH y la adopción de ethereum?
EIP-8479 tiene implicaciones potenciales a largo plazo para la infraestructura de Ethereum, pero su impacto inmediato en ETH valuation probablemente esté más determinado por las expectativas del mercado que por cambios directos en la economía de la red. La propuesta no ha sido implementada y no hay un calendario confirmado de activación en mainnet. En consecuencia, aún no proporciona evidencia medible de tarifas más bajas para rollups, mayor utilización de blobs o mayor demanda de transacciones en ETH.
A corto plazo, los operadores y analistas es probable que monitoreen más de cerca la actividad de trading de spot de ETH, la postura en derivados, los flujos de ETF y las condiciones generales del mercado. Las noticias sobre la propuesta podrían fortalecer el interés en la hoja de ruta técnica de Ethereum, pero una especificación preliminar por sí sola no es suficiente para establecer un catalizador de precio sostenido.
A largo plazo, una implementación exitosa podría respaldar el papel de Ethereum como capa segura de disponibilidad y liquidación de datos. Una capacidad de blobs más flexible podría ayudar a los rollups a gestionar la publicación de datos, mientras que los compromisos basados en hash y las pruebas STARK podrían contribuir a la transición post-cuántica de la red. Estas mejoras podrían fortalecer la confianza de los desarrolladores y la participación del ecosistema si entregan beneficios de rendimiento prácticos.
Sin embargo, la valoración general de ETH seguirá dependiendo de la actividad de la red, el staking, la dinámica de la oferta, la adopción de aplicaciones y la competencia de otros ecosistemas de cadena de bloques. Por lo tanto, EIP-8479 debe considerarse como un componente del desarrollo a largo plazo de la infraestructura de Ethereum, y no como una tesis de inversión independiente.
Conclusión
El diseño propuesto de PeerDAS post-cuántico y de blobs de tamaño variable de Ethereum representa una dirección de investigación importante para la infraestructura de disponibilidad de datos de la red. Al reemplazar los compromisos KZG y las pruebas de celda con compromisos Merkle de Keccak-256 y verificación LeanDA STARK, la propuesta explora una arquitectura criptográfica mejor alineada con los objetivos de seguridad post-cuántica a largo plazo. Su diseño de blobs de tamaño variable, que oscila entre 2 KiB y 512 KiB, también introduce mayor flexibilidad para los rollups que necesitan publicar distintos volúmenes de datos de transacciones.
Sin embargo, la propuesta aún se encuentra en una etapa inicial de borrador. Sus parámetros de prueba, integración con clientes, cambios en la red y requisitos de rendimiento aún deben abordarse mediante revisión técnica y pruebas de implementación. Para Ethereum, la importancia de este desarrollo radica en la combinación de resiliencia criptográfica y eficiencia de datos de Layer 2. Si finalmente mejora la economía de los rollups o influye en la adopción de ETH dependerá de una implementación exitosa y beneficios medibles para el ecosistema. Por ahora, EIP-8479 se entiende mejor como una propuesta de infraestructura con visión de futuro dentro de la agenda más amplia de escalado e investigación post-cuántica de Ethereum.
Preguntas frecuentes
¿Cuál es la diferencia entre un EIP y un ERC?
Una Propuesta de Mejora de Ethereum (EIP) describe cambios propuestos al protocolo, estándares o procesos de desarrollo de Ethereum. Una Solicitud de Comentarios de Ethereum (ERC) generalmente especifica estándares de capa de aplicación, como interfaces de tokens y convenciones de contratos inteligentes. EIP-8479 es una propuesta Core porque se refiere a la disponibilidad de datos fundamental y al comportamiento del protocolo.
¿Qué significa PeerDAS?
PeerDAS significa Muestreo de Disponibilidad de Datos entre Pares. Es un mecanismo que permite a los nodos de ethereum muestrear porciones de datos de blobs distribuidos en lugar de descargar cada elemento de datos. Este enfoque ayuda a reducir los requisitos de datos individuales de los nodos mientras mantiene una forma de verificar la disponibilidad de los datos.
¿Qué es la codificación Reed-Solomon?
La codificación Reed-Solomon es un código corrector de errores que añade redundancia a los datos. Esto permite reconstruir las partes faltantes cuando suficientes partes válidas siguen disponibles. Es relevante para PeerDAS porque la disponibilidad distribuida de datos depende de la capacidad de la red para recuperar los datos originales a partir de componentes muestreados y distribuidos.
¿Qué es una configuración de confianza en criptografía?
Una configuración de confianza es un proceso de inicialización utilizado por ciertos sistemas criptográficos para generar parámetros públicos. Si la información secreta no se destruye adecuadamente, puede generar riesgos de seguridad. Los compromisos KZG dependen de una configuración de confianza, mientras que el diseño propuesto basado en STARK busca evitar este requisito mediante una construcción de prueba transparente.
¿Cómo pueden los usuarios seguir el progreso de una Propuesta de Mejora de Ethereum?
Los usuarios pueden seguir el repositorio de Ethereum EIPs en GitHub, revisar discusiones técnicas en Ethereum Magicians y monitorear actualizaciones de los desarrolladores de Ethereum. Los hitos importantes incluyen revisiones de especificaciones, revisiones independientes, implementaciones de prototipos, pruebas de clientes y cualquier decisión formal sobre la inclusión en una futura actualización de la red.
Descargo de responsabilidad: Esta información general del mercado, posiblemente proveniente de fuentes terceras, comerciales o patrocinadas, se proporciona únicamente con fines de referencia y educativos y no constituye asesoramiento financiero o de inversión, una oferta, solicitud o garantía. Renunciamos a toda responsabilidad por su precisión, completitud, confiabilidad y cualquier pérdida resultante. Las inversiones/opciones de trading son arriesgadas; el rendimiento pasado no garantiza resultados futuros. Los usuarios deben investigar, juzgar con prudencia y asumir toda la responsabilidad. Para más detalles, consulte las Condiciones de uso y Divulgación de riesgos de KuCoin.
Aviso: Esta página fue traducida utilizando tecnología de IA para tu conveniencia. Para obtener la información más precisa, consulta la versión original en inglés.