К основному содержимому
Все коллекцииEOS Support Media
Сводка c круглого стола операторов нод [февраль 2023 #1]
Сводка c круглого стола операторов нод [февраль 2023 #1]

Опубликована 28 февраля 2023 года

Dario Cesaro avatar
Автор: Dario Cesaro
Обновлено более года назад

Автор: Marco González

Редактор: Randall Roland

Перевод: Evgeny Chirochkin

Каждую неделю операторы Node собираются вместе с разработчиками ядра Antelope и членами сообщества. Главной целью Круглого стола операторов Node является:

"...улучшить протокол Antelope (специально) для операторов узлов".

Встречи проходят в среду в 17 МСК и длятся в течение часа.

1 февраля: Конфигурация. Параметры для операторов нод на Leap v3.2+

На круглом столе 1 февраля были рассмотрены текущие (Leap v3.2) и будущие параметры конфигурации. В середине обсуждения стало ясно, что конфигурация нод - это тема, требующая дальнейшего внимания.

UPDATE: Leap, DUNE и Ubuntu

С недавним выпуском DUNE v1.1, Leap делает еще один шаг вперед в своей миссии сделать разработку и работу над нодами более дружелюбной. Обратите внимание, что поддержка Ubuntu 18.04 будет удалена до мартовского тестирования Leap v4.0. Разработчики, желающие использовать Ubuntu, должны будут обновиться. Официально будут поддерживаться версии Ubuntu 20.04 и 22.04.

Также обратите внимание, что мартовское тестирование не будет включать в себя консенсус-обновление. Вместо этого, сентябрь был упомянут (во время круглого стола 8 февраля) в качестве потенциальной даты принятия консенсуса.

Итоги встречи

Конфигурирование нод для специальных целей оказывается сложным вопросом. Необходима новая документация. Ожидается, что документация по Leap 3.2 будет улучшена, чтобы решать вопросы конфигурации заранее, до обновления.

Время отклика HTTP заняло большую часть встречи. Есть консенсус, что время ответа должно быть, по крайней мере, равно максимальному времени сериализации. Время отклика может быть установлено выше, чтобы обеспечить баланс входящих и исходящих запросов. Например, HTTP-запрос не срабатывает при таймауте на больших блоках. В качестве иллюстрации был использован Atomic Hub.

Кроме того, необходимо рассмотреть вопрос о чрезмерном количестве звонков и общей эффективности. В начале обсуждения было упомянуто, что следует ожидать помощи от "библиотек усиления" и стратегических изменений.

Смотрите запись на YT фонда EOS Network Foundation.

ИТОГИ

Заметки о потенциальной конфигурации нод и их применении заняли большую часть этой встречи. Тема обсуждения на следующей неделе называется: "Ноды специального назначения".

Как лучше всего конфигурировать узлы для конкретных нужд, ожидается, что обсуждение выйдет за рамки следующей недели. Основные области, определенные для улучшения, включают:

  • alleviating pressure (ослабление давления)

  • read-only

  • эффективность

  • block propagation (распространение блоков)

Обратите внимание, что пункты (например, ослабление давления и эффективность) часто взаимосвязаны. Ноды специального назначения и их классификация имеют дело с абстрактными понятиями.

8 февраля: Ноды специального назначения

На круглом столе 8 февраля начался процесс классификации различных способов конфигурирования и использования нод. Разрабатываемый документ по таксономии нод Antelope выходит в преддверии выхода Leap v4.0 (целевая дата - конец марта в тестовой сети Jungle). Ожидайте согласованного обновления Leap уже в сентябре.

Обновление:

В дополнение к намеченным на март и сентябрь срокам ожидается объявление о замораживании кода для Leap 4.0.

О серии дискуссий "Особое назначение"

Ноды специального назначения - это концептуальная модель всех потенциальных вариантов использования. Организация использования и конфигурации нод- тема, которая давно находит отклик у разработчиков EOS. С версией 4.0 операторы нод получат гигантский скачок в оптимизации рутинного управления.

Брайан Хаззард сравнил процесс мозгового штурма нод с "блоками Лего". Как можно заметить, черты и будущие роли нод Antelope часто абстрактны. Обратная связь с сообществом приветствуется. Для получения текущего списка нод или их классификации изучите документ: проект таксономии ролей, которые играют различные ноды "Антилопы".

Предварительные классификации

Рабочие классификации перечислены в проекте документа. На этом круглом столе были рассмотрены:

  • Нода-производитель блоков: подчиняется консенсусу BP для организации и добавления блоков в цепочку

  • Нода ретрансляции блоков: получает блоки от пиров, проверяет заголовки, а затем передает остальным членам группы пиров.

  • Нода ретрансляции транзакций: получает блоки от пиров, проверяет подписи, а затем передает остальным членам группы пиров.

Обзор обсуждаемых типов узлов

Ниже приводится обзор типов нод, обсуждавшихся на этой встрече. Более подробную информацию можно найти на GitHub (см. вопросы за неделю) и в проекте документа таксономии.

Нода производителя блоков

Идентифицированные признаки нод, требующих консенсуса, которые добавляют блоки в цепь, включают:

  • обеспечивать ожидающие транзакции, уделяя основное внимание предотвращению сбоев

  • эффективно принимать действительные ожидающие транзакции

  • изолировать от злоупотреблений (например, TCP, UDP и Интернет)

  • физически разделять безопасность ключей

  • поддерживать открытый канал (как для входящих, так и для исходящих)

    • поддерживать низкое число равных (от 3 до 5)

Лучшие практики конфигурирования включают:

  • частный запуск с доступом к HTTP API для мониторинга локальной сети

  • API производителя для черных списков

См. проект документа по таксономии для будущих соображений.

Ноды передачи блоков

Самая основная классификация - это узел блочной ретрансляции. Определение говорит само за себя. Ретрансляция включает в себя поддержание соединений с аналогами и проверку заголовков блоков. Благодарим Стивена Дизеля за комментарий:

“Хорошие блоки входят, хорошие блоки выходят.”

Преимущество ноды ретрансляции в том, что она может работать с большим количеством пиров (10-15), чем нода BP. Также обратите внимание, что хотя нода ретрансляции блоков может быть публичной, она не должен рекламироваться (например, на bp.json).

Комментарий Стивена иллюстрирует необходимость поддержания группы пиров, способных постоянно предоставлять блоки, готовые к ретрансляции. Поддержание открытого канала включает в себя не только синхронизацию транзакций, но и готовность принимать новые блоки. Неготовность поддерживать готовность была определена как причина пустых блоков.

Ноды передачи транзакций

Как и ноды ретрансляции блоков, нода ретрансляции транзакций может действовать исключительно для передачи блоков после проверки заголовка. Отличительной особенностью узла ретрансляции транзакций является возможность принимать:

  • незавершенные транзакции

  • транзакции от предпочитаемых пиров

  • публичные транзакции через P2P или API

Дополнительные примечания:

Kevin Heifner shared a link to an in-the-works solution to improve block propagation following header validation. EOSUSA Michael shared a diagram of his node setup (see Feb. 8 roundtable).

Кевин Хейфнер поделился ссылкой на готовое решение для улучшения распространения блоков после проверки заголовков. Майкл из EOSUSA поделился схемой настройки своей нодой (см. круглый стол 8 февраля).

Лучшие практики будут изучены и подробно описаны в дальнейшем. Типы нод, похоже, имеют три основные конфигурации:

  • nodeos

  • machine code

  • networking

Смотрите запись на ютуб канале EOS Network Foundation.

ВЫВОДЫ

Следующие пять классификаций нод в проекте документа:

  • Push API Node

  • Node API Node

  • Chain API Node

  • State API Node

  • Developer Node

На следующей неделе ожидается продолжение серии обсуждений нод специального назначения с упором на вышеупомянутые классификации (API), лучшие практики и соответствующую документацию.


Источники и ссылки

Нашли ответ на свой вопрос?