filefilego
v1.4.3
El protocolo FileFileGo es una red de almacenamiento y intercambio de datos de igual a igual diseñada para la era Web3, con un mecanismo de incentivos, búsqueda de texto completo y un motor de almacenamiento. Su arquitectura descentralizada permite a los usuarios almacenar y compartir datos sin censura o un solo punto de falla. Al aprovechar los conceptos de la teoría del juego, FileFilego incentiva la participación y garantiza la disponibilidad de datos al tiempo que alcanza la tolerancia a fallas y la preservación de la privacidad.
FileFileGo es un proyecto comunitario de código abierto, sin control o propiedad centralizada. Su distribución de monedas está diseñada para ser justa, con una emisión de 40 FFG por bloque que disminuye en la mitad cada 24 meses. El protocolo se lanza sin ICO/STO/IEO o pre-Mine, confiando en un algoritmo de consenso de prueba de autoridad que eventualmente pasará a la prueba de participación para permitir que más partes interesadas participen.
Al admitir FileFilego, los usuarios pueden ayudar a promover los derechos digitales, la privacidad, la libertad de información y la neutralidad de la red. Alentamos contribuciones e ideas innovadoras para garantizar que Internet siga siendo una plataforma abierta y descentralizada.
Supongamos que node_1 necesita descargar algunos data_x , propiedad de node_2 , y pagar las tarifas requeridas por node_2 . ¿Qué sucede en el caso de los nodos de falla bizantina? ¿Cómo verificamos la transferencia de datos exitosa a los nodos de destino y evitamos los siguientes casos maliciosos?
node_1 es un nodo deshonesto que informa data_x como inválido, para evitar pagar las tarifas.node_2 es un nodo deshonesto que sirve data_y a node_1 y afirma que es data_x . La red puede resistir fallas bizantinas si node_x puede transmitir (punto a igual) un valor x y satisfacer lo siguiente:
node_x es un nodo honesto, entonces todos los nodos honestos están de acuerdo con el valor x. La prueba del mecanismo de transferencia aborda los problemas antes mencionados al permitir nodos honestos en la red para verificar y alcanzar el consenso sobre la transferencia exitosa de data_x desde node_2 a node_1 . Esto se logra mediante el uso de verificadores, que son responsables de desafiar los nodos participantes. Si bien un enfoque directo implicaría enviar los datos requeridos a un verificador y luego reenviarlos al nodo de destino, este método puede conducir a un ancho de banda y cuellos de botella de almacenamiento, reduciendo así el rendimiento general de la red. Por lo tanto, la solución de prueba de transferencia se ha diseñado para minimizar el ancho de banda y los requisitos de almacenamiento/memoria asociados con este proceso.
┌───────────┐
┌────────►[verifiers]◄─────────┐
│ └───────────┘ │
┌────┴───┐ ┌────┴───┐
│ │ │ │
│ node_1 ◄─────────────────────► node_2 │
│ │ │ │
└────────┘ ├────────┤
│ data_x │
└────────┘
Dejar
Divide el contenido del archivo
Calcule el hash del árbol de Merkle de los segmentos: dejar
Baraja los segmentos: deja
Cifrar el 1 por ciento de los segmentos barajados: dejar
Descifrado de segmentos cifrados: para cada uno de los
Restauración del orden barajado: dado que los segmentos se barajaron durante el proceso de cifrado, deben restaurarse a su orden original utilizando la permutación inversa
Cálculo del hash de Merkle Tree: Recalcule el hash del árbol de Merkle de los segmentos descifrados en el orden restaurado. Construya el árbol hash de manera similar a la construcción original, pero use los segmentos descifrados
Finalmente, el hash de raíz de merkle original derivado
El consenso se logra si el hash de la raíz de Merkle derivado coincide con el hash de la raíz Merkle original.
Considere un escenario que involucra un archivo que contiene el contenido posterior:
FileFileGo_Network
Al cargar un archivo a un proveedor de almacenamiento, el hash raíz de Merkle del archivo se calcula a través de la segmentación de su contenido en distintos segmentos de datos.
La ilustración resultante muestra una manifestación simplificada de la disposición del archivo en el medio de almacenamiento. Cada cuadro individual dentro de la ilustración simboliza 1 byte de datos.
┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┐
│ F │ i │ l │ e │ F │ i │ l │ e │ G │ o │ _ │ N │ e │ t │ w │ o │ r │ k │
└───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┘
Para encontrar el hash de Merkle Root de este archivo, dividimos el archivo en partes más pequeñas. Por ejemplo, dividamos el archivo en nueve secciones, y cada parte tendrá solo dos bytes.
0 1 2 3 4 5 6 7 8
┌───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ F i │ l e │ F i │ l e │ G o │ _ N │ e t │ w o │ r k │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
Ahora tomamos el hash de cada segmento:
segment 0: hash("Fi"), denoted by h0
segment 1: hash("le"), denoted by h1
segment 2: hash("Fi"), denoted by h2
segment 3: hash("le"), denoted by h3
segment 4: hash("Go"), denoted by h4
segment 5: hash("_N"), denoted by h5
segment 6: hash("et"), denoted by h6
segment 7: hash("wo"), denoted by h7
segment 8: hash("rk"), denoted by h8
Y luego calculamos el hash de la raíz Merkle del archivo aplicando el algoritmo.
Aquí hay un ejemplo de cómo funciona este algoritmo:
┌───┬───┬───┬───┬───┬───┬───┬───┐
Data Blocks:│ a │ b │ c │ d │ e │ f │ g │ h │
└───┴───┴───┴───┴───┴───┴───┴───┘
0 1 2 3 4 5 6 7
│ │ │ │ │ │ │ │
└───┘ └───┘ └───┘ └───┘
h01 h23 h45 h67
│ │ │ │
└───────┘ └───────┘
h(h01+h23) h(h45+h67)
│ │
│ │
└───────────────┘
Merkle root: h(h(h01+h23)+h(h45+h67))
Ahora, poseemos un hash de Root Merkle para el archivo, representado como MT (F), que es esencialmente otro valor hash.
Cuando una solicitud para recuperar datos llega a un proveedor de almacenamiento, el proveedor reorganiza los segmentos de datos en un orden aleatorio. Por ejemplo, considere la secuencia de segmentos de datos:
random segments [ 1, 5, 2, 4, 7, 6, 3, 0, 8 ] , que se traduce en la siguiente disposición:
1 5 2 4 7 6 3 0 8
┌───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ l e │ _ N │ F i │ G o │ w o │ e t │ l e │ F i │ r k │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
Posteriormente, el proveedor genera una clave simétrica y un vector de inicialización (IV) para cifrar una parte de estos segmentos. En esta ilustración, optaremos por cifrar el 25% de los segmentos, lo que equivale a 2 segmentos. Además, cifraremos cada 4 segmentos, lo que implica que cifraremos los segmentos 0 y 4:
25% Segment Encryption = 2 segments
┌───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ l e │ _ N │ F i │ * * │ w o │ e t │ l e │ * * │ r k │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
Ahora, los datos mencionados se proporcionarán al solicitante de datos. Simultáneamente, la clave/IV, el orden aleatorizado de los segmentos y el contenido de los segmentos 0 y 4 se transmiten al data verifier . Es importante destacar que el descargador posee Zero-Knowledge con respecto al orden de los segmentos dentro del archivo y la clave de cifrado/IV.
Es posible que le preocupe la posibilidad de que alguien cree un guión para intentar varias combinaciones de segmentos para determinar el orden original, lo que puede conducir a una vulnerabilidad de seguridad y un posible ataque.
Para proporcionar más información, considere que un archivo se divide en aproximadamente 1024 segmentos (o ligeramente menos) en un escenario del mundo real, y estos segmentos se aleatorizan. Para que un atacante reconstruya el orden de segmento original, necesitaría llevar a cabo una "permutación sin repetición". ¡El recuento total de formas de organizar estos segmentos de archivo viene dado por n! (factorial), que equivale a 1024! en este caso. (https://coolconversion.com/math/factorial/what-is-the-factorial-of_1024_%3F)
El paso posterior del atacante implica intentar adquirir la clave y la IV utilizada para encriptar los dos segmentos. Sin embargo, vale la pena señalar que esta tarea se considera actualmente imposible en función de las vulnerabilidades existentes en el campo.
Después de esto, el descargador de archivos debe solicitar la clave de cifrado/IV y el orden aleatorizado de los segmentos de archivos desde un data verifier designado dentro de la red.
El descargador de datos envía una solicitud al verificador de datos, buscando la clave de cifrado/IV y los segmentos aleatorios. Esta solicitud está acompañada por el segmento hash del archivo descargado, que se presentan de la siguiente manera:
h1
h5
h2
h(enc(4))
h7
h6
h3
h(enc(0))
h8
El data verifier realiza cifrado y hash para los segmentos 0 y 4, lo que resulta en los siguientes valores hash:
h1
h5
h2
h4
h7
h6
h3
h0
h8
Por último, el data verifier reorganiza los segmentos de acuerdo con el orden aleatorizado generado por el archivo Hoster durante la transferencia de datos al solicitante. Este proceso produce la secuencia original de hashs de segmento:
h0
h1
h2
h3
h4
h5
h6
h7
h8
En última instancia, a través de la ejecución del cálculo de hash de Merkle Root, el verificador de datos deduce el hash de Root Merkle original sin necesitar acceso local completo a todo el contenido del archivo.
Al confirmar que el hash de raíz derivada de Merkle coincide con el original, hemos establecido efectivamente una prueba matemática de que el descargador de datos posee todos los datos solicitados. Posteriormente, el verificador de datos transmite la clave de cifrado/IV y el orden de segmentos aleatorios al descargador de datos, lo que lleva a la versión automática de tarifas al archivo Hoster.
En esta sección, se demuestra el ciclo de vida completo de una verificación de transferencia de datos.
1. Data Query Request
┌───────┐
┌───────────────►[nodes]├───────────────┐
│ └───────┘ │
┌───┴────┐ ┌────▼───┐
│ │ │ │
│ node_1 │ │ node_2 │
│ │ │ │
└───▲────┘ └───┬────┘
│ 2. Data Query Response │
└──────────────────────────────────────┘
Data Query Response contiene toda la información necesaria para preparar una transacción de contrato inteligente. Esta transacción se transmite a la red que luego es seleccionada por un verificador. ┌──────────────────────────────────────┐
│ TRANSACTION │
├──────────────────────────────────────┤
│ Data : │
│ - Data query response │
│ - Remote node signature │
│ Value: │
│ - Fees required by node │
│ │
│ Fees : │
│ - Fees collected by verifier │
│ │
│ To : │
│ - Network verifier │
└──────────────────────────────────────┘
v1 ) se comunica con los nodos participantes y genera un desafío para el nodo que aloja los datos ( node_2 ). El desafío consiste en los siguientes pasos:node_2 debe crear un árbol de Merkle que coincida con la raíz Merkle original de data_x cargada en primer lugar.v1 decide el orden y el número de bloques/rangos de datos que se enviarán a node_1 por node_2 . Todavía no queremos revelar el orden de los bloques a node_1 .v1 le pide node_2 un rango fijo de datos, que se encriptará utilizando una clave aleatoria k1 como data_enc por v1 y enviado a node_1 . En esta etapa, node_1 posee algunos data_z y data_enc pero carece del conocimiento de cómo combinarlos para obtener el archivo original. El verificador, V1, puede verificar la integridad de los datos transmitidos a node_1 y, si coinciden con la identidad del árbol de Merkle original, la clave de descifrado K1 se proporciona a node_1 . Además, el orden de bloque se envía a node_1 , lo que permite el reensamblaje de todas las piezas para formar los datos originales. Una vez que se completa este proceso, V1 libera las tarifas a node_2 .
El uso de este algoritmo permite el logro simultáneo de prueba de transferencia y prueba de posesión de datos.
Siga las instrucciones para compilar e instalar fileFileGo
https://filefilego.com/documentation/docs/installation.html#prerequisites
FileFileGo es una red descentralizada que incorpora la robustez de la tecnología innovadora de blockchain/criptomonedas, DHT y BitTorrent para formar una infraestructura inexpugnable.
Para lograr un tiempo de bloque de 10 segundos, FileFileGo requiere un algoritmo de consenso que sea eficiente en el procesamiento de un alto volumen de transacciones y conserva la potencia de procesamiento. Para la fase inicial, hemos seleccionado la prueba de autoridad (POA) como nuestro algoritmo de consenso. En el futuro, un mecanismo de prueba (POS) reemplazará el algoritmo actual.
El uso de algoritmos basados en POW para nuevas blockchains presenta un riesgo, ya que ya hay grupos sustanciales de energía informática disponibles que podrían usarse para ataques del 51%. Por lo tanto, hemos optado por POA, que es seguro por diseño y proporciona la eficiencia necesaria para respaldar nuestros altos requisitos de volumen de transacciones.
Las identidades de los validadores están codificadas en la cadena de bloques y pueden verificarse examinando la transacción Coinbase del Block Genesis. Los nodos participantes pueden verificar fácilmente la autenticidad de estas identidades verificando las firmas del bloque.
A medida que avanzamos, el mecanismo POA actual se reemplazará por prueba de participación para permitir que múltiples partes participen en el proceso de minería de bloques. Nuestro objetivo para la gobernanza de blockchain es alentar a más partidos y desarrolladores a involucrarse y aumentar el compromiso de las partes interesadas. Uno de los incentivos para lograr este objetivo es el mecanismo de prueba de estaca.
Para simplificar la transacción y la mutación del estado, FileFilego adopta un enfoque diferente a las estructuras similares a UTXO. En lugar de usar tales estructuras, almacenamos contabilidad y metadatos como filas de base de datos regulares, al tiempo que conservamos los bloques sin procesar en su formato original dentro de la base de datos. Este enfoque ayuda a eliminar la complejidad innecesaria.
En esta sección, proporcionaremos una visión general de los términos y conceptos técnicos utilizados en FileFileGo.
Los canales en FileFilego permiten a los usuarios organizar y agrupar datos en distintos cubos o carpetas. Por ejemplo, todo el contenido en ubuntu.com podría colocarse en un canal llamado "Oficial de Ubuntu". El usuario que crea un canal recibe todos los permisos necesarios para actualizaciones y otras operaciones relacionadas con el canal.
Los canales se estructuran en un formato de cadena de nodo y pueden identificarse como un nodo sin un ParentHash .
El concepto de sub-canal es poder clasificar aún más los datos. Por ejemplo, documentos, imágenes o música.
En FileFilego, una Entry representa una publicación o una pieza de datos que contiene más información sobre la entrada en sí en lugar de la categorización/pedido. File y Directory se pueden colocar en una Entry .
Storage Engine es la capa de almacenamiento que rastrea los datos binarios, que utilizan los punteros hash dentro de la cadena de bloques para referirse a un dato. La estructura NodeItem tiene un campo llamado FileHash que se refiere al hash binario y está en forma de "{HASH_ALGORITHM}:>{DATA_HASH}" . Nos gustaría mantener los metadatos del algoritmo de hash utilizado, ya que podría ser útil en el futuro.
En FileFilego, la precisión de búsqueda y la flexibilidad son igualmente importantes como la funcionalidad de blockchain central. Nuestro objetivo es permitir a los usuarios construir consultas complejas, incluidas las búsquedas binarias, utilizando un lenguaje de consulta específico. Por ejemplo, deberían ser posibles consultas de los siguientes tipos:
Desarrollar un lenguaje de consulta que respalde consultas tan complejas es una herramienta poderosa que puede mejorar significativamente la precisión del motor de búsqueda.
También es posible habilitar la funcionalidad de indexación de texto completo de un nodo utilizando el indicador CLI --search .
La capa de almacenamiento realiza un seguimiento de los archivos binarios y utiliza hashes para representar una información dentro de la cadena de bloques. Esta característica se puede activar utilizando las siguientes banderas:
... --storage --storage_dir="/somewhere/to/store/data" --storage_token="somelongtokenhere" --storage_fees_byte="10000" ...
--storage_dir debe ser un directorio que existe con los permisos de lectura/escritura apropiados. Tenga en cuenta que los nodos completos pueden funcionar sin este mecanismo. storage_token es un token que otorga derechos de administrador a un token para que pueda crear otros tokens utilizando la API HTTP. Esto es útil cuando las aplicaciones web o los usuarios distintos necesitan un derecho de acceso y --storage_fees_byte="10000" son las tarifas cobradas por byte de datos.
| Unidad | Valor |
|---|---|
| Ffgone | 1 |
| Kffg | 1.000 |
| Mffg | 1.000.000 |
| Gffg | 1.000.000.000 |
| Microffg | 1.000.000.000.000 |
| Lente | 1.000.000.000.000.000 |
| FFG (unidad predeterminada) | 1.000.000.000.000.000.000 |
| Zffg | 1.000.000.000.000.000.000.000 |
Suministro total: 500 millones de FFG Validación/recompensa de participación: 40 FFG por bloque de suministro Tasa de disminución: Divide 2 cada 24 meses
