Расширение технологического стека: Обзор принципов zkTLS и потенциальных сценариев использования

Автор:@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, которое включает:

l Поддерживаемые версии TLS (например, TLS 1.3)

l Поддерживаемые алгоритмы шифрования (Cipher Suites, например, AES-GCM, ChaCha20)

l Случайное число (Client Random) (используется для генерации ключа)

l Параметры обмена ключами (например, открытый ключ ECDHE)

l SNI (Server Name Indication) (опционально, используется для поддержки HTTPS с несколькими доменами)

Его цель — сообщить серверу о возможностях шифрования клиента и подготовить параметры безопасности.

2. Сервер отправляет ServerHello:

Сервер отвечает сообщением ServerHello, которое включает:

l Выбранный алгоритм шифрования

l Случайное число сервера (Server Random)

l Сертификат сервера (сертификат X.509)

l Параметры обмена ключами сервера (например, открытый ключ ECDHE)

l Сообщение Finished (используется для подтверждения завершения рукопожатия)

Его цель — сообщить клиенту личность сервера и подтвердить параметры безопасности.

3. Клиент проверяет сервер:

Клиент выполняет следующие действия:

l Проверка сертификата сервера: обеспечение того, что сертификат подписан доверенным CA (центром сертификации), а также проверка срока действия сертификата и его отзыва;

l Вычисление общего ключа: использование своего открытого ключа ECDHE и открытого ключа сервера для вычисления ключа сессии (Session Key), который используется для последующего симметричного шифрования коммуникации (например, AES-GCM).

l Отправка сообщения Finished: подтверждение целостности данных рукопожатия для предотвращения атак типа «человек посередине» (MITM).

Его цель — убедиться в надежности сервера и сгенерировать ключ сессии.

4. Начало зашифрованной коммуникации:

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

l Использование симметричного шифрования (например, AES-GCM, ChaCha20) для шифрования данных, что повышает скорость и безопасность.

l Защита целостности данных: использование 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.

Некоторые могут спросить, почему нельзя просто встроить возможность вызова Web2 API непосредственно в среду ончейн-VM. Ответ: нельзя, потому что причина, по которой в ончейн-среде необходимо поддерживать закрытые данные, заключается в обеспечении отслеживаемости всех данных, то есть в процессе консенсуса все узлы имеют единую логику оценки точности определенных данных или результатов выполнения, иными словами, это объективная логика проверки. Это гарантирует, что в полностью бездоверительной среде большинство доброжелательных узлов могут полагаться на свои избыточные данные для определения истинности непосредственного результата. Однако из-за данных Web2 трудно построить эту единую логику оценки, поскольку из-за некоторых задержек сети результаты, полученные разными узлами при доступе к ресурсам Web2 HTTPS, могут отличаться, что затрудняет консенсус, особенно в некоторых областях высокочастотных данных. Кроме того, другая ключевая проблема заключается в том, что безопасность протокола TLS, от которого зависит протокол HTTPS, зависит от случайного числа, сгенерированного клиентом (Client Random) (используется для генерации ключа), и параметров обмена ключами для реализации согласования ключа шифрования с серверной стороной. Но мы знаем, что ончейн-среда открыта и прозрачна. Если позволить смарт-контракту поддерживать случайные числа и параметры обмена ключами, ключевые данные будут раскрыты, что нанесет ущерб конфиденциальности данных.

Тогда zkTLS использует другой подход. Его концепция заключается в замене высокой стоимости обеспечения доступности данных традиционными Oracle на основе механизма консенсуса криптографической защитой. Это похоже на оптимизацию OP-Rollup с помощью ZK-Rollup в L2. Конкретнее, путем внедрения доказательства с нулевым разглашением ZKP и вычисления Proof для ресурсов, полученных запросом оффчейн-узла ретрансляции к определенному HTTPS, соответствующей информации проверки сертификата CA, доказательства временной последовательности и доказательства целостности данных на основе HMAC или AEAD. При этом в цепи поддерживается необходимая информация для проверки и алгоритмы проверки, что позволяет смарт-контракту проверять подлинность, актуальность и надежность источника данных, не раскрывая ключевую информацию. Конкретные детали алгоритма здесь не обсуждаются, заинтересованные могут изучить их самостоятельно.

Наибольшее преимущество этого технического решения заключается в снижении стоимости обеспечения доступности ресурсов Web2 HTTPS. Это стимулирует много новых потребностей, особенно в снижении затрат на получение цен нишевых активов в цепи, использовании авторитетных веб-сайтов в мире Web2 для проведения ончейн-KYC, тем самым оптимизируя техническую архитектуру DID, Web3 Game и т. д. Конечно, мы можем заметить, что влияние zkTLS на существующие предприятия Web3 также существует, особенно в отношении текущих основных проектов оракулов. Поэтому, чтобы противостоять этому влиянию, такие гиганты отрасли, как Chainlink и Pyth, активно ведут исследования в соответствующих направлениях, пытаясь сохранить доминирующее положение в процессе технологической итерации. Одновременно это также породит новые бизнес-модели, например, переход от прежней оплаты за время к оплате за использование, Compute as a service и т. д. Конечно, сложность здесь, как и в большинстве проектов ZK, заключается в том, как снизить вычислительные затраты, чтобы это имело коммерческую ценность.

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