Когда я изучаю механизм консенсуса Dusk, больше всего времени у меня уходит не на то, кто именно формирует блоки, а на Succinct Attestation — ту часть в этом названии, которую проще всего пропустить.
Давайте сначала разберём, какую проблему решает это решение. Подтверждение блоков в Dusk многоэтапное: Deterministic Sortition выбирает участников для разных этапов среди тех Provisioner’ов, которые соответствуют условиям, затем идут Proposal, Validation и Ratification, чтобы завершить подтверждение. Главная сложность многоэтапных схем в том, что процесс становится более запутанным: как сделать так, чтобы все могли с низкой стоимостью поверить в то, что «результат действительно верный»? Succinct Attestation как раз и делает это — сжимает доказательства многоэтапного консенсуса в компактное доказательство, чтобы окончательность можно было проверить, не воспроизводя весь процесс заново.
Смысл этого дизайна особенно хорошо виден в финансовых сценариях. Финансовым учреждениям важна не «быстрая генерация блоков», а «подтверждение — это окончательно». То есть по завершении расчёта не должно оставаться вероятности отката, которая висит в воздухе. У большинства цепочек окончательность вероятностная (после большего числа подтверждённых блоков). Dusk же делает окончательность проверяемой: Attestation — это то самое удостоверение «на этом всё», «необратимо».
Это также заставило меня по-новому понять, почему этим стоит заниматься: расхождения в дизайне консенсуса по сути — это разногласия о том, «во что именно верить». В одних цепочках доверяют вычислительным мощностям, в других — залогам. В Dusk доверяют «честности случайного выбора плюс доказуемой сжатости». Что лучше — покажет время.
Конечно, чем точнее и сложнее механизм, тем больше того, что нужно проверить. Инженерная реализация Succinct Attestation и его поведение в экстремальных сетевых условиях всё ещё требуют проверки временем — как правило, максимальный риск сложных механизмов прячется именно в их собственной сложности.
@Dusk $DUSK #dusk
Давайте сначала разберём, какую проблему решает это решение. Подтверждение блоков в Dusk многоэтапное: Deterministic Sortition выбирает участников для разных этапов среди тех Provisioner’ов, которые соответствуют условиям, затем идут Proposal, Validation и Ratification, чтобы завершить подтверждение. Главная сложность многоэтапных схем в том, что процесс становится более запутанным: как сделать так, чтобы все могли с низкой стоимостью поверить в то, что «результат действительно верный»? Succinct Attestation как раз и делает это — сжимает доказательства многоэтапного консенсуса в компактное доказательство, чтобы окончательность можно было проверить, не воспроизводя весь процесс заново.
Смысл этого дизайна особенно хорошо виден в финансовых сценариях. Финансовым учреждениям важна не «быстрая генерация блоков», а «подтверждение — это окончательно». То есть по завершении расчёта не должно оставаться вероятности отката, которая висит в воздухе. У большинства цепочек окончательность вероятностная (после большего числа подтверждённых блоков). Dusk же делает окончательность проверяемой: Attestation — это то самое удостоверение «на этом всё», «необратимо».
Это также заставило меня по-новому понять, почему этим стоит заниматься: расхождения в дизайне консенсуса по сути — это разногласия о том, «во что именно верить». В одних цепочках доверяют вычислительным мощностям, в других — залогам. В Dusk доверяют «честности случайного выбора плюс доказуемой сжатости». Что лучше — покажет время.
Конечно, чем точнее и сложнее механизм, тем больше того, что нужно проверить. Инженерная реализация Succinct Attestation и его поведение в экстремальных сетевых условиях всё ещё требуют проверки временем — как правило, максимальный риск сложных механизмов прячется именно в их собственной сложности.
@Dusk $DUSK #dusk
