Привет!
Речь пойдёт об облаках, одноранговых сетях, web технологиях, анонимности и защищённости данных в сети.
Приведённый ниже текст является обоснованием того как, а главное зачем, я собираюсь разработать протокол взаимодействия компьютеров в сети, а так же клиент, работающий по этому протоколу.
Протокол строится с расчётом на то, что пользователь должен иметь возможность работы с клиентом сети из коробки. Просто облако для него станет распределённым. Так же клиентские настройки будут очень гибкими, главным образом для того, что бы минимизировать возможность паразитирования отдельных пользователей (личеров).
ИМХО, концепция облака, как она сейчас есть, требует кардинальной переработки. Получившие распространение в конце нулевых облака уже успели стать атрибутом Большого Брата, который разрешил хранить файлы пользователей на своих серверах. Любое облако знает, что вы храните в своей папке. Более того, облако может быть заблокировано ввиду политических санкций или просто закроется из-за своей убыточности (да, конечно же они собираются зарабатывать на пользователях). Вот так уехал в отпуск, а по приезду узнал, что вся рабочая документация потеряна. Но слава Богу уже давно существуют распределённые сети, которые успешно хранят в себе файлы, и работают несмотря на все попытки закрыть их. Так у меня родилась идея реализовать однорангувую сеть для хранения данных (и не только).
Теперь о главном, о том как это будет работать.
Каждый файл пользователя разбивается на блоки и шифруется. Эти блоки избыточно раскидываются по машинам, которые во-первых, не забиты данными, во-вторых, лучше других по характеристикам (канал интернета, uptime, поддерживаемое количество зеркал, и т.д.). Каждая из этих машин знает только идентификатор доверенного ей блока файла и то, у каких машин хранятся копии этого блока. Данные, позволяющие собрать воедино эти блоки, находятся только у пользователя. Допустим, существует 10 зеркал одного блока, и половина из них ушла в офлайн (не важно по какой причине). Оставшиеся пять машин будут проинформированы об этом и сами сделают ещё пять копий блока, оставив сообщение для старых машин, о том, что когда те будут онлайн, они могут удалить свои зеркала блока, а для владельца файла оставят сообщение о том, что адреса хранения блоков изменились. Что касается возможности “поделиться” файлом, то достаточно дать файл-ссылку (содержащий идентификатор владельца файла, идентификатор файла и ключ для расшифровки файла). Если количество обращений к какому то файлу будет достигать некоторого порога, то количество зеркал будет временно увеличиваться. Так же полезной фичей будет возможность читать файл из сети последовательно. Если кому-то понравится файл, и он захочет добавить его себе, то ему будет достаточно просто сохранить в своём списке файлов файл-ссылку, и этот файл будет доступен ему, даже если старый владелец удалит его из своего списка файлов. Это решает проблему избыточности.
У сети не может быть никакого владельца, следовательно закрыть её или заблокировать будет невозможно.
Таким образом сеть сможет гарантировать, что Ваши данные никуда не исчезнут и Вы всегда будете иметь к ним доступ, а благодаря высокому уровню шифрования содержание Ваших файлов будет известно только Вам.
Данные о списке файлов, и прочей информации пользователя будет тщательно шифроваться и распространяться по всей сети, так что пользователь сможет получить доступ к своим файлам (и прочим возможностям сети) с любой машины находящейся в этой сети.
Стойкая криптография — это краеугольный камень сети. Любые данные, которые будут передаваться по сети, будут передаваться в зашифрованном виде.
Что касается анонимности, то анонимность будет осуществляться на уровне хранения данных и доступа к ним. Посредством “туннелей” из случайно выбранных свободных узлов сети. Участники туннеля, в свою очередь, не будут знать ничего об информации, передаваемой через них.
Структура аккаунта будет предусматривать возможность публиковать личные данные, однако, это не является обязательным. И их никто не станет указывать, если бы не одно “но”. Аккаунты с контактной информацией, естественно, будут пользоваться большей степенью доверия, чем анонимные аккаунты.
Нужно чётко разделять анонимность в передаче и хранении данных и открытость в социальном взаимодействии. Оба эти пункта могут уживаться в одном программном продукте. Очень важно осознать это.
Итак, смоделируем ситуацию:
Действующие лица:
Алиса, Ева — жители США
Боб, Дейв — жители Великобритании
Microsoft — трансконтинентальная корпорация
Предположим, Алиса, которая живёт в Вашингтоне, хочет передать Бобу, который живёт в Лондоне, 100 у.е.
Так же есть компания Microsoft, у которой уже есть аккаунт в сети. Этот аккаунт подтверждён другими пользователями и ему доверяют. Ева, находясь в Вашингтоне, отдаёт свои 100у.е. компании Microsoft. Дейв находится Лондоне и делает то же самое. В итоге Microsoft остаётся должен Еве и Дейву по 100у.е.
Теперь я опишу как произойдёт безопасная транзакция между Алисой и Бобом.
Алиса выписывает виртуальный долг Бобу в 100у.е.
A->B 100у.е.
Алиса идёт к Еве и отдаёт ей свои 100у.е.
Ева выписывает виртуальный долг Алисе в 100у.е.
E->A 100у.е.
A->B 100у.е.
==
E->B 100у.е.
Ева просит Дейва занять ей 100у.е.
Дейв выписывает виртуальный долг Еве в 100у.е.
E->D 100у.е.
D->E 100у.е.
E->B 100у.е.
==
E->D 100у.е.
D->B 100у.е.
Дейв отдаёт 100у.е. Бобу.
E->D 100у.е.
M->E 100у.е.
M->D 100у.е.
В итоге получается, что Ева должна Дейву 100у.е. Теперь, если Ева куда-то свалит, Дейв всегда сможет пойти в Microsoft и получить 100у.е. Однако, это крайняя мера, т.к. та же операция может понадобиться и в обратную сторону, и тогда их долги сократятся.
Обратите внимание на то, что Дейв и Ева могут брать комиссию за свои услуги, но комиссия эта будет жестко регулироваться конкуренцией, т.к. в Лондоне и Вашингтоне может найтись сотня подобных Ев и Дейвов, у которых условия будут более вкусными.
Также Ева не сможет набрать долгов и скрыться, т.к. любая Алиса, видя что Microsoft поручился за Еву только на 100у.е. не доверит свои деньги Еве пока сумма незавершенных транзакций упирается в эту сумму.
Что касается распределённого web.
На сегодняшний день, большая часть сайтов, которыми мы пользуемся, это большие сервисы. И каждый из таких сервисов можно рассматривать как отдельное приложение.
Теперь стоит углубиться в структуру такого приложения. Оно всегда делится на клиентскую и серверную части.
Клиент — это программа с открытым исходным кодом, который исполняется у пользователя, и результатам её вычислений доверять нельзя (т.к. пользователь мог изменить этот код). Сервер же — это программа, в результатах вычислений которой можно быть уверенным, и именно она наполняет базу данных.
Данные БД, в свою очередь, ценны тем, что они достоверны в той степени, которая гарантируется серверным кодом.
(Пояснение: любая программа может быть разбита на функции.)
Теперь возникает вопрос: как обойтись без сервера? Ведь нужно проверять достоверность вычислений проведённых клиентом, что бы сообщить результат другим участникам сети.
Задача становится проще если аппроксимировать её на ситуацию, когда в одной комнате сидят несколько студентов и перед ними на доске написана задача. Не сложно догадаться, что удостоверяться в правильности своего решения они будут, сверяясь друг с другом. Тот же самый финт могут проделать и программные клиенты: поручив другим клиентам посчитать ту же функцию что и они, и приняв за истину результат абсолютного большинства.
Но база данных — это не статичный файл. Данные в ней постоянно изменяются. Поэтому алгоритм работы с такой базой будет немного отличаться от привычного.
Данные будут синхронизироваться не полностью, и по этому децентрализованная обработка потребует существенно меньшего количества данных.
Возьмём в качестве примера Facebook. Мне не зачем хранить у себя данные о записях людей, которые ко мне не имеют никакого отношения. Однако, у меня будут храниться все записи тех, на кого я подписан. Данные о том, кто и когда “лайкнул” мою запись на стене, должны быть достоверны. Поэтому они будут подписаны тем, кто инициировал вычисление (тем, кто “лайкнул”), а результат этого вычисления будет подписан всеми, кто “проверил” достоверность результата.
Ну, вот вроде бы и всё, что я хотел сказать о проблемах сегодняшних технологических решений.
Разговоры о том, что всё это нужно, идут уже давно. Но всё стопорится на стадии детального проектирования и разработки, т.к. вся эта система очень объёмная, и разработка её займёт достаточно продолжительное время. Чаще всего причиной забрасывания проекта, становится добыча средств к существованию. Я предлагаю сообществу поддержать нас (меня и ещё пару энтузиастов) на протяжении разработки. Все, кто скинутся на разработку, будут перечислены в оригинальном клиенте, сортировка списка будет осуществляться пропорционально сумме пожертвования. Если Вы, по той или иной причине не можете помочь проекту материально, но чувствуете, что проект стоящий воплощения, расскажите о нём как можно большему количеству человек.
Спецификация протокола будет опубликована сразу после завершения работы над ней. В блоге будет вестись журнал разработки.
Клиент сети будет распространяться бесплатно (и без рекламы внутри), исходники будут открыты.
Благодарю за внимание.
P.S. На размышления меня подтолкнули публикации «Тёмная материя интернета» и «Ripple: первая в мире распределённая глобальная валютная биржа».
Автор: Flash_X
