Автор: EQ Labs Источник: equilibrium Перевод: Шань-Оуба, Золотые финансы

В первой части нашей серии о конфиденциальности мы рассмотрели значение термина "конфиденциальность", разницу между конфиденциальностью в сети Блокчейн и веб-2, а также почему конфиденциальность сложно реализовать в Блокчейне.

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

Избавьтесь от оков прошлого, встретьте будущее

Существующая в блокчейне инфраструктура конфиденциальности направлена на обработку очень конкретных случаев использования, таких как частные платежи или голосование. Это довольно узкое видение, которое в основном отражает текущее использование блокчейна (сделки, трансферы и спекуляции). Как сказал Том Уолпо, криптовалюта подвержена парадоксу Ферми: 01928374656574839201

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

• Скрытое состояние: Большинство финансовых случаев требуют (по крайней мере) конфиденциальности перед другими пользователями, и если нет какого-то скрытого состояния, то многие аспекты игры будут потеряны (например, если каждый игрок за столом в покер может видеть карты друг друга).
• 隐藏逻辑：Некоторые сценарии требуют скрытия некоторой логики, одновременно позволяя другим использовать эту программу, например, стратегии соответствующего двигателя транзакций в блокчейне.

Эмпирический анализ (из web2 и web3) показывает, что большинство пользователей не готовы платить дополнительные деньги за повышение конфиденциальности или пропускать дополнительные этапы, и мы согласны с тем, что сама по себе конфиденциальность не является ключевым моментом. Однако она действительно делает возможным существование новых и (надеемся) более значимых случаев использования на блокчейне — давайте избавимся от парадокса Ферми.

Технология улучшения конфиденциальности (PET) и современные решения по шифрованию * («Программируемость пароля») * являются основными строительными блоками для достижения этой цели * (дополнительную информацию о доступных различных решениях и их компромиссах см. в приложении*).

Три предположения, влияющие на нашу точку зрения

Три ключевых предположения определяют наше представление о том, как развивается инфраструктура конфиденциальности блокчейна:

1. Технология шифрования будет абстрагирована от рук разработчиков приложений: Большинство разработчиков приложений не хотят (или не знают, как с ними обращаться) технология шифрования, необходимая для обеспечения конфиденциальности. Неразумно ожидать, что они реализуют свою собственную технологию шифрования и создадут цепочки частных приложений* (например, Zcash или Namada) или частные приложения поверх публичных цепочек (например, Tornado Cash). Это слишком сложно и накладно, и в настоящее время ограничивает пространство для проектирования для большинства разработчиков (неспособных создавать приложения, требующие некоторой конфиденциальности). Поэтому мы считаем, что важно абстрагироваться от сложности управления шифрованием от рук разработчика приложения. Здесь используются два подхода: Программируемость инфраструктуры конфиденциальности (общий частный L1/L2) или «секрет как услуга», который позволяет передавать конфиденциальные вычисления на аутсорсинг.
2. Многочисленные случаи использования (возможно, больше, чем мы представляем) требуют совместного использования частного состояния: как уже упоминалось, многие приложения требуют некоторого скрытого состояния и/или логики для нормального функционирования. Совместное использование частного состояния является одним из подмножеств, в котором долговременный расчет выполняется над одним и тем же частным состоянием. Хотя мы можем доверить централизованной стороне выполнение этой работы и остановиться на этом, но в идеале мы хотим сделать это с минимальным уровнем доверия, чтобы избежать единой точки отказа. Просто с использованием Доказательства с нулевым разглашением (ZKP) этого достичь невозможно - нам нужно использовать другие инструменты, такие как доверенная исполнительная среда (TEE), Полностью Гомоморфное шифрование (FHE) и/или долговременные вычисления (MPC).
3. Большие наборы маскировки могут максимально защищать конфиденциальность: большинство информации утекает при входе или выходе из набора маскировки, поэтому мы должны минимизировать такие случаи. Построение нескольких частных приложений на одной блокчейн может помочь укрепить защиту конфиденциальности путем увеличения числа пользователей и транзакций в одном и том же наборе маскировки.

Конец инфраструктуры конфиденциальности

Учитывая вышеприведенные предположения, какова конечная цель инфраструктуры конфиденциальности блокчейна? Существует ли способ, подходящий для всех приложений? Существует ли технология повышения конфиденциальности, которая может охватить все приложения?

Не совсем так. Все они имеют различные компромиссы, и мы уже видели, как они сочетаются разными способами. В целом, мы определили 11 различных подходов.

В настоящее время два наиболее популярных способа создания конфиденциальной инфраструктуры в блокчейне - использование ZKP или FHE. Однако оба имеют фундаментальные недостатки:

• Протокол, обеспечивающий сильную конфиденциальность на основе ZK с подтверждением клиента, позволяет лонгующий вычислять одно и то же приватное состояние. Это ограничивает возможности выражения, то есть, какие типы приложений могут создавать разработчики.
• FHE поддерживает вычисления над данными, зашифрованными и совместно используемыми частными состояниями, но возникает вопрос, кто* владеет* этим состоянием, то есть, кто владеет Секретный ключ расшифровки. Это ограничивает степень защиты конфиденциальности и нашу способность верить, что сегодняшняя конфиденциальность останется такой же завтра.

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

Обратите внимание, что хотя эти два метода в конечном итоге сольются, их применение в MPC различно:

• Сеть ZKP: MPC увеличивает выразительные возможности, реализуя вычисления с общим частным состоянием.
• Сеть FHE: MPC повышает безопасность и укрепляет конфиденциальность, распределяя расшифрованный секретный ключ комиссии MPC (а не отдельному стороннему лицу).

Хотя обсуждение начинает переходить к более детальным точкам зрения, гарантии, стоящие за этими различными методами, все еще не до конца изучены. Учитывая, что наше допущение доверия сводится к предположению о МПК, три ключевых вопроса, которые следует задать, это:

1. Насколько сильную конфиденциальность может обеспечить протокол MPC в блокчейне?
2. Достаточно ли зрела технология? Если нет, то в чем заключается узкое место?
3. Учитывая силу гарантии и затраты на ее внедрение, имеет ли это смысл по сравнению с другими методами?

Давайте более подробно ответим на эти вопросы.

Использование MPC для анализа рисков и уязвимостей

Всякий раз, когда решение использует FHE, люди всегда спрашивают: "Кто владеет секретным ключом для расшифровки?" Если ответ - "сеть", то следующий вопрос: "Какие реальные сущности составляют эту сеть?" Последний вопрос связан со всеми примерами использования MPC в какой-либо форме.

Источник информации: выступление Zama на ETH CC

Основным риском MPC является сговор, то есть злонамеренное сговорение достаточного количества участников для расшифровки данных или кражи вычислений. Сговор может достигаться вне блокчейна, и он будет раскрыт только в том случае, если злонамеренная сторона предпримет определенные действия (вымогательство, производство Токен01928374656574839201 и т.д.). Несомненно, это имеет значительное влияние на уровень конфиденциальности, который может обеспечить система. Риск сговора зависит от:

• На сколько злонамеренных сторон может выдержать этот Протокол?
• Какие стороны составляют сеть? Насколько им можно доверять?
• Количество и распределение различных сторон, участвующих в сети - существуют ли общие средства атаки?
• Сеть требует лицензии или лицензии не требуется (экономическая выгода и репутация/правовой базис)?
• Каково наказание за злонамеренное поведение? Является ли сговор в игре наилучшим результатом с точки зрения теории?

Насколько сильной является конфиденциальность, которую может обеспечить протокол MPC в блокчейне?

TLDR：Не так мощно, как мы надеялись, но сильнее, чем полагаться на централизованного посредника.

Пороговое значение для расшифровки зависит от выбранной схемы MPC — это в значительной степени компромисс между активностью ("гарантированная доставка результатов") и безопасностью. Вы можете выбрать очень безопасную схему N/N, но она может потерпеть неудачу, если один из Узлов выйдет из строя. С другой стороны, схемы N/2 или N/3 более надежны, но увеличивают риск злоумышленничества.

Два условия, которые нужно сбалансировать, это:

1. Секретная информация никогда не будет раскрыта (например, расшифрованный Секретный ключ)
2. Секретная информация никогда не исчезнет (даже если 1/3 участников внезапно уйдут).

Выбранные схемы отличаются в зависимости от реализации. Например, цель Zama - N/3, в то время как Arcium в настоящее время реализует схему N/N, но позже будет поддерживать схемы с более высокой гарантией активности (и большими предположениями доверия).

На этой границе компромиссное решение - использование смешанного подхода:

• Высокодоверительный комитет обрабатывает Секретный ключ с использованием порогового значения, например N/3.
• Комитет по вычислениям ротируется, например, существует N-1 порогов (или несколько различных комитетов по вычислениям с различными характеристиками для выбора пользователем).

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

Ещё один способ усиления безопасности - выполнение MPC в доверенном аппаратном обеспечении для совместного сохранения Секретного ключа в безопасной области. Это делает извлечение или использование совместно сохраненного Секретного ключа для операций, не относящихся к Протоколу, более сложным. По крайней мере, Zama и Arcium изучают TEE.

Более мелкие риски включают такие пограничные случаи, как социальная инженерия, например, все компании в кластере MPC нанимают высококвалифицированного инженера с опытом работы от 10 до 15 лет.

2. Технология достаточно зрела? Если нет, то что является узким местом?

С точки зрения производительности ключевым вызовом для MPC является коммуникационные затраты. Они возрастают с увеличением сложности вычислений и количества Узлов в сети (требуется больше обратной связи). Для случаев использования Блокчейна это имеет два практических последствия:

1. Набор малых операторов: чтобы управлять коммуникационными издержками, большинство существующих Протокол в настоящее время ограничены набором малых операторов. Например, сеть дешифровки Zama в настоящее время разрешает максимум 4 Узел (хотя они планируют расширить до 16). Согласно начальному Бенчмарк Zama для ее дешифровочной сети (TKMS), даже с кластером из 4 Узел дешифровка занимает 0.5-1 секунды (полный e2e процесс занимает больше времени). Другой пример - MPC, реализованная Taceo для базы данных радужки Worldcoin, где участвуют 3 стороны (предполагая 2/3 честных сторон).

Источник информации: выступление Zama на ETH CC 2. 3. Набор лицензированных операторов: В большинстве случаев операторы лицензированы. Это означает, что мы полагаемся на репутацию и юридические контракты, а не на экономическую или шифрование безопасность. Основной проблемой набора операторов без лицензии является то, что нельзя знать, сговорились ли люди вне блокчейна. Кроме того, требуется периодическое направление или перераспределение долей ключей, чтобы узел мог динамически входить/выходить из сети. Хотя набор операторов без лицензии является конечной целью, исследуется, как расширить механизм PoS для достижения порога MPC (например, Zama), но лицензированный путь кажется наилучшим направлением на данный момент.

Альтернативные методы

Полный набор конфиденциальности включает в себя:

• FHE используется для делегирования приватных вычислений
• ZKP используется для проверки правильности выполнения вычислений FHE
• MPC для расшифровки порогового значения
• Каждый Узел MPC работает внутри TEE для повышения безопасности

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

Это стоит? Возможно, стоит, но также стоит исследовать другие методы, которые могут обеспечить значительно более эффективные вычисления, при этом слегка снижая уровень конфиденциальности. Как сказал Лайрон из Seismic - мы должны сосредоточиться на самом простом решении, чтобы соответствовать нашим стандартам приватности и приемлемому компромиссу, а не просто излишне усложнять его.

1. Прямое использование MPC для общего вычисления

Если в конечном итоге ZK и FHE вернутся к доверительному предположению MPC, почему бы не использовать прямо MPC для вычислений? Это разумный вопрос, который также является тем, что команды, такие как Arcium, SodaLabs (использующие Coti v2), Taceo и Nillion, пытаются решить. Обратите внимание, что MPC имеет несколько форм, но здесь мы говорим о Протоколе на основе секретного распределения и гарбажных цепей (GC) в рамках трех основных методов, а не о Протоколе на основе FHE, который использует MPC для расшифровки.

Хотя MPC уже используется для распределенной подписи и более безопасных Кошелек и других простых вычислений, основной вызов при использовании MPC для более общих вычислений является коммуникационные издержки (которые возрастают с увеличением сложности вычислений и количества Узелов, вовлеченных в процесс).

Есть несколько способов снизить расходы, например, предварительная обработка в офлайн-режиме (то есть самая дорогая часть в Протоколе) - Arcium и SodaLabs исследуют этот вопрос. Затем выполнение вычислений на этапе онлайн, что потребует часть данных, сгенерированных на этапе офлайн. Это существенно снижает общие коммуникационные расходы.

Нижеприведенная таблица отображает начальные бенчмарки (в микросекундах), необходимые для выполнения 1,000 различных кодовых операций в gcEVM от SodaLabs. Хотя это является шагом в правильном направлении, все еще требуется много работы по улучшению эффективности и расширению набора операторов за пределы нескольких узлов.

Источник: SodaLabs

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

2. Доверенное исполнение

Недавно интерес к TEE снова возрос, его можно использовать как самостоятельно (на основе частных блокчейнов или сопроцессоров на базе TEE), так и в сочетании с другими PET (например, на основе решений ZK) для вычислений с общим частным состоянием только с использованием TEE).

Хотя TEE в некоторых аспектах более зрелы и имеют меньшие затраты на производительность, они не лишены недостатков. Во-первых, TEE имеет различные доверительные предположения (1/N) и обеспечивает аппаратные, а не программные решения. Критика, которую часто слышат, связана с ранними уязвимостями SGX, но стоит отметить, что TEE ≠ Intel SGX. TEE также требует доверия к поставщику аппаратного обеспечения, а стоимость аппаратных средств высока (большинство людей не могут себе это позволить). Одно из решений для устранения риска физических атак может быть запуск TEE в космосе для выполнения ключевых задач.

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

3. Частные DAC и другие методы защиты конфиденциальности, основанные на доверенных третьих лицах

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

Комитет по доступности частных данных (DAC) - пример того, как члены DAC хранят данные вне блокчейна, в которых пользователи доверяют им в правильном хранении данных и выполнении обновлений состояния. Другая форма - это лицензированный последователь Тома Уолпо.

Хотя данная методика сделала большой компромисс в области защиты конфиденциальности, однако с точки зрения стоимости и производительности, это может быть единственной возможной альтернативой для приложений с низкой стоимостью и высокой производительностью (по крайней мере, в настоящее время). Например, протокол Lens планирует использовать частную DAC для реализации частного потока информации. Для социальных сценариев в блокчейне и других применений может быть разумным компромисс между конфиденциальностью и стоимостью/производительностью (учитывая затраты на альтернативные решения).

4. Адрес невидимки

Адрес 01928374656574839201 может обеспечить конфиденциальность, аналогичную созданию нового Адреса для каждой транзакции, но этот процесс автоматически выполняется на сервере и не открыт для пользователей. Дополнительную информацию можно найти в этом обзоре Виталика или в этой статье, рассматривающей различные методы подробнее. Основными участниками в этой области являются Umbra и Fluidkey.

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

Кроме того, конфиденциальность, обеспеченная адресом, менее надежна, чем у других альтернатив. Анонимность может быть нарушена простым кластерным анализом, особенно если поступления и отчисления находятся вне обычного диапазона (например, получение 10 000 долларов, но ежедневные транзакции в среднем составляют 10-100 долларов). Еще одной проблемой для протокола является необходимость обновления секретного ключа для каждого кошелька отдельно (общее хранение секретных ключей может помочь решить эту проблему). С точки зрения пользовательского опыта, если у счета нет токенов (например, ETH), то для использования протокола адресования требуется абстрагирование счета или оплата комиссии от отправителя.

Риски, с которыми сталкивается наш аргумент

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

1. Общая частная статус не так важно, как мы себе представляем: в этом случае, на основе ZK инфраструктуры, вероятнее всего, будет преобладать, поскольку она обеспечивает более сильную конфиденциальность и более низкие затраты, чем FHE. Уже есть некоторые случаи использования, которые показывают хорошие результаты работы на основе ZK систем, например, приватной платежной ПротоколPayy.
2. Компромисс в производительности не стоит преимущества конфиденциальности: Некоторые могут сказать, что предположение о доверии сети MPC с 2-3 лицензированными сторонами не сильно отличается от одного централизованного участника, и значительное увеличение затрат/издержек не стоит того. Для многих приложений, особенно для низкостоимостных и чувствительных к затратам приложений (например, социальных или игровых), это может быть верным. Однако, есть и много высокоценных случаев использования, где сотрудничество в настоящее время очень дорого (или невозможно) из-за юридических проблем или координационных проблем. Вот где MPC и решения на основе FHE могут выиграть.
3. Специализация превосходит универсальный дизайн: создание новой цепи и направление пользователей и разработчиков сообщества очень сложно. Поэтому универсальная инфраструктура конфиденциальности (L1/L2) может быть сложна в использовании. Еще одной проблемой является специализация; сложно создать единственный Протокол, который охватывает все пространство компромиссов. В этом мире решения, обеспечивающие конфиденциальность для существующей экосистемы (как услуга конфиденциальности) или для специального случая (например, платежи), будут иметь преимущество. Однако мы относимся к последнему скептически, потому что это создает сложность для разработчиков приложений, которым нужно самостоятельно реализовывать некоторые техники шифрования (вместо их абстрагирования).
4. Регулирование продолжает препятствовать испытаниям решений в области конфиденциальности: для тех, кто строит инфраструктуру конфиденциальности и приложения с определенной защитой конфиденциальности, это представляет собой риск. Для применений в некредитной сфере регуляторные риски невелики, но сложно (или невозможно) контролировать, что строится на нелицензированной инфраструктуре конфиденциальности. Скорее всего, мы решим технические проблемы до решения проблем регулирования.
5. Для большинства сценариев затраты на решения, основанные на MPC и FHE, все еще слишком высоки: хотя MPC в основном страдает от издержек связи, команда FHE сильно зависит от аппаратного ускорения для повышения производительности. Однако, если мы можем предположить развитие специализированного аппаратного обеспечения в области ZK, то время, необходимое до получения доступного для производства аппаратного обеспечения FHE, будет намного длиннее, чем предполагают большинство людей. Команды, работающие над ускорением аппаратного обеспечения FHE, включают Optalysys, fhela и Niobium.

Общее

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

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

Однако не все проблемы требуют использования одного и того же инструмента для их решения. Несмотря на то, что мы считаем МПК конечной целью, все же есть и другие методы, которые являются приемлемым выбором, пока затраты на решение, управляемое МПК, остаются высокими. Всегда стоит обдумать, какой метод лучше всего подходит для конкретных потребностей/характеристик проблемы, которую мы пытаемся решить, и каких компромиссов мы готовы сделать.

Даже если у вас лучший молоток в мире, это не значит, что все - гвозди.