Обновление акселератора

warning

Эта страница переведена сообществом на русский язык, но нуждается в улучшениях. Если вы хотите принять участие в переводе свяжитесь с @alexgton.

в разработке

Эта функция сейчас доступна только в тестовой сети! Используйте на свой страх и риск.

Главной особенностью блокчейна TON является возможность распределять обработку транзакций по узлам сети и переключение с "все проверяют все транзакции" на "каждая транзакция проверяется защищенным подмножеством валидаторов". Эта способность к бесконечному горизонтальному масштабированию пропускной способности по шардам, когда один воркчейн разделяется на необходимое количество шардчейнов, отличает TON от других сетей L1.

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

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

Акселератор

Акселератор — это предстоящее обновление, разработанное для улучшения масштабируемости блокчейна. Его основные функции:

Частичные узлы: узел сможет отслеживать определенные шарды блокчейна вместо всего набора шардов.
Инфраструктура Liteserver: операторы Liteserver смогут настроить каждый LS для отслеживания набора шардов, а liteclients будут выбирать подходящий LS для каждого запроса.
Разделение Коллатор-Валидатор: валидаторы будут отслеживать только мастерчейн, что значительно снизит их нагрузку. Валидатор будет использовать новые узлы Коллатор для сопоставления новых шард блоков.

Обновление акселлератора в настоящее время частично реализовано в тестовой сети. Узлы тестовой сети можно настроить для мониторинга подмножества шардов, а liteclient можно настроить на такие частичные liteservers.

Разделение коллатор-валидатор еще не развернуто в тестовой сети. Однако можно протестировать некоторые его части, запустив собственные узлы коллатор.

Частичные узлы

Раньше каждый узел TON должен был загружать все шарды блокчейна, что ограничивало масштабируемость. Вот почему основная функция обновления — разрешить узлам отслеживать только подмножество шардов.

Узел отслеживает шард, если он сохраняет это состояние шарда и загружает все новые блоки в шард.

Каждый узел всегда отслеживает мастерчейн.

У бейсчейна есть параметр monitor_min_split в ConfigParam 12, который в тестовой сети установлен на 2. Он делит бейсчейн на 2^monitor_min_split=4 группы шардов:

Шарды с префиксом 0:2000000000000000
Шарды с префиксом 0:60000000000000000
Шарды с префиксом 0:a0000000000000000
Шарды с префиксом 0:e00000000000000000

Узлы могут контролировать только группу шардов в целом. Например, узел может контролировать все шарды с префиксом 0:2000000000000000 но не может отслеживать 0:1000000000000000, не включая 0:30000000000000000.

Гарантируется, что шарды из разных групп не будут объединяться. Это гарантирует, что отслеживаемый шард не будет неожиданно объединяться с неконтролируемым шардом.

Конфигурация узла

Обновите свой узел до последнего коммита ветки testnet.

По умолчанию узел отслеживает все шарды. Отключите это поведение, добавив флаг -M в validator-engine. Узел с флагом -M отслеживает только мастерчейн. Для отслеживания шардов бейсчейна используйте флаг --add-shard <wc:shard>. Например:

validator-engine ... -M --add-shard 0:2000000000000000 --add-shard 0:e000000000000000

Эти флаги настраивают узел на отслеживание всех шардов с префиксами 0:20000000000000000 и 0:e00000000000000000. Вы можете добавить эти флаги к существующему узлу или запустить новый узел с этими флагами.

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

Примечание 2: Если установлен флаг -M, то узел начнет загрузку недостающих шардов, что может занять некоторое время. То же самое верно, если новые шарды добавляются позже с помощью --add-shard.

Примечание 3: --add-shard 0:08000000000000000 добавляет всю группу шардов с префиксом 0:2000000000000000 из-за monitor_min_split.

Низкоуровневая конфигурация

Флаг --add-shard является сокращением для некоторых команд консоли валидатора. Узел хранит список шардов для мониторинга в конфигурации (см. файл db/config.json, раздел shards_to_monitor). Этот список можно изменить с помощью validator-engine-console:

add-shard <wc>:<shard>
del-shard <wc>:<shard>

Флаг --add-shard X эквивалентен команде add-shard X.

Конфигурация Lite client

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

{
  "liteservers_v2": [
    {
      "ip": 123456789, "port": 10001,
      "id": { "@type": "pub.ed25519", "key": "..." },
      "slices": [
        {
          "@type": "liteserver.descV2.sliceSimple",
          "shards": [
            { "workchain": 0, "shard": 2305843009213693952 },
            { "workchain": 0, "shard": -6917529027641081856 }
          ]
        }
      ]
    },
    {
      "ip": 987654321, "port": 10002,
      "id": { "@type": "pub.ed25519", "key": "..." },
      "slices": [
        {
          "@type": "liteserver.descV2.sliceSimple",
          "shards": [
            { "workchain": 0, "shard": 6917529027641081856 },
            { "workchain": 0, "shard": -2305843009213693952 }
          ]
        }
      ]
    }
  ],
  "validator": "...",
  "dht": "..."
}

Эта конфигурация включает два liteserver.

Первый отслеживает шарды с префиксами 0:20000000000000000 и 0:a00000000000000000.
Второй отслеживает шарды с префиксами 0:60000000000000000 и 0:e00000000000000000.

Оба liteserver отслеживают мастерчейн, явно включать мастерчейн в конфигурацию не требуется.

Примечание: Чтобы получить значение для "shard": 6917529027641081856, преобразуйте идентификатор шарда в шестнадцатеричном формате (60000000000000000) в десятичное число в диапазоне [-2^63,2^63).

lite-client и tonlib поддерживают этот новый глобальный формат конфигурации. Клиенты выбирают подходящий liteserver для каждого запроса в зависимости от его шарда.

Прокси liteserver

Прокси liteserver — это сервер, который принимает стандартные запросы liteserver и пересылает их другим liteserver.

Его основная цель — создать один liteserver, который действует как LS со всеми шардами, при этом распределяя входящие запросы по соответствующим дочерним liteserver. Это устраняет необходимость для клиентов поддерживать несколько TCP-соединений для разных шардов и позволяет старым клиентам использовать шардированные liteserver через прокси.

Использование:

proxy-liteserver -p <tcp-port> -C global-config.json --db db-dir/ --logname ls.log

Перечислите все дочерние liteserver в глобальной конфигурации. Это могут быть частичные liteserver, как показано в примере выше.

Чтобы использовать прокси liteserver в клиентах, создайте новую глобальную конфигурацию с этим прокси в разделе liteservers. См. db-dir/config.json:

{
   "@type" : "proxyLiteserver.config",
   "port" : 10005,
   "id" : {
      "@type" : "pub.ed25519",
      "key" : "..."
   }
}

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

Ключ генерируется при первом запуске и остается неизменным после перезапуска. Если вам нужно использовать существующий закрытый ключ, поместите файл закрытого ключа в db-dir/keyring/<key-hash-hex> и запустите proxy-liteserver с флагом --adnl-id <key-hash-hex>.

Разделение Колллатор-Валидатор

Общие сведения

В настоящее время валидаторы тестовой и основной сети работают следующим образом:

Все валидаторы отслеживают все шарды.
Для каждого шарда случайным образом выбирается группа валидаторов для генерации и проверки новых блоков.
Внутри группы валидаторов, валидаторы собирают (генерируют) новые блоки-кандидаты по одному, другие валидаторы проверяют и подписывают их.

Изменения в обновлении акселлератора:

Валидаторы отслеживают только мастерчейн, что значительно снижает их нагрузку. (еще не включено в тестовой сети)
Процесс выбора групп валидаторов и подписания блоков остается неизменным.
Валидаторы Masterchain сопоставляют и проверяют блоки, как и раньше.
Сопоставление блока шарда требует мониторинга шарда. Поэтому вводится новый тип узла, называемый коллатор. Валидаторы шарда отправляют запросы узлам-коллекторам для генерации кандидатов на блоки.
Валидаторы по-прежнему проверяют блоки самостоятельно. Коллатор прикрепляет сопоставленные данные (доказательство состояния шарда) к блокам, что позволяет выполнять проверку без мониторинга шарда.

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

Запуск коллатор узла

Обновите свой узел до ветки accelerator.

Чтобы настроить коллатор узел, используйте следующие команды validator-engine-console:

new-key
add-adnl <key-id-hex> 0
add-collator <key-id-hex> <wc>:<shard>

new-key и add-adnl создают новый адрес adnl. add-collator запускает коллатор узел для заданного шарда на этом адресе adnl. Коллатор для шарда X может создавать блоки для всех шардов, которые являются предками или потомками X. Коллатор узлы не могут создавать блоки для мастерчейна, только для бейсчейна.

В простом случае вы можете взять узел, который отслеживает все шарды, и запустить коллатор для всех шардов: add-collator <key-id-hex> 0:80000000000000000.

Также вы можете запустить частичный узел, который отслеживает и сортирует только подмножество шардов. Пример: запустить узел с флагами -M --add-shard 0:20000000000000000, запустить коллатор с командой add-collator <key-id-hex> 0:20000000000000000. Этот коллатор будет генерировать блоки в первой группе шардов.

Примечание 1: Коллатор узел генерирует блоки автоматически, даже без запросов от валидаторов.

Примечание 2: Коллатор узел, настроенный на генерацию блоков в определенном шарде, не требуется для мониторинга других шардов, даже если исходящие очереди сообщений из соседних состояний шардов необходимы для сортировки. Это достигается путем загрузки этих очередей сообщений с других узлов, которые контролируют соответствующие шарды.

Настройка валидатора

Обновите валидатор до ветки accelerator.

По умолчанию валидаторы сами сортируют все блоки. Чтобы использовать коллатор узлы, создайте список коллатор узлов и предоставьте его валидатору с помощью validator-engine-console:

set-collators-list <имя_файла> устанавливает новый список сортировщиков.
clear-collators-list восстанавливает работу валидатора до состояния по умолчанию.
show-collators-list отображает текущий список.

Список коллатор узлов — это файл json. Он содержит список идентификаторов adnl коллатор узлов для каждого шарда.

Пример 1: коллаторы для всех шардов

{
  "shards": [
    {
      "shard_id": { "workchain": 0, "shard": -9223372036854775808 },
      "self_collate": true,
      "select_mode": "random",
      "collators": [
        { "adnl_id": "jKT47N1RExRD81OzeHcH1F194oxHyHv76Im71dOuQJ0=" },
        { "adnl_id": "H39D7XTXOER9U1r/CEunpVbdmd7aNrcX0jOd8j7pItA=" }
      ]
    }
  ]
}

Этот список содержит два коллатора, которые могут генерировать блоки во всех шардах в бейсчейне (shard_id - 0:80000000000000000).

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

"self_collate": true означает, что если все коллаторы отключены, то валидатор будет собирать блок самостоятельно. Рекомендуется использовать эту опцию для тестирования, поскольку валидаторы все еще могут генерировать блоки шардов.

### Пример 2: частичные коллатор узлы

{
  "shards": [
    {
      "shard_id": { "workchain": 0, "shard": 4611686018427387904 },
      "self_collate": true,
      "select_mode": "random",
      "collators": [
        { "adnl_id": "jKT47N1RExRD81OzeHcH1F194oxHyHv76Im71dOuQJ0=" }
      ]
    },
    {
      "shard_id": { "workchain": 0, "shard": -6917529027641081856 },
      "self_collate": true,
      "select_mode": "random",
      "collators": [
        { "adnl_id": "H39D7XTXOER9U1r/CEunpVbdmd7aNrcX0jOd8j7pItA=" }
      ]
    },
    {
      "shard_id": { "workchain": 0, "shard": -2305843009213693952 },
      "self_collate": true,
      "select_mode": "random",
      "collators": []
    }
  ]
}

В этом списке есть один коллатор для префикса 0:40000000000000000, один коллатор для префикса 0:a0000000000000000 и ни одного коллатора для 0:e0000000000000000. self_collate - это true, поэтому валидатор будет сортировать самостоятельно, если ни один коллатор для шарда не будет в сети.

Формальный протокол для выбора коллатора

Список коллатор узлов содержит список shards. Каждая запись имеет следующие параметры: shard_id, select_mode, self_collate, collators. Чтобы сгенерировать блок в шарде X, валидатор делает следующее:

Если X - это мастерчейн, то валидатор сам генерирует блок.
Возьмите первую запись из shards, где shard_id пересекается с X.
Валидатор периодически пингует коллаторы из списка, чтобы определить, какие из них находятся в сети и готовы ответить.
Выберите онлайн коллатора из списка collators. select_mode определяет метод выбора:
- random: случайный коллатор онлайн.
- ordered: первый из списка (пропуская автономные коллаторы).
- round_robin: последовательно выбирайте коллаторы (пропуская автономные коллаторы).
Отправьте запрос выбранному коллатору.
Если все коллаторы находятся в сети, а self_collate равен true, то валидатор сам генерирует блок.

Статистика коллатор менеджера

Команда collation-manager-stats в validator-engine-console отображает состояние коллаторов: какие коллаторы в данный момент используются, а какие находятся в сети.

Белый список коллаторов

По умолчанию узел коллатора принимает запросы от любого валидатора. Вы можете включить белый список, чтобы разрешить запросы только от определенных валидаторов, используя validator-engine-console:

collator-whitelist-enable 1 включает белый список.
collator-whitelist-enable 0 отключает белый список.
collator-whitelist-add <validator-adnl-id-hex> добавляет валидатор в белый список.
collator-whitelist-del <validator-adnl-id-hex> удаляет валидатор из белого списка.

Полные сопоставленные данные

По умолчанию валидаторы, предлагающие новый блок в наборе валидаторов, не прикрепляют данные, которые подтверждают состояние "до блокировки". Эти данные должны быть получены другими валидаторами из локально сохраненного состояния. Таким образом, старые (из главной ветви) и новые узлы могут достичь консенсуса, но новые валидаторы должны следить за всем состоянием сети.

После того, как ton::capFullCollatedData возможности в параметре конфигурации сети 8 будут включены, collated_data будет включен в блоки, и валидаторы смогут избавиться от мониторинга чего-либо, кроме мастерчейна: входящих данных будет достаточно для полной проверки корректности блока.

Следующие шаги

Полная и простая в использовании поддержка валидации с помощью коллаторов в MyTONCtrl
Оптимизация размера collated_data: в настоящее время это нормально для большинства блоков, но некоторые транзакции могут вызвать чрезмерное использование данных
Включение трансляции collated_data
Поддержка автоматической оплаты сортировки от MyTONCtrl для создания рынка сопоставления данных и, таким образом, повышения надежности

Акселератор

Частичные узлы

Конфигурация узла​

Низкоуровневая конфигурация​

Конфигурация Lite client​

Прокси liteserver​

Разделение Колллатор-Валидатор

Общие сведения​

Запуск коллатор узла​

Настройка валидатора​

Пример 1: коллаторы для всех шардов​

### Пример 2: частичные коллатор узлы​

Формальный протокол для выбора коллатора​

Статистика коллатор менеджера​

Белый список коллаторов​