filefilego
v1.4.3
Protokol FileFilego adalah jaringan penyimpanan & pembagian data peer-to-peer yang dirancang untuk era Web3, dengan mekanisme insentif, pencarian teks lengkap, dan mesin penyimpanan. Arsitekturnya yang terdesentralisasi memungkinkan pengguna untuk menyimpan dan berbagi data tanpa sensor atau satu titik kegagalan. Dengan memanfaatkan konsep teori permainan, FileFilego memberi insentif kepada partisipasi dan memastikan ketersediaan data saat mencapai toleransi kesalahan dan menjaga privasi.
FileFilego adalah proyek komunitas open-source, tanpa kontrol atau kepemilikan terpusat. Distribusi koinnya dirancang agar adil, dengan emisi 40 FFG per blok yang berkurang setengahnya setiap 24 bulan. Protokol diluncurkan tanpa ICO/STO/IEO atau pra-tambang, mengandalkan bukti algoritma konsensus otoritas yang pada akhirnya akan beralih ke bukti saham untuk memungkinkan lebih banyak pemangku kepentingan untuk berpartisipasi.
Dengan mendukung FileFilego, pengguna dapat membantu mempromosikan hak digital, privasi, kebebasan informasi, dan netralitas bersih. Kami mendorong kontribusi dan ide -ide inovatif untuk memastikan bahwa Internet tetap merupakan platform yang terbuka dan terdesentralisasi.
Mari kita anggap bahwa node_1 perlu mengunduh beberapa data_x , dimiliki oleh node_2 , dan membayar biaya yang diperlukan oleh node_2 . Apa yang terjadi dalam kasus node patahan Bizantium? Bagaimana kami memverifikasi transfer data yang berhasil ke node tujuan dan mencegah kasus jahat berikut:
node_1 adalah simpul yang tidak jujur yang melaporkan data_x tidak valid, untuk menghindari membayar biaya.node_2 adalah simpul yang tidak jujur yang melayani data_y ke node_1 dan mengklaim bahwa itu adalah data_x . Jaringan dapat menahan kesalahan Bizantium jika node_x dapat menyiarkan (peer-to-peer) nilai x, dan memenuhi yang berikut:
node_x adalah simpul yang jujur, maka semua node yang jujur menyetujui nilai x. Bukti mekanisme transfer membahas masalah -masalah yang disebutkan di atas dengan mengaktifkan node jujur dalam jaringan untuk memverifikasi dan mencapai konsensus tentang keberhasilan transfer data_x dari node_2 ke node_1 . Ini dicapai melalui penggunaan verifikasi, yang bertanggung jawab untuk menantang node yang berpartisipasi. Sementara pendekatan langsung akan melibatkan pengiriman data yang diperlukan ke verifier dan kemudian meneruskannya ke node tujuan, metode ini dapat menyebabkan kemacetan bandwidth dan penyimpanan, sehingga mengurangi keseluruhan throughput jaringan. Oleh karena itu, bukti solusi transfer telah dirancang untuk meminimalkan persyaratan bandwidth dan penyimpanan/memori yang terkait dengan proses ini.
┌───────────┐
┌────────►[verifiers]◄─────────┐
│ └───────────┘ │
┌────┴───┐ ┌────┴───┐
│ │ │ │
│ node_1 ◄─────────────────────► node_2 │
│ │ │ │
└────────┘ ├────────┤
│ data_x │
└────────┘
Membiarkan
Bagilah konten file
Hitung hash pohon merkle dari segmen: biarkan
Kocok segmen: biarkan
Mengenkripsi 1 persen dari segmen yang dikocok: biarkan
Dekripsi segmen terenkripsi: untuk masing -masing
Memulihkan urutan yang dikocok: Karena segmen -segmen itu dikocok selama proses enkripsi, mereka perlu dipulihkan ke urutan aslinya menggunakan permutasi terbalik
Perhitungan Hash Pohon Merkle: Hitung ulang hash pohon merkle dari segmen yang didekripsi dalam urutan yang dipulihkan. Bangun pohon hash mirip dengan konstruksi asli, tetapi gunakan segmen yang didekripsi
Akhirnya, hash root merkle asli yang diturunkan
Konsensus dicapai jika hash root merkle yang diturunkan cocok dengan hash root merkle asli.
Pertimbangkan skenario yang melibatkan file yang berisi konten selanjutnya:
FileFileGo_Network
Setelah mengunggah file ke penyedia penyimpanan, hash root merkle dari file dihitung melalui segmentasi kontennya menjadi segmen data yang berbeda.
Ilustrasi berikutnya menggambarkan manifestasi yang disederhanakan dari pengaturan file pada media penyimpanan. Setiap kotak individu dalam ilustrasi melambangkan 1 byte data.
┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┐
│ F │ i │ l │ e │ F │ i │ l │ e │ G │ o │ _ │ N │ e │ t │ w │ o │ r │ k │
└───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┘
Untuk menemukan hash root merkle dari file ini, kami memecah file menjadi bagian yang lebih kecil. Misalnya, mari kita pisahkan file menjadi sembilan bagian, dan masing -masing bagian hanya akan memiliki dua byte.
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 │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
Sekarang kami mengambil hash dari setiap segmen:
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
Dan kemudian kami menghitung hash root merkle dari file dengan menerapkan algoritma.
Berikut adalah contoh bagaimana algoritma ini beroperasi:
┌───┬───┬───┬───┬───┬───┬───┬───┐
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))
Sekarang, kami memiliki hash root merkle untuk file tersebut, diwakili sebagai Mt (f), yang pada dasarnya adalah nilai hash lain.
Ketika permintaan untuk mengambil data mencapai penyedia penyimpanan, penyedia mengatur ulang segmen data dalam urutan acak. Misalnya, pertimbangkan urutan segmen data:
random segments [ 1, 5, 2, 4, 7, 6, 3, 0, 8 ] , yang diterjemahkan ke pengaturan berikut:
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 │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
Selanjutnya, penyedia menghasilkan kunci simetris dan vektor inisialisasi (IV) untuk mengenkripsi sebagian dari segmen -segmen ini. Dalam ilustrasi ini, kami akan memilih untuk mengenkripsi 25% dari segmen, yang setara dengan 2 segmen. Selain itu, kami akan mengenkripsi setiap 4 segmen, menyiratkan bahwa kami akan mengenkripsi segmen ke -0 dan ke -4:
25% Segment Encryption = 2 segments
┌───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ l e │ _ N │ F i │ * * │ w o │ e t │ l e │ * * │ r k │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
Sekarang, data yang disebutkan di atas akan diberikan kepada pemohon data. Secara bersamaan, kunci/IV, urutan acak segmen, dan isi segmen 0 dan 4 ditransmisikan ke data verifier . Penting untuk menyoroti bahwa pengunduh memiliki Zero-Knowledge mengenai urutan segmen dalam file dan kunci enkripsi/iv.
Anda mungkin khawatir tentang kemungkinan seseorang yang membuat skrip untuk mencoba berbagai kombinasi segmen untuk menentukan urutan asli, berpotensi mengarah ke kerentanan keamanan dan potensi serangan.
Untuk memberikan wawasan lebih lanjut, pertimbangkan bahwa file dibagi menjadi sekitar 1024 segmen (atau sedikit lebih sedikit) dalam skenario dunia nyata, dan segmen ini kemudian diacak. Agar penyerang merekonstruksi urutan segmen asli, mereka perlu melakukan "permutasi tanpa pengulangan." Total jumlah cara untuk mengatur segmen file ini diberikan oleh N! (faktorial), yang berjumlah 1024! dalam hal ini. (https://coolconversion.com/math/factorial/what-is-the-factorial-of_1024_%3f)
Langkah penyerang berikutnya melibatkan upaya untuk memperoleh kunci dan IV yang digunakan untuk mengenkripsi kedua segmen tersebut. Namun, perlu dicatat bahwa tugas ini saat ini dianggap mustahil berdasarkan kerentanan yang ada di lapangan.
Setelah ini, pengunduh file harus meminta kunci enkripsi/IV dan urutan acak segmen file dari data verifier yang ditunjuk dalam jaringan.
Pengunduh data mengirimkan permintaan ke verifikasi data, mencari kunci enkripsi/IV dan segmen acak. Permintaan ini disertai dengan hash segmen dari file yang diunduh, yang disajikan sebagai berikut:
h1
h5
h2
h(enc(4))
h7
h6
h3
h(enc(0))
h8
data verifier melakukan enkripsi dan hashing untuk segmen 0 dan 4, menghasilkan nilai hash berikut:
h1
h5
h2
h4
h7
h6
h3
h0
h8
Terakhir, data verifier mengatur ulang segmen sesuai dengan urutan acak yang dihasilkan oleh file hoster selama transfer data ke pemohon. Proses ini menghasilkan urutan asli hash segmen:
h0
h1
h2
h3
h4
h5
h6
h7
h8
Pada akhirnya, melalui pelaksanaan perhitungan hash root merkle, verifier data menyimpulkan hash root merkle asli tanpa memerlukan akses lokal lengkap ke seluruh konten file.
Setelah mengkonfirmasi bahwa hash root merkle yang diturunkan cocok dengan yang asli, kami telah secara efektif menetapkan bukti matematika bahwa pengunduh data memiliki semua data yang diminta. Selanjutnya, verifier data mentransmisikan kunci enkripsi/IV dan urutan segmen acak ke pengunduh data, yang mengarah ke pelepasan biaya otomatis ke file hoster.
Pada bagian ini, siklus hidup lengkap dari verifikasi transfer data ditunjukkan.
1. Data Query Request
┌───────┐
┌───────────────►[nodes]├───────────────┐
│ └───────┘ │
┌───┴────┐ ┌────▼───┐
│ │ │ │
│ node_1 │ │ node_2 │
│ │ │ │
└───▲────┘ └───┬────┘
│ 2. Data Query Response │
└──────────────────────────────────────┘
Data Query Response berisi semua informasi yang diperlukan untuk menyiapkan transaksi kontrak pintar. Transaksi ini kemudian disiarkan ke jaringan yang kemudian dipilih dengan verifier. ┌──────────────────────────────────────┐
│ TRANSACTION │
├──────────────────────────────────────┤
│ Data : │
│ - Data query response │
│ - Remote node signature │
│ Value: │
│ - Fees required by node │
│ │
│ Fees : │
│ - Fees collected by verifier │
│ │
│ To : │
│ - Network verifier │
└──────────────────────────────────────┘
v1 ) berkomunikasi dengan node yang berpartisipasi dan menghasilkan tantangan untuk node yang meng -host data ( node_2 ). Tantangannya terdiri dari langkah -langkah berikut:node_2 harus membuat pohon merkle yang cocok dengan root Merkle asli dari data_x yang diunggah di tempat pertama.v1 memutuskan pesanan dan jumlah blok/rentang data yang akan dikirim ke node_1 oleh node_2 . Kami belum ingin mengungkapkan urutan blok ke node_1 .v1 meminta node_2 untuk rentang data tetap, yang akan dienkripsi menggunakan kunci acak k1 sebagai data_enc oleh v1 dan dikirim ke node_1 . Pada tahap ini, node_1 memiliki beberapa data_z dan data_enc tetapi tidak memiliki pengetahuan tentang cara menggabungkannya untuk mendapatkan file asli. Verifier, V1, dapat memverifikasi integritas data yang ditransmisikan ke node_1 dan, jika mereka cocok dengan identitas pohon Merkle asli, kunci dekripsi K1 disediakan untuk node_1 . Selain itu, urutan blok dikirim ke node_1 , memungkinkan penyatuan kembali semua bagian untuk membentuk data asli. Setelah proses ini selesai, V1 melepaskan biaya ke node_2 .
Penggunaan algoritma ini memungkinkan pencapaian simultan bukti transfer dan bukti kepemilikan data.
Ikuti instruksi untuk mengkompilasi dan menginstal filefilego
https://filefilego.com/documentation/docs/installation.html#prerequisites
FileFilego adalah jaringan terdesentralisasi yang menggabungkan ketahanan blockchain/cryptocurrency, DHT, dan teknologi inovatif Bittorrent untuk membentuk infrastruktur yang tidak dapat disangkal.
Untuk mencapai waktu blok 10 detik, FileFilego memerlukan algoritma konsensus yang keduanya efisien dalam memproses volume transaksi yang tinggi dan menghemat daya pemrosesan. Untuk fase awal, kami telah memilih bukti otoritas (POA) sebagai algoritma konsensus kami. Di masa depan, mekanisme bukti (POS) akan menggantikan algoritma saat ini.
Menggunakan algoritma berbasis POW untuk blockchain baru menimbulkan risiko, karena sudah ada kumpulan daya komputasi yang tersedia yang dapat digunakan untuk 51% serangan. Oleh karena itu, kami telah memilih POA, yang aman berdasarkan desain dan memberikan efisiensi yang diperlukan untuk mendukung persyaratan volume transaksi kami yang tinggi.
Identitas validator dimodelkan ke dalam blockchain dan dapat diverifikasi dengan memeriksa transaksi koinbase blok Genesis. Node yang berpartisipasi dapat dengan mudah memverifikasi keaslian identitas ini dengan memeriksa tanda tangan blok.
Saat kami bergerak maju, mekanisme POA saat ini akan digantikan dengan bukti-t-taruhan untuk memungkinkan banyak pihak untuk berpartisipasi dalam proses penambangan blok. Tujuan kami untuk tata kelola blockchain adalah untuk mendorong lebih banyak pihak dan pengembang untuk terlibat dan meningkatkan keterlibatan pemangku kepentingan. Salah satu insentif untuk mencapai tujuan ini adalah mekanisme bukti-tisu.
Untuk menyederhanakan transaksi dan mutasi keadaan, FileFilego mengadopsi pendekatan yang berbeda dari struktur seperti Utxo. Daripada menggunakan struktur seperti itu, kami menyimpan akuntansi dan metadata sebagai baris basis data biasa, sambil mempertahankan blok mentah dalam format aslinya dalam database. Pendekatan ini membantu menghilangkan kompleksitas yang tidak perlu.
Di bagian ini, kami akan memberikan gambaran umum tentang istilah dan konsep teknis yang digunakan dalam filefilego.
Saluran di FileFilego memungkinkan pengguna untuk mengatur dan mengelompokkan data ke dalam ember atau folder yang berbeda. Misalnya, semua konten di ubuntu.com dapat ditempatkan di saluran bernama "Ubuntu Official." Pengguna yang membuat saluran menerima semua izin yang diperlukan untuk pembaruan dan operasi terkait saluran lainnya.
Saluran disusun dalam format rantai simpul dan dapat diidentifikasi sebagai simpul tanpa ParentHash .
Konsep sub-saluran adalah untuk dapat mengkategorikan data lebih jauh. Misalnya, dokumen, gambar, atau musik.
Dalam FileFilego, Entry mewakili pos atau sepotong data yang berisi lebih banyak informasi tentang entri itu sendiri daripada kategorisasi/pemesanan. File dan Directory dapat ditempatkan ke dalam Entry .
Storage Engine adalah lapisan penyimpanan yang melacak data biner, yang digunakan oleh pointer hash di dalam blockchain untuk merujuk pada sepotong data. Struktur NodeItem memiliki bidang yang disebut FileHash yang mengacu pada hash biner dan dalam bentuk "{HASH_ALGORITHM}:>{DATA_HASH}" . Kami ingin menjaga metadata algoritma hashing yang digunakan karena mungkin berguna di masa depan.
Dalam FileFilego, akurasi dan fleksibilitas pencarian sama pentingnya dengan fungsionalitas inti blockchain. Kami bertujuan untuk memungkinkan pengguna untuk membangun kueri yang kompleks, termasuk pencarian biner, menggunakan bahasa kueri tertentu. Misalnya, pertanyaan dari jenis berikut harus dimungkinkan:
Mengembangkan bahasa kueri yang mendukung kueri kompleks seperti itu adalah alat yang ampuh yang secara signifikan dapat meningkatkan akurasi mesin pencari.
Dimungkinkan juga untuk mengaktifkan fungsionalitas pengindeksan teks lengkap node menggunakan flag --search CLI.
Lapisan penyimpanan melacak file biner dan menggunakan hash untuk mewakili sepotong informasi di dalam blockchain. Fitur ini dapat dihidupkan dengan menggunakan bendera berikut:
... --storage --storage_dir="/somewhere/to/store/data" --storage_token="somelongtokenhere" --storage_fees_byte="10000" ...
--storage_dir harus menjadi direktori yang ada dengan izin baca/tulis yang sesuai. Harap dicatat bahwa node penuh dapat bekerja tanpa mekanisme ini. storage_token adalah token yang memberikan hak admin ke token sehingga dapat membuat token lain menggunakan HTTP API. Ini berguna ketika akses kanan diperlukan oleh aplikasi web atau pengguna yang berbeda dan --storage_fees_byte="10000" adalah biaya yang dibebankan per byte data.
| Satuan | Nilai |
|---|---|
| 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 default) | 1.000.000.000.000.000.000 |
| Zffg | 1.000.000.000.000.000.000.000.000 |
Total Pasokan: 500 juta FFG Validasi/Hadiah Saham: 40 FFG per blok Tingkat penurunan pasokan: Bagi dengan 2 setiap 24 bulan
