На техническом фронте все было немного тихо, но не потому, что мы не были заняты - как раз наоборот! С момента запуска токена HOPR в феврале мы были полностью заняты работой над предстоящим выпуском Eiger.
Мы знаем, что вы все терпеливо ждали - а некоторые не очень терпеливо - начали размещать свои токены HOPR, но это тонкий баланс, создающий безопасную, надежную и справедливую реализацию, и это еще до того, как вы добавите конфиденциальность.
Одним из огромных препятствий было избавление зависимости протокола от серверов начальной загрузки, которые, как помнят наши участники тестовой сети, были основным источником нестабильности и простоев. Это препятствие, наконец, было устранено с помощью DEADR, представленного в предстоящем выпуске Kiautschou, который должен быть в пути к вам в конце следующей недели, при условии, что внутренние тесты пройдут хорошо.
Проблемы роста
Еще до запуска нашего токена команда инженеров HOPR неустанно работала над разработкой протокола HOPR.
Если вы забыли, мы в HOPR внедряем микснет конфиденциальности 0 уровня, позволяющий любому обмениваться данными конфеденциально. К настоящему времени вы, вероятно, уже протестировали нашу официальную версию Jungfrau, открыли несколько каналов, отправили несколько сообщений и получили несколько билетов с помощью wxHOPR, чтобы продемонстрировать нашу концепцию proof-of-relay.
К сожалению, если вы работали с Jungfrau, вам, вероятно, встречался следующий экран:
Надпись: Эквивалент синего экрана смерти для вашего узла HOPR
Спросив об этом в нашем Telegram, амбассадоры, вероятно, направят вас на нашу страницу статуса. Диагноз? Наш сервер начальной загрузки, вероятно, не работал. Решение? Повторите попытку позже, когда сервер перезагрузится.
Это неинтересно, и это серьезная головная боль, когда дело доходит до трафика покрытия и стекинга. Прелесть модели стекинга HOPR в том, что она интегрирована прямо в протокол конфиденциальности: это не просто произвольный способ распределения денег между китами, а фундаментальная часть стимулирования микснета.
Но это работает только в том случае, если вы можете получить доступ к сети. Стекинг невозможен, в то время как проблемы с начальной загрузкой могут случайным образом заблокировать доступ людей к сети HOPR.
К счастью, следующий выпуск HOPR полностью изменит способ подключения узлов к сети HOPR и ретрансляции данных, резко снизив зависимость от серверов начальной загрузки и проложив путь для трафика покрытия и стекинга.
Чтобы понять, как все это работает, нам нужно посмотреть, почему HOPR так долго зависел от серверов начальной загрузки.
Так что же такое сервер начальной загрузки?
Децентрализованные сети не возникают из воздуха. Узлы должны знать, где искать, чтобы начать присоединение к сети, а затем им нужно найти других участников этой сети для обмена данными, даже если новые узлы включены или отключены. Это достаточно сложно даже до того, как вы добавите конфиденциальность - как вы присоединяетесь и отслеживаете сеть, в которой никто не должен знать, где кто-либо находится?
Самый простой ответ - использовать сервер начальной загрузки.
В децентрализованной сети сервер начальной загрузки подобен организатору вечеринки, который знает всех приглашенных. Это один (или несколько) узлов, которые размещают информацию о других узлах в сети, являясь первой точкой входа и сохраняя адреса каждого в структуре данных, называемой распределенной хеш-таблицей (DHT). Каждый раз, когда узел HOPR запускается, он ищет сервер начальной загрузки по умолчанию, на котором он объявляет о себе, чтобы другие могли его найти. Это довольно стандартный подход. Например, Golem использует аналогичные стратегии, чтобы сообщать поставщикам о частях своей инфраструктуры.
Надпись: В процессе централизованной начальной загрузки в децентрализованной сети (показано слева) обычно имеется одна или несколько точек входа. Узлы регистрируют свои адреса (1) на сервере начальной загрузки, чтобы он записал их, чтобы другие узлы могли их видеть. После обнаружения между узлами предпринимается попытка установить прямое соединение (2) без необходимости в сервере начальной загрузки. Однако, если это не удается, сервер начальной загрузки может продолжать использоваться в качестве узла ретрансляции (3).
Теперь для большинства блокчейн-приложений это не проблема. Во-первых, большинство клиентов (например, geth, bitcoind) обычно требуют, чтобы программное обеспечение было открыто за общедоступным IP-адресом, или просят своих пользователей перенаправить порт в настройках домашней сети, или использовать статический IP-адрес. Во-вторых, когда соединение отсутствует и/или другие одноранговые узлы не могут объявить о себе другим узлам, они могут просто продолжать пинговать другие узлы, пока не достигнут достаточного количества одноранговых узлов, чтобы их можно было принять во внимание. Этого вполне достаточно, поскольку обычно вам нужно только согласовать последнее состояние блока и отслеживать последние транзакции, выполненные узлами.
Однако для HOPR этот подход недостаточно хорош. Без стабильного соединения между узлами пакеты, которыми они обмениваются между собой, могут быть потеряны во время передачи. Это означает, что отправители не будут получать билеты и, таким образом, не будут иметь стимула запускать свой узел. Поскольку HOPR не может функционировать как микснет без надлежащей ретрансляции, на сеть могут быть совершены многочисленные атаки, подвергающие опасности конфиденциальность пользователей HOPR. В отличие от других протоколов, которые могут работать всего с несколькими надежными узлами, для правильной работы HOPR требуется как можно больше одноранговых узлов.
Возвращаясь к нашей первоначальной проблеме, использование сервера начальной загрузки с этой стратегией снижает надежность сети в целом. Когда сервер не работает, новые узлы не могут подключиться, и прямые подключения не могут ретранслироваться. Проще говоря, он становится единой точкой отказа не только для новых узлов, которые не могут подключиться, но и для существующих узлов, которые используют его для ретрансляции.
Представляем DEADR, стратегию уничтожения сервера начальной загрузки
Поскольку серверы начальной загрузки запускают то же программное обеспечение, что и «стандартные» узлы HOPR, мы быстро поняли, что можем повысить надежность серверов начальной загрузки, не ограничивая их только HOPR Association. Проще говоря, если мы настроим узлы HOPR для «идентификации», когда они общедоступны (то есть за общедоступным IP-адресом), их можно будет использовать как в качестве серверов начальной загрузки, так и в качестве обычных узлов.
Вдобавок ко всему, мы можем избежать необходимости запрашивать сетевой DHT с одного сервера начальной загрузки, если каждый раз, когда узел входит в сеть, мы сохраняем его адрес в другом месте, кроме DHT сервера начальной загрузки. Поскольку мы уже используем блокчейн для расчета платежей узлов, мы также можем использовать блокчейн для хранения этих данных и получения их позже. В конце концов, мы используем тот же механизм для хранения наших платежных каналов.
На основе этих идей родилась стратегия Decentralized Entry Advertisement & Distributed Relaying (или просто DEADR). В своей основе DEADR определяет три фундаментальных принципа:
- По возможности узел HOPR за общедоступным IP-адресом должен транслировать свой адрес в наш смарт-контракт HOPR для регистрации в качестве сервера начальной загрузки.
- Все серверы будут иметь возможность регистрироваться в качестве узлов входа в сеть с помощью блокчейна сразу после запуска узла.
- Ретрансляция больше не ограничивается одним сервером начальной загрузки, но может выполняться любым узлом HOPR, ранее зарегистрированным в качестве узла входа.
DEADR уже был опубликован в нашей организации на GitHub, и первая реализация будет запущена как часть нашей версии Kiautschou (на самом деле она была частью нашей версии Stirling, но были еще некоторые функции, которые мы хотели реализовать, прежде чем поделиться с публикой. Как всегда, вы можете проверить все это на нашем GitHub.
Часто задаваемые вопросы
Означает ли это, что мой узел будет использоваться другими участниками узла для ретрансляции трафика? Разве это не приведет к утечке секретности пакетов?
Если ваш узел находится за общедоступным IP-адресом (очень вероятно, если вы используете облачного провайдера), то ваш узел, вероятно, будет использоваться в качестве ретранслятора. Однако, поскольку HOPR использует формат пакета SPHINX, даже если ваш узел используется для ретрансляции трафика, у вас не будет возможности проверять любой трафик, передаваемый по сети.
Повлияет ли использование моего узла в качестве ретранслятора на его производительность или память по сравнению с другими узлами?
Мы не измерили это точно, но анализ нашего сервера начальной загрузки показывает, что это вполне вероятно. Однако, если ваш узел используется в качестве ретранслятора, это означает, что у него есть каналы, открытые для других узлов, и, следовательно, он с большей вероятностью будет задействован для трафика покрытия. Так что вы не останетесь без награды, как и должно быть.
Следующие шаги и путь к стекингу
Ожидайте первую реализацию HOPR с DEADR в нашем следующем релизе, Kiautschou, который, если все будет хорошо, будет доступен для тестирования сообществом к 18 июня. Это не полный публичный релиз, но если вам интересно посмотреть на достигнутый нами прогресс, это хорошая возможность запустить узел и протестировать сеть. Как всегда, пожалуйста, не ставьте более 10 wxHOPR на ваш узел в целях тестирования - нет никакой пользы от добавления большего количества прямо сейчас.
Внедрение DEADR также окончательно разблокирует дорогу для трафика покрытия и стекинга - механизма стимулирования, используемого HOPR Association для запуска трафика в сети.
Другая интересная новость: 18 июня, в день выхода Kiautschou, мы собираемся провести встречу с сообществом, где мы продемонстрируем релиз, расскажем о планах по стакингу и покрытию трафика, а также вспомним, что происходило в HOPR за последние несколько месяцев. Более подробная информация об этой встрече будет представлена на следующей неделе, но мы надеемся, что вы все присоединитесь к нам.
Jose Aguinaga
Руководитель отдела разработки HOPR