Мы живем в мультисетевом мире. Идея о том, что все децентрализованные приложения будут использовать один и тот же общий блокчейн смарт-контрактов, на практике мертва. Эфириум переходит к дорожной карте, в которой приложения имеют свои собственные цепочки свертки данных, растет популярность многоцепочечных экосистем, таких как Cosmos и Polkadot, а также альтернативных цепочек уровня 1, таких как Solana и Polygon. Сегодня децентрализованные приложения разбросаны по разным блокчейнам.
Однако цепочкам, в которых находятся приложения, нужен способ обмена данными между собой (межсетевая совместимость), чтобы позволить приложениям в этих цепочках читать и записывать состояние друг друга (композитивность . В совокупности это обычно известно как межсетевая коммуникация .
В этом посте мы изложим некоторую теорию и практику того, как мы в Celestia думаем об общем пространстве проектирования межсетевых коммуникаций, основываясь на идее кластеров цепочек. В двух словах, мы представляем себе модель экосистемы блокчейна, в которой цепочки, использующие один и тот же кластер, могут объединяться друг с другом с минимальным доверием (внутрикластерная связь). Цепочки между кластерами составляются друг с другом таким образом, что требуются менее безопасные предположения , основанные на доверии (межкластерная связь).
Коммуникация между сетями требует компромиссов безопасности
Как показали Замятин и соавт. , безопасная связь между блокчейнами без доверенной третьей стороны или предположения о синхронности невозможна. Безопасный в этом контексте означает атомарный . Например, если Алиса перемещает 5 монет из цепочки A в цепочку B, то это включает в себя две транзакции: (1) вычитание баланса Алисы на 5 монет в цепочке A и (2) увеличение его на 5 монет в цепочке B. Для кросс- чтобы цепная связь была атомарной, должны происходить либо обе, либо ни одна из этих транзакций. Если происходит только одна из этих транзакций (например, баланс Алисы вычитается в цепочке A, но не увеличивается в цепочке B), она не является атомарной.
Это означает, что возможность компоновки между несколькими цепочками всегда будет иметь компромиссы в плане безопасности по сравнению с простым использованием одной цепочки, где атомарность межконтрактных вызовов гарантируется без доверенной третьей стороны или синхронности в соответствии с правилами валидности блока. Это связано с тем, что пользователи могут запускать полностью проверяющие узлы и отклонять недопустимые блоки в своем локальном представлении.
Мы можем считать, что (неофициально) есть два ключевых компонента для обеспечения атомарной межцепочечной связи:
- Жизнеспособность реле: если происходит транзакция, которая изменяет состояние цепочки A таким образом, что это влияет на состояние цепочки B, то какая-то транзакция в конечном итоге должна быть отправлена в цепочку B (будь то пользователем, ретранслятором или какой-либо другой стороной). чтобы завершить транзакцию. Например, если Алиса заблокирует несколько монет в цепочке A, чтобы переместить их в цепочку B, в конечном итоге должна быть отправлена соответствующая транзакция, чтобы увеличить баланс Алисы в цепочке B.
- Проверка состояния: когда цепочка A и цепочка B предпринимают действия на основе состояний друг друга, они должны быть уверены, что полученная ими информация о состоянии действительно соответствует согласованному и действительному состоянию цепочки в соответствии с действительностью транзакции цепочки. правила. Обратите внимание, что живость требует государственной проверки. Более подробно о проверке состояния между цепочками см. Zamyatin et al.
Определение «доверенной третьей стороны» является широким. Блокчейн сам по себе является доверенной третьей стороной; он просто распределяет доверие между большинством участников консенсусного протокола (допущение честного большинства). DAO также может быть доверенной третьей стороной.. Например, в случае моста между стандартной боковой цепью (или цепью уровня 1) и родительской цепью консенсус боковой цепи может заблокировать или украсть средства, внесенные в боковую цепь через родительскую цепь. Это связано с тем, что для проверки состояния родительская цепочка не проверяет транзакции в самой боковой цепи. Вместо этого он надеется, что операторы сайдчейна (т. е. консенсус) только перемещают депонированные средства в родительской цепочке в соответствии с правилами действительности транзакций сайдчейна. Такой мост является доверенным мостом, потому что он основан на предположении честного большинства, чтобы предотвратить кражу средств операторами моста, например, мосты Ethereum-Polygon и Ethereum-Solana.
Однако свертки не требуют допущений честного большинства для проверки состояния, чтобы гарантировать атомарность депозитов или снятия средств, потому что основная цепочка косвенно проверяет действительность транзакции свертки, используя такие методы, как доказательства ZK или доказательства мошенничества. Однако вывод средств из накопительных сумм через родительскую цепочку требует наличия доверенной третьей стороны в виде очень слабого допущения честного меньшинства для жизнеспособности: по крайней мере один ретранслятор или агрегатор должен публиковать блоки накопительных сумм в родительской цепочке. В случае свертки, где любая сторона может быть ретранслятором или агрегатором, и, таким образом, сам пользователь может выполнять эту роль, требуется допущение о синхронности .(т.е. существует синхронная сеть, так что когда пользователь отправляет сообщение, оно будет получено сетью в течение определенного периода времени). 1
Кластеры
Таким образом, мы можем разделить межсетевые коммуникации на две основные категории:
- Межсетевое общение с минимальным доверием , которое опирается либо на честное меньшинство, либо на предположение о синхронности для обеспечения жизнеспособности и проверки состояния. Многие протоколы имеют «гибридную» модель , в которой по умолчанию пользователи полагаются на предположение о честном меньшинстве, но могут переключиться на предположение о синхронности, если предположение о честном меньшинстве не работает.
- Надежная межсетевая коммуникация, основанная на допущении честного большинства для обеспечения жизнеспособности и проверки состояния.
Следует отметить, что такие мосты, как Nxtp , требующие допущения о синхронности на стороне клиента, считаются требующими допущения честного большинства для проверки состояния. Это связано с тем, что даже если цепочки по обе стороны моста активны, клиенты не могут воздействовать на состояние цепочек, если в цепочках нет доступных данных . Проверка наличия данных является частью государственной проверки . 3
Мы можем определить кластер как набор цепочек, которые взаимодействуют друг с другом ( внутрикластерная связь ) с межцепочечной связью с минимальным доверием, в том числе с использованием проверки состояния с минимальным доверием, такой как доказательства мошенничества, доказательства достоверности или прямая проверка транзакций. Кластер может, например, представлять собой набор агрегаций, подключенных к родительской цепочке (как в случае агрегации Ethereum), или автономных цепочек уровня 1, таких как Polygon или Solana.
Ключевым свойством кластера является то, что каждая цепочка в кластере может проверять конечный автомат каждой другой цепочки в кластере. Например, все накопительные пакеты Ethereum совместимы с EVM, поэтому можно проверить доказательства мошенничества или ZK накопительных пакетов в EVM. Однако практически невозможно проверить конечный автомат Solana в EVM, поэтому Solana не может использовать общий кластер с Ethereum.
Кластеры также могут взаимодействовать с другими кластерами ( межкластерная связь ) с помощью доверенной межцепочечной связи, используя методы проверки состояния, которые не минимизируют доверие, например, полагаясь на комитет из 2/3 валидаторов для подписания блоков. Мост Ethereum-Polygon является примером этого.
Следует отметить, что кластеры являются суверенными, а это означает, что цепочка в кластере A не может привести цепочку в кластере B внутрь круга кластера A без хардфорка кластера A или B. Например, невозможно создать накопительный пакет Ethereum, который создает мост с минимальным доверием между этим накопительным пакетом и Polygon, не изменяя Polygon для реализации в качестве накопительного пакета (т. е. делая его мошенническим или доказуемым ZK), чтобы, например, ввести его внутрь кластера Ethereum. (Точно так же одна страна не может навязать свой закон другой стране без международного соглашения, если только она не вторгнется в эту страну или не произойдет революция. 4 )
Компромисс между безопасной компоновкой и масштабируемостью
Выше мы установили, что связь между несколькими цепочками всегда требует компромисса с безопасностью по сравнению с связью между смарт-контрактами в одной цепочке.
Однако зачем вообще идти на этот компромисс? Почему бы просто не разместить все транзакции в одной цепочке и обеспечить для всех простую и безопасную компоновку? К сожалению, существуют теоретические пределы того, насколько масштабируемой может быть отдельная цепочка , даже с использованием самых известных на сегодняшний день методов масштабируемости. Расширение до нескольких цепочек является необходимостью.
Точно так же существуют ограничения на размер одного кластера цепочек, включая набор сверток в основной цепочке. Прогнозируется, что даже с учетом агрегации Ethereum 2.0 в настоящее время будет обрабатывать около 100 000 транзакций в секунду .
Два важных основных ограничения, которые ограничивают размер кластера:
- Требование ко всем цепочкам в кластере понимать среду выполнения друг друга. Например, если у вас есть набор оптимистичных сверток на основе EVM, которые взаимодействуют друг с другом, они должны иметь возможность понимать EVM, чтобы понимать доказательства мошенничества друг друга. Аналогично с накопительными пакетами ZK, они должны понимать системы проверки ZK друг друга. Если вы хотите создать накопительный пакет с использованием новой среды выполнения, вы должны создать свой собственный кластер или выполнить жесткую разветвление существующего кластера.
- Емкость доступности данных кластера. Чтобы поддерживать проверку состояния между всеми цепочками в кластере с минимальным доверием, каждая цепочка должна проверять доступность данных блоков каждой другой цепочки в этом кластере с минимальным доверием, либо путем загрузки данных напрямую, либо с использованием методов. такие как доказательства наличия данных . Даже при теоретически оптимальных доказательствах доступности данных существует ограничение на размер одного кластера из-за ограничений ресурсов производителей блоков (т. е. требований к целевым ресурсам для запуска валидатора). 2
На практике мы можем наблюдать, что модель кластеризации — это уже то, как работает экосистема блокчейна в реальном мире — набор цепочек уровня 1 и сверток с внутрикластерными и межкластерными мостами друг с другом (см. диаграмму выше). Однако межкластерные мосты сопряжены с серьезными проблемами безопасности — вы должны быть уверены, что набор валидаторов не украдет ваши средства. Таким образом, блокчейн-сообщество должно обеспечить максимальную масштабируемость внутри кластера (например, с помощью свертки), чтобы были достигнуты ограничения каждого кластера, прежде чем запускать новые кластеры, которые полагаются на менее безопасную связь между кластерами.
Кластеры в Celestia
Celestia предоставляет подключаемый уровень консенсуса и доступности данных для блокчейнов, включая сводные данные. Это блокчейн, в котором консенсус и выполнение разделены, поскольку он не обеспечивает среду для смарт-контрактов в цепочке, такую как Ethereum, а только консенсус и доступность данных. Экосистема Celestia сама по себе не является кластером, поскольку не использует какой-либо конкретный механизм межцепочечной связи между цепочками на основе Celestia, но обеспечивает основной компонент для создания кластеров.
Как упоминалось в предыдущем разделе, внутрикластерная связь требует проверки состояния с минимальным доверием, что требует проверки доступности данных всех цепочек в кластере. Это потому что:
- в случае оптимистичной свертки клиентам необходимо проверить, опубликованы ли блоки свертки, чтобы убедиться, что полные узлы имеют данные для создания доказательств мошенничества при переходе состояния;
- в случае свертки ZK клиенты должны проверить, что блоки свертки были опубликованы, чтобы быть уверенными, что узлы могут знать состояние цепочки (например, балансы счетов); а также
- в других случаях, когда цепочки полностью проверяют транзакции друг друга напрямую, вам, очевидно, нужно знать, что это за транзакции, чтобы их валидировать.
Таким образом, Celestia предоставляет основной компонент для построения кластера цепей: уровень доступности данных. Сами кластеры располагаются выше этого уровня, на уровне исполнения (как показано на диаграмме выше). Чтобы кластер поддерживал внутрикластерные связи, все цепочки в кластере должны проверять, что блоки друг друга были включены в цепочку доступности данных Celestia, и, таким образом, могут выполнять проверку состояния друг друга с минимальным доверием, используя один из три описанные выше техники.
С этой целью важным проектом, над которым мы работаем, является optimint , замена Tendermint, которая позволяет разработчикам создавать цепочки на основе Cosmos в виде сверток, которые могут использовать другие цепочки, такие как Celestia, в качестве уровня консенсуса и доступности данных. В будущем наша цель — сделать так, чтобы зоны Cosmos на основе объединения могли формировать кластер друг с другом с использованием протокола Inter-Blockchain Communication (IBC) .
Вывод
Недавно произошел кембрийский взрыв команд, работающих на поперечных цепных мостах. По мере развития пространства мы считаем важным, чтобы экосистема пришла к общей модели и языку для мостов между цепями. В этом посте мы определили естественную классификацию мостов между цепочками: мосты с минимальным доверием , которые образуют кластеры, и доверенные мосты .
Спасибо Юрию Стрикеру, Василию Шаповалову, Нику Уайту, Исмаилу Хоффи, Алексею Замятину, DeFi Frog, epolynya, Dankrad Feist, Patrick McCorry, Layne, Arjun Bhuptani и Hasu за комментарии к этому посту.
Сноски
1. Следует отметить, что родительская цепочка требует допущения честного большинства для включения выводов из агрегации в цепочку. Однако в этой модели мы предполагаем, что обе цепочки обладают постоянством и живучестью (см. определения 1 и 2 в Zamyatin et al. ), так что если транзакция будет отправлена в цепочку, она в конечном итоге будет включена в цепочку.
2. Это верно, даже если у вас есть сегменты данных, потому что накладные расходы на загрузку дополнительного заголовка блока для каждого сегмента означают, что сегментирование не масштабируется линейно.
3. Допущение честного большинства для проверки состояния в протоколах атомарного обмена, таких как Nxtp, не обязательно имеет значение, если два контрагента являются пользователями, которые сами проверяют цепочки. Однако это имеет значение в случае протоколов «зафиксируй и отчекани», когда активы изымаются из одной цепочки и депонируются в другой, где контрагентами являются две цепочки.
4. См. эту статью о DAO как интернет-конституциях .