1. Фон

Співзасновник Ethereum Віталік Бутерін дав зрозуміти, що «якщо не буде здійснено технологічний перехід до конфіденційності, Ethereum зазнає краху». Це тому, що всі транзакції є загальнодоступними, і для багатьох користувачів жертва конфіденційністю є занадто великою, що змушує їх звертатися до централізованих рішень, які принаймні до певної міри приховують дані.

У 2023 році Віталік провів серію досліджень щодо захисту конфіденційності та технології доказів з нульовим знанням (ZK). За перше півріччя Віталік опублікував на своєму сайті три статті, присвячені саме ЗК і захисту приватності. У квітні він також представив дослідження щодо проблем конфіденційності зберігача гаманців на Reddit. У вересні він разом з іншими професіоналами написав статтю, в якій пропонується рішення для досягнення балансу між конфіденційністю та відповідністю.

Крім того, екосистема Ethereum активно сприяє обговоренню та популяризації цієї теми. У березні на заході ETHDenver відбувся спеціальний захід, присвячений конфіденційності. На щорічній конференції спільноти Ethereum (EDCON) у травні Віталік підкреслив, що «протягом наступних 10 років ZK-SNARK буде таким же важливим, як і блокчейн».

У цій статті відстежуються останні події в екосистемі Ethereum у 2023 році щодо використання технології ZK для покращення захисту конфіденційності. Якщо ви хочете вийти на трек Ethereum ZK, ця стаття може надати необхідну інтерпретацію та вказівки.

2. Ethereum ZK Track: Building the Future of Privacy Protection

Прозорість Ethereum може поставити особисту інформацію користувачів під загрозу витоку. У блокчейнах, таких як Ethereum, немає секретів, і вся інформація є загальнодоступною, включаючи транзакції, голосування та інші дії в ланцюзі. Таке оприлюднення може призвести до відстеження конкретних транзакцій та адрес і пов’язування їх із справжніми користувачами. Тому впровадження захисту конфіденційності на Ethereum стає вирішальним. Приховати інформацію в ланцюжку можна за допомогою технології шифрування, але завдання полягає в тому, щоб переконатися, що дійсність цих транзакцій можна перевірити, одночасно захищаючи конфіденційність. Технологія ZK надає рішення, яке може довести справжність транзакцій без розкриття додаткової інформації, враховуючи конфіденційність і можливість перевірки.

Ethereum надає великого значення ZK-SNARK, особливо в певних ключових випадках використання захисту конфіденційності, де його значення особливо виражене. Це яскраво відображено в дослідженнях і пропозиціях Віталіка. Салюс зібрав типові сценарії, запропоновані Віталіком у своєму дослідженні, а саме транзакції конфіденційності та соціальне відновлення.

2.1 Приватні операції

Що стосується транзакцій конфіденційності, Віталік запропонував дві концепції: Stealth Addresses і Privacy Pools.

· Схеми приватної адреси дозволяють проводити транзакції, приховуючи особу одержувача транзакції. Це рішення не тільки забезпечує функції захисту конфіденційності, але й забезпечує прозорість і можливість перевірки транзакцій.

· На основі протоколу Privacy Pool користувачі можуть довести, що кошти їхніх транзакцій належать відомим і сумісним джерелам, не розкриваючи попередні транзакції. Це рішення дозволяє користувачам проводити приватні транзакції, дотримуючись правил.

Обидва рішення невіддільні від ЗК. В обох сценаріях користувачам дозволено генерувати докази з нульовим знанням, щоб підтвердити дійсність своїх транзакцій.

2.1.1 Адреса конфіденційності

Якщо припустити, що Аліса має намір передати певні активи Бобу, то, коли Боб отримає активи, він не хоче, щоб інформація стала відомою широкій громадськості. Хоча приховати факт передачі активів важко, існує можливість приховати особу одержувача. Саме в цьому контексті з’явилися схеми адрес конфіденційності, які в першу чергу стосуються того, як ефективно приховати особу одержувача транзакції.

Отже, яка різниця між приватною адресою та звичайною адресою Ethereum? Як використовувати приватні адреси на основі ZK для приватних транзакцій? Salus познайомить вас із кожним із них.

(1) Яка різниця між приватною адресою та звичайною адресою Ethereum?

Приватна адреса — це адреса, яка дозволяє відправнику транзакції генерувати її неінтерактивно та доступна лише одержувачу. Ми проілюструємо різницю між приватною адресою та звичайною адресою Ethereum з двох вимірів: хто її генерує та хто має до неї доступ.

Хто його генерує

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

Хто має до нього доступ?

Типи, суми та джерела коштів на звичайних рахунках Ethereum є загальнодоступними. У транзакціях із використанням приватних адрес лише одержувач може отримати доступ до коштів, що зберігаються на його невидимій адресі. Спостерігачі не можуть пов’язати приватну адресу одержувача з його особою, таким чином захищаючи конфіденційність одержувача.

(2) Як використовувати адреси конфіденційності на основі ZK для приватних транзакцій?

Якщо Аліса хоче надіслати активи на приватну адресу Боба, щоб приховати одержувача транзакції. Нижче наведено детальний опис процесу транзакції:

1) Створіть приватну адресу

● Боб створює та зберігає ключ витрат, який є закритим ключем, який можна використовувати для витрачання коштів, надісланих на приватну адресу Боба.

● Боб використовує ключ споживання, щоб створити мета-адресу конфіденційності (мета-адресу прихованої інформації), яку можна використовувати для обчислення адреси конфіденційності для певного одержувача, і передає мета-адресу конфіденційності Алісі. Аліса обчислює мета-адресу конфіденційності та генерує приватну адресу, що належить Бобу.

2) Надіслати активи на приватну адресу

● Аліса надсилає активи на особисту адресу Боба.

● Оскільки Боб не знає, що ця приватна адреса наразі належить йому, Алісі також потрібно опублікувати деякі додаткові зашифровані дані (тимчасовий відкритий ключ, ефемерний pubkey) у ланцюжку, щоб допомогти Бобу виявити, що ця приватна адреса належить йому.

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

2.1.2 Пул конфіденційності

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

Віталік запропонував рішення під назвою «Пул конфіденційності», яке призначене для збалансування захисту конфіденційності та відповідності вимогам блокчейну. Однак які проблеми із захистом конфіденційності та відповідністю? Як збалансувати конфіденційність і відповідність? З обох питань Салюс проводить глибокі та повчальні дискусії.

(1) Проблеми із захистом конфіденційності та відповідністю

Складність забезпечення дотримання транзакцій із одночасним захистом конфіденційності яскраво демонструє аналіз справи Tornado Cash.

Tornado Cash — це криптовалютний міксер, який змішує разом велику кількість депозитів і зняття коштів. Після того, як користувач внесе токен за адресою, він або вона має показати ZK Proof, щоб підтвердити, що він або вона вклав токен, а потім використати нову адресу, щоб зняти гроші. Ці дві операції публічні в ланцюжку, але листування між ними не є публічним, тому вони анонімні. Хоча це може покращити конфіденційність користувачів, воно часто використовується незаконними суб’єктами для відмивання грошей. У результаті OFAC, Міністерство фінансів США, остаточно внесло адресу смарт-контракту Tornado Cash у список санкцій. Регулятори вважають, що угода сприяє відмиванню грошей і не сприяє боротьбі з фінансовими злочинами.

Недоліком Tornado Cash у захисті конфіденційності є те, що він не може перевірити, чи джерело токенів користувача відповідає вимогам. Щоб вирішити цю проблему, Tornado Cash надає централізований сервер, який допомагає користувачам довести, що їхні токени відповідають вимогам. Однак сервер повинен отримати конкретну інформацію про зняття, надану користувачем, визначити, якому депозиту відповідає зняття, і створити сертифікат. Цей централізований механізм не тільки коштує припущень про довіру, але й створює інформаційну асиметрію. Зрештою, механізм використовувався небагатьма користувачами. Хоча Tornado Cash реалізує приховану приватну функцію, він не забезпечує ефективного механізму перевірки відповідності джерела токенів користувача, що дозволяє злочинцям скористатися ним.

(2) Як збалансувати конфіденційність і відповідність?

Виходячи з вищезазначених проблем, Віталік запропонував концепцію Privacy Pools, яка дозволяє користувачам доводити, що їхні джерела коштів відповідають вимогам, не розкриваючи історичну інформацію про транзакції. Це створює баланс між конфіденційністю та відповідністю.

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

Колекції асоціацій створюються постачальниками колекцій асоціацій відповідно до певних стратегій:

1) Підтвердження членства: помістіть депозити з усіх надійних торгових платформ у пов’язаний набір, і є певні докази того, що вони мають низький ризик.

2) Доказ виключення: визначте групу депозитів, позначених як ризиковані, або депозитів, які мають чіткі докази того, що вони не відповідають вимогам. Побудуйте пов’язану колекцію, що містить усі депозити, крім цих депозитів.

Під час внесення депозиту користувач генерує секрет через ZK і хешує його для розрахунку загальнодоступного ідентифікатора монети, щоб позначити його зв’язок із коштами. Під час виведення грошей користувач надає нуліфікатор, який відповідає секрету (нуліфікатор — це унікальний ідентифікатор, отриманий із секрету), щоб підтвердити, що кошти належать йому. Крім того, користувачі використовують ZK, щоб підтвердити дві філії Merkle, щоб довести, що їхні кошти належать відомим сумісним джерелам:

1) Його ідентифікатор монети належить до дерева ідентифікаторів монети, яке є набором усіх транзакцій, що відбуваються на даний момент;

2) Його ідентифікатор монети належить до дерева набору асоціацій, яке є набором деяких законних транзакцій, які користувач розглядає.

(3) Які сценарії застосування ZK у пулі конфіденційності?

1）Гарантована гнучкість у приватних транзакціях: для обробки переказів будь-якої номіналу в приватних транзакціях до кожної транзакції додаються додаткові докази нульового знання. Це підтвердження гарантує, що загальний номінал створених токенів не перевищуватиме загальний номінал спожитих токенів, забезпечуючи тим самим дійсність транзакції. По-друге, ZK підтримує безперервність і конфіденційність транзакцій, перевіряючи прихильність кожної транзакції до початкового ідентифікатора маркера депозиту, так що навіть у разі часткового зняття коштів кожне зняття буде гарантовано пов’язане з відповідним початковим депозитом.

2）Протистояти атакам підсумовування балансу: можна протистояти атакам підсумовування балансу шляхом об’єднання токенів і встановлення набору ідентифікаторів маркерів, а також об’єднання батьківських транзакцій для кількох вхідних транзакцій. Цей підхід покладається на ZK, щоб гарантувати, що всі зафіксовані ідентифікатори маркерів знаходяться в їх пов’язаному наборі, тим самим підвищуючи конфіденційність транзакцій.

2.2 Соціальне оздоровлення

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

Подібним чином у блокчейнах, таких як Ethereum, ми можемо мати кілька адрес (облікових записів). Закритий ключ схожий на пароль банківської картки і є єдиним інструментом контролю коштів на рахунку. Після втрати закритого ключа ви втрачаєте контроль над своїм обліковим записом і більше не можете отримати доступ до коштів у своєму обліковому записі. Подібно до отримання пароля в реальному світі, блокчейн-гаманці забезпечують механізм соціального відновлення, який допомагає користувачам відновити втрачені закриті ключі. Цей механізм дозволяє користувачам вибрати групу довірених осіб як опікунів під час створення гаманця. Ці опікуни можуть допомогти користувачам відновити контроль над своїми обліковими записами, схваливши скидання закритого ключа користувача, якщо він втрачений.

Відповідно до цього механізму соціального відновлення та опіки Віталік запропонував два пункти захисту конфіденційності, які потребують уваги:

1）Приховати кореляцію між кількома адресами користувача: щоб захистити конфіденційність користувачів, нам потрібно запобігти розкриттю права власності на кілька адрес під час використання однієї фрази відновлення для їх відновлення.

2）Захист конфіденційності власності користувача від вторгнення опікунів: ми повинні гарантувати, що під час процесу схвалення операцій користувача опікуни не можуть отримати інформацію про активи користувача або спостерігати за поведінкою його транзакцій, щоб запобігти порушенню конфіденційності власності користувача.

Ключовою технологією для досягнення цих двох типів захисту конфіденційності є підтвердження нульового знання.

2.2.1 Приховати кореляцію між кількома адресами користувачів

(1) Питання конфіденційності під час соціального відновлення: кореляції між адресами розкриваються

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

Однак, якщо закритий ключ користувача буде втрачено, кошти під кількома адресами, згенерованими закритим ключем, не будуть відновлені. У цьому випадку потрібне соціальне відновлення. Простий метод відновлення полягає у відновленні кількох адрес одним клацанням миші, коли користувач використовує ту саму фразу відновлення для відновлення кількох адрес, згенерованих одним закритим ключем. Але цей підхід не є ідеальним, оскільки початковий намір користувачів, які створюють кілька адрес, полягає в тому, щоб запобігти їх пов’язанню один з одним. Якщо користувач вирішує відновити всі адреси одночасно або в один і той же час, це фактично еквівалентно тому, щоб відкрити зовнішньому світу, що ці адреси належать одному користувачеві. Ця практика перешкоджає початковій меті створення користувачами кількох адрес для захисту конфіденційності. Це є питанням захисту конфіденційності в процесі соціального відновлення.

（2) Рішення ZK: як запобігти розкриттю кореляції кількох адрес?

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

1) Логіка перевірки: користувачі мають кілька адрес у блокчейні, але логіка перевірки для всіх цих адрес пов’язана з одним основним контрактом автентифікації (контрактом сховища ключів).

2) Утримання та торгівля активами: коли користувачі працюють з будь-якої адреси, вони використовують технологію ZK для перевірки повноважень операцій, не розкриваючи, яка це адреса.

Таким чином, навіть якщо всі адреси підключено до одного контракту сховища ключів, зовнішні спостерігачі не можуть визначити, чи належать ці адреси одному користувачеві, таким чином досягаючи захисту конфіденційності між адресами.

Дуже важливо розробити приватне рішення соціального відновлення, яке може відновлювати кілька адрес користувачів одночасно, не виявляючи кореляції між адресами.

2.2.2 Захист конфіденційності власності користувача від вторгнення опікунів

(1) Питання конфіденційності: привілеї опікуна

У блокчейнах, таких як Ethereum, користувачі можуть налаштувати кілька опікунів під час створення гаманця. Особливо для гаманців з кількома підписами та гаманців соціального відновлення роль опікуна є вирішальною. Як правило, опікун — це набір із N адрес, які належать іншим, де будь-які M адреси можуть схвалити операцію.

Які привілеї мають опікуни? наприклад:

1) Для гаманця з кількома підписами кожна транзакція має бути підписана M із N опікунів, перш ніж її можна буде продовжити.

2) Для гаманця соціального відновлення, якщо приватний ключ користувача втрачено, тоді M з N опікунів повинні підписати повідомлення для скидання приватного ключа.

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

(2) Рішення ZK: захист конфіденційності власності користувача від вторгнення опікуна

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

Основна роль ZK — забезпечити систему доказів, яка дозволяє опікунам довести, що певне твердження правдиве, не розкриваючи конкретних деталей твердження. У цьому випадку опікуни можуть використовувати ZK-SNARK, щоб підтвердити, що вони мають дозвіл на виконання дії, не розкриваючи жодних деталей про зв’язок між обліковим записом і скринькою.

2.3 Дослідження: новий розділ ZK і конфіденційності в екосистемі Ethereum

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

(1) Фінансування від Ethereum Foundation

У вересні цього року фонд Ethereum профінансував два проекти із захисту конфіденційності: IoTeX і ZK-Team. IoTex — це гаманець абстракції облікового запису, заснований на доказах нульового знання, і ZK-Team прагне дозволити організаціям керувати членами команди, зберігаючи особисту конфіденційність.

(2) Інвестиції

У жовтні цього року співзасновник Ethereum Віталік інвестував у Nocturne Labs, щоб запровадити приватні облікові записи в Ethereum. Користувачі матимуть «внутрішній» обліковий запис у Nocturne，Кошти надходять/виплачуються з цих рахунків анонімно. За допомогою технології ZK користувачі можуть довести, що у них достатньо коштів для платежів, застав та інших операцій.

(3) Зустрічі та заходи

ETHDenver вважається однією з найважливіших подій у світі, пов’язаних з технологією Ethereum і блокчейн. У березні цього року ETHDenver організував спеціальний захід, присвячений конфіденційності. Ця подія не тільки демонструє стурбованість спільноти Ethereum питаннями конфіденційності, але також відображає наголос глобальної спільноти блокчейнів на захист конфіденційності. Під час цього спеціального заходу було проведено дев’ять тематичних конференцій, пов’язаних із конфіденційністю, зокрема «Конфіденційність за проектом» і «Конфіденційність проти безпеки».

EDCON (Конференція спільноти Ethereum) — це глобальна щорічна конференція, яку проводить спільнота Ethereum, яка має на меті сприяти розвитку та інноваціям Ethereum і зміцнювати зв’язки та співпрацю спільноти Ethereum. На цьогорічній конференції EDCON у травні Віталік зробив важливу заяву, сказавши: «У наступні 10 років ZK-SNARK будуть такими ж важливими, як блокчейн». Ця заява підкреслює важливу позицію ZK-SNARK в тенденції розвитку технології блокчейн.

(4) Проект

На даний момент деякі проекти прикладного рівня почали використовувати технологію ZK для надання послуг захисту конфіденційності для користувачів і транзакцій. Ці проекти прикладного рівня називаються ZK Applications. Наприклад, програма ZK, розгорнута на Ethereum, unyfy, приватна біржа активів. Ціни торгових ордерів тут приховані, а цілісність цих ордерів з прихованими цінами перевіряється технологією ZK. Окрім unyfy, на L2 є інші програми ZK, такі як ZigZag і Loopring. Хоча ці додатки ZK реалізують функції захисту конфіденційності на основі ZK, наразі вони не можуть бути розгорнуті в Ethereum, оскільки EVM не може безпосередньо запускати ці додатки ZK.

(5) Дослідження

Крім того, дослідники провели гарячі дискусії щодо технології ZK та її застосування на платформі Ethereum Research. Серед них є дослідницька стаття від Salus, присвячена використанню ZK для захисту конфіденційності та інших реалізацій на прикладному рівні Ethereum. У цій статті перевірено продуктивність кількох різних мов ZK, Circom, Noir і Halo2, і результати показали, що Circom має кращу продуктивність. У цій статті також пропонується загальне рішення для інтеграції Circom у Solidity для реалізації проектів рівня додатків Ethereum на основі ZK. Це має важливі наслідки для переходу конфіденційності Ethereum. Це дослідження набуло значної популярності у 2023 році, посівши перше місце в списку.

Ця дослідницька стаття є найбільш читаним дослідженням Ethereum Research 2023 року — від Salus

3. Виклик

Незважаючи на те, що багато існуючих проектів прикладного рівня Ethereum потребують термінового впровадження механізмів захисту конфіденційності на основі ZK, цей процес стикається з рядом проблем.

1. ZK бракує людських ресурсів: вивчення технології ZK вимагає міцної теоретичної основи, особливо в галузі криптографії та математики. Оскільки впровадження технології ZK включає складні формули, учні також повинні мати сильні здібності до інтерпретації формул. Але проблема в тому, що відносно мало людей займаються вивченням технології ZK.

2. Обмеження мови розробки ZK: такі мови, як Rust, Cairo, Halo2 тощо, використовуються для розробки схем перевірки ZK, але вони зазвичай застосовуються лише до конкретних сценаріїв і не підходять для проектів прикладного рівня. Деякі з цих мов, як-от Cairo, все ще перебувають на експериментальній стадії та можуть мати проблеми сумісності між різними версіями, що ускладнює та ускладнює їх впровадження в реальні програми.

3. Труднощі впровадження технології ZK: рішення, запропоноване Віталіком для застосування технології ZK для захисту конфіденційності Ethereum, може зіткнутися з низкою складних проблем під час фактичного впровадження, наприклад, як уникнути атак із сумуванням балансу та подвійним витрачанням приватних транзакцій. напади. чекати. Існують певні технічні труднощі у вирішенні цих завдань.

Захист конфіденційності проти відповідності: хоча приватні транзакції можуть захистити особистість користувачів і деталі транзакцій, вони також можуть приховувати незаконні дії, такі як відмивання грошей. У майбутньому залишилося перевірити, чи можуть додатки ZK на Ethereum відповідати нормам під час впровадження захисту конфіденційності.

Незважаючи на труднощі, обов’язковою умовою для трансформації конфіденційності Ethereum — забезпечення переказів коштів із збереженням конфіденційності та гарантування того, що всі інші інструменти, що розробляються (соціальне відновлення, ідентичність, репутація), зберігають конфіденційність — є широке розгортання додатків ZK. Як згадувалося вище, дослідження, опубліковане Salus, базується на технології ZK для сприяння захисту конфіденційності та інших функцій прикладного рівня Ethereum. Крім того, Salus вперше запропонував універсальне рішення, яке інтегрує Circom і Solidity і застосовується до проектів прикладного рівня Ethereum. Він реалізує систему ZK proof поза мережею на основі Circom і реалізує смарт-контракти та логіку перевірки ZK на Ethereum на основі Solidity. Якщо вам потрібна підтримка або у вас виникли запитання, не соромтеся звертатися до Salus.

4. Підсумок і перспектива

У 2023 році спільнота Ethereum на чолі з Віталіком Бутеріним глибоко вивчила потенціал технології захисту з нульовими знаннями з метою покращення функції захисту конфіденційності платформи. Хоча ці пропозиції все ще знаходяться на стадії дослідження, дослідження та документи Віталіка, особливо щодо балансу між захистом конфіденційності та відповідністю, закладають теоретичну основу для технології без знань для захисту конфіденційності користувачів.

Хоча існують проблеми з інтеграцією технології підтвердження нульового знання в Ethereum, оскільки технологія розвивається та спільнота продовжує свої зусилля, очікується, що докази нульового знання відіграватимуть більш важливу роль в екосистемі Ethereum у найближчому майбутньому. Таким чином, своєчасна участь і активне дослідження цього поля, використання перших можливостей допоможе зайняти вигідну позицію в цій галузі, що розвивається.

Відмова від відповідальності:

1. Цю статтю передруковано з [theblockbeats]. Усі авторські права належать оригінальному автору [LZ]. Якщо є заперечення щодо цього передруку, будь ласка, зв’яжіться з командою Gate Learn , і вони негайно розглянуть це.
2. Відмова від відповідальності: погляди та думки, висловлені в цій статті, належать виключно автору та не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконує команда Gate Learn. Якщо не зазначено вище, копіювання, розповсюдження або плагіат перекладених статей заборонено.