Один из самых неловких моментов в цепочке расчетов ценных бумаг — это не обязательно взлом хакерами; зачастую никто явно не творит злое дело, но журнал (реестр) так и не удается перевернуть на следующую страницу. Узлы отключаются, возникает сетевое разделение, комиссия не может набрать нужное количество голосов: деньги не исчезают, но все вынуждены ждать. Для обычной публичной сети это называют перегрузкой, а для финансового рынка это может напрямую превратиться в инцидент расчетов.
Я снова просмотрел @Dusk Whitepaper в разделе Emergency Mode и обнаружил, что там не притворяются, будто такого не случится. В Succinct Attestation за одну «итерацию» максимум выполняется 50 циклов; если подряд 16 итераций терпят неудачу, протокол переходит в аварийный режим. Шаги в рамках обычного процесса, для которых истекло время ожидания, отключаются, а NoCandidate и NoQuorum больше не рассматриваются как результат для продвижения вперед. Уже запущенные итерации продолжают ждать, пока в «кандидатной» области появится блок, а затем состоятся двухфазные этапы — проверка и одобрение — пока не будет набрано установленное число голосов.
Смысл этого решения очень прямой: в обычной ситуации консенсус может «переключиться» на следующую группу людей из‑за таймаута, но в крайних случаях нельзя бесконечно обходить проблему, прикрываясь фразой «просто никто вовремя не собрался». Система предпочитает держать несколько параллельно открытых итераций, а не останавливаться, и ждать, пока найдется блок, который сможет подтвердить комиссия — так повышается вероятность того, что реестр продолжит продвигаться дальше.
Однако плата тоже описана в whitepaper. Параллельные итерации могут привести к тому, что в одной и той же «раунде» появится несколько кандидатов, уже признанных консенсусом; риск форка при этом растет. Поэтому протокол может выбрать только кандидата с наименьшим номером итерации, чтобы «свернуть» процесс. Если в самом конце восстановить работу так и не удастся, большинство прав по стейкингу все еще может совместно запросить аварийный пустой блок, который не содержит транзакций. Dusk‑ноды сгенерируют новую «seed», и сеть сможет перескочить через этот раунд.
Я не буду трактовать это как «бесконечную остановку». Это больше похоже на руководство по восстановлению после катастроф: признать, что консенсус может замедлиться, и заранее определить, кто сможет продвинуть восстановление, а также что именно можно пожертвовать во время восстановления. В будущем, оценивая $DUSK способности к финансовым расчетам, меня будет больше интересовать реальное число срабатываний аварийного режима, его длительность, количество форков и запросы пустых блоков — а не только то, сколько секунд требуется для блока в «нормальном состоянии».
Настоящая инфраструктура уровня организаций — это не та, которая никогда не выходит из строя. Это та, в которой правила обработки заранее прописаны на случай сбоя, а цена и последствия видны всем.
#dusk
Я снова просмотрел @Dusk Whitepaper в разделе Emergency Mode и обнаружил, что там не притворяются, будто такого не случится. В Succinct Attestation за одну «итерацию» максимум выполняется 50 циклов; если подряд 16 итераций терпят неудачу, протокол переходит в аварийный режим. Шаги в рамках обычного процесса, для которых истекло время ожидания, отключаются, а NoCandidate и NoQuorum больше не рассматриваются как результат для продвижения вперед. Уже запущенные итерации продолжают ждать, пока в «кандидатной» области появится блок, а затем состоятся двухфазные этапы — проверка и одобрение — пока не будет набрано установленное число голосов.
Смысл этого решения очень прямой: в обычной ситуации консенсус может «переключиться» на следующую группу людей из‑за таймаута, но в крайних случаях нельзя бесконечно обходить проблему, прикрываясь фразой «просто никто вовремя не собрался». Система предпочитает держать несколько параллельно открытых итераций, а не останавливаться, и ждать, пока найдется блок, который сможет подтвердить комиссия — так повышается вероятность того, что реестр продолжит продвигаться дальше.
Однако плата тоже описана в whitepaper. Параллельные итерации могут привести к тому, что в одной и той же «раунде» появится несколько кандидатов, уже признанных консенсусом; риск форка при этом растет. Поэтому протокол может выбрать только кандидата с наименьшим номером итерации, чтобы «свернуть» процесс. Если в самом конце восстановить работу так и не удастся, большинство прав по стейкингу все еще может совместно запросить аварийный пустой блок, который не содержит транзакций. Dusk‑ноды сгенерируют новую «seed», и сеть сможет перескочить через этот раунд.
Я не буду трактовать это как «бесконечную остановку». Это больше похоже на руководство по восстановлению после катастроф: признать, что консенсус может замедлиться, и заранее определить, кто сможет продвинуть восстановление, а также что именно можно пожертвовать во время восстановления. В будущем, оценивая $DUSK способности к финансовым расчетам, меня будет больше интересовать реальное число срабатываний аварийного режима, его длительность, количество форков и запросы пустых блоков — а не только то, сколько секунд требуется для блока в «нормальном состоянии».
Настоящая инфраструктура уровня организаций — это не та, которая никогда не выходит из строя. Это та, в которой правила обработки заранее прописаны на случай сбоя, а цена и последствия видны всем.
#dusk
