Наша Core-команда активно работает, и на данный момент сеть Universa больше не зависит от ICANN или сторонних центров сертификации SSL. Более того, мы собрали все наработки по этой теме воедино и убедились, что для функционирования самой сети доменные имена не важны, и ноды при обычной работе и коммуникации их не используют.
Небольшое вступление
Как мы уже писали, наш домен universa.io был забран по решению суда США (https://medium.com/universablockchain/universablockchain-com-new-home-a1fc5092fbdd). Компания с аналогичным названием подала возражение против нашей заявки на товарный знак, которую мы подали в январе 2018 года. Компания находится в США, суд находится в США, и ICANN также находится в США — поэтому они смогли забрать наше доменное имя, хотя эта компания на шесть месяцев отстала от нас в регистрации товарных знаков! И ни наша компания, ни домен .IO тоже не имеют никакого отношения к США. И наш регистратор в Новой Зеландии был удивлен, так как они никогда не получали уведомления о смене владельца домена. Вот почему мы сейчас находимся по адресу universablockchain.com. Домен, в принципе, могут забрать как на уровне регистратора, так и на уровне ICANN. Кроме того, есть ещё SSL/TLS-сертификаты для HTTPS обычно выдаются централизованно совершенно сторонними организациями, а те их могут легко отзывать. Мы давно работали над тем, как наша сеть коммуницирует и подобная ситуация побудила команду собрать все наработки воедино.
В последнее время в интернете и браузерах идёт очень большая война с unsecured-соединениями (https://www.blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/). Например, отправить с https-страницы JSON RPC реквест на адрес с http совершенно невозможно. И появляется очень интересный логический парадокс:
1. Чтобы из браузера из нормального клиента отправить запрос, на другой стороне отвечать на этот запрос узел должен из-под HTTPS.
2. Чтобы ответить по HTTPS, у него должен быть сертификат, выданный сторонним центром CA. Можно, конечно, self-signed, но браузеры такое не любят из-за лишнего риска.
3. Чтобы получить в CA сертификат, необходимо сказать на какой домен ты его берёшь. Надо получить SSL-сертификат на IP-адрес.
4. А домены находятся под таким централизованным управлением ICANN. Который может взять и отобрать домен у регистратора даже без его ведома.
И получается, что изменять надо всю систему.
Что было сделано
Мы добавили в код возможность того, чтобы ноды общались друг с другом по IP и даже без всякого https. Можно подумать, что это небезопасно, но это не так. Мы изначально шифровали соединение и убеждались в авторизации средствами Universa. Во всей нашей сети и взаимодействии с клиентами давно используется собственный уровень шифрования/подписи, независимый от SSL.
Версия 3.9.9 нашей кодовой базы на Java, включая код узлов сети, uniclient, Java API и обновлённую библиотеку UMI, включает все самые последние наработки в области первоначальной установки соединения с сетью и последующего его поддержания — такая логика уже давно работает и проверена под нагрузкой в нодах, теперь настало время и для всех клиентов:
- Больше нет никаких зависимостей и нужды в доменных именах для нод, которые могут быть подменены с помощью DNS-hijack, утеряны регистратором доменов или даже отобраны ICANN-ом.
- Аналогично, больше никаких зависимостей от SSL/TLS-сертификатов или от сторонних CA-сервисов — достаточно положиться на собственные ключи Universa. И больше никакой траты ресурсов из-за двойного шифрования, когда трафик Universa сначала шифруется или подписывается на уровне Universa, а потом на уровне слоя TLS.
Топология
Помимо всего этого, теперь нахождение топологии сети основывается на алгоритме консенсуса (на случай, если часть нод были злонамеренно захвачены), и топология после этого поддерживается и перегенерируется в течение всех последующих клиентских сессий (аналогично, опять-таки полагаясь исключительно на криптографические ключи Universa). Мы сделали так, что ноды отдают топологию сети, в которой для каждой ноды есть одновременно и IP-адреса, и hostname-адреса. Точнее, ноды так делали уже давно, а теперь и обычные клиенты научились работать с такими продвинутыми топологиями.
Топология теперь хранится на диске в ~/.universa/topologies/. Если вам необходимо создать свою тестовую сеть, то у неё будет собственная топология, которую можно хранить в отдельном файле внутри каталога ~/.universa/topologies/.
Теперь по умолчанию в комплекте, даже в API, уже идёт «стартовая топология» для нашей сети, а когда появится 20 и более новых нод, то даже в гитхаб не обязательно обновлять файл — при следующем запуске и начале работы клиент, работающий через Java API, стукнется к любой ноде из стартовой топологии, узнает актуальное состояние сети и обновит его в ~/.universa/topologies
Что в итоге
Наша команда борется с любой [потенциальной возможностью](https://medium.com/@universa_blockchain/%D0%B1%D0%BB%D0%BE%D0%BA%D1%87%D0%B5%D0%B9%D0%BD%D1%83-universa-%D0%BD%D0%B5-%D1%81%D1%82%D1%80%D0%B0%D1%88%D0%BD%D0%B0-%D0%B0%D1%82%D0%B0%D0%BA%D0%B0-51-6a2e68f3c43d) заблокировать или каким-то образом препятствовать работе сети Universa и наших нод. И это не все новости в развитии сети и кодовой базы, которые ждут вас.
