Проектирование и реализация окон обслуживания
У нас уже есть реализация этой функции для проверки и тестирования: #998 (https://github.com/gonka-ai/gonka/pull/998).
Понятно, спасибо, что обратили на это мое внимание. Тогда я закрою эту дискуссию.
Русский перевод
Привет. Прочитав дорожную карту сети сообщества Gonka (https://docs.google.com/document/d/1wPXTM40CnXyd8Hz_dvf7H1n6KQDqjw0RzppMx92xR8U/edit?pli=1&tab=t.0#heading=h.c2j5tayw22w8), мы увидели проект 2 в треке 3 под названием «Окна обслуживания хостов», которые по состоянию на 06 марта 2026 г. имеют следующее описание (скопировано и вставлено сюда):
Проект должен предоставить хосту возможность заранее объявить окно обслуживания, проверить, разрешено ли окно обслуживания, временно отказаться от части своих обязанностей и вернуться к работе без отдельного согласования и без штрафов за запланированный простой.
Метрики:
- ПЕРВИЧНЫЙ: удержание принимающей стороны и доверие.
- ВТОРИЧНОЕ: надежность и доверие сети.
Что это дает сети:
Сеть получает формальный процесс обслуживания, который отделяет запланированные простои от незапланированных сбоев и снижает количество предотвратимых ошибок, штрафов и споров.
Возможная общая схема проекта для этого проекта может выглядеть следующим образом:
- Создайте новое сообщение, например MsgSetScheduledMaintenance, позволяющее хосту планировать ожидаемое время простоя для обслуживания и транслировать его в основную сеть. Точные поля в этом сообщении являются предметом обсуждения, но оно должно содержать, по крайней мере, временную метку начала обслуживания (например: Maintenance_start_timestamp). Основная сеть должна изменить статус участника: на DRAINING перед техническим обслуживанием (хост завершит свои текущие сеансы, но не будет участвовать в новых) и на MAINTENANCE (хост временно отключен из-за планового обслуживания). Возможно, в этой государственной машине возникнет необходимость в большем количестве статусов и переходов, которые следует изучить. Время DRAINING может быть настроено, но хорошим началом может быть, например, хотя бы целая эпоха, поскольку сессия devshard в настоящее время не может пересечь границу эпохи. Цепочка не должна назначать этому участнику запросы на вывод или проверку, если оно слишком близко к запланированному времени обслуживания, а также не должно помещать участника в devshards. Должна пройти минимальная задержка до того, как участник сможет запланировать новое окно обслуживания. Например, хост не должен иметь возможность назначать окно обслуживания всего на 1 минуту после MsgSetScheduledMaintenance, чтобы предотвратить злоупотребления. Во время периода обслуживания хост не должен подвергаться штрафам за пропущенные выводы, проверки и т.п. Однако вполне возможно, что хост может отключиться от сети, и выполнение обслуживания займет очень много времени или вообще никогда не вернется. Следовательно, должно быть установлено максимально допустимое время для окон обслуживания. Если время превышено, хост должен быть оштрафован как обычно и техническое обслуживание следует считать завершенным. В этом случае при сокращении могут использоваться текущие штрафы за простой/аннулирование.
- Основная сеть должна изменить статус участника: на DRAINING перед техническим обслуживанием (хост завершит свои текущие сеансы, но не будет участвовать в новых) и на MAINTENANCE (хост временно отключен из-за планового обслуживания). Возможно, в этой государственной машине возникнет необходимость в большем количестве статусов и переходов, которые следует изучить. Время DRAINING может быть настроено, но хорошим началом может быть, например, хотя бы целая эпоха, поскольку сессия devshard в настоящее время не может пересечь границу эпохи.
- Время DRAINING может быть настроено, но хорошим началом может быть, например, хотя бы целая эпоха, поскольку сессия devshard в настоящее время не может пересечь границу эпохи.
- Цепочка не должна назначать этому участнику запросы на вывод или проверку, если оно слишком близко к запланированному времени обслуживания, а также не должно помещать участника в devshards.
- Должна пройти минимальная задержка до того, как участник сможет запланировать новое окно обслуживания. Например, хост не должен иметь возможность назначать окно обслуживания всего на 1 минуту после MsgSetScheduledMaintenance, чтобы предотвратить злоупотребления.
- Во время периода обслуживания хост не должен подвергаться штрафам за пропущенные выводы, проверки и т.п. Однако вполне возможно, что хост может отключиться от сети, и выполнение обслуживания займет очень много времени или вообще никогда не вернется. Следовательно, должно быть установлено максимально допустимое время для окон обслуживания. Если время превышено, хост должен быть оштрафован как обычно и техническое обслуживание следует считать завершенным. В этом случае при сокращении могут использоваться текущие штрафы за простой/аннулирование.
- Новое сообщение, указывающее, что плановое обслуживание завершено, например MsgFinishScheduledMaintenance. Хозяину следует обратить внимание на максимально отведенное время на обслуживание.
- Хозяину следует обратить внимание на максимально отведенное время на обслуживание.
- Новое сообщение на случай, если хост передумает и решит не проводить обслуживание, например MsgCancelScheduledMaintenance . Другими словами, сообщение MsgFinishScheduledMaintenance следует отправлять во время окна запланированного обслуживания, чтобы позволить участнику закрыть окно и возобновить свою обычную деятельность, а сообщение MsgCancelScheduledMaintenance следует отправлять перед окном запланированного обслуживания, чтобы предотвратить его начало.
- Другими словами, сообщение MsgFinishScheduledMaintenance следует отправлять во время окна запланированного обслуживания, чтобы позволить участнику закрыть окно и возобновить свою обычную деятельность, а сообщение MsgCancelScheduledMaintenance следует отправлять перед окном запланированного обслуживания, чтобы предотвратить его начало.
Есть еще некоторые открытые вопросы и соображения, которые требуют исследования в отношении этой конструкции:
- Хост может совершить злоупотребление, если отменяет окно обслуживания на время, очень близкое к его началу. Как мы должны наказывать за это?
Что касается вопроса 2, как мы должны наказать хост, который отменяет окно обслуживания вскоре после его начала?
Каким должен быть период восстановления между окнами обслуживания?
Сколько окон должно быть разрешено на один хост в течение эпохи?
Какова допустимая максимальная отметка времени для обслуживания, прежде чем хост будет считаться отключенным?
Мы хотели бы предложить команде доработать идею и дизайн и начать работу над этим проектом. Предварительный план команды должен выглядеть следующим образом:
- Сначала исследуйте и улучшите конструкцию. Уладьте все возможные открытые вопросы, подумайте, как предотвратить злоупотребление этим механизмом и сократить обнаруженные попытки, спроектируйте возможный дизайн сообщений, рассмотрите возможные изменения для devshards и т. д.
- Реализуйте проект, выбранный на первом этапе, одновременно добавляя тесты в соответствии с лучшими практиками тестирования и документирования.
- Напишите интеграционные тесты с помощью testermint, проверяя счастливые и несчастливые пути, включая тесты хостов, пытающихся обмануть систему.
- Четко задокументируйте, как передать эту функцию сообществу и команде Gonka.
- [Необязательно] Обеспечьте постоянную поддержку и обслуживание этой функции.
У нас уже есть реализация этой функции для проверки и тестирования: #998 (https://github.com/gonka-ai/gonka/pull/998).
Понятно, спасибо, что обратили на это мое внимание. Тогда я закрою эту дискуссию.
Оригинал
Hello. After reading the Gonka Community Network Roadmap (https://docs.google.com/document/d/1wPXTM40CnXyd8Hz_dvf7H1n6KQDqjw0RzppMx92xR8U/edit?pli=1&tab=t.0#heading=h.c2j5tayw22w8) , we’ve seen project 2 in track 3 entitled “Maintenance windows for hosts”, which as of 2026-03-06 has the following description (copied and pasted here):
The project should give a host a way to declare a maintenance window in advance, check whether the maintenance window is allowed, temporarily step out of part of its duties, and return to service without separate coordination and without being penalized for planned downtime.
Metrics:
- PRIMARY: host retention and confidence.
- SECONDARY: network reliability and trust.
What this gives the network:
The network gets a formal maintenance-window process that separates planned downtime from unplanned failures and reduces avoidable misses, penalties, and disputes.
A possible high-level design outline for this project may look like the following:
- Create a new message, such as MsgSetScheduledMaintenance , allowing the host to schedule expected maintenance downtime and broadcast it to the mainnet. The exact fields in this message are up for debate, but it should at least contain a timestamp for when the maintenance begins (e.g.: maintenance_start_timestamp ). The mainnet should change the status of the participant: to DRAINING prior to the maintenance (host will finalize their ongoing sessions but won’t participate in new ones) and to MAINTENANCE (the host is temporarily offline due to scheduled maintenance). There might be the necessity for more statuses and transitions in this state machine, which should be researched. The DRAINING time may be tuned, but a good start may be for example, at least for an entire epoch, as a devshard session currently can’t cross the epoch boundary. The chain should not assign inference or validation requests for this participant if it’s too close to a scheduled maintenance time and neither it should place the participant in devshards. There should be a minimum delay until the participant can schedule a new maintenance window. For example, a host should not be able to assign a maintenance window just 1 minute from MsgSetScheduledMaintenance , to prevent abuse. During the maintenance window, the host must not be penalized for missed inferences, validations, or related. However, it’s possible the host may come offline and take a very long time to perform maintenance, or never return at all. Hence, there should be a maximum allowed time for the maintenance windows. If the time is exceeded, the host should be penalized as usual and the maintenance should be considered finished. The slashing may use the current downtime/invalidation penalties in this case.
- The mainnet should change the status of the participant: to DRAINING prior to the maintenance (host will finalize their ongoing sessions but won’t participate in new ones) and to MAINTENANCE (the host is temporarily offline due to scheduled maintenance). There might be the necessity for more statuses and transitions in this state machine, which should be researched. The DRAINING time may be tuned, but a good start may be for example, at least for an entire epoch, as a devshard session currently can’t cross the epoch boundary.
- The DRAINING time may be tuned, but a good start may be for example, at least for an entire epoch, as a devshard session currently can’t cross the epoch boundary.
- The chain should not assign inference or validation requests for this participant if it’s too close to a scheduled maintenance time and neither it should place the participant in devshards.
- There should be a minimum delay until the participant can schedule a new maintenance window. For example, a host should not be able to assign a maintenance window just 1 minute from MsgSetScheduledMaintenance , to prevent abuse.
- During the maintenance window, the host must not be penalized for missed inferences, validations, or related. However, it’s possible the host may come offline and take a very long time to perform maintenance, or never return at all. Hence, there should be a maximum allowed time for the maintenance windows. If the time is exceeded, the host should be penalized as usual and the maintenance should be considered finished. The slashing may use the current downtime/invalidation penalties in this case.
- A new message indicating that it has finalized the scheduled maintenance, for example, MsgFinishScheduledMaintenance . The host should pay attention to the maximum allotted time for maintenance.
- The host should pay attention to the maximum allotted time for maintenance.
- A new message in case the host may change its mind and decide to not have the maintenance, for example, MsgCancelScheduledMaintenance . In other words, MsgFinishScheduledMaintenance should be sent during the scheduled maintenance window to let the participant close the window and resume its ordinary activities, while MsgCancelScheduledMaintenance should be sent before the scheduled maintenance window to prevent it from ever beginning.
- In other words, MsgFinishScheduledMaintenance should be sent during the scheduled maintenance window to let the participant close the window and resume its ordinary activities, while MsgCancelScheduledMaintenance should be sent before the scheduled maintenance window to prevent it from ever beginning.
There are still some open questions and considerations that need research with this design:
- It’s possible for a host to abuse if it cancels its maintenance window to a time that is very close to its start. How should we penalize it?
Related to question 2, how should we penalize a host that cancels its maintenance window shortly after it began?
What should be the cooldown period between maintenance windows?
How many windows should be allowed per host during an epoch?
What is an acceptable maximum timestamp for maintenance, before the host is considered gone?
We would like to offer a team to refine the idea and design and begin work on this project. A tentative plan for the team should look like the following:
- First research and improve the design. Iron all possible open questions, think how to prevent abuse of this mechanism and slash for detected attempts, architect the possible design for the messages, consider the possible changes for the devshards, etc..
- Implement the design decided during the first step, simultaneously adding tests following the best practices for testing and documentation.
- Write integration tests using testermint, testing the happy paths and unhappy paths, including tests of hosts trying to cheat the system.
- Clearly document how to hand this feature to the community and the Gonka team.
- [Optional] Provide continuous support and maintenance for this feature.
We have an implementation of this feature already out for review and testing: #998 (https://github.com/gonka-ai/gonka/pull/998)
I see, thank you for bringing this to my attention. I'll close this discussion, then.
Привет. Прочитав дорожную карту сети сообщества Gonka (https://docs.google.com/document/d/1wPXTM40CnXyd8Hz_dvf7H1n6KQDqjw0RzppMx92xR8U/edit?pli=1&tab=t.0#heading=h.c2j5tayw22w8), мы увидели проект 2 в треке 3 под названием «Окна обслуживания хостов», которые по состоянию на 06 марта 2026 г. имеют следующее описание (скопировано и вставлено сюда):
Проект должен предоставить хосту возможность заранее объявить окно обслуживания, проверить, разрешено ли окно обслуживания, временно отказаться от части своих обязанностей и вернуться к работе без отдельного согласования и без штрафов за запланированный простой.
Метрики:
Что это дает сети:
Сеть получает формальный процесс обслуживания, который отделяет запланированные простои от незапланированных сбоев и снижает количество предотвратимых ошибок, штрафов и споров.
Возможная общая схема проекта для этого проекта может выглядеть следующим образом:
Есть еще некоторые открытые вопросы и соображения, которые требуют исследования в отношении этой конструкции:
Что касается вопроса 2, как мы должны наказать хост, который отменяет окно обслуживания вскоре после его начала?
Каким должен быть период восстановления между окнами обслуживания?
Сколько окон должно быть разрешено на один хост в течение эпохи?
Какова допустимая максимальная отметка времени для обслуживания, прежде чем хост будет считаться отключенным?
Мы хотели бы предложить команде доработать идею и дизайн и начать работу над этим проектом. Предварительный план команды должен выглядеть следующим образом: