filefilego
v1.4.3
Le protocole FileFileGo est un réseau de stockage et de partage de données entre pairs conçu pour l'ère Web3, avec un mécanisme d'incitation, une recherche en texte intégral et un moteur de stockage. Son architecture décentralisée permet aux utilisateurs de stocker et de partager des données sans censure ou un seul point de défaillance. En tirant parti des concepts de théorie du jeu, FileFileGo incite la participation et assure la disponibilité des données tout en atteignant la tolérance aux pannes et la préservation de la confidentialité.
FileFileGo est un projet communautaire open source, sans contrôle ni propriété centralisé. Sa distribution de pièces est conçue pour être juste, avec une émission de 40 FFG par bloc qui diminue de moitié tous les 24 mois. Le protocole est lancé sans ICO / STO / IEO ou pré-mine, en s'appuyant sur un algorithme de consensus de preuve d'autorité qui passera éventuellement à une preuve de participation pour permettre à plus de parties prenantes de participer.
En prenant en charge FileFileGo, les utilisateurs peuvent aider à promouvoir les droits numériques, la confidentialité, la liberté d'information et la neutralité du Net. Nous encourageons les contributions et les idées innovantes pour nous assurer que Internet reste une plate-forme ouverte et décentralisée.
Supposons que node_1 ait besoin de télécharger certaines data_x , appartenant à node_2 , et de payer les frais requis par node_2 . Que se passe-t-il dans le cas des nœuds de faille byzantins? Comment vérifier le transfert de données réussi vers les nœuds de destination et empêcher les cas malveillants suivants:
node_1 est un nœud malhonnête qui rapporte data_x comme invalide, pour éviter de payer les frais.node_2 est un nœud malhonnête qui sert data_y à node_1 et affirme qu'il s'agit data_x . Le réseau peut résister aux défauts byzantins si node_x peut diffuser (peer-to-peer) une valeur x, et satisfaire ce qui suit:
node_x est un nœud honnête, tous les nœuds honnêtes s'accordent sur la valeur x. La preuve du mécanisme de transfert aborde les problèmes susmentionnés en permettant aux nœuds honnêtes du réseau de vérifier et d'atteindre un consensus sur le transfert réussi de data_x de node_2 à node_1 . Ceci est accompli grâce à l'utilisation de vérificateurs, qui sont responsables de la défaite des nœuds participants. Bien qu'une approche simple impliquerait d'envoyer les données requises à un vérificateur, puis de la transmettre au nœud de destination, cette méthode peut entraîner la bande passante et les goulots d'étranglement de stockage, réduisant ainsi le débit global du réseau. Par conséquent, la solution de preuve de transfert a été conçue pour minimiser les exigences de bande passante et de stockage / mémoire associées à ce processus.
┌───────────┐
┌────────►[verifiers]◄─────────┐
│ └───────────┘ │
┌────┴───┐ ┌────┴───┐
│ │ │ │
│ node_1 ◄─────────────────────► node_2 │
│ │ │ │
└────────┘ ├────────┤
│ data_x │
└────────┘
Laisser
Divisez le contenu du fichier
Calculez le hachage de l'arbre Merkle des segments: laissez
Mélanger les segments: laissez
Crypter 1% des segments mélangés: laissez
Décription des segments cryptés: pour chacun des
Restauration de l'ordre mélangé: Étant donné que les segments ont été mélangés pendant le processus de chiffrement, ils doivent être restaurés à leur ordre d'origine en utilisant la permutation inverse
Calcul du hachage de Merkle Tree: Recalculez le hachage de l'arbre Merkle des segments décryptés dans l'ordre restauré. Construisez l'arbre de hachage de manière similaire à la construction d'origine, mais utilisez les segments décryptés
Enfin, le hachage racine Merkle original dérivé
Le consensus est obtenu si le hachage racine Merkle dérivé correspond au hachage racine Merkle d'origine.
Considérez un scénario impliquant un fichier contenant le contenu ultérieur:
FileFileGo_Network
Lors du téléchargement d'un fichier sur un fournisseur de stockage, le hachage racine Merkle du fichier est calculé via la segmentation de son contenu en segments de données distincts.
L'illustration qui a suivi représente une manifestation simplifiée de la disposition du fichier sur le support de stockage. Chaque boîte individuelle dans l'illustration symbolise 1 octet de données.
┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┐
│ F │ i │ l │ e │ F │ i │ l │ e │ G │ o │ _ │ N │ e │ t │ w │ o │ r │ k │
└───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┘
Pour trouver le hachage racine de Merkle de ce fichier, nous divisons le fichier en parties plus petites. Par exemple, divisons le fichier en neuf sections, et chaque pièce n'aura que deux octets.
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 │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
Maintenant, nous prenons le hachage de chaque segment:
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
Et puis nous calculons le hachage racine Merkle du fichier en appliquant l'algorithme.
Voici un exemple de fonctionnement de cet algorithme:
┌───┬───┬───┬───┬───┬───┬───┬───┐
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))
Maintenant, nous possédons un hachage racine Merkle pour le fichier, représenté comme MT (F), qui est essentiellement une autre valeur de hachage.
Lorsqu'une demande de récupération des données atteint un fournisseur de stockage, le fournisseur réorganise les segments de données dans un ordre aléatoire. Par exemple, considérez la séquence des segments de données:
random segments [ 1, 5, 2, 4, 7, 6, 3, 0, 8 ] , ce qui se traduit par l'arrangement suivant:
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 │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
Par la suite, le fournisseur génère une clé symétrique et un vecteur d'initialisation (IV) pour crypter une partie de ces segments. Dans cette illustration, nous opterons pour crypter 25% des segments, ce qui équivaut à 2 segments. De plus, nous crypterons tous les 4 segments, ce qui implique que nous crypterons les 0e et 4e segments:
25% Segment Encryption = 2 segments
┌───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ l e │ _ N │ F i │ * * │ w o │ e t │ l e │ * * │ r k │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
Maintenant, les données susmentionnées seront fournies au demandeur de données. Simultanément, la clé / IV, l'ordre randomisé des segments et le contenu des segments 0 et 4 sont transmis au data verifier . Il est important de souligner que le téléchargeur possède Zero-Knowledge concernant à la fois l'ordre des segments dans le fichier et la clé de chiffrement / IV.
Vous pourriez être préoccupé par la possibilité que quelqu'un crée un script pour tenter diverses combinaisons de segments pour déterminer l'ordre d'origine, conduisant potentiellement à une vulnérabilité de sécurité et à une attaque potentielle.
Pour fournir des informations supplémentaires, considérez qu'un fichier est divisé en environ 1024 segments (ou légèrement moins) dans un scénario du monde réel, et ces segments sont ensuite randomisés. Pour qu'un attaquant reconstruit l'ordre du segment d'origine, il devrait effectuer une «permutation sans répétition». Le nombre total de façons d'organiser ces segments de fichiers est donné par N! (factoriel), qui s'élève à 1024! Dans ce cas. (https://coolconversion.com/math/factorial/what-is-the-factorial-of_1024_%3f)
L'étape ultérieure de l'attaquant consiste à tenter d'acquérir la clé et IV utilisées pour chiffrer les deux segments. Cependant, il convient de noter que cette tâche est actuellement considérée comme impossible en fonction des vulnérabilités existantes sur le terrain.
Suite à cela, le téléchargeur de fichiers doit demander la clé de chiffrement / IV et l'ordre randomisé des segments de fichiers d'un data verifier désigné dans le réseau.
Le téléchargeur de données envoie une demande au vérificateur de données, à la recherche de la clé de chiffrement / IV et des segments randomisés. Cette demande est accompagnée des hachages de segment du fichier téléchargés, qui sont présentés comme suit:
h1
h5
h2
h(enc(4))
h7
h6
h3
h(enc(0))
h8
Le data verifier entreprend le chiffrement et le hachage pour les segments 0 et 4, ce qui entraîne les valeurs de hachage suivantes:
h1
h5
h2
h4
h7
h6
h3
h0
h8
Enfin, le data verifier réorganise les segments en fonction de l'ordre randomisé généré par le fichier Hoster lors du transfert de données vers le demandeur. Ce processus donne la séquence d'origine des hachages de segment:
h0
h1
h2
h3
h4
h5
h6
h7
h8
En fin de compte, grâce à l'exécution du Merkle Root Hash Computation, le vérificateur de données déduit le hachage racine Merkle d'origine sans nécessiter un accès local complet à l'ensemble du contenu de fichier.
En confirmant que le hachage racine de Merkle dérivé correspond à celui d'origine, nous avons effectivement établi une preuve mathématique que le téléchargeur de données possède toutes les données demandées. Par la suite, le vérificateur de données transmet la clé de chiffrement / IV et l'ordre des segments randomisés au téléchargeur de données, conduisant à la version automatique des frais au fichier Hoster.
Dans cette section, le cycle de vie complet d'une vérification de transfert de données est démontré.
1. Data Query Request
┌───────┐
┌───────────────►[nodes]├───────────────┐
│ └───────┘ │
┌───┴────┐ ┌────▼───┐
│ │ │ │
│ node_1 │ │ node_2 │
│ │ │ │
└───▲────┘ └───┬────┘
│ 2. Data Query Response │
└──────────────────────────────────────┘
Data Query Response contient toutes les informations nécessaires pour préparer une transaction de contrat intelligent. Cette transaction est ensuite diffusée sur le réseau qui est ensuite sélectionné par un vérificateur. ┌──────────────────────────────────────┐
│ TRANSACTION │
├──────────────────────────────────────┤
│ Data : │
│ - Data query response │
│ - Remote node signature │
│ Value: │
│ - Fees required by node │
│ │
│ Fees : │
│ - Fees collected by verifier │
│ │
│ To : │
│ - Network verifier │
└──────────────────────────────────────┘
v1 ) communique avec les nœuds participants et génère un défi pour le nœud qui héberge les données ( node_2 ). Le défi se compose des étapes suivantes:node_2 devrait créer un arbre Merkle qui correspond à la racine Merkle d'origine de data_x téléchargée en premier lieu.v1 décide l' ordre et le nombre de plages de blocs / données à envoyer à node_1 par node_2 . Nous ne voulons pas encore révéler l'ordre des blocs à node_1 .v1 demande node_2 une plage fixe de données, qui sera chiffrée à l'aide d'une clé aléatoire k1 en tant que data_enc par v1 et envoyée à node_1 . À ce stade, node_1 possède certains data_z et data_enc mais ne fait pas savoir comment les combiner pour obtenir le fichier d'origine. Le vérificateur, V1, est en mesure de vérifier l'intégrité des données transmises à node_1 et, s'ils correspondent à l'identité de l'arbre Merkle d'origine, la clé de décryptage K1 est fournie à node_1 . De plus, l'ordre de bloc est envoyé à node_1 , permettant le remontage de toutes les pièces pour former les données d'origine. Une fois ce processus terminé, V1 libère les frais de node_2 .
L'utilisation de cet algorithme permet la réalisation simultanée de la preuve de transfert et la preuve de possession de données.
Suivez les instructions pour compiler et installer FileFileGo
https://filefilego.com/documentation/docs/installation.html#prerequisites
FileFilego est un réseau décentralisé qui intègre la robustesse de la blockchain / crypto-monnaie, DHT et la technologie innovante de BitTorrent pour former une infrastructure inattaquable.
Pour obtenir un temps de bloc de 10 secondes, FileFileGo nécessite un algorithme de consensus qui est à la fois efficace dans le traitement d'un volume élevé de transactions et conserve la puissance de traitement. Pour la phase initiale, nous avons sélectionné la preuve d'autorité (POA) comme algorithme de consensus. À l'avenir, un mécanisme de preuve de participation (POS) remplacera l'algorithme actuel.
L'utilisation d'algorithmes basés sur des POW pour les nouvelles blockchains présente un risque, car il existe déjà des pools de puissance de calcul substantiels disponibles qui pourraient être utilisés pour 51% d'attaques. Par conséquent, nous avons opté pour POA, qui est sûr par conception et fournit l'efficacité nécessaire pour soutenir nos exigences de volume de transaction élevées.
Les identités des validateurs sont codées en dur dans la blockchain et peuvent être vérifiées en examinant la transaction Coinbase du bloc Genesis. Les nœuds participants peuvent facilement vérifier l'authenticité de ces identités en vérifiant les signatures du bloc.
Au fur et à mesure que nous avançons, le mécanisme POA actuel sera remplacé par une preuve de mise en place pour permettre à plusieurs parties de participer au processus d'extraction de bloc. Notre objectif pour la gouvernance de la blockchain est d'encourager davantage de parties et de développeurs à s'impliquer et à accroître l'engagement des parties prenantes. L'une des incitations pour atteindre cet objectif est le mécanisme de la preuve de mise.
Pour simplifier la transaction et la mutation de l'état, FileFileGo adopte une approche différente de celle des structures de type UTXO. Plutôt que d'utiliser de telles structures, nous stockons la comptabilité et les métadonnées comme des lignes de base de données régulières, tout en conservant les blocs bruts dans leur format d'origine dans la base de données. Cette approche aide à éliminer la complexité inutile.
Dans cette section, nous fournirons un aperçu des termes et concepts techniques utilisés dans FileFileGo.
Les canaux de FileFileGo permettent aux utilisateurs d'organiser et de regrouper les données en seaux ou dossiers distincts. Par exemple, tout le contenu sur ubuntu.com pourrait être placé dans une chaîne nommée "Ubuntu Official". L'utilisateur qui crée un canal reçoit toutes les autorisations nécessaires aux mises à jour et autres opérations liées aux canaux.
Les canaux sont structurés dans un format de chaîne de nœud et peuvent être identifiés comme un nœud sans ParentHash .
Le concept d'un sous-canal est de pouvoir classer encore plus les données. Par exemple, des documents, des images ou de la musique.
Dans FileFileGo, une Entry représente un poste ou un élément de données qui contient plus d'informations sur l'entrée elle-même plutôt que sur la catégorisation / la commande. File et Directory peuvent être placés dans une Entry .
Storage Engine est la couche de stockage qui suit les données binaires, qui sont utilisées par des pointeurs de hachage dans la blockchain pour désigner un élément de données. La structure NodeItem a un champ appelé FileHash qui fait référence au hachage binaire et est sous la forme de "{HASH_ALGORITHM}:>{DATA_HASH}" . Nous aimerions conserver les métadonnées de l'algorithme de hachage utilisés car il pourrait être utile à l'avenir.
Dans FileFileGo, la précision et la flexibilité de la recherche sont tout aussi importantes que la fonctionnalité principale de la blockchain. Nous visons à permettre aux utilisateurs de construire des requêtes complexes, y compris des recherches binaires, en utilisant un langage de requête spécifique. Par exemple, les requêtes des types suivantes devraient être possibles:
Développer un langage de requête qui prend en charge ces requêtes complexes est un outil puissant qui peut améliorer considérablement la précision du moteur de recherche.
Il est également possible d'activer les fonctionnalités d'indexation de texte intégral d'un nœud à l'aide de l'indicateur CLI --search .
La couche de stockage garde une trace des fichiers binaires et utilise des hachages pour représenter une information dans la blockchain. Cette fonction peut être activée en utilisant les indicateurs suivants:
... --storage --storage_dir="/somewhere/to/store/data" --storage_token="somelongtokenhere" --storage_fees_byte="10000" ...
--storage_dir devrait être un répertoire qui existe avec les autorisations de lecture / écriture appropriées. Veuillez noter que les nœuds complets peuvent fonctionner sans ce mécanisme. storage_token est un jeton qui accorde des droits d'administration sur un jeton afin qu'il puisse créer d'autres jetons à l'aide de l'API HTTP. Ceci est utile lorsque l'accès est nécessaire par les applications Web ou les utilisateurs distincts et --storage_fees_byte="10000" est les frais facturés par octet de données.
| Unité | Valeur |
|---|---|
| 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 (unité par défaut) | 1.000.000.000.000.000.000 |
| Zffg | 1.000.000.000.000.000.000.000 |
Offre totale: 500 millions de FFG Validation / Récompense de pieu: 40 FFG par bloc d'alimentation Taux de diminution: diviser par 2 tous les 24 mois
