ПОЧЕМУ DUSK НЕ ДЕЛАЕТ ОДНУ НОДУ “ВСЁ ПОД КАПОТОМ”
Две недели назад я пытался сэкономить на VPS. Я разместил на одном небольшом сервере основное приложение, резервные копии базы данных и тяжёлую задачу по обработке изображений. Казалось эффективно. На самом деле — нет. Задание по изображениям начиналось, и внезапно моё основное приложение переставало получать запросы.
Эта глупая проблема с маленьким VPS снова всплывает, когда я читаю схему настройки нод Dusk. Dusk разделяет работу между ролями Provisioner, Archive и Prover. Это не три “красивых” названия для одной машины, которая делает всё.
Provisioner отвечает за консенсус и требует как минимум 1,000 DUSK в стейке. Archive Node хранит финализированную историю — например, "moonlightHistory" и "finalizedEvents". А Prover выполняет более тяжёлую работу по генерации доказательств с нулевым разглашением (Zero-Knowledge).
Затем я перехожу к роли Prover — и аппаратная проблема снова меняется. Dusk говорит, что генерация доказательств однопоточная, поэтому важна сильная производительность одного ядра. Инфраструктура Archive стартует с другими требованиями: 4 ядра, 8 ГБ ОЗУ, 500 ГБ хранилища и сеть 100 Мбит/с.
И это та часть, которая кажется знакомой. Dusk рекомендует держать инфраструктуру production API отдельно от задач Provisioner, потому что трафик запросов и обслуживание могут конкурировать с работой консенсуса. Я понял это же самое неприятным способом на том VPS.
Теперь я смотрю на эти три роли чуть иначе. Если консенсус, исторические запросы и ZK-подтверждения начинают бороться за одни и те же ресурсы, возможно, вариант “одна коробка делает всё” вовсе не самый простой.
@Dusk #dusk $DUSK
Две недели назад я пытался сэкономить на VPS. Я разместил на одном небольшом сервере основное приложение, резервные копии базы данных и тяжёлую задачу по обработке изображений. Казалось эффективно. На самом деле — нет. Задание по изображениям начиналось, и внезапно моё основное приложение переставало получать запросы.
Эта глупая проблема с маленьким VPS снова всплывает, когда я читаю схему настройки нод Dusk. Dusk разделяет работу между ролями Provisioner, Archive и Prover. Это не три “красивых” названия для одной машины, которая делает всё.
Provisioner отвечает за консенсус и требует как минимум 1,000 DUSK в стейке. Archive Node хранит финализированную историю — например, "moonlightHistory" и "finalizedEvents". А Prover выполняет более тяжёлую работу по генерации доказательств с нулевым разглашением (Zero-Knowledge).
Затем я перехожу к роли Prover — и аппаратная проблема снова меняется. Dusk говорит, что генерация доказательств однопоточная, поэтому важна сильная производительность одного ядра. Инфраструктура Archive стартует с другими требованиями: 4 ядра, 8 ГБ ОЗУ, 500 ГБ хранилища и сеть 100 Мбит/с.
И это та часть, которая кажется знакомой. Dusk рекомендует держать инфраструктуру production API отдельно от задач Provisioner, потому что трафик запросов и обслуживание могут конкурировать с работой консенсуса. Я понял это же самое неприятным способом на том VPS.
Теперь я смотрю на эти три роли чуть иначе. Если консенсус, исторические запросы и ZK-подтверждения начинают бороться за одни и те же ресурсы, возможно, вариант “одна коробка делает всё” вовсе не самый простой.
@Dusk #dusk $DUSK