Rollups как суверенные цепочки

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

В этом посте мы обсудим, что такое роллапы, как они сейчас работают на Ethereum и как они будут работать на Celestia.

С текущими агрегациями Ethereum цепочка Ethereum закреплена за агрегацией в качестве уровня расчетов, что делает агрегацию Ethereum фактически «дочерней цепочкой» для Ethereum, где правильная цепочка агрегации определяется смарт-контрактом на Ethereum. Это также сопоставимо с моделью парачейна Polkadot, где ретрансляционная цепочка закреплена в качестве расчетного уровня для парачейнов.

Однако в Celestia мы представляем новый тип объединения: суверенные цепочки объединения. Это независимые суверенные цепочки, в которых правильная цепочка свертки определяется самой подсетью свертки, аналогично независимой L1, и могут дополнительно иметь доверенные мосты или мосты с минимальным доверием с другими цепочками или расчетными уровнями.

Оглавление

• Что такое роллапы?
• Роллапы на Ethereum (закрепленные расчеты)
• Роллапы на Celestia (соверен)
• Суверенные кросс-сводные коммуникации
• Почему государь?

Что такое Rollups ?

Rollups  — это блокчейны, которые размещают свои блоки в другом блокчейне и наследуют консенсус и доступность данных этого блокчейна (называемые «уровнем консенсуса и доступности данных»).

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

Секвенсоры — это узлы, которые получают от пользователей новые сводные транзакции, объединяют транзакции в блок и отправляют этот блок на уровень консенсуса и доступности данных. Блок состоит из двух компонентов: заголовка блока и фактических данных транзакции. Заголовок блока содержит, среди прочего, криптографическое подтверждение состояния цепочки — обычно это корень Меркла.

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

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

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

За более подробным и техническим объяснением сверток мы отсылаем читателя к этой статье на форуме Celestia, посвященной сверткам .

Rollups на Ethereum (регулированное хранение)

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

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

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

Rollups на Celestia (суверенный)

Суверенные накопительные пакеты на Celestia не публикуют свои блоки в смарт-контракте, а непосредственно в цепочке в виде необработанных данных. Уровень консенсуса и доступности данных Celestia не интерпретирует и не выполняет никаких вычислений в блоках свертки, а также не запускает облегченный клиент в цепочке для свертки.

Вместо этого накопительный пакет эффективно работает как блокчейн уровня 1: полные узлы и легкие клиенты загружают блоки накопительного пакета непосредственно из его собственной одноранговой сети. Основное отличие состоит в том, что они также проверяют, были ли данные блока свертки включены и упорядочены на уровне доступности данных Celestia с помощью доказательства Меркла. Таким образом, подобно блокчейну уровня 1, каноническая цепочка определяется узлами, которые локально проверяют правило выбора форка и транзакции объединения, а не закрепленным в цепочке легким клиентом.

Доказательства мошенничества и достоверности также работают так же, как и в блокчейне уровня 1. Доказательства мошенничества передаются клиентам напрямую через одноранговую сеть, а доказательства достоверности просто включаются в заголовок блока (например, см. Mina Protocol ). Поскольку задержка сетевой синхронизации в одноранговой сети, вероятно, будет значительно меньше, чем задержка включения доказательства мошенничества в цепочку, это означает, что период проверки для доказательств мошенничества в одноранговой сети, вероятно, может быть намного больше. ниже, что приводит к более быстрому завершению для легких клиентов.

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

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

«Не закреплять расчетный уровень» — это, прежде всего, социальное различие, а не техническое, что означает, что между сообществом накопительного пакета существует общественный договор о том, что правила действительности транзакций накопительного пакета определяются сообществом, а не неизменным контрактом L1. На практике это означает, что мосты к свертыванию, которые не закреплены, должны быть изменяемыми, чтобы существовал путь обновления, который признает хардфорки в суверенном свертывании (обсуждается в следующем разделе).

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

Суверенные накопительные пакеты также могут использовать Ethereum только в качестве уровня доступности данных без закрепления Ethereum для расчетов, однако это увеличивает накладные расходы по сравнению с использованием «чистого» уровня доступности данных, такого как Celestia, поскольку узлы агрегации должны быть заинтересованы в достоверности все транзакции на уровне расчетов Ethereum, чтобы запустить узел для уровня доступности данных Ethereum.

Также возможно построить «сводку поселений» на Celestia , которая является разновидностью суверенной свертки. Расчетный накопительный пакет может иметь несуверенные накопительные пакеты, которые используют его в качестве закрепленного расчетного слоя. Однако уровень расчетов является суверенным так же, как Ethereum L1 является суверенным, поскольку его сообщество часто обновляет его с помощью хард-форков посредством социального консенсуса.

Суверенные кросс-сводные коммуникации

Как упоминалось выше, накопительные пакеты Celestia не имеют встроенного моста между накопительным пакетом и каким-либо уровнем расчета. Таким образом, уровень расчетов и уровень выполнения сводного пакета разделены и модульны. Итак, как накопительные пакеты Celestia могут соединяться с другими сетями? Отсутствие закрепленного расчетного слоя позволяет нам иметь более широкое пространство для проектирования мостов с перекрестными цепями. Мы исследуем пространство дизайна и различные варианты ниже.

Предположим, что некоторая суверенная цепочка свертки A хочет соединиться с другой цепочкой B, которая, как мы предполагаем, также является свертой.

Одноранговые сети и расчеты по ним

Сети A и B могут напрямую встраивать легкий клиент друг для друга в легкие клиенты обеих цепочек. Например, обе цепочки будут запускать легкий клиент для цепочек A и B. Таким образом, легкие клиенты будут получать заголовки блоков и любые связанные с ними доказательства мошенничества или достоверности напрямую через одноранговую сеть. Мы называем это равноправным расчетом .

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

С другой стороны, легкие клиенты также могут быть реализованы как смарт-контракты в сети, а заголовки блоков и доказательства мошенничества/ZK будут отправлены в смарт-контракты в сети. Это статус-кво с накопительными пакетами Ethereum. Мы называем это расчетами по цепочке .

Мост «ступица-и-спица» против моста «точка-точка»

В настоящее время ожидается, что накопительные пакеты будут связаны с одним уровнем расчетов, который выступает в качестве центра расчетов, таким как Ethereum (мост по схеме « звезда » ). Если цепочки свертки A и B подключены к одному и тому же хабу, то они могут соединять активы друг с другом, используя хаб в качестве посредника для расчетов.

Однако, как и IBC, накопительные пакеты также могут напрямую соединяться друг с другом, а не использовать промежуточную цепочку узлов ( точка-точка ).

Динамическое и статическое мостовое соединение

В зависимости от среды выполнения цепочек объединения может потребоваться обновление цепочки или хард-форк для соединения новых цепочек. Это связано с тем, что цепочки A и B должны поддерживать среды выполнения друг друга, чтобы поддерживать доказательства мошенничества или ZK друг друга.

Предположим, что конечный автомат оптимистичной цепочки свертки A написан непосредственно на Golang (например, с использованием Cosmos SDK), а не в среде смарт-контрактов, такой как EVM или CosmWasm. Чтобы соединиться с цепочкой B, цепочке B потребуется обновить программное обеспечение своего узла, чтобы включить конечный автомат цепочки A в качестве библиотеки для проверки доказательств мошенничества в цепочке A. Это связано с тем, что цепочка B не может автоматически добавлять код конечного автомата цепочки A, потому что он может быть вредоносным или недетерминированным, что создает угрозу безопасности. Поэтому необходим общественный консенсус или управление, чтобы добавить такой мост. Это также будет необходимо в случае свертывания достоверности, в котором используется конструкция доказательства ZK, не понятная цепочкой B. Мы называем это статическим мостом ., потому что мосты должны быть явно добавлены при обновлении цепочки. Такой мост может быть реализован как легкий клиент IBC .

С другой стороны, если оптимистичная цепочка свертки A написана в изолированной среде смарт-контрактов, такой как EVM или CosmWasm, то цепочка B может позволить добавить код конечного автомата цепочки A непосредственно в конечный автомат цепочки B без какой-либо необходимости. для социального консенсуса или управления, например, с использованием смарт-контракта. Точно так же, если бы цепочка A была сверткой ZK, ее можно было бы динамически связать с цепочкой B, если цепочка B способна понимать доказательства ZK цепочки A. Мы называем это динамическим мостом .

Незакрепленный и закрепленный расчетный слой

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

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

Мосты на основе комитетов против мостов на основе доказательств

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

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

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

Модернизируемые и non-upgradeable мосты

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

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

• Для статического моста цепь B также должна пройти хардфорк. Такой путь обновления будет означать, что мост минимизирует доверие, поскольку в нем не участвует мультиподпись или комитет.
• Для динамического моста комитет (например, DAO), контролируемый цепочкой A, может обновить легкий клиент в цепочке B. Это будет доверенный мост.
• Для динамического моста комитет (например, DAO), контролируемый цепочкой B, может обновить легкий клиент в цепочке B. Если цепочка B является расчетным уровнем, это возлагает ответственность за реализацию обновлений на расчетный уровень, что может быть желательно, если слой поселений имеет специализированное управление для этого или имеет высокую экономическую безопасность. Это также будет доверенный мост.

Почему суверенитет?

По своей сути накопительные пакеты — это просто блокчейны, а накопительные мосты — просто легкие клиенты для этих блокчейнов. Текущий статус-кво для накопительных пакетов, популяризированных Ethereum, направлен на не обновляемые накопительные пакеты с закрепленным уровнем расчетов. Это эквивалентно запуску клиента для блокчейна, который никогда не может быть обновлен, чьи блоки действительны только в том случае, если они приняты одним закрепленным в цепочке экземпляром легкого клиента для объединения. Как мы показали выше, это лишь небольшое подмножество пространства для проектирования сверток.

В Celestia Labs мы заинтересованы в суверенных объединениях без закрепленного уровня расчетов, потому что мы считаем, что самый важный уровень в блокчейнах — это социальный консенсус. В частности, блокчейны — это инструмент, позволяющий сообществам осуществлять суверенную социальную координацию, не обременяясь статус-кво. Это означает, что хардфорки следует рассматривать как функцию, а не как ошибку, поскольку хардфорки дают суверенным сообществам возможность добиваться социального консенсуса. Это особенно важно в качестве механизма социальной защиты, когда что-то идет не так, как, например, в случае разветвления Eth после взлома DAO .

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

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

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