Una comprensión profunda de IPFS El núcleo de IPFS es un sistema de archivos versionado

"Después de tener IPFS, puede comenzar a ver todo lo demás de una manera específica, y luego se dará cuenta de que puede reemplazarlos a todos". -
Juan Benet, fundador de IPFS

01 simple comprensión de IPFS

Esta sección intentará proporcionar información de alto nivel sobre el siguiente resumen técnico en profundidad del Dr. Christian Lundkvist.

IPFS fue propuesto originalmente por Juan Benet con el propósito de intentar construir un sistema de datos científicos versionados que pueda moverse rápidamente. El control de versiones le permite rastrear el estado del software a lo largo del tiempo (similar a Git). Desde entonces, IPFS se ha considerado una Web distribuida y permanente. "IPFS es un sistema de archivos distribuido diseñado para conectar todos los dispositivos informáticos con el mismo sistema de archivos. De alguna manera, es similar a la dirección original de la Web, pero de hecho es más similar a un solo grupo de bittorrent (bitstream) que intercambia Objetos Git. IPFS puede convertirse en un nuevo subsistema importante de Internet en el futuro. Si se construye con éxito, podrá complementar o reemplazar HTTP, e incluso reemplazar más. Suena loco, es una locura ".

El núcleo de IPFS es un sistema de archivos versionado, puede obtener archivos y administrarlos, también puede almacenarlos en una dirección determinada y luego rastrear la versión a lo largo del tiempo. IPFS también considera cómo estos archivos se mueven a través de la red, por lo que también es un sistema de archivos distribuido.

Inserte la descripción de la imagen aquí
IPFS tiene reglas similares a bittorrent sobre cómo se mueven los datos y el contenido en la red. La capa del sistema de archivos proporciona propiedades muy interesantes, como:

-Un sitio web completamente distribuido
- Un sitio web sin un servidor de origen -Un sitio web que
se puede ejecutar completamente en el navegador del cliente
-No hay un sitio web de servidor con el que hablar

Direccionamiento de contenido

IPFS no se refiere a objetos (imágenes, artículos, videos) a través del servidor donde se almacenan los objetos, sino que se refiere a todo el contenido a través del hash del archivo. El principio es que si desea visitar una página específica en un navegador, IPFS preguntará a toda la red "¿Alguien posee el archivo correspondiente a este hash?" Un nodo en IPFS puede devolver el archivo para que pueda acceder a él.

IPFS utiliza direccionamiento de contenido en la capa HTTP. Esta es una convención, crearemos alguna representación del contenido en sí, en lugar de crear un identificador que ubique las cosas por ubicación. Esto significa que el contenido determinará la dirección. El mecanismo consiste en obtener un archivo y luego aplicar un hash de forma cifrada, de modo que pueda obtener una representación muy pequeña y segura del archivo, lo que garantiza que alguien no pueda simplemente sacar otro con el mismo valor de hash. archivo y utilícelo como una dirección. La dirección de un archivo en IPFS generalmente comienza con un hash que identifica el objeto raíz y luego una ruta que se mueve hacia abajo. Está hablando con un objeto específico en lugar de hablar con el servidor, puede ver la ruta dentro de ese objeto.

HTTP vs IPFS buscar y recuperar archivos

HTTP tiene una propiedad agradable, donde el identificador es la ubicación, por lo que es fácil encontrar la computadora que aloja el archivo y hablar con ella. Esto es útil y generalmente funciona bien, pero no se puede usar en situaciones fuera de línea o en grandes esquemas distribuidos donde desea minimizar la carga en toda la red.

En IPFS, los pasos se pueden dividir en dos partes: use el direccionamiento de contenido para identificar el archivo, para encontrarlo; cuando tenga el valor hash, le preguntará a la red conectada "¿quién es el propietario de este contenido? (Hash)", y luego Conéctese al nodo correspondiente y descargue. El resultado es una cobertura de punto a punto, que puede proporcionarle un enrutamiento muy rápido.

Inserte la descripción de la imagen aquí
02 ejemplo de IPFS

La inspección técnica y el sistema de archivos interplanetario (IPFS) son una combinación de tecnologías de Internet probadas, como DHT, sistema de versión Git y Bittorrent. Crea un grupo P2P que puede intercambiar objetos IPFS. El número total de objetos IPFS forma una estructura de datos encriptada y verificada llamada Merkle DAG, que se puede utilizar para modelar muchas otras estructuras de datos. En este artículo presentaremos los objetos IPFS y Merkle DAG, y proporcionaremos ejemplos estructurales que se pueden modelar utilizando IPFS.

Objetos IPFS

IPFS es esencialmente un sistema P2P para recuperar y compartir objetos IPFS. El objeto IPFS es una estructura de datos con dos campos:

Datos: blobs de datos binarios no estructurados de menos de 256 kb de tamaño.
Enlaces: una serie de estructuras de enlaces, estos son enlaces a otros objetos IPFS.

La estructura del enlace tiene tres campos de datos:

Name: el nombre del enlace.
Hash: el hash del objeto IPFS vinculado.
Tamaño: el tamaño acumulativo del objeto IPFS vinculado, incluida la posición que sigue a su vínculo.

Este campo de tamaño se usa principalmente para optimizar redes P2P, y básicamente lo ignoraremos aquí, porque conceptualmente hablando, no es necesario para estructuras lógicas.

Los objetos IPFS suelen ser referenciados por su hash codificado en Base58. Por ejemplo, usemos la herramienta de línea de comandos IPFS para ver el objeto IPFS con el hash QmarHSr9aSNaPSR6G9KFPbuLV9aEqJfTk1y9B8pdwqK4Rq (pruébelo en casa):

Los lectores pueden notar que todos los hashes comienzan con "Qm". Esto se debe a que el hash es en realidad multihash, lo que significa que el hash en sí mismo especifica la función hash y la longitud del hash en los dos primeros bytes de multihash. En el ejemplo anterior, los primeros dos bytes de hexadecimal son 1220, donde 12 significa que esta es la función hash SHA256 y 20 significa la longitud del hash (en bytes), que es 32 bytes.

Los datos y los enlaces con nombre proporcionan la estructura del Merkle DAG para la recopilación de objetos IPFS: DAG significa gráfico acíclico dirigido y Merkle significa una estructura de datos cifrada y autenticada que utiliza hashes cifrados para procesar contenido. Este es un ejercicio que le queda al lector para que piense por qué no puede haber ciclos en este gráfico.

Para visualizar la estructura del gráfico, usaremos un gráfico para visualizar el objeto IPFS. El gráfico contiene los datos en los nodos. Los enlaces se dirigen a los bordes del gráfico de otros objetos IPFS, donde el nombre del enlace es una etiqueta en el borde del gráfico. El ejemplo anterior es el siguiente:

Ahora ilustraremos las diversas estructuras de datos que pueden ser representadas por objetos IPFS.

Sistema de archivos

IPFS puede representar fácilmente un sistema de archivos compuesto por archivos y directorios.

Archivo pequeño

Un archivo pequeño (<256 kB) está representado por un objeto IPFS. Los datos son el contenido del archivo (más un pequeño encabezado y pie de página). No hay enlace, es decir, la matriz de enlaces está vacía. Tenga en cuenta que el nombre del archivo no forma parte del objeto IPFS, por lo que dos archivos con nombres diferentes y el mismo contenido tendrán la misma representación del objeto IPFS y, por lo tanto, el mismo valor hash.

Podemos usar el comando ipfs para agregar un pequeño archivo a IPFS:

Podemos usar ipfs cat para ver el contenido del archivo del objeto IPFS anterior:

Utilice objetos ipfs para ver la infraestructura y obtener beneficios:

Visualizamos el archivo de la siguiente manera:

Archivo grande

Los archivos grandes (> 256 kB) se representan mediante una lista enlazada de bloques de archivos de menos de 256 kB, y solo los datos más pequeños especifican que este objeto representa un archivo grande. El nombre del enlace al bloque de archivos es una cadena vacía.

Estructura de directorios

Un directorio está representado por una lista de enlaces que apuntan a objetos IPFS que representan archivos u otros directorios. El nombre del enlace es el nombre del archivo y el directorio. Por ejemplo, considere la siguiente estructura de directorio del directorio test_dir:

Los archivos hello.txt y my_file.txt contienen la cadena Hello World! \ n. El archivo testing.txt contiene la cadena Testing 123 \ n.

Al representar esta estructura de directorio como un objeto IPFS, se ve así:

Tenga en cuenta que contiene Hello World! \ nEl archivo se deduplica automáticamente, \ n, los datos en el archivo solo se almacenan en una ubicación lógica en IPFS (direccionado por su dirección hash).

La herramienta de línea de comandos IPFS puede seguir sin problemas el nombre del enlace del directorio para recorrer el sistema de archivos:

Sistema de archivos de versión

IPFS puede representar la estructura de datos utilizada por Git para sistemas de archivos versionados. El objeto de confirmación de Git se describe en el Libro de Git. En el momento de redactar este documento, la estructura de los objetos de presentación de IPFS aún no se ha especificado completamente y las discusiones aún están en curso.

El atributo principal del objeto de envío es que tiene uno o más enlaces con nombres de parent0, parent1, etc., que apuntan al envío anterior, y tiene un enlace al objeto de nombre (llamado árbol en Git), que apunta a el archivo al que hace referencia la estructura del sistema de objetos.

Tomemos la estructura de directorios del sistema de archivos anterior y dos envíos como ejemplo: el primer envío es la estructura original, y en el segundo envío, hemos actualizado el archivo my_file.txt para representar otro mundo, no el original "¡Hola mundo!" .

También tenga en cuenta que tenemos deduplicación automática, por lo que los nuevos objetos en el segundo envío son solo el directorio de inicio, el nuevo directorio my_dir y el archivo actualizado my_file.txt.

Inserte la descripción de la imagen aquí
03 cadena de bloques

Este es uno de los casos de uso más interesantes de IPFS. La cadena de bloques tiene una estructura DAG natural, porque los bloques pasados ​​siempre están vinculados por el valor hash de sus bloques sucesores. Las cadenas de bloques más avanzadas, como la cadena de bloques Ethereum, también tienen una base de datos de estado asociada, que tiene una estructura de árbol Merkle-Patricia y también se puede simular utilizando objetos IPFS.

Asumimos un modelo de cadena de bloques simple, donde cada bloque contiene los siguientes datos:

La lista de objetos de transacción;
el enlace al bloque anterior;
el hash del árbol / base de datos de estado.

Luego, la cadena de bloques se puede modelar en IPFS de la siguiente manera:

Al colocar la base de datos de estado en IPFS, vimos los beneficios de la deduplicación: entre dos bloques, solo los elementos de estado modificados deben almacenarse explícitamente.

El punto interesante aquí es la diferencia entre almacenar datos en la cadena de bloques y almacenar datos hash en la cadena de bloques. En la plataforma Ethereum, debe pagar una tarifa considerable para almacenar datos en la base de datos de estado asociada para minimizar la expansión de la base de datos de estado (expansión de blockchain). Por lo tanto, este es un patrón de diseño común, es decir, los datos más grandes no almacenan los datos en sí, sino un hash IPFS de los datos en la base de datos del estado.

Si una cadena de bloques con una base de datos de estado relacionada ya está representada en IPFS, la diferencia entre almacenar hashes en la cadena de bloques y almacenar datos en la cadena de bloques se vuelve un poco borrosa, porque todo es igual de todos modos. Almacenado en IPFS, y solo el hash del Se necesita un bloque para codificar la base de datos de estado. En este caso, si alguien almacena un enlace IPFS en la cadena de bloques, podemos seguir el enlace sin problemas para acceder a los datos, al igual que los datos se almacenan en la propia cadena de bloques.

Sin embargo, todavía podemos distinguir entre el almacenamiento de datos dentro y fuera de la cadena. Hacemos esto observando con qué debe lidiar el minero al crear un nuevo bloque. En la red Ethereum actual, los mineros necesitan procesar transacciones que actualizarán la base de datos de estado, para ello, necesitan acceder a la base de datos de estado completa para poder actualizarla en cualquier lugar después del cambio.

Por lo tanto, en la base de datos de estado de la cadena de bloques representada por IPFS, todavía necesitamos marcar los datos como "en cadena" o "fuera de cadena". Para los mineros, los datos "en cadena" son esenciales para la minería local, y estos datos se verán afectados directamente por las transacciones. Los usuarios deberán actualizar los datos "fuera de la cadena" y los mineros no tendrán que tocarlos.

Supongo que te gusta

Origin blog.csdn.net/weixin_49795899/article/details/114695080
Recomendado
Clasificación