Технологии
Операции с узлами Vaulta: Прогресс Spring 2.0, выпуск патча и дебаты о поиске пиров
Недавнее собрание операторов узлов Vaulta (ранее EOS) собрало участников для обсуждения последних разработок в программном обеспечении Antelope. Разговор затронул срочный выпуск патча для версии 1.2.2, текущий прогресс долгожданной Spring 2.0, а также оживленные дебаты о том, как узлы находят друг друга в сети. Это была насыщенная сессия, посвященная повышению стабильности и упрощению управления системой.
Основные выводы
Операторам узлов рекомендуется срочно установить патч для Antelope Spring 1.2.2, чтобы исправить редкую проблему, которая может остановить производство блоков. Это обновление также включает незначительные улучшения сети.
Разработка Antelope Spring 2.0 продвигается, и вскоре ожидается выпуск Developer Preview 2, который представит новую функцию под названием «события». Для этого релиза планируется отдельная тестовая сеть.
Developer Preview 3 уже на подходе и станет последней возможностью внести существенные изменения в интерфейсы перед окончательным выпуском Spring 2.0, с акцентом на стабильность.
Продолжается дискуссия о том, как узлы соединяются, поскольку текущие методы не позволяют многим операторам подключаться. Рассматриваются такие идеи, как начало работы с небольшой группой надежных «хаб-узлов».
Операторы узлов просят более простые способы поиска других узлов, предлагая такие инструменты, как получение списков пиров по URL или использование простых файлов JSON.
Настоятельно рекомендуется выпуск патча Antelope Spring 1.2.2
Команда разработчиков Antelope призвала операторов узлов обновить свои системы до патча 1.2.2 для версии Spring. Это обновление важно, поскольку оно устраняет редкую проблему, которая может остановить производство блоков. Оно также включает в себя небольшие улучшения того, как узлы взаимодействуют друг с другом, и исправляет несколько других ошибок. В интересах стабильности сети всем рекомендуется установить этот патч как можно скорее.
Прогресс разработки Antelope Spring 2.0
Разработка Antelope Spring 2.0 продвигается, команда работает над несколькими ключевыми функциями. Выпуск Developer Preview 2 запланирован на ближайшее время, вероятно, на конец сентября или начало октября. Этот предварительный просмотр представит новый класс данных под названием «события», который, как ожидается, изменит способ обработки определенной информации в сети. Для поддержки этого выпуска создается отдельная временная тестовая сеть, отличная от существующей тестовой сети Jungle. Это позволит целенаправленно тестировать новые функции, прежде чем они будут более широко интегрированы. Команда также планирует Developer Preview 3, который будет направлен на доработку функций, представленных в Preview 2, и устранение любых компромиссов. Этот третий предварительный просмотр предназначен для того, чтобы стать последней возможностью для внесения существенных изменений в интерфейсы, с акцентом на повышение надежности синхронных вызовов и новой функциональности событий.
Developer Preview 3 на горизонте
Команда готовится к выпуску Developer Preview 3, который станет последней возможностью для внесения существенных изменений в интерфейс перед полным выпуском Antelope Spring 2.0. Этот предстоящий предварительный просмотр направлен на устранение проблем и компромиссов, возникших во время разработки Preview 2. Основное внимание будет уделено повышению надежности вызовов синхронизации и доработке функциональности событий, которая была представлена ранее.
Ключевые направления работы для Developer Preview 3 включают:
Повышение стабильности и надежности процесса синхронизации узлов.
Дальнейшая разработка и тестирование нового класса данных «события».
Устранение любых оставшихся ошибок или узких мест в производительности, выявленных в предыдущих предварительных просмотрах.
Обеспечение более плавного перехода для операторов узлов, обновляющихся до новой версии.
Дебаты о пиринге по протоколу Gossip и обнаружении сети
Дискуссия о том, как узлы находят друг друга в сети Antelope, часто называемая обнаружением пиров, была горячей темой. Прямо сейчас кажется, что не все подключаются к такому количеству других узлов, к какому могли бы. Это привело к множеству разговоров о текущем методе, который основан на системе, называемой «gossip peering». По сути, узлы обмениваются информацией о других узлах, которые им известны. Однако эффективность этой системы, похоже, является предметом споров.
Было предложено несколько идей для улучшения ситуации. Одно из предложений заключалось в том, чтобы начинать новые узлы с небольшой, надежной группой «хаб-узлов». Это дало бы им прочную основу для начала подключения. Другой обсуждаемый аспект заключался в балансе между ручной настройкой подключений к конкретным пирам и предоставлением системе gossip автоматического их поиска. Основная проблема, похоже, заключается в обеспечении надежного и широкомасштабного подключения без чрезмерного усложнения для операторов узлов.
Это, естественно, привело к призывам к более простым способам поиска пиров. Многие операторы выразили желание иметь инструменты, которые могли бы получать списки пиров по URL или из файла. Идея публикации списков начальных точек подключения, возможно, в формате JSON, набирает некоторую поддержку. Также упоминалось о добавлении способов проверки легитимности этих списков, просто для дополнительной безопасности.
Призывы к упрощению инструментов обнаружения пиров
Многие операторы узлов выразили желание иметь более простые способы поиска и подключения к другим узлам в сети. Текущие методы могут быть несколько сложными, и есть стремление сделать этот процесс более простым. Распространенное предложение — позволить операторам указывать URL или путь к файлу, из которого узел может получить список пиров для подключения. Это позволит отказаться от необходимости вручную настраивать каждый пир. Другая идея, набирающая поддержку, включает публикацию списков начальных узлов в формате JSON. Такой структурированный подход может облегчить узлам загрузку своих подключений. Также ведутся разговоры о добавлении необязательных способов проверки надежности этих списков пиров, что добавляет уровень безопасности к процессу обнаружения.
Долгосрочные улучшения на рассмотрении
Помимо немедленных исправлений и предстоящих выпусков, команда рассматривает способы сделать сеть более надежной и простой в управлении с течением времени. Одна из обсуждаемых идей включает создание легковесных ретрансляционных узлов. Эти узлы, потенциально построенные с использованием чего-то вроде Wharfkit, могли бы помочь более эффективно распространять информацию по сети.
Также ведутся разговоры о том, чтобы сделать систему gossip умнее. Это может означать расширение способов обмена информацией между узлами и поиск способов автоматического управления соединениями, чтобы операторам не приходилось выполнять столько ручной настройки.
Кроме того, группа планирует вернуться и рассмотреть некоторые функции, которые были предложены ранее, но так и не были включены в код. Эти старые идеи могут предложить решения некоторых текущих проблем с тем, как узлы находят друг друга.
Подведение итогов встречи и дальнейшие шаги
Обсуждения завершились четким набором действий и областей для дальнейшего внимания. Операторам узлов настоятельно рекомендуется начать тестирование предстоящего Developer Preview 2 Antelope Spring, как только он станет доступен. Этот практический опыт жизненно важен для сбора обратной связи, особенно в отношении последствий нового класса данных «события». Команда ищет широкое участие, чтобы помочь оценить, как эти события будут функционировать в реальных сценариях.
Из дневных бесед выделились несколько ключевых моментов:
Был подтвержден интерес сообщества к более простым методам обнаружения пиров, таким как «обнаружение для бедных» с использованием списков начальных узлов. Этот подход, который включает получение списков пиров по URL или из файла, был расценен как практический шаг вперед.
Было согласовано дальнейшее исследование легковесных ретрансляционных узлов, потенциально использующих такие инструменты, как Wharfkit, как способ улучшить распространение в сети и облегчить процесс подключения для операторов.
Команда пересмотрит ранее предложенные, но неинтегрированные функции, направленные на улучшение общих механизмов обнаружения сети.
Эти следующие шаги направлены на удовлетворение насущных потребностей в стабильности и удобстве использования, а также на создание основы для более надежных долгосрочных решений в управлении сетью.
Эта статья была создана с поддержкой технологий, основанных на искусственном интеллекте, с использованием множества авторитетных источников. Финальный контент был тщательно проверен и отредактирован редакционной командой BlockzHub для обеспечения точности, ясности и согласованности. Оригинальные источники информации указаны, когда это необходимо и уместно. Мнения, выраженные в этой статье, не обязательно отражают официальные взгляды или позиции BlockzHub. Эта статья предназначена исключительно для информационных целей и не должна восприниматься как финансовый или профессиональный совет. Инвестирование связано с рисками, и перед принятием инвестиционных решений следует проконсультироваться с квалифицированным финансовым консультантом.
0 0.0 27от The Briefing EngineНовичок .jpeg)
