Децентрализованное Torrent хранилище в DHT

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

Уже много лет, как существует система DHT и вместе с ней торренты, которые мы успешно используем для получения любой информации.

Вместе с этой системой существуют команды для взаимодействия с ней. Их не так уж много, но для создания децентрализованной БД нужно всего два: put и get. Об этом и пойдёт речь далее...

По логике все могут понять. Put - это положить. А Get - это получить. Так вот достоверно положить с помощью команды Put можно до 1000 байт любой информации. И достоверно эта информация будет хранится в DHT около часа. Get - это получить, то что положили. Всё просто.

Команда Put имеет два вида. Первый - это положить без возможности изменения. Второй - положить с возможностью изменения. Т.е. можно мало того, что положить в DHT 1000 байт, так ещё и менять их, как хочется.

Что бы положить или менять изменяемые данные нужно 2 ed25519 ключа. Публичный и приватный. И каждый у кого есть эти два ключа может менять данные, как ему хочется.

напомню, как работают приватные и публичные ключи

Информацию можно зашифровать приватным ключом, а расшифровать публичным. Но зашифровать публичным нельзя. Поэтому эти ключи парные. Отгадать приватный ключ невозможно.

На этом и можно построить децентрализованную БД

Вариантов много. Это дело вашей фантазии, но можно использовать, например такой.

У всех пользователей = пиров есть публичный и приватный ключ.

Пользователь 1 хочет изменить БД. Он получает содержимое DHT с помощью Get и публичного ключа. В полученных данных, может быть всё что угодно. У нас это будет sha1 ссылка торрента по которой можно скачать торрент. Её размер около 20 байт. По этой ссылке он скачивает торрент в котором находится БД. Изменяет БД. Генерирует торрент (получая sha1 ключ) и раздаёт его. Публикует Putом полученный sha1 ключ по которому уже можно скачать новую, изменённую БД.

Пользователь 2 хочет изменить БД....аналогично...

Для того что бы данные в DHT не пропали нужна регулярная синхронизация пиров. Синхронизация это Get с публичным ключом через udp. Очень малозатратно. И если данные изменились, то скачивание их. Это уже немного более затратно, но тут тоже можно ставить ограничение по скорости скачивания, например.

Если данные в DHT пропали, то пир, который хочет синхронизироваться просто делает Put с последними данными, какие у него есть, либо с чистыми данными.

А теперь немного о том, почему это БД, а не обмен файлами

В 1000 байт можно зашить всё что угодно. А в передаваемую БД бесконечное количество информации. Так как пользователь не знает публичного и приватного ключа, то он не может сам публиковать что-то. Это может только программа. А программа в зависимости от данных в этих 1000 байт может делать всё что угодно. Может получить блокировку пользователя и перевести его только в режим чтения. Получается это БД с правами доступа на изменение определённой информации. Особенно, это будет похожим на БД, если скачиваемые данные шифровать и хранить в одном файле без расширения.

Конечно здесь могут возникнуть определённые проблемы, но все они решаются.

Теперь о недостатках и проблемах

Например, если пользователь 1 опубликовал новый хеш, изменённой БД, но не стал раздавать его. В DHT можно хранить 5 записей sha1 это 100+байт всего и если какой либо из пользователей не смог скачать изменённую версию, то он качает следующую из 5ти и затем перепубликовывает на ту, которая скачивается. Соответственно другие пользователи уже не будут пытаться скачать, то что не качается и получат БД быстрее. Чем больше пользователей, тем лучше и быстрее будет работать БД.

Главная проблема подобной системы это время ожидания. Публикация (Put) занимает от 20 до 60 секунд + время что бы кто-то скачал эти данные. Если пользователь не выключает программу, то это только 20-60 секунд. Зато получение данных так как это торренты - выполняется на максимальной скорости устройства с использованием множества торрент технологий и протоколов. Скачивание только изменённых данных? Думаю можно, но не спрашивайте как.

Вторая не менее важная проблема это то что каждый пользователь имеет программу в которой хранятся публичный ключ и приватный. И если взломать программу, то можно получить эти ключи и с помощью них публиковать свои ложные данные. Тут можно сочинить не мало способов борьбы с этим. Возможно в комментариях подскажут ещё какие-то. Но например: можно хранить ключ в шифрованном виде и расшифровывать его только при использовании. Можно шифровать БД отдельным ключом так что злоумышленнику понадобится вычислить ещё и этот ключ. Можно хранить ключи тоже в DHT и менять их периодически или на сайте. Способов столько на сколько фантазия богата. Поэтому нельзя точно сказать, что это уязвимость.

Технически это возможно сделать на основе любой торрент библиотеки. Например Libtorrent. Она весит после компиляции всего 2,5Мб, написана на с++ и работает максимально быстро. Там есть техническая информация про Put.

Подобная система используется в моём приложении "Торрент плеер", для публикации плейлистов. У меня уже есть даже админка для модерации. Всё успешно работает. Пользуйтесь.

Источник: https://habr.com/ru/post/546354/


Интересные статьи

Интересные статьи

В этой серии статей мы подробно рассмотрим, почему и как недавно были внесены изменения в наши Условия обслуживания. Эта статья подробно опишет политику хранения неактивных образов,...
Принято считать, что персонализация в интернете это магия, которая создается сотнями серверов на основе БигДата и сложного семантического анализа контента.
Получить трафик для интернет-магазина сегодня не проблема. Есть много каналов его привлечения: органическая выдача, контекстная реклама, контент-маркетинг, RTB-сети и т. д. Вопрос в том, как вы распор...
«Битрикс» — кошмар на костылях. Эта популярная характеристика системы среди разработчиков и продвиженцев ныне утратила свою актуальность.
Автокэширование в 1с-Битрикс — хорошо развитая и довольно сложная система, позволяющая в разы уменьшить число обращений к базе данных и ускорить выполнение страниц.