Resumen:

· La red B^2 Network ha establecido una capa de Disponibilidad de Datos (DA) conocida como B^2 Hub dentro de la cadena de Bitcoin, inspirándose en los conceptos de Celestia. Esta red de capa DA implementa muestreo de datos y codificación de borrado para garantizar la distribución rápida de nuevos datos a numerosos nodos externos y evitar la retención de datos. Además, el Committer dentro de la red B^2 Hub es responsable de subir el índice de almacenamiento y el hash de datos de DA a la cadena de Bitcoin para acceso público.

Para aliviar la carga en los nodos de la capa DA, los datos históricos en B^2 Hub no se retienen permanentemente. En consecuencia, B^2 se ha esforzado por reconstruir una red de almacenamiento, empleando un mecanismo de incentivo de almacenamiento similar a Arweave para incentivar a más nodos a almacenar conjuntos de datos históricos completos a cambio de recompensas de almacenamiento;

· En cuanto a la verificación de estado, B^2 adopta un enfoque de verificación híbrido para validar pruebas de conocimiento cero (ZK) fuera de la cadena y aprovecha el concepto de bitVM para desafiar las trazas de verificación de pruebas de ZK en la cadena. La seguridad de la red B^2 se asegura cuando un nodo retador inicia un desafío al detectar un error, alineándose con el modelo de confianza del protocolo de prueba de fraude. Sin embargo, debido a la utilización de pruebas de conocimiento cero (ZK), este proceso de verificación de estado es esencialmente híbrido en su naturaleza;

·En línea con la hoja de ruta futura de B^2 Network, el B^2 Hub compatible con EVM tiene el potencial de servir como una capa de verificación fuera de la cadena y una capa DA que conecta múltiples soluciones de la Capa 2 de Bitcoin. Su objetivo es evolucionar hacia una capa de expansión funcional fuera de la cadena de Bitcoin similar a BTCKB. Dadas las limitaciones de Bitcoin para soportar varios escenarios, se prevé que el desarrollo de una capa de expansión funcional fuera de la cadena se convierta en una práctica prevalente dentro del ecosistema de la Capa 2.

B^2 Hub: capa universal de Disponibilidad de Datos (DA) y capa de verificación dentro de la cadena Bitcoin

El ecosistema actual de Bitcoin se asemeja a un vasto panorama de oportunidades y riesgos, donde las secuelas del Verano de las Inscripciones han insuflado nueva vida a este dominio, similar a un suelo fértil e inexplorado con el aroma de la riqueza en el aire. El advenimiento de la Capa 2 de Bitcoin a principios de este año ha transformado este paisaje antes desolado en un centro de aspiraciones para numerosos visionarios.

Volviendo al meollo de la cuestión: la definición de Capa 2 sigue siendo un punto de controversia entre las personas. ¿Es una cadena lateral? ¿Un indexador? ¿El término Capa 2 engloba cadenas que establecen conexiones? ¿Puede un simple complemento dependiente de Bitcoin y Ethereum calificar como una Capa? Estas preguntas se asemejan a ecuaciones no resueltas sin una solución definitiva.

Según las perspectivas de las comunidades de Ethereum y Celestia, la Capa 2 representa una instancia distinta de una cadena de bloques modular. En este contexto, existe una estrecha interdependencia entre la llamada “segunda capa” y “primera capa”. La seguridad de la Capa 1 puede ser heredada parcial o significativamente por la red de la segunda capa. La seguridad en sí misma abarca varias subcategorías, incluidas DA, verificación de estado, verificación de retiro, resistencia a la censura y resistencia a la reorganización.

Dadas las limitaciones inherentes de la red Bitcoin, no es inherentemente propicia para admitir una red completa de Capa 2. Por ejemplo, en términos de DA, la capacidad de procesamiento de datos de Bitcoin se retrasa significativamente con respecto a la de Ethereum. Con un tiempo promedio de generación de bloques de 10 minutos, la tasa máxima de procesamiento de datos de Bitcoin es apenas de 6.8KB/s, aproximadamente 1/20 parte de la capacidad de Ethereum. En consecuencia, el espacio de bloque congestionado resulta en costos elevados para la publicación de datos.

(El costo de publicar datos en un bloque de Bitcoin puede incluso alcanzar $5 por KB)

Si la Capa 2 publica directamente los datos de transacción recién agregados al bloque de Bitcoin, no logrará un alto rendimiento ni tarifas de transacción bajas. Para abordar esto, un enfoque es comprimir significativamente los datos antes de cargarlos en el bloque de Bitcoin. Citrea actualmente emplea este método, afirmando que cargarán los cambios de estado (diferencia de estado) que ocurren en múltiples cuentas en la cadena de Bitcoin, acompañados por certificados ZK correspondientes durante un período específico.

Esto permite a cualquier persona verificar la validez de la diferencia de estado y ZKP descargados de la red principal de Bitcoin mientras mantiene datos livianos en la cadena.

(El antiguo libro blanco de Polygon Hermez explica el principio del esquema de compresión anterior)

A pesar de la compresión significativa del tamaño de los datos lograda por este método, puede encontrar cuellos de botella en escenarios donde numerosas transacciones generan cambios de estado en muchas cuentas en un corto período. Si bien es más ligero que cargar directamente datos de transacciones individuales, cargar cambios de cuentas todavía conlleva costos sustanciales de liberación de datos.

Como resultado, muchas soluciones de Capa 2 de Bitcoin optan por no cargar datos de DA a la red principal de Bitcoin y en su lugar utilizan capas de DA de terceros como Celestia. En contraste, B^2 implementa un enfoque diferente al establecer una red de Disponibilidad de Datos (DA) directamente debajo de la cadena, conocida como B^2 Hub. En este diseño, los datos cruciales como datos de transacción o diferencias de estado se almacenan fuera de la cadena, con solo sus índices de almacenamiento y hash de datos (denominados datos para simplificar) cargados en la red principal de Bitcoin.

Estos hashes de datos e índices de almacenamiento se registran en la cadena de Bitcoin de manera similar a las inscripciones. Al ejecutar un nodo de Bitcoin, las personas pueden acceder localmente al hash de datos y al índice de almacenamiento. Utilizando el valor del índice, pueden recuperar los datos originales de la capa de almacenamiento o DA fuera de la cadena de B^2. El hash de datos permite verificar la corrección de los datos obtenidos de la capa de DA fuera de la cadena con respecto al hash correspondiente en la cadena de Bitcoin. Este enfoque sencillo permite a las soluciones de Capa 2 mitigar la dependencia de la mainnet de Bitcoin para problemas de DA, reducir costos de transacción y lograr un alto rendimiento.

Sin embargo, es crucial reconocer que las plataformas DA de terceros bajo la cadena pueden participar en prácticas de retención de datos, evitando el acceso externo a nuevos datos, un fenómeno conocido como un "ataque de retención de datos." Varias soluciones DA abordan este problema de manera diferente, con el objetivo compartido de difundir datos de manera rápida y amplia para evitar que unos pocos nodos controlen los permisos de acceso a los datos.

Según la nueva hoja de ruta oficial de B^2 Network, su solución DA se basa en Celestia. En el último diseño, los proveedores de datos de terceros proporcionarán continuamente datos a la red de Celestia. Los productores de bloques de Celestia organizarán estos fragmentos de datos en forma de Árbol de Merkle, los insertarán en bloques de TIA y los transmitirán a la red. Validador/nodo completo.

Dado que hay una gran cantidad de datos y los bloques son relativamente grandes, la mayoría de las personas no pueden permitirse ejecutar nodos completos y solo pueden ejecutar nodos ligeros. El nodo ligero no sincroniza el bloque completo, sino que solo sincroniza un encabezado de bloque con la raíz del árbol de Mekrle escrito en él.

Según la última hoja de ruta de la red B^2, su solución DA se inspira en Celestia. Bajo este diseño, los proveedores de datos externos suministran continuamente datos a la red Celestia. Los productores de bloques dentro de Celestia organizan estos fragmentos de datos en una estructura de árbol de Merkle, los incrustan en bloques de TIA y los difunden a los validadores y nodos completos de la red. Debido al volumen sustancial de datos y al tamaño de los bloques grandes, muchas personas optan por ejecutar nodos ligeros en lugar de nodos completos. Los nodos ligeros sincronizan solo los encabezados de bloque que contienen la raíz del árbol de Merkle.

Si bien los nodos ligeros carecen de una vista integral del Árbol de Merkle y no pueden verificar el contenido de nuevos datos, pueden solicitar nodos hoja específicos a los nodos completos. Los nodos completos proporcionan los nodos hoja solicitados junto con las Pruebas de Merkle correspondientes para convencer a los nodos ligeros de su existencia dentro del Árbol de Merkle del bloque de Celestia, asegurando que no se trate de datos fabricados.

(Fuente de la imagen: W3 Hitchhiker)

En la red de Celestia, existen una multitud de nodos ligeros que participan en el muestreo de datos de alta frecuencia desde varios nodos completos. Estos nodos ligeros seleccionan aleatoriamente fragmentos de datos específicos del Árbol de Merkle y los diseminan rápidamente y eficientemente a otros nodos conectados, con el objetivo de distribuir datos a una amplia audiencia de personas y dispositivos. Este enfoque facilita la rápida diseminación de datos, garantizando que un número suficiente de nodos reciba prontamente los datos más recientes, eliminando así la necesidad de depender de un grupo limitado de proveedores de datos. Este objetivo fundamental subraya la esencia principal de la Disponibilidad de Datos (DA) y la distribución de datos.

Sin embargo, a pesar de la eficacia de la solución mencionada anteriormente para permitir un acceso rápido a los datos, no garantiza la integridad de la fuente de datos. Por ejemplo, un productor de bloques de Celestia podría insertar datos erróneos en un bloque, complicando los esfuerzos para reconstruir el conjunto de datos completo y preciso. Incluso si las personas obtienen todos los fragmentos de datos en el bloque, no pueden restaurar el conjunto de datos completo que "debería estar incluido". (Nota: La palabra "debería" es importante aquí).

Además, en escenarios donde ciertos datos de transacción permanecen ocultos para partes externas, retener tan solo el 1% de los fragmentos de datos puede impedir que los externos reconstruyan todo el conjunto de datos, una situación que recuerda a los ataques de retención de datos.

En el contexto descrito anteriormente, comprender la disponibilidad de datos se refiere a si los datos de transacción dentro de un bloque están completos, accesibles y listos para compartirse fácilmente con fines de verificación. Contrariamente a la percepción común, la disponibilidad no denota únicamente la accesibilidad de los datos históricos de blockchain para entidades externas. Por lo tanto, los funcionarios de Celestia y los fundadores de L2BEAT abogan por renombrar la disponibilidad de datos como “publicación de datos”, lo que significa la publicación de un conjunto de datos de transacciones completo y accesible dentro de un bloque.

Para abordar el problema de los ataques de retención de datos, Celestia emplea codificación de borrado bidimensional. Si al menos 1/4 de los fragmentos de datos (códigos de borrado) dentro de un bloque son válidos, las personas pueden reconstruir el conjunto de datos original. Sin embargo, si un productor de bloques inserta 3/4 de fragmentos de datos erróneos, la reconstrucción del conjunto de datos se vuelve inviable. Es importante destacar que la presencia excesiva de datos no deseados en un bloque puede ser identificada fácilmente por nodos ligeros, actuando como un disuasivo contra actividades maliciosas por parte de los productores de bloques.

Al implementar esta solución, Celestia mitiga efectivamente la retención de datos en su plataforma de distribución de datos. B^2 Network planea utilizar la metodología de muestreo de datos de Celestia como punto de referencia fundamental en el futuro, potencialmente integrando tecnologías criptográficas como el compromiso KZG para mejorar la eficiencia y confiabilidad de los procesos de muestreo y verificación de datos llevados a cabo por nodos ligeros.

Es crucial reconocer que si bien la solución mencionada aborda la retención de datos dentro de la plataforma DA en sí misma, en la infraestructura de la Capa 2, tanto la plataforma DA como el Secuenciador poseen capacidades de retención de datos. En flujos de trabajo como el de B^2 Network, el Secuenciador genera nuevos datos organizando y procesando transacciones de usuarios y cambios de estado resultantes en lotes antes de transmitirlos a los nodos del B^2 Hub que funcionan como la capa DA.

En los casos en que surjan anomalías dentro de un lote generado por el Secuenciador, existe un riesgo de retención de datos u otras actividades maliciosas. En consecuencia, al recibir el lote, la red DA de B^2 Hub verifica meticulosamente su contenido y rechaza cualquier lote problemático. Así, B^2 Hub no solo funciona como una capa DA similar a Celestia, sino que también opera como una capa de verificación fuera de la cadena similar a CKB en el protocolo RGB++.

(Diagrama de la estructura subyacente de la red B^2 incompleto)

De acuerdo con la última hoja de ruta tecnológica de la red B^2, una vez que B^2 Hub recibe y verifica un lote, lo retiene durante un período específico antes de que expire y lo elimine del nodo local. Para abordar las preocupaciones de obsolescencia y pérdida de datos similares a EIP-4844, B^2 Network establece una red de nodos de almacenamiento encargados de almacenar permanentemente los datos del lote para facilitar la recuperación de datos históricos cuando sea necesario.

Sin embargo, es poco probable que las personas operen un nodo de almacenamiento B^2 sin una razón convincente. Para alentar a más participantes a ejecutar nodos de almacenamiento y mejorar la confianza de la red, es necesario establecer un mecanismo de incentivos. La implementación de dicho mecanismo requiere medidas para prevenir actividades fraudulentas. Por ejemplo, si un sistema de incentivos recompensa a las personas que almacenan datos localmente en sus dispositivos, existe el riesgo de un comportamiento deshonesto donde alguien elimina parte de los datos después de la descarga mientras afirma falsamente que sus datos almacenados están completos, una forma de trampa demasiado común.

Filecoin emplea protocolos de prueba conocidos como PoRep y PoSt, lo que permite a los nodos de almacenamiento proporcionar certificados de almacenamiento como evidencia para demostrar que han almacenado datos de forma segura en un plazo especificado. Sin embargo, este enfoque de prueba de almacenamiento implica la generación de pruebas ZK, que son intensivas computacionalmente y generan demandas significativas de hardware en los nodos de almacenamiento, lo que potencialmente lo hace económicamente inviable.

En la última hoja de ruta tecnológica de B^2 Network, los nodos de almacenamiento implementarán un mecanismo similar a Arweave, compitiendo por la oportunidad de producir bloques para ganar incentivos de tokens. Si un nodo de almacenamiento elimina datos de manera encubierta, su probabilidad de convertirse en el próximo productor de bloques disminuye. Los nodos que preservan la mayor cantidad de datos tienen una mayor probabilidad de producir con éxito bloques y recibir mayores recompensas. En consecuencia, es ventajoso para la mayoría de los nodos de almacenamiento mantener el conjunto de datos históricos completo para optimizar sus perspectivas de producción de bloques.

Esquema de verificación de estado mezclado con ZK y prueba de fraude

Anteriormente, elaboramos sobre la solución de Disponibilidad de Datos (DA) de la Red B^2, y ahora profundizaremos en su mecanismo de verificación de estado. El término "esquema de verificación de estado" se refiere a cómo la Capa 2 asegura una transición de estado lo suficientemente "confiable".

(El sitio web L2BEAT evalúa los cinco principales indicadores de seguridad para Scroll. La Validación del Estado se refiere al esquema de verificación del estado)

Como se destaca en el sitio web de L2BEAT, que evalúa los indicadores de seguridad para Scroll, la Validación de Estado aborda específicamente el esquema de verificación de estado. En la red B^2 y la mayoría de los procesos de Capa 2, los nuevos datos son originados por el secuenciador. Esta entidad consolida y procesa transacciones iniciadas por el usuario junto con sus cambios de estado resultantes posteriores a la ejecución. Estas modificaciones se agrupan en lotes y se difunden a varios nodos dentro de la red de Capa 2, abarcando nodos completos estándar de Capa 2 y nodos de Hub B^2.

Al recibir los datos del lote, el nodo B^2 Hub analiza meticulosamente y verifica su contenido, abarcando la anteriormente mencionada "verificación de estado". Básicamente, la verificación de estado implica validar la precisión de los "cambios de estado posteriores a la ejecución de la transacción" documentados en el lote generado por el secuenciador. Cualquier estado erróneo dentro de un lote provoca el rechazo por parte del nodo B^2 Hub.

Funcionando como una cadena pública de Prueba de Participación (POS), B^2 Hub distingue entre productores de bloques y verificadores. Periódicamente, los productores de bloques de B^2 Hub generan nuevos bloques y los diseminan a otros nodos (validadores). Estos bloques encapsulan datos de Batch presentados por el secuenciador, reflejando un proceso similar a Celestia. Los nodos externos solicitan con frecuencia fragmentos de datos del nodo de B^2 Hub, facilitando la distribución de datos de Batch a numerosos dispositivos nodales, incluida la red de almacenamiento mencionada anteriormente.

Dentro de B^2 Hub opera un papel fundamental conocido como el Committedor. Esta entidad hashea los datos del Lote (específicamente la raíz de Merkle), almacena el índice y lo presenta en forma de inscripción en la cadena de Bitcoin. El acceso al hash de datos y al índice de almacenamiento permite la recuperación de datos completos de la capa de almacenamiento/lote fuera de la cadena. Suponiendo que N nodos almacenan datos del Lote bajo la cadena, una vez que un nodo está dispuesto a compartir datos con entidades externas, cualquier parte interesada puede acceder a los datos requeridos. La suposición de confianza en este escenario es 1/N.

Ciertamente, es evidente que en el proceso mencionado anteriormente, B^2 Hub, encargado de validar las transiciones de estado de la Capa 2, opera de forma independiente a la red principal de Bitcoin, sirviendo únicamente como una capa de verificación fuera de la cadena. En consecuencia, el esquema de verificación de estado de la Capa 2 en este momento no alcanza la confiabilidad de la red principal de Bitcoin.

En general, ZK Rollup tiene la capacidad de heredar completamente la seguridad de la Capa 1. Sin embargo, dadas las limitaciones actuales de la cadena de Bitcoin en el soporte solo de cálculos básicos y la falta de capacidades directas de verificación de pruebas ZK, ninguna solución de Capa 2 en Bitcoin puede rivalizar con el modelo de seguridad de Ethereum, especialmente aquellas que emplean técnicas de ZK Rollup como Citrea y BOB.

Hasta ahora, el enfoque más viable, como se explica en el libro blanco de BitVM, implica trasladar procesos computacionales complejos de la cadena Bitcoin. Solo los cálculos esenciales se migran a la cadena cuando sea necesario. Por ejemplo, las trazas de computación generadas durante la verificación de la prueba ZK pueden ser divulgadas públicamente y compartidas con entidades externas para su examen. Si surgen discrepancias en los pasos de cálculo intrincados, las personas pueden verificar estos cálculos controvertidos en la cadena Bitcoin. Esto requiere aprovechar el lenguaje de script de Bitcoin para emular las funcionalidades de máquinas virtuales especializadas como la Máquina Virtual Ethereum (EVM). Aunque este esfuerzo puede implicar importantes esfuerzos de ingeniería, sigue siendo una empresa factible.

Referencias:Una interpretación minimalista de BitVM: Cómo verificar la prueba de fraude en la cadena de BTC (ejecutar el código de operación de EVM u otro VM)

En la solución técnica de la red B^2, una vez que el secuenciador genera un nuevo lote, se transmite al agregador y al Prover. El Prover luego ZK-iza el proceso de verificación de datos del lote, produce un certificado ZK y finalmente lo transfiere al nodo B^2 Hub compatible con EVM. La Prueba ZK es autenticada a través de un contrato de Solidity, con todos los procesos computacionales desglosados en circuitos de compuertas lógicas de nivel bajo intrincados. Estos circuitos están codificados en el lenguaje de script de Bitcoin, formateados y enviados a una plataforma de Disponibilidad de Datos (DA) de terceros con el rendimiento adecuado.

Si las personas cuestionan las trazas de verificación ZK reveladas y sospechan un error en un paso específico, tienen la opción de emitir un "desafío" en la cadena de Bitcoin. Este desafío incita al nodo de Bitcoin a examinar directamente el paso en disputa y aplicar las consecuencias apropiadas si es necesario.

(El diagrama de estructura general de la red B^2, excluyendo los nodos de muestreo de datos)

Entonces, ¿a quién se castiga? En realidad es Committer. En el marco de la Red B^2, el Committer no solo transmite el hash de datos mencionado anteriormente a la cadena de Bitcoin, sino que también divulga el "compromiso" de verificación del certificado ZK a la red principal de Bitcoin. A través de configuraciones específicas de Bitcoin Taproot, las personas conservan la capacidad de plantear consultas e impugnar el "Compromiso de verificación de prueba de ZK" emitido por el Committer en la cadena de Bitcoin en cualquier momento.

Para ampliar el concepto de "compromiso", denota individuos que afirman la precisión de ciertos datos fuera de la cadena y publican una declaración correspondiente en la cadena de bloques. Esta declaración sirve como un "compromiso" donde los valores de promesa están vinculados a datos específicos fuera de la cadena. En la solución B^2, si alguna parte cuestiona el compromiso de verificación ZK emitido por el Comprometido, tienen la opción de desafiarlo.

Uno podría cuestionar por qué B^2 Hub necesita verificar el certificado ZK "repetidamente y de manera exhaustiva" si ya valida el Lote al recibirlo. ¿Por qué no divulgar el proceso de verificación del lote públicamente para desafíos directos en lugar de introducir la prueba ZK? La inclusión de la prueba ZK sirve para condensar las trazas de cálculo en un tamaño más manejable antes de su liberación. Revelar públicamente el proceso de verificación que implica transacciones de Capa 2 y cambios de estado en compuertas lógicas y scripts de Bitcoin resultaría en un tamaño de datos sustancial. La ZKización comprime efectivamente estos datos antes de su difusión.

Aquí hay un resumen conciso del flujo de trabajo de B^2:

1. El secuenciador en B^2 genera nuevos bloques de Capa 2 y consolida múltiples bloques en lotes de datos. Estos lotes se envían al agregador y al nodo Validador en la red B^2 Hub.

2. El agregador envía el lote de datos al nodo Prover, lo que permite la creación de la prueba de conocimiento cero correspondiente. Posteriormente, el certificado ZK se transmite a la red de verificación y DA de B^2 (B^2 Hub).

3. El nodo B^2 Hub verifica si la Prueba ZK del agregador coincide con el Lote del Secuenciador. La correspondencia exitosa indica el paso de verificación. El hash de datos del Lote verificado y el índice de almacenamiento se transmiten a la cadena Bitcoin por un nodo B^2 Hub designado (Committer).

4. Todo el proceso de cálculo para verificar la Prueba de Conocimiento Cero es públicamente divulgado por B^2 Hub, con el Compromiso de este proceso enviado a la cadena de Bitcoin para posibles desafíos. Un desafío exitoso resulta en sanciones económicas para el nodo emisor B^2 Hub (su UTXO en la cadena de Bitcoin se desbloquea y se transfiere al desafiante).

Este enfoque de verificación de estado de la red B^2 integra metodologías ZK y a prueba de fraudes, constituyendo un método híbrido de verificación de estado. Con al menos un nodo honesto bajo la cadena dispuesto a desafiar al detectar un error, se brinda garantía con respecto a la integridad de la transición de estado de la red B^2.

Según las ideas de los miembros de la comunidad occidental de Bitcoin, hay especulaciones sobre una posible futura bifurcación de la red principal de Bitcoin para admitir capacidades computacionales mejoradas. Esto podría allanar el camino para la verificación directa de pruebas ZK en la cadena de Bitcoin, anunciando cambios transformadores para todo el panorama de la Capa 2 de Bitcoin. Sirviendo como una capa de verificación y DA fundamental, B^2 Hub no solo funciona como un componente principal de B^2 Network, sino que también potencia otras capas secundarias de Bitcoin. En el competitivo ámbito de las soluciones de la Capa 2 de Bitcoin, las capas de expansión funcional fuera de la cadena están ganando prominencia, con B^2 Hub y BTCKB representando solo un vistazo de este panorama en evolución.

Descargo de responsabilidad:

1. Este artículo ha sido reproducido de [Geek Web3 ), con el título original "Análisis de la nueva hoja de ruta de la tecnología B^2: la necesidad de DA y la capa de verificación bajo la cadena de Bitcoin." Los derechos de autor son atribuidos al autor original, Faust de Geek Web3. Si hay alguna objeción a la reimpresión, por favor contacta al Equipo de Aprendizaje de Gatepara una resolución rápida siguiendo los procedimientos relevantes.

2. Las perspectivas y opiniones expresadas en este artículo reflejan únicamente los puntos de vista personales del autor y no constituyen asesoramiento de inversión.

3. Las traducciones del artículo a otros idiomas son proporcionadas por el equipo de Gate Learn. Los artículos traducidos no pueden ser copiados, difundidos o plagiados sin mencionar Gate.io.