Уровень общей безопасности

Что такое уровень общей безопасности?

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

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

Официальная документация релейной цепи Polkadot описывает общую безопасность как модель, в которой подключенные цепочки получают преимущества Nominated Proof of Stake без необходимости самостоятельно создавать собственную систему безопасности.

Официальная документация Cosmos Hub Interchain Security описывает Interchain Security как платформу для запуска цепочек на Cosmos-SDK, которые могут использовать набор валидаторов, стейкинг и сообщество Cosmos Hub.

Официальный обзор EigenLayer описывает рестейкинг как систему, позволяющую стейкерам обеспечивать безопасность сервисов в экосистеме EigenLayer.

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

Основная цель — снизить стоимость и сложность запуска защищенной инфраструктуры.

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

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

Почему уровни общей безопасности важны

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

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

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

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

Это может снизить затраты разработчиков на начальный запуск и повысить безопасность для пользователей.

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

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

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

Когда эти компоненты разделяются, пользователям становится сложнее понимать предпосылки безопасности.

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

Как работает уровень общей безопасности

Уровень общей безопасности работает, подключая несколько систем к одному источнику безопасности.

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

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

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

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

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

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

Точная конструкция зависит от экосистемы.

Некоторые системы реплицируют набор валидаторов цепочки-поставщика на потребительские цепочки.

Другие позволяют лишь части валидаторов подключаться к защите конкретного сервиса.

Таким образом, уровень общей безопасности — не одна отдельная технология, а семейство архитектур, объединяющих доверие и экономическую безопасность.

Цепочка-поставщик

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

В моделях общей безопасности в стиле Cosmos цепочка-поставщик может делиться своим набором валидаторов и стейкингом с потребительскими цепочками.

В документации Cosmos Hub Interchain Security указано, что Hub может позволять цепочкам использовать его валидаторов, стейкинг и сообщество.

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

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

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

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

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

Если вознаграждения слишком низкие, валидаторы могут не захотеть участвовать.

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

Потребительская цепочка

Потребительская цепочка — это блокчейн, получающий безопасность от цепочки-поставщика или уровня общей безопасности.

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

Она заимствует часть структуры безопасности, которая валидирует или защищает ее состояние.

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

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

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

Пользователям также следует проверить, какая часть безопасности поставщика действительно распространяется на потребительскую цепочку.

Некоторые архитектуры требуют, чтобы потребительскую цепочку валидировал весь набор валидаторов.

Другие допускают только частичный набор или группу участников, подключающихся добровольно.

Надежность потребительской цепочки зависит от деталей соглашения об общей безопасности.

Набор валидаторов

Набор валидаторов — это группа валидаторов, ответственная за создание, проверку, финализацию или аттестацию активности блокчейна.

На уровне общей безопасности набор валидаторов может защищать более одной цепочки или сервиса.

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

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

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

Если слишком много систем зависят от одного набора валидаторов, сбои могут стать коррелированными.

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

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

Общий набор валидаторов может быть мощным, но он должен оставаться децентрализованным, контролируемым и иметь надлежащие стимулы.

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

Объединенная безопасность

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

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

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

Объединенная безопасность может быть эффективной, поскольку один и тот же капитал безопасности способен поддерживать более одного полезного сервиса.

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

Поэтому объединенную безопасность необходимо оценивать и с точки зрения преимуществ, и с точки зрения нагрузки.

Преимущество заключается в более сильной общей защите.

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

Объединенная безопасность привлекательна, но не является бесплатной.

Каждый дополнительный сервис меняет профиль риска и вознаграждения общего пула.

Рестейкинг и общая безопасность

Рестейкинг — одна из важнейших современных моделей общей безопасности.

Рестейкинг позволяет использовать застейканные активы или токены ликвидного стейкинга для защиты дополнительных сервисов помимо исходной базовой цепочки.

В обзоре EigenLayer указано, что рестейкинг позволяет стейкерам повторно размещать нативный ETH или токены ликвидного стейкинга для обеспечения безопасности Autonomous Verifiable Services.

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

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

Стейкеры могут делегировать операторам активы или самостоятельно запускать инфраструктуру оператора.

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

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

Рестейкинг превращает застейканный капитал в общий ресурс безопасности.

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

Autonomous Verifiable Services

Autonomous Verifiable Services, часто называемые AVS в экосистеме EigenLayer, — это сервисы, использующие рестейкинговую безопасность через EigenLayer.

В обзоре EigenLayer AVS описываются как сервисы, созданные на протоколе и использующие общую безопасность Ethereum.

AVS может определять задачи, которые должны выполнять операторы.

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

Операторы подключаются для предоставления услуг AVS.

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

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

Если дизайн AVS слабый, общая безопасность может не защитить пользователей ожидаемым образом.

Пользователям не следует считать, что каждый AVS имеет одинаковый уровень безопасности лишь потому, что использует протокол общей безопасности.

Качество архитектуры сервиса по-прежнему имеет значение.

Interchain Security

Interchain Security — это подход к общей безопасности в экосистеме Cosmos.

Он позволяет потребительской цепочке использовать безопасность цепочки-поставщика вместо запуска с изолированным набором валидаторов.

В документации Cosmos Interchain Security он описывается как платформа для запуска цепочек на Cosmos-SDK.

Официальная документация Partial Set Security поясняет, что потребительские цепочки могут использовать только подмножество валидаторов цепочки-поставщика, обеспечивая большую гибкость по сравнению с предыдущей реплицируемой моделью.

Это означает, что общую безопасность можно настраивать с учетом потребностей потребительской цепочки.

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

Небольшая или экспериментальная цепочка может выбрать модель добровольного участия с меньшим гарантированным уровнем безопасности.

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

Interchain Security показывает, как общая безопасность может стать отношением управления и экономики между цепочками.

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

Общая безопасность Polkadot

Polkadot — один из наиболее устоявшихся примеров уровня общей безопасности.

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

В документации релейной цепи Polkadot говорится, что подключенные цепочки Layer 1 получают преимущества безопасности Nominated Proof of Stake без необходимости самостоятельно формировать собственный набор валидаторов.

В документации по парачейнам Polkadot указано, что парачейны наследуют безопасность набора валидаторов Polkadot и могут взаимодействовать через Cross-Consensus Messaging.

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

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

Модель Polkadot отличается от рестейкинга и Cosmos Interchain Security.

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

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

Общая безопасность наиболее сильна, когда пользователи понимают как общую базу безопасности, так и логику цепочки конкретного приложения.

Уровень общей безопасности и автономный блокчейн

Автономный блокчейн сам отвечает за собственную безопасность.

Он должен привлекать валидаторов, стейкеров, майнеров, делегаторов, операторов нод, участников управления и инфраструктуру мониторинга.

Цепочка с общей безопасностью может полагаться на существующий уровень безопасности в части этих обязанностей.

Это может облегчить запуск и масштабирование.

Однако автономная цепочка может иметь больше независимости и меньше внешних зависимостей.

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

Компромисс заключается в выборе между независимостью и первоначальным созданием безопасности.

Автономная цепочка контролирует собственную судьбу, но должна защищать себя самостоятельно.

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

Ни одна из моделей не является автоматически лучшей: подходящий вариант зависит от целей приложения, допустимого риска и ожиданий пользователей.

Уровень общей безопасности и сайдчейн

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

Сайдчейн часто имеет собственный набор валидаторов и собственные предпосылки безопасности.

Цепочка с общей безопасностью более непосредственно полагается на общий уровень безопасности или набор валидаторов поставщика.

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

Цепочка может быть подключена мостом, не разделяя безопасность валидаторов.

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

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

Общая безопасность касается того, кто валидирует и защищает систему, а не только того, как активы перемещаются между системами.

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

Ответ меняет модель риска.

Уровень общей безопасности и роллап

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

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

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

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

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

Общая безопасность может добавлять еще один уровень операторов, стейкеров, вознаграждений и условий слэшинга.

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

Пользователям следует проверить, какая часть стека защищена общей безопасностью.

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

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

Уровень общей безопасности и мост

Мост перемещает активы или сообщения между цепочками.

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

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

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

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

Мост может соединять две цепочки, которые вообще не имеют общей безопасности.

Уровень общей безопасности может поддерживать совместимость, но его главная задача — не простое перемещение активов.

При оценке кроссчейн-приложений пользователям следует отделять риск моста от риска общей безопасности.

Сильный уровень общей безопасности все равно может работать вместе со слабым мостом.

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

Экономическая безопасность

Экономическая безопасность — это стоимость средств под риском, которая делает атаки дорогостоящими.

В системах Proof of Stake экономическая безопасность часто обеспечивается застейканными активами, которые валидаторы могут потерять при нарушении правил.

На уровне общей безопасности экономическая безопасность может повторно использоваться или объединяться между несколькими сервисами.

Это может повысить безопасность небольших сервисов, поскольку им не нужно самостоятельно создавать крупный бюджет безопасности.

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

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

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

Экономическая безопасность — это не просто показатель в заголовке.

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

Сильная общая безопасность требует убедительных штрафов и надежного мониторинга.

Слэшинг в общей безопасности

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

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

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

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

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

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

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

Правила слэшинга должны быть ясными, по возможности объективными и исполнимыми.

Неясные правила слэшинга могут создавать неопределенность, споры и путаницу у пользователей.

Уровень общей безопасности настолько надежен, насколько он способен справедливо выявлять и наказывать серьезные сбои.

Вознаграждения в общей безопасности

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

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

Модель общей безопасности должна балансировать вознаграждения и риски.

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

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

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

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

Системы в стиле Polkadot могут связывать доступ к безопасности с coretime и распределением сетевых ресурсов.

Пользователям не следует оценивать общую безопасность только по доходности.

Им следует сопоставлять вознаграждения с риском слэшинга, риском смарт-контрактов, риском ликвидности, риском операторов и риском управления.

Общая безопасность и совместимость

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

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

В документации релейной цепи Polkadot описывается безопасная совместимость через нативную межсетевую коммуникацию.

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

Однако общая безопасность не решает автоматически все проблемы совместимости.

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

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

Разработчикам следует объяснять, что является общим, что верифицируется и что все еще зависит от отдельной инфраструктуры.

Пользователям не следует считать, что каждое сообщение между цепочками общей безопасности не несет риска.

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

Общая безопасность и модульные блокчейны

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

Уровень общей безопасности может обеспечивать защиту одной или нескольких из этих функций.

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

Такая модульная архитектура может улучшить специализацию и производительность.

Она также может усложнить понимание риска, поскольку пользователям приходится одновременно оценивать несколько уровней.

Сбой одного модуля может повлиять на все приложение.

Сбой доступности данных может повлиять на восстановление роллапа.

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

Сбой моста может повлиять на погашение активов.

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

Общая безопасность и MEV

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

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

Он также может концентрировать власть над упорядочиванием, если многие приложения полагаются на одних операторов.

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

Это может создавать как эффективность, так и риск.

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

Пользователям следует понимать, защищает ли уровень общей безопасности от цензуры или лишь предусматривает экономические штрафы после нарушения.

Разработчикам не следует считать, что общая безопасность автоматически обеспечивает справедливое упорядочивание.

Общая безопасность может способствовать лучшей координации, но управление MEV требует специального дизайна.

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

Устойчивость к цензуре

Устойчивость к цензуре — это способность пользователей включать действительные транзакции без несправедливой блокировки.

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

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

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

В документации Cosmos Partial Set Security объясняется, что цепочки с добровольным подключением могут не получать фиксированный объем безопасности и должны отслеживать участие валидаторов.

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

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

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

Устойчивость к цензуре не гарантируется самим выражением «общая безопасность».

Она зависит от разнообразия валидаторов, стимулов, правил и реальной инфраструктуры.

Живучесть

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

Уровень общей безопасности должен обеспечивать как безопасность, так и живучесть.

Безопасность означает, что система не финализирует недействительное или противоречивое состояние.

Живучесть означает, что система не останавливается на неопределенный срок.

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

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

Потребительская цепочка может остановиться, если недостаточно общих валидаторов участвуют корректно.

AVS может не предоставить сервис, если операторы находятся офлайн или неверно настроены.

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

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

Управление в общей безопасности

Управление определяет, как уровень общей безопасности меняется со временем.

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

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

В системах рестейкинга управление протокола или поставщики сервисов могут определять наборы операторов и условия слэшинга.

Управление может повысить адаптивность, но также создает риск централизации.

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

Если управление слишком медленное, экосистема может не успеть отреагировать на срочные угрозы.

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

Общая безопасность — не только техническая система.

Это также система управления и координации.

Концентрация операторов

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

Это может снизить децентрализацию и повысить риск коррелированных сбоев.

Если многие пользователи делегируют одному оператору, его ошибка может повлиять на многих стейкеров.

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

Концентрация операторов также может приводить к влиянию на управление и концентрации MEV.

Перед делегированием активов в рестейкинг или использованием сервиса пользователям следует проверять разнообразие операторов.

Разработчикам следует создавать стимулы, поощряющие широкую базу операторов.

Крупные операторы могут быть профессиональными и надежными, но один лишь размер не следует считать показателем безопасности.

Здоровый уровень общей безопасности должен сокращать единые точки отказа.

Децентрализованная безопасность зависит как от экономического стейкинга, так и от операционного распределения.

Риски общей безопасности

Первый риск — коррелированный слэшинг в нескольких сервисах.

Второй риск — перегрузка операторов из-за чрезмерного числа обязанностей по валидации.

Третий риск — захват управления или небезопасные обновления.

Четвертый риск — слабая конструкция слэшинга, не наказывающая за реальные сбои.

Пятый риск — чрезмерно агрессивный слэшинг, несправедливо наказывающий за добросовестные ошибки.

Шестой риск — уязвимости смарт-контрактов в контрактах рестейкинга, делегирования, вознаграждений или мостов.

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

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

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

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

Преимущества уровней общей безопасности

Первое преимущество — более быстрое первоначальное обеспечение безопасности для новых цепочек и сервисов.

Второе преимущество — более сильная экономическая безопасность, чем многие небольшие автономные наборы валидаторов могут обеспечить самостоятельно.

Третье преимущество — более низкая стоимость запуска для разработчиков.

Четвертое преимущество — улучшенная совместимость подключенных систем.

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

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

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

Восьмое преимущество — более тесная связь экосистемы между цепочками-поставщиками, потребительскими цепочками, операторами и пользователями.

Девятое преимущество — более гибкая модульная архитектура блокчейна.

Десятое преимущество — общая безопасность может повысить надежность высокоценной инфраструктуры до появления у нее крупной экономики нативного токена.

Как оценить уровень общей безопасности

Начните с определения источника безопасности.

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

Проверьте, какой объем стейкинга действительно защищает конкретную цепочку или сервис.

Проверьте, является ли набор валидаторов полным, частичным, добровольным, разрешенным или открытым.

Проверьте, действует ли слэшинг, является ли он объективным, исполнимым, отложенным или опосредованным управлением.

Проверьте, являются ли валидаторы или операторы разнообразными и надежными.

Проверьте размер вознаграждений и их устойчивость.

Проверьте, имеет ли подключенная система собственные риски смарт-контрактов, мостов, оракулов или управления.

Проверьте, могут ли пользователи безопасно выйти из системы при сбое сервиса или изменении отношений безопасности.

Качественная оценка отвечает на вопросы: что является общим, кто обеспечивает соблюдение правил, что может выйти из строя и кто несет расходы при сбое.

Рекомендации для разработчиков

Четко объясняйте модель безопасности в пользовательской документации.

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

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

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

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

Постоянно отслеживайте операторов и валидаторов.

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

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

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

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

Рекомендации для пользователей

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

Проверьте, защищает ли уровень безопасности всю систему или только один модуль.

Перед внесением средств проверьте участие валидаторов или операторов.

Перед стейкингом, делегированием или рестейкингом активов разберитесь в риске слэшинга.

Не стремитесь к более высоким вознаграждениям, не проверив, какие дополнительные риски создают эти вознаграждения.

Оценивайте риски мостов, оракулов, смарт-контрактов и управления отдельно от заявлений об общей безопасности.

При использовании новой цепочки или сервиса выполняйте небольшие тестовые транзакции.

Отслеживайте, каким операторам или валидаторам подвержены ваши активы.

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

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

Распространенные заблуждения об уровнях общей безопасности

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

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

Третье заблуждение — путать мост с уровнем общей безопасности.

Четвертое заблуждение — считать заявленную общую стоимость в стейкинге полностью доступной защитой для каждого сервиса.

Пятое заблуждение — игнорировать концентрацию валидаторов или операторов.

Шестое заблуждение — игнорировать условия слэшинга.

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

Восьмое заблуждение — игнорировать управление и права на обновления.

Девятое заблуждение — считать вознаграждения за рестейкинг бесплатной доходностью.

Десятое заблуждение — не проверять, действует ли уровень общей безопасности, является ли он частичным, экспериментальным или все еще меняется.

FAQ

Что означает Shared Security Layer в криптоиндустрии?

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

Почему проекты используют уровень общей безопасности?

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

Является ли общая безопасность тем же, что мост?

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

Является ли общая безопасность тем же, что сайдчейн?

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

Что такое рестейкинг в общей безопасности?

Рестейкинг позволяет застейканным активам или токенам ликвидного стейкинга обеспечивать безопасность дополнительных сервисов помимо исходной базовой цепочки.

Может ли общая безопасность снизить риск?

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

Что такое цепочка-поставщик?

Цепочка-поставщик — это блокчейн, предоставляющий безопасность потребительским цепочкам или подключенным сервисам.

Что такое потребительская цепочка?

Потребительская цепочка — это блокчейн, получающий безопасность от цепочки-поставщика или уровня общей безопасности.

Каков наибольший риск общей безопасности?

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

Как пользователям оценивать заявления об общей безопасности?

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

Заключение

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

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

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

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

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

Разработчикам следует точно объяснять, что защищено, кто это защищает, как работают вознаграждения и что происходит при сбое валидаторов или операторов.

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

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

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

В контексте криптоглоссария Shared Security Layer означает объединенную систему безопасности, которая позволяет нескольким блокчейн-сетям или сервисам полагаться на общих валидаторов или обеспечение, принимая специфические риски этой общей модели.

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