En este blog técnico, veremos cómo podemos usar fragmentos de código Swarm y convertirlos en módulos funcionales que puedan funcionar dentro de un navegador web. Al hacer estos módulos de recursos de luz basados en navegador web, podemos excluir las formas de comunicación Web 2.0 con la red Swarm y utilizar los métodos nativos de Swarm. De esta manera, podemos comenzar a usar la Web de una manera verdaderamente descentralizada pero sin la experiencia de usuario torpe y las tasas de adopción de las tecnologías descentralizadas.
Vemos permitir un uso más amplio de Swarm y, en consecuencia, de un enfoque de datos cero a usar la Web como algo fuertemente alineado con la misión y los valores de Fair Data Society. Por eso hemos decidido incluir esta publicación de blog en nuestra publicación.
Hoy en día, los dapps Web 3.0 ya pueden almacenar datos de usuario, estado de usuario o el código dapp en Swarm. El problema que surge aquí es que muchos de ellos todavía usan métodos Web 2.0 (como conexiones http o https) para conectarse a una puerta de enlace central de Swarm. Es similar a cómo los dapps de Ethereum usan Infura para acceder a la cadena de bloques.
Afortunadamente, hay una mejor manera de permitir que Dapps use Swarm de una manera más descentralizada. Una forma de lograr esto es reescribir Swarm en un lenguaje web amigable para el cliente como JavaScript. Otra forma es envolver el código Swarm en WebAssembly (WASM), para que pueda usarse en el lado del cliente. Estos métodos eliminan el acceso web 2.0 de la última milla y ayudan a que los dapps se vuelvan verdaderamente descentralizados.
Compilar todo el código Swarm como un módulo WASM monolítico no tendría sentido, ya que daría como resultado un gran tamaño binario y agregaría retraso a las aplicaciones front-end. En cambio, podemos dividir Swarm en múltiples componentes lógicos y tener una envoltura WASM para cada uno de ellos. Esto permitirá que los dapps frontales elijan y elijan los módulos que necesitan, reduciendo la hinchazón innecesaria en el código.
Empujar Swarm al lado del cliente también significa que deberíamos ser ligeros en cuanto a almacenamiento y requisitos de ancho de banda. El equipo de Swarm ya ha publicado una pista de GitHub en Cliente de luz de enjambre. Se recomienda que implementemos los cambios de la vía en los módulos SWASM que proponemos a continuación. Los siguientes son algunos de los módulos SWASM que se requieren para lograr un acceso y uso de Swarm verdaderamente descentralizado.
1) Enjambre de capa de red WASM
BZZ es el protocolo principal de Swarm que se encarga de sincronizar los fragmentos a través de la red. La superposición Swarm kademlia, o Hive como se le llama en el código Swarm, es la responsable de enrutar los paquetes en la red Swarm. Esta superposición depende del protocolo devp2p de nivel inferior para mantener un canal cifrado para cada uno de los pares de un nodo Swarm determinado.
La colmena es el punto de entrada al mundo de Swarm. Si esta capa se empaqueta como un módulo WASM separado, cualquier dapp puede usarla para comunicarse de forma nativa con cualquier nodo Swarm. La entrada de este módulo provendrá del Archivo de imagen previa distribuido o del Servicio postal sobre los módulos WASM de Swarm que se describen a continuación. La salida de este módulo se enviará a la red Swarm, de forma nativa, desde el propio dapp.
2) WASM de archivo preimagen distribuido (DPA)
DPA se encarga de las funciones como fragmentar archivos en piezas más pequeñas y encriptar. Esta funcionalidad solo es necesaria para dapps que necesitan cargar archivos en Swarm. En un nodo Swarm completo, el DPA también tiene una tienda local, que almacena los fragmentos cerca de este nodo. Pero para la mayoría de las funciones del lado del cliente, el DPA debe implementar almacenamiento ligero como se recomienda en Cliente de luz de enjambre propuesta. Este módulo WASM debe incluirse en dapps que requieren el almacenamiento de datos de usuario o estado de usuario en Swarm. Si un dapp decide usar este módulo WASM, la entrada del módulo debe provenir del dapp y luego enviar los fragmentos cifrados al primer módulo – Swarm Network Layer WASM – módulo.
3) Servicio postal sobre enjambre (PSS) WASM
El Servicio Postal sobre Swarm es el módulo de comunicación de Swarm. Los Dapps que necesitan una forma descentralizada y resistente a la censura para comunicarse entre ellos son los principales usuarios de este módulo. Por ejemplo: aplicaciones de chat. PSS utiliza el enrutamiento Kademlia Swarm para encontrar el destino del mensaje. También se encarga del cifrado y la gestión de claves.
PSS toma la entrada del dapp y entrega la salida al módulo WASM Swarm Network Layer, que a su vez envía el mensaje utilizando el enrutamiento kademlia.
4) Alimenta WASM
Feeds es una estructura de datos simple sobre Swarm para que dapps almacene datos mutables en Swarm. Feeds es un mecanismo simple para que la red recuerde el último hash de los datos en cuestión. Los feeds toman la entrada de los dapps y usan la capa DPA para almacenar los detalles en Swarm. Este módulo WASM será útil para dapps que necesitan algún tipo de mutabilidad en el almacenamiento de datos en Swarm.
1) compresión
La compresión sin pérdida es algo que Swarm no admite actualmente. Si se implementa, debería ser parte del módulo DPA descrito anteriormente. Sin embargo, hay un par de cosas que deben tenerse en cuenta al implementar la compresión en Swarm:
Debemos tener cuidado al usar la compresión de bloques como snappy, bz2, etc. Estos esquemas de compresión de bloques pueden descomprimir una parte del archivo sin acceder a todo el archivo. Esto es importante, ya que los archivos en Swarm se dividen en fragmentos y se distribuyen por la red. Debe haber algún índice que asigne la ubicación real de un archivo a la ubicación comprimida. Debido a que Swarm Chunking funciona en ubicaciones de archivos reales, debemos tener cuidado de no alterar esta lógica.
2) bloques
Los trozos en Swarm tienen un tamaño de 4 kb y el tamaño es fijo. Para algunos casos de uso, como la transmisión de video, esta es una propiedad muy agradable. Pero para muchas aplicaciones que manejan grandes cantidades de datos (por ejemplo, análisis, procesamiento de grandes datos, ETL …), realizar un seguimiento de millones de fragmentos es una sobrecarga.
Block es una forma abstracta de pensar en trozos. Varios trozos forman un bloque. El tamaño del bloque se fija para un solo archivo, que se decide durante la creación del archivo en Swarm. A diferencia de los fragmentos, los metadatos del bloque están expuestos a la aplicación. Las aplicaciones pueden realizar su lógica por bloque.
Los metadatos del archivo tendrán detalles sobre los bloques, como clave de cifrado, esquema de compresión, etc.
El desarrollo de estos cuatro módulos es un paso importante para la adopción de tecnologías descentralizadas y beneficiará a todo el ecosistema de Swarm. Los módulos proporcionarán a los dapps una forma directa y descentralizada de comunicarse con la red Swarm a través de interfaces establecidas, como un navegador web, creando un puente entre la Web 2.0 y la Web 3.0.
Es por eso que el equipo de Datafund ha decidido hacer del desarrollo de estos módulos su próxima contribución a Fair Data Society y los módulos también se han incluido en nuestra hoja de ruta. Esperamos enfrentar este desafío, creando una Web mejor y más privada para todos.
