Опубликовано в Группа компаний «Эмбер» 13 сен 2022 г.

Введение

За последние два года произошел взрыв новых распределенных реестров с поддержкой смарт-контрактов, которые направлены на устранение предполагаемых недостатков Bitcoin и Ethereum. Эти «альтернативные уровни 1» или «альтернативные уровни 1», как их обычно называют, обычно предлагают новые архитектуры и делают различные компромиссы в дизайне для повышения масштабируемости и удобства использования распределенных реестров. Некоторые из этих альтернативных уровней 1, такие как Solana и Avalanche, привлекли большое внимание своими растущими пользовательскими базами, расширяющимися экосистемами и (в основном) высококачественным пользовательским опытом. В результате Solana , Avalanche , Near и другие привлекли сотни миллионов долларов от известных инвесторов, чтобы стать основной инфраструктурой интернета следующего поколения.

В последнее время все чаще обсуждаются два долгожданных распределенных реестра: Aptos и Sui. Aptos и Sui еще не запустили свои основные сети, и мало кто, кроме разработчиков, использовал их сети. Несмотря на это, им все же удалось вызвать ажиотаж среди криптоэнтузиастов и собрать значительный капитал от инвесторов, что делает их предстоящие релизы похожими на прибытие двух новых топовых L1.

По крайней мере часть ажиотажа вокруг Aptos и Sui связана с тем, что обе они были основаны бывшими членами подразделения распределенного реестра Facebook, Diem, также известного как Libra. Учитывая впечатляющий профессиональный опыт обеих команд и значимость основных L1 в более широкой криптоиндустрии, неудивительно, что и Aptos, и Sui привлекли столько внимания.

Оба этих уровня 1 ведут свое происхождение от Facebook, и оба используют новый язык программирования смарт-контрактов Move, так что вы можете подумать, что это просто две версии схожего дизайна. Однако, несмотря на эти сходства, их базовые архитектуры на самом деле довольно сильно отличаются друг от друга. В этой статье мы рассмотрим механику того, как каждый из этих новых распределенных реестров работает на высоком уровне, и обсудим, что это означает для будущего этих двух новых участников ландшафта уровня 1.

Архитектура блокчейна Aptos против архитектуры DAG Sui

Вы могли заметить, что в этом посте мы использовали фразу «распределенный реестр» вместо «блокчейн». Это потому, что распределенный реестр Sui на самом деле является «хранилищем объектов», данные которого записываются как направленный ациклический граф, или DAG. Почти все механические различия между Aptos и Sui сводятся к тому, что Aptos записывает свой реестр как блокчейн, в то время как Sui записывает его как DAG. Это просто две разные разновидности технологии распределенного реестра (DLT), но их различия имеют важные последствия для их механизмов консенсуса, порядка транзакций, выполнения транзакций и общей масштабируемости.

Сначала мы опишем архитектуру Aptos, которая содержит много общих элементов дизайна типичного блокчейна, а затем опишем, чем DAG Суи отличается от Aptos и большинства архитектур блокчейнов.

Ориентация на адрес против ориентации на объект

Вероятно, наиболее важное различие между этими двумя конструкциями заключается в ориентации на адрес, а не на объект.

Как и в случае с большинством блокчейнов, почти вся активность в Aptos связана с изменением данных, связанных с адресами. Подавляющее большинство транзакций просто обновляют балансы активов, удерживаемых заданным набором адресов. Одним из следствий этой конструкции является то, что каждый простой перевод (т. е. когда Алиса платит Бобу) требует двух обновлений в реестре: одно для отправляющего счета и одно для получающего счета.

«Алиса платит Бобу 1 USDC» будет выглядеть примерно так на Aptos. Реестр обновляет как баланс USDC Алисы, так и баланс USDC Боба.

Уменьшив масштаб, мы можем визуализировать, как большое количество этих транзакций отображается в традиционном реестре блокчейна. Транзакция Алисы и Боба является одной из многих транзакций внутри одного блока в универсальном реестре, который содержит все исторические транзакции для всех активов, как показано ниже:

Напротив, почти вся деятельность в Sui включает в себя изменение данных, связанных с определенными « объектами », которые могут быть токеном, смарт-контрактом или другой сущностью в цепочке. Каждый объект в Sui имеет список атрибутов, включая адрес его владельца (или атрибуты общего владения), свойства чтения/записи, свойства переносимости, функциональность в dapp/игре и т. д. В этой конструкции большинство простых переводов (например, Алиса платит Бобу) требуют только одного обновления в реестре: изменение атрибута «владелец» определенного объекта.

«Алиса платит Бобу 1 USDC» будет выглядеть примерно так на Sui. Реестр делает одно обновление: объект 1 USDC, владельцем которого является Алиса, изменит свой атрибут владельца на Боба.

Однако для некоторых простых переводов может потребоваться разделить существующий объект на два объекта перед обработкой перевода. «Алиса платит Бобу 0,5 USDC» может потребоваться транзакция, разделяющая объект номиналом 1 USDC на два объекта номиналом 0,5 USDC с атрибутом владельца «Алиса» (зеленые стрелки), и последующая транзакция для изменения атрибута владельца одного из объектов номиналом 0,5 USDC с «Алиса» на «Боб».

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

Каждая строка на диаграмме представляет собой полную историю транзакций определенного объекта. Например, серая строка показывает всю историю транзакций одного определенного токена USDC, причем последняя транзакция — «Алиса заплатила Бобу 1 USDC». Каждая стрелка на диаграмме представляет транзакцию — изменение метаданных определенного экземпляра объекта. Для большинства простых транзакций изменение будет касаться атрибута «владелец» определенного токена, но язык программирования Move позволяет объектам иметь множество других атрибутов, которые также могут быть изменены. Кроме того, объекты могут создавать другие объекты (например, объект смарт-контракта может выпустить объект NFT), и новые объекты могут быть созданы и даже удалены транзакциями. Возможность удалять объекты может помочь уменьшить «раздувание состояния», когда реестр становится слишком большим для легкого хранения на компьютере. Обратите внимание, что истории транзакций движутся только в одном направлении и не возвращаются в предыдущие состояния — именно здесь в игру вступают «направленные» и «ациклические(al)» части. Часть «граф» относится к общей диаграмме, которая получается в результате выполнения множества транзакций со многими объектами. DAG Суи также называют глобальным «хранилищем объектов» или «пулом объектов».

Этот объектно-ориентированный метод записи транзакций в DAG, а не в блокчейне, приводит к значительным различиям в обработке транзакций в Sui и Aptos. Почему? Потому что транзакции в DAG не связаны друг с другом по своей сути — каждый актив по сути имеет свой собственный отдельный реестр, который может обновляться независимо от реестра любого другого актива. В блокчейне каждая транзакция должна обновлять один универсальный реестр, который содержит всю историю транзакций каждого актива, и это различие имеет важные последствия для упорядочивания и пакетирования транзакций.

Упорядочение и пакетирование транзакций

Дизайн Aptos следует другой определяющей характеристике блокчейнов: все транзакции должны быть упорядочены и объединены в блоки валидаторами перед записью в единый универсальный реестр. Этот двойной процесс упорядочения и объединения требует кратковременной остановки состояния универсального реестра для записи групп (т. е. блоков) транзакций. Он также требует, чтобы валидаторы достигли консенсуса относительно порядка каждой транзакции , записанной в реестр, что может внести дополнительную задержку по сравнению с дизайном, который не требует упорядочивания каждой транзакции. При этом выполнение и распространение транзакций в Aptos выполняются валидаторами непрерывно в фоновом режиме, даже если записанное состояние реестра кратковременно приостановлено.

В проекте Суи, поскольку каждый объект по сути имеет свой собственный независимый реестр, значительная часть транзакций, отправленных в любой момент времени, вообще не нуждается в упорядочивании. Единственные транзакции, которые требуют упорядочения, — это те, которые просматривают или изменяют атрибуты того же объекта(ов), что и другая транзакция. Если две или более транзакций отправляются валидатору в одно и то же время и не затрагивают ни один из тех же объектов, они могут быть записаны в реестр одновременно. Кроме того, запись одной из этих транзакций в реестр не требует приостановки всего состояния реестра — требуется только приостановка реестра конкретного объекта, на который влияет транзакция.

В Sui это работает через «общие объекты», объекты, которые можно просматривать и/или изменять по любому адресу Sui. Если объект обозначен как общий объект, то любая транзакция, которая считывает/записывает этот объект, должна пройти через протокол Narwhal mempool для секвенирования, а затем быть обработана Tusk , высокопроизводительным протоколом консенсуса BFT, чтобы завершить это секвенирование. Для объектов, которые не являются общими, известных как «объекты с одним владельцем» или «объекты с уникальным владением», транзакции не должны секвенироваться валидаторами, а иногда и вовсе не секвенироваться. Это применимо ко многим простым передачам между адресами. Мы можем визуализировать это с помощью нашей предыдущей диаграммы:

Зеленые и оранжевые транзакции, выделенные в правой части диаграммы, не связаны друг с другом, поэтому их вообще не нужно упорядочивать. Их можно просто записать в реестр без достижения консенсуса относительно порядка, в котором они произошли. Наоборот, синие и зеленые транзакции, выделенные в верхней центральной части диаграммы, взаимодействовали с одним и тем же объектом (пятая версия синего объекта), поэтому их нужно упорядочить. Если синий объект окажется «общим объектом», транзакции должны будут пройти упорядочивание через Narwhal и консенсус через Tusk.

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

В Sui, поскольку он использует объектно-центрическую модель, активы, принадлежащие одному и тому же лицу, независимы друг от друга — каждый из них является отдельным объектом, даже если они являются одним и тем же типом токена. Поэтому многие (но не все) транзакции, включающие один и тот же тип токена от одного и того же владельца, не нуждаются в упорядочивании.

Например, если Алиса владеет 2 USDC, то на самом деле она владеет двумя отдельными объектами 1-USDC, каждый из которых имеет атрибут владельца «Алиса». Если она отправляет 1 USDC двум разным людям (например, Бобу и Фрэнку), эти транзакции не нужно упорядочивать. В адресно-ориентированной модели эти транзакции должны быть упорядочены, чтобы подтвердить, что у Алисы есть достаточный баланс USDC для оплаты обеих запрошенных ею транзакций.

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

В адресно-ориентированном блокчейне две транзакции выше считаются связанными и должны быть упорядочены, поскольку они взаимодействуют с одним и тем же адресом (Алисы). Одна из транзакций должна быть записана в реестр после другой, чтобы убедиться, что на адресе Алисы есть достаточный баланс USDC для оплаты как Бобу, так и Фрэнку. Порядок, в котором Боб и Фрэнк получают оплату (или не получают, если баланс Алисы слишком низок), определяется валидаторами блокчейна через его протоколы мемпула и консенсуса.

В объектно-ориентированном блокчейне транзакции из предыдущей диаграммы (Алиса платит по 1 USDC Бобу и Фрэнку) считаются несвязанными и не требуют упорядочивания. Не требуется «проверка баланса» адреса Алисы — она просто запрашивает изменение атрибута владельца двух независимых объектов, которыми она в настоящее время владеет, поэтому обе запрошенные ею транзакции могут быть записаны в реестр параллельно.

Однако предположим, что Алиса хочет отправить по 0,5 USDC и Бобу, и Фрэнку. В этом случае Алисе нужно будет разделить объект номиналом 1 USDC на два объекта номиналом 0,5 USDC и изменить атрибут владельца каждого из них, что в общей сложности составит три транзакции. В объектно-ориентированной модели Суи транзакция «разделения» (красные стрелки) считается связанной с двумя транзакциями «отправки» (зеленые стрелки), поскольку разделение должно быть записано в реестр до ее платежей Бобу и Фрэнку, поэтому требуется упорядочивание. Однако после того, как разделение произойдет, две транзакции «отправки» Бобу и Фрэнку могут быть записаны в реестр одновременно, как в предыдущем примере. Кроме того, нет необходимости упорядочивать любую из этих трех транзакций через протоколы mempool и консенсуса, поскольку ни в какой точке две транзакции не взаимодействуют с общим объектом.

Рассмотрим другой объектно-ориентированный пример: предположим, что Алиса и Джилл хотят отправить транзакцию в общий объект: например, в пул ликвидности. В этом случае, поскольку транзакции Алисы и Джилл взаимодействуют с одним и тем же общим объектом, их необходимо упорядочить с помощью валидаторов через протоколы mempool и консенсуса реестра.

Наконец, мы можем рассмотреть две транзакции, которые не связаны ни в объектно-ориентированной, ни в адресно-ориентированной модели: Алиса платит Бобу, а Джилл платит Фрэнку. В адресно-ориентированной модели эти не связанные транзакции все равно должны быть упорядочены, прежде чем они будут записаны в реестр. В объектно-ориентированной модели их не нужно упорядочивать, и они могут быть записаны в реестр одновременно.

Дизайн Aptos действительно включает оптимизацию для более эффективной последовательности транзакций. Действительно, Александр Шпигельман, работающий исследователем блокчейна в Aptos Labs, был соавтором оригинальной статьи , описывающей протокол пула памяти Narwhal и протокол консенсуса Tusk. Текущий механизм упорядочивания Aptos, DiemBFTv4, следует очень похожим принципам, что и Narwhal & Tusk: проще говоря, он отделяет последовательность транзакций от процесса консенсуса для увеличения пропускной способности и уменьшения задержки. Это работает так, что и Narwhal, и DiemBFTv4 требуют, чтобы ведущий валидатор в любой момент времени (лидер) отправлял только метаданные группы транзакций в качестве предлагаемого блока другим валидаторам. Эти метаданные представляют собой просто хэш или «дайджест» группы транзакций. Метаданные также содержат порядок транзакций в предлагаемом блоке. В большинстве существующих уровней 1 ведущий валидатор предлагает сами транзакции другим валидаторам. Отправка только метаданных транзакций значительно уменьшает размер блоков и ускоряет их загрузку и обработку другими валидаторами в сети, что повышает пропускную способность и сокращает задержки.

Чтобы было ясно, все валидаторы непрерывно создают блоки параллельно и транслируют их другим валидаторам, но они обрабатываются и хранятся отдельно от метаданных и не используются в ходе фактического процесса секвенирования. После согласования секвенирования валидаторы могут получить доступ к фактическим данным транзакции для выполнения связанного с ними кода.

Исходя из их соответствующих конструкций, Aptos и Sui должны работать сопоставимо с точки зрения последовательности транзакций. Однако конструкция Sui дает преимущество в том, что часть транзакций вообще не нужно упорядочивать. Если Sui удастся избежать упорядочивания, скажем, 20–30% активности в своем реестре, это может привести к значительному улучшению пропускной способности и задержки. При этом важно отметить, что все транзакции в Sui, включая неупорядоченные транзакции, по-прежнему требуют подписей от достаточного большинства валидаторов, чтобы ведущий валидатор мог записать их в реестр Sui. Сбор этих подписей на основе транзакции за транзакцией создает дополнительную нагрузку для ведущих валидаторов по сравнению с Aptos, чьи ведущие валидаторы собирают подписи только для каждого предложенного блока транзакций. Дополнительная нагрузка может, по крайней мере, частично компенсировать преимущество пропускной способности и задержки за счет пропуска протоколов mempool и консенсуса. Кроме того, частое разделение объектов в Sui может потенциально создать сложности при обработке транзакций. Ниже мы более подробно рассмотрим разделение объектов.

Используя персонажей из наших предыдущих примеров, предположим, что Боб, Фрэнк и Алиса продолжают обмениваться дробными частями USDC друг с другом в течение некоторого периода времени. Всего после трех раундов этих транзакций (представленных на диаграмме ниже разноцветными стрелками) исходный единый объект в 1 USDC может оказаться разделенным на восемь отдельных объектов. Очевидно, что это может быстро усложнить пул объектов Суи и связанные с ним транзакции.

Транзакции Sui, которые не «тратят» весь объект, требуют разделения объекта на две части. Это может быстро привести к большому количеству объектов. В конечном итоге Алисе, Фрэнку или Бобу может потребоваться запросить большое количество транзакций для передачи права собственности на данный тип токена. На схеме выше после трех раундов разделения объектов Фрэнк владеет четырьмя отдельными объектами USDC (выделены желтыми квадратами): один с номиналом 0,05 и три с номиналом 0,1. Ему нужно будет запросить четыре транзакции для передачи всех принадлежащих ему USDC, а не только одну.

В настоящее время Sui планирует предложить собственный API кошелька, который позволит пользователям «объединять» эти объекты малого номинала в один объект большего номинала. Это должно помочь очистить пул объектов. Тем не менее, необходимость разделять и снова объединять объекты добавляет уровень сложности к дизайну реестра и является одним из недостатков объектно-ориентированного подхода Sui.

Исполнение транзакции

Что касается фактического выполнения транзакций (т. е. запуска фактического кода), как Aptos, так и Sui могут выполнять неперекрывающиеся транзакции параллельно. Aptos использует новый механизм выполнения, называемый BlockSTM (Block Software Transactional Memory), для распараллеливания выполнения. Как и в некоторых других блокчейнах, если две транзакции в Aptos не затрагивают одни и те же адреса, код для каждой из них может быть запущен одновременно на разных ядрах обработки в пределах одного компьютера. Однако, в отличие от большинства других блокчейнов, BlockSTM не требует предварительного объявления зависимостей транзакции, что обеспечивает большую гибкость в типах транзакций, которые могут запрашивать пользователи.

На очень высоком уровне BlockSTM берет список последовательных транзакций и выполняет их все параллельно, как будто ни одна из них не касается одних и тех же адресов. Для транзакций, которые действительно касаются одних и тех же адресов или имеют одни и те же зависимости, BlockSTM будет повторно выполнять их, пока не сделает это в правильном порядке, чтобы получить правильный результат. Очень важно, что BlockSTM может непрерывно оценивать зависимости данной транзакции, чтобы минимизировать количество времени и усилий, затрачиваемых на повторное выполнение транзакций. Такой подход позволяет Aptos максимально распараллелить выполнение транзакций, не требуя подробных данных о последствиях и зависимостях транзакций.

В Sui код двух транзакций также может выполняться параллельно, если они не касаются одного и того же объекта. Однако для этого требуется, чтобы приложения, такие как кошелек пользователя, объявляли зависимости и/или объекты, на которые влияет данная транзакция. Преимущество этого подхода в том, что механизм выполнения Sui будет тратить гораздо меньше времени и усилий на повторное выполнение перекрывающихся транзакций, но это достигается ценой увеличения сложности данных, включенных в запросы транзакций.

Другие типичные блокчейны, включая Ethereum, выполняют все транзакции последовательно, одну за другой. Очевидно, что максимально возможное распараллеливание выполнения увеличивает потенциальную пропускную способность данного блокчейна, поэтому неудивительно, что и Aptos, и Sui сделали это ключевой частью своих архитектур. И снова мы можем визуализировать несколько сценариев, чтобы лучше понять, какие транзакции можно или нельзя распараллелить в Aptos и Sui.

В блокчейне Aptos код для двух транзакций выше не может быть выполнен параллельно, поскольку они взаимодействуют с одним и тем же адресом (Алисы). Одна из транзакций в конечном итоге должна быть выполнена после другой, чтобы убедиться, что у Алисы есть достаточный баланс для оплаты и Бобу, и Фрэнку. Порядок, в котором Боб и Фрэнк получают оплату (или не получают, если баланс Алисы слишком низок), определяется валидаторами блокчейна.

В объектно-ориентированном DAG Суи две вышеуказанные транзакции могут выполняться параллельно, поскольку они не взаимодействуют с одним и тем же объектом(ами), хотя обе они исходят от Алисы. Алиса меняет атрибут владельца двух отдельных объектов USDC, которыми она в настоящее время владеет. Во время выполнения этих двух платежей не требуется «проверка баланса».

Однако, как и прежде, транзакции Sui, требующие разделения одного объекта на два, считаются связанными и не могут выполняться параллельно. Валидаторы должны сначала выполнить разделение, а затем выполнить любые оставшиеся транзакции на результирующем объекте(ах).

И Aptos, и Sui могут выполнять вышеуказанные транзакции полностью параллельно, поскольку они не затрагивают одни и те же адреса или объекты.

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

Из раздела «Сертификация реестра» технического документа Aptos (выделено мной):

«На этом этапе конвейера каждый отдельный валидатор  вычислил новое состояние для зафиксированного блока транзакций . Однако для эффективной поддержки проверенных легких клиентов и синхронизации состояний блокчейн Aptos реализует сертификацию реестра для истории реестра, а также для состояния реестра. Одним из ключевых отличий блокчейна Aptos является то, что сертификация реестра не находится на критическом пути обработки транзакций и может быть запущена полностью вне диапазона, если это необходимо.Валидатор добавляет транзакции вместе с их выходными данными выполнения в глобальную аутентифицированную структуру данных реестра. Частью выходных данных транзакции является набор записей состояния, состоящий из изменений, внесенных в глобальное состояние, доступное Move. Короткий аутентификатор этой структуры данных является обязательным обязательством для истории реестра, которая включает в себя недавно выполненный пакет транзакций. Подобно выполнению транзакции, генерация этой структуры данных является детерминированной. Каждый валидатор подписывает короткий аутентификатор в новой версии результирующей базы данных. Валидаторы делятся своим последним набором подписанных коротких аутентификаторов друг с другом, коллективно объединяют подписанные кворумом короткие аутентификаторы, а также делятся последними подписанными кворумом короткими аутентификаторами друг с другом .

Валидаторы в Sui также обычно выполняют каждую транзакцию на своих компьютерах, но из-за архитектуры Sui на основе DAG состояние реестра не нужно замораживать, чтобы записать данную транзакцию в реестр. Вместо этого валидаторы Sui создают свое представление DAG, используя общедоступные данные транзакции (код), и используют систему контрольных точек для периодической проверки того, что их построенный DAG соответствует DAG достаточного количества валидаторов в сети. Эти контрольные точки, которые создает Sui, аналогичны блокам в традиционной архитектуре блокчейна. Однако, в отличие от традиционного блокчейна, если транзакция медленно проходит через процесс консенсуса, другие транзакции все равно могут быть записаны в реестр, не дожидаясь подтверждения медленной транзакции. Опять же, возможность обновлять независимый реестр каждого объекта может предоставить Sui преимущество в задержке в определенных случаях. Одним из потенциальных недостатков Sui является то, что валидаторы отвечают за отслеживание и построение собственного представления пула объектов. Таким образом, если между контрольными точками имеется большое количество сложных транзакций, для некоторых валидаторов может возникнуть проблема с синхронизацией состояния своего пула объектов с другими валидаторами.

Хранение транзакций

Последнее отличие, которое мы хотим подчеркнуть, касается того, как Aptos и Sui обрабатывают хранение данных. В типичной архитектуре блокчейна все выполненные транзакции остаются в реестре навсегда. В течение длительного периода времени это может привести к раздуванию состояния и материальным требованиям к памяти для валидаторов. При этом блокчейн Aptos представлен в виде дерева Меркла, что значительно снижает требования к хранению узлов валидаторов. Кроме того, узлы могут обрезать определенные данные транзакций и событий, чтобы снизить требования к хранению. Обе эти оптимизации должны снизить нагрузку на хранение для валидаторов и других узлов.

Как упоминалось ранее, одним из недостатков объектно-ориентированного дизайна Sui является то, что разделенные объекты могут быстро накапливаться и занимать ценное место для хранения на валидаторах и других узлах. Однако экономическая модель Sui включает стимулы и штрафы, призванные смягчить эту проблему. Во-первых, пользователи должны платить отдельные сборы за газ за выполнение и хранение. Сборы за хранение, которые устанавливаются руководством Sui, вносятся в фонд хранения, который используется для корректировки доли будущих валидаторов и увеличения их вознаграждений по мере роста их реальных потребностей в хранении. По сути, фонд хранения накапливает все большую долю токенов SUI и может делегировать эту долю валидаторам, чтобы платить им больше по мере роста их затрат на хранение. Кроме того, Sui позволяет пользователям фактически удалять объекты из реестра. Если объект не указан как «только для чтения», то его владелец(и) могут удалить его, если пожелают. Пользователи, удаляющие объекты, получают скидку на плату за хранение, что дает стимул бороться с раздуванием состояния. Модель программирования Sui также включает собственную функцию для обертывания объектов. Когда объект оборачивается, он встраивается в другой объект и по сути становится атрибутом этого объекта. С точки зрения памяти и хранения это имеет аналогичный эффект, что и полное удаление объекта. Наконец, возможность объединения определенных объектов с помощью API кошелька Sui может также помочь сократить использование памяти. Удаление, оборачивание и объединение объектов можно использовать для уменьшения раздувания состояния, если и когда это становится проблемой.

Важно отметить, что поскольку Aptos и Sui являются совершенно новыми компаниями уровня 1, раздувание штата вряд ли станет для них приоритетной проблемой в ближайшем будущем.

Наш вывод

Aptos и Sui представляют собой кульминацию многолетних исследований масштабируемости распределенного реестра, а их новые протоколы mempool и консенсуса обеспечивают существенное повышение производительности по сравнению с существующими архитектурами. Как и в случае с любым слоем 1, фактическая реализация соответствующих проектов Aptos и Sui будет основным фактором, определяющим их производительность в реальном мире. К счастью, оба этих новых участника ландшафта слоя 1 обладают опытом и капиталом для хорошей реализации своего видения. На наш взгляд, объектно-ориентированный DAG Sui, по-видимому, обеспечивает определенные преимущества по сравнению с традиционными блокчейнами с точки зрения пропускной способности и задержки, по крайней мере в теории. Однако это может быть достигнуто за счет легкой делимости активов и дополнительной нагрузки на валидаторов. В любом случае, оба протокола все еще находятся на ранних стадиях разработки, поэтому мы можем увидеть, как их соответствующие преимущества в производительности со временем уменьшаются по мере улучшения каждого из них. В любом случае, оба этих новых слоя 1 являются весьма амбициозными начинаниями, которые, как мы ожидаем, продвинут возможности слоя 1 и нашу отрасль вперед.