Sistema de arquivos distribuído IPFS e FileCoin

Sistema de arquivos distribuído IPFS e FileCoin

Neste artigo, quero falar sobre o recentemente popular IPFS (InterPlanetary File System), um sistema de arquivos distribuído ponto a ponto; mais de meio século se passou desde o surgimento do protocolo HTTP, e há poucos projetos que podem Aprimore toda a rede HTTP ou traga novos recursos para ela.

Insira a descrição da imagem aqui

Usar o protocolo HTTP para transferir arquivos relativamente pequenos é realmente muito barato e conveniente, mas com o crescimento exponencial dos recursos de computação e espaço de armazenamento, estamos enfrentando o problema de precisar obter uma grande quantidade de dados a qualquer momento, e o IPFS deve resolver esse problema.

Projeto de arquitetura

Como um sistema de arquivos distribuído, o IPFS fornece uma plataforma que suporta implantação e gravação, bem como a distribuição e gerenciamento de versão de arquivos grandes. Para atingir o objetivo acima, o protocolo IPFS é dividido nos seguintes subprotocolos:

Insira a descrição da imagem aqui
Os sete subprotocolos acima são responsáveis ​​por diferentes funções no IPFS. Nos capítulos seguintes, apresentaremos o que cada protocolo faz e como o IPFS é implementado.

Identidade

Na rede IPFS, todos os nós são identificados por um NodeId exclusivo, que é um tanto semelhante ao endereço Bitcoin. Na verdade, é um hash de uma chave pública. No entanto, para aumentar o custo do invasor, o IPFS usa S / Kademlia conforme mencionado O algoritmo aumenta o custo de criação de uma nova identidade:

difficulty = <integer parameter>
n = Node{
    
    }
do {
    
    
  n.PubKey, n.PrivKey = PKI.genKeyPair()
  n.NodeId = hash(n.PubKey)
  p = count_preceding_zero_bits(hash(n.NodeId))
} while (p < difficulty)

Cada nó é representado pela estrutura Node no código IPFS , que contém apenas o NodeId e um par de chaves pública e privada:

type NodeId Multihash
type Multihash []byte
type PublicKey []byte
type PrivateKey []byte

type Node struct {
    
    
  NodeId NodeId
  PubKey PublicKey
  PriKey PrivateKey
}

Resumindo, a principal função do sistema de identidade é representar cada nó na rede IPFS e representar cada "usuário" usando IPFS.

A Internet

Como um sistema de armazenamento distribuído, a comunicação e a transferência de informações entre os nós precisam ser realizadas através da rede, podendo usar uma variedade de protocolos da camada de transporte e garantir confiabilidade, conectividade, integridade das informações e autenticidade.

Insira a descrição da imagem aqui

O IPFS pode usar qualquer rede para se comunicar. Não pressupõe que deva ser executado no protocolo IP, mas usa o formato de multiaddr para indicar o endereço de destino e o protocolo usado, de modo a ser compatível e expandir outros protocolos de rede que possam surgir no futuro:

/ip4/10.20.30/40/sctp/1234/
/ip4/5.6.7.8/tcp/5678/ip4/1.2.3.4/sctp/1234/

roteamento

Em um sistema distribuído, um sistema de roteamento é necessário para recuperar ou acessar recursos armazenados em outros nós. IPFS usa DSHT baseado em S / Kademlia e Coral para implementar um sistema de roteamento. Podemos usar libp2p / go-libp2p-routing Encontre a interface do sistema de roteamento IPFS em /routing.go:

type IpfsRouting interface {
    
    
	ContentRouting
	PeerRouting
	ValueStore

	Bootstrap(context.Context) error
}

type ContentRouting interface {
    
    
	Provide(context.Context, *cid.Cid, bool) error
	FindProvidersAsync(context.Context, *cid.Cid, int) <-chan pstore.PeerInfo
}

type PeerRouting interface {
    
    
	FindPeer(context.Context, peer.ID) (pstore.PeerInfo, error)
}

type ValueStore interface {
    
    
	PutValue(context.Context, string, []byte) error
	GetValue(context.Context, string) ([]byte, error)
	GetValues(c context.Context, k string, count int) ([]RecvdVal, error)
}

A partir daqui, podemos ver que o roteamento em IPFS precisa implementar três funções básicas, roteamento de conteúdo, roteamento de nó e armazenamento de dados. O "roteador" que implementa essas interfaces pode ser substituído na camada inferior sem afetar o trabalho de outras partes do sistema. Atualmente, o IPFS usa DHT e DNS globais para resolver registros de roteamento, enquanto Kademlia DHT tem as seguintes vantagens:

  1. Encontre o endereço de destino rapidamente em nós de lote, a complexidade de tempo é log 2 (n) log_2 (n)l o g2( n ) , ou seja, apenas 20 consultas são necessárias em 10.000.000 de nós;
  2. Otimize o comprimento da mensagem de controle entre os nós e reduza o custo de coordenação de informações;
  3. Resista a vários ataques de rede selecionando preferencialmente nós de longo prazo;
  4. É amplamente utilizado em aplicações ponto a ponto, como BitTorrent e Gnutella, e a tecnologia é relativamente madura;

Troca de dados

No IPFS, a distribuição e troca de dados usa o protocolo BitSwap, que é responsável por duas coisas: solicitar os blocos necessários de outros nós e fornecer blocos para outros nós.

Insira a descrição da imagem aqui

Quando precisarmos solicitar Block de outros nós ou fornecer Block para outros nós, enviaremos uma mensagem BitSwap, que contém principalmente duas partes: lista de desejos do remetente e bloco de dados. Toda a mensagem é codificada usando Protobuf :

message Message {
    
    
  message Wantlist {
    
    
    message Entry {
    
    
      optional string block = 1; // the block key
      optional int32 priority = 2; // the priority (normalized). default to 1
      optional bool cancel = 3;  // whether this revokes an entry
    }

    repeated Entry entries = 1; // a list of wantlist entries
    optional bool full = 2;     // whether this is the full wantlist. default to false
  }

  optional Wantlist wantlist = 1;
  repeated bytes blocks = 2;
}

No sistema BitSwap, existem dois gerenciadores de requisitos de módulo muito importantes (Want-Manager) e mecanismo de decisão (Decision-Engine); o primeiro retornará o bloco correspondente localmente quando o nó solicitar um bloco ou emitir uma solicitação adequada, e o último Decida como alocar recursos para outros nós. Quando um nó recebe uma mensagem contendo Lista de Desejos, a mensagem será encaminhada para o mecanismo de decisão, e o mecanismo decidirá como processar a solicitação com base no Razão do nó.

Os leitores que desejam saber mais sobre os detalhes de implementação de BitSwap e Spec podem ler outros conteúdos de BitSwap Spec.

Além de definir as mensagens enviadas entre os nós, o IPFS também introduz incentivos e penalidades para garantir que não haverá nós "maliciosos" em toda a rede. O razão é usado para armazenar trocas de dados entre dois nós:

type Ledger struct {
    
    
    owner      NodeId
    partner    NodeId
    bytes_sent int
    bytes_recv int
    timestamp  Timestamp
}

O mecanismo de decisão irá calcular um índice de dívida por meio do razão entre os dois nós:

O índice de endividamento é usado para medir a confiança entre os nós. Ele pode não apenas evitar que invasores criem um grande número de nós, mas também proteger os relacionamentos de transação existentes quando os nós ficarem indisponíveis por um curto período de tempo e encerrar as transações antes que os relacionamentos dos nós se deteriorem.

O IPFS usa o Ledger para criar uma rede com incentivos e penalidades para garantir que a maioria dos nós da rede possa trocar dados e operar normalmente.

Sistema de arquivo

O DHT e o BitSwap permitem que o IPFS construa um grande sistema ponto a ponto para armazenar e distribuir blocos de dados; além disso, o IPFS constrói um Merkle DAG, cada objeto IPFS pode conter um conjunto de links e dados no nó atual:

type IPFSLink struct {
    
    
    Name string
    Hash Multihash
    Size int
}
type IPFSObject struct {
    
    
    links []IPFSLink
    data []byte
}

Podemos usar o seguinte comando para listar todos os links sob o objeto:

$ ipfs ls QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG
QmZTR5bcpQD7cFgTorqxZDYaew1Wqgfbd2ud9QqGPAkK2V 1688 about
QmYCvbfNbCwFR45HiNP45rwJgvatpiW38D961L5qAhUM5Y 200  contact
QmY5heUM5qgRubMDD1og9fhCPA6QdkMp3QCwd4s7gJsyE7 322  help
QmdncfsVm2h5Kqq9hPmU7oAVX2zTSVP3L869tgTbPYnsha 1728 quick-start
QmPZ9gcCEpqKTo6aq61g2nXGUhM4iCL3ewB6LDXZCtioEB 1102 readme
QmTumTjvcYCAvRRwQ8sDRxh8ezmrcr88YFU7iYNroGGTBZ 1027 security-notes

Os dados originais mais links universais são a base para a construção de qualquer estrutura de dados no IPFS. Armazenamento de valores-chave, bancos de dados relacionais tradicionais e blockchains criptografados podem ser armazenados e distribuídos no Merkle DAG do IPFS.

Além disso, o IPFS define uma série de objetos para construir um sistema de arquivos que suporte controle de versão, que é muito semelhante ao modelo de objeto do Git, e todos os objetos de arquivo são, na verdade, codificados em binário por meio do Protobuf:

Insira a descrição da imagem aqui

Os arquivos IPFS podem ser representados por listas e blobs:

  • O blob não contém links, apenas dados;
  • Mas a lista contém uma fila ordenada de blobs e listas
  • O objeto de arquivo de árvore é muito semelhante à árvore no Git, ele representa um diretório de arquivo do nome ao hash;
  • O commit final representa um instantâneo de qualquer objeto;
    Insira a descrição da imagem aqui

No gráfico de objeto de arquivo acima, o commit de nível superior representa um certo instantâneo histórico. Comparar a árvore formada pelos dois commits e os nós filhos pode obter a diferença entre os dois instantâneos. Podemos pensar que Merkle DAG e o objeto de arquivo constituem Todo o sistema de arquivos em IPFS.

Sistema de nomenclatura

Até agora, a pilha de tecnologia IPFS forneceu um sistema de troca de dados ponto a ponto que pode enviar objetos DAG entre nós e pode enviar e recuperar objetos imutáveis, mas o sistema de nomenclatura de variável também é uma parte indispensável da rede. Afinal, precisamos usar o mesmo endereço para obter diferentes status, porque o nome de domínio não pode ser alterado devido a atualizações do site, então o IPFS precisa fornecer um "serviço de nome de domínio" para resolver este problema.

Os seguintes namespaces de variáveis ​​podem ser usados ​​no IPFS para resolver esses problemas. Um usuário pode publicar um objeto e outros nós podem acessar esses objetos publicados na rede por meio de ipns mais o endereço de nó do usuário:

/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm/

Claro, também podemos adicionar registros TXT ao sistema DNS existente, para que possamos acessar os objetos de arquivo publicados na rede IPFS através do nome de domínio:

ipfs.benet.ai. TXT "ipfs=XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm"

/ipns/XLF2ipQ4jD3UdeX5xp1KBgeHRhemUtaA8Vm
/ipns/ipfs.benet.ai

No IPFS, os hashes não apenas podem ser usados ​​para acessar objetos variáveis, mas também podem ser incorporados aos serviços DNS existentes para funcionar bem, resolvendo o problema de comutação contínua de serviços subjacentes.

excitação

Hoje, quando discutimos a tecnologia de blockchain subjacente de IPFS, temos que mencionar FileCoin construído em IPFS, que fornece um mercado para hosts e uploaders negociarem, através do qual o custo de armazenamento pode ser ajustado, upload O usuário pode escolher velocidade, redundância e custo com base no preço.

A maioria das redes de blockchain tem apenas um único tipo de nó padrão, mas existem dois nós diferentes no FileCoin: nós de armazenamento e nós de recuperação.

Insira a descrição da imagem aqui

Todos podem se tornar um nó de armazenamento, alugando espaço de armazenamento adicional em seus próprios discos. A FileCoin usará esses discos para armazenar parte de alguns arquivos criptografados menores; enquanto os nós de recuperação precisam estar o mais próximo possível de mais nós de armazenamento, e também precisam Com maior largura de banda e menor latência, os usuários pagarão pelo nó de recuperação que retorna o arquivo mais rápido.

Quando queremos fazer upload de um arquivo, precisamos pagar uma determinada taxa de armazenamento. O nó de armazenamento fornecerá uma cotação para o direito de armazenar o arquivo. FileCoin irá selecionar o nó de armazenamento com o menor preço para salvar o arquivo; o arquivo armazenado será criptografado e dividido em várias partes E enviado para vários nós, a localização do arquivo será armazenada na tabela global, após a qual apenas o nó com a chave privada pode consultar, montar e descriptografar o arquivo carregado.

Algoritmo de consenso

Podemos dizer que todos os aplicativos de blockchain requerem algoritmos de consenso para garantir que vários nós cheguem a um consenso sobre um determinado resultado e resolvam conflitos. Bitcoin e Ethereum atualmente usam Proof-of-Work como o algoritmo de consenso, enquanto FileCoin Use Proof-of-Replication (PoRep) para resolver os problemas internos de sua rede.

Introduzimos esquemas de Prova de Replicação (PoRep), que permitem a um provador P (a) comprometer-se a armazenar n réplicas distintas (cópias fisicamente independentes) de D, e então (b) convencer um verificador V de que P está de fato armazenando cada uma das réplicas.

PoRep permite que o experimentador P para enviar e armazenar n cópias diferentes de D, e, em seguida, convencer o verificador V P que tenham sido gravados estas cópias.

No artigo Prova de Replicação, você pode encontrar algoritmos de consenso, como PoRep e PoS (Prova de Armazenamento), que são usados ​​para verificar se o provedor de espaço em disco realmente armazena recursos. Não os apresentarei aqui.

Resumindo

IPFS é uma tecnologia subjacente de blockchain muito interessante. Ele implementa um sistema de armazenamento de arquivos ponto a ponto baseado na compatibilidade com os protocolos de Internet existentes e propõe uma solução para armazenamento de big data. O autor experimentou o cliente IPFS oficial go- O ipfs é de fato mais fácil de usar, mas também está nos estágios iniciais do projeto. Muitos módulos e funções ainda não foram finalizados, e o FileCoin baseado em IPFS não tem uma Prova de Replicação de log exata a ser lançada. Este white paper também está marcado como WIP (Trabalho Em processamento), algumas partes não foram concluídas, por isso leva muito tempo para aguardar a maturidade desta tecnologia.

Acho que você gosta

Origin blog.csdn.net/uucckk/article/details/103816567
Recomendado
Clasificación