🎃 Загадочное веселье, настоящие награды! Gate.io #Halloween Magic# вот здесь!
🎁 Откройте Таинственную Дверь, чтобы получить конфеты или золотые монеты и поделиться $60,000 угощениями!
🎉 Получите 1 БЕСПЛАТНЫЙ шанс каждый день: https://www.gate.io/activities/halloween-magic
Подробности: https://ww
Каждая дорога ведет к MPC? Исследование конечной цели инфраструктуры конфиденциальности
Автор: EQ Labs Источник: equilibrium Перевод: Шань-Оуба, Золотые финансы
В первой части нашей серии о конфиденциальности мы рассмотрели значение термина "конфиденциальность", разницу между конфиденциальностью в сети Блокчейн и веб-2, а также почему конфиденциальность сложно реализовать в Блокчейне.
Основная идея этой статьи заключается в том, что если идеальным конечным состоянием является инфраструктура конфиденциальности с Программируемостью, которая может обрабатывать общие частные состояния без каких-либо одиночных точек отказа, то все дороги ведут к MPC. Мы также рассмотрим зрелость MPC и его доверительные предположения, подчеркнем альтернативные подходы, сравним компромиссы и предоставим обзор отрасли.
Избавьтесь от оков прошлого, встретьте будущее
Существующая в блокчейне инфраструктура конфиденциальности направлена на обработку очень конкретных случаев использования, таких как частные платежи или голосование. Это довольно узкое видение, которое в основном отражает текущее использование блокчейна (сделки, трансферы и спекуляции). Как сказал Том Уолпо, криптовалюта подвержена парадоксу Ферми: 01928374656574839201
Помимо расширения личной свободы, мы считаем, что конфиденциальность является предварительным условием для расширения пространства Блокчейн-дизайна, превосходящего текущие спекулятивные метаданные. Многие приложения требуют некоторого приватного состояния и/или скрытой логики для нормальной работы:
Эмпирический анализ (из web2 и web3) показывает, что большинство пользователей не готовы платить дополнительные деньги за повышение конфиденциальности или пропускать дополнительные этапы, и мы согласны с тем, что сама по себе конфиденциальность не является ключевым моментом. Однако она действительно делает возможным существование новых и (надеемся) более значимых случаев использования на блокчейне — давайте избавимся от парадокса Ферми.
Технология улучшения конфиденциальности (PET) и современные решения по шифрованию * («Программируемость пароля») * являются основными строительными блоками для достижения этой цели * (дополнительную информацию о доступных различных решениях и их компромиссах см. в приложении*).
Три предположения, влияющие на нашу точку зрения
Три ключевых предположения определяют наше представление о том, как развивается инфраструктура конфиденциальности блокчейна:
Конец инфраструктуры конфиденциальности
Учитывая вышеприведенные предположения, какова конечная цель инфраструктуры конфиденциальности блокчейна? Существует ли способ, подходящий для всех приложений? Существует ли технология повышения конфиденциальности, которая может охватить все приложения?
Не совсем так. Все они имеют различные компромиссы, и мы уже видели, как они сочетаются разными способами. В целом, мы определили 11 различных подходов.
В настоящее время два наиболее популярных способа создания конфиденциальной инфраструктуры в блокчейне - использование ZKP или FHE. Однако оба имеют фундаментальные недостатки:
Если идеальным конечным состоянием является наличие инфраструктуры конфиденциальности с возможностью программирования, способной обрабатывать общие конфиденциальные состояния, не допуская при этом любых односторонних отказов, то два пути могут привести к MPC:
Обратите внимание, что хотя эти два метода в конечном итоге сольются, их применение в MPC различно:
Хотя обсуждение начинает переходить к более детальным точкам зрения, гарантии, стоящие за этими различными методами, все еще не до конца изучены. Учитывая, что наше допущение доверия сводится к предположению о МПК, три ключевых вопроса, которые следует задать, это:
Давайте более подробно ответим на эти вопросы.
Использование MPC для анализа рисков и уязвимостей
Всякий раз, когда решение использует FHE, люди всегда спрашивают: "Кто владеет секретным ключом для расшифровки?" Если ответ - "сеть", то следующий вопрос: "Какие реальные сущности составляют эту сеть?" Последний вопрос связан со всеми примерами использования MPC в какой-либо форме.
Источник информации: выступление Zama на ETH CC
Основным риском MPC является сговор, то есть злонамеренное сговорение достаточного количества участников для расшифровки данных или кражи вычислений. Сговор может достигаться вне блокчейна, и он будет раскрыт только в том случае, если злонамеренная сторона предпримет определенные действия (вымогательство, производство Токен01928374656574839201 и т.д.). Несомненно, это имеет значительное влияние на уровень конфиденциальности, который может обеспечить система. Риск сговора зависит от:
Насколько сильной является конфиденциальность, которую может обеспечить протокол MPC в блокчейне?
TLDR:Не так мощно, как мы надеялись, но сильнее, чем полагаться на централизованного посредника.
Пороговое значение для расшифровки зависит от выбранной схемы MPC — это в значительной степени компромисс между активностью ("гарантированная доставка результатов") и безопасностью. Вы можете выбрать очень безопасную схему N/N, но она может потерпеть неудачу, если один из Узлов выйдет из строя. С другой стороны, схемы N/2 или N/3 более надежны, но увеличивают риск злоумышленничества.
Два условия, которые нужно сбалансировать, это:
Выбранные схемы отличаются в зависимости от реализации. Например, цель Zama - N/3, в то время как Arcium в настоящее время реализует схему N/N, но позже будет поддерживать схемы с более высокой гарантией активности (и большими предположениями доверия).
На этой границе компромиссное решение - использование смешанного подхода:
Хотя это теоретически привлекательно, но оно также вводит дополнительную сложность, например, взаимодействие комиссии по вычислениям с высокодоверенной комиссией.
Ещё один способ усиления безопасности - выполнение MPC в доверенном аппаратном обеспечении для совместного сохранения Секретного ключа в безопасной области. Это делает извлечение или использование совместно сохраненного Секретного ключа для операций, не относящихся к Протоколу, более сложным. По крайней мере, Zama и Arcium изучают TEE.
Более мелкие риски включают такие пограничные случаи, как социальная инженерия, например, все компании в кластере MPC нанимают высококвалифицированного инженера с опытом работы от 10 до 15 лет.
2. Технология достаточно зрела? Если нет, то что является узким местом?
С точки зрения производительности ключевым вызовом для MPC является коммуникационные затраты. Они возрастают с увеличением сложности вычислений и количества Узлов в сети (требуется больше обратной связи). Для случаев использования Блокчейна это имеет два практических последствия:
Источник информации: выступление Zama на ETH CC 2. 3. Набор лицензированных операторов: В большинстве случаев операторы лицензированы. Это означает, что мы полагаемся на репутацию и юридические контракты, а не на экономическую или шифрование безопасность. Основной проблемой набора операторов без лицензии является то, что нельзя знать, сговорились ли люди вне блокчейна. Кроме того, требуется периодическое направление или перераспределение долей ключей, чтобы узел мог динамически входить/выходить из сети. Хотя набор операторов без лицензии является конечной целью, исследуется, как расширить механизм PoS для достижения порога MPC (например, Zama), но лицензированный путь кажется наилучшим направлением на данный момент.
Альтернативные методы
Полный набор конфиденциальности включает в себя:
Это очень сложно, вводит много неисследованных крайних случаев, требует больших затрат и, возможно, не сможет быть реализовано в течение многих лет в будущем. Еще один риск заключается в том, что люди могут чувствовать ложное чувство безопасности из-за наложения нескольких сложных концепций. Чем больше сложности и предположений о доверии мы добавляем, тем сложнее делать выводы о общей безопасности решения.
Это стоит? Возможно, стоит, но также стоит исследовать другие методы, которые могут обеспечить значительно более эффективные вычисления, при этом слегка снижая уровень конфиденциальности. Как сказал Лайрон из 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, главным образом по следующим причинам:
Общее
*В конечном счете, прочность цепи зависит от ее самого слабого звена. В случае программной конфиденциальности инфраструктуры, если мы хотим, чтобы она могла обрабатывать общие приватные состояния без единой точки отказа, то гарантия доверия сводится к гарантии MPC.
Хотя этот текст кажется критическим по отношению к MPC, на самом деле это не так. MPC значительно улучшил текущее положение, зависящее от централизованных сторон. Мы считаем, что основная проблема заключается в том, что в отрасли существует ложное доверие, и проблема скрыта. Напротив, мы должны прямо сталкиваться с проблемой и фокусироваться на оценке потенциальных рисков.
Однако не все проблемы требуют использования одного и того же инструмента для их решения. Несмотря на то, что мы считаем МПК конечной целью, все же есть и другие методы, которые являются приемлемым выбором, пока затраты на решение, управляемое МПК, остаются высокими. Всегда стоит обдумать, какой метод лучше всего подходит для конкретных потребностей/характеристик проблемы, которую мы пытаемся решить, и каких компромиссов мы готовы сделать.
Даже если у вас лучший молоток в мире, это не значит, что все - гвозди.