#dusk $DUSK
Честно, я в шоке. Всего 5 баллов, хотя просмотров было 5K — ощущается это действительно несправедливо и разочаровывающе.
Публикую сегодня с тяжёлым сердцем… но перед постом — быстрый скап:
Long $PORTAL 📈
Short $CYS 📉
не забудьте поблагодарить меня, когда будете выводить прибыль
сначала я думал, что с меня «срежут» на @Dusk — значит, одно: потерять ставку и перезапустить ноду
руководство по восстановлению проводит гораздо более чёткую грань.
Мягкие штрафы могут приостановить право провайдерa (provisioner) и часть его активной ставки перевести в заблокированную. Эта ставка всё ещё принадлежит оператору и может быть раз заблокирована (разставлена).
Жёсткие штрафы применяются к доказуемо неверному консенсусному поведению, например к конфликтующим голосам или к эковокации. Часть ставки сжигается, и перезапуск или повторная ставка (restaking) не сможет это вернуть
вот в чём различие — оно застряло.
Dusk по-разному относится к пропущенному участию и противоречивому участию. Устаревшая версия, длительный простой, плохая синхронизация или блокировка сетевого трафика могут вызвать операционную неисправность. Подпись конфликтующих сообщений уводит в то поведение, которое протокол может доказать как недействительное.
Предупреждение о дубликате ключа делает эту границу практичной.
Запуск одного и того же консенсусного ключа на двух активных нодах может привести к тому, что обе машины подпишут несовместимые сообщения, даже если оператор думал, что вторая нода — только бэкап.
Мне нравится, что восстановление начинается с исправления версии, синхронизации, подключения и конфигурации ключа, прежде чем создавать новую позицию провайдерa. Restaking без поиска причины просто поставит новую позицию позади той же сломанной настройки
модель также означает, что резервирование нужно проектировать внимательно. Бэкап, предназначенный для повышения доступности, может создать риск жёсткого «слэша», если он станет активным с тем же ключом.
Отделение операционной ошибки от эковокации делает штрафы справедливее или же управление консенсусным ключом — самая беспощадная часть в работе провайдерa?
Слэш провайдеров на @Dusk поднимает интересный вопрос
Что важнее для того, чтобы валидаторы были в безопасности?
Честно, я в шоке. Всего 5 баллов, хотя просмотров было 5K — ощущается это действительно несправедливо и разочаровывающе.
Публикую сегодня с тяжёлым сердцем… но перед постом — быстрый скап:
Long $PORTAL 📈
Short $CYS 📉
не забудьте поблагодарить меня, когда будете выводить прибыль
сначала я думал, что с меня «срежут» на @Dusk — значит, одно: потерять ставку и перезапустить ноду
руководство по восстановлению проводит гораздо более чёткую грань.
Мягкие штрафы могут приостановить право провайдерa (provisioner) и часть его активной ставки перевести в заблокированную. Эта ставка всё ещё принадлежит оператору и может быть раз заблокирована (разставлена).
Жёсткие штрафы применяются к доказуемо неверному консенсусному поведению, например к конфликтующим голосам или к эковокации. Часть ставки сжигается, и перезапуск или повторная ставка (restaking) не сможет это вернуть
вот в чём различие — оно застряло.
Dusk по-разному относится к пропущенному участию и противоречивому участию. Устаревшая версия, длительный простой, плохая синхронизация или блокировка сетевого трафика могут вызвать операционную неисправность. Подпись конфликтующих сообщений уводит в то поведение, которое протокол может доказать как недействительное.
Предупреждение о дубликате ключа делает эту границу практичной.
Запуск одного и того же консенсусного ключа на двух активных нодах может привести к тому, что обе машины подпишут несовместимые сообщения, даже если оператор думал, что вторая нода — только бэкап.
Мне нравится, что восстановление начинается с исправления версии, синхронизации, подключения и конфигурации ключа, прежде чем создавать новую позицию провайдерa. Restaking без поиска причины просто поставит новую позицию позади той же сломанной настройки
модель также означает, что резервирование нужно проектировать внимательно. Бэкап, предназначенный для повышения доступности, может создать риск жёсткого «слэша», если он станет активным с тем же ключом.
Отделение операционной ошибки от эковокации делает штрафы справедливее или же управление консенсусным ключом — самая беспощадная часть в работе провайдерa?
Слэш провайдеров на @Dusk поднимает интересный вопрос
Что важнее для того, чтобы валидаторы были в безопасности?
- Fair penalty design
35%
- Consensus-key security
22%
- Reliable node uptime
13%
- All equally important
30%
23 проголосовали • Голосование закрыто