Автор: @Web3_Mario
Резюме: В последнее время я искал новые направления для проектов и столкнулся с технологическим стеком, с которым ранее не работал, поэтому я провел исследование и собрал свои мысли, чтобы поделиться ими с вами. В общем, zkTLS - это новая технология, сочетающая нулевое знание (ZKP) и TLS (протокол транспортного уровня безопасности), которая в основном используется в среде виртуальных машин на блокчейне в Web3, позволяя проверять достоверность предоставленных оффлайн данных HTTPS без доверия к третьим лицам. Эта достоверность включает три аспекта: источник данных действительно является определенным HTTPS ресурсом, возвращенные данные не были изменены и актуальность данных может быть гарантирована. Благодаря этой криптографической механике реализации, смарт-контракты на блокчейне получают возможность надежно получать доступ к оффлайн ресурсам Web2 HTTPS, разрушая изоляцию данных.
Что такое протокол TLS
Чтобы глубже понять ценность технологии zkTLS, необходимо сделать простой обзор протокола TLS. Протокол TLS (протокол транспортного уровня безопасности) используется для обеспечения шифрования, аутентификации и целостности данных в сетевом взаимодействии, гарантируя безопасную передачу данных между клиентом (например, браузером) и сервером (например, веб-сайтом). Для тех, кто не занимается разработкой сетевых приложений, может показаться, что некоторые доменные имена имеют префикс https, а другие - http. При доступе к последним основные браузеры показывают предупреждение о небезопасности. В то время как первые могут столкнуться с сообщениями «Ваша связь не является частной» или ошибками сертификата HTTPS. Причина таких предупреждений заключается в доступности протокола TLS.
Конкретно, протокол HTTPS - это протокол, который на основе протокола HTTP использует протокол TLS для обеспечения конфиденциальности и целостности передачи информации, а также делает достоверность сервера проверяемой. Мы знаем, что протокол HTTP является протоколом передачи в открытом виде, и этот протокол не может проверить достоверность сервера, что создает несколько проблем безопасности:
1. Информация, которую вы передаете серверу, может быть перехвачена третьими лицами, что может привести к утечке конфиденциальности;
2. Вы не можете проверить достоверность сервера, то есть были ли ваши запросы перехвачены другими вредоносными узлами и возвращены вредоносные данные;
3. Вы не можете проверить целостность возвращаемой информации, т.е. существует ли возможность потери данных из-за сетевых причин;
Протокол TLS был разработан для решения этих проблем. Здесь стоит пояснить, что некоторые могут знать протокол SSL, на самом деле протокол TLS был разработан на основе версии SSL 3.1, однако по некоторым коммерческим причинам он получил другое название, хотя на самом деле они имеют одни и те же корни. Поэтому в некоторых контекстах эти два термина могут использоваться взаимозаменяемо.
Основная идея протокола TLS заключается в том, чтобы решить вышеупомянутые проблемы:
1. Защищенная связь: использование симметричного шифрования (AES, ChaCha20) для защиты данных от прослушивания.
2. Аутентификация: проверка личности сервера с помощью цифровых сертификатов (например, сертификатов X.509), выданных третьей стороной, чтобы предотвратить атаки типа «человек посередине» (MITM).
3. Целостность данных: использование HMAC (код аутентификации сообщения) или AEAD (аутентифицированное шифрование) для обеспечения того, чтобы данные не были изменены.
Давайте кратко объясним технические детали протокола HTTPS, основанного на протоколе TLS, в процессе обмена данными, весь процесс делится на два этапа: сначала это этап рукопожатия (Handshake), когда клиент и сервер согласовывают параметры безопасности и устанавливают защищенную сессию. Затем этап передачи данных, когда используется сеансовый ключ для защищенной связи. Конкретный процесс делится на четыре шага:
1. Клиент отправляет ClientHello:
Клиент (например, браузер) отправляет серверу сообщение ClientHello, которое включает в себя:
Поддерживаемые версии TLS (например, TLS 1.3)
Поддерживаемые криптографические алгоритмы (шифровые наборы, такие как AES-GCM, ChaCha20)
Случайное число (Client Random) (для генерации ключей)
Параметры обмена ключами (например, ECDHE публичный ключ)
SNI (индикатор имени сервера) (по желанию, для поддержки нескольких доменных имен HTTPS)
Цель заключается в том, чтобы сервер знал о криптографических возможностях клиента и подготовил параметры безопасности.
2. Сервер отправляет ServerHello:
Ответ сервера на сообщение ServerHello включает в себя:
Выбранный криптографический алгоритм
Серверное случайное число (Server Random)
Сертификат сервера (X.509 сертификат)
Параметры обмена ключами сервера (например, ECDHE публичный ключ)
Завершено 消息（用来确认握手完成）
Цель заключается в том, чтобы клиент знал личность сервера и подтвердил параметры безопасности.
3. Клиент проверяет сервер:
Клиент выполняет следующие действия:
Верификация сертификата сервера: убедитесь, что сертификат выдан доверенным CA (центром сертификации), а также проверьте, не истек ли срок действия сертификата или не был ли он отозван;
Вычисление общего ключа: используя свои и серверные ECDHE публичные ключи, рассчитывается сеансовый ключ (Session Key), который будет использоваться для симметричного шифрования последующей связи (например, AES-GCM).
Отправка сообщения Finished: подтверждение целостности данных рукопожатия, предотвращение атак типа «человек посередине» (MITM).
Цель состоит в том, чтобы гарантировать доверие к серверу и сгенерировать сеансовый ключ.
4. Начало защищенной связи:
Клиент и сервер теперь используют согласованный сеансовый ключ для защищенной связи.
Использование симметричного шифрования (например, AES-GCM, ChaCha20) для шифрования данных, повышая скорость и безопасность.
Защита целостности данных: использование AEAD (например, AES-GCM) для предотвращения подделки.
Таким образом, после выполнения этих четырех шагов можно эффективно решить проблемы протокола HTTP. Однако эта основная технология, широко используемая в сети Web2, создает затруднения для разработки приложений в Web3, особенно когда смарт-контракты на блокчейне хотят получить доступ к некоторым оффлайн данным, так как из-за проблем с доступностью данных виртуальные машины на блокчейне не открывают возможности вызова внешних данных, чтобы обеспечить всю доступность данных и тем самым гарантировать безопасность механизма консенсуса.
Однако после ряда итераций разработчики обнаружили, что DApp все же нуждаются в данных вне блокчейна, и в результате появились проекты Oracle, такие как Chainlink и Pyth. Они выступают в качестве моста между данными на блокчейне и вне его, разрушая изоляцию данных. Чтобы гарантировать доступность промежуточных данных, эти Oracle обычно реализуют механизмы консенсуса PoS, чтобы сделать затраты на злоупотребление узлов выше, чем выгоды, что экономически делает их невыгодными для предоставления неверной информации на блокчейне. Например, если мы хотим получить взвешенную цену BTC на централизованных биржах, таких как Binance и Coinbase, нам необходимо полагаться на эти Oracle для доступа и агрегирования данных вне блокчейна, прежде чем передавать их в смарт-контракт на блокчейне для хранения.
Что решает zkTLS
Тем не менее, люди обнаружили, что данное решение по получению данных на основе Oracle имеет два недостатка:
1. Высокие затраты: Мы знаем, что для обеспечения достоверности данных, передаваемых Oracle на блокчейн, они должны быть подтверждены механизмом консенсуса PoS, однако безопасность механизма консенсуса PoS основана на объеме залоговых средств, что приводит к затратам на обслуживание. Обычно в механизме консенсуса PoS существует множество избыточных взаимодействий с данными, так как для достижения консенсуса данные должны многократно передаваться, вычисляться и агрегироваться в сети, что также увеличивает затраты на использование данных. Поэтому обычно проекты Oracle для привлечения клиентов будут бесплатно поддерживать лишь самые основные данные, такие как цены на BTC и другие основные активы. Для специализированных потребностей требуется оплата. Это препятствует инновациям в приложениях, особенно для некоторых длинных хвостов и индивидуализированных потребностей.
2. Низкая эффективность: в обычных случаях консенсус PoS требует времени, что приводит к задержкам с данными на блокчейне, что неблагоприятно для некоторых сценариев частого доступа, поскольку данные на блокчейне имеют значительную задержку по сравнению с реальными оффлайн данными.
Для решения вышеупомянутых проблем была разработана технология zkTLS, основная идея которой заключается в том, что с помощью алгоритма ZKP нулевого знания смарт-контракты на блокчейне могут напрямую проверять данные, предоставляемые определенным узлом, которые действительно поступили от определенного HTTPS ресурса и не были изменены, таким образом избегая высоких затрат на использование традиционных Oracle из-за алгоритмов консенсуса.
Некоторые могут спросить, почему нельзя напрямую встроить возможность вызова API Web2 в среду VM на блокчейне. Ответ в том, что это невозможно, потому что необходимость поддерживать закрытость данных в среде блокчейна заключается в обеспечении всех данных возможностью отслеживания, то есть в процессе консенсуса все узлы имеют единую оценочную логику по определенным данным или результатам выполнения, или, иначе говоря, объективную логику верификации. Это обеспечивает то, что в полностью недоверительном окружении большинство добросовестных узлов могут полагаться на свои избыточные данные, чтобы оценить истинность результата. Однако с данными Web2 вы не можете построить такую единую оценочную логику, потому что, возможно, из-за задержек в сети разные узлы получат разные результаты при доступе к ресурсам HTTPS Web2, что создает сложности для консенсуса, особенно в области данных с высокой частотой. Кроме того, еще одной ключевой проблемой является то, что безопасность протокола HTTPS зависит от случайного числа, генерируемого клиентом (Client Random) (для генерации ключей) и параметров обмена ключами, что обеспечивает согласование шифровальных ключей между клиентом и сервером. Но мы знаем, что среда блокчейна является открытой и прозрачной, если смарт-контракту позволить поддерживать случайные числа и параметры обмена ключами, критически важные данные будут раскрыты, что приведет к утечке конфиденциальности данных.
Таким образом, zkTLS использует другой подход, его идея заключается в том, чтобы за счет криптографической защиты снизить высокие затраты, связанные с доступностью данных, которые традиционные Oracle обеспечивают на основе механизмов консенсуса. Это похоже на оптимизацию ZK-Rollup для OP-Rollup в L2. Конкретно, за счет введения ZKP и запроса к узлам реле для ресурсов HTTPS, получения информации о проверке соответствующих CA сертификатов, временных доказательствах и доказательствах целостности данных на основе HMAC или AEAD, создается Proof, и на блокчейне поддерживаются необходимые данные для проверки и алгоритмы проверки, что позволяет смарт-контрактам проверять достоверность данных, актуальность и надежность источника данных, не раскрывая критически важную информацию. Конкретные детали алгоритма здесь не обсуждаются, заинтересованные могут углубиться в изучение.
Основное преимущество этого технологического решения заключается в снижении затрат на доступность ресурсов HTTPS Web2. Это пробуждает множество новых потребностей, особенно в снижении затрат на получение цен на длинные хвосты активов на блокчейне, использовании авторитетных веб-сайтов из мира Web2 для KYC на блокчейне, что оптимизирует архитектурное проектирование DID и Web3 Game. Конечно, мы можем заметить, что zkTLS также оказывает влияние на существующие Web3 компании, особенно на текущие основные проекты Oracle. Поэтому, чтобы противостоять этому влиянию, такие гиганты отрасли, как Chainlink и Pyth, активно исследуют связанные направления, пытаясь сохранить свою доминирующую позицию в процессе технологической итерации, а также это приведет к появлению новых бизнес-моделей, таких как переход от оплаты по времени к оплате по объему, Compute as a service и т.д. Конечно, здесь есть сложности, как и у большинства ZK проектов, это все еще связано с тем, как снизить вычислительные затраты и сделать это коммерчески жизнеспособным.
В заключение, коллеги, при разработке продуктов вы также можете следить за развитием zkTLS и интегрировать этот технологический стек в подходящих аспектах, возможно, вы сможете найти новые направления в инновациях бизнеса и архитектуре технологий.