Чи може доказ ZK у реальному часі, згаданий Віталіком, покладатися на апаратне прискорення ZK?

Оригінал |. Odaily Planet Daily

Автор |. Чоловік Як

Доказ ZK у реальному часі, згаданий Віталіком, можна отримати, покладаючись на апаратне прискорення ZK?

Під час Гонконгського карнавалу Web3 у 2024 році співзасновник Ethereum Віталік Бутерін виступив з промовою «Досягнення меж дизайну протоколів». У цьому виступі Віталік детально розповідає про те, як підвищити ефективність zk-snark.

У своїй промові Віталік зазначив, що поточний розвиток блокчейну базується на жертві конфіденційністю та масштабованістю, а властивості zk-snark можуть виправити жертву конфіденційністю та масштабованістю. Однак ефективність zk-snark наразі низька. В Ethereum час, який потрібен вузлу Ethereum для перевірки блоку, становить близько 400 мілісекунд, тоді як час, потрібний zk-snark для перевірки блоку Ethereum, становить близько 20 хвилин. , що змушує мережу. Забезпечуючи конфіденційність і масштабованість, час виконання в 3000 разів довший. Тому, якщо ви хочете запустити zk-snark в існуючу мережу блокчейну, вам потрібно надати «доказ у режимі реального часу», якщо час генерації підтвердження буде зменшено, можна покращити конфіденційність і масштабованість, забезпечуючи при цьому швидкість роботи блокчейну .

Яким методом можна отримати "доказ у реальному часі"? Для цього Odaily Planet Daily проаналізує ідеї, висловлені Віталіком у його промові, і коротко розповість про відповідні проекти.

zk-snark реалізує три напрямки «доказу в реальному часі»

Перед цим давайте дізнаємося про повну назву zk-snark — це стислий неінтерактивний доказ для кращого розуміння.

  • Доказ із нульовим знанням: тобто перевіряючий (Prover) може змусити верифікатор вважати певне твердження правильним, не надаючи жодної корисної інформації верифікатору (Verifier).
  • Простий: означає, що процес перевірки транзакції не передбачає передачі великих обсягів даних, а алгоритм перевірки простий.
  • Неінтерактивний: Немає потреби у взаємодії між довідником і верифікатором.

Нижче наведено схему операцій zk-snark. Проста інтерпретація zk-snark з картинки:

  1. Використовуйте налаштування, щоб згенерувати параметр довіри F за допомогою випадкових чисел і згенерувати ключ підтвердження pk і ключ підтвердження v.
  2. Проверювач вводить приватний вхід W і відкритий вхід x, генерує доказ π і підписує його закритим ключем pk. π зашифровано за допомогою еліптичної кривої, приховуючи W
  3. Верифікатор перевіряє доказ: верифікатор утримує v, вводить x і π і підтверджує, що перевіряльник знає W. Верифікатор не може знати W
  4. Повернення результату: TRUE, якщо перевірка пройшла успішно, інакше повертається FALSE.

Доказ ZK у реальному часі, згаданий Віталіком, можна отримати, покладаючись на апаратне прискорення ZK?

Завдяки наведеному вище вступу до процесу Zcash, пов’язаного з zk-snark, неважко виявити, що zk-snark не виконує багато кроків під час перевірки доказу, відповідно до характеристик zk-snark Згідно з відповідною статистикою, пов’язаною з zk-snark, час перевірки та перевірки зазвичай не перевищує 80 мілісекунд, чому zk-snark стає перешкодою для роботи публічного ланцюжка перевірка.

Доказ ZK у реальному часі, згаданий Віталіком, можна отримати, покладаючись на апаратне прискорення ZK?

Наведене вище зображення є підсумком найбільш поширених на даний момент технологій, пов’язаних з zk-snark. З нього неважко зрозуміти, що розмір доказу, час генерації доказу та час перевірки є стандартами для вимірювання zk-snark. технології. Незалежно від часу перевірки, більшість доказів zk-snark не відповідають стандартам, які використовував Віталік як приклад Ethereum на початку цієї статті, щодо розміру доказів і часу генерації де він розташований, не має функції смарт-контрактів, і його неможливо порівняти з розміром блоку Ethereum. Необхідний розмір доказу та час створення доказу вищі.

З цією метою Віталік у своїй промові надав три напрямки оптимізації рішення для реалізації «доказу реального часу» zk-snark.

  • Розпаралелювання та агрегація: підвищте ефективність перевірки великих блоків за допомогою паралельного обчислення та агрегації доказів. Кожен крок обчислення можна перевірити незалежно, а потім ці докази об’єднуються, щоб скоротити час обчислення та споживання ресурсів під час процесу перевірки. Цього можна досягти шляхом використання характеристик паралельних обчислень і розподілених систем для прискорення процесу перевірки великомасштабних блоків.
  • Покращення конструкції апаратного забезпечення: розробіть ASIC спеціально для обчислень SNARK, щоб підвищити ефективність обчислень. Подібно до ASIC, які використовуються в майнінгу, SNARK ASIC можуть прискорити процес обчислення SNARK за допомогою налаштованих апаратних структур і оптимізованих алгоритмів, завдяки чому досягається більша швидкість верифікації та менші витрати.
  • Покращення алгоритму: подальша оптимізація алгоритму snark, включаючи Groth 16, таблицю пошуку, 64-бітний snark, 32-бітний stark тощо, щоб покращити ефективність і масштабованість алгоритму. Крім того, можна досліджувати та розробляти більш ефективні хеш-функції та алгоритми підписів, щоб зробити їх більш придатними для обчислень snark і ще більше підвищити швидкість перевірки та використання ресурсів.

Віталік виступає за перший напрямок рішення – паралельне обчислення та агрегацію доказів, що вимагає оптимізації відповідних публічних ланцюжків і процесів роботи zk-snark, таких як рекурсивні властивості алгоритму Plonk у попередньому алгоритмі zk-snark. Однак паралельні обчислення та докази агрегації наразі недоступні Немає кращого рішення для вирішення відповідної проблеми.

Що стосується вдосконалення алгоритму, то наразі в області zk-snark, з точки зору продуктивності, досі залишається алгоритм Groth 16. Подальші алгоритми zk-snark здебільшого призначені для вирішення проблеми довірених налаштувань, і немає ніяких покращень у. Швидкість роботи та час генерації доказів Існує великий прогрес, і в алгоритмі zk-snark налаштування довіри приблизно просте, чим швидше він працює, але тим гірша безпека. З цієї причини, з точки зору безпеки, zk-snark потрібно продовжувати створювати, щоб збільшити його швидкість.

Наведені вище два напрямки вирішення в основному підтримуються теорією, яка займе багато часу, щоб досягти прориву. Отже, окрім теорії, чи можна швидко досягти «доказу в реальному часі» іншими методами? Удосконалення апаратного забезпечення може бути найкращим способом досягнення ваших цілей.

Апаратне прискорення ZK може ввімкнути «доказ у реальному часі» якомога швидше

З попереднього вмісту про продуктивність zk-snark неважко виявити, що справжнє обмеження продуктивності zk-snark полягає в генерації доказів, де розмір перевірки та масштаб схеми визначають час створення перевірки. В даний час більшість проектів стають все більш і більш складними, їх розмір і масштаб схеми також постійно зростають, а обчислювальна потужність для створення доказів також зростає. З цієї причини виник проект апаратного прискорення ZK.

Апаратне прискорення ZK в основному забезпечує підтримку обчислювальної потужності для завдань поліноміального типу NTT і завдань еліптичної кривої MSM у створенні доказів. В основному логіка виконання цих двох завдань проста, більшість логіки обчислень повторюється, і можна виконувати паралельні обчислення.

Обладнання ZK мало чим відрізняється від обладнання для майнінгу, все ще є три типи: GPU, FPGA та ASIC. Однак рішення GPU/FPGA наразі є більш поширеним у сфері апаратного прискорення ZK. Це рішення легше реалізувати, а відповідні аксесуари легше отримати поточні точки зростання в області апаратного прискорення ZK.

Наразі проект апаратного прискорення ZK використовує два методи надання послуг обчислювальної потужності для пов’язаних проектів ZK, включаючи продаж апаратного забезпечення та послуги обчислювальної потужності SaaS. Продаж апаратного забезпечення, як випливає з назви, продає машини для майнінгу, як і Bitmain; послуги обчислювальної потужності SaaS більше схожі на ринок обчислювальної потужності, де проекти ZK можуть купувати обчислювальну потужність, щоб допомогти проектам створити докази ZK.

Зараз галузь апаратного прискорення ZK є відносно нішевою, якби Віталік не згадав про це у своєму виступі, більшість людей не знали б, які існують проекти. З цієї причини Odaily Planet Daily відсортував проекти в цьому секторі, серед яких Cysic, Ingopedia, Supranational, Ulvantanna та Auradine є відносно відомими проектами.

Серед них Cysic наразі привертає велику увагу, а його апаратне прискорення FPGA/ASIC є видатним щодо продуктивності обчислювальної потужності. Він також має ринок обчислювальної потужності, щоб надати клієнтам послуги з підтримки обчислювальної потужності; Auradine є більш комплексним, і його головне просування Він також забезпечує відповідне обладнання для обчислення ZK, але обладнання ZK не є його основним продуктом; для забезпечення підтримки обчислювальної потужності для проекту ZK варто відзначити в основному кластери ZK Capital є його інвестором; оновлення проекту на офіційному веб-сайті Twitter є невідомим, чи працюють вони в даний час на базі GPU і FPGA.

Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
  • Нагородити
  • 1
  • Репост
  • Поділіться
Прокоментувати
0/400
GateUser-e1f1f745vip
· 2024-04-12 01:55
Я думаю, що багато про 2.2 однаково
Переглянути оригіналвідповісти на0
  • Закріпити