В этой статье специалист по программному обеспечению Притхи Касиредди (Preethi Kasireddy) делится своими взглядами на проблемы технологии блокчейн и способы их решения. С первой частью статьи можно ознакомиться здесь.
2. Ограничения конфиденциальности
Ваши транзакции в блокчейне не имеют прямой привязки лично к вам, и потому они могут казаться конфиденциальными, ведь кто угодно может создать анонимный кошелек и совершать транзакции через него.
Но не все так просто.
С одной стороны, использование псевдонимов составляет сильную сторону этой технологии. Хоть история транзакций и хранится в открытом реестре, эти данные привязаны к учетным записям, состоящим только из букв и цифр. Кроме того, к учетным записям не привязаны никакие реальные данные, и отыскать человека, который совершил транзакцию, кажется невозможным.
Но на самом деле это только создает видимость безопасности. Человек действительно может сохранять анонимность, пока его псевдоним в сети не связан с его реальным именем, но достаточно одной утечки информации, чтобы это перестало быть тайной. Один такой случай уже произошел: правоохранительные органы подтвердили, что в ходе расследования узнали имена людей, переводивших биткоины, и тем самым опровергли предположение о полной конфиденциальности подобных транзакций.
Как они смогли это сделать?
Информация из cookie-файла или из программы, которая анализирует поведение пользователя на веб-сайте, может попасть в сеть и стать доступной для кого угодно — и для правительств, и для правоохранительных органов, и для злоумышленников.
Более того, в таких блокчейн-платформах, как Ethereum, пользователи создают смарт-контракты, которые могут оперировать самыми разными данными. В блокчейне Ethereum все данные из смарт-контрактов, включая отправителя, получателя, переданные в транзакции данные, выполненный код и состояние, записанное в контракте, находятся в открытом доступе.
Для большинства компаний неприемлемо записывать важные данные в блокчейн, где их может увидеть кто угодно, включая и хакеров, и конкурентов. Примерами таких данных могут служить:
- Электронные медицинские карты. Публикация этих данных в блокчейне недопустима, потому что нарушает право пациента на конфиденциальность.
- Данные из удостоверений личности – например, номер паспорта.
- Данные для авторизации, такие как пароли и ключи.
- Финансовые документы – например, таблицы капитализации или данные о зарплате сотрудников.
- И многое другое.
Конфиденциальность остается серьезным препятствием для физических лиц и организаций, а также в отраслях, где важна сохранность личных данных. Многие из тех, кто возлагает большие надежды на криптовалюты, заинтересованы в создании системы, которая предоставляет новые финансовые возможности и при этом не требует доверия к другим участникам и устойчива к цензуре. Как ни парадоксально, сейчас для этих целей используется открытый и легко отслеживаемый реестр!
Решения проблемы конфиденциальности
Вот примеры решений, над которыми сейчас работают разные команды разработчиков.
Адреса на эллиптической кривой Диффи-Хеллмана-Меркле (ECDHM, от Elliptic Curve Diffie-Hellman-Merkle)
Концепция ECDHM-адресов основана на протоколе Диффи-Хеллмана. Он позволяет двум сторонам получить общий секретный ключ, с помощью которого они в дальнейшем смогут обмениваться закрытыми сообщениями в открытой сети.
Каким образом?
Отправитель и получатель могут публично обменяться ECDHM-адресами, а затем использовать общий секретный ключ для генерации анонимных адресов в сети Биткоин. Эти Биткоин-адреса могут быть открыты только тому, кому известен секретный ключ, а в открытом доступе остаются только ECDHM-адреса многоразового использования. Поэтому участники могут не переживать за конфиденциальность своих транзакций.
Концептуальная схема идеи обмена ключами, которая использует разные цвета вместо очень больших чисел (Источник)
Примеры схем, основанных на ECDHM-адресах, включают Stealth-адреса Питера Тодда (Peter Todd), платежные коды многоразового использования из BIP47 Юстуса Ранвье (Justus Ranvier) и обмен адресами по внешнему каналу из BIP75 Джастина Ньютона (Justin Newton). Однако рабочие реализации таких схем встречаются крайне редко.
Миксеры
Идея миксера заключается в том, что несколько пользователей объединяют свои платежи в общий пул и хранят записи о том, кто кому сколько должен, в закрытом реестре. После того как средства из общего пула потрачены, нельзя определить источники отдельных платежей. Наблюдатель может видеть, кому и сколько было передано средств, но вычислить человека, который совершил тот или иной платеж, в теории, нельзя. Пример такого миксера — CoinJoin.
К сожалению, на практике миксеры оказались ненадежным решением. Например, эксперты смогли легко установить источник транзакций, совершенных с помощью CoinJoin, и доказали, что злонамеренному пользователю достаточно потратить 32 000 долларов, чтобы с вероятностью 90% лишить участников транзакции анонимности. Более того, оказалось, что миксеры слабо устойчивы к атакам Сивиллы и DoS-атакам.
Еще более разочаровывает то, что якобы защищенный реестр миксера требует администрирования третьей стороной, которой должны доверять участники пула миксера.
Поскольку CoinJoin не является сервисом, предоставляемым по умолчанию, его используют не так много людей, то есть количество участников в пуле миксера невелико. Поэтому несложно определить, что конкретную транзакцию совершил один из нескольких возможных участников.
Другой пример такого решения – CoinShuffle, децентрализованный миксер-протокол, разработанный группой исследователей из Саарского университета в Германии. Они попытались улучшить CoinJoin, исключив необходимость наличия доверенной третьей стороны для компоновки объединенных транзакций.
Monero
Другой способ решения проблемы конфиденциальности — это создание криптовалюты, анонимной по умолчанию, такой как Monero. В отличие от многих альткоинов, Monero – не форк Биткоина. В основе Monero лежит альтернативный протокол CryptoNote.
Главное отличие Monero от других криптовалют — использование схемы кольцевой подписи.
Это вариант групповой подписи, где каждый участник, имеющий право поставить подпись, имеет открытый и закрытый ключи. В отличие от обычной криптографической подписи, которая показывает, что транзакция подтверждена одним участником, групповая подпись означает, что транзакция подтверждена одним из участников группы, но неизвестно, каким именно.
Доказательство с нулевым разглашением
Этот криптографический протокол позволяет проверяющей сторонеубедиться, что доказывающая сторона обладает неким секретным знанием, без необходимости раскрытия информации о нем проверяющей стороне. Другими словами, программа может предусматривать ввод секретных данных, но доказывающая сторона не предоставляет эти данные проверяющей. Доказательство с нулевым разглашением предоставляет основные элементы для реализации механизмов обеспечения конфиденциальности. Рассмотрим несколько примеров.
Пример 1: игры «вызов — ответ»
В сфере компьютерной безопасности аутентификация типа «вызов — ответ» описывает класс протоколов, в которых одна сторона должна задать вопрос («вызов»), а другая — предоставить верный ответ. Такую «игру» можно использовать для подтверждения транзакций в блокчейне. Если транзакция оказалась недействительной, другой узел может «привлечь внимание» к этому факту. Для подтверждения того, что транзакция недействительна, требуется доказательство, которое можно проверить. Если такого доказательства нет, источник транзакции получает «вызов», и для подтверждения подлинности транзакции он должен отправить верный ответ.
Рассмотрим пример. Боб имеет эксклюзивный доступ к некоему ресурсу (например, к своему автомобилю). Алиса хочет получить доступ к этому автомобилю, потому что ей нужно ехать в магазин. Боб отправляет ей вызов, например, «52w72y». Алиса должна отправить Бобу символьную строку, которая будет верным ответом на его вызов. Единственный способ сформировать такую строку — использовать алгоритм, который известен и Бобу, и Алисе. Кроме того, Боб каждый раз присылает новый вызов. Таким образом, если Алиса знает правильные ответы на прошлые вызовы, это не дает ей никакого преимущества.
Игры «вызов — ответ» уже используются в некоторых блокчейнах, например, в Ethereum. Однако пока нам не хватает библиотек и инструментов, которые могли бы серьезно упростить использование таких схем аутентификации.
Пример 2: zk-SNARK
Что такое zk-SNARK? Давайте разбираться.
- zk = zero-knowledge (дословно — нулевое знание, здесь — нулевое разглашение). Это значит, что для доказательства существования информации необязательно делиться этой информацией.
- SNARK: Succinct Non-interactive Adaptive ARgument of Knowledge (сжатое неинтерактивное адаптивное доказательство знания).
- «Сжатое» означает, что доказательство может быть предоставлено в короткий срок.
- «Неинтерактивное» означает, что проверяющей стороне не нужно напрямую взаимодействовать с доказывающей стороной. Вместо этого, доказывающая сторона может заранее опубликовать доказательство, которое потребуется проверяющей стороне.
- «Адаптивное доказательство знания» означает доказательство знания о некоем вычислении.
zk-SNARK — это перспективная и впечатляющая технология обеспечения конфиденциальности, однако у нее есть узкие места:
Пример 3: zk-SNARK + Zcash
Zcash — анонимная криптовалюта, основанная на zk-SNARK. В Zcash есть так называемые защищенные транзакции, свойства которых распространяются на каждый из передаваемых коинов. Защищенные транзакции используют защищенные адреса, которые требуют от отправителя или получателя сгенерировать доказательство с нулевым разглашением, позволяющее другим участникам сети верифицировать зашифрованные данные транзакции без доступа к ним.
Схема транзакций Zcash
Несомненно, такой проект, как Zcash, заслуживает особого внимания.
Пример 4: zk-SNARK + Ethereum
В Metropolis, следующем обновлении протокола Ethereum, разработчики получат возможность эффективно и ончейн верифицировать доказательства zk-SNARK.
Какие возможности откроет использование технологии zk-SNARK в Ethereum? Некоторые параметры контрактов можно будет сделать конфиденциальными. Вместо того чтобы хранить информацию о секрете в блокчейне, ее можно хранить на стороне пользователей, которые будут подтверждать выполнение условий контракта с помощью SNARK. Каждый из этих пользователей должен заранее пройти фазу настройки. Но как только вычисление зафиксировано, его можно использовать для проверки сколь угодно большого числа транзакций.
Однако SNARK не сможет обеспечить для Ethereum конфиденциальность без участия пользователя. Ведь в этом случае SNARK полагается на пользователя, который хранит секрет вне блокчейна, и поэтому проверка секрета без участия этого пользователя невозможна.
Пример 5: zk-STARK
У zk-SNARK есть «преемник» — zk-STARK. Здесь буква T означает «Transparent» (прозрачный). zk-STARK исправляет одну из основных уязвимостей zk-SNARK — необходимость предварительной настройки. Кроме того, эта технология проще, потому что она основана только на хешировании и теории передачи информации, и еще она лучше защищена от взлома с помощью квантовых компьютеров, так как не использует эллиптические кривые и экспоненциальные допущения.
В целом, несмотря на большой прогресс в улучшении перечисленных выше схем обеспечения конфиденциальности с помощью доказательств с нулевым разглашением, они еще нуждаются в серьезных доработках. Библиотеки, реализующие доказательство с нулевым разглашением, требуют всестороннего анализа, проверок в полевых условиях и дополнительного развития. Также нужны проверки технологий zk-SNARK и zk-STARK в различных публичных блокчейнах. И мы еще посмотрим, как заложенные в Zcash сценарии использования покажут себя в большем масштабе и в реальных условиях. Для всего этого нужно время.
Обфускация кода
Еще один механизм обеспечения конфиденциальности – обфускация (запутывание) кода. Предположим, у нас есть программа P. Применив к ней обфускатор, мы получим программу O(P) = Q. При одинаковых входных данных обе программы возвращают одинаковые результаты, но с помощью анализа программы Q невозможно получить информацию о внутреннем устройстве P. Таким образом можно скрыть конфиденциальные данные (пароли, номера документов и т. п.) внутри Q, и при этом они будут оставаться доступными для использования.
Эксперты считают, что полная обфускация, которая превратила бы программу в «черный ящик», невозможна. Зато возможен более слабый вариант этого преобразования, который называется «обфускация неразличимости» (indistinguishability obfuscation). Возьмем две программы A и B, которые при одинаковых входных данных возвращают одинаковые результаты. После применения к ним обфускатора неразличимости получаются программы O(A) = P и O(B) = Q, и если у вас нет доступа к программам A и B, то вы не сможете определить, какая из них была исходной для программы P.
Эксперты Крейг Джентри (Craig Gentry), Амит Сахай (Amit Sahai) и др.описали реализацию обфускации неразличимого кода. Разработанный ими алгоритм очень требователен к вычислительным ресурсам, но если получится его улучшить, это решит многие проблемы. Самая интересная возможность в мире криптовалют — это идея публикации в блокчейне контрактов, содержащих закрытые данные.
Например, представим себе контракт на платформе Ethereum, который содержит пользовательский пароль для Coinbase. Можно написать программу, которая при выполнении определенных условий контракта открывает HTTPS-соединение с Coinbase через какой-нибудь промежуточный узел, авторизуется с этим паролем и совершает сделку. Если данные, которые хранятся в контракте, будут скрыты с помощью обфускатора, ни промежуточный узел, ни любой другой пользователь блокчейна не смогут изменить передаваемый запрос или узнать пароль.
Оракулы
Применительно к блокчейнам, оракул — это сторона, которая выполняет обмен данными между смарт-контрактами и внешними источниками данных. Фактически это носитель информации, передаваемой между смарт-контрактами, которые находятся в блокчейне, и внешними источниками данных, которые находятся вне блокчейна. Один из способов сохранения конфиденциальности данных — это использование оракулов для получения закрытых данных из внешних источников.
Безопасная среда исполнения
Безопасная среда исполнения (Trusted Execution Environment, TEE) представляет собой защищенную область в главном процессоре. Код и данные, загруженные в эту область, защищены с точки зрения целостности и конфиденциальности. Безопасная среда существует параллельно с операционной системой, в которой работает пользователь, но по сравнению с последней, она должна иметь более высокую степень конфиденциальности и защищенности.
Уже сейчас проводятся исследования возможностей использования безопасной среды исполнения для обеспечении конфиденциальности в блокчейне. Приятно, что многие эксперты работают в этом направлении, но хотелось бы, чтобы их стало еще больше.
Продолжение следует..
Будь в курсе! Подписывайся на Криптовалюта.Tech в Telegram
