На прошлой неделе операторы узлов Vaulta, ранее известной как EOS, собрались для обсуждения важных обновлений. На встрече обсуждался прогресс в разработке программного обеспечения Antelope Spring 2.0, работа новой системы обмена данными (gossip system) для подключения производителей блоков, а также идеи по повышению безопасности сетевых соединений. Операторы узлов поделились своим опытом решения технических проблем и настройки своих сетей, поддерживая при этом бесперебойную работу блокчейна Vaulta.
Основные выводы
-
Вышла первая предварительная версия для разработчиков (Developer Preview 1) Antelope Spring 2.0, сфокусированная на синхронных вызовах; более значительные изменения ожидаются в Preview 2 примерно в сентябре.
-
Новая система событий потребует от операторов узлов установки лимитов хранения, более подробная информация будет предоставлена по мере продолжения разработки.
-
Внедрение системы однорангового взаимодействия (gossip peering) происходит, но не все крупные производители блоков еще подключены, что означает, что сеть не полностью связана.
-
Настройка сети обмена данными оказалась сложной, с проблемами в поиске одноранговых узлов и предложениями использовать размещенные списки для помощи новым узлам в подключении.
-
Новая идея заключается в том, чтобы позволить операторам узлов создавать списки разрешенных или заблокированных одноранговых узлов для системы обмена данными, чтобы помочь управлять соединениями и безопасностью.
Прогресс разработки Antelope Spring 2.0
Разработка Antelope Spring 2.0 продолжается, и первая предварительная версия для разработчиков (DP1) уже выпущена. Этот первоначальный релиз обеспечивает поддержку синхронных вызовов и предоставляет доступ к тестовой среде. Разработчикам предлагается перестроить свои контракты с использованием CDT 5.0 dev 1.1. В настоящее время DP1 не сильно меняет ситуацию для операторов узлов, так как более значительные изменения ожидаются с DP2. Следующая предварительная версия, DP2, запланирована на начало сентября и будет включать новую систему событий, а также улучшения в скорости работы.
Предварительный обзор системы событий и ее последствия
Предстоящая предварительная версия для разработчиков 2 (DP2) для Antelope Spring 2.0 должна представить новую систему событий. Эта система позволит транслировать эфемерные события, которые криптографически фиксируются в данных консенсуса. Для операторов узлов это означает введение нового параметра конфигурации, требующего от них установки минимальных настроек хранения для этих событий. Точные детали и лучшие практики управления этими событиями все еще разрабатываются по мере развития, но DP2 предоставит первоначальные функции и конфигурации, относящиеся к узлам, необходимые для их обработки. Последствия для операторов узлов значительны, так как им потребуется адаптировать свои конфигурации для размещения этого нового потока данных.
Функциональность системы событий
-
События — это временные сообщения.
-
Они защищены криптографическими обязательствами в консенсусе.
-
Операторы узлов должны определять лимиты хранения.
Требования к конфигурации для операторов узлов
-
Установить минимальное хранилище для эфемерных событий.
-
Мониторинг потока данных событий.
-
Адаптация к новым параметрам конфигурации в DP2.
Ожидаемое влияние системы событий
-
Новые типы данных для управления.
-
Потенциал для улучшенного мониторинга сети.
-
Необходимость обновления операционных процедур.
Статус внедрения однорангового взаимодействия BP по протоколу Gossip
Несколько ведущих производителей блоков (BP) предприняли шаги для регистрации своих одноранговых ключей, что является хорошим началом. Мы наблюдаем частичные одноранговые соединения, например, между Genereos и Eosphere, что показывает, что базовая связность для некоторых функциональна. Однако это еще не происходит по всей сети. Внедрение все еще находится в процессе, и большая координация и четкие подтверждения от BP действительно помогли бы ускорить процесс. Мы не достигли критической массы внедрения, что, возможно, является причиной того, что сеть обмена данными не полностью связана, как ожидалось.
Технические проблемы при формировании сети Gossip
Настройка стабильной сети обмена данными (gossip network) для производителей блоков (BP) не так проста, как может показаться. Мы сталкиваемся с несколькими препятствиями. Во-первых, поиск других одноранговых узлов может быть непредсказуемым. Это часто происходит потому, что некоторые BP могут не иметь полностью настроенных конфигураций, или, возможно, брандмауэры мешают, блокируя эти соединения. Это означает, что иногда узлы просто не могут видеть друг друга, хотя должны.
Сейчас, чтобы запустить процесс, люди предлагают вручную добавлять одноранговые узлы для начальной загрузки соединений. Это работает, но не идеально для децентрализованной системы, которая должна находить свой собственный путь. Нам не хватает способа для узлов автоматически обнаруживать друг друга, например, системы "начальных одноранговых узлов", которая помогает новым узлам находить существующие. Некоторые идеи включают использование размещенных JSON-списков одноранговых узлов для помощи в этой первоначальной настройке.
Предлагаемая функция белого/черного списка для соединений Gossip
Для управления соединениями в сети обмена данными рассматривается функция, позволяющая использовать белые и черные списки одноранговых узлов. Это даст операторам узлов больше контроля над тем, к каким другим узлам они подключаются. Идея состоит в том, чтобы позволить операторам указывать конкретные учетные записи производителей блоков (BP), которым разрешено или запрещено подключаться.
Эта предлагаемая система будет работать наряду с существующими ручными конфигурациями одноранговых узлов. Любые одноранговые узлы, которые вы вручную добавляете в конфигурацию своего узла, по-прежнему будут иметь приоритет. Однако для одноранговых узлов, обнаруженных через протокол обмена данными, будут применяться правила белого и черного списков.
Основная цель этой функции — предоставить способ предотвращения соединений с узлами, которые могут работать со сбоями или подвергаться какой-либо форме атаки. Это рассматривается как способ уменьшить необходимость для операторов управлять сложными внешними правилами брандмауэра только для фильтрации входящего трафика обмена данными.
Вот как это может работать:
-
Белый список: Список конкретных учетных записей BP, которым явно разрешено подключаться к вашему узлу через протокол обмена данными.
-
Черный список: Список конкретных учетных записей BP, которым явно запрещено подключаться к вашему узлу через протокол обмена данными.
-
Поведение по умолчанию: Если ни белый, ни черный список не настроены, или если одноранговый узел не находится ни в одном из списков, узел, вероятно, будет следовать своему поведению подключения по умолчанию, потенциально разрешая соединение.
Проблемы с идентификацией одноранговых узлов и смягчением злоупотреблений
Проблемы с идентификацией одноранговых узлов
Одна из главных проблем с системой обмена данными заключается в том, чтобы выяснить, кто на самом деле что отправляет. Поскольку сообщения могут передаваться разными узлами, трудно отследить, откуда на самом деле начался вредоносный трафик. Это затрудняет пресечение проблем в источнике. Если вы заблокируете один узел, который вызывает проблемы, он может продолжать распространяться через другие узлы, которые вы еще не идентифицировали. Это немного похоже на игру "ударь крота", и нет простого способа точно узнать, кто был первоначальным отправителем.
Стратегии смягчения злоупотреблений
Чтобы справиться с этим, люди просят о лучших способах контроля того, кто может подключаться и какой трафик разрешен. Это означает нечто большее, чем простое блокирование. Нам нужны системы, которые могут проверять личность одноранговых узлов и более тщательно применять правила. Текущая настройка на самом деле не дает нам такого детального контроля, что является большим препятствием для поддержания чистоты и безопасности сети. Очевидно, что простого блокирования отдельных узлов недостаточно, когда сеть предназначена для такой свободной передачи информации.
Сетевые ограничения, влияющие на жизнеспособность функций
Когда мы рассматриваем возможность внедрения новых функций, особенно таких, как предлагаемые белый и черный списки для соединений gossip, мы сталкиваемся с некоторыми реальными проблемами в сети. Это не всегда так просто, как просто щелкнуть выключателем. Например, многие узлы используют прокси-серверы для подключения. Это довольно распространено, но это означает, что исходный IP-адрес соединения скрывается. Это затрудняет точное определение источника трафика, что является большой проблемой, если вы пытаетесь контролировать, кто может подключаться.
Затем есть сама базовая технология. Протокол TCP, который используется gossip, не предлагает такого же тонкого контроля над тем, кто подключается, как, например, HTTP. Это означает, что мы не можем легко настроить правила для разрешения или блокировки конкретных соединений на основе подробной информации. Кроме того, с динамическими IP-адресами и всеми этими различными настройками прокси-серверов попытка применить строгий белый или черный список становится настоящей головной болью. Кажется, что мы постоянно догоняем.
Из-за этих проблем многие операторы узлов обнаруживают, что традиционные средства контроля на уровне брандмауэра по-прежнему являются наиболее практичным и эффективным способом управления сетевым трафиком. Они привыкли к этому, и это работает надежно, даже если это не так интегрировано, как могла бы быть функция, специфичная для gossip. Нам нужно рассмотреть, могут ли предлагаемые функции действительно преодолеть эти существующие сетевые реалии или они просто добавят больше сложности, не решая основных проблем.
Заключение и дальнейшие шаги
Разработка Antelope Spring 2.0, в частности, предстоящая Developer Preview 2 (DP2) и ее интегрированная система событий, представляет собой важную область для предстоящего тестирования и обратной связи от операторов узлов. Продолжение усилий по поощрению и мониторингу внедрения протокола Gossip для однорангового взаимодействия производителей блоков (BP) также важно. Предлагаемая функция белого и черного списков для управления соединениями gossip была признана потенциально полезным инструментом, хотя ее текущие ограничения означают, что она не является полным решением для сетевой безопасности. Будут собраны дальнейшие исследования и мнения сообщества для оценки практической жизнеспособности и эффективности внедрения таких функций.
Ключевые области внимания для операторов
-
DP2 и система событий: Операторы узлов должны подготовиться к тестированию этих компонентов по мере их появления.
-
Внедрение однорангового взаимодействия Gossip: Поощряется постоянное участие и подтверждение успешного однорангового взаимодействия для создания более надежной сети gossip.
-
Обратная связь по функциям безопасности: Предоставление информации о предлагаемом механизме белого/черного списка и других проблемах безопасности поможет сформировать будущие разработки.
Будущие соображения
-
Надежность сети Gossip: Решение проблем с обнаружением одноранговых узлов и стабильностью соединения остается приоритетом.
-
Идентификация и злоупотребления: Разработка более эффективных методов идентификации и смягчения злоупотреблений в сети gossip требует дальнейшего исследования.
-
Сетевые реалии: Практические ограничения, связанные с маскировкой IP и существующей сетевой инфраструктурой, должны быть тщательно учтены при разработке новых функций.
Эта статья была создана с поддержкой технологий, основанных на искусственном интеллекте, с использованием множества авторитетных источников. Финальный контент был тщательно проверен и отредактирован редакционной командой BlockzHub для обеспечения точности, ясности и согласованности. Оригинальные источники информации указаны, когда это необходимо и уместно. Мнения, выраженные в этой статье, не обязательно отражают официальные взгляды или позиции BlockzHub. Эта статья предназначена исключительно для информационных целей и не должна восприниматься как финансовый или профессиональный совет. Инвестирование связано с рисками, и перед принятием инвестиционных решений следует проконсультироваться с квалифицированным финансовым консультантом.