Виталик призывает разработчиков ZK и FHE «напрямую показать коэффициент шифрования»: можно с первого взгляда увидеть разницу, а потом говорить об оптимизации

👤 02mp@Charlotte 📅 2026-07-18 02:01:22

Технологии конфиденциальности должны быть понятны с первого взгляда. Виталик Бутерин призвал разработчиков напрямую показывать «коэффициент эффективности», когда речь идет о производительности ЗК и ФХЭ.
(Предварительное резюме: Фонд Ethereum создал «Группу исследования конфиденциальности» для продвижения шести основных дорожных карт и полноценного запуска конкуренции в области конфиденциальности)
(Справочное дополнение: Фонд Ethereum выпустил комплексный план конфиденциальности, трехсторонний подход к укреплению основы DeFi и обеспечению соответствия)

Содержание этой статьи

Соучредитель Ethereum Виталик Бутерин недавно опубликовал статью о платформе X, в которой рекомендует разработчикам оценивать доказательства с нулевым разглашением (ZK) и полностью гомоморфное шифрование (FHE), следует отказаться от привычного показателя «N операций в секунду» и вместо этого сосредоточиться на соотношении эффективности «время расчета шифрования/исходное время расчета». Намерение состоит в том, чтобы предложить более прямой стандарт проверки возможности технологии конфиденциальности Web3.

Виталик уделяет особое внимание коэффициенту эффективности

Традиционные показатели пропускной способности чрезвычайно зависят от аппаратной среды и не могут выявить истинную нагрузку, вызванную уровнем шифрования. Виталик отмечает, что если разработчики знают, что первоначальный расчет занимает всего 1 миллисекунду, они смогут напрямую сделать вывод из коэффициента эффективности, как долго будет усиливаться шифрование.


Твиттер Виталика:

Я надеюсь, что больше людей, использующих ZK (с нулевым разглашением) и FHE (полностью гомоморфное шифрование), смогут использовать значения отношений для выражения дополнительных накладных расходов («время вычислений под криптографической защитой» по сравнению с «исходным временем вычислений»), вместо того, чтобы просто говорить «мы можем выполнять N операций в секунду».

Это более независимо от аппаратного обеспечения и может дать очень информативную информацию: если мое приложение защищено криптографией, а не доверием, насколько эффективностью я пожертвую?

Это также, как правило, лучше для оценки, потому что как разработчик я уже знаю, сколько времени занимает необработанный расчет, и я просто беру это время и умножаю его на множитель.

(Да, я знаю, что это сложно, поскольку операции, необходимые между «выполнением» и «генерацией доказательства», имеют разную природу, особенно с использованием SIMD/распараллеливания и шаблонов доступа к памяти, поэтому даже на соотношение все еще в некоторой степени влияет аппаратное обеспечение. Но даже в этом случае я все равно думаю, что выражение накладных расходов в виде кратного, хотя и не идеальное, все же является хорошим индикатором.)


Я бы хотел, чтобы больше людей из ZK и FHE указывали свои накладные расходы в виде отношения (время для вычислений в криптографии к времени для вычислений в необработанных данных), а не просто говорили: «Мы можем выполнять N операций в секунду».

Это более независимо от оборудования и дает очень информативное число: насколько я эффективен…

— Vitalik.eth (@VitalikButerin) 18 октября, 2025

Виталик подчеркнул, что, хотя на это соотношение по-прежнему будут влиять расположение памяти, степень распараллеливания и различия в наборе команд, оно, по крайней мере, позволяет сообществу «использовать одну и ту же линейку» для измерения разных решений.

Узкие места производительности ZK и FHE

ZK и FHE выполняют совершенно разные функции по защите конфиденциальности пользователей, но они также сталкиваются с большими накладными расходами. При увеличении сложности схемы ЗК время генерации доказательства может занять сотни раз. Узкое место FHE еще более очевидно. Версия FHE для вывода машинного обучения в 20 000 раз медленнее, чем обычный текст.

Эти задержки затрудняют реализацию таких сценариев, как DeFi, децентрализованная идентификация (DID) и ИИ в цепочке, а также подчеркивают важность структуры коэффициента эффективности. Поэтому Виталик призывает всех увидеть нагрузку каждого решения, прежде чем говорить об оптимизации.

Путь оптимизации и экологическое сотрудничество

Инициатива Виталика побуждает сообщество перераспределять ресурсы исследований и разработок. Видно, что в краткосрочной перспективе инновации на уровне алгоритмов по-прежнему остаются основным средством снижения этого соотношения. Следующей среднесрочной перспективой станет модернизация вычислительного оборудования GPU или ASIC, которая, как ожидается, позволит сократить время расчета абсолютного времени до диапазона, приемлемого для пользователей.

В долгосрочной перспективе выборочное шифрование и межуровневое сотрудничество станут ключом к массовому внедрению. В настоящее время индустрия шифрования продвигает стандартизацию схем ZK, оптимизацию компилятора FHE и обмен доказательствами вне сети. Цель состоит в том, чтобы снизить коэффициент эффективности без ущерба для конфиденциальности и выиграть больше сценариев для децентрализованных приложений.

Nhãn:
chia sẻ:
FB X YT IG
02mp@Charlotte

02mp@Charlotte

Trình chỉnh sửa chuỗi khối và tài sản tiền điện tử, tập trung vàophân tíchPhân tích nội dung tên miền và hiểu biết sâu sắc

Bình luận (10)

Una 11ngày trước
La industria todavía necesita tiempo para asentarse.
Elspeth 11ngày trước
Todavía hay muchas oportunidades para la innovación en la industria.
Vendaval 11ngày trước
En la actualidad, la industria todavía necesita tecnología para promoverse.
wallace 11ngày trước
El reconocimiento y la construcción de comunidad son cruciales.
jason 11ngày trước
Estamos de acuerdo en que la construcción a largo plazo es más importante que la narrativa a corto plazo.
Ciro 11ngày trước
Poner activos en la cadena es sólo el comienzo y la ecología es el futuro.
Natán 12ngày trước
Después de cargar una transacción en la cadena, ¿es realmente completamente inmodificable?
Edmundo 16ngày trước
El punto de vista es muy profundo y, de hecho, vale la pena esperar con ansias el futuro de blockchain.
yuri 26ngày trước
¿Por dónde debería empezar para empezar con el desarrollo de blockchain?
Esme 29ngày trước
El desarrollo actual de la industria requiere más paciencia.

Thêm nhận xét

Nội dung phổ biến