Уже много лет, как существует система DHT и вместе с ней торренты, которые мы успешно используем для получения любой информации.
Вместе с этой системой существуют команды для взаимодействия с ней. Их не так уж много, но для создания децентрализованной БД нужно всего два: put и get. Об этом и пойдёт речь далее...
По логике все могут понять. Put - это положить. А Get - это получить. Так вот достоверно положить с помощью команды Put можно до 1000 байт любой информации. И достоверно эта информация будет хранится в DHT около часа. Get - это получить, то что положили. Всё просто.
Команда Put имеет два вида. Первый - это положить без возможности изменения. Второй - положить с возможностью изменения. Т.е. можно мало того, что положить в DHT 1000 байт, так ещё и менять их, как хочется.
Что бы положить или менять изменяемые данные нужно 2 ed25519 ключа. Публичный и приватный. И каждый у кого есть эти два ключа может менять данные, как ему хочется.
напомню, как работают приватные и публичные ключи
Информацию можно зашифровать приватным ключом, а расшифровать публичным. Поэтому эти ключи парные. Отгадать приватный ключ, имея публичный, невозможно.
На этом и можно построить децентрализованную БД
Вариантов много. Это дело вашей фантазии. Рассмотрим, например, такие:
Вариант 1.
У всех пользователей = пиров есть публичный и приватный ключ.
Пользователь 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 и менять их периодически или на сайте. Способов столько на сколько фантазия богата. Поэтому нельзя точно сказать, что это уязвимость.
Вариант 2.
Пользователь генерирует пару ключей. Приватный и публичный. Связывается с менеджером (человек) и обменивается с ним публичными ключами (например через Bluetoth, Wifi). Далее у пользователя есть публичный ключ по которому он может получить БД и своя пара ключей для публикации изменений к БД. Пользователь с помощью своей пары ключей публикует изменения к БД. Менеджер делает опрос всех публичных ключей пользователей. Получает изменения пользователей, вносит их в БД и публикует. Пользователи получают новую БД и так по кругу.
Такую систему невозможно взломать, так как ключи не зашиты в программе, как в предыдущем примере. Однако и тут есть небольшой недостаток. Количество пользователей, которых нужно опросить менеджеру влияет на скорость обновления БД. Однако не существенно. В одну секунду можно опрашивать около 1000 пользователей и получать ответы в течении 30 секунд, как обычно. Думаю, в реальности опрос 1000 пользователей (=1000 UDP запросов) займёт около минуты. Для увеличения скорости можно подумать о распределённой БД. Например, у каждого менеджера будет по 1000 пользователей и менеджеры обменявшись публичными ключами для обмена информацией (между БД) могут публиковать изменения для другого менеджера под специальным публичным ключом. Таким образом падение производительности из-за количества пользователей удастся избежать.
Таким образом получается децентрализованная, но управляемая менеджерами БД.
Подобную систему уже можно использовать даже для биллинга. Отличие от блокчейн систем тут будет в том, что менеджер может управлять содержимым БД. Т.е. если пользователи используют БД для хранения денег, то они должны доверять менеджеру секрет транзакций. Для надёжности менеджеров может быть несколько. Чем их больше, тем быстрее будет происходить обновление БД и тем надёжнее будут данные в БД, но так же возрастает количество людей, знающих о транзакциях. Впрочем вместо менеджера может быть просто компьютер, которому все доверяют :)
Так как все публикуемые данные публичны, то для передачи транзакций от пользователей к менеджеру можно использовать всё те же публичные и приватные ключи для шифрования текста уже.
Для повышения доверия пользователей к менеджеру - можно использовать замкнутую систему экономики, при которой при совершении сделки у одного пользователя баланс отнимается, а у другого прибавляется и таким образом сумма всех денег всегда равна нулю. Это было бы отличной заменой не управляемым блокчейн системам. В которых деньги пропадают навсегда и нельзя отменить транзакцию, особенно, если это ограбление.
Вариант 3.
Возможно сделать децентрализованный интернет.
Например, если менеджеры будут хранить БД не с биллингом, а с ДНС именами и публичными ключами. То пользователи могут добавлять свои ДНС имена и могут скачивать БД с ДНС именами или обращаться к БД через публичный ip.
А дальше открывая сайт, пользователи будут обращаться к публичному ключу сайта, по которому будут получать информацию о том, как скачать содержимое сайта. Скачают сайт и смогут получать обновления сайта примерно раз в пол минуты. При этом браузер может отправлять информацию на сервер сайта с помощью публичного и приватных ключей, которые придут вместе с сайтом. Получится децентрализованная двусторонняя связь, скорость работы, которой будет расти от количества серверов сайта и пользователей, потому что все будут раздавать контент сайта. А получение изменений сайта возможно в пофайловом режиме.
Для работы подобного интернета нужно разработать специальный торрент-браузер и серверную часть.
Технически это возможно сделать на основе любой торрент библиотеки. Например Libtorrent. Она весит после компиляции всего 2,5Мб, написана на с++ и работает максимально быстро. Там есть техническая информация про Put.
Подобная система используется в моём приложении "Media Library", для публикации плейлистов. У меня уже есть даже админка для модерации. Всё успешно работает. Пользуйтесь.
По причине не правильной работы системы кармы на сайте, я не могу комментировать свои же статьи. Поэтому можете считать, что комментарии к статье отключены. Пишите вопросы в личные сообщения. Там, возможно, отвечу.
