#dusk $DUSK @Dusk
Раньше я думал, что консенсус в дизайне блокчейна — это скучная часть любого проекта: инженеры спорят об этом, но это не то, что определяет, сможет ли на платформе реально выполняться финансовая активность. Но после того, как я разобрался, как работает валидаторский набор Dusk, мое мнение немного изменилось.
Большинство цепочек, ориентированных на регулируемые финансы, по-прежнему строят консенсус, рассчитанный прежде всего на открытое участие, а соответствие требованиям (compliance) добавляют позже. Dusk не отказывается от этой «базы» без разрешений — любой, кто блокирует требуемый стейк, может стать provisioner — но делает с этим кое-что конкретное. Консенсус Succinct Attestation выбирает комитеты подходящих provisioner’ов с помощью детерминированной сортировки (deterministic sortition), и эти комитеты предлагают, валидируют и ратифицируют каждый блок через явные раунды голосования, а не через вероятностную финализацию. Это важно: сети, где институциональным участникам нужно проводить расчеты по сделкам, требуется однозначный, проверяемый ответ о финализации блока — при этом не превращая реестр в открытую книгу со всей активностью каждого участника.
Показательно, что это подается не как компромисс между децентрализацией и комплаенсом, а как ограничение дизайна с самого первого дня. Оператор рынка, работающий, например, по лицензии ЕС MTF, нуждается в консенсусном процессе, результат которого можно проверять блок за блоком, не допуская того, чтобы каждый контрагент видел каждую сделку. Это отличается от оптимизации под TPS или комиссии за газ — о чем большинство нарративов «enterprise blockchain» просто умалчивают.
Кроме того, это поднимает вопрос, на который у меня пока нет точного ответа: финализация на основе комитетов просит provisioner’ов на каждом раунде реально сойтись и сформировать аттестацию, вместо того чтобы позволить цепочке «дозреть» до нужного состояния со временем. Насколько это лучше подходит для регулируемых расчетов — или же это просто иной компромисс между живучестью (liveness) и участием — стоит проверить в реальных условиях сети, а не предполагать исходя лишь из дизайна. Мы не узнаем этого, пока реальный институциональный объем не попытается проводить расчеты on-chain и не начнет испытывать эти предположения под давлением.
Раньше я думал, что консенсус в дизайне блокчейна — это скучная часть любого проекта: инженеры спорят об этом, но это не то, что определяет, сможет ли на платформе реально выполняться финансовая активность. Но после того, как я разобрался, как работает валидаторский набор Dusk, мое мнение немного изменилось.
Большинство цепочек, ориентированных на регулируемые финансы, по-прежнему строят консенсус, рассчитанный прежде всего на открытое участие, а соответствие требованиям (compliance) добавляют позже. Dusk не отказывается от этой «базы» без разрешений — любой, кто блокирует требуемый стейк, может стать provisioner — но делает с этим кое-что конкретное. Консенсус Succinct Attestation выбирает комитеты подходящих provisioner’ов с помощью детерминированной сортировки (deterministic sortition), и эти комитеты предлагают, валидируют и ратифицируют каждый блок через явные раунды голосования, а не через вероятностную финализацию. Это важно: сети, где институциональным участникам нужно проводить расчеты по сделкам, требуется однозначный, проверяемый ответ о финализации блока — при этом не превращая реестр в открытую книгу со всей активностью каждого участника.
Показательно, что это подается не как компромисс между децентрализацией и комплаенсом, а как ограничение дизайна с самого первого дня. Оператор рынка, работающий, например, по лицензии ЕС MTF, нуждается в консенсусном процессе, результат которого можно проверять блок за блоком, не допуская того, чтобы каждый контрагент видел каждую сделку. Это отличается от оптимизации под TPS или комиссии за газ — о чем большинство нарративов «enterprise blockchain» просто умалчивают.
Кроме того, это поднимает вопрос, на который у меня пока нет точного ответа: финализация на основе комитетов просит provisioner’ов на каждом раунде реально сойтись и сформировать аттестацию, вместо того чтобы позволить цепочке «дозреть» до нужного состояния со временем. Насколько это лучше подходит для регулируемых расчетов — или же это просто иной компромисс между живучестью (liveness) и участием — стоит проверить в реальных условиях сети, а не предполагать исходя лишь из дизайна. Мы не узнаем этого, пока реальный институциональный объем не попытается проводить расчеты on-chain и не начнет испытывать эти предположения под давлением.