#dusk $DUSK @Dusk
То, что привлекло мое внимание, — не «нулевая осведомленность» (zero knowledge) Dusk, которой обычно уделяют больше всего внимания. Меня заинтересовала более мелкая деталь в том, как блок реально становится окончательным.
Я хотел проверить, как Succinct Attestation, permissionless-протокол DuskDS на основе комитетов BFT proof-of-stake, на практике подтверждает транзакцию — ведь здесь «мгновенное завершение» (instant settlement) упоминают довольно вольно.
Каждый раунд проходит три шага: provisioner предлагает и транслирует кандидатный блок; комитет его валидирует; затем второй комитет ратифицирует эту валидацию и финализирует блок. Только после согласия обоих комитетов блок продвигается дальше.
Интересно, что @Dusk не рассматривает окончательность как единое бинарное событие. Блок считается Accepted, когда он проходит все три этапа; Confirmed — когда позже на него начинают опираться последующие блоки; Stable — когда он достаточно «похоронен» глубже; и, наконец, Final — детерминированно и криптографически гарантированно, то есть его нельзя отменить.
Для регулируемых расчетов (regulated settlement) такая многоступенчатая разница важнее, чем просто скорость. Хранителю (custodian) недостаточно, чтобы транзакция была быстрой — ему нужен определенный момент, когда необратимость можно доказать, а не просто предполагать.
Что я бы хотел уточнить, так это поведение при длительной нагрузке. Согласование двух отдельных комитетов добавляет этап координации, который пропускают цепочки с одним proposer. По мере роста набора provisioner и распределения стейка: ратификация остается быстрой или сама координация комитетов становится узким местом?
Документация описывает фазы и разделение вознаграждений: 70% proposer и 5%/5% комитетам валидации и ратификации — ясно, что они делают. Но то, что они не проясняют, — это потолок пропускной способности при реальной сетевой перегрузке; описано только поведение в тестнете.
Кто-нибудь видел данные по выбору комитетов или времени до финальности (finality Time) в Dusk при реальной длительной нагрузке транзакций, а не в условиях простоя сети?
$DUSK #Dusk
То, что привлекло мое внимание, — не «нулевая осведомленность» (zero knowledge) Dusk, которой обычно уделяют больше всего внимания. Меня заинтересовала более мелкая деталь в том, как блок реально становится окончательным.
Я хотел проверить, как Succinct Attestation, permissionless-протокол DuskDS на основе комитетов BFT proof-of-stake, на практике подтверждает транзакцию — ведь здесь «мгновенное завершение» (instant settlement) упоминают довольно вольно.
Каждый раунд проходит три шага: provisioner предлагает и транслирует кандидатный блок; комитет его валидирует; затем второй комитет ратифицирует эту валидацию и финализирует блок. Только после согласия обоих комитетов блок продвигается дальше.
Интересно, что @Dusk не рассматривает окончательность как единое бинарное событие. Блок считается Accepted, когда он проходит все три этапа; Confirmed — когда позже на него начинают опираться последующие блоки; Stable — когда он достаточно «похоронен» глубже; и, наконец, Final — детерминированно и криптографически гарантированно, то есть его нельзя отменить.
Для регулируемых расчетов (regulated settlement) такая многоступенчатая разница важнее, чем просто скорость. Хранителю (custodian) недостаточно, чтобы транзакция была быстрой — ему нужен определенный момент, когда необратимость можно доказать, а не просто предполагать.
Что я бы хотел уточнить, так это поведение при длительной нагрузке. Согласование двух отдельных комитетов добавляет этап координации, который пропускают цепочки с одним proposer. По мере роста набора provisioner и распределения стейка: ратификация остается быстрой или сама координация комитетов становится узким местом?
Документация описывает фазы и разделение вознаграждений: 70% proposer и 5%/5% комитетам валидации и ратификации — ясно, что они делают. Но то, что они не проясняют, — это потолок пропускной способности при реальной сетевой перегрузке; описано только поведение в тестнете.
Кто-нибудь видел данные по выбору комитетов или времени до финальности (finality Time) в Dusk при реальной длительной нагрузке транзакций, а не в условиях простоя сети?
$DUSK #Dusk