Как надежные среды выполнения масштабируются, частные интеллектуальные контракты

Таблица ссылок

Аннотация и I. Введение

II Тур молнии

Iii. Методология систематизации

IV Раствор слоя-один

V. Slayer-Two Solution

VI Дискуссия

VII. Исследовательские проблемы

VIII. Заключительные замечания и ссылки

Приложение А.Ключевые управления

Приложение B.Анонимность и конфиденциальность

Приложение C.Фон

Приложение D.Протокол голосования на основе TCSC

V. Slayer-Two Solution

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

Система модели.В решении общего уровня-двора блокчейн используется в качестве уровня разрешения споров. Умный контракт выполняется за пределами блокчейна, заставляя Tees выступать в качестве агента между пользователями и системами блокчейна. Предположим, что пользователь стремится использовать частный контракт. Сначала ей нужно скомпилировать исходный код контракта, подтолкнуть бинарные коды в TEE, а затем загрузить результаты выполнения в публичную книгу. Как показано на рис. 4, мы извлекаем общий поток данных следующим образом. Пользователь отправляет зашифрованные входные данные в узел с тройником. Затем тройник расшифровывает входные данные и выполняет контракт. После этого результаты зашифрованного выполнения отправляются на платформу блокчейна для проверки и хранения. Наконец, пользователь получает и расшифровывает результаты, подтвержденные блокчейном.

А. Оценка собственности

Содержание конфиденциальности.АКонфиденциальное исполнениеявляется важной собственностью. В системах-уровнях, таких как [46], [68], [69], контрактные вычисления работают внутри анклавах Intel SGX, в то время как TZ4Fabric [44] переносит выполнения контрактов в доверенную зону ARM. Поскольку процесс трансляции штата контракт происходит внутри футболок, любые промежуточные государства остаются невидимыми снаружи. Между тем, для достижения полной безопасности жизненного цикла для интеллектуального контракта, вход, отправленный в TEE, и вывод, возвращаемый из этой футболки, также должны быть зашифрованы. Например, в Shadoweth [68], PDOS [46], Phala [69] и Hybridchain [41] аргументы вызовов контракта ширируются с помощью публичного ключа TEE. Их можно только расшифровать только в анклаве. Кроме того, перед передачей результатов выполнения в блокчейн (или пользователей) промежуточные (или конечные) состояния в анклаве зашифрованы. Некоторые варианты также улучшают сохраняющие конфиденциальность свойства от других аспектов. В Phala [69] только уполномоченные запросы договора будут отвечать. Исходные коды смарт -контракта в Shadoweth [68] скрыты во время процедур развертывания и синхронизации. Это еще больше снижает возможность утечки данных в последующих казнях контрактов. Учитывая, что фиксированный адрес может разоблачить пользователя, который применил контракт, PDOS [46] также позволяет пользователю использовать адреса псевдонима для отправки транзакции (включая выходы TEE) в блокчейн.

Блокчейн внутренняя особенность.Shadoweth [68] и TaxaS [70] представляют внешнюю распределенную услугу для управления контрактами, достигая свойствНепостояемость кода, высокая доступностьиДецентрализованное исполнениеПолем Между тем, системы-слоя-второго уровня удовлетворяют согласованности состояния по причинам, которые зашифрованные состояния контрактов в различных узлах блокчейна в конечном итоге будут последовательными при достижении успешного соглашения. Интуитивно, контракты, развернутые в системах-уровнях, должны сохранять функции, приведенные оригинальными блокчейнами. Тем не менее, некоторые фундаментальные свойства теряются при использовании решений-уровня. Например, большинство систем двух слоев теряют совместимость с контрактами, поскольку каждый контракт выполняется на разных машинах. Среди всех оцениваемых систем только Phala [69] определяет эту проблему и предлагает архитектуру сегрегации командных запросов для обеспечения определенной совместимости. Кроме того, публичная проверка является важной собственностью для блокчейна, поскольку она позволяет каждому вызову контракта, а выполнение контракта поддается публично. К сожалению, контракты выполняются в тройниках, так что выходы зашифрованы. Чтобы проверить, выполнила ли TEE контракты после загруженных спецификаций контракта, является нетривиальной задачей.

Б. Оценка системы

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

Tee Host Security.Несколько решений-слоев-двух решений принимают механизмы стимулирования или наказания, чтобы поощрять хозяева матков предоставлять стабильную и безопасную среду для выполнения конфиденциальных контрактов. Например, Fastkitten [43] и Erdstall [75], [76] предлагаютштрафтранзакции, в которых хозяин будет наказан, если его злонамеренное поведение будет выявлено. В частности, если исполнение TEE прервано, хост будет взиматься в соответствии с предыдущими депозитами. В таксонах [70] каждый узел может идентифицировать любые неисправные узлы с надежными доказательствами для выполнения дальнейшего экономического наказания. На другом маршруте хосты Tee в Phala [69] будут оплачены, предоставляя их вычислительные ресурсы пользователям. Точно так же вознаграждение в Shadoweth [68] будет передано хостам, которые выполняют частные контракты. Эти механизмы могут эффективно предотвратить злонамеренные хозяева из экономического аспекта. Тем не менее, они бессильны против внешних угроз. Противник может напрямую прекратить хост -тройник в любое время. Хуже того, TEE предоставляет пользователям открытый интерфейс, который уязвим для DOS [77] или одноточечной атаки. Чтобы преодолеть такие проблемы и достичь устойчивости к разлому, предлагаются различные методы. Fastkitten обеспечивает низкоуровневую устойчивость к разлому путем периодической экономии зашифрованного снимка текущих состояний в анклавах. Если анклав не удается, хост TEE может создать создание нового анклава и перезапустить вычисление, начиная с зашифрованного снимка. Аналогичным образом, таксоны [70] хранят файл сеанса для поддержания и восстановления запросов пользователя. Тем не менее, злонамеренный атакующий может напрямую прекратить хост TEE, и Fastkitten не терпит таких неудач хоста. Другой технический маршрут - поддерживать безопасную сеть. Shadoweth поддерживает группу узлов TEE, чтобы обеспечить последовательность с помощью алгоритма, подобного Paxos [78]. Таксоны принимают вычислительные узлы с поддержкой TEE, работающие в результате алгоритма, полученного из PBFT [79]. Любой узел в сети несет такую ​​же ответственность за частное выполнение смарт -контрактов и результаты выполнения передачи в блокчейн. Тем не менее, это приносит дополнительные проблемы аутентификации. Хост футболки должен быть тщательно аутентифицирован, чтобы обеспечить ее возможность TEE при присоединении к внешней сети.

Между тем, Systems PDOS [46], Phala [69], Ekiden [42] и Commitee [73] вводят расходуемое и взаимозаменяемое решение. Тройники не имеют состояния: любая конкретная футболка может быть легко заменена после того, как он столкнулся или завершит свою задачу. К сожалению, эти решения вместе с новыми проблемами. Во -первых, даже если тройники изменяются, обнаружение скомпрометированной футболки все еще трудно. Например, PDO могут повторно рассказать метод несколько раз для проверки. Учитывая одинаковые входные параметры для разных футболок, считается, что тройники работают надежно, только если их результаты соответствуют. Затем выходы анклавов разрешаются совершать блокчейн. Commitee принимаетМастер/Резервное копированиеМашины хоста. Если хозяин Master Tee оказывается вредоносным, резервный хозяин Тем не менее, эта модель увеличивает интерфейс атаки и делает всю систему уязвимой. Во -вторых, хосты футболисты без сохранения состояния. Это означает, что для обеспечения восстановления исключительного исполнения, любое постоянное состояние должно храниться в блокчейне или доверенной третьей стороне (TTP). Тем не менее, для не определенной системы блокчейна, такой как Ethereum (POS-версия) [2], проверка того, был ли элемент хранится на блокчейне, является нетривиальной задачей. Между тем, хранение данных в TTPS может привести к сбое с одной точкой, что противоречит реальному намерению блокчейна.

Сигона.Контракт работает внутри футболки и сильно зависит от службы удаленной аттестации. Отсталиваемые SGX системы блокчейна, включая PDO [46], Fastkitten [43], Shadoweth [68], Phala [69] и Ekiden [42], предполагают, что служба аттестации Intel (IAS) доверяет. IAS может правильно и полностью сообщить, является ли определенный выход с криптографическим материалом (цитировать[80]) производится аппаратным обеспечением с поддержкой SGX. Тем не менее, IAS может быть скомпрометирована, создавая риск для этих архитектур. Скомпрометированная или угнанная служба аттестации может злонамеренно сообщать об аттестации с неправильным криптографическим материалом, который не принадлежит соответствующему оборудованию для тройников, нарушая обещанную безопасность. Между тем, централизованная служба может быть разбита, что приведет к утечке частных штатов. К сожалению, ни одна из схем-слоев-двоих не рассматривает эти риски в проектах или реализациях.

Как уже говорилось, текущие реализации TEE имеют ограничения памяти для конфиденциальных выполнений. Если использование памяти превышает порог, оно может столкнуться с значительными проблемами производительности и безопасности [81]. Hybridchain [41] оптимизирует хранилище, сохраняя записи транзакций за пределами Intel SGX. Между тем, TZ4Fabric [44] сводит к минимуму TCB, избегая всех выполнений внутри TEE. Однако эти подходы увеличивают сложность реализации. Хорошо известный факт заключается в том, что футболка уязвима для физических уязвимостей [57]. К сожалению, очень немногие решения-решетки обеспечивают корректирующие меры для снижения риска атаки.

See Program Security.Плохо написанный договор может отклониться от назначенных функций и еще больше утечь секретную информацию. Эта часть обсуждает потенциальные ловушки и средства правовой защиты при развертывании контрактов.

В оригинальных системах интеллектуальных контрактов газовый механизм является мощным инструментом для предотвращенияБесконечная петляатаки [2]. Поскольку системы Layertwo выполняют смарт -контракт за пределами блокчейна, необходимо учитывать аналогичный механизм. Fastkitten [43] и Hybridchain [41] защищают от таких атак, используятайм -аутмеханизм. Ограничения в первую очередь определяются на максимальном количестве шагов выполнения, которые позволяют работать внутри футболки за раунд. Затем TEE контролирует операции с интеллектуальными контрактами. Если количество шагов выполнения превышает предопределенный порог, анклав прекратит выполнение. Shadoweth [68] объединяет механизм тайм -аута свознаграждениемеханизм. Подобно газовому механизму в Ethereum [2], хосты TEE по -прежнему могут получить вознаграждение, даже если контракт выходит после тайм -аута, поскольку они обеспечивают достаточную вычислительную мощность. Эти механизмы эффективно защищают от бесконечных петлей и отказа в услуге (DOS), запущенных внешними злоумышленниками.

Сам футболка не имеет самосознания входных данных, поскольку он не может различить, какое состояние является свежим. Отсутствие аутентификации входных данных делает систему уязвимой для атаки с откатом [82], [59]. Злоусознательный пользователь может много раз попытаться вызвать конфиденциальный контракт, чтобы искать просочившуюся секретную информацию. Аутентификация личности пользователя полезна для предотвращения этой атаки. Тем не менее, ни одно слое-два раствора не обеспечивает эти средства для этих потенциальных ловушек. С другой стороны, вход TEE может исходить от неэнергинистической системы блокчейна [83], [84], в которой решающий решающий вход был подтвержден, является сложным. Fastkitten [43] и Commitee [73] смягчите эту проблему, используяКонтрольная точкамеханизм. Что касается конфликтов вывода TEE, Ekiden [42] использует вероятностное протокол подтверждения публикации, чтобы избежать неоднозначного ввода.

После вызова частного контракта выходы, возвращаемые из Tees, загружаются в цепочке для окончательного подтверждения. Но злонамеренный тройник может отправить исключительный результат в блокчейн. Хуже того, два хоста могут одновременно публиковать различные обновления в отношении одного и того же контракта. Чтобы предотвратить такие злонамеренные публикации и уклоняться от конфликтов, PDOS [46] зависит от координации и журнала COMIT (CCL) для управления синхронизацией при выполнении взаимодействующих контрактов и позволяет владельцу контракта принять решение о выборе анклава для казней контрактов, что эффективно избегает конфликтов. PHALA [69] принимает архитектуру сегрегации командных запросов по поиску советов, чтобы масштабировать и избежать конфликтов, в которых операции записи регистрируются в качестве событий, и операции чтения могут служить текущим представлением государств. Опять же, эти решения противоречат свойству децентрализации. Экиден [42] и Shadeeth [68] полагаются на блокчейн, чтобы разрешить конфликты, возникающие в результате параллелизма. В частности, Shadeeth [68] требует, чтобы работник указал номер версии с меткой времени при нажатии данных в блокчейн. Сначала даже шахтеры принимают разные ответы, в конечном итоге они достигнут соглашения, сравнивая номер версии и временную метку с помощью консенсусной процедуры. Тем не менее, такой подход неэффективен, особенно в не определенных системах блокчейна.

Tees Key Management.PDOS [46] использует услугу предоставления ключей для распределения частных ключей. Недостаток очевиден: скомпрометированная служба предоставления может сделать всю систему провалиться. Чтобы повысить надежность частного ключа, Экиден [42] разрабатывает протокол распределенного ключа (DKG) [85] с использованием схемы секретного совместного использования [86]. Даже если один ключевой менеджер скомпрометирован, противник не может получить весь ключ. Тем не менее, это решение не полностью решает проблему утечки ключей. Последние ключи собираются и воспроизводятся среди всех концов. Если противник ставит компромисс конечную тему, разоблачение всего состояния контракта становится тривиальной задачей. Ключевая технология ротации, принятая Экиден [42], Fastkitten [43], Phala [69] частично решает вышеупомянутую проблему, предоставляя краткосрочный ключ в каждую эпоху. Противник не может испортить будущее или предыдущее совершенное состояние, что сводит к минимуму возможность ключевого воздействия злоумышленников и дополнительно помогает системе-слое-второго уровня достичь прямой секретности. Кроме того, проекты площади-второго уровня, такие как Commitee [73], смягчают эти ключевые вопросы, предоставляя каждый футболок на секретный ключ. Даже если бы личный ключ определенного футбола был украден, это только повлияет на умный контракт, работающий на этой компрометированной футболке. Кроме того, сеть Phala [69] оснащает каждый контракт с асимметричным ключом, называемымКонтрактный ключ, что также повышает ключевую безопасность в определенной степени.

C. Плюсы и минусы

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

Интегрируйте с существующими платформами общего блокчейна. К сожалению, этот метод также ставит проблемы безопасности и функциональности при делегировании задачи управления контрактами на внешний тройник.

Во-первых, решение-решении-слоя, комплексное управление данными контракта. Контракты, которые развернуты за пределами блокчейна, требуют внешнего выполнения/хранилища. Злоусовечник, сопровождающий хранения, может отказаться от предоставления услуги, в то время как вредоносный хост может прервать выполнения футболок, прекратить анклавы или сообщения о задержке/сбросе. Даже честный хозяин может случайно потерять штаты в силовом цикле. Чтобы решить проблему централизации и переносить неудачи хозяина, предлагаются многие контрмеры, такие как сеть TEE, футболки без гражданства и механизмы наказания. Тем не менее, эти решения не являются легкими, что неизбежно усложняет систему и трудно реализовать на практике.

Во-вторых, раствор-слой-дворник увеличивает поверхность атаки и, таким образом, становится уязвимым для атаки с обратной связи. Существует высокая вероятность того, что узел противника может отменить транзакции, в которых временные вилки, представляющие противоречивые представления блокчейна, разрешены в системах блокчейна с вероятностным консенсусом (например, военнослужащим). Поскольку тройники не дают никаких гарантий на проверку входных данных; Они не могут различить, является ли входное состояние свежим или нет. Злоумышленник может предложить устаревшие штаты, чтобы возобновить исполнение футболки. Это позволяет атаковать откат против рандомизированных программ Tees. Хуже того, подключение этих лазейков нуждается в больших усилиях.