Когда я только начал знакомиться с Dusk, у меня сразу возник огромный вопрос. Ведь при том, что и другие проекты создают приватные блокчейны, любой желающий может подключиться и участвовать в производстве блоков; а в Dusk используется разрешительная модель для узлов. Тогда интуитивно мне казалось, что это ради более высокой скорости «пожертвовали» децентрализацией — и первое впечатление тут же сильно поблекло.
Только когда я терпеливо разобрался в полной картине нижнего уровня, стало ясно: мое прежнее понимание было неверным. Честно говоря, это не уступка, продиктованная тем, что разработчикам «лень»; это архитектурное решение, которого нельзя избежать, если вы хотите делать ZK-приватность.
@Dusk она умно разделяет выполнение смарт-контрактов и консенсус по блокам на две независимые стадии. В изолированной среде Piecrust VM запускаются контракты, чтобы генерировать ZK-доказательство; такие чувствительные данные, как сумма транзакции и адреса пользователей, на всем протяжении не раскрываются. Верифицирующие узлы комитета SBA не видят исходное содержание транзакций — они лишь проверяют, насколько само доказательство убедительно и надежно, и фиксируют окончательное состояние блока.
Иными словами, верифицирующие узлы — это как «экзаменаторы с закрытыми билетами»: они не получают «оригинальные условия задач» для проверяемых. Как только снять все пороги и полностью открыть доступ, в сеть быстро хлынет множество узлов с сомнительным происхождением. В такой ситуации очень легко получить уязвимости вроде сбоев валидации и вредоносного «пустого прогонов», из-за чего пользователям будет трудно сохранить приватность.
Конечно, у этой схемы есть и свои недостатки, которые никуда не деться. Путь компиляции WASM‑ZK — новый, и он неизбежно повышает издержки на генерацию доказательств; а разрешительный отбор узлов тоже может привести к потенциальной проблеме чрезмерной концентрации. $DUSK
Сейчас я пристально наблюдаю за тем, сможет ли система удержать издержки валидации, когда после этого на блокчейн зайдут большие объемы RWA-объектов реальных активов, и удастся ли сбалансировать отношения между приватностью, безопасностью и децентрализацией.
Как вы оцениваете консенсус Dusk с разрешительными узлами?
#dusk $DUSK @Dusk
Только когда я терпеливо разобрался в полной картине нижнего уровня, стало ясно: мое прежнее понимание было неверным. Честно говоря, это не уступка, продиктованная тем, что разработчикам «лень»; это архитектурное решение, которого нельзя избежать, если вы хотите делать ZK-приватность.
@Dusk она умно разделяет выполнение смарт-контрактов и консенсус по блокам на две независимые стадии. В изолированной среде Piecrust VM запускаются контракты, чтобы генерировать ZK-доказательство; такие чувствительные данные, как сумма транзакции и адреса пользователей, на всем протяжении не раскрываются. Верифицирующие узлы комитета SBA не видят исходное содержание транзакций — они лишь проверяют, насколько само доказательство убедительно и надежно, и фиксируют окончательное состояние блока.
Иными словами, верифицирующие узлы — это как «экзаменаторы с закрытыми билетами»: они не получают «оригинальные условия задач» для проверяемых. Как только снять все пороги и полностью открыть доступ, в сеть быстро хлынет множество узлов с сомнительным происхождением. В такой ситуации очень легко получить уязвимости вроде сбоев валидации и вредоносного «пустого прогонов», из-за чего пользователям будет трудно сохранить приватность.
Конечно, у этой схемы есть и свои недостатки, которые никуда не деться. Путь компиляции WASM‑ZK — новый, и он неизбежно повышает издержки на генерацию доказательств; а разрешительный отбор узлов тоже может привести к потенциальной проблеме чрезмерной концентрации. $DUSK
Сейчас я пристально наблюдаю за тем, сможет ли система удержать издержки валидации, когда после этого на блокчейн зайдут большие объемы RWA-объектов реальных активов, и удастся ли сбалансировать отношения между приватностью, безопасностью и децентрализацией.
Как вы оцениваете консенсус Dusk с разрешительными узлами?
#dusk $DUSK @Dusk
A、架构设计很强,隐私赛道的优选方案
0%
B、存在中心化隐患,长远来看风险不小
0%
C、保持中立观望,静待后续落地迭代
0%
0 проголосовали • Голосование закрыто