¡Hola a todos!
El trabajo de SDFS de esta semana se ha dedicado al diseño de la documentación, lo que significa que John y yo hemos pasado la semana descubriendo los detalles de cómo funcionarán las distintas funciones. Esto ha llevado a un discurso bastante interesante, y estamos encontrando buenas soluciones.
La característica principal que nos ha llamado la atención esta semana ha sido el "Servicio de utilidad de Chunk". Cuando un usuario desea compartir un archivo, ese archivo se divide en varias partes más pequeñas de ese archivo, llamadas "Chunks", que se cifran individualmente. En términos más simples de SDFS, esos trozos son almacenados por el "cargador" (en realidad, los términos "cargar" y "descargar" no tienen mucho sentido en el contexto de un sistema descentralizado; tema que saldrá pronto). Cuando alguien quiere "descargar" ese archivo, le piden a la persona que carga los fragmentos y, suponiendo que el descargador tiene permiso para recibirlos, se los envía.
¿Qué sucede, sin embargo, cuando el cargador está fuera de línea? Según el escenario anterior, el archivo no se puede transferir. Para algunos casos de uso, esto puede ser realmente aceptable, tal vez porque los nodos involucrados pueden configurarse para que tengan un tiempo de actividad elevado (de modo que el cargador no esté nunca funcionalmente conectado), o porque la alta disponibilidad no sea una preocupación principal. Sin embargo, ¿qué se puede hacer cuando no se puede garantizar el tiempo de actividad pero es deseable una alta disponibilidad?
Aquí es donde el "Servicio de utilidad de Chunk" entra en escena. El CUS es un servicio que almacena grandes porciones en nombre de otros usuarios y, presumiblemente (aunque no explícitamente), mantiene un alto tiempo de actividad. La lista de usuarios permitidos para cargar trozos o descargar cualquier trozo en particular es configurable, y el CUS se conecta a las cadenas de bloques para proporcionar registros no repudiables de los trozos que se han transferido ya quién. Gracias a nuestros estrictos requisitos de criptografía, el CUS, a pesar de estar conectado a la cadena de bloques, no podrá descifrar ninguna de las transacciones en la cadena de bloques que no están específicamente diseñadas para ello; esto garantiza que el CUS se pueda agregar a un sistema. Proporcionando una gran utilidad sin comprometer la seguridad. Ahora, cuando el "cargador" está fuera de línea, los fragmentos se pueden recuperar del CUS.
La idea general en este momento es que el CUS sería un servicio dedicado que podría ser ejecutado por un usuario en una máquina personal, en un servidor alojado o en la nube, según sea necesario. El objetivo, naturalmente, es asegurarse de que funcione en Linux, Windows y Mac. El diseño de seguridad, mencionado anteriormente, es un poco intenso para una publicación de blog en mi opinión: los detalles del diseño se harán públicos cuando la documentación se publique en el futuro.
Gracias por leer. Sintonice la próxima vez para más actualizaciones de progreso.
Sobre el Autor:
Cody Sandwith se graduó en la Universidad de Washington y ha estado trabajando para Topia Technology desde 2011 en Secrata, una plataforma de sincronización y uso de archivos altamente cifrada.
