#dusk $DUSK
За эти два дня я просмотрел последний выпуск @Dusk Developer Update. Есть одно обновление, которое, как мне кажется, стоит смотреть больше, чем фраза «просто добавили ещё одну ZK-возможность».
Теперь zk-tools начинает дополнять генерацию и валидацию Groth16 Solidity verifier.
На первый взгляд — что-то небольшое.
Но если вы реально писали ZK-приложения, то знаете: proof готов только половина дела.
Дальше возникает очень практичный вопрос:
как Solidity-контракт «понимает» эту proof?
Правила задаются в circuit: prover генерирует proof. А на стороне EVM нужно, чтобы verifier-контракт проверял, что proof и public inputs соответствуют исходным ограничениям.
Если этот слой интерфейса сделан плохо, то даже при очень сильной криптографии обычным Solidity-разработчикам это всё равно остаётся далеко.
Поэтому, глядя на это обновление Dusk, я считаю, что главная ценность не в самом названии Groth16.
А в том, что оно закрывает:
proof → verifier → Solidity application
— цепочку инженерных звеньев между ними.
Конечно, verifier тоже не «всемогущий».
Он может подтвердить, что конкретная proof соответствует заранее написанному circuit. Но откуда взялись данные, имеет ли это правило смысл для бизнеса и действительна ли «квалификация» сейчас — это всё должно определяться самим приложением.
И в этом я как раз ничего удивительного не вижу.
Криптография отвечает за то, чтобы «доказательство» было проверено по делу. А продукт сам решает, что именно делать с этим доказательством.
Сейчас DuskEVM ещё на Testnet, и я не буду утверждать, что вся ZK-workflow уже созрела, только потому что добавили ещё один tooling для verifier.
Но такие обновления, по крайней мере, куда реальнее, чем одна фраза «поддерживаем ZK».
То, что действительно позволяет разработчикам начать использовать технологию, чаще всего — это именно такие интерфейсы, которые выглядят не слишком «сексапильно».
За эти два дня я просмотрел последний выпуск @Dusk Developer Update. Есть одно обновление, которое, как мне кажется, стоит смотреть больше, чем фраза «просто добавили ещё одну ZK-возможность».
Теперь zk-tools начинает дополнять генерацию и валидацию Groth16 Solidity verifier.
На первый взгляд — что-то небольшое.
Но если вы реально писали ZK-приложения, то знаете: proof готов только половина дела.
Дальше возникает очень практичный вопрос:
как Solidity-контракт «понимает» эту proof?
Правила задаются в circuit: prover генерирует proof. А на стороне EVM нужно, чтобы verifier-контракт проверял, что proof и public inputs соответствуют исходным ограничениям.
Если этот слой интерфейса сделан плохо, то даже при очень сильной криптографии обычным Solidity-разработчикам это всё равно остаётся далеко.
Поэтому, глядя на это обновление Dusk, я считаю, что главная ценность не в самом названии Groth16.
А в том, что оно закрывает:
proof → verifier → Solidity application
— цепочку инженерных звеньев между ними.
Конечно, verifier тоже не «всемогущий».
Он может подтвердить, что конкретная proof соответствует заранее написанному circuit. Но откуда взялись данные, имеет ли это правило смысл для бизнеса и действительна ли «квалификация» сейчас — это всё должно определяться самим приложением.
И в этом я как раз ничего удивительного не вижу.
Криптография отвечает за то, чтобы «доказательство» было проверено по делу. А продукт сам решает, что именно делать с этим доказательством.
Сейчас DuskEVM ещё на Testnet, и я не буду утверждать, что вся ZK-workflow уже созрела, только потому что добавили ещё один tooling для verifier.
Но такие обновления, по крайней мере, куда реальнее, чем одна фраза «поддерживаем ZK».
То, что действительно позволяет разработчикам начать использовать технологию, чаще всего — это именно такие интерфейсы, которые выглядят не слишком «сексапильно».
