На недавней встрече операторов узлов EOS/Vaulta, состоявшейся 30 апреля 2025 года, разработчики и операторы инфраструктуры собрались, чтобы обсудить важные обновления и проблемы в экосистеме EOS. Среди ключевых тем были патч Antelope Spring 1.1.5, который устранил критические ошибки, и прогресс в разработке функций сетевого взаимодействия на основе сплетен. Встреча также охватила предстоящий пилотный тестнет Jungle для автоматического соединения по сплетням и переход от Фонда сети EOS к Фонду Vaulta. Обсуждения о распространении транзакций и ролях финализаторов подчеркнули продолжающуюся эволюцию моделей управления в сети EOS. Вот краткое резюме основных моментов встречи.
Ключевые выводы
-
Antelope Spring 1.1.5 исправляет серьезные ошибки, улучшая стабильность и производительность узлов.
-
Обновление 3.9.0 RC1 вводит автоматическое соединение по сплетням, улучшая сетевую связанность.
-
Тестнет Jungle будет испытывать реальные сценарии сплетен для проверки устойчивости сети.
-
Фонд Vaulta теперь является основной организацией для проектов GitHub, связанных с EOS.
-
Поддержка IPv4 и IPv6 ограничена, продолжаются проблемы с конфигурацией и рекламой.
Патч Antelope Spring 1.1.5 устраняет критические проблемы компиляции и сбои
Итак, патч Antelope Spring 1.1.5 вышел, и он, похоже, довольно важен. Он решает серьезные проблемы, которые вызывали трудности для операторов узлов.
В основном, была ошибка, из-за которой компиляция контракта OC завершалась неудачей без каких-либо уведомлений, что, конечно, мешало производительности узлов. Перезапуск узлов помогал на некоторое время, но реальное решение — это просто обновление. Также были исправлены редкие сбои, которые происходили с ship, особенно когда соединения обрывались. Если вы используете OC или ship для синхронизации или индексирования, вам, вероятно, стоит обновиться.
Прогресс функции автоматического соединения по сплетням с 3.9.0 RC1
Функция автоматического соединения по сплетням движется вперед, с обновлениями, включенными в релиз 3.9.0 RC1. Это довольно важное событие, потому что оно может изменить способ, которым узлы соединяются и обмениваются информацией. Системные контракты были обновлены для обработки регистрации и удаления ключей пиров, что делает автоматическое соединение возможным.
Вот краткий обзор того, что происходит:
-
Ожидается, что многостороннее (MSIG) предложение о развертывании этого на тестнете Jungle будет скоро, возможно, в начале следующей недели.
-
Если вы хотите протестировать это, инструкции были опубликованы в канале Jungle. Команда ищет отзывы, чтобы убедиться, что все работает гладко.
-
Цель состоит в том, чтобы сделать работу узлов проще и эффективнее, автоматизировав процесс соединения. Больше никаких ручных добавлений пиров, надеемся!
Тестнет Jungle будет пилотировать автоматическое соединение по сплетням с реальными сценариями
Тестнет Jungle собирается стать полигоном для функции автоматического соединения по сплетням. Идея заключается в том, чтобы смоделировать реальные условия сети, чтобы увидеть, насколько хорошо новая система выдерживает нагрузку. Это довольно важный шаг перед тем, как что-либо запустится в основной сети.
Операторов просят минимизировать свои жестко закодированные списки пиров. Это важно, чтобы система сплетен могла быть протестирована должным образом. Сети нужно хорошее количество участников, чтобы действительно проверить ее, особенно когда все становится немного хаотичным.
Говоря о хаосе, планируется ввести некоторые преднамеренно разрушительные сценарии, такие как:
-
Смена портов.
-
Перестановка расписаний.
-
В общем, сделать все немного непредсказуемым.
Одним большим вопросом является то, как брандмауэры будут вести себя с новой системой. Обратная связь от сообщества по конфигурациям брандмауэров определенно необходима, чтобы получить более четкое представление.
Фонд Vaulta заменяет Фонд сети EOS на GitHub
Итак, Фонд сети EOS больше нет на GitHub, и Фонд Vaulta теперь на его месте. Это, по сути, смена названия для организации, которая отвечает за такие вещи, как системные контракты и документация. Все репозитории были перенесены.
Это не очень большая проблема, но стоит об этом знать. Вот что вам следует знать:
-
Название организации изменилось, поэтому репозитории, такие как системные контракты и документация, теперь находятся под новым управлением.
-
Старые ссылки должны автоматически перенаправляться, что приятно. Но все же лучше обновить свои закладки, если они у вас есть.
-
Это не меняет ничего в том, как работает сеть, это скорее административный вопрос.
Ограничения рекламы IPv4 и IPv6 и проблемы конфигурации
В данный момент узлы могут рекламировать только один P2P-адрес. Если вы пытаетесь запустить и IPv4, и IPv6, вам придется внести некоторые изменения в код, чтобы это заработало правильно. Это немного хлопотно, честно говоря. Операторы видят разные вещи из-за того, как работает DNS и как настроены сети. Плюс, не так много людей действительно используют IPv6, так что большинство соединений все еще по IPv4. Это стоит учитывать, если вы настраиваете свой узел.
В данный момент узлы поддерживают только один рекламируемый P2P-адрес; поддержка двойного стека требует изменений в коде.
Вот несколько вещей, которые стоит учитывать:
-
Разрешение DNS может быть немного непредсказуемым.
-
Настройки сети сильно различаются, что приводит к разным впечатлениям.
-
Принятие IPv6 все еще довольно низкое в реальном мире.
Переработка распространения транзакций нацелена на узкие места больших транзакций
Итак, есть такая проблема с большими транзакциями, которые иногда забивают сеть. Команда работает над исправлением, которое должно сделать все более плавным, особенно когда происходит много активности. Идея заключается в том, чтобы сократить сетевую перегрузку, отправляя меньшие "уведомления о транзакциях" вместо всей транзакции сразу.
Представьте это так:
-
Вместо того, чтобы все одновременно кричали полное сообщение, они просто отправляют быстрое уведомление.
-
Транзакции пересылаются только тем пирами, которые еще не были уведомлены, что сокращает ненужные повторы.
-
Это должно действительно помочь производительности, когда сеть очень загружена.
Это обновление запланировано на релиз Spring 1.3. Все это направлено на то, чтобы убедиться, что сеть не застревает, когда происходит множество транзакций одновременно. Это как дать сети немного "второго дыхания".
Обсуждения о финализаторах показывают гибкость в консенсусе Savannah
Итак, было несколько разговоров о финализаторах и о том, как они работают в механизме консенсуса Savannah. Оказывается, есть больше гибкости, чем изначально думали. Основной вывод заключается в том, что роли финализаторов не обязательно должны быть напрямую связаны с предложителями блоков, что открывает возможности для лучшей избыточности.
Подумайте об этом:
-
В данный момент системные контракты настроены на принуждение консенсуса 2/3+1. Но, вот что интересно, это можно настроить вплоть до 51%. Это довольно большое дело.
-
Меньшие цепочки, такие как Ultra, действительно настаивают на моделях консенсуса, которые могут масштабироваться. Им нужно что-то, что работает, не разоряя бюджет.
-
Интересная часть заключается в том, что вы могли бы технически запустить множество легковесных финализаторов для повышения устойчивости к сбоям. Больше финализаторов, меньше риск того, что что-то пойдет не так. Все дело в вариантах, и Savannah, похоже, предлагает множество.
Вес и разделение ролей позволяют продвинутые модели управления
Итак, система настроена на обработку взвешенных голосов финализаторов. Что это значит? По сути, это означает, что вы можете по-разному относиться к производителям и финализаторам. Это открывает интересные возможности для того, как структурируется управление.
Подумайте об этом:
-
Вы могли бы платить только узлам с высоким весом, вознаграждая тех, кто вносит наибольший вклад в безопасность и стабильность сети.
-
Вы могли бы использовать волонтеров для участия с низким весом, позволяя большему количеству людей участвовать, не имея при этом огромной доли.
-
Эта гибкость позволяет вам точно настраивать механизм консенсуса, не внося изменения на уровне протокола. Все дело в регулировке весов и ролей для достижения желаемого результата.
-
Это действительно подчеркивает потенциал для масштабируемых и устойчивых дизайнов, особенно на меньших цепочках, где ресурсы могут быть ограничены. Вы можете креативно распределять обязанности и вознаграждения, чтобы обеспечить здоровье и безопасность сети.
Заключение
В заключение, встреча операторов узлов EOS/Vaulta 30 апреля 2025 года подчеркнула несколько важных разработок в экосистеме EOS. Обсуждения о сетевом взаимодействии на основе сплетен и гибкости ролей финализаторов показали приверженность улучшению производительности и адаптивности сети. Обновления программного обеспечения Antelope и введение новых функций, таких как автоматическое соединение, являются шагами к более эффективной и устойчивой системе. Поскольку меньшие цепочки, такие как Ultra, стремятся извлечь выгоду из этих достижений, потенциал для инновационных моделей управления становится более ясным. В целом, эти изменения отражают проактивный подход к решению проблем, с которыми сталкиваются операторы узлов и более широкое сообщество.
Эта статья была создана с поддержкой технологий, основанных на искусственном интеллекте, с использованием множества авторитетных источников. Финальный контент был тщательно проверен и отредактирован редакционной командой BlockzHub для обеспечения точности, ясности и согласованности. Оригинальные источники информации указаны, когда это необходимо и уместно. Мнения, выраженные в этой статье, не обязательно отражают официальные взгляды или позиции BlockzHub. Эта статья предназначена исключительно для информационных целей и не должна восприниматься как финансовый или профессиональный совет. Инвестирование связано с рисками, и перед принятием инвестиционных решений следует проконсультироваться с квалифицированным финансовым консультантом.