#dusk $DUSK Я снова просмотрел документ о механизмах наказаний @Dusk и обнаружил проблему, которую стоит глубже изучить: границы между мягкими и жесткими наказаниями описаны очень четко, но фактическая сдерживающая сила наказаний зависит от исполнения, а не от самих правил.
В документе мягкие наказания нацелены на provisioner’ов, которые офлайн или отвечают несвоевременно: им могут приостановить право на выпуск блоков. Жесткие наказания — на вредоносные действия, связанные с подписанием конфликтующей информации: в этом случае они могут напрямую лишиться залога. Логика правил понятна, но данные о том, сколько раз правило было фактически срабатывало, выполнялось ли наказание после срабатывания, и корректировал ли provisioner свое поведение, чтобы снова выйти в онлайн — эти сведения сейчас не так легко получить из открытых источников.
Эффективность механизма наказаний определяется не тем, насколько сурово прописаны санкции, а тем, будет ли ожидаемая стоимость нарушения действительно выше ожидаемой выгоды. Допустим, provisioner офлайн на несколько часов и теряет лишь небольшую часть вознаграждения, при этом размер его залогов очень большой: тогда мягкое наказание для него может быть лишь «операционными издержками», а не «ограничением поведения». Чтобы жесткое наказание стало реально сдерживающим, вероятность обнаружения злонамеренного поведения должна быть достаточно высокой, а сумма наказания — достаточной, чтобы покрыть потенциальную выгоду от атаки.
Здесь есть еще один «слепой угол» в сценарии делегирования. Если участник делает ставку через пул третьей стороны, то кто в итоге несет наказание, возникающее из-за нарушений provisioner’а? Положения контракта пула четко распределяют ответственность? Если оператор пула действует во вред, есть ли у участников путь для предъявления претензий? Ответы на эти вопросы не находятся в протокольной документации — они зависят от конкретных условий каждого пула и от соответствующей юрисдикции.
Я смотрю на механизм наказаний в DUSK: он не будет оцениваться только по тому, насколько жестко сформулированы санкции; меня куда больше интересуют реальная частота наступления событий наказания, изменение поведения provisioner’а после наказания и то, как в делегированном сценарии в конечном счете распределяется стоимость наказаний. Между наказаниями, просто прописанными в коде, и наказаниями, которые действительно меняют поведение, лежит целая инженерная система исполнения, мониторинга и привлечения к ответственности.#dusk @Dusk