SUAVE — это децентрализованный проект, разработанный Flashbots. Он создает сеть со средой TEE для решения проблем, возникающих в процессе MEV, таких как хранение ключей и взаимное доверие между несколькими сторонами. В то же время добавление TEE в проект SUAVE дает SUAVE больше возможностей помимо решения проблем MEV.

Библиотека кода, связанная с SUAVE

Проект SUAVE основан на расширениях Ethereum, поэтому он по своей сути совместим с EVM. Текущие связанные проекты на GitHub включают: SUAVE-geth, SUAVE-std, SUAVE-examples и т. д.

Среди них SUAVE-geth — это код уровня выполнения, расширенный на основе geth. Он в основном добавляет зашифрованную вычислительную среду на основе geth, а также некоторую предварительную компиляцию в зашифрованной вычислительной среде. Особо стоит упомянуть добавление прекомпиляции для стандартных HTTPS-запросов, которое позволяет разработчикам использовать среду TEE для предоставления пользователям возможности доступа к другим сетям. Кроме того, он содержит серию прекомпиляций, основанных на функциях использования TEE, таких как получение параметров шифрования, хранение информации о шифровании, получение информации о шифровании и т. д., которые формируют инфраструктуру разработки на основе доверенной среды.

SUAVE-std — это проект, созданный для удобства разработчиков, и его можно понимать как библиотеку инструментов разработки. Например, он упаковывает способы использования HTTP-запросов и даже упаковывает на этой основе библиотеку кода для использования ChatGPT. Это избавляет разработчиков от необходимости собирать сообщения запроса ChatGPT и самостоятельно анализировать возвращаемые сообщения ChatGPT. Им нужно только собирать HTTP-запросы. Просто замените свой собственный ключ API при отправке сообщения. Среда безопасности TEE обеспечивает безопасность ключа API, поскольку все делается в среде TEE. Изначально стандартная библиотека ChatGPT по умолчанию использует модель GPT-3.5-turbo, а температура по умолчанию равна 0,7. Теперь добавлен гибкий интерфейс, а также модели можно передавать в качестве параметров.

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

Практика развития SUAVE

Поскольку SUAVE основан на расширениях Ethereum (его исполняемая среда называется MEVM или модифицированная виртуальная машина Ethereum), разработка смарт-контрактов совместима с EVM, а официальные документы разработки представлены в Solidity. Поэтому для разработчиков опыт разработки Solidity вполне полезен. В разработке приложений SUAVE разработку смарт-контрактов можно понимать как разработку Solidity с функцией шифрования вычислений в среде TEE.

Существует несколько ключевых прекомпиляций SUAVE MEVM. Первый — конфиденциальные входы. Этот прекомпилятор принимает параметры шифрования из запросов приложений. Обычно этот параметр представляет собой некоторую конфиденциальную информацию, которую необходимо зашифровать, например закрытые ключи, ключи API и т. д. Его гарантия безопасности должна требовать, чтобы его простой текст мог отображаться только в нем. среде TEE, а при разработке приложений получение этой информации зависит от этого интерфейса для получения простого текста. Процесс передачи полностью зашифрован, безопасен и надежен. Принцип мы обсудим позже. Второй — конфиденциальное хранилище, которое используется для хранения частной информации. Когда мы получаем личную информацию из параметров, она часто не требуется в этот момент для участия в расчетах, поэтому она сохраняется для последующего использования. Третий — конфиденциальный. Этот интерфейс используется при запросе открытого текста данных из контекста TEE, когда для участия в вычислениях требуется конфиденциальная информация.

Безопасное хранение частной информации SUAVE позволяет разработчикам реализовать такой сценарий: «Пользователь загружает закрытый ключ, а затем третья сторона выполняет бизнес-расчеты. Когда условия выполняются, третья сторона может напрямую использовать закрытый ключ пользователя для подписи. Таким образом, третья сторона может использовать закрытый ключ пользователя для подписи в соответствии с определенными правилами, но третья сторона никогда не сможет получить простой текст закрытого ключа».

SUAVE использует HTTPS-запросы для межсетевых операций. В наборе инструментов есть библиотека под названием «шлюз» для прямого чтения межцепочной информации. Ее суть заключается в том, что пользователь устанавливает узел RPC определенной цепочки. Чаще всего пользователь загружает информацию о ключах API, таких как Infura, Etherscan и т. д. ., а затем, когда вам нужно позвонить, просто используйте HTTP-запрос к соответствующему узлу. Когда необходимо записать информацию по цепочкам, в наборе инструментов есть пакет транзакций, который может помочь разработчикам кодировать сообщения, такие как EIP1559, и, наконец, транслировать транзакцию через интерфейс eth_sendRawTransaction.

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

Особенности SUAVE

Конечным состоянием SUAVE является цепочка, которую мы называем цепочкой SUAVE. Мы можем рассматривать цепочку SUAVE как цепочку, реализующую MEVM. Поскольку это EVM-совместимый блокчейн, мы также можем создавать на SUAVE такие активы, как ERC20 и ERC721, и его операции в цепочке ничем не отличаются от операций серии EVM. Но его уникальность заключается в добавлении операций вне цепочки, таких как отправка транзакций на узлы в других цепочках. Результаты операций вне цепочки или условия использования могут храниться в цепочке SUAVE, и сохраненные результаты гарантируются консенсусом. Это обеспечивает согласованность между вычислениями вне сети и статусом в сети. Например, разработчики могут написать смарт-контракт для записи некоторых условий в цепочке (которые также можно изменить). Когда осуществляется доступ к определенному узлу сети цепочки и возвращаемый результат соответствует требованиям, будет произведена предустановленная передача определенного актива ERC20. выполненный.

Вышеупомянутое — это все функции, предоставляемые доверенными вычислениями вне сети SUAVE. Мы знаем, что SUAVE был разработан командой Flashbots, а SUAVE рассматривается командой Flashbots как «будущее MEV», поэтому обработка пакетных транзакций определенно необходима. Основанная на цепочке SUAVE в доверенной среде, принципы, связанные с MEV, определенно необходимы. очень просто: транзакции сборки Bundle отправляются на ретрансляционные узлы Flashbots. Приватные ключи могут храниться конфиденциально, даже в коде, что открывает огромный потенциал для использования. Например, в дополнение к вознаграждению за газ в целевой цепочке строитель также может получить определенные цифровые активы в цепочке SUAVE. На рынке MEV можно гибко определять услуги, обеспечивая при этом безопасность частной информации, чего MEV в настоящее время сделать не может (в настоящее время могут быть достигнуты только традиционные внесетевые гарантии, основанные на доверии, контракте, доброй воле и т. д.).

Инструменты и инфраструктура разработки SUAVE

Для разработчиков, помимо разработки смарт-контрактов в сети, важной частью разработки dapp также являются наборы инструментов, такие как ether.js, для фронтенд-разработки. При разработке приложений SUAVE, поскольку цепочка SUAVE модифицирована на основе EVM, также можно использовать такие инструменты, как ether.js и web3.js. Эти инструменты взаимодействуют со смарт-контрактами в цепочке SUAVE не иначе, чем другие EVM-совместимые цепочки. Но вызывать можно только функции в неконфиденциальной среде. Смарт-контракт цепочки SUAVE делится на операции внутри цепочки (имеются в виду цепочки SUAVE) и операции вне цепочки (кросс-чейновые операции также включены в эту категорию). Операции вне цепочки фактически относятся к вычислениям конфиденциальной среды. Для вычислений в конфиденциальной среде команда Flashbots предоставляет SDK на двух языках (Go и TypeScript). Использование описано в документации SUAVE. При отправке частной вычислительной транзакции (команда Flashbots называет ее конфиденциальным запросом вычислений) на узел SUAVE вы можете ввести конфиденциальные входные данные, которые являются частными параметрами. В течение всего процесса передачи окончательный открытый текст этого параметра будет отображаться только в файле. ТЭЭ-среда.

Наконец, когда дело доходит до развертывания смарт-контрактов, имя тестовой сети цепочки SUAVE называется Regil, но оно было обновлено и называется Toliman. Метод развертывания подробно описан в документе SUAVE. Его метод развертывания, метод взаимодействия после развертывания и т. д. ничем не отличаются от развертывания смарт-контракта Ethereum.

Чайник

После развертывания смарт-контракта его фактическая работа отличается от работы Ethereum. Основной исполнительный блок SUAVE называется Kettle. Kettle — это операционная среда TEE компании SUAVE (она включает в себя узел MEVM и хранилище конфиденциальных данных). После того как разработчик пишет и развертывает смарт-контракт, пользователь отправляет запрос на конфиденциальные вычисления (далее — CCR). Когда смарт-контракту необходимо использовать конфиденциальные вычисления, его фактически запускает Kettle.

Структурная схема Чайника выглядит следующим образом:

Мы видим, что разработчики используют язык Solidity для разработки и развертывания приложений. После отправки окончательного запроса в Kettle он весь обрабатывается MEVM. Помимо функции geth, MEVM также добавляет к нему некоторую прекомпиляцию, которая может сохранять и извлекать данные. личные данные, подождите. Кроме того, он также обрабатывает (включая изменение и получение) статус цепочки SUAVE.

Основная задача Kettle — получать и обрабатывать частные вычисления, а также хранить и извлекать частные данные. Если взять в качестве примера хранение определенных личных данных, то весь процесс выглядит следующим образом: пользовательский интерфейс использует SDK или инструмент suave geth для инициирования запроса CCR к смарт-контракту в цепочке SUAVE. SDK или инструмент suave geth. будет использовать ключ данных (симметричный ключ) для данных. Этот ключ данных будет отображаться только в среде Kettle, а узел RPC SUAVE будет видеть только зашифрованный текст. Существует ли связь «один к одному» между чайником и узлами, в документации SUAVE не указано. Аналогичным образом, в документе не представлены подробные принципы работы самого Kettle, узлов и обмена ключами. Однако, основываясь на известном процессе шифрования и дешифрования, у разработчиков есть основания полагать, что защита данных может быть гарантирована между пользовательским интерфейсом и внутренней средой TEE Kettle.

Частные данные Kettle будут храниться в хранилище конфиденциальных данных. Когда разработчики разрабатывают смарт-контракты, они будут указывать посетителей и модификаторы данных. Kettle опубликует их через свою транспортную сеть. Если этот контракт указан для доступа, последующие запросы CCR будут. также необходимо отправить на этот Kettle, поскольку хранилище данных Kettle не обновляется глобально. После того, как разработчик развернет смарт-контракт и пользователь получит доступ к соответствующему Kettle (в запросе CCR есть параметр, необходимо указать адрес Kettle), можно будет получить доступ к его приватным данным. Когда пользователь отправляет CCR и запрашивает личные данные в смарт-контракте, для извлечения используются идентификатор и ключ, созданные при хранении соответствующих данных. Другими словами, доступ к частным данным осуществляется и используется через значение ключа.

HTTP-запросы и т. д. также обрабатываются Kettle. Очевидно, что это задания вне цепочки SUAVE, а это означает, что эти задания выполняются одним узлом. Хотя SUAVE — это цепочка, ее свойства блокчейна слабы. Когда Kettle запускает запрос CCR, на многих узлах не будет выполнения. затем проверьте. Причина очень проста. Доступ к ресурсам вне цепочки определенно не является идемпотентным. Итак, это задачи вне цепочки SUAVE, и результаты фактически зависят от узла. Поэтому разработчикам следует обращать внимание на адрес Kettle при развертывании (с этой точки зрения Kettle можно рассматривать как специальный смарт-контракт), а последующие пользовательские CCR-запросы должны нести соответствующий адрес Kettle.

Кроме того, есть еще одна проблема, заслуживающая внимания разработчиков. В текущей тестовой сети Toliman не гарантируется работа чайника в среде TEE. Поэтому при разработке смарт-контрактов в тестовой сети вы должны уделять внимание защите частных данных и предотвращению утечки действительно частных данных.

Подвести итог

Внедряя среду TEE, цепочка SUAVE предоставляет мощные возможности для разработки приложений, а потенциальные сценарии ее применения многочисленны. Его простое и удобное межсетевое управление также дает достаточно места для воображения в дизайне Dapp.

Конструкция Kettle цепочки SUAVE способна обрабатывать ресурсы вне цепочки, что приводит к проблемам проверки и консенсуса. Нечестный чайник разрушительен для Интернета. Как гарантировать, что Кеттл не совершает зла, или чтобы зло можно было наказать, или чтобы цена зла была достаточно высокой — все это проблемы, которые необходимо решить. Разработчики все еще ждут, чтобы увидеть, сможет ли модель PoA, используемая в консенсусе цепочки SUAVE, выдержать практические соображения.