Skip to content
denizzzka edited this page Aug 18, 2014 · 50 revisions

DIANNA - IANA Decentralized

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

Каким службам нужна децентрализация?

  • DNS (в том числе для скрытосетей типа i2p и Tor)
  • Центрам сертификации (они могут быть упразднены, так как вместе с DNS-именем в децентрализованном хранилище может лежать отпечаток сертификата для этого имени)
  • Службам назначения автономных систем (Autonomous System, AS), IP-адресов
  • Для новой глобальной системы аутентификации (глобальный логин для всех ресурсов пользователя)
  • Другим, распределяющим достаточно большие но конечные ресурсы, в том числе ресурсы, существующие вне интернета. (Глобальные ники абонентов телефонной сети при частой смене ими телефонных номеров, радиочастотные ресурсы и т.п.)

Все эти задачи можно решить (или приблизить решение), создав глобальное открытое децентрализованное распределённое хранилище ключ-значение.

Требования к хранилищу

  • Поиск и доступ к записям в хранилище должен быть общедоступен и анонимен
  • Создание и владение записью (например, о зарегистрированном домене) должно быть анонимным
  • Хранилище не должно иметь централизованного управления
  • В хранилище должна быть исключена возможность цензуры информации
  • Искажение или исчезновение данных на некоторых серверах не должно влиять на консистентность данных в хранилище и на функционирование всей системы
  • Ставшие более ненужными записи должны удаляться (для экономии имён ключей и уменьшения объёма хранилища)
  • Хранилище должно быть защищено от сквоттеров

Защита от сквоттеров

Сквоттеры - главная проблема, стоящая перед конструкторами открытых глобальных хранилищ.

Причём, под сквоттерами нужно понимать не только тех, кто регистрирует в хранилище ключи (например, названия доменов) по словарю популярных слов, в надежде в дальнейшем перепродать эти записи, но также и тех, кто только что узнал о хранилище, зарегистрировал в нём свои записи "просто так, на всякий случай" но никогда не воспользуется этими записями в будущем.

Для защиты от сквоттеров при создании записей хранилище требует от создающего затратить определённую работу, создав proof-of-work (подобно тому, как это происходит в Bitcoin при генерации блока). Хэш этого proof-of-work используется для защиты цепочки ранее созданных в хранилище записей.

В dianna2 любая запись стирается из хранилища через полгода. (Точнее, 180 дней работы записи + 90 дней запас на случай непредвиденных обстоятельств.) То есть, невозможно создать запись в хранилище, которая будет храниться в нём много лет: не реже чем раз в полгода все владельцы записей должны подтверждать желание продолжать владеть ими обновлением этих записей с генерацией нового proof-of-work.

Сквоттеры будут вынуждены тратить значительные ресурсы на обновление proof-of-work всех своих записей, иначе их записи из хранилища будут удалены.

Сложность proof-of-work

Если принять во внимание, что все создатели записей в хранилище анонимны, то по каким признакам можно отличить обычного пользователя от сквоттера?

  • Для обычных пользователей характерно желание не уменьшать сложность создания доменов, так как в этом случае домен пользователя оказывается менее защищён.
  • Для сквоттеров характерно желание не увеличивать сложность создания доменов, так как в этом случае затраты сквоттеров на создание и содержание доменов возрастают.

Ничем другим держатели записей на условиях анонимности не отличаются.

Поэтому, сложность создания proof-of-work для записи в хранилище должна находиться в балансе: она должна быть максимальной, но такой, с которой пользователи системы в среднем согласны мириться. (Эту сложность можно назвать "рыночной" - именно в таких условиях работает любой рынок, в том числе - рынок регистрации доменов существующей сейчас системы DNS.)

Чтобы добиться установления такой сложности создания proof-of-work хранилище определяет начало всплесков и спадов количества созданных в хранилище записей в единицу времени и устанавливает сложность таким образом, чтобы это изменение сложности позволило сгладить возмущения.

Такое устройство хранилища не позволяет избавиться от сквоттеров на 100%, но заставляет процессорные мощности сквоттеров работать на благо обычных пользователей: сквоттеры, создавая в хранилище новые хэши proof-of-work защищают от цензуры цепочки, содержащие записи, созданные обычными пользователями.

Хранение

Полноценная копия всех данных хранится каждым участником p2p-сети хранилища. Это довольно расточительный подход и не видно никаких препятствий для того, чтобы в будущем по мере роста сети он был пересмотрен.

расчёт размеров хранилища на примере DNS

По википедии: Общая численность доменов 2-го уровня во всех доменах 1-го уровня в 2011 году превысила 225 млн имен.

Скажем, в среднем длина домена это 10 букв ASCII. умножаем на 10, чтобы покрыть будущее (скорость роста популяции человечества замедлилась, так что в 10 раз вполне хватит):

10 букв * 225 * 1000 * 1000 * по 10 раз = 20 Гб

Конечно, не забываем про сопутствующие значения, подписи ЭЦП и прочие накладные расходы на индексы, поэтому, ВСЯ существующая мировая база ДНС в децентрализованном виде явно умещается в 0.5-1 Терабайт при наших десятикратных допущениях. И это уже сейчас легко подъёмно для любого пользователя и, тем более, провайдера.

А пока dianna2 используется мало объём хранилища составит десятки мегабайт, что вполне доступно даже домашним роутерам.

Сравнение с Bitmessage и Bitcoin

dianna2 устроена подобно Bitmessage в части создания записей, которые существуют ограниченное время. Но, в отличии от Bitmessage, dianna2 использует цепочку блоков для исключения возможности цензурирования данных в хранилище - этим она похожа на Bitcoin.

Сравнение с Bitcoin/Namecoin

Многие разрабатываемые конкурирующие системы (например, Namecoin) базируются на Bitcoin или используют его цепочку транзакций. Это порочный подход, поскольку у Bitcoin есть фундаментальный недостаток - бесконечный рост цепочки транзакций. Для хранилища типа ключ-значение (например, данных DNS) это неприемлемо - лог транзакций Bitcoin достиг чудовищного размера и продолжает расти.

dianna2 лишена этого недостатка поскольку не хранит никаких данных, которые требуется сохранять навечно.

Никакого параллельного использования dianna2 или её частей в качестве валюты не предусматривается. При этом возможна передача прав на существующие в хранилище записи с помощью передачи или замены ключа управления записью. (Таким образом, в случае использования хранилища для хранения DNS-доменов присутствует возможность торговли зарегистрированными в dianna2 доменами на сторонних площадках.)

Сеть

Ноды-участники системы объединяются в p2p-сеть аналогично тому, как это происходит в Bitcoin.

Как получить доступ к DNS dianna2?

Для организации доступа из обычного интернета вам необходимы один или несколько DNS-серверов, которые будут авторитативными серверами вашей зоны.

В записи вашего домена в dianna2 нужно указать адреса или DNS-имена этих серверов.

Теперь пользователи dianna2 смогут найти серверы вашей зоны с помощью своих DNS-серверов, подключенных к хранилищу. (PowerDNS Remote Backend JSON-RPC, вероятно, будет наиболее удобен для этого)

Хранение других записей DNS в dianna2 не предусмотрено намеренно с целью уменьшения объёма хранимых данных.

Нерешённая проблема

Сложность подмены цепочки зависит от количества уже сохраняемых хранилищем пар ключ-значение - чем их меньше тем легче произвести подмену. Таким образом, без массового распространения системы невозможно обеспечить надёжность сохранения записей за их владельцами.

Эту проблему можно решить, например, используя аналог Unique Node List из Ripple.