filefilego
v1.4.3
Протокол FileFilego-это одноранговая сеть хранения и обмена данными, предназначенная для эпохи Web3, с механизмом стимулирования, полнотекстовым поиском и двигателем хранения. Его децентрализованная архитектура позволяет пользователям хранить и обмениваться данными без цензуры или единой точки отказа. Используя концепции теории игр, FileFilego стимулирует участие и обеспечивает доступность данных при достижении сбоя и сохранения конфиденциальности.
FileFilego-это проект сообщества с открытым исходным кодом, без централизованного контроля или владения. Его распределение монет предназначено для того, чтобы быть справедливым, с выбросом 40 FFG на блок, который уменьшается наполовину каждые 24 месяца. Протокол запускается без ICO/STO/IEO или Pre-Mine, полагаясь на подтверждение алгоритма консенсуса власти, который в конечном итоге будет перейти к доказательству доктора, чтобы позволить больше заинтересованным сторонам участвовать.
Поддерживая FileFilego, пользователи могут помочь продвигать цифровые права, конфиденциальность, свободу информации и сетевой нейтралитет. Мы поощряем вклад и инновационные идеи для обеспечения того, чтобы Интернет оставался открытой и децентрализованной платформой.
Предположим, что node_1 должен загрузить некоторые data_x , принадлежащие node_2 , и оплатить плату, требуемую node_2 . Что происходит в случае византийских узлов разломов? Как мы проверяем успешную передачу данных в узлы назначения и предотвращаем следующие вредоносные случаи:
node_1 - это нечестный узел, который сообщает data_x как недействительный, чтобы избежать оплаты сборов.node_2 - это нечестный узел, который служит data_y node_1 и утверждает, что это data_x . Сеть может сопротивляться византийским разломам, если node_x может транслировать (одноранговая) значение x и удовлетворить следующее:
node_x - честный узел, то все честные узлы согласуются с значением x. Механизм доказательства передачи решает вышеупомянутые проблемы, позволяя честным узлам в сети проверять и достичь консенсуса по успешной передаче data_x от node_2 в node_1 . Это достигается за счет использования верификаторов, которые ответственны за оспаривание участвующих узлов. В то время как простой подход будет включать в себя отправку необходимых данных в проверку, а затем переадресовать их в узлом назначения, этот метод может привести к узким местам пропускания и хранения, что снижает общую пропускную способность сети. Следовательно, решение о проверке передачи было разработано для минимизации требований к полосе пропускания и хранения/памяти, связанных с этим процессом.
┌───────────┐
┌────────►[verifiers]◄─────────┐
│ └───────────┘ │
┌────┴───┐ ┌────┴───┐
│ │ │ │
│ node_1 ◄─────────────────────► node_2 │
│ │ │ │
└────────┘ ├────────┤
│ data_x │
└────────┘
Позволять
Разделите содержание файла
Рассчитайте хэш дерева Меркл сегментов: пусть
Перетасовать сегменты: пусть
Шифровать 1 процент перетасованных сегментов: пусть
Дешифрование зашифрованных сегментов: для каждого из
Восстановление перетасованного порядка: Поскольку сегменты были перетасованы во время процесса шифрования, их необходимо восстановить до первоначального порядка, используя обратную перестановку
Расчет хеша Merkle Tree: пересчитывайте хэш дерева Меркл дешифрованных сегментов в восстановленном порядке. Построить хеш -дерево аналогично исходной конструкции, но используйте расшифрованные сегменты
Наконец, полученный оригинальный хэш корня Merkle
Консенсус достигается, если полученный хэш корня Merkle соответствует оригинальному хешу корня Merkle.
Рассмотрим сценарий, включающий файл, содержащий последующий контент:
FileFileGo_Network
После загрузки файла поставщику хранилища корневой хеш Merkle File вычисляется посредством сегментации его содержимого на различные сегменты данных.
В последующей иллюстрации изображен упрощенное проявление расположения файла на среде для хранения. Каждая отдельная коробка в иллюстрации символизирует 1 байт данных.
┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┐
│ F │ i │ l │ e │ F │ i │ l │ e │ G │ o │ _ │ N │ e │ t │ w │ o │ r │ k │
└───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┘
Чтобы найти хэш корня Merkle этого файла, мы разбиваем файл на более мелкие части. Например, давайте разделим файл на девять разделов, и каждая часть будет иметь только два байта.
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 │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
Теперь мы берем хеш каждого сегмента:
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
И затем мы рассчитываем хэш корня Merkle файла, применяя алгоритм.
Вот пример того, как работает этот алгоритм:
┌───┬───┬───┬───┬───┬───┬───┬───┐
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))
Теперь мы обладаем хэшем корня Merkle для файла, представленного как MT (F), который по сути является еще одним хэш -значением.
Когда запрос на получение данных достигает поставщика хранения, поставщик переставляет сегменты данных в случайном порядке. Например, рассмотрим последовательность сегментов данных:
random segments [ 1, 5, 2, 4, 7, 6, 3, 0, 8 ] , что переводится на следующее расположение:
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 │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
Впоследствии поставщик генерирует симметричный ключ и вектор инициализации (IV) для шифрования части этих сегментов. На этой иллюстрации мы выберем шифрование 25% сегментов, что приравнивается к 2 сегментам. Кроме того, мы зашифруем каждые 4 сегмента, подразумевая, что мы будем шифровать 0 -е и 4 -е сегменты:
25% Segment Encryption = 2 segments
┌───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ l e │ _ N │ F i │ * * │ w o │ e t │ l e │ * * │ r k │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
Теперь вышеупомянутые данные будут предоставлены для запроса данных. Одновременно ключ/IV, рандомизированный порядок сегментов и содержимое сегментов 0 и 4 передается на data verifier . Важно подчеркнуть, что загружатель обладает Zero-Knowledge как по порядку сегментов в файле, так и ключ для шифрования/IV.
Вы можете быть обеспокоены возможностью того, что кто -то создает сценарий, чтобы попытаться сделать различные комбинации сегментов, чтобы определить первоначальный порядок, что может привести к уязвимости безопасности и потенциальной атаке.
Чтобы дать дальнейшее понимание, рассмотрите, что файл разделен на приблизительно 1024 сегментах (или немного меньше) в реальном сценарии, и эти сегменты затем рандомизированы. Для злоумышленника, чтобы восстановить первоначальный заказ сегмента, им нужно будет выполнить «перестановку без повторения». Общее количество способов организовать эти сегменты файлов дается N! (Фактор), который составляет 1024! в этом случае. (https://coolconversion.com/math/factorial/what-is-the-chactorial-of_1024_%3F)
Последующий шаг злоумышленника включает в себя попытку приобрести ключ и IV, используемый для шифрования двух сегментов. Тем не менее, стоит отметить, что эта задача в настоящее время считается невозможной на основе существующих уязвимостей в этой области.
После этого загружающий файл должен запросить ключ шифрования/IV и рандомизированный порядок сегментов файлов из назначенного data verifier в сети.
Загрузитель данных отправляет запрос Verifier Data, в поисках ключа шифрования/IV и рандомизированных сегментов. Этот запрос сопровождается хэшами сегмента загруженного файла, которые представлены следующим образом:
h1
h5
h2
h(enc(4))
h7
h6
h3
h(enc(0))
h8
data verifier предпринимает шифрование и хэширование для сегментов 0 и 4, что приводит к следующим значениям хэша:
h1
h5
h2
h4
h7
h6
h3
h0
h8
Наконец, data verifier реорганизует сегменты в соответствии с рандомизированным порядком, сгенерированным файлом hoster во время передачи данных в запрашивающий. Этот процесс дает исходную последовательность хэшей сегмента:
h0
h1
h2
h3
h4
h5
h6
h7
h8
В конечном счете, благодаря выполнению вычислений хеш -хэша Merkle, проверка данных вычитает исходный хэш Merkle Root, не требуя полного локального доступа ко всему файловому содержимому.
После подтверждения того, что полученный хэш корня Merkle соответствует первоначальному, мы эффективно установили математическое доказательство того, что загружатель данных обладает всеми запрошенными данными. Впоследствии, проверка данных передает ключ шифрования/IV и порядок рандомизированных сегментов для загрузчика данных, что приводит к автоматическому выпуску сборов в File Hoster.
В этом разделе демонстрируется полный жизненный цикл проверки передачи данных.
1. Data Query Request
┌───────┐
┌───────────────►[nodes]├───────────────┐
│ └───────┘ │
┌───┴────┐ ┌────▼───┐
│ │ │ │
│ node_1 │ │ node_2 │
│ │ │ │
└───▲────┘ └───┬────┘
│ 2. Data Query Response │
└──────────────────────────────────────┘
Data Query Response содержит всю информацию, необходимую для подготовки транзакции с интеллектуальным контрактом. Эта транзакция затем передается в сеть, которая затем выбирается верификатором. ┌──────────────────────────────────────┐
│ TRANSACTION │
├──────────────────────────────────────┤
│ Data : │
│ - Data query response │
│ - Remote node signature │
│ Value: │
│ - Fees required by node │
│ │
│ Fees : │
│ - Fees collected by verifier │
│ │
│ To : │
│ - Network verifier │
└──────────────────────────────────────┘
v1 ) связывается с участвующими узлами и генерирует задачу для узла, который размещает данные ( node_2 ). Задача состоит из следующих шагов:node_2 должен создать дерево Меркл, которое соответствует исходному корню Merkle of data_x загруженного в первую очередь.v1 решает порядок и количество блоков/диапазонов данных , которые будут отправлены в node_1 node_2 . Мы еще не хотим раскрывать порядок блоков node_1 .v1 спрашивает node_2 для фиксированного диапазона данных, который будет зашифрован с использованием случайной ключа k1 в качестве data_enc от v1 и отправленной node_1 . На этом этапе node_1 обладает некоторыми data_z и data_enc , но не имеет знаний о том, как их объединить для получения исходного файла. Verifier, v1, способен проверить целостность данных, передаваемых node_1 , и, если они соответствуют оригинальной личности дерева Меркл, ключ дешифрования K1 предоставляется node_1 . Кроме того, порядок блока отправляется в node_1 , что позволяет собирать все части для формирования исходных данных. Как только этот процесс будет завершен, V1 выпускает сборы node_2 .
Использование этого алгоритма позволяет одновременно достигать доказательства передачи и подтверждения хранения данных.
Следуйте инструкциям для компиляции и установки FileFilego
https://filefilego.com/documentation/docs/installation.html#prerequisites
FileFilego - это децентрализованная сеть, которая включает в себя надежность блокчейна/криптовалюты, DHT и инновационных технологий BitTorrent для формирования непреодолимой инфраструктуры.
Для достижения времени блока 10 секунд FileFilego требует консенсусного алгоритма, который эффективен при обработке большого объема транзакций и сохраняет мощность обработки. Для начального этапа мы выбрали доказательство власти (POA) в качестве нашего консенсусного алгоритма. В будущем механизм доказательства кола (POS) заменит текущий алгоритм.
Использование алгоритмов на основе POW для новых блокчейнов представляет риск, так как уже существуют существенные пулы вычислительной мощности, которые можно использовать для 51% атак. Таким образом, мы выбрали POA, который безопасен по проекту и обеспечивает необходимую эффективность для поддержки наших требований высокого объема транзакций.
Идентификации валидаторов жестко кодируются в блокчейн и могут быть проверены путем изучения транзакции Coinbase Block Genesis. Участвующие узлы могут легко проверить подлинность этих идентичностей, проверяя подписи блока.
По мере продвижения вперед, текущий механизм POA будет заменен доказательством, чтобы позволить нескольким сторонам участвовать в процессе добычи блоков. Наша цель управления блокчейном состоит в том, чтобы побудить больше сторон и разработчиков принять участие и увеличить участие заинтересованных сторон. Одним из стимулов для достижения этой цели является механизм доказательства ухода.
Чтобы упростить транзакцию и мутацию состояния, FileFilego использует другой подход, чем UTXO-подобные структуры. Вместо того, чтобы использовать такие структуры, мы храним бухгалтерский учет и метаданные в качестве регулярных строк базы данных, сохраняя при этом необработанные блоки в их исходном формате в базе данных. Этот подход помогает устранить ненужную сложность.
В этом разделе мы предоставим обзор технических терминов и концепций, используемых в FileFilego.
Каналы в FileFilego позволяют пользователям организовывать и группировать данные в различные ведра или папки. Например, весь контент на Ubuntu.com может быть помещен в канал под названием «Чиновник Ubuntu». Пользователь, который создает канал, получает все разрешения, необходимые для обновлений и других операций, связанных с каналом.
Каналы структурированы в формате цепочки узлов и могут быть идентифицированы как узел без ParentHash .
Концепция подканала заключается в том, чтобы иметь возможность еще больше классифицировать данные. Например, документы, картинки или музыка.
В FileFilego Entry представляет собой сообщение или часть данных, которая содержит больше информации о самой записи, а не о категоризации/упорядочении. File и Directory могут быть помещены в Entry .
Storage Engine - это уровень хранения, который отслеживает двоичные данные, которые используются с помощью указателей хэш в блокчейне для обозначения части данных. Структура NodeItem имеет поле, называемое FileHash , которое относится к бинарному хэш и находится в форме "{HASH_ALGORITHM}:>{DATA_HASH}" . Мы хотели бы сохранить метаданные алгоритма хеширования, поскольку он может быть полезен в будущем.
В FileFilego точность поиска и гибкость одинаково важны в качестве основной функции блокчейна. Мы стремимся позволить пользователям построить сложные запросы, включая бинарные поиски, используя конкретный язык запросов. Например, должны быть возможны запросы следующих типов:
Разработка языка запросов, который поддерживает такие сложные запросы, является мощным инструментом, который может значительно повысить точность поисковой системы.
Также возможно включить полнотекстовую функцию индексации узла с использованием флага CLI- --search .
Уровень хранения отслеживает двоичные файлы и использует хэши, чтобы представить часть информации в блокчейне. Эту функцию можно включить, используя следующие флаги:
... --storage --storage_dir="/somewhere/to/store/data" --storage_token="somelongtokenhere" --storage_fees_byte="10000" ...
--storage_dir должен быть каталогом, который существует с соответствующими разрешениями для чтения/записи. Обратите внимание, что полные узлы могут работать без этого механизма. storage_token - это токен, который предоставляет права администратора в токен, поэтому он может создавать другие токены, используя HTTP API. Это полезно, когда право доступа требуется веб -приложениям или различным пользователям, а --storage_fees_byte="10000" -это сборы, взимаемые за байт данных.
| Единица | Ценить |
|---|---|
| Ffgone | 1 |
| Kffg | 1.000 |
| Mffg | 1.000.000 |
| GFFG | 1.000.000.000 |
| Microffg | 1.000.000.000.000 |
| Милифг | 1.000.000.000.000.000 |
| FFG (блок по умолчанию) | 1.000.000.000.000.000.000 |
| Zffg | 1.000.000.000.000.000.000.000 |
Общая подача: 500 миллионов FFG Валидация/вознаграждение доля: 40 FFG на запас .
