filefilego
v1.4.3
Das FileFileGo-Protokoll ist ein Peer-to-Peer-Speicher- und Daten-Sharing-Netzwerk, das für die Web3-Ära entwickelt wurde und einen Anreizmechanismus, eine Volltext-Suche und eine Speichermotor ist. Mit seiner dezentralen Architektur können Benutzer Daten ohne Zensur oder einen einzelnen Fehler speichern und teilen. Durch die Nutzung von Game-Theory-Konzepten wird der FileFileGo die Teilnahme angeregt und die Datenverfügbarkeit gewährleistet, gleichzeitig die Fehlertoleranz erreicht und die Privatsphäre erhalten.
FileFileGo ist ein Open-Source-Community-Projekt ohne zentralisierte Kontrolle oder Besitz. Die Münzverteilung ist so ausgelegt, dass er fair ist und eine Emission von 40 FFG pro Block, die alle 24 Monate um die Hälfte abnimmt. Das Protokoll wird ohne ICO/STO/IEO oder vor der Mine gestartet und stützt sich auf einen Beweis für den Konsens-Algorithmus des Autorität, der letztendlich zum Nachweis des Anteils übergeht, damit mehr Stakeholder teilnehmen können.
Durch die Unterstützung von FileFileGo können Benutzer dazu beitragen, digitale Rechte, Datenschutz, Informationsfreiheit und Netzneutralität zu fördern. Wir fördern Beiträge und innovative Ideen, um sicherzustellen, dass das Internet eine offene und dezentrale Plattform bleibt.
Nehmen wir an, dass node_1 einige data_x herunterladen muss, die node_2 im Besitz von NODE_2 sind, und die von node_2 erforderlichen Gebühren bezahlen müssen. Was passiert bei byzantinischen Verwerfungsknoten? Wie überprüfen wir die erfolgreiche Datenübertragung auf Zielknoten und verhindern die folgenden böswilligen Fälle:
node_1 ist ein unehrlicher Knoten, der data_x als ungültig meldet, um die Zahlung der Gebühren zu vermeiden.node_2 ist ein unehrlicher Knoten, der data_y zu node_1 dient und behauptet, dass es sich data_x handelt. Das Netzwerk kann byzantinischen Fehlern widerstehen, wenn node_x (Peer-to-Peer) einen Wert X übertragen und Folgendes erfüllen kann:
node_x ein ehrlicher Knoten ist, sind sich alle ehrlichen Knoten auf den Wert X einig. Der Nachweis des Übertragungsmechanismus befasst sich mit den oben genannten Problemen, indem er ehrliche Knoten im Netzwerk ermöglicht, den Konsens über die erfolgreiche Übertragung von data_x von node_2 nach node_1 zu überprüfen und zu erzielen. Dies wird durch die Verwendung von Verifikern erreicht, die für die herausfordernden teilnehmenden Knoten verantwortlich sind. Während ein unkomplizierter Ansatz das Senden der erforderlichen Daten an einen Verifizierer und dann an den Zielknoten weiterleitet, kann diese Methode zu Bandbreiten- und Speicher Engpässen führen, wodurch der Gesamtnetzwerkdurchsatz verringert wird. Daher wurde der Nachweis der Übertragungslösung entwickelt, um die mit diesem Prozess verbundenen Bandbreiten- und Speicher-/Speicheranforderungen zu minimieren.
┌───────────┐
┌────────►[verifiers]◄─────────┐
│ └───────────┘ │
┌────┴───┐ ┌────┴───┐
│ │ │ │
│ node_1 ◄─────────────────────► node_2 │
│ │ │ │
└────────┘ ├────────┤
│ data_x │
└────────┘
Lassen
Teilen Sie den Inhalt der Datei auf
Berechnen Sie den Merkle -Baumhash der Segmente: Lassen Sie
Mischen Sie die Segmente: Lassen Sie
Verschlüsseln Sie 1 Prozent der gemischten Segmente: Lassen Sie
Entschlüsselung verschlüsselter Segmente: für jeden der von
Wiederherstellung der gemischten Reihenfolge: Da die Segmente während des Verschlüsselungsprozesses gemischt wurden, müssen sie mit der inversen Permutation in ihre ursprüngliche Ordnung wiederhergestellt werden
Merkle Tree Hash -Berechnung: Berechnen Sie den Merkle -Baumhash der entschlüsselten Segmente in der wiederhergestellten Reihenfolge neu. Konstruieren Sie den Hash -Baum ähnlich wie die ursprüngliche Konstruktion, verwenden Sie jedoch die entschlüsselten Segmente
Schließlich hat der abgeleitete ursprüngliche Merkle Root Hash
Der Konsens wird erzielt, wenn der abgeleitete Merkle -Root -Hash mit dem ursprünglichen Merkle -Root -Hash übereinstimmt.
Betrachten Sie ein Szenario, in dem eine Datei mit dem nachfolgenden Inhalt enthält:
FileFileGo_Network
Beim Hochladen einer Datei in einen Speicheranbieter wird der Merkle -Root -Hash der Datei durch die Segmentierung seines Inhalts in verschiedene Datensegmente berechnet.
Die folgende Abbildung zeigt eine vereinfachte Manifestation der Anordnung der Datei auf dem Speichermedium. Jedes einzelne Box in der Abbildung symbolisiert 1 Daten Byte.
┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┐
│ F │ i │ l │ e │ F │ i │ l │ e │ G │ o │ _ │ N │ e │ t │ w │ o │ r │ k │
└───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┘
Um den Merkle -Root -Hash dieser Datei zu finden, unterbrechen wir die Datei in kleinere Teile. Lassen Sie uns beispielsweise die Datei in neun Abschnitte aufteilen, und jeder Teil hat nur zwei 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 │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
Jetzt nehmen wir den Hash jedes Segments:
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
Und dann berechnen wir den Merkle -Root -Hash der Datei, indem wir den Algorithmus anwenden.
Hier ist ein Beispiel dafür, wie dieser Algorithmus funktioniert:
┌───┬───┬───┬───┬───┬───┬───┬───┐
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))
Jetzt besitzen wir einen Merkle Root Hash für die Datei, das als MT (F) dargestellt wird, was im Wesentlichen ein weiterer Hash -Wert ist.
Wenn eine Anfrage zum Abrufen von Daten einen Speicheranbieter erreicht, ordnet der Anbieter die Datensegmente in einer zufälligen Reihenfolge um. Betrachten Sie beispielsweise die Abfolge von Datensegmenten:
random segments [ 1, 5, 2, 4, 7, 6, 3, 0, 8 ] , was die folgende Anordnung übersetzt:
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 │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
Anschließend erzeugt der Anbieter einen symmetrischen Schlüssel- und Initialisierungsvektor (IV), um einen Teil dieser Segmente zu verschlüsseln. In dieser Abbildung entscheiden wir uns für die Verschlüsselung von 25% der Segmente, was 2 Segmenten entspricht. Darüber hinaus verschlüsseln wir alle 4 Segmente, was impliziert, dass wir die 0. und 4. Segmente verschlüsseln werden:
25% Segment Encryption = 2 segments
┌───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ l e │ _ N │ F i │ * * │ w o │ e t │ l e │ * * │ r k │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
Jetzt werden die oben genannten Daten dem Datenanforderer zur Verfügung gestellt. Gleichzeitig werden der Schlüssel/IV, die randomisierte Reihenfolge der Segmente und der Inhalt der Segmente 0 und 4 an den data verifier übertragen. Es ist wichtig hervorzuheben, dass der Downloader in Bezug auf die Reihenfolge der Segmente innerhalb der Datei als auch in Bezug auf den Verschlüsselungsschlüssel/IV Zero-Knowledge besitzt.
Möglicherweise sind Sie besorgt über die Möglichkeit, dass jemand ein Skript erstellt, um verschiedene Kombinationen von Segmenten zu versuchen, um die ursprüngliche Ordnung zu bestimmen, was möglicherweise zu einer Sicherheitsanfälligkeit und einem potenziellen Angriff führt.
Um weitere Einblicke zu gewährleisten, sollten Sie in einem realen Szenario in ungefähr 1024 Segmente (oder etwas weniger) in ungefähr 1024 Segmente (oder etwas weniger) unterteilt sind, und diese Segmente werden dann randomisiert. Damit ein Angreifer die ursprüngliche Segmentordnung rekonstruieren kann, müssten sie eine "Permutation ohne Wiederholung" durchführen. Die Gesamtzahl der Möglichkeiten, diese Dateisegmente zu arrangieren, ist von n! (Faktor), die 1024 entspricht! In diesem Fall. (https://coolconversion.com/math/factorial/what-is-the-factorial-of_1024_%3f)
Der nachfolgende Schritt des Angreifers besteht darin, den Schlüssel zu erwerben, und IV, das zum Verschlüsseln der beiden Segmente verwendet wird. Es ist jedoch erwähnenswert, dass diese Aufgabe derzeit aufgrund bestehender Schwachstellen vor Ort als unmöglich angesehen wird.
Anschließend muss der Datei -Downloader den Verschlüsselungsschlüssel/IV und die randomisierte Reihenfolge der Dateisegmente aus einem festgelegten data verifier innerhalb des Netzwerks anfordern.
Der Daten -Downloader sendet eine Anfrage an den Datenüberprüfer und sucht den Verschlüsselungsschlüssel/IV und die randomisierten Segmente. Diese Anfrage wird von den Segmenthashes der heruntergeladenen Datei begleitet, die wie folgt dargestellt werden:
h1
h5
h2
h(enc(4))
h7
h6
h3
h(enc(0))
h8
Der data verifier übernimmt Verschlüsselung und Hashing für die Segmente 0 und 4, was zu den folgenden Hash -Werten führt:
h1
h5
h2
h4
h7
h6
h3
h0
h8
Zuletzt organisiert die data verifier die Segmente nach der randomisierten Reihenfolge, die von der Dateiwerbung während der Datenübertragung an den Antragsteller generiert wurde. Dieser Prozess liefert die ursprüngliche Abfolge von Segmenthashes:
h0
h1
h2
h3
h4
h5
h6
h7
h8
Durch die Ausführung der Merkle Root -Hash -Berechnung wird letztendlich der Datenprüfer den ursprünglichen Merkle -Root -Hash abgeleitet, ohne einen vollständigen lokalen Zugriff auf den gesamten Dateiinhalt zu erfordern.
Bei bestätigter Bestätigung, dass der abgeleitete Merkle Root Hash mit dem Original übereinstimmt, haben wir einen mathematischen Beweis ermittelt, dass der Daten -Downloader alle angeforderten Daten besitzt. Anschließend überträgt der Datenüberprüfer den Verschlüsselungsschlüssel/IV und die randomisierte Segmente in den Datendownloader, was zur automatischen Veröffentlichung der Gebühren an den Dateierheiger führt.
In diesem Abschnitt wird der vollständige Lebenszyklus einer Datenübertragungsüberprüfung nachgewiesen.
1. Data Query Request
┌───────┐
┌───────────────►[nodes]├───────────────┐
│ └───────┘ │
┌───┴────┐ ┌────▼───┐
│ │ │ │
│ node_1 │ │ node_2 │
│ │ │ │
└───▲────┘ └───┬────┘
│ 2. Data Query Response │
└──────────────────────────────────────┘
Data Query Response enthält alle Informationen, die zur Erstellung einer Smart -Vertrags -Transaktion erforderlich sind. Diese Transaktion wird dann in das Netzwerk ausgestrahlt, das dann von einem Verifizierer ausgewählt wird. ┌──────────────────────────────────────┐
│ TRANSACTION │
├──────────────────────────────────────┤
│ Data : │
│ - Data query response │
│ - Remote node signature │
│ Value: │
│ - Fees required by node │
│ │
│ Fees : │
│ - Fees collected by verifier │
│ │
│ To : │
│ - Network verifier │
└──────────────────────────────────────┘
v1 ) kommuniziert mit den teilnehmenden Knoten und generiert eine Herausforderung für den Knoten, der die Daten hostet ( node_2 ). Die Herausforderung besteht aus den folgenden Schritten:node_2 sollte einen Merkle -Baum erstellen, der dem ursprünglichen Merkle -Root von data_x entspricht, der überhaupt erst geladen wurde.v1 entscheidet über die Reihenfolge und die Anzahl der Blöcke/Datenbereiche , die von node_2 an node_1 gesendet werden sollen. Wir wollen die Reihenfolge der Blöcke noch nicht zu node_1 preisgeben.v1 fragt node_2 nach einem festen Datenbereich, der mit einem zufälligen Schlüssel k1 als data_enc von v1 verschlüsselt und an node_1 gesendet wird. In dieser Phase verfügt node_1 besitzt einige data_z und data_enc aber es fehlt das Wissen darüber, wie sie kombiniert werden, um die Originaldatei zu erhalten. Der Verifier V1 kann die Integrität der an node_1 übertragenen Daten überprüfen. Wenn sie mit der Identität des ursprünglichen Merkle -Baums übereinstimmen, wird der Entschlüsselungsschlüssel K1 node_1 zur Verfügung gestellt. Zusätzlich wird die Blockbestellung an node_1 gesendet, sodass die Zusammenbau aller Teile die Originaldaten bilden kann. Sobald dieser Vorgang abgeschlossen ist, gibt V1 die Gebühren an node_2 frei.
Die Verwendung dieses Algorithmus ermöglicht die gleichzeitige Erreichung des Übertragungsnachweises und des Besitzes des Datenbesitzes.
Befolgen Sie die Anweisungen zum Kompilieren und Installieren von FileFileGo
https://filefilego.com/documentation/docs/installation.html#prerequisites
FileFileGo ist ein dezentrales Netzwerk, das die Robustheit der innovativen Technologie von Blockchain/Kryptowährung, DHT und BitTorrent zur Bildung einer unangreifbaren Infrastruktur umfasst.
Um eine Blockzeit von 10 Sekunden zu erreichen, erfordert FileFileGo einen Konsensalgorithmus, der sowohl bei der Verarbeitung eines hohen Transaktionsvolumens effizient als auch die Verarbeitungsleistung effizient ist. Für die Anfangsphase haben wir den Nachweis der Autorität (POA) als unseren Konsensalgorithmus ausgewählt. In Zukunft wird ein Mechanismus des POS -Beweises (POS) den aktuellen Algorithmus ersetzen.
Die Verwendung von Pow-basierten Algorithmen für neue Blockchains stellt ein Risiko dar, da bereits erhebliche Rechenleistungspools zur Verfügung stehen, die für 51% -Angriffe verwendet werden könnten. Daher haben wir uns für POA entschieden, das durch Design sicher ist und die erforderliche Effizienz für unsere hohen Transaktionsvolumenanforderungen bietet.
Die Identitäten von Validatoren sind in der Blockchain festcodiert und können durch Untersuchung der Coinbase -Transaktion des Genesis Block verifiziert werden. Die teilnehmenden Knoten können die Authentizität dieser Identitäten leicht überprüfen, indem die Signaturen des Blocks überprüft werden.
Wenn wir uns vorwärts bewegen, wird der aktuelle POA-Mechanismus durch Proof-of-Stake ersetzt, damit mehrere Parteien am Blockabbauprozess teilnehmen können. Unser Ziel für die Blockchain -Governance ist es, mehr Parteien und Entwickler zu ermutigen, sich zu engagieren und das Engagement der Stakeholder zu erhöhen. Eines der Anreize für das Erreichen dieses Ziels ist der Mechanismus des Nachweises.
Um die Transaktion und die Zustandsmutation zu vereinfachen, verwendet FileFileGo einen anderen Ansatz als UTXO-ähnliche Strukturen. Anstatt solche Strukturen zu verwenden, speichern wir Buchhaltung und Metadaten als reguläre Datenbankzeilen, während wir die Rohblöcke in ihrem ursprünglichen Format in der Datenbank behalten. Dieser Ansatz hilft, unnötige Komplexität zu beseitigen.
In diesem Abschnitt geben wir einen Überblick über technische Begriffe und Konzepte, die in FileFileGo verwendet werden.
Mit Kanälen in FileFileGo können Benutzer Daten in unterschiedlichen Eimer oder Ordnern organisieren und gruppieren. Zum Beispiel könnten alle Inhalte auf Ubuntu.com in einem Kanal namens "Ubuntu Official" platziert werden. Der Benutzer, der einen Kanal erstellt hat, empfängt alle für Aktualisierungen und andere kanalbezogenen Vorgänge erforderlichen Berechtigungen.
Kanäle sind in einem Knotenkettigungsformat strukturiert und können als Knoten ohne ParentHash identifiziert werden.
Das Konzept eines Unterkanals besteht darin, Daten noch weiter zu kategorisieren. Zum Beispiel Dokumente, Bilder oder Musik.
In FileFileGo stellt ein Entry einen Beitrag oder ein Datenstück dar, der mehr Informationen über den Eintrag selbst als Kategorisierung/Bestellung enthält. File und Directory können in einen Entry eingegeben werden.
Storage Engine ist die Speicherschicht, die binäre Daten verfolgt, die von Hash -Zeigern innerhalb der Blockchain verwendet werden, um auf ein Datenstück zu verweisen. Die NodeItem -Struktur verfügt über ein Feld namens FileHash , das sich auf den binären Hash bezieht und in Form von "{HASH_ALGORITHM}:>{DATA_HASH}" ist. Wir möchten die Metadaten des Hashing -Algorithmus in Zukunft nützlich sein.
In FileFileGo sind die Suchgenauigkeit und Flexibilität gleichermaßen wichtig wie die Kernblockchain -Funktionalität. Wir wollen es Benutzern ermöglichen, komplexe Abfragen zu erstellen, einschließlich binärer Suchvorgänge, unter Verwendung einer bestimmten Abfragesprache. Beispielsweise sollten Abfragen der folgenden Typen möglich sein:
Die Entwicklung einer Abfragesprache, die solche komplexen Abfragen unterstützt, ist ein leistungsstarkes Tool, das die Genauigkeit der Suchmaschine erheblich verbessern kann.
Es ist auch möglich, die Volltextindizierungsfunktionen eines Knotens mithilfe des CLI- --search zu aktivieren.
Die Speicherebene verfolgt binäre Dateien und verwendet Hashes, um eine Information innerhalb der Blockchain darzustellen. Diese Funktion kann mit den folgenden Flags eingeschaltet werden:
... --storage --storage_dir="/somewhere/to/store/data" --storage_token="somelongtokenhere" --storage_fees_byte="10000" ...
--storage_dir sollte ein Verzeichnis sein, das mit geeigneten Lese-/Schreibberechtigungen existiert. Bitte beachten Sie, dass vollständige Knoten ohne diesen Mechanismus funktionieren können. storage_token ist ein Token, das ein Token für Verwaltungsrechte gewährt, damit es andere Token mithilfe der HTTP -API erstellen kann. Dies ist nützlich, wenn der Zugriff rechts von Web -Apps oder verschiedenen Benutzern benötigt wird. --storage_fees_byte="10000" sind die Gebühren, die gemäß Datenbyte geladen werden.
| Einheit | Wert |
|---|---|
| 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 (Standardeinheit) | 1.000.000.000.000.000.000 |
| Zffg | 1.000.000.000.000.000.000.000 |
Gesamtversorgung: 500 Millionen FFG -Validierung/Anteilbelohnung: 40 FFG pro Blockversorgungsrate: Dividen Sie alle 24 Monate um 2 Teilen um 2
