Однако эти события также вызвали серьезную озабоченность. Если модульность является окончательным решением для масштабирования, и эти протоколы являются важнейшими компонентами этого решения, они, вероятно, заблокируют огромное количество BTC и ETH. Это ставит под сомнение безопасность самих протоколов. Станет ли сложная многослойность, образованная многочисленными протоколами LSD (Liquid Стейкинг Деривативы) и LRT (Уровень 2 Rollup Tokens), самым большим черным лебедем в будущем блокчейна? Здрава ли их коммерческая логика? Поскольку мы уже анализировали EigenLayer в наших предыдущих статьях, следующее обсуждение будет сосредоточено в первую очередь на Babylon, чтобы решить эти проблемы.
Первая фракция использует достаточно безопасный уровень 1 (обычно Ethereum) в качестве трех нижних уровней или части функциональных слоев для роллапов. Это решение обеспечивает высочайшую безопасность и легитимность и может поглощать ресурсы из экосистемы основной цепочки. Тем не менее, он может быть не особенно удобным с точки зрения пропускной способности и стоимости для конкретных накопительных пакетов (цепочки приложений, цепочки лонг-tail и т. д.).
Вторая фракция стремится создать существование, близкое к безопасности Биткойна и Ethereum, но с лучшими показателями затрат, таких как Celestia. Celestia достигает этого за счет использования чистой архитектуры функций DA, минимизации требований к аппаратному обеспечению узлов и низких затрат на газ. Этот упрощенный подход направлен на создание уровня DA, который соответствует безопасности и децентрализации Ethereum, обеспечивая при этом высокую производительность в кратчайшие сроки. Недостатком этого подхода является то, что его безопасности и децентрализации все еще требуется некоторое время, чтобы полностью развиться, и ему не хватает легитимности, поскольку он находится в прямой конкуренции с Ethereum, что ведущее к отторжению сообществом Ethereum.
Третий тип в этой фракции включает в себя Babylon и EigenLayer. Они используют основную концепцию Proof-of-Stake (POS), используя стоимость активов Биткойн или Ethereum для создания общих служб безопасности. По сравнению с первыми двумя типами, это более нейтральное существование. Его преимущество заключается в том, что он наследует легитимность и безопасность, а также обеспечивает большую полезность активов основной цепочки и предлагает большую гибкость.
Для другой половины мира блокчейна, особенно после того, как Ethereum перешел на PoS после обновления в Шанхае, можно сказать, что большинство публичных сетей используют разные архитектуры PoS для достижения консенсуса по умолчанию. Однако новые разнородные сети часто не могут привлечь значительный капитал стейкинга, что ставит под сомнение их безопасность. В нынешнюю модульную эру зоны Cosmos и различные решения Уровень 2 могут использовать различные уровни DA для компенсации, но это часто происходит за счет автономности. Для большинства старых механизмов PoS или цепочек консорциумов использование Ethereum или Celestia в качестве уровня DA также в целом непрактично. Ценность Babylon заключается в том, чтобы заполнить этот пробел за счет использования стейкинга BTC для обеспечения защиты цепочек PoS. Точно так же, как человечество использовало золото для поддержки стоимости бумажной валюты, BTC хорошо подходит для того, чтобы играть эту роль в мире блокчейна.
Разбивая основные элементы, которые в настоящее время использует Биткойн, по сути, следующие: 1. Модель UTXO, 2. Временные метки, 3. Различные методы подписи, 4. Основные коды операций. Учитывая ограниченную программируемость Биткойна и его пропускную способность, решение Babylon основано на принципе минимализма. В биткойне необходимо выполнить только основные функции для контрактов на стейкинг, а это означает, что стейкинг, разрезание, вознаграждение и извлечение BTC обрабатываются в основной цепочке. Как только это соотношение 0 к 1 будет достигнуто, более сложные требования могут быть обработаны зоной Cosmos. Тем не менее, остается критический вопрос: как записать данные цепочки PoS в основную цепочку?
Babylon также необходимо использовать UTXO для реализации контрактов на стейкинг (Babylon называет это удаленным стейкингом, где безопасность биткойна удаленно передается в цепочки PoS через промежуточный уровень). Реализацию контракта можно разбить на четыре шага, умело комбинируя существующие опкоды:
Блокировка средств
Пользователи отправляют средства на адрес, контролируемый мультиподписью. Через OP_CTV (OP_CHECKTEMPLATEVERIFY, который позволяет создавать предопределенные шаблоны транзакций, гарантируя, что транзакции могут быть выполнены только в соответствии с определенными структурами и условиями), в контракте может быть указано, что эти средства могут быть потрачены только при определенных условиях. После блокировки средств генерируется новый UTXO, указывающий на то, что эти средства были поставлены.
Проверка состояния
При вызове OP_CSV (OP_CHECKSEQUENCEVERIFY, который позволяет установить относительную блокировку времени на основе порядкового номера транзакции, указывая, что UTXO может быть потрачен только после определенного относительного времени или количества блоков), можно реализовать блокировку времени. В сочетании с OP_CTV это может обеспечить стейкинг, отмену стейкинга (позволяя стейкеру тратить заблокированные UTXO после истечения периода стейкинга) и разрезание (принудительное расходование UTXO на заблокированный адрес, если стейкер действует злонамеренно, делая его нерасходуемым, подобно адресу черной дыры).

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


Разобравшись в базовой реализации Протокола, не требующей доверия, давайте углубимся в то, как сам Вавилон соединяет два конца с помощью зоны Космоса. Согласно подробному объяснению Стэнфордской лаборатории Це на Вавилоне, Babylon может получать потоки контрольных точек из нескольких цепочек PoS и объединять эти контрольные точки для публикации в биткойне. Используя агрегированные подписи от валидаторов Babylon, размер контрольных точек может быть сведен к минимуму, а частота этих контрольных точек контролируется, позволяя валидаторам Babylon изменяться только один раз за эпоху.
Валидаторы из различных цепочек PoS загружают блоки Babylon, чтобы проверить, включены ли их контрольные точки PoS в блоки Babylon, проверенные биткойном. Это позволяет цепочкам PoS обнаруживать несоответствия, например, если валидаторы Babylon создают недоступный блок, проверенный Биткойном, и лгут о содержащихся в нем контрольных точках PoS. Основными составляющими Протокола являются:
· Контрольные точки: Биткойн проверяет только последний блок эпохи Вавилона. Контрольная точка состоит из хеша блока и одной агрегированной подписи BLS, соответствующей подписям большинства в две трети валидаторов, подписавших блок для окончательности. Вавилонские контрольно-пропускные пункты также включают в себя номер эпохи. Блоки PoS могут назначать временные метки Биткойна через контрольные точки Babylon. Например, первые два блока PoS помечены блоками Babylon, которые затем проверяются блоком Биткойн с t_3 меткой времени. Следовательно, этим блокам PoS присваивается Биткойн t_3 метки времени.

· Канонические цепочки PoS: Когда происходит форк цепочки PoS, цепочка с более ранней меткой времени считается канонической цепочкой PoS. Если две вилки имеют одинаковую временную метку, связь разрывается в пользу блока PoS с более ранней контрольной точкой на Babylon.

· Правила вывода средств: Для вывода средств валидаторы отправляют запрос на вывод средств в цепочку PoS. Блок PoS, содержащий запрос на вывод средств, затем проверяется Babylon, а затем Биткойн, присваивая ему временную метку t_1. Как только блок Биткойн с временной меткой t_1 достигает глубины k, вывод средств осуществляется в цепочке PoS. Если валидатор с выведенными стейками попытается провести атаку в диапазоне лонг, блокам в цепочке атак может быть присвоена метка времени только позже t_1. Это связано с тем, что как только блок Биткойн с t_1 метки времени достигает глубины k, его нельзя откатить. Наблюдая за ордерами этих контрольных точек на Биткойне, клиенты PoS могут отличить каноническую цепочку от цепочки атак и игнорировать последнюю.

· Правила слэшинга: Если валидаторы не выводят свои стейки при обнаружении атаки, они могут быть слэшены за наличие конфликтующих блоков PoS с двойной подписью. Вредоносные PoS валидаторы знают, что если они будут ждать, пока их запрос на вывод средств не будет одобрен, чтобы запустить атаку лонг диапазона, они не смогут обмануть клиентов, которые могут обратиться к Биткойн для идентификации канонической цепочки. Следовательно, они могут форк цепочки PoS, присваивая временные метки биткойна блокам в канонической цепочке PoS. Эти PoS валидаторы в сотрудничестве с вредоносными майнерами Babylon валидаторы и Биткойн форк Babylon и Биткойн заменить блок Биткойн с меткой времени t_2 на другой блок с t_3 метки времени. В последующем представлении клиентов PoS это изменит каноническую цепочку PoS с верхней цепочки на нижнюю цепочку. Несмотря на то, что это успешная атака на безопасность, она приводит к разрезание стейков вредоносных PoS валидаторы, потому что они дважды подписывают конфликтующие блоки, не снимая свои ставки.

· Недоступность PoS Правила приостановки контрольных точек: PoS валидаторы должны приостановить свою цепочку PoS, заметив недоступную PoS контрольную точку на карте «Вавилон». Недоступная контрольная точка PoS определяется как хеш, подписанная двумя третями PoS валидаторы, что предположительно соответствует блоку PoS, который невозможно наблюдать. Если PoS валидаторы не приостановите цепочку PoS при обнаружении недоступной контрольной точки, злоумышленник может раскрыть ранее недоступную цепочку атак, изменив каноническую цепочку в последующих клиентских представлениях. Это связано с тем, что контрольная точка теневой цепи, обнаруженная позже, появляется ранее на Вавилоне. Приведенное выше правило приостановки объясняет, почему мы требуем, чтобы хеши блоков PoS, отправленные в качестве контрольных точек, были подписаны набором валидаторов PoS. Если эти контрольные точки не подписаны, любой злоумышленник может отправить произвольный хеш, утверждая, что это хеш недоступной контрольной точки блока PoS в Babylon. В этом случае PoS валидаторы придется остановиться на контрольно-пропускном пункте. Обратите внимание, что создать недоступную цепочку PoS непросто: для того, чтобы подписать блок PoS, не предоставив данные честным валидаторы, требуется скомпрометировать не менее двух третей PoS валидаторы. Однако в предполагаемой атаке, описанной выше, злоумышленник приостанавливает цепочку PoS, не ставя под угрозу ни одного валидатора. Чтобы предотвратить подобные атаки, мы требуем, чтобы PoS контрольно-пропускные пункты были подписаны двумя третями PoS валидаторы. Следовательно, на Вавилоне не будет недоступных PoS контрольно-пропускных пунктов, если только две трети PoS валидаторы не будут скомпрометированы, что крайне маловероятно из-за стоимости компрометации PoS валидаторы и не повлияет на другие цепочки PoS или сам Вавилон.
· Недоступность правил приостановки контрольных точек Babylon: валидаторы PoS и Babylon должны приостановить блокчейн при обнаружении недоступной контрольной точки Babylon на биткойне. Недоступная контрольная точка Babylon определяется как хеш с агрегированной подписью BLS двух третей валидаторов Babylon, что предположительно соответствует блоку Babylon, который невозможно наблюдать. Если валидаторы Babylon не приостанавливают блокчейн Babylon, злоумышленник может раскрыть ранее недоступную цепочку Babylon, изменив каноническую цепочку Babylon в более поздних клиентских представлениях. Аналогичным образом, если PoS валидаторы не приостановите цепочку PoS, злоумышленник может раскрыть ранее недоступную цепочку атак PoS и цепочку Babylon, изменив каноническую цепочку PoS в более поздних клиентских представлениях. Это связано с тем, что глубокая цепочка Вавилона, раскрытая позже, имеет более раннюю временную метку на Биткойн и включает в себя контрольные точки позже обнаруженной цепочки атак PoS. Подобно правилу приостановки на недоступных контрольных точках PoS, это правило объясняет, почему мы требуем, чтобы хеши блоков Babylon, отправляемые в качестве контрольных точек, имели агрегированную подпись BLS, подтверждающую подписи двух третей валидаторы Babylon. Если бы контрольные точки Babylon были неподписанными, любой злоумышленник мог бы отправить произвольный хеш, утверждая, что это хеш недоступной контрольной точки блока Babylon на Биткойне. PoS валидаторы и Babylon валидаторы должны были бы ждать контрольно-пропускного пункта, в прообразе которого нет недоступных цепей Babylon или PoS. Чтобы создать недоступную вавилонскую цепь, необходимо скомпрометировать, по крайней мере, две трети вавилонской валидаторы. Однако в предполагаемой атаке, описанной выше, злоумышленник приостанавливает все цепочки в системе, не компрометируя ни одного валидатора Babylon или PoS. Чтобы предотвратить такие атаки, мы требуем, чтобы контрольные точки Babylon были подтверждены агрегированными подписями; таким образом, не будет недоступных контрольных точек Babylon, если две трети валидаторов не будут скомпрометированы, что крайне маловероятно из-за стоимости компрометации валидаторов Babylon. Но в крайних случаях это повлияет на все цепочки PoS, заставив их приостановиться.
Собственный слой в BTC
С точки зрения назначения, хотя Babylon похож на Eigenlayer, он далеко не является простым «форком» Eigenlayer. Учитывая нынешнюю невозможность нативного использования DA в основной цепочке BTC, присутствие Babylon весьма значительно. Этот протокол не только обеспечивает безопасность внешних цепочек PoS, но и имеет решающее значение для возрождения экосистемы BTC внутри компании.
Сокращение периодов стейкинга и повышение безопасности: Цепочки PoS обычно требуют социального консенсуса (консенсуса между сообществом, операторами узлов и валидаторами) для предотвращения атак на расстоянии лонга. Эти атаки включают в себя переписывание истории блокчейна для манипулирования записями транзакций или контроля над цепочкой. Атаки Лонг диапазона особенно серьезны в PoS системах, поскольку, в отличие от PoW, PoS системы не требуют валидаторы для потребления значительных вычислительных ресурсов. Злоумышленник может переписать историю, контролируя ключи ранних стейкеров. Для обеспечения стабильности и безопасности консенсуса сети блокчейн, как правило, необходимы периоды лонга стейкинга. Например, для Cosmos требуется 21-дневный период разблокировки. Однако в Babylon исторические события цепочки PoS могут быть включены в сервер временных меток BTC, используя BTC в качестве источника доверия для замены социального консенсуса. Это может сократить время разблокировки до одного дня (что эквивалентно примерно 100 блокам BTC). Кроме того, цепочки PoS могут иметь двойную безопасность за счет стейкинга собственных токенов и стейкинга BTC.

Совместимость между цепочками: Через протокол IBC Babylon может получать данные о контрольных точках из нескольких цепочек PoS, обеспечивая кросс-чейн совместимость. Такая совместимость обеспечивает бесперебойную коммуникацию и обмен данными между различными блокчейнами, повышая общую эффективность и функциональность экосистемы блокчейна.- Интеграция экосистемы BTC: Большинство проектов в рамках текущей экосистемы BTC, включая уровень 2, LVT и DeFi, не имеют достаточной безопасности и часто полагаются на предположения о доверии третьих сторон. Эти протоколы также хранят большие суммы BTC на своих адресах. В будущем Babylon может разработать некоторые решения с высокой совместимостью с этими проектами, создавая взаимную выгоду и в конечном итоге формируя надежную экосистему, аналогичную Eigenlayer в Ethereum.- Кроссчейн-управление активами: Протокол Babylon можно использовать для безопасного управления кроссчейн-активами. Добавляя временные метки к кроссчейн-транзакциям, он обеспечивает безопасность и прозрачность передачи активов между различными блокчейнами. Этот механизм помогает предотвратить двойное расходование и другие кроссчейн-атаки.

На данный момент тестовая сеть Babylon предоставила гарантии безопасности 50 зонам Cosmos через протокол IBC. Помимо экосистемы Cosmos, Babylon интегрировался с некоторыми протоколами LSD (Liquid Стейкинг Деривативы), протоколами совместимости омничейнов и протоколами экосистемы Биткойн. Однако с точки зрения стейкинга Babylon в настоящее время отстает от Eigenlayer, который может повторно использовать стейкинг и LSD в экосистеме Ethereum. Однако в лонге огромное количество BTC, дремлющее в кошельках и протоколах, еще не полностью пробуждено, представляя собой лишь верхушку айсберга в 1,3 триллиона долларов. Babylon необходимо сформировать позитивный симбиоз со всей экосистемой BTC.
Тем не менее, важно отметить, что Eigenlayer и Babylon в основном направлены на то, чтобы направить маховик ставок в сторону подлинной полезности, создавая реальный спрос для компенсации рисков. Таким образом, в то время как эти протоколы «общей безопасности» могут косвенно или прямо усугубить плохую практику, они также представляют собой единственный способ избежать возврата многоуровневого стейкинга, подобного Понци. Более насущный вопрос сейчас заключается в том, является ли коммерческая логика протоколов «общей безопасности» действительно жизнеспособной.
Эта статья перепечатана с [Medium]. Все авторские права принадлежат оригинальному автору [YBB]. Если у вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой [Gate Learn](https://www.Gate.com/questionnaire/3967, и они оперативно рассмотрят их.
Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, принадлежат исключительно автору и не являются какими-либо инвестиционными рекомендациями.
Переводом статьи на другие языки занимается команда Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.





