broker.toml (xeon e5 2695v4 (x2) на huananzhi x-99 fd8 plus, 256 ram (ecc/reg), 1 tb nvme, RTX 3070ti + RTX 4070 ti super)

caution wet floor

Разбираем broker.toml

[market]

Что такое mcycle_price?

Это цена за мегацикл (миллион циклов RISC-V), выраженная в нативном токене сети (например, ETH).

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

Текущее значение:

mcycle_price = "0.0000005"  # 0.0000005 ETH за 1 млн циклов

Как выбрать оптимальное значение?

Сравни с другими пруверами:

Проверь среднюю цену в сети (например, через блокчейн-эксплорер или чаты сообщества).
Если большинство ставят 0.0000004, а ты 0.0000005, твои таски будут брать реже.

Учитывай свои затраты:

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

Твой сервер мощный (2× Xeon + 2× GPU), поэтому можешь брать больше задач за счёт низкой цены.
Например, можно поставить 0.0000004 или даже 0.00000035, если хочешь больше нагрузки.

Тестовый режим:

Начни со стандартного значения (0.0000005), затем:

Если задачи идут слишком медленно — снижай цену.
Если система перегружена, а доход низкий — повышай.

Что это?

Это цена за мегацикл (миллион RISC-V циклов), но выраженная в стейкинг-токене Boundless (не в ETH или другом нативном токене).
Используется для заказов, оплаченных стейкинг-токенами (например, если у клиента закончился депозит или заказ с истёкшим сроком).

Текущее значение:

mcycle_price_stake_token = "0.0001"  # 0.0001 стейкинг-токена за 1 млн циклов

Как выбрать оптимальное значение?

Сравнение с mcycle_price (в ETH)

Должно быть экономически эквивалентно основной цене (mcycle_price).
Например, если:

0.0000005 ETH = 0.0001 StakeToken,
то курс: 1 StakeToken = 0.005 ETH (или 1 ETH = 200 StakeToken).

Рыночная конкуренция

Если другие пруверы ставят 0.00008 StakeToken, твоя цена (0.0001) может быть менее привлекательной.
Если сеть перегружена спросом, можно повысить цену.

Стейкинг-мотивация

Низкая цена (0.00008–0.0001) может стимулировать клиентов использовать стейкинг-токены вместо ETH.
Высокая цена (>0.0001) выгодна тебе, но снижает спрос.

Оптимальная настройка `mcycle_price_stake_token` для USDC

Исходя из вашей конфигурации и экономики, вот детальные рекомендации:

1. Текущая ситуация:

Ваша цена: 0.0001 USDC за 1 млн циклов (0.01 цента)
При 200,000 мегациклов/час: 20 USDC/час (нереалистично высокий доход)
Проблема: Цена занижена относительно стоимости электричества и оборудования

2. Как рассчитать минимальную цену:

Себестоимость вычислений:

Электричество: $0.05/час (500 Вт × $0.1/кВт·ч)
Амортизация оборудования: ~$0.10/час (примерно $900/год на 2 GPU + CPU)
Итого: $0.15/час — минимальный доход для безубыточности.

Минимальная цена:

При 50,000 мегациклов/час (реалистичная нагрузка):
0.0001 USDC × 50,000 = 5 USDC/час → Сильно выше себестоимости.
Можно снизить цену для конкуренции, но не ниже 0.00003 USDC (3 USDC/час).

3. Рекомендуемые значения:

| Цель | Значение (USDC/млн циклов) | Доход при 50k Mcycles/час | |---------------------|---------------------------|--------------------------| | Агрессивная конкуренция | 0.00003 | $1.5/час | | Баланс спроса/дохода | 0.00005 | $2.5/час | | Премиум-сегмент | 0.0001 | $5/час |

[market]
mcycle_price_stake_token = "0.00005"  # Оптимальный баланс

Оптимальная настройка `peak_prove_khz` для вашей конфигурации

1. Что означает параметр `peak_prove_khz`?

Это оценка пиковой производительности вашего кластера в килогерцах (тысячах циклов в секунду).
Используется системой для:

Расчета пропускной способности прувера
Автоматического ограничения принимаемых задач, чтобы избежать перегрузки

Значение можно определить через бенчмаркинг с помощью Bento CLI или на основе реальных данных выполнения заказов.

2. Анализ вашего текущего значения

peak_prove_khz = 100  # 100,000 циклов/сек

Что это значит?

Ваш кластер заявляет способность обрабатывать 100,000 RISC-V циклов в секунду.
В пересчете на мегациклы: 0.1 мегацикла/сек или 360 мегациклов/час.

Проблема:

Это значение слишком низкое для вашего мощного оборудования (2× Xeon + 2× GPU).
Фактически вы искусственно ограничиваете свой доход.

Перевод в kHz:

Теоретический максимум: 9,800 kHz
Рекомендуемое значение: 5,000 kHz (с запасом для стабильности)

peak_prove_khz = 5000  # 5,000,000 циклов/сек

Почему именно 5000 kHz?

Баланс между доходом и стабильностью:

Заниженная цифра (100 kHz) приводит к недогрузке оборудования.
Завышенная (9,800 kHz) может вызвать перегрев/перегрузку.
5000 kHz — компромисс для 70-80% загрузки.

Проверка через Bento CLI:
Запусти тест для точной калибровки:bento benchmark --cycles 10000000 --gpu # Пример команды (уточни в документации)

Если результат >7,000 kHz, можно повысить значение.
Если <3,000 kHz, уменьши до 3000 и оптимизируй настройки.

Бенчмарк с сервера

Оптимальная настройка `max_mcycle_limit` для вашего оборудования

1. Что означает параметр?

max_mcycle_limit = 8000 = 8 миллиардов циклов (8000 × 1 млн)
Это максимальный размер задачи, которую ваш прувер готов выполнять. Задачи сложнее будут автоматически отклоняться.

2. Как выбрать значение для вашего сервера?

Факторы для расчета:

Производительность системы (peak_prove_khz):

При 5000 kHz (5 млн циклов/сек):

8 млрд циклов = 8000 / 5 = 1600 сек ≈ 27 минут на задачу.

Это разумно, но можно увеличить лимит для более сложных (и дорогих) задач.

Стабильность работы:

Слишком долгие задачи (>1 часа) могут привести к:

Перегреву GPU/CPU.
Риску обрыва соединения или таймаута.

Экономическая выгода:

Крупные задачи часто оплачиваются лучше (меньше накладных расходов).
Но требуют больше ресурсов ОЗУ (у вас 256 GB — запас большой).

Итоговая рекомендация:

max_mcycle_limit = 15000  # 15 млрд циклов (баланс между доходом и стабильностью)

Оптимальная настройка `max_journal_bytes`

1. Что делает параметр?

max_journal_bytes = 10000 ограничивает максимальный размер журнала (журнал — это данные, которые нужно отправить в блокчейн для подтверждения выполнения задачи).
Если журнал превышает этот размер — задача автоматически отклоняется.

2. Как выбрать значение?

Критерии:

Блокчейн-лимиты:

Например, в Ethereum максимальный размер данных в транзакции — ~128 KB (но лучше держаться ниже).
В других сетях (Solana, Polygon) лимиты могут быть выше.

Экономическая целесообразность:

Большие журналы = дороже газовые сборы.
Маленькие лимиты = меньше гибкости для сложных задач.

Ваша конфигурация:

У вас 256 GB RAM — можно позволить буферу журнала расширяться.

3. Рекомендуемые значения

| Сценарий | Значение (max_journal_bytes) | Комментарий | |------------------------------|--------------------------------|----------------------------------| | Консервативный (тесты) | 10_000 (10 KB) | Минимум для простых задач | | Стандартный | 100_000 (100 KB) | Баланс стоимости и гибкости | |
Для сложных вычислений | 1_000_000 (1 MB) | Если сеть поддерживает большие журналы |

Итоговая рекомендация:

max_journal_bytes = 100000  # 100 KB (оптимально для большинства сценариев)

Разбор параметра `min_deadline` (минимальное время до дедлайна)

Что это значит?

min_deadline = 300 означает, что ваш прувер будет брать в работу только те задачи, у которых до дедлайна осталось не меньше 300 секунд (5 минут).
Это защита от ситуаций, когда времени может не хватить на выполнение и отправку результата в блокчейн.

Зачем это нужно?

Техническая страховка:

Если взять задачу с дедлайном 1 минута → можно не успеть её выполнить и отправить proof → потеря вознаграждения.
5 минут — минимальный "буфер" для гарантированного завершения.

Оптимизация работы:

Отсекает "горящие" задачи, которые могут перегрузить систему.
Даёт время на:

Генерацию доказательства (proof).
Подпись транзакции.
Отправку в сеть (учёт возможных задержек).

Как выбрать значение?

Для вашего мощного сервера (2× Xeon + 2× GPU):

300 (5 минут) — разумный минимум, но можно увеличить для сложных задач.
Если задачи часто не успевают — попробуйте 600 (10 минут).

Оптимальная настройка `lookback_blocks` для вашего прувера

1. Что делает этот параметр?

lookback_blocks = 300 означает, что при запуске прувер будет проверять последние 300 блоков в блокчейне на наличие незакрытых заказов.
При среднем времени блока 12 секунд это охватывает примерно 1 час истории блокчейна.

2. Как выбрать правильное значение?

Факторы для рассмотрения:

Частота перезапусков прувера:

Если перезапускаете редко (раз в сутки) — можно увеличить до 1000-2000 блоков (~3-6 часов)
Для частых рестартов достаточно 300

Загрузка сети Boundless:

При высокой активности (много заказов) лучше уменьшить до 150-200 для быстрого старта
При низкой — увеличить для поиска большего количества заказов

Производительность ноды:

Ваш сервер с 256GB RAM легко обработает 1000+ блоков
Но слишком большое значение замедлит начальную синхронизацию

3. Рекомендуемые значения

| Сценарий работы | Значение (блоки) | Примерное время охвата | |--------------------------|------------------|------------------------| | Тестовый режим | 100-200 | 20-40 минут | | Стандартная работа | 300-500 | 1-2 часа | | После длительного простоя | 1000-1500 | 3-5 часов |

4. Особенности для вашей конфигурации

С вашим оборудованием (2× Xeon + 2× GPU) оптимально:

lookback_blocks = 500  # ~100 минут истории при 12s/блок

Оптимальная настройка `max_file_size` для вашего прувера

1. Что делает этот параметр?

max_file_size = 50_000_000 (50 МБ) ограничивает максимальный размер файлов (входных данных/образов), которые прувер будет загружать для обработки задач.
Файлы больше указанного размера автоматически отклоняются.

2. Как выбрать правильное значение?

Ключевые факторы:

Типичные задачи в сети Boundless:

Для большинства zk-доказательств достаточно 1-10 МБ
ML-модели могут требовать 20-100 МБ
Видео/аудио обработка - до 500 МБ

Ваши аппаратные возможности:

256GB RAM - легко обработает файлы до 1GB
1TB NVMe - достаточно места для временных файлов
Сетевой канал - учитывайте скорость загрузки

Экономическая целесообразность:

Большие файлы = больше времени загрузки = выше затраты
Но и оплата за такие задачи обычно выше

3. Рекомендуемые значения

| Тип задач | Значение (байты) | Комментарий | |---------------------|-------------------|----------------------------------| | Легкие вычисления | 10_000_000 (10MB) | Для стандартных zk-proof задач | | Универсальное | 50_000_000 (50MB) | Подходит для большинства ML | | Ресурсоемкие задачи | 200_000_000 (200MB)| Для обработки медиа и больших моделей |

4. Оптимальная настройка для вашего железа

max_file_size = 200_000_000  # 200MB

Оптимальная настройка `max_fetch_retries` для вашего прувера

1. Что делает этот параметр?

max_fetch_retries = 2 определяет, сколько раз прувер будет повторять попытку загрузки входных данных (например, файлов или изображений) при возникновении ошибок сети или временной недоступности URL.
Если не задано, используется значение по умолчанию (обычно 1-3 попытки).

2. Как выбрать правильное значение?

Ключевые факторы:

Стабильность источников данных:

Если URL часто недоступны или медленные — увеличьте количество попыток
Для надежных источников можно уменьшить

Тип задач:

Для критически важных задач — больше попыток (3-5)
Для стандартных задач — 2-3 попытки

Таймауты соединения:

Учитывайте настройки request_timeout в сетевых параметрах

3. Рекомендуемые значения

| Сценарий работы | Значение | Комментарий | |--------------------------|----------|----------------------------------| | Стабильная сеть | 2 | Баланс между надежностью и скоростью | | Ненадежные источники | 3-5 | Увеличивает шансы на успешную загрузку | | Очень важные задачи | 5 | Максимальные попытки для гарантии |

4. Оптимальная настройка для вашей конфигурации

max_fetch_retries = 3  # 3 попытки (оптимальный баланс)

Оптимальная настройка `max_concurrent_proofs` для вашего оборудования

1. Что делает этот параметр?

max_concurrent_proofs = 2 ограничивает количество доказательств (proofs), которые могут обрабатываться одновременно
Это критически важный параметр для управления нагрузкой на ваши GPU

2. Анализ для вашей конфигурации

Ваше оборудование:

2 GPU: RTX 3070 Ti (8GB) + RTX 4070 Ti Super (16GB)
256GB RAM
2× Xeon E5-2695v4 (36 ядер/72 потока)

3. Рекомендуемые значения

| Конфигурация | Значение | Обоснование | |-------------|---------|------------| | Консервативная | 2 | По одному proof на GPU (текущая настройка) | | Оптимальная | 3 | Использует 4070 Ti Super для двух proofs + 3070 Ti для одного | | Агрессивная | 4 | Максимальная загрузка (требует мониторинга температуры) |

4. Оптимальная настройка

max_concurrent_proofs = 3  # Лучший баланс производительности

Как это работает:

RTX 4070 Ti Super будет обрабатывать 2 proofs одновременно (благодаря 16GB VRAM)
RTX 3070 Ti - 1 proof
CPU-потоки распределяются автоматически

Оптимальная настройка `max_concurrent_preflights` для вашего сервера

Что делает этот параметр?

max_concurrent_preflights ограничивает количество одновременных задач предварительной оценки (preflight), которые определяют стоимость выполнения заказа
Защищает систему от перегрузки при массовой обработке входящих запросов

Оптимальные значения:

max_concurrent_preflights = 8  # Оптимально для вашего сервера

3. Обоснование выбора

Оптимальная настройка `max_critical_task_retries` для промышленного сервера

1. Назначение параметра

Параметр max_critical_task_retries = 10 определяет:

Максимальное количество попыток повтора для критических системных задач
После исчерпания попыток процесс аварийно завершается
Защищает от бесконечных циклов при фатальных ошибках

Оптимальные значения:

# Производственная среда (high-availability)
max_critical_task_retries = 15

# Тестовый режим/разработка
# max_critical_task_retries = 3

1. Что делает `balance_warn_threshold`?

Это пороговое значение баланса кошелька, при котором система начнёт выдавать предупреждения в логах. Если баланс упадёт ниже указанного значения, вы увидите сообщения типа:
"Warning: Submitter balance below threshold (0.1 ETH)".

2. Как выбрать значение?

Критерии:

Стоимость транзакций в сети:

Если газ дорогой (например, в Ethereum), установите более высокий порог (например, 0.5–1.0), чтобы успеть пополнить баланс до исчерпания.
Для дешёвых сетей (например, Polygon) хватит 0.1–0.3.

Частота отправки транзакций:

Если ваш прувер активно участвует в тасках (много lockinRequest/submitProof), ставьте запас 0.3–1.0.
Для редких операций достаточно 0.1.

Тип токена:

Для ETH (Ethereum) значения обычно выше (0.3+), так как газ стоит дорого.
Для других нативных токенов (например, MATIC) можно снизить до 0.1.

Пример для вашего случая:

Сеть Ethereum:balance_warn_threshold = "0.5" # ETH

1. Что делает `lockin_gas_estimate`?

Это предполагаемый лимит газа для операции lockinRequest (резервирование таска прувером).
Используется для:

Расчёта стоимости заказа (чтобы покрыть комиссии сети).
Предотвращения ошибок типа out of gas.

Если не задан, система использует консервативное значение (например, 400-500k газа).

Для вашего случая:

Начните с 300000 и мониторьте логи:lockin_gas_estimate = 300000
Если видите ошибки out of gas — увеличивайте на 50-100k.
Если транзакции проходят с большим неиспользованным газом (gas_used << gas_limit) — уменьшайте.

1. Что делает `fulfill_gas_estimate`?

Оценивает затраты газа для операции подтверждения выполнения (fulfill), которая обычно сложнее, чем lockin (может включать проверку proof, запись в контракт и т.д.).
Влияет на:

Корректное резервирование средств для комиссий.
Успешность транзакций (избегание out of gas).

2. Рекомендуемые значения

Для вашей конфигурации (2×Xeon E5-2695v4, RTX 3070 Ti + 4070 Ti Super) и разных сетей:

| Сеть/Тип задачи | Значение fulfill_gas_estimate | Обоснование | |--------------------------|----------------------------------|-----------------------------------------------------------------------------| | Ethereum Mainnet | 700000–1,200,000 | Высокие комиссии, сложные контракты (например, с верификацией zk-proof). | | Arbitrum/Polygon | 500000–800,000 | Оптимизированные L2, но fulfill может требовать больше газа, чем lockin. | | Тестовая сеть | 400000–600,000 | Для тестов можно снизить (но зависит от контракта). |

Стартовое значение:

fulfill_gas_estimate = 750000  # Средний вариант для L2/L1

1. Что делает этот параметр?

Оценивает затраты газа на операцию верификации zk-SNARK доказательства (алгоритм Groth16) в смарт-контракте.
Используется для:

Корректного ценообразования при резервировании тасков
Гарантии успешного выполнения транзакции (избежание out-of-gas)
Оптимизации комиссий при работе с разными сетями

2. Рекомендуемые значения для разных сетей

| Сеть | Диапазон значений | Обоснование | |---------------------|-------------------------|------------| | Ethereum Mainnet | 200,000 - 400,000 | Высокие базовые комиссии, сложные операции верификации | | Arbitrum/OP | 150,000 - 300,000 | Оптимизированные L2, но верификация всё равно ресурсоёмка | | Polygon | 120,000 - 250,000 | Более дешёвые вычисления, но зависит от нагрузки сети | | Тестовые сети | 100,000 - 200,000 | Для отладки можно использовать меньшие значения |

Для вашей конфигурации (2×Xeon + RTX 3070 Ti/4070 Ti Super) рекомендуем начать с:

groth16_verify_gas_estimate = 250000

[prover]

1. Что делает параметр?

Определяет количество попыток опроса статуса доказательства (proving status) перед тем, как система засчитает временный сбой как ошибку.
Решает проблемы:

Кратковременные сетевые задержки
Временная недоступность RPC-ноды
Задержки в работе GPU (например, из-за перегрева)

2. Оптимальное значение для вашей системы

Обоснование:

Мощные GPU (3070 Ti + 4070 Ti Super):

Генерируют proof быстрее среднего, но могут возникать микрозадержки из-за:

Параллельной работы двух карт
Динамического разгона/троттлинга

Дополнительные попытки компенсируют это.

Сетевые условия:

Если вы используете удалённые RPC-ноды (например, QuickNode/Alchemy), их ответы могут быть нестабильны при высокой нагрузке.
Для локальной ноды (если развёрнута) хватит и 3, но для облачных эндпоинтов лучше 5.

Баланс между скоростью и надёжностью:

3: Быстрее выявляет реальные ошибки, но может ложно срабатывать при кратковременных проблемах.
5: Уменьшает количество ложных срабатываний, но увеличивает время реакции на критические сбои.

1. Что делает `proof_retry_count`?

Параметр определяет количество повторных попыток для всего процесса генерации доказательства (proof), если что-то пошло не так. Это критически важно, потому что:

Процесс proof — многоэтапный (создание задачи + опрос статуса).
Ошибки могут быть временными (сеть, API, нагрузка на GPU).
Повторная попытка может спасти дорогостоящие вычисления.

2. Рекомендуемое значение для вашей системы

proof_retry_count = 2  # Увеличьте с 1 до 2

Обоснование:

Мощные GPU:

Ваши RTX 3070 Ti и 4070 Ti Super генерируют proof быстро, но:

При параллельной работе двух карт возможны конфликты ресурсов.
Из-за динамической нагрузки (разгон/троттлинг) возможны сбои.

2 попытки дадут системе шанс автоматически исправить временные ошибки.

Стабильность сети:

Если вы используете облачные RPC (Infura/Alchemy), их API иногда может «затыкаться».
1 попытка — слишком рискованно (можно потерять результат работы GPU).

Баланс между надёжностью и производительностью:

1: Быстрее выявляет критические ошибки, но чаще приводит к потере вычислений.
2: Оптимально для вашего железа (минимизирует потери без избыточных задержек).
3+: Только если вы работаете в нестабильной сети или с ненадёжным провайдером proof.

Для параметра proof_retry_sleep_ms = 500 (задержка между повторными попытками генерации доказательства) рекомендации зависят от вашей инфраструктуры и нагрузки. Вот анализ:

Что учесть:

GPU Load: Две карты (особенно 4070 Ti Super) могут создавать конкуренцию. Если proof-задачи требуют много ресурсов, увеличение задержки снизит риск ошибок.
Сеть: Если prover взаимодействует с удаленным API, добавьте запас на сетевые задержки.
Логирование: Мониторьте логи (debug режим) на предмет ошибок proof_retry. Если видите частые ретраи — увеличивайте значение.

Пример для вашей конфигурации:

proof_retry_sleep_ms = 1000  # Компромисс между скоростью и стабильностью для 2x GPU

Если после тестов заметите, что ретраи редки, можно уменьшить значение для ускорения работы. Для старта лучше оставить 1000 мс.

caution wet floor

Текущее значение:

Как выбрать оптимальное значение?

Рекомендация для старта:

Что это?

Текущее значение:

Как выбрать оптимальное значение?

Рекомендация:

Оптимальная настройка mcycle_price_stake_token для USDC

1. Текущая ситуация:

2. Как рассчитать минимальную цену:

3. Рекомендуемые значения:

Оптимальная настройка peak_prove_khz для вашей конфигурации

1. Что означает параметр peak_prove_khz?

2. Анализ вашего текущего значения

Почему именно 5000 kHz?

Оптимальная настройка max_mcycle_limit для вашего оборудования

1. Что означает параметр?

2. Как выбрать значение для вашего сервера?

Оптимальная настройка max_journal_bytes

1. Что делает параметр?

2. Как выбрать значение?

3. Рекомендуемые значения

Разбор параметра min_deadline (минимальное время до дедлайна)

Что это значит?

Зачем это нужно?

Как выбрать значение?

Оптимальная настройка lookback_blocks для вашего прувера

1. Что делает этот параметр?

2. Как выбрать правильное значение?

3. Рекомендуемые значения

4. Особенности для вашей конфигурации

Оптимальная настройка max_file_size для вашего прувера

1. Что делает этот параметр?

2. Как выбрать правильное значение?

3. Рекомендуемые значения

4. Оптимальная настройка для вашего железа

Оптимальная настройка max_fetch_retries для вашего прувера

1. Что делает этот параметр?

2. Как выбрать правильное значение?

3. Рекомендуемые значения

4. Оптимальная настройка для вашей конфигурации

Оптимальная настройка max_concurrent_proofs для вашего оборудования

1. Что делает этот параметр?

2. Анализ для вашей конфигурации

3. Рекомендуемые значения

4. Оптимальная настройка

Оптимальная настройка max_concurrent_preflights для вашего сервера

3. Обоснование выбора

Оптимальная настройка max_critical_task_retries для промышленного сервера

1. Назначение параметра

1. Что делает balance_warn_threshold?

2. Как выбрать значение?

Критерии:

Пример для вашего случая:

1. Что делает lockin_gas_estimate?

Рекомендуемые значения:

Для вашего случая:

1. Что делает fulfill_gas_estimate?

2. Рекомендуемые значения

Стартовое значение:

1. Что делает этот параметр?

2. Рекомендуемые значения для разных сетей

1. Что делает параметр?

2. Оптимальное значение для вашей системы

Рекомендация:

Обоснование:

Рекомендации по настройке параметра status_poll_ms для вашей конфигурации:

1. Что делает proof_retry_count?

2. Рекомендуемое значение для вашей системы

Рекомендации:

Что учесть:

Пример для вашей конфигурации:

Оптимальная настройка `mcycle_price_stake_token` для USDC

Оптимальная настройка `peak_prove_khz` для вашей конфигурации

1. Что означает параметр `peak_prove_khz`?

Оптимальная настройка `max_mcycle_limit` для вашего оборудования

Оптимальная настройка `max_journal_bytes`

Разбор параметра `min_deadline` (минимальное время до дедлайна)

Оптимальная настройка `lookback_blocks` для вашего прувера

Оптимальная настройка `max_file_size` для вашего прувера

Оптимальная настройка `max_fetch_retries` для вашего прувера

Оптимальная настройка `max_concurrent_proofs` для вашего оборудования

Оптимальная настройка `max_concurrent_preflights` для вашего сервера

Оптимальная настройка `max_critical_task_retries` для промышленного сервера

1. Что делает `balance_warn_threshold`?

1. Что делает `lockin_gas_estimate`?

1. Что делает `fulfill_gas_estimate`?

Рекомендации по настройке параметра `status_poll_ms` для вашей конфигурации:

1. Что делает `proof_retry_count`?