Чтобы исправить интеллектуальные контракты, начните с их секретов
2 июля 2025 г.Авторы:
(1) Руджия Ли, Южный университет науки и технологии, Китай, Университет Бирмингема, Великобритания и этот автор внес свой вклад в эту работу;
(2) Цинь Ван, CSIRO DATA61, Australia и этот автор внес свой вклад в эту работу;
(3) Ци Ван, Южный университет науки и техники, Китай;
(4) Дэвид Галиндо, Университет Бирмингема, Великобритания;
(5) Марк Райан, Университет Бирмингема, Великобритания.
Таблица ссылок
Аннотация и I. Введение
II Тур молнии
Iii. Методология систематизации
IV Раствор слоя-один
V. Slayer-Two Solution
VI Дискуссия
VII. Исследовательские проблемы
VIII. Заключительные замечания и ссылки
Приложение А.Ключевые управления
Приложение B.Анонимность и конфиденциальность
Приложение C.Фон
Приложение D.Протокол голосования на основе TCSC
Абстрактный-Смарт-контракт на основе блокчейна не имеет конфиденциальности, поскольку штат контракта и код инструкции подвергаются общественности. Комбинирование выполнения интеллектуального контракта с доверенной средой выполнения (TEE) обеспечивает эффективное решение, называемое интеллектуальными контрактами с помощью TEE, для защиты конфиденциальности контрактных состояний. Однако комбинированные подходы различны, и систематическое исследование отсутствует. Недавно выпущенные системы могут не использовать опыт, изученный из существующих протоколов, таких как повторяющиеся известные ошибки дизайна или применение технологии TEE небезопасными способами. В этой статье мы сначала исследуем и классифицируем существующие системы на два типа: решение слоя-один и решение-слое-два. Затем мы устанавливаем структуру анализа, чтобы запечатлеть их общие огни, охватывая желаемые свойства (для контрактных услуг), модели угроз и соображения безопасности (для базовых систем). Основываясь на нашей таксономии, мы определяем их идеальные функции и раскрываем фундаментальные недостатки и причину проблем в дизайне каждой спецификации. Мы считаем, что эта работа предоставит руководство по разработке интеллектуальных контрактов с помощью TEE, а также основы для оценки будущих конфиденциальных контрактных систем с помощью TEE.
I. Введение
Умный контракт был первоначально введен Szabo [1] и дополнительно разработан Ethereum [2] в системах блокчейна. Смарт-контракты на основе блокчейна [3], [4], [5] применяют языки сценариев с заполнением, чтобы достичь сложных функциональных возможностей [6] и выполнить предопределенную логику посредством репликации перехода штата по сравнению с алгоритмами консенсуса для реализации окончательной согласованности. Умные контракты позволяют незнакомым и распределенным участникам справедливо обменять без доверия третьих сторон и дополнительно используются для создания единого подхода к разработке децентрализованных приложений (DAPPS [7]). Тем не менее, смарт-контракт на основе блокчейна не хватает конфиденциальности. Информация о состоянии и код инструкции полностью прозрачны [8], [9], [10]. Любые штаты с их изменениями являются общедоступными, и все данные транзакции пользователей и переменные контракта видны внешним наблюдателям. Без конфиденциальности создание расширенных дапсов, которые полагаются на конфиденциальные данные пользователя, становится проблемой [11], [12], [13], [14]. Например, интеллектуальные контракты в Ethereum [2] не могут быть напрямую применяться к аукциону Vickrey [15], [16] или E-Voting Systems [17], [18], где предложение и голосование требуют, чтобы быть скрыты от общественности. Более того, Европейский Союз может быть запрещена DAPPS без охраны конфиденциальности, поскольку они противоречат общему регулированию защиты данных [19], [20]. Таким образом, полная прозрачность интеллектуальных контрактов ограничивает их широкое принятие. Недавно исследователи изучили множество криптографических решений для решения этих проблем, включая использование методов доказательств нулевого знания (ZKP) [21], [22], [12], [23], [24], [25], гомоморфного шифрования (HE) [26] и безопасных вычислений в области многопоставления (MPC) [27]. Однако эти подходы просто применимы к приложениям, требующим простых вычислений.
Хотя были предложены различные протоколы TCSC, недавно выпущенные проекты могут не использовать опыт, изученный из существующих протоколов, такие как повторяющиеся известные ошибки дизайна или применение криптографии небезопасными способами. Например, отсутствие экономических стимулов будет создавать риски безопасности и снизить стабильность протокола. Тем не менее, недавняя подготовленная Hybridchain схемы TCSC [41] повторяет аналогичные ловушки, просто объединив футболку с разрешенной сетью блокчейна, исключая соображения по механизму стимулирования майнера. Повторение подводных камней происходит от двойного размера. Во-первых, в Уилде проекты отличаются от одного к другому, и отсутствует относительно уникальная модель, которая сужает видение разработчиков. Между тем, единая структура оценки отсутствует, в результате чего многие угрозы безопасности будут раскрыты и приводят к значительным потерям от приложений, лежащих в основе выполнения конфиденциальных интеллектуальных контрактов. Эта статья направлена на то, чтобы абстрагировать основу высокого уровня, чтобы просто систематизировать знания о современных схемах TCSC. Мы пытаемся запечатлеть некоторые общие черты между этими проектами в отношении их особенностей, свойств и потенциальной уязвимости безопасности. Мы считаем, что установление критериев оценки для измерения функций и выявления проблем и недостатков существующих протоколов TCSC предложит хорошее руководство для отраслевых сообществ и способствует процветанию DAPPS. Основными вкладами (визуализированное руководство на рис.2) являются:
• Мы предоставляем систематизацию существующих систем TCSC, обусловленных академической работой ив производственных проектах.Основываясь на их эксплуатационных механизмах и способах комбинации, мы исследуем и классифицируем набор типичных протоколов на две основные классификации:Layer-Oneрешение ислой-дварешение.
• Мы устанавливаем единую структуру оценки для конфиденциальных систем смарт -контракта. Мы рассмотрим две части: интеллектуальные контракты, используемые какуслугии базовые поддерживаемые системы блокчейна. Соответственно, структура охватывает три аспекта:Желательные свойстваДля контрактных услуг,модель угрозирассмотрение безопасностиДля базовых систем. В частности, мы обсуждаем два разных типа желательных свойств:Типичные свойстваэто наследуется от традиционных умных контрактов и показаноСвязанные с конфиденциальностью свойства.Затем мы подчеркиваем практические проблемы, подводные камни и средства правовой защиты при разработке блокчейнов с помощью тройников из четырех аспектов (хост/футболка/программаценные бумаги иУправление ключамиуслуги).
• Мы проводим сравнительный анализ существующих протоколов на основе нашей структуры оценки. Мы обсуждаем системы как из ихОбщие дизайны(Системная классификация, модель угроз) иотличительные черты(Проекты, свойства). Общие конструкции показывают нам последовательную идею при переосмыслении системы, в то время как выдающиеся функции выделяют изобретательность каждого дизайна системы, которая отклоняется от других (см. Tab.iii/tab.iv).
• Далее мы даем всестороннее обсуждение текущих проектов и реализаций, в том числе проводящего примера, сравнения между системами Layer-One и Slayer-TWO с точки зрениябезопасностьВэффективностьиЛегко приусадебноеи общие проблемы напубличная проверкаПолем К сожалению, зрелый дизайн все еще не готов к крупномасштабным приложениям. Тем самым мы указываем на исследованиепроблемыВ этой области желание дать представление об сообществах по определению их моделей и обнаружению возможных решений проектирования систем TCSC.
Остальная часть бумаги организована следующим образом. Sec.II дает введение высокого уровня о том, как управлять конфиденциальным интеллектуальным контрактом внутри футболок. Sec.III предоставляет методологию систематизации (Системная классификацияиОценка структура) Системы Layer-One и Layer-TWO анализируются в Sec.IV и Sec.V, соответственно. Обсуждения представлены в Sec.Vi. Проблемы исследований суммированы в Sec.VII. Наконец, Sec.VIII дает заключительные замечания. Дополнительные детали указаны в Приложении A-D.
Эта статья есть
Оригинал