Я присматривался(лась) к тому, как @Dusk обрабатывает консенсус, и одна деталь, которую легко упустить из виду, — что этот процесс не рассматривается как одно-единственное решение.

Сначала подготавливается и предлагается блок. Затем участники голосования оценивают его, прежде чем сеть согласится на получившееся состояние.

Мне важно это разделение, потому что создание кандидатного блока и принятие этого блока — не одно и то же. Если предложение ошибочно, этап голосования дает отдельную точку, где участники могут отклонить его, а не считать само производство блоков автоматическим принятием.

Мне нравится такой подход с системной точки зрения. Так логике проще разделиться: сначала предлагаешь, затем достигаешь согласия.

Но есть и другая сторона, о которой я постоянно думаю. Более явные этапы также означают больше координации между компонентами. Если эти этапы зависят друг от друга, дополнительная структура может создать дополнительные места, где координация должна работать корректно.

Мое мнение: интересный вопрос не в том, выглядит ли дизайн изощренным. В том, действительно ли это разделение повышает устойчивость, не создавая ненужной сложности.

Делает ли поэтапный консенсус Dusk более устойчивым к плохим предложениям? Или добавленная координация создает новый компромисс?
#dusk $DUSK