Пересылка оригинального заголовка ‘Как мы можем сделать использование данных web2 в web3 на самом деле частным и верифицируемым?’

Многие люди, утверждающие, что web3 - это новый интернет, определяют его фразой “читать, писать, владеть”. Части “читать” и “писать” понятны, но когда речь идет о “владении” данными, сегодня у нас почти ничего нет.

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

Тем не менее, мы не можем просто перейти в мир, где существует только web3, не делясь ничем. Нет, нам все равно нужно делиться, но только тем, что необходимо.

Как человек с более слабым паспортом, я застрял в подаче заявления на электронные визы и предоставлении бесконечных данных о себе, чтобы доказать, что я имею право на получение определенных виз. И я всегда спрашиваю себя:

• Почему мне нужно предоставлять весь банковский отчет, когда им нужно только подтвердить определенный уровень дохода?

• Почему я должен предоставлять точную бронь отеля, а не просто доказывать, что я забронировал отель в этой стране?

• Почему мне нужно предоставлять полные данные моего паспорта, когда им достаточно проверить мое постоянное место жительства в моей текущей стране?

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

1. Web3 не обойдется без данных web2.

Как большинство из вас знает, умные контракты по сути не имеют представления о том, сколько стоит BTC, ETH, SOL или любой другой актив. Эта задача делегируется оракулам, которые постоянно публикуют общедоступные данные из внешнего мира в умном контракте.

В мире Ethereum эту роль почти монополизировала @chainlinkс их сетями оракулов, чтобы гарантировать, что мы не полагаемся на один узел. Итак, нам действительно нужны веб-данные для большего количества случаев использования, чем просто знание цены определенных активов.

Однако это относится только к публичным данным. Что делать, если я хочу безопасно подключить свой банковский счет или учетную запись Telegram и поделиться конфиденциальной информацией, которая не является общедоступной, но является конфиденциальной для меня?

Первая мысль: как мы можем перенести эти данные в блокчейн с доказательством того, что личные данные находятся в безопасности?

К сожалению, это не работает так, потому что серверы не подписывают отправляемые ими ответы, поэтому вы не можете надежно проверить что-то подобное в смарт-контрактах.

Протокол, который защищает обмен данными по компьютерной сети, называется TLS: Transport Layer Security. Даже если вы не слышали о нем, вы используете его ежедневно. Например, читая эту статью, вы увидите «https://» в адресной строке браузера.

Если вы попытались получить доступ к веб-сайту с помощью подключения «http://» (без «s»), ваш браузер предупредит вас, что соединение не безопасно. «S» в ссылке означает TLS, который обеспечивает безопасное соединение, гарантируя конфиденциальность и предотвращая кражу передаваемых вами данных.

2. Соединение уже защищено, не можем ли мы просто транспортировать и использовать его в web3?

Как я уже упоминал ранее, у нас возникает проблема проверяемости: серверы не подписывают отправляемые ими ответы, поэтому мы не можем действительно проверить данные.

Даже если источник данных соглашается поделиться своими данными, стандартный протокол TLS не может доказать его подлинность другим. Простой передачи ответа недостаточно: клиенты могут легко изменять данные локально, совместное использование этих ответов полностью раскрывает их, рискуя конфиденциальностью пользователей.

Один из подходов к проблеме верификации - это улучшенная версия TLS, называемая zkTLS.

Рабочий механизм zkTLS аналогичен TLS, но немного отличается, вот как это работает:

• Вы посещаете веб-сайт через безопасное соединение TLS и отправляете необходимый запрос.

• zkTLS генерирует zk-доказательство, которое проверяет данные, раскрывая только конкретные детали, которые пользователь хочет доказать, сохраняя все остальное в тайне.

• Сгенерированное доказательство zk затем используется другими приложениями для подтверждения и проверки предоставленной информации.

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

1. TEE (Доверенная Выполнения Среда)
2. MPC (Многозначение Вычисление Сторон)
3. Прокси

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

3. Почему нет единого стандарта для zkTLS? В чем их различия?

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

Как я уже упоминал ранее, существует три основных подхода: использование TEE-TLS, MPC-TLS или Proxy-TLS.

TEE relies on specialized hardware, like Intel SGX or AWS Nitro Enclaves, to create a secure “black box” where data can be processed and proofs generated. The hardware ensures the data stays private and computations are tamper-proof.

В настройке zkTLS на основе TEE TEE запускает протокол, доказывая выполнение и содержимое сеанса TLS. Проверяющим является сам TEE, поэтому доверие зависит от производителя TEE и его устойчивости к атакам. Этот подход эффективен с низкой вычислительной и сетевой нагрузкой.

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

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

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

4. Чем так особенны MPC-TLS и сеть непрозрачности?

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

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

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

Сеть Opacity улучшает классическую @tlsnotaryфреймворк, добавляя средства защиты для минимизации проблем доверия. Он использует несколько мер безопасности, таких как:

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

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

Вы можете увидеть, как работает Опасити, подробно описано ниже:

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

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

Однако, если TEE не смогут, это может позволить узлу замешаться в коллузии в рамках MPC. Вот почему нужен дополнительный экономический слой безопасности, чтобы предотвратить такое поведение.

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

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

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

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

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

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

5. Чем особенны прокси-TLS и Протокол Возврата?

Прокси-серверы HTTPS, распространенные в Интернете, пересылают зашифрованный трафик без доступа к его содержимому. В модели zkTLS прокси он работает почти так же, но с небольшими дополнениями:

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

• Прокси видит все зашифрованные обмены и удостоверяет их подлинность, отмечая, является ли каждый запросом или ответом.

• Затем браузер генерирует доказательство zk, которое утверждает, что он может зашифровать эти данные общим ключом, не раскрывая ключ, и показывает результат.

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

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

Большинство серверов не ограничивают доступ на основе различных IP-адресов, что делает этот метод довольно широко применимым.

Reclaim Protocol использует Proxy-TLS для эффективной проверки данных и использует прокси для обхода межсетевых экранов Web2, предотвращая масштабную блокировку прокси.

Вот как это работает:

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

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

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

Экосистема Reclaim насчитывает более 20 проектов, но я бы хотел выделить 4 из них на рынках денег, цифровой идентификации, потребления и найма персонала.

@3janexyz — это первый кредитный денежный рынок на Base, предлагающий обеспеченные кредитные линии пользователям криптовалют путем оценки их кредитоспособности и будущих денежных потоков с использованием финансовых данных как в сети, так и вне сети.

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

Еще одно использование баллов кредитной истории с zkTLS - через@zkme_‘s функция, zkCreditScore. Он использует Протокол Восстановления для безопасного получения вашего кредитного рейтинга в США с zkTLS. Это позволяет zkMe проверить кредитный рейтинг пользователя и создать уникальные токены, привязанные к душе (SBT), чтобы хранить эти данные.

Могут ли существовать другие случаи использования, кроме кредитных рейтингов? Конечно, есть.

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

В то же время, @bondexapp, которая является одной из самых популярных досок объявлений в криптосфере, использует Reclaim для получения подтверждения работы профилей, проверяя, что данные являются реальными, конфиденциальными и подтверждаемыми.

Рассматривая возможные сценарии использования через zkTLS, возможность проверять транскрипты TLS on-chain уже разблокирует множество новых функций, позволяя пользователям контролировать свои собственные данные без необходимости разрешения от крупных корпораций.

Что еще более важно, zkTLS создан для того, чтобы гарантировать, что ваши персональные данные не будут использованы против вас. Итак, к чему это ведет?

6. Будет ли zkTLS оставаться здесь?

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

@Tim_Roughgardenв эфире a16z crypto podcast подчеркнули, что zk proofs, предложенные в 1985 году, стали популярными только благодаря сотням разработчиков, работающих над уменьшением размера и затрат на доказательства, в контексте применения их в блокчейн-приложениях.

И теперь вклад блокчейн-индустрии находит применение и в других областях, помимо самой криптовалюты.

Я ожидаю, что с zkTLS повторится похожая история, начиная с реализации в Web3, а затем выходя за её пределы, потому что, как я уже говорил, в настоящее время мы “читаем” и “пишем”, но мы едва ли защищены и едва ли владеем даже своими данными.

Отказ:

1. Эта статья перепечатана с [Павел Парамонов]. Все авторские права принадлежат оригинальному автору [Павел Парамонов]. Если у вас есть возражения по поводу этого перепечатывания, пожалуйста, свяжитесь с Gate Learn команды, и они оперативно с этим справятся.
2. Отказ от ответственности: Взгляды и мнения, высказанные в этой статье, являются исключительно мнением автора и не являются инвестиционными советами.
3. Команда gate Learn занимается переводом статей на другие языки. Копирование, распространение или плагиат переведенных статей запрещены без упоминания.