filefilego
v1.4.3
O Protocolo FileFilego é uma rede de armazenamento e compartilhamento de dados ponto a ponto projetada para a era da Web3, com um mecanismo de incentivo, pesquisa de texto completo e um mecanismo de armazenamento. Sua arquitetura descentralizada permite que os usuários armazenem e compartilhem dados sem censura ou um único ponto de falha. Ao alavancar os conceitos da teoria dos jogos, o FileFilego incentiva a participação e garante a disponibilidade de dados enquanto atinge a tolerância a falhas e preservando a privacidade.
O FileFilego é um projeto comunitário de código aberto, sem controle ou propriedade centralizada. Sua distribuição de moedas foi projetada para ser justa, com uma emissão de 40 FFG por bloco que diminui pela metade a cada 24 meses. O protocolo é lançado sem OCO/STO/IEO ou pré-mina, contando com um algoritmo de consenso de prova de autoridade que acabará por fazer a transição para a prova de participação para permitir que mais partes interessadas participem.
Ao apoiar o FileFilego, os usuários podem ajudar a promover direitos digitais, privacidade, liberdade de informação e neutralidade da rede. Incentivamos contribuições e idéias inovadoras para garantir que a Internet continue sendo uma plataforma aberta e descentralizada.
Suponhamos que node_1 precise baixar alguns data_x , de propriedade do node_2 , e pagar pelas taxas exigidas pelo node_2 . O que acontece no caso de nós de falha bizantina? Como verificamos a transferência de dados bem -sucedida para os nós de destino e impedimos os seguintes casos maliciosos:
node_1 é um nó desonesto que relata data_x como inválido, para evitar pagar as taxas.node_2 é um nó desonesto que serve data_y para node_1 e afirma que é data_x . A rede pode resistir a falhas bizantinas se node_x puder transmitir (ponto a ponto) um valor x e satisfazer o seguinte:
node_x for um nó honesto, todos os nós honestos concordaram com o valor x. O mecanismo de prova de transferência aborda os problemas acima mencionados, permitindo que nós honestos na rede verifiquem e atinjam o consenso sobre a transferência bem -sucedida de data_x de node_2 para node_1 . Isso é realizado através do uso de verificadores, responsáveis por desafiar nós participantes. Embora uma abordagem direta envolvesse o envio dos dados necessários para um verificador e, em seguida, encaminhe -os para o nó de destino, esse método pode levar à largura de banda e gargalos de armazenamento, reduzindo assim a taxa de transferência de rede geral. Portanto, a solução de prova de transferência foi projetada para minimizar os requisitos de largura de banda e armazenamento/memória associados a esse processo.
┌───────────┐
┌────────►[verifiers]◄─────────┐
│ └───────────┘ │
┌────┴───┐ ┌────┴───┐
│ │ │ │
│ node_1 ◄─────────────────────► node_2 │
│ │ │ │
└────────┘ ├────────┤
│ data_x │
└────────┘
Deixar
Divida o conteúdo do arquivo
Calcule o hash da árvore de Merkle dos segmentos: deixe
Embaralhar os segmentos: deixe
Criptografar 1 % dos segmentos embaralhados: deixe
Descriptografia de segmentos criptografados: para cada um dos
Restaurando a ordem embaralhada: como os segmentos foram embaralhados durante o processo de criptografia, eles precisam ser restaurados ao seu pedido original usando a permutação inversa
Cálculo de hash de árvores de merkle: recalcule o hash da árvore de merkle dos segmentos descriptografados na ordem restaurada. Construa a árvore de hash de maneira semelhante à construção original, mas use os segmentos descriptografados
Finalmente, o hash original derivado da raiz Merkle
O consenso é alcançado se o hash da raiz de Merkle derivado corresponder ao hash original da raiz Merkle.
Considere um cenário envolvendo um arquivo que contém o conteúdo subsequente:
FileFileGo_Network
Ao fazer o upload de um arquivo para um provedor de armazenamento, o hash da raiz Merkle do arquivo é calculado através da segmentação de seu conteúdo em segmentos de dados distintos.
A ilustração que se seguiu mostra uma manifestação simplificada do arranjo do arquivo no meio de armazenamento. Cada caixa individual dentro da ilustração simboliza 1 byte de dados.
┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┐
│ F │ i │ l │ e │ F │ i │ l │ e │ G │ o │ _ │ N │ e │ t │ w │ o │ r │ k │
└───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┘
Para encontrar o hash da raiz Merkle deste arquivo, dividimos o arquivo em peças menores. Por exemplo, vamos dividir o arquivo em nove seções, e cada parte terá apenas dois 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 │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
Agora tomamos o 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
e então calculamos o hash da raiz Merkle do arquivo aplicando o algoritmo.
Aqui está um exemplo de como esse algoritmo opera:
┌───┬───┬───┬───┬───┬───┬───┬───┐
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))
Agora, possuímos um hash de raiz Merkle para o arquivo, representado como MT (F), que é essencialmente outro valor de hash.
Quando uma solicitação para recuperar dados atinge um provedor de armazenamento, o provedor reorganiza os segmentos de dados em uma ordem aleatória. Por exemplo, considere a sequência de segmentos de dados:
random segments [ 1, 5, 2, 4, 7, 6, 3, 0, 8 ] , que se traduz no seguinte arranjo:
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, o provedor gera um vetor de chave simétrica e inicialização (iv) para criptografar uma parte desses segmentos. Nesta ilustração, optaremos por criptografar 25% dos segmentos, o que equivale a 2 segmentos. Além disso, criptografaremos a cada 4 segmentos, implicando que criptografaremos os 0º e 4º segmentos:
25% Segment Encryption = 2 segments
┌───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ l e │ _ N │ F i │ * * │ w o │ e t │ l e │ * * │ r k │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
Agora, os dados acima mencionados serão fornecidos ao solicitante de dados. Simultaneamente, a chave/IV, a ordem randomizada dos segmentos e o conteúdo dos segmentos 0 e 4 são transmitidos ao data verifier . É importante destacar que o downloader possui Zero-Knowledge sobre a ordem dos segmentos dentro do arquivo e a chave de criptografia/IV.
Você pode estar preocupado com a possibilidade de alguém criar um script para tentar várias combinações de segmentos para determinar a ordem original, potencialmente levando a uma vulnerabilidade de segurança e um possível ataque.
Para fornecer mais informações, considere que um arquivo é dividido em aproximadamente 1024 segmentos (ou um pouco menos) em um cenário do mundo real, e esses segmentos são randomizados. Para um invasor reconstruir a ordem do segmento original, ele precisaria realizar uma "permutação sem repetição". A contagem total de maneiras de organizar esses segmentos de arquivo é dada por n! (Fatorial), que equivale a 1024! neste caso. (https://coolconversion.com/math/factorial/what-is-the-fatorial-of_1024_%3f)
A etapa subsequente do invasor envolve tentar adquirir a chave e o IV usado para criptografar os dois segmentos. No entanto, vale a pena notar que essa tarefa é atualmente considerada impossível com base nas vulnerabilidades existentes no campo.
Depois disso, o download do arquivo deve solicitar a chave de criptografia/IV e a ordem randomizada dos segmentos de arquivo de um data verifier designado dentro da rede.
O download de dados envia uma solicitação ao verificador de dados, buscando a chave de criptografia/IV e os segmentos randomizados. Esta solicitação é acompanhada pelos hashes do segmento do arquivo baixado, que são apresentados da seguinte forma:
h1
h5
h2
h(enc(4))
h7
h6
h3
h(enc(0))
h8
O data verifier realiza criptografia e hash para os segmentos 0 e 4, resultando nos seguintes valores de hash:
h1
h5
h2
h4
h7
h6
h3
h0
h8
Por fim, o data verifier reorganiza os segmentos de acordo com a ordem randomizada gerada pelo arquivo de arquivo durante a transferência de dados para o solicitante. Este processo produz a sequência original de hashes de segmento:
h0
h1
h2
h3
h4
h5
h6
h7
h8
Por fim, através da execução do computação de hash da raiz Merkle, o verificador de dados deduz o hash da raiz Merkle original sem necessidade de acesso local completo ao conteúdo inteiro do arquivo.
Ao confirmar que o hash derivado da raiz Merkle corresponde ao original, estabelecemos efetivamente uma prova matemática de que o download de dados possui todos os dados solicitados. Posteriormente, o verificador de dados transmite a chave de criptografia/IV e a ordem dos segmentos randomizados para o download de dados, levando à liberação automática de taxas no arquivo.
Nesta seção, o ciclo de vida completo de uma verificação de transferência de dados é demonstrado.
1. Data Query Request
┌───────┐
┌───────────────►[nodes]├───────────────┐
│ └───────┘ │
┌───┴────┐ ┌────▼───┐
│ │ │ │
│ node_1 │ │ node_2 │
│ │ │ │
└───▲────┘ └───┬────┘
│ 2. Data Query Response │
└──────────────────────────────────────┘
Data Query Response contém todas as informações necessárias para preparar uma transação de contrato inteligente. Essa transação é então transmitida para a rede que é então selecionada por um 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 com os nós participantes e gera um desafio para o nó que hospeda os dados ( node_2 ). O desafio consiste nas seguintes etapas:node_2 deve criar uma árvore Merkle que corresponda à raiz Merkle original de data_x carregada em primeiro lugar.v1 decide o pedido e o número de blocos/faixas de dados a serem enviadas para node_1 por node_2 . Ainda não queremos revelar a ordem dos blocos para node_1 .v1 solicita node_2 para uma gama fixa de dados, que será criptografada usando uma chave aleatória k1 como data_enc por v1 e enviada para node_1 . Nesse estágio, node_1 possui alguns data_z e data_enc , mas não possui o conhecimento de como combiná -los para obter o arquivo original. O verificador, V1, é capaz de verificar a integridade dos dados transmitidos ao node_1 e, se eles corresponderem à identidade da Merkle Tree original, a chave de descriptografia K1 é fornecida ao node_1 . Além disso, a ordem do bloco é enviada para node_1 , permitindo a remontagem de todas as partes para formar os dados originais. Depois que esse processo estiver concluído, a V1 libera as taxas para node_2 .
O uso desse algoritmo permite a obtenção simultânea de prova de transferência e prova de posse de dados.
Siga as instruções para compilar e instalar o FileFilego
https://filefilego.com/documentation/docs/installation.html#prerequisites
O FileFilego é uma rede descentralizada que incorpora a robustez da tecnologia inovadora de Blockchain/Cryptocurrency, e a tecnologia inovadora da BitTorrent para formar uma infraestrutura inatacável.
Para atingir um tempo de bloqueio de 10 segundos, o FileFilego requer um algoritmo de consenso que seja eficiente no processamento de um alto volume de transações e conserva o poder de processamento. Para a fase inicial, selecionamos a prova de autoridade (POA) como nosso algoritmo de consenso. No futuro, um mecanismo de Prova de Estaca (POS) substituirá o algoritmo atual.
O uso de algoritmos baseados em prisioneiros de guerra para novas blockchains representa um risco, pois já existem conjuntos substanciais de energia de computação disponíveis que podem ser usados para 51% de ataques. Portanto, optamos pelo POA, que é seguro pelo design e fornece a eficiência necessária para apoiar nossos requisitos de alto volume de transações.
As identidades dos validadores são codificadas na blockchain e podem ser verificadas examinando a transação de moeda do Genesis Block. Os nós participantes podem verificar facilmente a autenticidade dessas identidades verificando as assinaturas do bloco.
À medida que avançamos, o mecanismo POA atual será substituído pela prova de participação para permitir que várias partes participem do processo de mineração de blocos. Nosso objetivo para a governança de blockchain é incentivar mais partes e desenvolvedores a se envolver e aumentar o envolvimento das partes interessadas. Um dos incentivos para atingir esse objetivo é o mecanismo de prova de participação.
Para simplificar a transação e a mutação do estado, o FileFilego adota uma abordagem diferente das estruturas do tipo UTXO. Em vez de usar essas estruturas, armazenamos contabilidade e metadados como linhas regulares de banco de dados, mantendo os blocos brutos em seu formato original no banco de dados. Essa abordagem ajuda a eliminar a complexidade desnecessária.
Nesta seção, forneceremos uma visão geral dos termos e conceitos técnicos usados no FileFilego.
Os canais no FileFilego permitem que os usuários organizem e agrupem dados em baldes ou pastas distintas. Por exemplo, todo o conteúdo do Ubuntu.com pode ser colocado em um canal chamado "Official do Ubuntu". O usuário que cria um canal recebe todas as permissões necessárias para atualizações e outras operações relacionadas ao canal.
Os canais são estruturados em um formato de cadeia de nó e podem ser identificados como um nó sem ParentHash .
O conceito de sub-canal é poder categorizar ainda mais os dados. Por exemplo, documentos, fotos ou música.
No FileFilego, uma Entry representa uma postagem ou uma peça de dados que contém mais informações sobre a entrada em si, em vez de categorização/ordenação. File e Directory podem ser colocados em uma Entry .
Storage Engine é a camada de armazenamento que rastreia dados binários, que são usados por hash ponteiros dentro da blockchain para se referir a uma peça de dados. A estrutura NodeItem possui um campo chamado FileHash , que se refere ao hash binário e está na forma de "{HASH_ALGORITHM}:>{DATA_HASH}" . Gostaríamos de manter os metadados do algoritmo de hash usado, pois pode ser útil no futuro.
No FileFilego, a precisão e a flexibilidade da pesquisa são igualmente importantes como a funcionalidade Blockchain Core. Nosso objetivo é permitir que os usuários construam consultas complexas, incluindo pesquisas binárias, usando uma linguagem de consulta específica. Por exemplo, as consultas dos seguintes tipos devem ser possíveis:
O desenvolvimento de uma linguagem de consulta que suporta consultas tão complexas é uma ferramenta poderosa que pode melhorar significativamente a precisão do mecanismo de pesquisa.
Também é possível ativar a funcionalidade de indexação de texto completo de um nó usando o sinalizador-CLI- --search .
A camada de armazenamento acompanha os arquivos binários e usa hashes para representar uma informação dentro da blockchain. Esse recurso pode ser ativado usando os seguintes sinalizadores:
... --storage --storage_dir="/somewhere/to/store/data" --storage_token="somelongtokenhere" --storage_fees_byte="10000" ...
--storage_dir deve ser um diretório que exista com permissões de leitura/gravação apropriadas. Observe que nós completos podem funcionar sem esse mecanismo. storage_token é um token que concede direitos de administrador a um token para que possa criar outros tokens usando a API HTTP. Isso é útil quando o direito de acesso é necessário por aplicativos da Web ou usuários distintos e --storage_fees_byte="10000" são as taxas cobradas por byte de dados.
| Unidade | Valor |
|---|---|
| Ffgone | 1 |
| Kffg | 1.000 |
| Mffg | 1.000.000 |
| Gffg | 1.000.000.000 |
| Microffg | 1.000.000.000.000 |
| Miliffg | 1.000.000.000.000.000 |
| FFG (unidade padrão) | 1.000.000.000.000.000.000 |
| Zffg | 1.000.000.000.000.000.000.000 |
Fornecimento total: 500 milhões de validação/participação da FFG Recompensa: 40 FFG por suprimento de bloco Taxa de redução: Divida por 2 a cada 24 meses
