@Dusk 的 консенсус называется Succinct Attestation, PoS с комитетом-при-одобрении. После утверждения блока наступает детерминированная финальность; при нормальной работе нет перегруппировок, которые были бы заметны пользователям. В третьей главе white paper есть полные спецификации.
Увидев слова «комитетная схема», первая реакция обычно такая: каждый блок решает небольшой набор участников, и разве это не более централизованно, чем модель Nakamoto?
Потом я понял: для этой цепочки это не компромисс, а предпосылка.
Первая причина связана с правом. В ЕС для финальности расчетов есть отдельная директива: «свершено/проведено» — это юридический статус, а не описание вероятности. Когда сделка в модели DvP выполнена, деньги нельзя откатить назад. Относить вероятностную финальность к этому — не вопрос удобства восприятия: это означает отмену юридически завершенной поставки, то есть уже не «добавить блок», а судебный процесс.
Вторая причина интереснее и напрямую связана с приватностью.
В прозрачной цепочке при реорганизациях возможны воспроизведение (replay) и сверка: состояние «раскладывается» и видно, кто кому что отправил. Скрытое состояние устроено иначе. Phoenix — это модель «note + nullifier»: после реорганизации нужно заново разбираться, какие note уже были потрачены, а какие nullifier должны стать недействительными. Сложность при этом вообще несопоставима с прозрачным бухгалтерским учетом.
То есть допустимая «терпимость» к вероятностной финальности для приватной цепочки ниже, а не выше, чем для прозрачной. Чем выше степень криптозащиты, тем сильнее вы полагаетесь на жесткую гарантию «этот блок и есть финальный».
Поэтому комитетная схема — это не способ обменять централизацию на производительность, а необходимое условие, чтобы одновременно решить две задачи: приватность и расчеты/свершение. Если выбрали Phoenix, почти неизбежно придется выбрать детерминированную финальность.
Цена при этом тоже реальна. Обратная сторона детерминированной финальности такая: когда условия плохие, цепочка скорее предпочтет остановиться, а не разветвиться. Остановка — это другой риск, и доступность комитета становится ключевой переменной для «живости» системы. Эту часть нужно держать под контролем.
Все вышеизложенное основано на официальной документации и публичных материалах white paper; детали могли измениться, сверяйте самостоятельно. Это не является рекомендацией.
Итак, последний вопрос: если в ончейне работает зашифрованное состояние, предпочли бы вы, чтобы цепочка иногда останавливалась, а не чтобы иногда откатывалась?
#dusk $DUSK @Dusk
Увидев слова «комитетная схема», первая реакция обычно такая: каждый блок решает небольшой набор участников, и разве это не более централизованно, чем модель Nakamoto?
Потом я понял: для этой цепочки это не компромисс, а предпосылка.
Первая причина связана с правом. В ЕС для финальности расчетов есть отдельная директива: «свершено/проведено» — это юридический статус, а не описание вероятности. Когда сделка в модели DvP выполнена, деньги нельзя откатить назад. Относить вероятностную финальность к этому — не вопрос удобства восприятия: это означает отмену юридически завершенной поставки, то есть уже не «добавить блок», а судебный процесс.
Вторая причина интереснее и напрямую связана с приватностью.
В прозрачной цепочке при реорганизациях возможны воспроизведение (replay) и сверка: состояние «раскладывается» и видно, кто кому что отправил. Скрытое состояние устроено иначе. Phoenix — это модель «note + nullifier»: после реорганизации нужно заново разбираться, какие note уже были потрачены, а какие nullifier должны стать недействительными. Сложность при этом вообще несопоставима с прозрачным бухгалтерским учетом.
То есть допустимая «терпимость» к вероятностной финальности для приватной цепочки ниже, а не выше, чем для прозрачной. Чем выше степень криптозащиты, тем сильнее вы полагаетесь на жесткую гарантию «этот блок и есть финальный».
Поэтому комитетная схема — это не способ обменять централизацию на производительность, а необходимое условие, чтобы одновременно решить две задачи: приватность и расчеты/свершение. Если выбрали Phoenix, почти неизбежно придется выбрать детерминированную финальность.
Цена при этом тоже реальна. Обратная сторона детерминированной финальности такая: когда условия плохие, цепочка скорее предпочтет остановиться, а не разветвиться. Остановка — это другой риск, и доступность комитета становится ключевой переменной для «живости» системы. Эту часть нужно держать под контролем.
Все вышеизложенное основано на официальной документации и публичных материалах white paper; детали могли измениться, сверяйте самостоятельно. Это не является рекомендацией.
Итак, последний вопрос: если в ончейне работает зашифрованное состояние, предпочли бы вы, чтобы цепочка иногда останавливалась, а не чтобы иногда откатывалась?
#dusk $DUSK @Dusk