Whitepaper проекта Sui
Переведено NM Insight Оригинальный источник
Платформа смарт-контрактов
Команда MystenLabs [email protected]
Sui — это децентрализованная платформа смарт-контрактов без разрешений, ориентированная на управление активами с низкой задержкой. Она использует язык программирования Move для определения активов как объектов, которыми может владеть адрес. Программы Move определяют операции над этими типизированными объектами, включая пользовательские правила для их создания, передачи этих активов новым владельцам, а также операции, которые мутируют активы.
Sui поддерживается бессрочным набором авторитетов, которые играют роль, аналогичную валидаторам или майнерам в других системах блокчейн. Для обеспечения безопасности общих операций над активами используется византийский согласованный протокол трансляции между органами власти, обеспечивающий меньшую задержку и лучшую масштабируемость по сравнению с византийским соглашением. Он полагается на византийское соглашение только для обеспечения безопасности общих объектов. А также операции управления и контрольные точки, выполняемые вне критического латентного пути. Выполнение смартконтрактов также естественным образом распараллеливается, когда это возможно. Sui поддерживает легкие клиенты, которые могут аутентифицировать чтение, а также полные клиенты, которые могут проверять все переходы на целостность. Эти средства позволяют создавать мосты с минимальным уровнем доверия к другим блокчейнам.
Собственный актив SUI используется для оплаты газа для всех операций. Он также используется его владельцами для делегирования доли властям для управления Суи в течение эпох, и периодически власти реконфигурируются в соответствии с делегированной им долей. Использованный газ распределяется между органами власти и их делегатами в соответствии с их долей и вкладом в работу Sui.
Данный документ состоит из двух частей: в Разделе 2 описывается модель программирования Sui с использованием языка Move, а в Разд. 4 описывает работу децентрализованной системы без разрешений, которая обеспечивает безопасность, быстродействие и производительность Sui.
2. ПРОГРАММИРОВАНИЕ СМАРТКОНТРАКТОВ SUI
Смарт-контракты Sui написаны на языке Move[4]. Move безопасен и выразителен, а его система типов и модель данных естественным образом поддерживают параллельные стратегии соглашения/исполнения, которые делают Sui масштабируемой. Move — это язык программирования с открытым исходным кодом для создания смарт-контрактов, изначально разработанный в Facebook для блокчейна Diem. Этот язык не зависит от платформы, и помимо того, что он был принят в Sui, он набирает популярность на других платформах (например, 0L, StarCoin).
В этом разделе мы рассмотрим основные возможности языка Move и объясним, как он используется для создания и управления активами на Sui. Более подробное объяснение возможностей Move можно найти в книге “Язык программирования Move “1 , более подробное содержание Move, специфичное для Sui, можно найти на портале разработчиков Sui2 , а более формальное описание Move в контексте Sui можно найти в разделе 3.
Глобальное состояние Sui включает пул программируемых объектов, созданных и управляемых пакетами Move, которые представляют собой коллекции модулей Move (подробнее см. раздел 2.1.1), содержащих функции и типы Move. Сами пакеты Move также являются объектами. Таким образом, объекты Sui можно разделить на две категории:
• Значения данных структур: Типизированные данные, управляемые модулями Move. Каждый объект представляет собой значение struct с полями, которые могут содержать примитивные типы (например, целые числа, адреса), другие объекты и необъектные структуры.
• Значения кода пакета: набор связанных модулей байткода Move, опубликованных как атомарная единица. Каждый модуль в пакете может зависеть как от других модулей в этом пакете, так и от модулей в ранее опубликованных пакетах.
Объекты могут кодировать активы (например, сменные или несменные токены), возможности, дающие право вызывать определенные функции или создавать другие объекты, “smart contracts”, управляющие другими активами, и так далее — все зависит от программиста. Код Move для объявления пользовательского типа объекта Sui выглядит следующим образом:
id: VersionedID, // globally unique ID and version
f: u64 // objects can have primitive fields
Все структуры, представляющие объекты Sui (но не все значения структуры Move), должны иметь поле id и способность key3, указывающие на то, что значение может храниться в глобальном пуле объектов Sui.
Программа Move организована как набор модулей, каждый из которых состоит из списка объявлений структур и функций. Модуль может импортировать типы struct из других модулей и вызывать функции, объявленные другими модулями.
Значения, объявленные в одном модуле Move, могут перетекать в другой — например, модуль OtherObj в приведенном выше примере может быть определен в другом модуле, а не в модуле, определяющем Obj. Это отличается от большинства языков смарт-контрактов, которые позволяют только неструктурированным байтам перетекать через границы контракта. Однако Move способен поддерживать это, поскольку он предоставляет функции инкапсуляции, помогающие программистам писать надежный безопасный [14] код. В частности, система типов Move гарантирует, что такой тип, как Obj выше, может быть создан, уничтожен, скопирован, прочитан и записан только функциями внутри модуля, который объявляет этот тип. Это позволяет модулю обеспечить строгие инварианты для своих объявленных типов, которые сохраняются даже при пересечении границ доверия смарт-контракта.
2.1.2 Транзакции и точки входа.
Глобальный пул объектов обновляется с помощью транзакций, которые могут создавать, уничтожать, читать и записывать объекты. Транзакция должна принимать на вход каждый существующий объект, с которым она хочет работать. Кроме того, транзакция должна включать версионный идентификатор объекта пакета, имя модуля и функции внутри этого пакета, а также аргументы функции (включая входные объекты). Например, для вызова функции:
o1: Obj, o2: &mut Obj, o3: &Obj, x: u64, ctx: &mut TxContext
транзакция должна предоставить идентификаторы для трех отдельных объектов, тип которых Obj, и целое число для привязки к x. TxContext — это специальный параметр, заполняемый средой выполнения, который содержит адрес отправителя и информацию, необходимую для создания новых объектов. Входы в точку входа (и, в более общем случае, в любую функцию Move) могут передаваться с различными разрешениями на изменяемость, закодированными в типе. Вход Obj может быть прочитан, записан, передан или уничтожен. Вход & mut Obj может быть только прочитан или записан, а &Obj может быть только прочитан. Отправитель транзакции должен быть авторизован для использования каждого из входных объектов с указанными разрешениями на изменяемость — более подробно см. раздел 4.4
2.1.3 Создание и передача объектов. Программисты могут создавать объекты, используя TxContext, переданный в точку входа, чтобы сгенерировать свежий ID для объекта:
public fun create_then_transfer(
f: u64, g: OtherObj, o1: Obj, ctx: &mut TxContext
) {
let o2 = Obj { id: TxContext::fresh_id(ctx), f, g };
Transfer::transfer(o1, TxContext:sender());
Transfer::transfer(o2, TxContext:sender());
}
Этот код принимает на вход два объекта типа OtherObj и Obj, использует первый из них и сгенерированный ID для создания нового Obj, а затем передает оба объекта Obj отправителю транзакции. После передачи объекта он попадает в глобальный пул объектов и не может быть доступен коду в оставшейся части транзакции. Модуль Transfer является частью стандартной библиотеки Sui, которая включает функции для передачи объектов на пользовательские адреса и на другие объекты. Отметим, что если в коде программиста не будет включен один из вызовов передачи, этот код будет отвергнут системой типов Move. Move обеспечивает безопасность ресурсов [5], чтобы гарантировать, что объекты не могут быть созданы без разрешения, скопированы или случайно уничтожены. Другим примером безопасности ресурсов может быть попытка дважды передать один и тот же объект, которая также будет отклонена системой типов Move.
3. МОДЕЛЬ ПРОГРАММИРОВАНИЯ SUI
В этом разделе мы расширим неформальное описание модели программирования Sui из раздела 2, представив подробные семан- тические определения. В предыдущем разделе были приведены примеры исходного кода Move; здесь мы определяем структуру байткода Move. Разработчики пишут, тестируют и формально проверяют [10, 16] исходный код Move локально, затем компилируют его в байткод Move перед публикацией в блокчейн. Любой байткод Move, публикуемый на блокчейне, должен пройти через верификатор байткода[4, 5], чтобы убедиться, что он удовлетворяет ключевым свойствам, таким как безопасность типов, памяти и ресурсов.
Как упоминалось в разделе 2, Move — это платформо-независимый язык, который может быть адаптирован к специфическим потребностям различных систем без форка основного языка. В следующем описании мы определяем оба понятия из основного языка Move и специфические для Sui функции, расширяющие основной язык Move (обозначены оранжевым текстом).
Код Move организован в модули, структура которых определена в таблице 1. Модуль состоит из коллекции объявлений именованных структур и коллекции объявлений именованных функций (примеры этих объявлений приведены в разделе 2.1). Модуль также содержит объявление специальной функции, служащей инициализатором модуля. Эта функция вызывается ровно один раз в момент публикации модуля на цепочке.
Объявление struct представляет собой набор именованных полей, где имя поля сопоставлено с хранимым типом. Его объявление также включает необязательный список способностей (см. раздел 2 для описания хранимых типов и способностей). Объявление struct может также включать список общих параметров с ограничениями на способности, в этом случае мы называем его объявлением generic struct, например struct Wrapper{ t: T }. Общий параметр представляет собой тип, который будет использоваться при объявлении полей struct — он неизвестен на момент объявления struct, а конкретный тип будет определен при инстанцировании struct (т.е. при создании значения struct)
Объявление функции включает список типов параметров, список возвращаемых типов и список инструкций, образующих тело функции. Объявление функции может также включать список общих параметров с ограничениями на способности, в этом случае мы называем его объявлением общей функции, например, fun unwrap(p: Wrapper){}. Аналогично объявлениям struct, общий параметр представляет собой тип, неизвестный во время объявления функции, но который, тем не менее, никогда не используется при объявлении параметров функции, возвращаемых значений и тела функции (конкретный тип задается при вызове функции).
Инструкции, которые могут появляться в теле функции, включают все двоичные инструкции Move, за исключением инструкций глобального хранения (например, move_to, move_from, borrow_global). Полный список инструкций ядра Move и их семантика приведены в [14]. В Sui постоянное хранение поддерживается через глобальный пул объектов Sui, а не через глобальное хранилище на основе учетных записей, как в ядре Move.
Существует четыре операции над объектами, специфичные для Sui. Каждая из этих операций изменяет метаданные владения объекта (см. раздел 3.3) и возвращает его в глобальный пул объектов. Проще говоря, объект Sui может быть передан на адрес конечного пользователя Sui. Объект также может быть передан другому родительскому объекту — эта операция требует, чтобы вызывающая сторона предоставила изменяемую ссылку на родительский объект в дополнение к дочернему объекту. Объект может быть разделяемым, тогда его может читать/писать любой человек в системе Sui. Наконец, объект может быть неизменяемо общим, тогда его может читать любой человек в системе Sui, но не писать никто.
Возможность различать разные виды собственности — уникальная особенность Sui. В других известных нам блокчейн-платформах каждый контракт и объект является общим. Как мы объясним в разделе 4, Sui использует эту информацию для параллельного выполнения транзакций (для всех транзакций) и параллельного согласования (для транзакций с объектами без общей мутабельности).
Программа Move манипулирует как данными, хранящимися в глобальном пуле объектов Sui, так и переходными данными, созданными при выполнении программы Move. И объекты, и переходные данные являются значениями Move на уровне языка. Однако не все значения созданы одинаковыми — они могут иметь разные свойства и разную структуру, предписанную их типами.
Типы, используемые в Move, определены в таблице 2. Move поддерживает многие из тех же примитивных типов, которые используются в других языках программирования, например, булевы типы или беззнаковые целые типы различных размеров. Кроме того, ядро Move имеет тип адреса, представляющий конечного пользователя в системе, который также используется для идентификации отправителя транзакции и (в Sui) владельца объекта. Наконец, Sui определяет тип id, представляющий личность объекта Sui — подробности см. в разделе 3.3. Тип struct описывает экземпляр (т.е. значение) структуры, де-кларированной в данном модуле (см. раздел 3.1 для информации о декларациях структур).
Тип struct type, представляющий собой родовое объявление struct (т.е. родовой тип struct), включает список хранимых типов — этот список является аналогом родового списка параметров в объявлении struct. Хранимый тип может быть как конкретным типом (примитив или struct), так и общим типом. Мы называем такие типы хранимыми, потому что они могут появляться в качестве полей структур и в объектах, хранящихся из общего параметра вложенной структуры или объявления функции - такой тип может использоваться для объявления полей структуры, параметров функции и т.д. Структурно общий тип представляет собой целочисленный индекс (определенный как N в таблице 5) в списке общих параметров в объемлющей структуре или объявлении функции.
На цепочке, в то время как ссылочные типы не могут. Например, тип Wrapper<u64> struct представляет собой общий тип struct параметризованный конкретным (примитивным) хранимым типом u64 - такой тип может быть использован для создания экземпляра struct (т.е. значения). С другой стороны, тот же родовой тип struct может быть параметризован родовым типом (например, struct Parent<T> { w: Wrapper<T> }). От общего параметра вложенной структуры или объявления функции - этот тип может быть использован для объявления полей struct, параметров функций и т.д. Структурно общий тип представляет собой целочисленный индекс (определенный как N в таблице 5) в списке общих параметров в объемлющей структуре или объявлении функции.
Vector type в Move описывает коллекцию однородных значений переменной длины. Вектор Move может содержать только хранимые типы, а также сам является хранимым типом.
Программа Move может работать со значениями напрямую или обращаться к ним косвенно через ссылки. Ссылочный тип включает в себя как хранимый тип, на который ссылаются, так и квалификатор изменяемости, используемый для определения (и принудительного применения) того, может ли значение данного типа быть прочитано и записано (mut) или только прочитано (immut). Следовательно, в самом общем виде тип значения Move (тип в таблице 2) может быть либо хранимым типом, либо ссылочным типом.
Наконец, способности в Move управляют тем, какие действия допустимы для значений данного типа, например, можно ли копировать (дублировать) значение данного типа. Способности ограничивают объявления структур и параметры общих типов. Верификатор байткода Move отвечает за то, что такие важные операции, как копирование, могут быть выполнены только для типов с соответствующей способностью.
3.3 Объекты и право собственности
Каждый объект Sui имеет глобально уникальный идентификатор (ObjID в Таблице 3 ), который служит постоянной идентификацией объекта при его перемещении между владельцами, а также в другие объекты и из них. Этот идентификатор присваивается объекту создающей его транзакцией. Идентификатор объекта создается путем применения хэш -функции, устойчивой к коллизиям, к содержимому текущей транзакции и к счетчику, регистрирующему количество объектов, созданных транзакцией. Транзакция (и, соответственно, ее дайджест) гарантированно уникальна благодаря ограничениям на входные объекты транзакции, как мы объясним далее.
В дополнение к идентификатору каждый объект несет метаданные о своем владении. Объект либо однозначно принадлежит адресу или другому объекту, либо является общим с правами записи/чтения, либо общим только с правами чтения. Владение объектом определяет, может ли транзакция использовать его в качестве входа и каким образом. В общем случае, объект с уникальной собственностью может быть использован только в транзакции, инициированной его владельцем или включающей его родительский объект в качестве входа, в то время как объект с общим доступом может быть использован любой транзакцией, но только с указанными разрешениями на изменение. Полное объяснение см. в разделе 4.4.
Существует два типа объектов: объекты кода пакета и объекты данных struct. Объект package содержит список модулей. Объект struct содержит значение Move struct и тип Move этого значения. Содержимое объекта может меняться, но его идентификатор, тип объекта (pack- age vs struct) и тип Move struct неизменны. Это гарантирует, что объекты сильно типизированы и имеют постоянную идентичность.
Наконец, объект содержит версию. Свежесозданные объекты имеют версию 0, а версия объекта увеличивается каждый раз, когда транзакция принимает объект на вход
Адрес - это постоянный идентификатор конечного пользователя Sui (хотя обратите внимание, что у одного пользователя может быть произвольное количество адресов). Чтобы передать объект другому пользователю, отправитель должен знать адрес получателя.
Как мы вскоре обсудим, транзакция Sui должна содержать адрес пользователя, отправляющего (т.е. инициирующего) транзакцию, и аутентификатор (authenticator), дайджест которого совпадает с адресом. Разделение между адресами и аутентификаторами обеспечивает криптографическую гибкость. Аутентификатором может быть открытый ключ из любой схемы подписи, даже если схемы используют разные длины ключей (например, для поддержки постквантовых подписей). Кроме того, аутентификатор не обязательно должен быть одним открытым ключом - он может быть (например) мультисигмальным ключом K-of-N.
В Sui есть два различных типа транзакций: публикация нового пакета Move и вызов ранее опубликованного пакета Move. Транзакция pub- lish содержит пакет - набор модулей, которые будут опубликованы вместе как единый объект, а также зависимости всех модулей этого пакета (закодированные в виде списка объектных ссылок, которые должны ссылаться на уже опубликованные объекты пакета). Чтобы выполнить транзакцию публикации, среда выполнения Sui запустит верификатор байткода Move для каждого пакета, свяжет пакет с его зависимостями и запустит инициализатор модуля каждого модуля. Инициализаторы модулей полезны для начального состояния приложения, реализуемого пакетом.
Наиболее важными аргументами транзакции вызова являются входы объектов. Аргументы объектов указываются либо через ссылку на объект (для неизменяемых объектов с одним владельцем и разделяемых объектов), либо через идентификатор объекта (для разделяемых изменяемых объектов). Ссылка на объект состоит из объекта, ID, версию объекта и хэш значения объекта. Время выполнения Sui разрешает как идентификаторы объектов, так и ссылки на объекты в значениях объектов, хранящихся в глобальном пуле объектов. Для ссылок на объекты среда выполнения сверяет версию ссылки с версией объекта в пуле, а также проверяет соответствие хэша ссылки объекту пула. Это гарантирует, что представление среды выполнения об объекте совпадает с представлением отправителя транзакции об объекте.
Кроме того, транзакция вызова принимает аргументы типа и аргументы чистого значения. Аргументы типа инстанцируют общие параметры типа вызываемой функции точки входа (например, если функция точки входа - send_coin(c: Coin, ...), то общий параметр типа T может быть инстанцирован с аргументом типа SUI для отправки токена Sui native). Чистые значения могут включать примитивные типы и векторы примитивных типов, но не типы struct.
Функция, которая будет вызвана вызовом, указывается через объектную ссылку (которая должна ссылаться на объект пакета), имя модуля в этом пакете и имя функции в этом пакете. Для выполнения транзакции вызова среда выполнения Sui разрешает функцию, привязывает аргументы типа, объекта и значения к параметрам функции и использует Move VM для выполнения функции. Транзакции call и publish подлежат учету и оплате за газ. Лимит учета выражается максимальным бюджетом газа. Время выполнения будет выполнять транзакцию до тех пор, пока бюджет не будет достигнут, и прервет ее без каких-либо последствий (кроме вычитания платы и сообщения кода прерывания), если бюджет исчерпан.
Плата списывается с объекта gas, указанного в качестве ссылки на объект. Этот объект должен быть собственным токеном Sui (т.е. его тип должен быть Coin<SUI>). Sui использует плату в стиле EIP15594: протокол определяет базовую плату (выраженную в единицах газа за токен Sui), которая алгоритмически корректируется на границах эпох, а отправитель транзакции может также включить необязательную плату (выраженную в токенах Sui). При нормальной загрузке системы транзакции будут обрабатываться быстро даже без чаевых. Однако если система перегружена, транзакции с большим размером чаевых будут обрабатываться в приоритетном порядке. Общая плата, взимаемая с объекта газа, составляет (GasUsed ∗ BaseFee) + Tip.
Выполнение транзакции генерирует эффекты транзакции, которые отличаются в случае, когда выполнение транзакции успешно
(SuccessEffects в таблице 6) и когда это не так (AbortEffects в
Таблица 6).
При успешном выполнении транзакции эффекты транзакции включают в себя информацию об изменениях, внесенных в глобальный пул объектов Sui (включая как обновления существующих объектов, так и вновь созданные объекты), и события, сгенерированные во время выполнения транзакции. Другим эффектом успешного выполнения транзакции может быть удаление (т.е. удаление) объектов из глобального пула, а также обертывание (т.е. встраивание) одного объекта в другой, что имеет эффект, аналогичный удалению - обернутый объект исчезает из глобального пула и существует только как часть объекта, который его обернул. Поскольку удаленные и обернутые объекты больше недоступны в глобальном пуле, эти эффекты представлены идентификатором и версией объекта.
События кодируют побочные эффекты успешного выполнения транзакции, помимо обновления глобального пула объектов. Структурно событие состоит из Move struct и его типа. События предназначены для потребления участниками вне блокчейна, но не могут быть прочитаны программами Move.
Транзакции в Move имеют семантику "все или ничего" - если выполнение транзакции прерывается в какой-то момент (например, из-за не ожидаемого сбоя), даже если до этого момента произошли некоторые изменения объектов (или были сгенерированы некоторые события), ни один из этих эффектов не сохраняется в прерванной транзакции. Вместо этого эффект прерванной транзакции включает цифровой код прерывания и имя модуля, в котором произошло прерывание транзакции. За прерванные транзакции по-прежнему взимается плата за газ.
В этом разделе мы описываем Sui с точки зрения систем, включая механизмы, обеспечивающие безопасность и непрерывность работы всех органов власти, несмотря на византийские сбои. Мы также объясняем работу клиентов, включая легкие клиенты, которым нужна некоторая уверенность в состоянии системы без проверки ее полного состояния.
Краткая предыстория. Система расчетов с низкой задержкой FastPay [3], расширенная для работы с произвольными объектами с помощью пользовательских смарт-контрактов и с безразрешительным делегированным доказательством состава комитета ставок [2]. Управление базовыми активами владельцев объектов основано на варианте византийской последовательной трансляции [6], которая имеет меньшую задержку и легче масштабируется на многих машинах по сравнению с традиционными реализациями византийского консенсуса [8, 11, 12].Когда требуется полное согласие, мы используем высокопроизводительный консенсус на основе DAG, например, [9] для управления блокировками, в то время как выполнение на различных общих объектах распараллеливается.
На рисунке 1 показаны высокоуровневые взаимодействия между клиентом и органами Sui для фиксации транзакции. Мы кратко опишем их здесь:
• Пользователь с закрытым ключом подписи создает и подписывает пользовательскую транзакцию транзакцию для изменения объектов, которыми он владеет, или общих объектов, в Sui. Впоследствии ключи подписи пользователя не нужны, и остальная часть процесса может быть выполнена пользовательский клиент или шлюз от имени пользователя (обозначается как бесключевая операция на диаграмме).
• Пользовательская транзакция отправляется в органы Sui, которые каждый раз проверяют ее на валидность, и в случае успеха подписывают ее и возвращают подписанную транзакцию клиенту. Клиент собирает ответы от кворума органов власти для формирования сертификата транзакции сертификат.
• Сертификат транзакции затем отправляется обратно во все органы власти, и если транзакция затрагивает объекты общего доступа, то он также отправляется в протокол византийского соглашения, управляемый
органами власти Sui. Органы проверяют сертификат и если задействованы разделяемые объекты, также ждут, пока протокол соглашения установит последовательность по отношению к другим транзакциям с разделяемыми объектами, а затем выполняют транзакцию.
транзакций, а затем выполняют транзакцию и суммируют ее последствия в подписанный ответ о последствиях.
• После того, как кворум органов власти выполнил сертификат, его действие становится окончательным (на диаграмме обозначено как окончательность). Клиенты могут собрать кворум авторитетных ответов и создать
сертификат эффектов и использовать его в качестве доказательства окончательности последствий транзакции.
В этом разделе подробно описана каждая из этих операций, а также операции по изменению конфигурации и управлению состоянием между органами власти.
Sui работает в последовательности эпох, обозначаемых 𝑒 ∈ {0, . . .}. Каждая
эпоха управляется комитетом 𝐶𝑒 = (𝑉𝑒, 𝑆𝑒 (-)), где 𝑉𝑒 - это набор органов власти с известными открытыми ключами проверки и сетевыми конечными точками. Функция 𝑆𝑒 (𝑣) отображает каждый орган 𝑣 ∈ 𝑉𝑒 на количество единиц делегированной доли. Мы предполагаем, что 𝐶𝑒 для каждой подписывается кворумом (см. ниже) авторитетного пакета акций в эпоху 𝑒 -1. (В разделе 4.7 рассматривается формирование и управление комитетами). В течение эпохи некоторые авторитеты являются корректными (они следуют (они точно следуют протоколу и живут), в то время как другие являются византийскими (они произвольно отклоняются от протокола). Предположение о безопасности состоит в том, что множество честных органов 𝐻𝑒 ⊆ 𝑉𝑒 наделено кворумом доли в течение эпохи, т.е. . Í ℎ∈𝐻𝑒 𝑆𝑒 (ℎ) > 2/3 Í 𝑣∈𝑉𝑒 𝑆𝑒 (𝑣) (и относятся к
любой набор органов власти с более чем двумя третями голосов как кворум).
Существует по крайней мере одна живая и корректная сторона, которая действует как ретранслятор для каждого сертификата (см. раздел 4.3) между честными органами власти. Этот обеспечивает оперативность и обеспечивает свойство конечной доставки для византийской трансляции (см. совокупность надежной трансляции в [6]). Каждый орган управляет таким реле, либо индивидуально, либо через коллективный протокол распространения. Внешние сущности, включая Sui клиенты, реплики и сервисы, также могут брать на себя эту роль. Различие между пассивным ядром органа власти и внутренним или внешним активным компонентом ретрансляции, который является менее надежным или доверенным, обеспечивает четкую демаркацию и минимизацию Trusted Computing База [15], на которую опирается безопасность и живучесть Sui.
4.2 Авторитетные & Репликативные структуры данных
Для представления состояния органы управления Sui полагаются на ряд структур данных. Мы определяем эти структуры на основе операций, которые они поддерживают. Все они имеют детерминированное байтовое представление.
Объект (Obj) хранит пользовательские смарт - контракты и данные в Sui. Они представляют собой кодировку объектов Move, представленных в разделе 2, на уровне системы Sui. Они поддерживают следующий набор операций:
• ref(Obj) возвращает ссылку (ObjRef) на объект, а именно триплет (ObjID, Version, ObjDigest). ObjID - это практически уникальный для всех новых создаваемых объектов, а Version - увеличивающееся положительное целое число, представляющее версию объекта в момент его мутации.
• owner(Obj) возвращает аутентификатор Auth владельца объекта. В простейшем случае Auth - это адрес, отражающий открытый ключ, который может использовать данный объект. Возможны и более сложные аутентификаторы (см. раздел 4.4).
• read-only(Obj) возвращает true, если объект доступен только для чтения. Объекты, доступные только для чтения, не могут быть изменены, обернуты или удалены. Они также могут использоваться кем угодно, а не только их владельцами.
• parent(Obj) возвращает дайджест транзакции (TxDigest), которая в последний раз мутировала или создала объект.
• contents(Obj) возвращает тип объекта Type и данные Data, которые могут быть использованы для проверки валидности транзакций и несут специфическую для приложения информацию.
Транзакция индексируется по ее TxDigest, который также может быть использован для проверки подлинности ее полного содержимого. Все действительные транзакции (кроме специальной жестко закодированной транзакции genesis) имеют по крайней мере один собственный вход, а именно объекты, используемые для оплаты газа. Структура эффектов транзакции (Effects) суммирует результаты выполнения транзакции. Она поддерживает следующие операции:
• digest(Effects) - это обязательство EffDigest перед Effects структура, которая может быть использована для индексации или аутентификации.
• transaction(Effects) возвращает TxDigest выполненной транзакции, дающей эффекты.
• dependencies(Effects) возвращает последовательность зависимостей [TxDigest], которые должны быть выполнены до того, как транзакция с этими эффектами может быть выполнена.
• contents(Effects) возвращает краткую информацию о выполнении. Status сообщает о результатах выполнения смарт-контракта. Списки Created, Mutated, Wrapped, Unwrapped и Deleted перечисляют ссылки на объекты, которые подверглись соответствующим операциям. А в списке Events перечислены события, вызванные выполнением.
Сертификат транзакции TxCert на транзакцию содержит саму транзакцию, а также идентификаторы и подписи от кворума органов власти. Обратите внимание, что сертификат может быть не уникальным, так как один и тот же логический сертификат может быть представлен разным набором органов, составляющих кворум. Кроме того, сертификат может быть подписан не строго 2/3 кворума, а, возможно, и больше, если большее количество органов власти будет реагировать. Однако, два разных действительных сертификата на одну и ту же транзакцию должны рассматриваться как семантически представляющие один и тот же сертификат. Частичный сертификат (TxSign) содержит ту же информацию, но подписи от набора авторов, представляющих долю меньше требуемого кворума, обычно от одного органа. Идентификаторы подписантов включаются в сертификат (т.е. подотчетные подписи [? ]) для идентификации органов, готовых обработать сертификат, или которые могут быть использованы для загрузки прошлую информацию, необходимую для обработки сертификата (см. раздел 4.8).
Аналогично, сертификат эффектов EffCert на структуру эффектов
содержит саму структуру эффектов и подписи от органов5
которые представляют кворум для эпохи, в которую транзакция является
действительной. Здесь действуют те же предостережения, касающиеся неуникальности и идентичности как и для сертификатов транзакций. Сертификат частичных эффектов, обычно содержащий подпись одного органа и структуру эффектов, обозначается как EffSign.
Постоянные хранилища. Каждый орган и реплика поддерживают набор
постоянных хранилищ. Хранилища реализуют семантику постоянных карт и могут быть представлены в виде набора пар ключ-значение (обозначается
𝑚𝑎𝑝 [𝑘𝑒𝑦] → 𝑣𝑎𝑙𝑢𝑒), таких, что только одна пара имеет заданный ключ. Перед тем, как пара вставляется, вызов contains(𝑘𝑒𝑦) возвращает false, а get(𝑘𝑒𝑦)
возвращает ошибку. После вставки пары вызов contains(𝑘𝑒𝑦) возвращает значение true, а get(𝑘𝑒𝑦) возвращает значение.
Авторитет поддерживает следующие постоянные хранилища:
• Карта блокировки ордера Lock𝑣 [ObjRef] → TxSignOption записывает первую действительную транзакцию Tx, замеченную и подписанную органом власти для принадлежащей версии объекта ObjRef, или None, если версия объекта существует, но не было замечено ни одной действительной транзакции, использующей ее в качестве входа. В ней также может быть записан первый увиденный сертификат с этим объектом в качестве входа. Эта таблица и правила ее обновления отражают состояние распределенных блокировок объектов между органами управления Sui и обеспечивают безопасность при одновременной обработке транзакций. -
с Карта сертификатов Ct𝑣 [TxDigest] → (TxCert, EffSign) записывает все полные сертификаты TxCert, которые также включают Tx, обработанные органом в течение эпохи их действия, вместе с их подписанными эффектами EffSign. Они индексируются по дайджесту транзакций TxDigest
•Объектная карта Obj𝑣 [ObjRef] → Obj записывает все объекты Obj, созданные транзакциями, включенными в сертификаты в пределах Ct𝑣, индексированные по ObjRef. Это хранилище может быть полностью восстановлено путем повторного выполнения всех сертификатов в Ct𝑣 . Поддерживается вторичный индекс, который связывает ObjID с последним объектом с этим идентификатором. Это единственная информация, необходимая для обработки новых транзакций, а более старые версии сохраняются только для облегчения чтения и аудита.
•Карта синхронизации Sync𝑣 [ObjRef] → TxDigest индексирует все сертификаты внутри Ct𝑣 по объектам, которые они создают, изменяют или удаляют в виде кортежей ObjRef. Эта структура может быть полностью воссоздана путем обработки всех сертификатов в Ct𝑣 , и используется для помощи клиентам в синхронизации транзакций, затрагивающих объекты, о которых они заботятся.
Органы власти поддерживают все четыре структуры, а также предоставляют доступ к локальным контрольным точкам своей карты сертификатов, чтобы другие органы и реплики могли загрузить полный набор обработанных сертификатов.
Репликация не обрабатывает транзакции, а только сертификаты, и
повторно выполняет их для обновления других таблиц, как это делают авторитеты. Она также поддерживает карту блокировки заказов для аудита неэквивокации.
Авторитет может быть разработан как полная реплика, поддерживающая все
четыре хранилища (и контрольные точки) для облегчения чтения и синхронизации, в сочетании с минимальным ядром авторитета, которое поддерживает только блокировки объектов и объекты для последней версии объектов, используемых для обработки новых транзакций и сертификатов. Это минимизирует доверенную вычислительную базу, на которую полагаются для обеспечения безопасности.
Только карта блокировки порядка требует сильной самосогласованности ключей,
а именно, чтение ключа всегда должно возвращать значение или
None присутствует для ключа, который существует, и такая проверка должна быть атомарной с обновлением, которое устанавливает блокировку на значение, отличное от None. Это более слабое свойство, чем сильная согласованность между ключами, и позволяет эффективно разделять хранилище для масштабирования. Другие хранилища могут быть в конечном итоге согласованными без ущерба для безопасности.
4.3 Управление базой полномочий
Обработка транзакции. При получении транзакции Tx орган выполняет ряд проверок:
(1) Это гарантирует, что epoch(Tx) является текущей эпохой.
(2) Убеждается, что все ссылки на объект inputs(Tx) и объект gas
в платеже(Tx) существуют в пределах Obj𝑣
и загружает их
в [Obj]. Для принадлежащих объектов точная ссылка должна
быть доступна; для объектов, доступных только для чтения или общего доступа, должен существовать идентификатор объекта
должен существовать.
(3) Обеспечивает наличие достаточного количества газа в объекте gas
для покрытия расходов на выполнение транзакции.
(4) Проверяет, что valid(Tx, [Obj]) истинно. Этот шаг гарантирует, что информация аутентификации в транзакции позволяет получить доступ
к принадлежащим объектам.
(5) Проверяется, что Lock𝑣 [ObjRef] для всех принадлежащих объектов inputs(Tx) существует, и он либо None, либо установлен на тот же Tx,
и атомарно устанавливает его на TxSign. (Мы называем это "блокировками
проверки").
Если ни одна из проверок не прошла, обработка завершается, и возвращается ошибка.
Тем не менее, частичное обновление Lock𝑣 может сохраняться (хотя
наша текущая реализация делает не частичное обновление, а атомарное
обновления всех блокировок).
Если все проверки прошли успешно, то орган возвращает подпись
на транзакции, т.е. частичный сертификат TxSign. Обработка
ордера является идемпотентной при успехе и возвращает частичный сертификат
(TxSign), или полный сертификат (TxCert), если он доступен.
Любая сторона может сопоставить транзакцию и подписи (TxSign)
для набора органов власти, образующих кворум для эпохи 𝑒, чтобы сформировать
сертификат транзакции TxCert.
Обработать сертификат. При получении сертификата орган
проверяет все условия действительности транзакции, кроме тех, которые относятся к блокировкам (так называемые "проверки блокировок"). Вместо этого он выполняет следующие проверки: для каждого принадлежащего объекта ввода в inputs(Tx) он проверяет, что блокировка существует, и что она либо отсутствует, либо установлена на любое значение TxSign, либо установлена на сертификат для той же транзакции, что и текущий сертификат. Если эта проверка модифицированных блокировок не проходит, то орган обнаруживает невосстановимый византийский сбой, прекращает нормальную работу и запускает процесс аварийного восстановления. Для разделяемых объектов (см.
разд. 4.4) органы власти проверяют, что блокировки были установлены посредством последовательность сертификатов в консенсусе, чтобы определить версию объекта доли для использования. Если да, то транзакция может быть
в противном случае она должна сначала дождаться такой последовательности.
Если проверка прошла успешно, орган добавляет сертификат в свою
карту сертификатов, вместе с эффектами, возникшими в результате его выполнения, т.е. Ct𝑣 [TxDigest] → (TxCert, EffSign); он обновляет карту блокировок, чтобы записывает сертификат Lock𝑣 [ObjRef] → TxCert для всех принадлежащих входных данных объектов, у которых блокировки не установлены на сертификат. Как только все объекты в Input(Tx) будут вставлены в Obj𝑣., то все эффекты в EffSign также материализуются путем добавления их ObjRef и содержимого в Obj𝑣.. Наконец, для всех созданных или измененных эффектов в EffSign карта синхронизации обновляется, чтобы сопоставить их с Tx.
Замечания. Логика работы с транзакциями и сертификатами приводит к ряду важных свойств:
• Причинность и параллелизм. Условия обработки для
транзакций и сертификатов обеспечивают причинно-следственное выполнение:
орган "голосует", подписывая транзакцию, только в том случае, если он
обработаны все сертификаты, создающие объекты, от которых зависит транзакция от которых зависит транзакция, как принадлежащих, так и совместно используемых и доступных только для чтения. Аналогично, орган обрабатывает сертификат только в том случае, если все входные объекты от которых он зависит, существуют в его локальной карте объектов. Этот накладывает причинно-следственный порядок выполнения, но также позволяет транзакциям, не зависящим друг от друга причинно-следственно, выполняться параллельно на разных ядрах или машинах.
• Подпись один раз и безопасность. Все принадлежащие входные объекты блокируются в Lock𝑣 [-] устанавливаются на первую транзакцию Tx, которая проходит проверки с их использованием, а затем первому сертификату, который использует объект в качестве входного. Мы называем это блокировкой объекта на эту транзакции, и разблокировка в течение эпохи не происходит. В результате
В результате орган подписывает только одну транзакцию для каждой блокировки,
что является важным компонентом последовательной трансляции [6],
и, следовательно, безопасность Sui.
• Восстановление после катастрофы. Орган, обнаруживающий два противоречивых сертификата для одной и той же блокировки, имеет доказательство неустранимого византийского поведения - а именно доказательство того, что предположение о кворуме предположение о честном авторитете не выполняется. Два противоречивых сертификата являются доказательством мошенничества [1], которое может быть передано
со всеми авторитетами и репликами для запуска процессов аварийного восстановления процессов. Авторитеты также могут получить другие формы доказательств невосстановимого византийского поведения, такие как >1/3 подписи на эффектах (EffSign), которые представляют собой неправильное исполнение сертификата. Или сертификат с входными объектами, которые
не представляют собой правильные выходы ранее обработанных
сертификатов. Они также могут быть упакованы как доказательство мошенничества и переданы всем органам власти и репликам. Обратите внимание, что это отличаются от доказательств того, что допустимое меньшинство органов власти (≤ 1/3 по доле) или владельцев объектов (любое количество) является византийским или двусмысленным, что может быть терпимо без какого-либо прерывания обслуживания.
• Финальность. Органы власти возвращают сертификат (TxCert) и
подписанные эффекты (EffSign) для любых запросов на чтение индекса
в Lock𝑣 , Ct𝑣 и Obj𝑣, Sync𝑣
• Транзакция считается окончательной, если более кворума органов власти сообщает Tx как включенную в их хранилище Ct𝑣. Это означает, что сертификат эффектов (EffCert) является передаваемым доказательством окончательности. Однако сертификат, использующий объект, также является доказательством того, что все зависимые сертификаты на его причинно-следственном пути также являются окончательными. Предоставление сертификата любой стороне, которая затем может направить его в супер большинство органов власти для обработки, также обеспечивает окончательность для последствий сертификата. Обратите внимание, что окончательность наступает позже чем fastpay [3], чтобы обеспечить безопасность при реконфигурации. Тем не менее, орган может применить эффект транзакции после получения сертификата, а не ждать фиксации.
4.4 Владельцы, авторизация и общие объекты
Валидность транзакции (см. раздел 4.3) гарантирует, что транзакция уполномочена включать все указанные входные объекты в транзакцию. Эта
проверка зависит от природы объекта, а также от владельца
поле.
Объекты, доступные только для чтения, не могут быть изменены или удалены и могут использоваться в транзакциях одновременно и всеми пользователями. Модули перемещения, например
например, доступны только для чтения. У таких объектов есть владелец, который может использоваться как часть смарт-контракта, но это не влияет на авторизацию для их использования. Они могут быть включены в любую транзакцию.
У объектов, находящихся в собственности, есть поле владельца. Владелец может быть установлен на адрес, представляющий открытый ключ. В этом случае транзакция имеет право использовать объект и изменять его, если он подписан этим адресом. адресом. Транзакция подписывается одним адресом, и поэтому может использовать один или несколько объектов, принадлежащих этому адресу. Однако одна транзакция не может использовать объекты, принадлежащие более чем одному адресу. Владелец объекта, называемого дочерним объектом, может быть установлен на ObjID другого объекта, называемого родительским объектом. В этом случае дочерний объект может быть использован только в том случае, если родительский объект включен в транзакцию, и транзакция уполномочена использовать этот объект. Этот возможность может быть использована контрактами для построения эффективных коллекций и других сложных структур данных.
Общие объекты являются изменяемыми, но не имеют конкретного владельца. Они могут быть включены в транзакции различными сторонами и
не требуют никакой авторизации. Вместо этого они выполняют свои собственные
логику авторизации. Такие объекты, в силу того, что они должны поддерживать
нескольких писателей, обеспечивая при этом безопасность и оперативность, требуют полного протокола согласования для безопасного использования. Поэтому они требуют дополнительной логики перед выполнением. Органы власти обрабатывают транзакции как указано в разд. 4.3 для принадлежащих объектов и объектов, доступных только для чтения для управления их блокировками. Однако органы власти не полагаются на последовательную трансляцию для управления блокировками общих объектов. Вместо этого, создатели транзакций, в которых участвуют общие объекты, вставляют сертификат о транзакции в высокопроизводительную систему консенсуса систему, например, [9]. Все органы власти наблюдают последовательность таких сертификатов и назначают версию общих объектов, используемых каждой транзакции в соответствии с этой последовательностью. После этого выполнение может
продолжаться, и гарантируется, что оно будет согласованным во всех инстанциях. Органы власти включают версию общих объектов, используемых в транзакции в сертификате эффектов.
Приведенные выше правила гарантируют, что выполнение транзакций, включающих только для чтения и объектов, находящихся в собственности, требуется только согласованная трансляция
и одного сертификата для продолжения; а византийское соглашение требуется только требуется для транзакций с участием разделяемых объектов. Интеллектуальный контракт. Поэтому авторы смарт-контрактов могут разрабатывать свои типы и операции так, чтобы оптимизировать передачи и другие операции над объектами одного пользователя с меньшей задержкой, наслаждаясь при этом гибкостью использования общих объектов.
Полные клиенты и реплики. Реплики, также иногда называемые полными клиентами, не проверяют новые транзакции, но поддерживают последовательную копию действительного состояния системы для целей аудита, а также для того, чтобы построения транзакций или работы сервисов, включая инфраструктуру чтения для легких клиентских запросов.
Легкие клиенты. Как ссылки на объекты, так и транзакции содержат
информацию, которая позволяет аутентифицировать полную причинно-следственную цепочку транзакций, которые привели к их созданию или выполнению. В частности, ссылка на объект (ObjRef) содержит ObjDigest, который является аутентификатором для полного состояния объекта, включая возможность получить parent(Obj), а именно TxDigest, который создал объект. Аналогично, TxDigest аутентифицирует транзакцию, включая возможность
извлечь через входные данные(Tx) объектные ссылки входных
объектов. Поэтому множество объектов и сертификатов образуют двудольный
граф, который является самоаутентифицирующимся. Более того, структуры эффектов также подписываются и могут быть объединены в сертификаты эффектов, которые непосредственно удостоверяют результаты выполнения транзакций.
Эти средства могут быть использованы для поддержки легких клиентов, которые могут выполнять высокоинтегрированное чтение состояния Sui, не поддерживая полного узла-реплики. В частности, авторитетный или полный узел может предоставить лаконичный пакет доказательств, включающий сертификат TxCert
на транзакцию Tx и входные объекты [Obj], соответствующие
inputs(Tx), чтобы убедить легкого клиента в том, что переход может иметь место
в пределах Sui. Легкий клиент может затем представить этот сертификат или проверить был ли он просмотрен кворумом или выборкой инстанций.
для обеспечения окончательности. Или он может создать транзакцию, используя объекты и наблюдать за тем, успешно ли она прошла.
Более непосредственно, служба может предоставить сертификат эффектов клиенту, чтобы убедить его в существовании и окончательности перехода в Sui.
чтобы убедить клиента в существовании и окончательности перехода в Sui, без каких-либо дальнейших действий или взаимодействия внутри
системы. Если доступна контрольная точка завершенных сертификатов, на
границе эпохи или иным образом, пакет доказательств, включая
входные объекты и сертификат, а также доказательство включения сертификата в контрольную точку. сертификата в контрольную точку также является доказательством окончательности.
Органы власти могут использовать механизм периодической проверки для создания коллективных контрольных точек завершенных транзакций, а также состояние Sui с течением времени. Сертификат с кворумом из кол
над контрольной точкой может быть использован легкими клиентами для эффективного подтверждения недавнего состояния объектов и испускаемых событий. Контрольная точка механизм необходим для реконфигурации комитета между эпохами. Более частые контрольные точки полезны для легких клиентов и также могут использоваться органами власти для сжатия своих внутренних структур данных структуры, а также синхронизировать свое состояние с другими органами власти более эффективно.
Встроенная поддержка легких клиентов и общих объектов, управляемых
Византийское соглашение позволяет Sui поддерживать двусторонние мосты к
другими блокчейнами [13]. Доверительные предположения таких мостов отражают предположения о доверии Sui и другого блокчейна, и не приходится полагаться на доверенные оракулы или аппаратное обеспечение, если другой блокчейн также поддерживает легкие клиенты [7].
Мосты используются для импорта актива, выпущенного на другом блокчейне,
представить его и использовать в качестве обернутого актива в системе Sui.
В конечном итоге, обернутый актив может быть разблокирован и передан
обратно пользователю на родном блокчейне. Мосты также могут позволить
активы, выпущенные на Sui, могут быть заблокированы и использоваться в качестве обернутых активов на других блокчейнах. В конечном итоге, обернутый объект на другой системе может быть уничтожен, а объект на Sui обновлен, чтобы отразить любые изменения состояния или владельца и разблокировать.
Семантика обмотанных активов имеет определенное значение для обеспечения полезности обмотанных активов. Легкорастворимые активы, соединенные между
блокчейн, могут обеспечить более богатое представление в обертке, что позволяет им быть делимыми и передаваемыми в обертке. Несгораемые активы не являются делимыми, а только передаваемыми. Они могут также поддерживать другие операции, которые контролируемым образом изменяют их состояние, когда они обернуты, что может привести к необходимости выполнения пользовательской логики смарт-контракта, когда они завернуты.
логика смарт-контракта, которая должна быть выполнена, когда они соединяются обратно и разворачиваются. Sui является гибкой и позволяет авторам смарт-контрактов определять такой опыт, поскольку мосты - это просто смарт-контракты реализованные в Move, а не в собственных концепциях Sui, и поэтому могут быть расширены с использованием гарантий совместимости и безопасности Move обеспечивает.
Реконфигурация происходит между эпохами, когда комитет 𝐶𝑒 заменяется
заменяется комитетом 𝐶𝑒 ′, где 𝑒 ′ = 𝑒 + 1. Реконфигурация безопасность гарантирует, что если транзакция Tx была зафиксирована в момент 𝑒 или раньше,
после 𝑒′ не может быть совершена никакая конфликтующая транзакция. Непрерывность гарантирует, что если Tx был совершен в 𝑒 или раньше, то он должен быть совершен и после 𝑒.
Мы используем систему смарт-контрактов Sui для выполнения значительной части работы, необходимой для реконфигурации. В системе Sui система смарт-контракт позволяет пользователям блокировать и делегировать долю кандидатам в органы власти. В течение эпохи владельцы монет могут передавать полномочия
путем блокировки токенов, отменить делегирование путем разблокировки токенов или изменить свое делегирование одному или нескольким органам власти.
Как только кворум участников эпохи 𝑒 голосует за завершение эпохи, органы власти обмениваются информацией, чтобы зафиксировать контрольную точку, определить следующий комитет и изменить эпоху. Сначала органы власти запускают протокол контрольной точки, с помощью протокола соглашения [9], чтобы согласовать сертифицированную контрольную точку для конца эпохи 𝑒.
Контрольная точка содержит объединение всех транзакций и потенциально результирующих объектов, которые были обработаны кворумом из
органов власти. В результате, если транзакция была обработана
кворумом органов власти, то по крайней мере один честный орган власти, который обработал ее, то хотя бы один из честных органов власти, который обработал ее, включит свои обработанные транзакции в
контрольную точку в конце эпохи, гарантируя, что транзакция и ее последствия
сохраняются на протяжении эпох. Более того, такая сертифицированная контрольная точка гарантирует, что все транзакции доступны честным органам
эпохи 𝑒.
Делегирование доли в контрольной точке в конце эпохи затем
используется для определения нового набора органов власти для эпохи 𝑒 + 1. Оба
кворум старой доли полномочий и кворум новой доли полномочий
подписывают новый комитет 𝐶𝑒 ′, и контрольную точку, в с которой начинается новая эпоха. Как только оба набора подписей становятся доступными, новый набор органов власти начинает обрабатывать транзакции для новой эпохи, а старые органы могут удалить свои ключи подписи эпохи
ключи.
Восстановление. Из-за ошибки клиента или равнодушия клиента возможно
объект, находящийся в собственности, может стать "заблокированным" в течение эпохи, не позволяя любой транзакции, касающейся этого объекта, быть сертифицированной (или завершенной). Например, клиент подписывает две различные транзакции, используя одну и ту же версию принадлежащего объекта, причем половина органов власти подписывает каждую из них, будет
не сможет сформировать сертификат, требующий кворума подписей
на любом из двух сертификатов. Восстановление гарантирует, что после смены эпох смены эпох такие объекты снова оказываются в состоянии, позволяющем использовать их в транзакциях. Поскольку сертификат не может быть сформирован, исходный объект доступен в начале следующей эпохи, чтобы с ним можно было работать. Поскольку транзакции содержат номер эпохи, старые эквивоцирующие транзакции не будут снова блокировать объект, давая его владельцу шанс использовать его.
Вознаграждения & криптоэкономика. У Sui есть собственный токен SUI, с
фиксированным запасом. SUI используется для оплаты газа, а также может быть использован в качестве делегированной доли в органах власти в течение эпохи. Право голоса органов власти в пределах эпохи зависит от этой делегированной доли. В конце эпохи сборы, собранные в результате всех обработанных транзакций, распределяются между органами власти в соответствии с их вкладом в работу Sui, и, в свою очередь, они делят часть сборов в качестве
вознаграждения адресам, которые делегировали им долю. Мы откладываем
полное описание экономики токенов Sui до отдельной статьи.
4.8 Авторитет и обновление реплик
Управляемые клиентом. Из-за сбоев клиентов или не византийских органов власти некоторые органы могут не обработать все сертификаты. В результате причинно связанные транзакции, зависящие от отсутствующих объектов, созданных этими сертификатами, будут отклонены. Однако клиент всегда может обновить честный орган до состояния, когда он сможет обработать корректную транзакцию. Он может сделать это, используя свое собственное хранилище прошлых сертификатов или используя один или несколько других честных авторитетов в качестве источника прошлых сертификатов.
Учитывая сертификат 𝑐 и хранилище 𝐶𝑡𝑣, которое включает в себя𝑐 и его каузальную истории, клиент может обновить честный авторитет 𝑣 ′ до точки, где 𝑐 также будет применяться. Для этого нужно найти наименьший набор сертификатов, не входящих в 𝑣 ′, такой, чтобы при его применении объекты в 𝑣 ′ включали все входы 𝑐. Обновление отстающей инстанции 𝐵 с помощью хранилища 𝐶𝑡𝑣, включая сертификат TxCert:
• Клиент ведет список сертификатов для синхронизации, первоначально содержащий только TxCert.
• Клиент рассматривает последний TxCert, требующий синхронизации. Он извлекает Tx из TxCert и извлекает все его входные объекты (с помощью Input(Tx)). объекты (используя Input(Tx)).
• Для каждого входного объекта он проверяет, был ли Tx, который генерировался или мутировал последним (используя Sync𝑣 индекс на 𝐶𝑡𝑣 ) имеет сертификат в пределах 𝐵, иначе его сертификат считывается из 𝐶𝑡𝑣 и добавляется в список сертификатов для синхронизации.
• Если больше ни один сертификат не может быть добавлен в список (потому что больше нет
отсутствуют входы 𝐵) список сертификатов сортируется
в причинно-следственном порядке и передается в 𝐵.
Приведенный выше алгоритм также применим для обновления объекта до определенной версии для проведения новой транзакции. В этом случае сертификат для Tx, который создал версию объекта, найденный в Sync𝑣 [ObjRef], передается в отстающий орган. Как только он будет выполнен на 𝐵, то объект в нужной версии станет доступным для использования.
Клиент, выполняющий эту операцию, называется ретранслятором. Может существовать быть несколько ретрансляторов, работающих независимо и одновременно. Им не доверяют с точки зрения целостности, и их работа является без ключей. Помимо клиентов, органы власти могут запускать логику ретранслятора для обновлять друг друга, а реплики, работающие с сервисами, также могут выступать в качестве ретрансляторы для обновления отстающих авторитетов.
Масса. Авторитеты предоставляют возможность последователю получать обновления при обработке сертификата. Это позволяет репликам поддерживать актуальное представление о состоянии авторитета. Кроме того, в краткосрочной перспективе авторитеты могут использовать сеть сплетен push-pull для обновления информации друг о друге о последней обработанной транзакции, чтобы уменьшить потребность в ретрансляторах для выполнения этой функции. В более долгосрочной перспективе отстающие органы могут использовать периодическую фиксацию состояния, на границах эпох или чаще, чтобы убедиться, что они обработали полный набор сертификатов до определенных контрольных точек.
Система Sui позволяет масштабировать систему, хотя органы власти выделяют больше ресурсов, а именно процессоров, памяти, сети и хранилища в рамках одной машины или нескольких машин, для обработки транзакций. Большее количество ресурсов приводит к увеличению способности обрабатывать транзакции, что приводит к увеличению комиссионного дохода для финансирования этих ресурсов. Большее количество ресурсов также приводит к снижению задержки, поскольку операции выполняются не дожидаясь, пока необходимые ресурсы станут доступны.
Пропускная способность. Чтобы гарантировать, что увеличение количества ресурсов приводит к увеличению производительность квазилинейно, дизайн Sui агрессивно уменьшает узкие места и точки синхронизации, требующие глобальных блокировок в органах власти. Обработка транзакций четко разделена на две фазы, а именно: (1) обеспечение транзакции эксклюзивным доступом к принадлежащим или разделяемым объектам в определенной версии, и (2) затем последующее выполнение транзакции и фиксация ее последствий
Фаза (1) требует от транзакции приобретения распределенных блокировок на гранулярности объектов. Для принадлежащих объектов это выполняется посредством надежный широковещательный примитив, который не требует глобальной синхронизации в пределах органа, и поэтому может быть масштабирован посредством шардинга управления блокировками на нескольких машинах по ObjID. Для транзакций с общими объектами требуется последовательность с использованием протокол консенсуса, который накладывает глобальный порядок на эти
транзакций и потенциально может стать узким местом. Однако, недавние достижения в разработке высокопроизводительных протоколов консенсуса [9] показывают, что последовательное выполнение является узким местом в репликации машин состояний, а не последовательность. В Sui, секвенирование используется только для определения версии входного общего объекта, а именно, увеличение номера версии объекта и ассоциирование его с дайджестом транзакции, а не для выполнения последовательного выполнение.
Фаза (2) происходит, когда версия всех входных объектов
известна органу власти (и безопасно согласована между органами власти) и включает в себя выполнение транзакции Move и фиксацию ее эффекты. Как только версия входных объектов известна, выполнение может происходить полностью параллельно. Виртуальные машины на нескольких ядрах или физические машины считывают версионные входные объекты, выполняют и записывают результирующие объекты из хранилищ и в хранилища. На сайте требования к согласованности хранилищ для объектов и транзакций (кроме карты блокировки порядка) очень слабые, что позволяет использовать масштабируемые распределенные хранилища ключевых значений внутри каждого органа. Выполнение является идемпотентным, что делает даже аварии или аппаратные сбои на компонентах, обрабатывающих выполнение, легко восстанавливаются.
В результате выполнение операций, не связанных друг с другом причинно-следственными связями, может происходить параллельно. Поэтому разработчики интеллектуальных контрактов могут проектировать модель данных объектов и операций в своих контрактах, чтобы воспользоваться преимуществами этого параллелизма.
Контрольные точки и обязательства по состоянию вычисляются вне
критических транзакций, чтобы не блокировать обработку свежих транзакций. Они включают операции чтения зафиксированных данных, а не требуют вычислений и согласования до того, как транзакция достигнет завершения. Поэтому они не влияют на задержку или пропускную способность обработки новых транзакций и могут быть распределены по доступным ресурсам.
Чтение может выиграть от очень агрессивного и масштабируемого кэширования.
Органы власти подписывают и делают доступными все данные, которые требуются легким клиентам для чтения, которые могут обслуживаться распределенными хранилищами как статические данные. Сертификаты выступают в качестве корней доверия для своей полной причинно-следственной истории транзакций и объектов. Обязательства состояния позволяют всей системе иметь регулярные глобальные корни доверия для всех состояний и обрабатываемых транзакций, по крайней мере, каждую эпоху или чаще.
Латентность. Разработчикам умных контрактов предоставляется гибкость в управлении задержкой операций, которые они определяют, в зависимости от того.
они связаны с принадлежащими или совместно используемыми объектами. Принадлежащие объекты полагаются на надежную трансляцию перед выполнением и фиксацией, что требует двух обходов кворума органов власти для достижения окончательного результата. Операции с участием разделяемых объектов, с другой стороны, требуют последовательной трансляции для создания сертификата, а затем обрабатываются в рамках консенсусного протокола, что приводит к увеличению задержки (от 4 до 8 обращений к кворуму по данным [9]).
к кворумам по данным [9]).
[1] Mustafa Al-Bassam, Alberto Sonnino, Vitalik Buterin, and Ismail Khoffi. 2021. Fraud and Data Availability Proofs: Detecting Invalid Blocks in Light Clients. In Financial Cryptography and Data Security - 25th International Conference, FC 2021, Virtual Event, March 1-5, 2021, Revised Selected Papers, Part II (Lecture Notes in Computer Science, Vol. 12675), Nikita Borisov and Claudia Diaz (Eds.). Springer, 279–298.
[2] Shehar Bano, Alberto Sonnino, Mustafa Al-Bassam, Sarah Azouvi, Patrick McCorry, Sarah Meiklejohn, and George Danezis. 2019. SoK: Consensus in the Age of Blockchains. In Proceedings of the 1st ACM Conference on Advances in Financial Technologies, AFT 2019, Zurich, Switzerland, October 21-23, 2019. ACM, 183–198.
[3] Mathieu Baudet, George Danezis, and Alberto Sonnino. 2020. FastPay: HighPerformance Byzantine Fault Tolerant Settlement. In AFT ’20: 2nd ACM Conference on Advances in Financial Technologies, New York, NY, USA, October 21-23, 2020. ACM, 163–177.
[4] Sam Blackshear, Evan Cheng, David L. Dill, Victor Gao, Ben Maurer, Todd Nowacki, Alistair Pott, Shaz Qadeer, Ra in, Dario Russi, Stephane Sezer, Tim Zakian, and Runtian Zhou. 2019. Move: A Language With Programmable Resources. https://developers.libra.org/docs/move-paper.
[5] Sam Blackshear, David L. Dill, Shaz Qadeer, Clark W. Barrett, John C. Mitchell, Oded Padon, and Yoni Zohar. 2020. Resources: A Safe Language Abstraction for Money. CoRR abs/2004.05106 (2020). arXiv:2004.05106 https://arxiv.org/abs/ 2004.05106
[6] Christian Cachin, Rachid Guerraoui, and Luís Rodrigues. 2011. Introduction to reliable and secure distributed programming. Springer Science & Business Media.
[7] Panagiotis Chatzigiannis, Foteini Baldimtsi, and Konstantinos Chalkias. 2021. SoK: Blockchain Light Clients. IACR Cryptol. ePrint Arch. (2021), 1657.
[8] Daniel Collins, Rachid Guerraoui, Jovan Komatovic, Petr Kuznetsov, Matteo Monti, Matej Pavlovic, Yvonne-Anne Pignolet, Dragos-Adrian Seredinschi, Andrei Tonkikh, and Athanasios Xygkis. 2020. Online Payments by Merely Broadcasting Messages. In 50th Annual IEEE/IFIP International Conference on Dependable Systems and Networks, DSN 2020, Valencia, Spain, June 29 - July 2, 2020. IEEE, 26–38.
[9] George Danezis, Eleftherios Kokoris-Kogias, Alberto Sonnino, and Alexander Spiegelman. 2021. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus. CoRR abs/2105.11827 (2021).
[10] David L. Dill, Wolfgang Grieskamp, Junkil Park, Shaz Qadeer, Meng Xu, and Jingyi Emma Zhong. 2021. Fast and Reliable Formal Verification of Smart Contracts with the Move Prover. CoRR abs/2110.08362 (2021). arXiv:2110.08362 https://arxiv.org/abs/2110.08362
[11] Rachid Guerraoui, Petr Kuznetsov, Matteo Monti, Matej Pavlovic, and DragosAdrian Seredinschi. 2018. AT2: Asynchronous Trustworthy Transfers. CoRR abs/1812.10844 (2018).
[12] Rachid Guerraoui, Petr Kuznetsov, Matteo Monti, Matej Pavlovic, and DragosAdrian Seredinschi. 2019. The Consensus Number of a Cryptocurrency. In Proceedings of the 2019 ACM Symposium on Principles of Distributed Computing, PODC 2019, Toronto, ON, Canada, July 29 - August 2, 2019, Peter Robinson and Faith Ellen (Eds.). ACM, 307–316.
[13] Patrick McCorry, Chris Buckland, Bennet Yee, and Dawn Song. 2021. SoK: Validating Bridges as a Scaling Solution for Blockchains. IACR Cryptol. ePrint Arch. (2021), 1589.
[14] Marco Patrignani and Sam Blackshear. 2021. Robust Safety for Move. CoRR abs/2110.05043 (2021). arXiv:2110.05043 https://arxiv.org/abs/2110.05043
[15] Jerome H Saltzer and Michael D Schroeder. 1975. The protection of information in computer systems. Proc. IEEE 63, 9 (1975), 1278–1308.
[16] Jingyi Emma Zhong, Kevin Cheang, Shaz Qadeer, Wolfgang Grieskamp, Sam Blackshear, Junkil Park, Yoni Zohar, Clark W. Barrett, and David L. Dill. 2020. The Move Prover. In Computer Aided Verification - 32nd International Conference, CAV 2020, Los Angeles, CA, USA, July 21-24, 2020, Proceedings, Part I (Lecture Notes in Computer Science, Vol. 12224), Shuvendu K. Lahiri and Chao Wang (Eds.). Springer, 137–150. https://doi.org/10.1007/978-3-030-53288-8_7