“Tardigrade: la pieza que faltaba en el rompecabezas para almacenar datos en la blockchain”
Entrevistados: Kevin Leffew, Desarrollo de negocios de Storj (KL), Dave Hodgson, NEM Group CIO (DH), Bader Youssef, IoDLT CTO (BY)
Comencemos con algunas presentaciones. Me gustaría comenzar contigo, Kevin, ¿podrías darnos una breve introducción de Storj?
KL:
Mi nombre es Kevin Leffew y dirijo el desarrollo de negocios aquí en Storj Labs. Lideró nuestro ecosistema de socios de código abierto, además de trabajar con socios y arquitectos que construyen soluciones que aprovechan la nube descentralizada de una manera más eficiente, económica, segura y confiable además de ser más resistente que las opciones centralizadas. Trabajo en estrecha colaboración con socios y clientes que se basan en Tardigrade para mejorar sus aplicaciones.
BY:
Mi nombre es Bader Yousef, soy el CTO de IoDLT. Somos una empresa que se enfoca principalmente en aplicaciones de IoT y blockchain, específicamente usamos blockchain e intentamos no usar ninguna otra tecnología arcaica en este momento. Hacemos todo tipo de integraciones, desde IoT hasta agregación de datos.
DH:
Soy Dave Hodgson, actualmente director de inversiones y director de asociaciones estratégicas de NEM Group. También dirijo NEM ventures como Director General. Por lo que podemos decir que NEM Group es la encargada de ayudar a coordinar todas las diferentes subsidiarias como NEM trading, NEM Ventures, NEM Software, para así garantizar que todos estemos dirigiéndonos como organización en la misma dirección. Todo lo anterior bajo el proyecto NEM, que obviamente es una cadena de bloques que ha existido durante los últimos 5,5 a 6 años, y la cual prepara el lanzamiento de Symbol en los próximos 3 meses.
Así que vayamos al tema que nos ocupa … ¿cómo surgió la conversación inicial para esta colaboración, de dónde surgió la idea? ¿Puedo empezar contigo Dave?
DH:
Kevin y yo nos reunimos en enero / febrero de 2020 en un evento y discutimos que, en esa etapa Storj estaba considerando lanzar Tardigrade y que se lanzaría dentro de unos meses. Discutimos varias formas en las que podríamos colaborar como dos proyectos que se lanzarán este año y que estaban a la vanguardia de la tecnología.
Me gusta particularmente la forma en que Storj opera de la misma manera que lo hace una nube centralizada pero con una naturaleza descentralizada, lo que significa que si alguien quiere usar la solución, entonces es muy fácil cambiar porque todas las llamadas a la API, etcétera, son muy similares. A partir de ahí, Tardigrade comenzó a anunciar varias asociaciones y, obviamente, Kevin fue fundamental en una de ellas, que fue MongoDB Connector. Así que tuve una charla con IoDLT porque sabía que IODLT estaba trabajando en varias implementaciones de cadenas privadas de AXON y buscaba formas de agilizar la propagación de nodos a través de esas redes privadas.
… Sabía que IODLT estaba trabajando en varias implementaciones de cadenas privadas de AXON y buscaba formas de optimizar la propagación de nodos a través de esas redes privadas.
Obviamente, NEM, Symbol utiliza MongoDB como una solución de tipo caché de solo lectura para que los nodos de la API puedan consultar datos de la cadena sin llegar a los nodos principales. Ese parecía un lugar lógico para comenzar la conversación, y Bader y Kevin básicamente lo siguieron desde allí. Esencialmente, conecté todas las partes y luego vi cómo sucedía todo, pero los muchachos definitivamente hicieron el trabajo pesado y realmente hicieron que todo saliera bien.
Desde tu perspectiva, Kevin, ¿fue así como se desarrolló?
KL:
Sí, lo diría de la misma forma. Todo comenzó en una conferencia. Estábamos hablando de nuestro conector MongoDB y considero que NEM utiliza MongoDB de una manera realmente innovadora, como describió Dave, como un caché de sólo lectura. Así que hubo muchos beneficios al aumentar los tiempos de consulta sin tener que consultar un nodo completo con lo cual podría correr el riesgo de sobrecargarme con solicitudes. El conector es una excelente manera de equilibrar la carga de los datos de blockchain y hacerlos fácilmente accesibles.
El conector es una excelente manera de equilibrar la carga de los datos de blockchain y hacerlos fácilmente accesibles.
Eso hizo que las ruedas giraran y, dado el trabajo que hemos hecho públicamente con MongoDB, pensé que sería un gran caso de uso para explorar más a fondo.
Excelente. Bader, ¿cuáles eran los problemas que buscaba tratar de resolver a través de esta colaboración? y ¿ Qué había detectado que necesitaba solucionarse?
BY:
Naturalmente, al trabajar con Symbol todos los días, comienzo a darme cuenta de algunos de los puntos débiles de la tecnología . Y uno de ellos era que cada vez que tenía que reiniciar un nodo por cualquier motivo (hay algunas razones por las que querría reiniciar un nodo), tendría que esperar a que este se sincronizará con la red. Lo que a su vez esencialmente evitaría que su aplicación funcione de la manera que se supone que debe hacerlo, porque no puede obtener los datos que necesita con la rapidez que se requiere. Entonces, esto fue lo siguiente que considere : “Oye, ¿Qué pasaría si en lugar de simplemente sentarnos allí y esperar a que los datos de la cadena se sincronicen, pudiéramos simplemente tomar un archivo de algún lugar y tenerlo todo disponible?, al menos para que podamos mantener la aplicación en funcionamiento mientras la cadena se sincroniza y verifica en segundo plano ” y ahí es donde realmente comenzó todo para mí.
“Oye, ¿qué pasaría si en lugar de quedarnos sentados y esperar a que los datos de la cadena se sincronicen, pudiéramos simplemente tomar un archivo de algún lugar y tenerlo todo disponible? , al menos para poder mantener la aplicación en funcionamiento mientras la cadena se sincroniza y verifica en segundo plano”.
Entonces, Dave, en términos de incorporación de personas de la comunidad, ¿Qué representa el conector para las personas que intentan trabajar con Symbol?
DH:
Yo diría que es básicamente un primer paso para que un nodo completo se almacene en soluciones como Tardigrade. Para ayudar a simplificar el tiempo que lleva construir un nuevo nodo o, como dice Bader, reconstruir uno antiguo.
Yo diría que es básicamente un primer paso para que un nodo completo se almacene en soluciones como Tardigrade. Para ayudar a optimizar el tiempo que lleva construir un nuevo nodo o, como dice Bader, reconstruir uno antiguo, especialmente para las soluciones de cadenas privadas como las que implementa IoDLT, es posible que necesiten construir una gran cantidad de nodos. digamos para un proyecto de ciudad inteligente, y el dispositivo AXON es un muy buen uso del nodo de cadena privada para eso porque usa Raspberry Pi. Son bastante livianos, y si intentas construir, digamos, un centenar de esos para pegarlos en todas las calles de un distrito, no querrás que todos tengan que esperar una o dos horas para descargar el archivo y a medida que la cadena se hace más grande, obviamente ese número aumenta.
Entonces, la solución básicamente agiliza la cantidad de tiempo que lleva construir un nodo y también, como dice Bader, la capacidad de restablecer el nodo y hacer que vuelva a estar en línea muy rápidamente. Desde el punto de vista de la comunidad NEM, en la cadena pública, el conector tiene algunos casos de uso para ayudar a acelerar el tiempo que lleva poner un nodo en línea. En la cadena privada o en las implementaciones de tipo IoT, definitivamente acelera la implementación, particularmente una vez que comienza a ingresar a las decenas o cientos de nodos.
Kevin, ¿Qué significa esto en términos reales para las personas que usan el conector? ¿Tienes alguna idea de cuál es la diferencia entre usar Tardigrade y el método tradicional?
KL:
Creo que la diferencia más obvia, y esto se menciona en la publicación de blog original que publicó Bader, así como en Storj, resultó en un aumento de quince X – 1500% – en el rendimiento. Para decirlo de otra manera, el conector ofrece una disminución del 93% en el tiempo que se tarda en sincronizar el nodo. Así que el rendimiento aumenta de manera asombrosa en comparación con el método tradicional. Y eso era algo que nos entusiasmaba mucho mostrar.
.. esto resultó en un quince X – 1500% – aumento en el rendimiento. Para decirlo de otra manera, el conector ofrece una disminución del 93% en el tiempo que se tarda en sincronizar el nodo.
¿Es eso habitual? esas estadísticas de rendimiento que mencionaste, suenan impresionantes. ¿Es eso algo a lo que aspirabas, o fue simplemente un resultado realmente agradable?
KL:
De hecho, también hemos visto resultados similares en el mundo Ethereum. Con las cadenas compatibles con Ethereum que se basan en GEF, hemos visto un aumento del veinticuatro por ciento en comparación con los métodos de sincronización tradicionales. Estamos probando nuestros nodos de archivo en este momento, por lo que estamos agrupando este caso de uso en algo que llamamos sincronización rápida descentralizada o DFS, y el rendimiento en el que aumenta para este subconjunto específico de casos de uso ha sido bastante impresionante, así que Estoy muy emocionado.
Suena como una solución asombrosa, cuando lo abordó, ¿encontró algún desafío o dificultad específica en términos de integración o trabajo conjunto? ¿Cuáles fueron los aspectos específicos que tuvo que superar para que el conector funcionara?
BY:
Tuve que hacer algunas modificaciones en la herramienta Connector para ajustarla, lo que en realidad significo algunos pequeños problemas dentro de las implementaciones de Catapult, servidor y REST, es decir, que hay una nueva forma en que el conector usa la autenticación.
Así que tuve que hacer algunos pequeños cambios en mi bifurcación para adaptarse, así como también cambiar el comportamiento de la funcionalidad del intermediario del servidor Catapult. Tuve que ir al servidor central y modificar cómo recogía los bloques y cómo los almacenaba en la base de datos. Para que pueda dar cuenta de la copia de seguridad entrante procedente de Storj. Esos fueron un par de pequeños desafíos, pero los superamos y aquí estamos.
Dave, desde tu perspectiva, ¿fue todo bastante sencillo en términos de colaboración?
DH:
¡Fue sencillo principalmente porque no vi nada de eso! No hice todos los detalles, pero supongo que lo que Bader estaba haciendo en el sentido no técnico es esencialmente que tenía que conseguir que el uso de Catapult de MongoDB fuera compatible con el funcionamiento de Storj. También tuvo que averiguar cómo realizar un corte de manera efectiva en un momento determinado de ese MongoDB, porque se está utilizando continuamente y se actualiza continuamente. Bader tuvo que echar un vistazo al corredor para averiguar cómo hacer que pareciera que deja de moverse para poder respaldarlo de manera efectiva.
Excelente. ¿Y dónde está el producto, dónde puede encontrarlo la gente, si quiere usarlo?
BY:
Si quieres salir y probarlo, puedes ir a nuestra bifurcación del devnet que tenemos. Hay un enlace dentro del artículo. Todavía necesito actualizar el devnet a la última versión, me gustaría integrarlo para que funcione a la perfección, en este momento, prácticamente está todo ahí. De hecho, puede ver cómo funciona todo y cómo se conecta.
Desde su perspectiva Kevin, ¿cuál es el potencial del conector Tardigrade? ¿A dónde ve que se dirige desde aquí?
KL:
Esa es una gran pregunta, creo que esto es realmente solo el comienzo de una colaboración más amplia en términos del ecosistema, la colaboración entre Symbol y Tardigrade. Esperamos poder respaldar casos de uso que requieren almacenamiento: cada aplicación en algún momento requerirá el almacenamiento y la distribución de cosas llamadas objetos que tienden a ser imágenes, videos, ya sabes, co-binarios, lo que sean. Queremos ser el estándar descentralizado para admitir el almacenamiento de objetos dentro del ecosistema NEM.
.. Creo que esto es realmente solo el comienzo de una colaboración más amplia en términos del ecosistema, la colaboración entre Symbol y Tardigrade. Esperamos poder brindar soporte a casos de uso que requieran almacenamiento. Queremos ser el estándar descentralizado para admitir el almacenamiento de objetos dentro del ecosistema NEM.
Entonces, Bader, ¿Cuáles crees que serán los próximos pasos en términos de cómo llevar adelante esta idea?
BY:
En la medida en que esto funcione en el lado de la aplicación, probablemente se haga a través de algún complemento de transacción Storj teórico en Symbol que le permitiría cargar un archivo a través de Symbol en Storj, y luego tenerlo accesible para los mecanismos de control en Symbol que le permitan compartir ese acceso con otras personas en la cadena de bloques.
Posteriormente, esto le permitiría vender el acceso a este archivo o este objeto. En el futuro, eso sería ideal para todo tipo de aplicaciones IoT como las de atención médica en donde se debe almacenar un archivo de paciente en asociación con la identidad etc.
Y Dave, ¿Cuál es el siguiente paso desde tu punto de vista?
DH:
El siguiente paso obvio, es observar cómo hacemos una copia de seguridad del nodo del mismo nivel de Symbol que incluiría efectivamente RocksDB y el directorio. Estamos en las primeras etapas del inicio de esa conversación, y suponiendo que se puedan lograr resultados similares a los que hemos visto con MongoDB, esto nos ayudará a medida que escalemos la red pública en general, y también ayudará a las empresas a usar redes privadas.
El segundo lugar debemos mirar retrospectivamente a NIS1. La actual cadena pública de NEM ya tiene cinco años y medio de datos, y está empezando a crecer en términos de almacenamiento de datos debido a la cantidad de transacciones que tiene allí, aunque todavía hay mucho espacio para la cabeza. Ya tenemos la posibilidad de descargar un archivo o transacciones históricas e importarlo a un nodo. Entonces, si podemos hacer que ese archivo se descargue más rápido y tenerlo más actualizado, eso ayudaría a implementar los nodos NIS1 en general. Vale la pena señalar que nuestros dos servidores no “confían” en la copia de seguridad al cien por cien, por lo que la descargan para usarla como punto de partida y luego validan con lo que la red cree que está presente. Básicamente, evita que alguien coloque una copia de seguridad falsa.
Y luego el tercero, y creo que este es probablemente el más interesante debido a la aplicación real y comercial del conector, es esencialmente configurar un marco de conector de almacenamiento y un marco de Oracle, donde tendría un extensión o un complemento que le permite agregar complementos para múltiples tipos de almacenamiento. Me gustaría ver a Tardigrade como el primero de ellos.
.. Creo que este es probablemente el más interesante debido a la aplicación comercial y del mundo real del conector, es esencialmente configurar un marco de conector de almacenamiento y un marco de Oracle, donde tendría un extensión o un complemento que le permite agregar complementos para múltiples tipos de almacenamiento. Me gustaría ver a Tardigrade como el primero de ellos…
de modo que logramos el mismo tipo de cosas que Bader estaba describiendo, donde esencialmente puedes ponerlo a disposición de todos en la cadena y se convierte en un tipo de transacción que tiene un archivo conectado. Posiblemente usando el intercambio entre cadenas, incluso podríamos pagar las tarifas de Storj, usando un intercambio descentralizado en el camino.
Creo que las aplicaciones de esto son probablemente muy difíciles de predecir exactamente, puedo nombrar algunas sencillas, como Kevin aludió con los videos y los documentos, pero, cada vez más, estamos comenzando a ver grandes cantidades de datos. Dos cadenas diferentes, y esos datos están comenzando a cambiar. Por lo tanto, pueden ser copias de seguridad de bases de datos o incluso estados hash de diferentes aplicaciones, etc.
Entonces, el potencial de esto en el futuro es enorme, ¿Es lo que te parece Dave?
KL:
Sí, así lo diría yo. Hay 3 componentes centrales en cualquier sistema informático: el aspecto informático, el aspecto de almacenamiento y el aspecto de red. Y queríamos cubrir ampliamente el aspecto del almacenamiento.
¿Hay algo más que le gustaría agregar sobre el conector Tardigrade o que no hayamos cubierto hasta ahora?
DH:
Lo principal que me gustaría agregar es probablemente más allá del conector MongoDB. Solo para reiterar que Tardigrade ya es una solución de almacenamiento que puede ser considerada por cualquier proyecto en el ecosistema NEM, independientemente de cualquiera de estas ideas de integración que tengamos en el futuro.
Si las empresas están considerando usar Amazon S3 o IPFS (InterPlanetary File System) o Filecoin cuando se presente, entonces pueden considerar usar Tardigrade, ya que en la actualidad está funcionando y es utilizable. Hemos utilizado un tipo de conector muy específico para los problemas que Bader quería resolver, pero el uso general del mismo (Tardigrade), como un lugar de almacenamiento para las personas que desean almacenar información de seguimiento de la cadena de suministro, como fotos, etc., todo funciona hoy, y ya puedes hacerlo.
Excelente. Y Kevin, ¿Hay algo que te gustaría transmitir desde el punto de vista de Storj?
KL:
En un nivel realmente alto, Tardigrade funciona así. Todos los archivos se cifran en el lado del cliente antes de que salgan de los servidores de nadie, por lo que, de forma predeterminada, obtiene un cifrado de extremo a extremo que puede ser difícil de configurar en AWS o cualquier otro proveedor. Obtiene las funciones estándar de cifrado de extremo a extremo, redundancia geográfica global de forma predeterminada, donde normalmente tendría que pagar para replicar en el Este de EE. UU., Oeste de EE. UU., Europa, Asia, si está utilizando un proveedor heredado. La otra cosa clave es que cada archivo está dividido en ochenta partes y es necesario editar veintinueve de las ochenta partes para reconstruir el archivo. Si alguno de esos ochenta nodos que almacenan el archivo se desconecta, el archivo se repara y, cuando lo llama, las veintinueve más rápidas de las ochenta piezas reconstruyen el archivo para que siempre esté optimizando el rendimiento obteniendo el subconjunto más rápido. de cualquier superconjunto de nodos en un momento dado. Ésta es una descripción general rápida de cómo funciona Tardigrade.
BY:
Dave cubrió lo que quería decir, pero esto es un cambio de juego para las aplicaciones de IoT en blockchain, porque creo que lo que muchas empresas buscan hacer es almacenar grandes cantidades de datos en blockchain, que no es realmente para lo que DLT y blockchain están hechas.
… esto es un cambio de juego para las aplicaciones de IoT en blockchain, porque creo que lo que muchas empresas buscan hacer es almacenar grandes cantidades de datos en blockchain, que no es realmente para lo que DLT y blockchain están hechas.
Tardigrade es esa pieza faltante del rompecabezas de las aplicaciones DLT que nos permite almacenar información relevante, y una gran cantidad de ella, que realmente será útil.
Esta es una traducción al español del artículo original (en inglés) escrito por NEM Official (Editors) en Medium . Traducido y editado por NEM en Español. Juntos estamos haciendo que NEM sea más fuerte y que Symbol sea más brillante.
Para más información y noticias sobre NEM, le invitamos a seguirnos en nuestras redes sociales: Facebook, Twitter e Instagram
