Переслати Оригінальний Заголовок‘’

Багато людей, які стверджують, що web3 - це новий інтернет, визначають його фразою «читати, писати, володіти». Частини «читати» та «писати» зрозумілі, але коли мова йде про «володіння» у сенсі даних, сьогодні ми майже нічого не володіємо.

Корпорації часто крадуть дані користувачів і використовують їх у своїх інтересах; насправді ми не володіємо нічим в інтернеті.

Однак ми не можемо просто перейти до світу, де існує лише web3, не ділячись нічим. Ні, нам все ще потрібно ділитися, але лише тим, що необхідно.

Як людина з менш сильним паспортом, я застрягаю, подаючи заявки на електронні візи та надсилаючи безліч деталей про себе, щоб довести, що я маю право на певні візи. І я завжди задаю собі питання:

• Чому мені потрібно поділитися всім випискою з банку, коли їм потрібно лише підтвердити конкретний рівень доходу?

• Чому мені слід предоставити точне бронювання готелю замість того, щоб просто довести, що я забронював готель у цій країні?

• Чому мені потрібно надавати всі мої повні паспортні дані, коли все, що їм потрібно, це підтвердити моє постійне місце проживання у моїй поточній країні?

Тут є дві основні проблеми: сервіси знають набагато більше, ніж їм потрібно, і надані вами дані не є конфіденційними. Але як це пов’язано з безпекою та конфіденційністю в криптосистемах?

1. Web3 не виживе без даних web2.

Як більшість з вас знає, смарт-контракти фактично не знають, скільки коштує BTC, ETH, SOL або будь-який інший актив. Це завдання делегується оракулам, які постійно публікують громадські дані зі світу зовнішнього до смарт-контракту.

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

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

Перша думка: як ми можемо привести ці дані на блокчейн з підтвердженням того, що приватні дані захищені?

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

Протокол, який забезпечує безпеку комунікації в мережі комп’ютерів, називається TLS: Захист транспортного рівня. Навіть якщо ви не чули про це, ви використовуєте його щоденно. Наприклад, під час читання цієї статті ви побачите «https://» у рядку адреси вашого браузера.

Якщо ви спробували отримати доступ до веб-сайту за допомогою з’єднання “http://“ (без “s”), ваш браузер попереджує вас, що з’єднання не є безпечним. “s” в посиланні означає TLS, який забезпечує безпеку вашого з’єднання, гарантуючи конфіденційність та запобігаючи крадіжку переданих даних.

2. Підключення вже захищене, чому б нам просто не транспортувати його та не використовувати в web3?

Як я вже зазначив раніше, ми стикаємося з проблемою перевірки: сервери не підписують відповіді, які вони відправляють, тому ми дійсно не можемо перевірити дані.

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

Один підхід до проблеми перевірки - це покращена версія TLS під назвою zkTLS.

Робочий механізм zkTLS схожий на TLS, але трохи відмінний, ось як він працює:

• Ви відвідуєте веб-сайт через безпечне з’єднання TLS та відправляєте необхідний запит.

• zkTLS генерує доказ zk, який перевіряє дані, водночас розкриваючи лише конкретні деталі, які користувач хоче довести, зберігаючи всі інші речі в приватності.

• Згенероване доказ перевірки zk потім використовується іншими додатками для підтвердження та перевірки правильності наданої інформації.

Коли я говорю про zkTLS, я маю на увазі проекти, які використовують zkTLS, але існують різні підходи до перевірки даних за допомогою різних рішень:

1. TEE (Trusted Execution Environment)
2. MPC (Multi-Party Computation)
3. Проксі

Цікаво, кожен підхід вводить свій власний набір унікальних використань. Так чим вони відрізняються?

3. Чому немає єдиного стандарту для zkTLS? Як вони відрізняються?

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

Як я вже згадував раніше, три основні підходи полягають у використанні TEE-TLS, MPC-TLS або Proxy-TLS.

TEE ҉ полагається на спеціалізований апаратний засіб, такий як Intel SGX або AWS Nitro Enclaves, щоб створити безпечний «чорний ящик», де дані можуть бути оброблені та згенеровані докази. Апаратне забезпечення забезпечує конфіденційність даних та невід’ємність обчислень.

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

Однак у ньому є серйозний недолік: ви повинні довіряти виробнику апаратного забезпечення, а вразливості в TEE (як от атаки з бокових каналів) можуть зруйнувати весь систему.

Проксі-TLS та MPC-TLS - найбільш поширені підходи, оскільки вони мають більший спектр використання. Проекти, такі як@OpacityNetwork та @reclaimprotocol, які побудовані на@eigenlayer, використовуйте ці моделі для забезпечення безпеки та конфіденційності даних разом із додатковим рівнем економічної безпеки.

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

4. Що особливого в MPC-TLS та мережі Opacity?

Під час TLS-рукостискання (де клієнт і сервер домовляються, як безпечно спілкуватися, обмінюючи ключі шифрування), роль веб-сайту залишається незмінною, а процес браузера робить щось інше.

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

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

Opacity Network покращує класику @tlsnotaryфреймворк, додавши заходи безпеки для мінімізації проблем довіри. Він використовує кілька заходів безпеки, таких як:

1. Верифікація веб2 облікових записів на ланцюжку
2. Схема зобов’язань
3. Розкрити схему
4. Випадкове вибіркове мережеве відбіркове дослідження
5. Перевірний журнал спроб

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

Ви можете побачити, як працює непрозорість докладно внизу:

Вузли непрозорості працюють у межах TEE, зроблюючи змову майже неможливою, якщо TEE є безпечним. Поза TEE непрозорість також використовує Eigenlayer для використання AVS, вимагаючи вузлам переставляти 32 stETH, з миттєвим укладенням за порушення, уникненням затримок, пов’язаних із відпочинками.

Ви можете побачити, що Opacity використовує як MPC, так і TEE, але оскільки MPC використовується для zkTLS, тоді як TEE використовується в основному для безпеки вузлів, його все одно називають MPC-TLS.

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

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

Благодаря своей простоте интеграции, безопасности и конфиденциальности, Opacity привернула различные протоколы для интеграции ее в свои продукты в сегментах потребителей, DeFi и искусственного интеллекта.

Команда з @earnos_ioрозробляє платформу, де бренди можуть винагороджувати користувачів за залучення або виконання завдань. EarnOS використовує технологію Opacity для підтвердження характеристик через популярні додатки, не розголошуючи особисту інформацію, дозволяючи брендам націлювати аудиторію, а користувачам зберігати конфіденційність та отримувати винагороди.

Opacity також інтегрована в @daylightenergy_протокол, що розробляє децентралізовану мережу електроенергетики, де користувачі можуть отримувати винагороду за сприяння чистим енергетичним рішенням. Завдяки Opacity користувачі можуть довести власність на енергетичному пристрої on-chain без спеціалізованого обладнання.

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

Однак TEE-TLS та MPC-TLS - лише дві варіації zkTLS, є ще третя, яка називається Proxy-TLS, з Reclaim Network, яка є найвідомішим представленням цієї моделі. Таким чином, як вона відрізняється за технологічними характеристиками від інших двох варіацій, та які використання можуть бути активовані за допомогою Proxy-TLS?

5. Що особливого в Proxy-TLS та протоколі Reclaim?

Проксі HTTPS, поширені в Інтернеті, передають зашифрований трафік, не звертаючись до його вмісту. У моделі проксі zkTLS вона працює майже так само з незначними додатками:

• Браузер надсилає запити на веб-сайт через проксі, яке також обробляє відповіді веб-сайту.

• Проксі бачить всі зашифровані обміни та підтверджує їх автентичність, вказуючи, чи кожен з них є запитом чи відповіддю.

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

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

Розкриття ключа вразило б все попередні повідомлення, включаючи чутливі дані, такі як імена користувачів та паролі. Проксі-TLS досить швидкий, доступний і добре обробляє великі обсяги даних, що робить його ідеальним для високопропускних налаштувань.

Більшість серверів не обмежують доступ на основі різних IP-адрес, що робить цей метод досить широко застосовним.

Протокол Reclaim використовує Proxy-TLS для ефективної перевірки даних та використовує проксі, щоб обійти брандмауери Web2, що запобігають масштабному блокуванню проксі.

Ось як це працює:

Основна проблема тут - це змова: якщо користувач і атестатор узгодяться, вони зможуть підписати практично будь-що й діяти злочинно. Щоб пом’якшити це, Reclaim включає підмножину валідаторів, обраних для введення випадковості та блокування таких зловживань.

Reclaim використовує AVS Eigen для децентралізації підтвердження даних. Оператори EigenLayer можуть виступати як підтверджувачі, але їм потрібно буде розгорнути власний AVS для визначення логіки підтвердження для своєї служби.

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

Екосистема Reclaim налічує понад 20 проєктів, але я б хотів виокремити 4 з них у грошових ринках, цифровому ідентифікаторі, споживчому секторі та секторі найму.

@3janexyzЦе перший кредитний грошовий ринок на Base, який пропонує забезпечені кредитні лінії для користувачів криптовалют, оцінюючи їх кредитоспроможність та майбутні грошові потоки за допомогою як on-chain, так і off-chain фінансових даних.

3Jane використовує модель повірених осіб Reclaim для перевірки кредитних даних від VantageScore, Cred, Coinbase та Plaid, забезпечуючи конфіденційність цих даних.

Ще одне використання кредитних балів з zkTLS - через @zkme_‘s функція, zkCreditScore. Вона використовує Протокол Reclaim для безпечного отримання вашого кредитного рейтингу в США за допомогою zkTLS. Це дозволяє zkMe перевіряти кредитний рейтинг користувача та створювати унікальні токени, пов’язані з душею (SBTs), для зберігання цих даних.

Чи можуть існувати інші використання крім кредитних балів? Звичайно, є.

Ми можемо взяти @zkp2pна приклад, який є ринком товарів споживання, який використовує Reclaim для перевірки даних користувачів Ticketmaster, а також перевірки платежів користувачів.

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

При дивлячись на можливі використання через zkTLS, можливість перевірки транскрипцій TLS on-chain вже відкриває безліч нових можливостей, дозволяючи користувачам контролювати власні дані без необхідності дозволу від великих корпорацій.

Ще важливіше, що zkTLS призначено забезпечити, щоб ваші особисті дані не використовувалися проти вас. Так куди це призведе?

6. Чи zkTLS залишиться тут надовго?

Ще є робота, яку потрібно виконати, але різні протоколи zkTLS вже вводять нові використання, які перерозподіляють потужність користувачам.

@Tim_RoughgardenНа подкасті a16z crypto було відзначено, що zk-докази, запропоновані в 1985 році, набули популярності лише у застосуваннях блокчейну завдяки роботі сотень розробників над зменшенням розміру доказу та витрат.

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

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

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

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