Me senté con Mahnush, quien durante mucho tiempo ha sido parte del equipo de DFINITY, para discutir las diversas innovaciones que lanzará DFINITY. Los temas cubren términos como firmas de umbral, balizas aleatorias y generación de claves distribuidas. No sólo discutimos estos conceptos, sino también por qué son tan importantes.

Hola y bienvenidos a otro episodio de Inside DFINITY. Hoy voy a hablar con Mahnush, quien se unió a nosotros desde muy temprano como investigador. Ella es de Yale y hoy veremos lo que hace en DFINITY, lo que ha hecho antes y luego también nos dará algunas ideas sobre algunas de las tecnologías e innovaciones que DFINITY ha desarrollado.

Gracias, te uniste a DFINITY desde muy temprano. Usted ha sido una parte clave de nuestro equipo de investigación desde nuestros inicios. Tal vez para las personas que aún no han oído hablar de ti, "¿Qué estás haciendo aquí?"

Soy investigador y lo que hago es ayudar y diseñar la capa de consenso y probar la seguridad de la capa de consenso y las balizas aleatorias.

Mi trabajo diario es recopilar ideas del equipo, hacerlas más formales para que podamos entenderlas entre nosotros y escribirlas formalmente, y luego me gusta demostrar que son seguras para que podamos usarlas.

Creo que una buena manera en que me describiste ayer es: "Tomo todo lo que proponemos y me aseguro de que sea seguro". Certifico que es seguro, por lo que estamos tratando de construir con DFINITY. Algo que creo que es un atributo muy importante.

¿Qué te llevó a este puesto? ¿Qué hiciste antes? ¿De dónde eres?

Antes de unirme a DFINITY, realicé un postdoctorado en la Universidad de Yale. Antes de eso, era estudiante de doctorado. Para mi doctorado, trabajé en seguridad, como la computación multipartita.

Computación multipartita segura

En la computación multipartita segura es necesario garantizar que todas las partes lleguen a un acuerdo. Una parte importante de la informática es el resultado, en el que todos deberían estar de acuerdo. Por lo tanto, el consenso y el acuerdo bizantino son partes importantes del protocolo MPC. Por eso me interesan los protocolos de consenso.

Luego, mientras estaba en Yale, traté de construir un protocolo de consenso que llegara a millones de partidos utilizando un protocolo basado en comités. Luego conocí a Timo y Dominic y supe que DFINITY estaba intentando hacer lo mismo, lo cual fue interesante para mí.

Es genial tenerte. Sé que hemos progresado mucho desde que se unió, incluido el documento técnico que publicamos a principios de este año, y sé que pasó muchas noches sin dormir trabajando en él.

computación en la nube

¿Qué acertijo o alguna pregunta interesante estamos tratando de resolver aquí? Creo que lo que estamos tratando de hacer en DFINITY es una nueva versión de la computación en la nube, que si lo piensas bien, es en realidad un replicador del estado.

Porque debes tener muchas réplicas para asegurarte de no perder cálculos o datos, pero todas deben tener un acuerdo. Porque si algunos de ellos piensan que algo es definitivo y otras copias piensan que algo más es definitivo, entonces los usuarios no sabrán qué versión es correcta.

Por lo tanto, garantizar que todas estas copias sean consistentes es una parte muy importante de DFINITY. Por eso los protocolos de consenso suelen ser muy importantes para DFINITY.

Ahora, si todas las réplicas son honestas, entonces esto es mucho más fácil porque podemos asegurarnos de que, por ejemplo, si en Google Cloud tienes varias réplicas y estás seguro de que todas las réplicas están controladas por Google, entonces... correcto, Como todos están controlados por Google, puedes estar seguro de que cada computadora puede aplicar el mismo algoritmo.

Eso es lo que estás diciendo: "¡Todos son honestos!". Sí, es mucho más fácil para ellos ya que todos pertenecen a un grupo central, pero al mismo tiempo debes confiar en Google para garantizar el algoritmo. correr es honesto.

réplica

Sin embargo, en DFINITY queremos asegurarnos de que todas las personas en el mundo puedan tener una copia, en lugar de asumir que todas las copias son propiedad de DFINITY. Por tanto, es como un enfoque más abierto a la computación en la nube.

Los usuarios no necesitan confiar en DFINITY, pero pueden confiar en los protocolos que ejecuta DFINITY. En algún momento, también será de código abierto, ¿verdad? ¿Qué significa que todos puedan ver el código y todos puedan tener una copia?

Básicamente, esto significa que todos pueden convertirse en mineros en nuestro sistema, mientras que DFINITY aún necesita mineros. Aunque no resolverán el rompecabezas de la prueba de trabajo, constituyen la potencia informática distribuida en DFINITY.

Están ayudando con los cálculos, están ayudando con el mantenimiento de los datos y están ayudando con el mantenimiento de los cálculos sobre los datos.

Protocolo práctico de tolerancia a fallas bizantinas

Si las réplicas son diferentes, como computadoras en diferentes dominios, algunas de ellas pueden estar dañadas o ser conflictivas. En informática lo llamamos bizantino porque proviene del problema de los generales bizantinos.

Bueno, resolver este problema es un problema muy difícil que ha persistido en la informática durante los últimos 40 años. Y todo el mundo está intentando mejorar la solución porque es un problema muy básico.

Si resuelves ese problema de manera efectiva, resolverás muchos problemas además. Ahora, diferentes intentos son nuevas formas de resolver el problema.

Entonces, cuando dices que el problema ha estado ahí durante mucho tiempo, una solución, en mi opinión, es si tengo tres copias independientes, dos que digan una cosa y la tercera que diga otra cosa, siempre creo en la mayoría. ¿Qué está pasando realmente en la red en este momento? ¿Hasta qué punto es completamente diferente?

Esta es la primera respuesta que han encontrado los científicos en informática: si tienes varias copias, digamos tres copias, entonces no puedes obtener una mayoría. Entonces, después de tener una mayoría, todos deben enviar sus comentarios a todos y es como un circuito con una gran profundidad de comunicación.

Aún así, porque si estás de acuerdo con un solo punto similar, la mayoría puede funcionar. Pero si estamos de acuerdo como una cuerda, incluso los grupos honestos pueden no estar de acuerdo. Por tanto, una de las soluciones para utilizar el protocolo PBFT es elegir un líder.

Protocolo PBFT (tolerancia a fallos bizantinos)

¿Qué significa PBFT? Es como la Tolerancia a Fallos Bizantinos (BFT), lo llaman el "lado malo" o "lado bizantino", y la P en PBFT proviene de la practicidad.

En este protocolo, los servidores réplica eligen un líder, así que, al igual que en el mundo real, si quieres llegar a un acuerdo, la mejor manera es elegir un líder, y luego el líder dice qué hacer a continuación. Todos lo hacen. lo mismo y llegan a un acuerdo.

Entonces, de manera similar al protocolo PBFT, eligen un líder y, si el líder es honesto, ofrecerá el mismo valor a todos en la red antes de que puedan llegar a un acuerdo.

Pero el problema es que si el líder no es honesto, entonces no pueden llegar a un consenso y el líder debe ser reemplazado. Comprobar que el líder es honesto y ofrece el mismo valor a todos y es un trato muy costoso sin cambiar de líder (lo llaman cambio de perspectiva) por lo que requiere comunicación en todos los ámbitos, lo cual es muy costoso.

Protocolo de cadena de bloques

Luego aparecen los protocolos blockchain como Bitcoin y deciden no cambiar al líder mientras sea deshonesto, y deciden, bueno, no, en realidad necesitamos cambiar al líder solo si el líder es deshonesto. Asumimos que el protocolo es sincrónico, por lo que cambiamos de líder en cada nueva época, en cada nueva ronda.

Luego necesitan una forma de elegir un líder, porque hay que elegir al líder, y luego al siguiente líder, y al siguiente líder.

No es necesario seguir comprobando si el líder es honesto, simplemente sigue construyendo sobre el protocolo, sobre los registros. Hay muchas posibilidades de que uno de estos líderes llegue a un acuerdo honesto y saludable. El problema ahora se reduce a seleccionar un líder que requiere números aleatorios.

Porque si tienes un número aleatorio, como un dado, entonces puedes usarlo para elegir un líder, y ahí es donde ayuda la Prueba de trabajo (POW).

prueba de trabajo

En esencia, los protocolos blockchain son protocolos bizantinos porque esencialmente utilizan prueba de trabajo para seleccionar líderes. Con solo ejecutar la prueba de trabajo, la primera persona que encuentra una solución de prueba de trabajo es el líder, lo cual es un proceso aleatorio.

Entonces, cuando hablo con padres u otras personas interesadas en blockchain, y hago esto con frecuencia, les pregunto: ¿Cómo se selecciona al azar a una de las personas en esta sala, digamos que hay 10 personas en la sala?

Primero, todo el mundo piensa que es fácil, como si simplemente estuviéramos tirando los dados. Creo. Entonces, ¿quién tira los dados? Dicen que simplemente sumamos todas las fechas de nacimiento, empezando por ti, y luego circulamos hasta llegar a ese número. Pero entonces, ¿cómo eliges con quién empezar?

Entonces esto parece una pregunta muy simple. Pero si realmente quieres que sea aleatorio, es difícil. Esa fue la gran innovación de Bitcoin: encontrar una manera de acordar básicamente elecciones aleatorias entre pares.

Básicamente, utilizar prueba de trabajo para crear aleatoriedad es una forma muy costosa de crear aleatoriedad porque hay que consumir mucha electricidad.

Entonces, para los esfuerzos actuales como Bitcoin, es como una nación poderosa que arde por resolver la prueba de trabajo, razón por la cual es intrínsecamente muy costoso.

En realidad, no usamos mucho Bitcoin, y si quisieras escalar usando Bitcoin para una gran cantidad de computación, tendrías que quemar todo el mundo. Si comparamos dónde está Bitcoin ahora y hacia dónde tiene que ir para lograr la visión, todavía tendrás que usar Bitcoin diez o cien veces.

Has mencionado que básicamente consume mucha energía. Por lo tanto, buscamos un método más eficiente para la selección de líderes para seleccionar personas aleatorias entre sus pares.

Prueba de trabajo como protocolo de sincronización

Otra razón por la que estamos tratando de cambiar la forma en que Bitcoin crea aleatoriedad es porque la prueba de trabajo es inherentemente un protocolo sincrónico, por lo que esencialmente el tiempo que tienes que dedicar a hacer la prueba de trabajo es un orden de magnitud mayor que la latencia de la red.

De lo contrario, no se sabe si las personas prefieren quemar electricidad para resolver la prueba de trabajo o dedicar tiempo a resolver la prueba de trabajo, o si su información se pierde en la red.

Esencialmente, las cadenas de prueba de trabajo o el consenso de prueba de trabajo tienen un rendimiento bajo y no se pueden realizar tics rápidamente porque esencialmente hay que esperar más que la latencia de la red para que se cree la siguiente pieza de aleatoriedad.

Es por eso que no se puede tener un protocolo de alto rendimiento además de esto, y es por eso que las transacciones también se vuelven muy costosas, porque solo un número limitado de transacciones pueden caber en cada bloque. No podemos aumentar el número de bloques por unidad de tiempo sin estropear el protocolo.

Cómo DFINITY crea números aleatorios

DFINITY está tratando de resolver este problema, por lo que el primer pensamiento es: ahora necesitamos una nueva forma de crear aleatoriedad, pero ahora, ¿cómo creamos aleatoriedad?

Como dije, esta es una pregunta muy difícil. Entonces, un enfoque es hacer que una persona cree la aleatoriedad, pero si esa persona es deshonesta, no puede sesgar la aleatoriedad.

Ahora necesitamos un grupo para crear la aleatoriedad, pero si elegimos un grupo, entonces si yo soy la primera persona en crear la aleatoriedad y tú eres la segunda persona, entonces la última persona puede mirar nuestro número aleatorio y elegir el suyo. aleatoriedad, el resultado es lo que quiere, lo llamamos sesgo del último hombre.

No podemos tener un grupo donde la última persona elija la aleatoriedad, por eso utilizamos criptografía de umbral.

criptografía de umbral

Lo que significa la criptografía de umbral es que en lugar de tener un grupo de n personas, pero todas las n personas necesitan crear aleatoriedad, hay un grupo de n personas, pero solo K de ellas necesitan participar.

Si está esperando a K personas, si recibe información de K menos 1 participante, está esperando una entrada. Pero cualquier otra parte con n menos K puede ser la última persona. Por lo tanto, no existe un sesgo de última persona.

Si la última persona decide "no quiero participar", entonces hay otra fiesta, pero eso no es suficiente. Porque ahora si los miembros de este grupo de K personas generan aleatoriedad, y el comportamiento de otro grupo de K personas genera aleatoriedad, si estas dos aleatoriedades son diferentes, el adversario (al determinar si quiero participar en este grupo) puede sesgar el protocolo. Por eso necesitamos singularidad.

unicidad

La unicidad de la aleatoriedad significa que no importa qué partido K participe en la creación de la aleatoriedad, el resultado siempre es único y el resultado es siempre el mismo. En primer lugar, ésta es una propiedad increíble. Por muy contradictorio que parezca, "¿Cómo llegamos allí?"

Si tiene un mensaje y utiliza firmas BLS para la firma del umbral, entonces necesita K participantes. Si el umbral es K, necesita que K participantes lo firmen, sin importar quiénes firmen los k participantes, obtendrá un resultado de identidad único. Este es un atributo clave de las firmas BLS.

Esta es una tecnología de cifrado basada en emparejamiento. Así que es nuevo, pero no demasiado nuevo, porque si el esquema es demasiado nuevo, uno se preocupa por la seguridad y por si se ha demostrado correctamente. Si suficientes personas lo revisan, dejen comentarios y pruébenlo.

En Stanford, suficiente gente lo miró y el grupo trabajó durante mucho tiempo para asegurarse de que fuera seguro y que fuera un protocolo muy seguro con buenas implementaciones. Entonces tenemos una implementación BLS muy rápida que es de código abierto y todos pueden usarla.

Tal vez, simplemente brinde una descripción general y luego también podremos hablar sobre balizas aleatorias y qué son exactamente. Pero usted mencionó eso y creo que es una buena explicación de por dónde empezar y dónde la prueba de trabajo no va más allá de cierto punto en términos de rendimiento y uso de energía.

Luego, el problema de utilizar el sesgo de la última persona para crear este número aleatorio lo resolvemos mediante k a partir de las firmas umbral de n personas. Y la firma BLS que utilizamos es exclusiva de k personas entre n personas y sigue siendo aleatoria. Estas son dos propiedades que todavía me cuesta ver siempre cómo encajan entre sí.

¿Entonces, qué debemos hacer? Volvamos a las cadenas de bloques de Satoshi Nakamoto y veamos cómo funcionan. Entonces, la cadena de bloques de Nakamoto es como crear completamente aleatoriedad para cada bloque, lo que significa que para cada bloque resuelves la prueba de trabajo desde el principio y no reutilizas nada de la aleatoriedad allí.

Ésa es una de las razones por las que es tan caro. Así que no queremos hacer eso aquí porque sabemos que el cifrado de umbral es muy costoso, al igual que en el mundo de la prueba de trabajo. No es tan caro, pero sigue siendo una operación muy cara.

Queremos asegurarnos de que la mayoría de las operaciones costosas se puedan realizar fuera de línea y luego, cuando estamos en línea, hacemos muy pocas de ellas. Si nos fijamos en el esquema de firma, hay diferentes métodos que deben abordarse y deben funcionar. Uno de ellos es la creación de claves, lo llamamos Generación de claves distribuidas (DKG).

DKG (Generación de claves distribuidas)

DKG (Generación de claves distribuidas) es una operación muy costosa porque todos deben ponerse de acuerdo sobre la clave pública que desean firmar, y todos generan una clave para ellos mismos que es parte de una clave más grande para el grupo para que puedan usarla para firmar. aporte.

Todo el proceso es un proceso costoso, es necesario utilizar una clave para autenticarse, por lo que es un proceso costoso. Solo para una discusión rápida, creo que este también es un tema interesante, básicamente significa que todos estamos afuera, todos estamos hablando entre nosotros, pero todos hemos acordado una clave no pública.

Es sorprendente que podamos hablar de esto... pero también significa que ambos creamos correctamente la clave privada para usarla con esa clave pública, y aunque no mencionamos nuestra clave privada a nadie más, todos nuestros Las claves también funcionan juntas de alguna manera.

Lo bueno es que puede ejecutar el proceso DKG una vez y luego firmar varias veces con la misma clave, lo que significa que debe amortizar el costo del costoso DKG varias veces. Podrías hacer una ronda y ejecutar DKG en un grupo y luego, una vez que tengan su propia clave, pueden usarla para firmar diferentes entradas.

Cada vez que vuelven a firmar, obtienen un nuevo número aleatorio, es un nuevo número pseudoaleatorio, en realidad ya no es un número aleatorio porque el primero era aleatorio, pero después es una función pseudoaleatoria. Actúa como un número pseudoaleatorio para usted.

Luego, de esta manera, podemos hacer que el esquema de firma no sea interactivo, lo que significa "No necesito hablar contigo para firmar".

Yo hago lo mejor que puedo, yo firmo, usted hace su parte, usted firma, pero podemos juntar esas firmas y fusionarlas y obtener una firma fusionada sin tener que hablar entre nosotros.

Esto es lo que llaman no interactivo. Esta es una buena propiedad ya que hace que el esquema de firma sea mucho más rápido que la versión no interactiva.

La forma en que funciona DFINITY es que creamos el grupo, luego hacemos el DKG, ahora firmamos la primera aleatoriedad, luego obtenemos una aleatoriedad para esta ronda, luego en la siguiente ronda firmamos la aleatoriedad anterior para la siguiente ronda. Crea una nueva ronda. de aleatoriedad y luego, se procede a la firma.

¿Cuánto tiempo queremos reutilizar la misma aleatoriedad original? Puedes reutilizarlo durante mucho tiempo, puedes reutilizarlo durante unos meses, o tal vez alrededor de un mes o dos meses. Por lo tanto, se puede reutilizar la misma aleatoriedad siempre que haya suficientes participantes en el grupo que sigan siendo activos y honestos. También mencionaste grupos.

¿Existen diferentes grupos sobre cómo opera DFINITY? Tenemos esta criptografía de umbral, tenemos el proceso DKG, pero si desea ejecutar este proceso en una gran cantidad de participantes, como 5 millones de Bitcoins, es un proceso muy costoso porque debe enviar un mensaje a todos, cada uno debe firmar. .

Este sigue siendo un proceso muy costoso. Analizamos el sistema y descubrimos que no se necesita la firma de todos, no se necesita la participación de todos en la aleatoriedad. Puede participar en la aleatoriedad seleccionando los partidos al azar, como si se celebraran elecciones en un país.

Entonces, si quieres decidir algo que no requiera que todos presenten una ley o tomen una decisión, puedes tener un comité, puedes tener representantes en lugar de todos, deberíamos elegir un grupo, pero ¿cómo elegimos un grupo? ¿grupo?

Aún así, podemos reutilizar nuestra propia aleatoriedad, de modo que dado que un grupo se elige al azar, ese grupo tiene propiedades similares al número cuadrado total real. En lugar de ejecutar el protocolo completo entre 5 millones de personas, puedes ejecutar el protocolo entre 500 personas y es diez veces más rápido.

Ya sea que haya 100.000 personas participando en toda la red o 100 millones de personas participando, el proceso por el que pasa el grupo es siempre similar porque el tamaño del grupo es constante. Otro beneficio de elegir grupos es que no solo se obtiene escalabilidad sino también paralelismo porque ahora podemos tener múltiples cadenas en lugar de una sola.

Fragmentación

Cada grupo es responsable de una cadena, luego puedes crear múltiples cadenas en paralelo, lo que generalmente llamamos fragmentos en una cadena de bloques. Esta es una forma natural de fragmentar.

Por eso creo que DFINITY tiene una excelente manera de fragmentar que es inherente a DFINITY porque tenemos grupos y luego cada grupo puede tener su propio fragmento. Entonces, ¿cuáles son los problemas más importantes a los que nos enfrentamos en este momento?

Actualmente, tenemos pruebas completas en la configuración de sincronización. En el modelo de computación síncrona o comunicación síncrona, cuando una parte honesta envía un mensaje, será recibido por todas las partes honestas dentro del rango Delta.

Por ejemplo, en Bitcoin, cuando una parte honesta envía un mensaje, se recibirá en aproximadamente un minuto, que es menos de un minuto para todas las personas en el mundo. El protocolo lo sabe y lo utiliza.

Entonces, en Bitcoin, la duración de la prueba de trabajo depende de la latencia de la red y debería ser mucho más larga, alrededor de 10 minutos para Bitcoin, porque creen que Bitcoin es 10 veces más larga.

La suposición de sincronización es válida, pero el problema es que si la suposición de sincronización es incorrecta en una red real, el protocolo ya no es seguro.

Pruebas completas en redes asíncronas.

Lo que hemos hecho en DFINITY es que tenemos pruebas de seguridad en un modelo totalmente sincrónico y estamos actualizando nuestras pruebas para que también sean utilizables en redes asincrónicas.

Esa es una de las áreas en las que estoy trabajando ahora y la otra área en la que estoy trabajando es el proceso DKG interactivo que estamos llevando a cabo ahora mismo en el proceso DKG, lo que significa que cada participante que quiera participar en la actividad ejecuta el DKG. Debería ser posible utilizar DKG al realizar el acuerdo.

DKG (generación de claves distribuidas) no interactiva

Queremos que sea no interactivo, lo que significa que las partes pueden participar y regresar cuando se complete el acuerdo. Entonces es como una forma más natural de ejecutarlo, DKG es la versión no interactiva en lugar de la versión interactiva.

La tercera cosa en la que estoy trabajando es la parte de fragmentación, de la que acabo de hablar. Estamos diseñando un sistema de fragmentación para DFINITY. Hemos diseñado un sistema de fragmentación para una red similar a Bitcoin y utilizamos el mismo concepto y nuestro artículo se publicará en CCS. Este es un buen artículo, así que deberías leerlo.

Tal vez simplemente para abordar la pregunta: "¿Cuáles son los requisitos para DFINITY? ¿Cuántas personas pueden ser deshonestas y la red aún sobrevivir?". Esa es una buena pregunta.

Normalmente, si trabaja en un entorno asíncrono o semisincrónico, el número de partes que un protocolo puede tolerar es un tercio. Por lo tanto, la fracción de partes deshonestas es siempre un tercio en el modelo asincrónico, que es el límite inferior, por lo que no puede tolerar nada superior a eso.

El sistema de fragmentación de DFINTY

DFINITY está trabajando en este modelo, lo que significa que la proporción de partes deshonestas en toda la red debería ser de un tercio, pero en cada grupo solo podemos tolerar la mitad de la proporción, por lo que pasamos de un tercio a la mitad. "¿Sabemos ya qué tan grandes van a ser estos grupos?"

El tamaño del grupo depende del nivel de seguridad que desee alcanzar, cuanto más grande sea el grupo, mejor seguridad obtendrá. Actualmente, para un nivel de seguridad de alrededor de 86-90, un tamaño establecido de 400 a 800 parece lógico, lo que significa que la probabilidad de error sería de alrededor de 86. Nunca pierdes tus tokens.

Bloquear el tiempo y la finalidad

Otra pregunta antes de terminar es que hablamos sobre eficiencia energética y mencionamos algunos de los tiempos de bloqueo para la cadena de bloques de Bitcoin, que usted mencionó que son aproximadamente diez minutos. Entonces, ¿cuál es el tiempo de bloqueo que logramos en DFINITY?

Actualmente, en nuestra red de prueba, los tiempos de bloqueo rondan un segundo, menos de un segundo.

Otra diferencia entre DFINITY y Bitcoin es que para llegar a la finalidad con Bitcoin, dado que no tienen un protocolo de consenso real, es necesario esperar seis bloques. Para DFINITY, necesitamos dos bloques.

Eso significa 2 segundos, 1 segundo por bloque, 2 segundos de finalidad, lo que significa que tenemos 2 segundos de finalidad, mientras que la finalidad de Bitcoin es aproximadamente 1 hora.

Básicamente, esto es lo que sucede en DFINITY con Bitcoin para habilitar una transacción similar a una tarjeta de crédito y completar la transacción, si voy a una cafetería a comprar un café, en el peor de los casos tengo que esperar una hora antes de poder usarlo. mi bitcóin. Asegúrese de que la transacción realmente se realice, lo que puede demorar hasta dos segundos en DFINITY.

En el mejor de los casos, si el creador del bloque es optimista y honesto, solo tiene que esperar dos segundos para alcanzar el estado final en DFINITY, entonces esto es como un sistema de alto rendimiento.

Gracias a Mahnush por tomarse el tiempo de explicarnos algunos de los desafíos e innovaciones de DFINITY.

Contenido IC que te interesa

Progreso tecnológico | Información del proyecto | Eventos globales

Recopila y sigue el canal IC Binance

Manténgase actualizado con la información más reciente