Я потратил час, отслеживая активацию PLONK V3 Dusk на блоке 3,590,904, а затем одна строка про безопасность кошелька отвлекла меня: репозиторий говорит, что внешний аудит еще не завершен.
Это не означает, что криптография Dusk слабая. Это значит, что серьезный криптографический талант оценивают по неверному поверхностному метрику.
Проверяющий доказательство может отклонять некорректные точки, не согласующиеся с публичными входными данными, и сжатые схемы — идеально, при этом транзакция пользователя все равно зависит от вывода пароля расширения, прав на память в JavaScript, разрешений нодового endpoint и подсказки при подписи.
Расширение использует PBKDF2 с 900 000 итераций и AES-GCM-256; нативный путь использует Stronghold плюс Argon2. Разные пути — разные допущения по доверию.
Так что я бы измерял поведение: сколько независимых сборок генерируют байт-в-байт одинаковые Solidity-верификаторы? Какое из некорректных доказательств потребляет больше всего газа до отклонения? Раскрывает ли CLI то же предупреждение о получателе, помеченное, что и Web Wallet? И был ли проверен путь подписи на уровне, сопоставимом с PLONK?
Некоторая асимметрия — нормальна. Браузерные кошельки не могут гарантировать зануление памяти JavaScript, а более простое развертывание верификатора имеет ценность даже если стоимость газа не снижается.
Но институциональная безопасность Dusk будет определяться самым слабым компонентом, на который опирается авторитет, а не его наиболее изящной математикой. Я слежу за тем, чтобы аудиты шли по пути транзакции end to end.
#dusk $DUSK @Dusk
Это не означает, что криптография Dusk слабая. Это значит, что серьезный криптографический талант оценивают по неверному поверхностному метрику.
Проверяющий доказательство может отклонять некорректные точки, не согласующиеся с публичными входными данными, и сжатые схемы — идеально, при этом транзакция пользователя все равно зависит от вывода пароля расширения, прав на память в JavaScript, разрешений нодового endpoint и подсказки при подписи.
Расширение использует PBKDF2 с 900 000 итераций и AES-GCM-256; нативный путь использует Stronghold плюс Argon2. Разные пути — разные допущения по доверию.
Так что я бы измерял поведение: сколько независимых сборок генерируют байт-в-байт одинаковые Solidity-верификаторы? Какое из некорректных доказательств потребляет больше всего газа до отклонения? Раскрывает ли CLI то же предупреждение о получателе, помеченное, что и Web Wallet? И был ли проверен путь подписи на уровне, сопоставимом с PLONK?
Некоторая асимметрия — нормальна. Браузерные кошельки не могут гарантировать зануление памяти JavaScript, а более простое развертывание верификатора имеет ценность даже если стоимость газа не снижается.
Но институциональная безопасность Dusk будет определяться самым слабым компонентом, на который опирается авторитет, а не его наиболее изящной математикой. Я слежу за тем, чтобы аудиты шли по пути транзакции end to end.
#dusk $DUSK @Dusk