paint-brush
Cómo desarrollamos el protocolo Exa y la cadena de bloques de Darwinpor@exaprotocol
317 lecturas
317 lecturas

Cómo desarrollamos el protocolo Exa y la cadena de bloques de Darwin

por Exa Protocol7m2023/08/11
Read on Terminal Reader

Demasiado Largo; Para Leer

Esta historia analiza el desarrollo de una red de almacenamiento de archivos descentralizada llamada Protocolo Exa, que utiliza espacio de almacenamiento gratuito en dispositivos móviles. Enfrentamos desafíos con los protocolos de Capa 1 existentes y diseñamos uno nuevo llamado Darwin, utilizando un enfoque de cadena de bloques paralelo. Darwin tiene como objetivo lograr un alto rendimiento y escalabilidad con cadenas secundarias independientes. Se ha creado TestNet, que ofrece un nuevo enfoque para la descentralización, lo que permite a las personas participar en el mantenimiento de la red y servir como infraestructura troncal de Internet.
featured image - Cómo desarrollamos el protocolo Exa y la cadena de bloques de Darwin
Exa Protocol HackerNoon profile picture

Todavía recuerdo el momento en que Google decidió retirar el almacenamiento ilimitado GRATUITO en su aplicación "Google Photos". Para un fotógrafo autoproclamado como yo, fue una noticia terrible y solo indicaba una cosa: comprar la suscripción de Google Storage. Me hizo pensar: “Oh, otra suscripción para vivir en este planeta. ¿No era suficiente suscribirme al gobierno pagándoles parte de mis ganancias? (también conocido como impuestos)”


Momentos como estos hacen que uno se pregunte si hay algo para resolver este problema. Mi cabeza tenía estos pensamientos:


  • “Construyamos un servicio de almacenamiento de fotos gratuito e ilimitado y entreguémoslo a la gente para que la gente lo use, y luego corre a los inversores para que puedas comprar y ejecutar más servidores, y luego, cuando estás teniendo pérdidas, dices: yo construyó un unicornio”: de manera realista, crear un servicio que solicite a los inversores que paguen por el almacenamiento de sus fotos.
  • “¡¿Pero y si cobro por el servicio?!” Luego, el ladrillo de la realidad golpea mi cabeza: "¿Entonces quieres construir otro Dropbox?"
  • Así que no hay servicio SaaSy. ¿Qué otra cosa?

Afortunadamente, una respuesta yacía en el mundo Web3

Un teléfono inteligente de hoy es tan capaz como una PC hace solo dos años (computacionalmente), pero permanece inactivo durante una cantidad considerable de tiempo sin hacer nada, o peor aún, utiliza recursos informáticos mínimos mientras mira TikToks o Reels. ¿Qué pasaría si este teléfono inactivo pudiera usarse para crear una infraestructura de almacenamiento masiva utilizando el espacio de almacenamiento gratuito disponible en los teléfonos?


Las matemáticas aproximadas sugieren que cada año, se agregan alrededor de 80 EXAbytes de almacenamiento a este mundo a través de nuevos dispositivos móviles. El protocolo está aquí para proporcionar algo de ese espacio al público. Por lo tanto, lo llamamos EXA... Protocolo.


Esto es lo que pensamos: “ Creemos un token en Ethereum y establezcamos su valor intrínseco en la cantidad de almacenamiento que las personas comparten en sus teléfonos. Serán compensados con el token nativo cada vez que alguien almacene o recupere archivos de su teléfono”. Con el enfoque móvil primero, las personas que no tienen los medios para aprovechar el poder de la descentralización y la cadena de bloques podrán hacerlo por primera vez. Esto, en un verdadero sentido, será la democratización de la tecnología blockchain.


No negaré que mientras trabajaba en esto, recordé esta cita de Joe Vitale:



“Un gol debería asustarte un poco y emocionarte mucho”.

joe vitale



Ideación

Recuerdo cuando Arpan Garg y yo ( Saurabh Singh ) fuimos a la pizarra muchos meses y aún no sabíamos cómo resolver el problema. La primera versión de la solución fue: "Usaremos Ethereum e implementaremos un contrato inteligente que compensará a los usuarios con nuestro token cada vez que permitan que las personas usen su almacenamiento móvil". y esto estaba plagado de grandes problemas:


  1. Ethereum ofrece un TPS limitado de 12 (antes de la bifurcación PoS). Habríamos ahogado la red Ethereum con solo 10 000 usuarios que, en promedio, realizan transacciones 100 veces al día (una solicitud de archivo podría significar 50 solicitudes debido a la fragmentación, que se describe más adelante). ¡Esto tendrá un efecto en cascada y empujará el precio del gas para ejecutar una transacción por las nubes! – ¡Esto no escalará!

  2. ¿Cómo convencemos a las personas para que guarden sus datos en los teléfonos de otros?

  3. Los teléfonos se encienden y apagan y mueren después de dos años. ¿Cómo asegurarse de que los datos estén seguros incluso cuando el teléfono muere?


Primero, abordamos los problemas 2 y 3:


  1. Permita que los usuarios cifren el archivo antes de que se envíe a otros nodos para su almacenamiento utilizando el cifrado AES 256 que ofrece suficiente seguridad.
  2. Una vez que el archivo está encriptado, podemos compartir el archivo y almacenar las piezas en diferentes dispositivos. Se utilizan varios dispositivos para almacenar el fragmento para redundancia y para el escenario: "¿QUÉ SUCEDE CUANDO UNO DE LOS DISPOSITIVOS SE DESCONECTA, PERDERÉ TODOS MIS DATOS?". Sí, nos hacen esta pregunta mucho...

Fig. 1: el archivo se divide en fragmentos, el cliente lo cifra y vincula, y se guarda en varios nodos de la red. Un fragmento se puede almacenar en varios nodos para redundancia en caso de que un nodo se desconecte


Para ser justos, la solución anterior fue probada y comprobada, y estábamos particularmente tranquilos sobre la solución de este problema. El principal problema estaba en los protocolos de la Capa 1. Eran lentos. Como muy lento. El rendimiento que ofrecían no era suficiente para sostener ni siquiera a 1000 usuarios en nuestra red de almacenamiento. Como se describió anteriormente, habríamos ahogado la red fácilmente. Los L2 tampoco ofrecían esperanza.


Por lo tanto, decidimos diseñar una nueva Capa 1 que escala y se ejecuta en dispositivos móviles de forma nativa. Estamos llamando a nuestro L1 - Darwin.

Solución

Una buena mañana, Arpan y yo estábamos sentados en la oficina discutiendo, discutiendo sobre la nueva arquitectura Blockchain . Nos hicimos esta pregunta: “¿ Qué pasaría si en lugar de 1 cadena de bloques, hubiera varias cadenas de bloques ejecutándose en paralelo?


Suena bien, pero ¿cómo lo gobernarías?


Al igual que gobernamos países, estados y ciudades permitiéndoles trabajar de forma independiente.


Pensémoslo bien; cuando había unos pocos humanos en este planeta, el mundo entero era un gran país para ellos ”.


Correcto.


Y cuando hubo más humanos, dividieron la tierra y crearon países separados.


Cierto.


“¿ Qué tal si hacemos lo mismo con los nodos móviles?


Podemos intentar…


¡Y lo intentamos! Pasamos toda la semana en la pizarra diseñando el L1 con analogías del mundo real. Nuestra pizarra solía verse así, resolviendo y puliendo los detalles de la arquitectura:


Fig. 2: Desde los patrones de los árboles en la pizarra hasta la creación de Darwin.


Un mes y medio después, finalizamos la arquitectura y la llamamos Darwin.


Darwin ha sido diseñado tal como las civilizaciones han evolucionado con el tiempo y han creado ciudades, estados y naciones tal como las conocemos. En lugar de ver todos los nodos como parte de una cadena de bloques completa, Darwin los segmenta en varias cadenas para lograr una mejor gobernanza y mejorar el rendimiento de la red.

Fig. 3: Para los primeros humanos, la tierra completa podía verse como una nación completa. A medida que aparecen más humanos, las tierras se segregan en secciones más pequeñas llamadas países con su propio gobierno.


Las civilizaciones evolucionan y crean grupos como ciudades; Darwin también evoluciona a medida que se agregan más nodos a la red. La evolución de Darwin Chain la divide en varias Child Chains para agrupar los nodos que están cerca y mejorar el rendimiento de la red.


Las civilizaciones también tienen un sólido sistema de gobierno que les permite funcionar correctamente. Darwin aporta gobernanza mediante el uso de nodos de servidor que auditan las cadenas secundarias con regularidad.

¿Cómo funciona Darwin?

Darwin Chain evoluciona continuamente para aumentar el TPS a medida que crece la red y también fragmenta y optimiza la cadena dinámicamente para crear cadenas secundarias paralelas que funcionan de forma independiente y tienen su propio conjunto de nodos completos para validar las transacciones. Estos nodos forman cadenas de nodos que pueden realizar transacciones entre sí con baja latencia, y luego cada cadena se divide en diferentes cadenas cuando coincide con algunas condiciones, lo que se denomina mutación.

Fig. 4: Representación de la mutación en la Cadena de Darwin a medida que aumenta el número de nodos completos y realizan transacciones entre ellos. El Fossil Block que se muestra aquí es el bloque de génesis de cada child chain.


Cuando una cadena muta, cada cadena secundaria crece de forma independiente y tiene sus propios nodos independientes para validar las transacciones. Los nodos se distribuyen entre cadenas secundarias mediante el uso de un algoritmo para reducir la latencia de comunicación y transacción en cada cadena secundaria. Esto aumenta exponencialmente el rendimiento de la cadena, ya que cada cadena secundaria funciona de forma independiente para crear y validar transacciones.


Los recursos están disponibles más rápido ya que los nodos se agrupan en función de la proximidad más cercana, tal como funciona en el caso de las aplicaciones Web2 alojadas en un servidor más cercano al área que tiene el tráfico máximo hacia los servidores. La cadena Darwin también utiliza factores que incluyen la potencia informática, el espacio de almacenamiento compartido y la disponibilidad/reputación de la red de un nodo al crear cadenas secundarias.


La creación de Darwin resolvió el mayor cuello de botella para nosotros: un L1 que puede admitir una infraestructura de almacenamiento descentralizada y ejecutarse de forma nativa en dispositivos móviles.

Rendimiento Darwin (máx. teórico): ~ 7,8 millones de TPS.


Todo esto se ha establecido formalmente en nuestro Libro Amarillo, que está disponible en nuestro sitio web .

Pero, ¿funciona?

Fig. 5: Captura de pantalla del explorador de cadenas de Darwin. Cada línea del árbol es una cadena de bloques que funciona de forma independiente.


¡Sí, lo hace!


Recientemente construimos una TestNet al convertir nuestra teoría en código real. En la captura de pantalla anterior, puede ver cómo se ve visualmente la cadena de bloques de Darwin. La estructura de árbol contiene cada cadena de bloques independiente.

Próximos pasos

Darwin es solo una capa 1 en este momento que puede realizar transacciones con nuestro token nativo. Nuestro próximo paso es integrar la lógica DFS (Sistema de archivos distribuidos) que cumplirá con nuestro objetivo de una infraestructura de almacenamiento verdaderamente descentralizada utilizando dispositivos móviles.


En cuanto a la escalabilidad de la cadena, permitir la implementación de contratos inteligentes mediante la creación de una VM compatible con EVM podría ser el siguiente paso después de integrar DFS.


Para algunos, puede ser solo otra cadena de bloques; para nosotros, vemos un nuevo enfoque hacia la descentralización. Cuando Satoshi escribió el Bitcoin Paper, imaginó un mundo en el que personas como tú y como yo pudiéramos participar en la red y mantenerla. Ha pasado más de una década y parece que el poder de mantener la red está en manos de unos pocos (me refiero a granjas mineras ultragrandes).


Con Darwin, tenemos la intención de dar a las personas (no a las corporaciones, no a unos pocos ricos) la custodia del sistema descentralizado que permite la transferencia de criptoactivos y servirá como una infraestructura troncal de Internet.


¿Participarás en este viaje con nosotros?


El día que Arpan (izquierda) y yo finalizamos la arquitectura de Darwin.


También publicado aquí .