В этой части мы представляем перевод следующих двух глав, посвящённых экосистемам Ethereum и Solana.

Если ты ещё не успел ознакомиться с предыдущими частями, они лежат по ссылкам ниже:

• Первая часть лежит по этой ссылке
• Вторая часть лежит по этой ссылке

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

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

Этот сценарий иллюстрирует трилемму блокчейна: практическую реальность того, что одновременная оптимизация децентрализации, безопасности и масштабируемости влечет за собой неизбежные противоречия. Ни одна цепь не может избежать этих ограничений. Биткоин (Глава I) ставит в приоритет децентрализацию и безопасность, принимая ограниченную пропускную способность. Solana (Глава III) повышает пропускную способность, но требует мощного оборудования, что естественным образом концентрирует валидацию. Ethereum (Глава II) идет срединным путем, сохраняя разумную децентрализацию при масштабировании через L2-решения, которые привносят свою сложность.

Основной тезис этой главы заключается в том, что любой дизайн блокчейна подразумевает врожденные компромиссы, а конкуренция между L1 зависит от ликвидности, внимания разработчиков и культурного импульса не меньше, чем от чистых технических характеристик. Цепь может обрабатывать 100 000 транзакций в секунду, но если ей не хватает пользователей и разработчиков, эти транзакции утекают в другое место. Понимание как технических архитектур, так и рыночной динамики, определяющей принятие (adoption), необходимо для оценки долгосрочных перспектив любого L1.

Раздел I: Реальность принятия

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

Десятки известных L1 конкурируют за ограниченную пользовательскую базу, состоящую в основном из крипто-нативов и розничных спекулянтов. На сегодняшний день фактически ни один блокчейн не достиг широкомасштабного устойчивого спроса на приложения вне специфических категорий: торговля (DEX), спекуляции (мемкоины, NFT), стейблкоины, фарминг доходности и платежи (особенно на развивающихся рынках). Начинают появляться зачатки активности в таких областях, как токенизация реальных активов (RWA) и децентрализованная физическая инфраструктура (DePIN), но они пока остаются на ранней стадии.

Ликвидность служит решающим фактором. Сети с нативной поддержкой USDC и USDT могут подключиться к сотням миллиардов циркулирующих стейблкоинов и триллионам ежегодного объема переводов. Сети без нативной интеграции стейблкоинов с трудом привлекают значимую ончейн-активность. Листинги на централизованных биржах обеспечивают важнейшие фиатные шлюзы (on-ramps), определяющие практическую доступность для пользователей. Превосходная технология мало что значит, если крупные биржи не поддерживают ввод и вывод средств.

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

Установив эти рыночные реалии, давайте рассмотрим технические архитектуры, в рамках которых приходится маневрировать L1-сетям.

Раздел II: Архитектуры блокчейнов

Четыре плоскости

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

Исполнение (Execution) — это кухня, где обрабатываются заказы (транзакции) и готовятся блюда (изменения состояния). Расчет (Settlement) — это обеденный зал, где готовые блюда доставляются клиентам, а те оплачивают счета (финализированное состояние). Консенсус (Consensus) — это система управления, гарантирующая, что все согласны с тем, какие заказы поступили первыми и к каким столам они относятся. Доступность данных (Data Availability) — это ведение учета, сохранение чеков и записей, чтобы любой мог проверить, что произошло.

Спектр модульности

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

Монолитные конструкции ставят в приоритет тесную интеграцию. Когда исполнение, консенсус, расчет и доступность данных делят одну цепь, большинство приложений живут внутри одного домена глобальной атомарной компонуемости. Атомарная компонуемость означает, что одна транзакция может затрагивать множество контрактов, и при этом либо применяются все изменения состояния, либо все они отменяются вместе, подобно гарантии «всё или ничего». Это значительно упрощает создание сложных DeFi-систем, поскольку всё рассчитывается внутри одной и той же машины состояний. Биткоин и Solana архитектурно находятся ближе к этому концу спектра, хотя они резко различаются по пропускной способности и аппаратным требованиям.

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

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

Эволюция Ethereum служит примером такого перехода. Роллап-центричная дорожная карта сети превращает Ethereum в базовый уровень, где L2-сети обрабатывают большую часть исполнения транзакций, в то время как L1 специализируется на консенсусе, расчетах (проверке доказательств роллапов и разрешении споров) и обеспечении доступности данных для транзакций роллапов. Роллапы оптимизируются для пропускной способности и стоимости; Ethereum обеспечивает безопасность и финальность.

Ключевые дизайнерские решения

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

Монолитные цепи предлагают локальную компонуемость. Сложные многошаговые операции работают бесшовно, так как все действия выполняются в одной атомарной транзакции. Если любой шаг терпит неудачу, всё откатывается назад, оставляя тебя именно там, где ты начал. Флэш-кредиты (flash loans) иллюстрируют эту мощь: пользователь может занять миллионы долларов, использовать эти средства в нескольких протоколах и погасить кредит — и всё это в рамках одной транзакции, которая либо полностью удается, либо полностью проваливается без частичного исполнения (Глава VII подробно рассматривает флэш-кредиты).

Распределенные архитектуры требуют межслойной компонуемости, координирующей действия между несколькими цепями с разным временем финализации и предположениями о доверии. Тот же арбитраж в одну транзакцию, который тривиален в монолитной цепи, не может быть выражен как по-настоящему атомарная операция между роллапами. Флэш-кредиты остаются строго локальными для одной среды исполнения. Межроллапный арбитраж вместо этого полагается на заранее выделенный капитал (или кредитные линии) и принимает риски инвентаря и моста, пока сообщения или активы перемещаются между доменами. Атомарность между роллапами, как правило, невозможна без дополнительных механизмов координации, синхронизирующих исполнение в нескольких цепях, которые всё еще находятся в стадии разработки.

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

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

Масштабирование через модульность: горизонтальные подходы

В то время как вертикальное масштабирование заставляет отдельные цепи обрабатывать больше транзакций (рассмотрено в Разделе V), горизонтальное масштабирование распределяет работу между несколькими параллельными цепями.

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

Вместо этого Ethereum перешел к роллап-центричной модели: L2 обеспечивают параллелизм и обрабатывают большинство пользовательских транзакций, в то время как L1 фокусируется на расчетах и доступности данных. Через транзакции с блобами (EIP-4844, рассмотренные в Главе II) и запланированные будущие обновления Ethereum распределяет данные роллапов между валидаторами вместо того, чтобы разделять исполнение на отдельные шарды. Это пример того, как разделенные уровни могут оптимизироваться независимо, координируясь через четко определенные интерфейсы.

Альтернативные подходы к специализации

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

Такой дизайн обеспечивает изоляцию производительности: тяжелые приложения в одной подсети не замедляют и не повышают стоимость работы приложений в других подсетях. Эти цепи общаются друг с другом через Avalanche Warp Messaging — систему, позволяющую безопасно передавать сообщения между цепями без необходимости объединять безопасность всех подсетей в один пул. Результатом является федерация настраиваемых блокчейнов, которая может масштабироваться горизонтально за счет добавления новых подсетей, а не конкуренции за место в одной общей сети.

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

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

Раздел III: Консенсус и финальность

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

Proof-of-Work против Proof-of-Stake

Системы Proof-of-Work (PoW), такие как Биткоин (подробно в Главе I), используют вычислительные задачи для выбора производителей блоков. Майнеры соревнуются в решении криптографически сложных задач, и победитель получает право предложить следующий блок. Безопасность проистекает из самой стоимости приобретения и эксплуатации оборудования, достаточного для контроля над сетью. Атакующему пришлось бы опередить совокупную вычислительную мощность всех честных майнеров.

Системы Proof-of-Stake (PoS), такие как Ethereum (подробно в Главе II), используют экономическую долю (стейк), а не вычислительную работу, для выбора производителей блоков. Валидаторы блокируют капитал в качестве залога, получая вознаграждение за честное участие, но сталкиваясь со штрафами (слэшингом) в случае плохого поведения. Безопасность здесь заключается в том, чтобы сделать атаки экономически иррациональными: атаковать сеть означает уничтожить собственный застейканный капитал.

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

Живучесть против Безопасности (Liveness vs Safety)

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

Живучесть (Liveness) означает, что сеть продолжает прогрессировать и производить новые блоки. Безопасность (Safety) означает, что сеть никогда не создает невалидные или конфликтующие блоки, даже если это требует полной остановки.

Разные блокчейны делают разный выбор в этом балансе:

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

Ethereum выбирает сбалансированный подход. У него есть функция «утечки при неактивности» (inactivity leak), которая постепенно сокращает стейк офлайн-валидаторов. Если исчезает достаточное количество валидаторов, этот механизм со временем позволяет оставшимся онлайн-валидаторам продолжать производство блоков, сохраняя живучесть, хотя в обычном режиме приоритет отдается безопасности.

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

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

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

Семейства консенсуса BFT

Многие новые цепи используют алгоритмы консенсуса Византийской отказоустойчивости (BFT). Название происходит от классической задачи информатики: как группе генералов скоординировать атаку, когда некоторые из них могут быть предателями, посылающими ложные сообщения? BFT-системы решают это, позволяя сетям достигать согласия, даже когда часть участников ведет себя злонамеренно или выходит из строя. Эти системы обеспечивают детерминированную финальность, достигая подтверждения за считанные секунды без риска отмены.

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

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

Tendermint

Tendermint используется в Cosmos и многих специфических для приложений цепях. Валидаторы должны достичь консенсуса через несколько раундов голосования перед производством каждого блока. Время блока обычно составляет от 1 до 7 секунд в зависимости от размера набора валидаторов и сетевых условий. Системе требуется как минимум две трети голосующей мощности онлайн для прогресса. Это осознанное ограничение: более медленная обработка транзакций в обмен на немедленную финальность и строгие гарантии безопасности.

Новые варианты BFT

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

Proof-of-History

Proof-of-History представляет собой отличительную инновацию консенсуса Solana, сочетающую криптографический механизм хронометража с голосованием Tower BFT. Система обеспечивает оптимистичные подтверждения примерно через 400 миллисекунд и полную финальность примерно через 12,8 секунды. Детальное описание работы Proof-of-History, его взаимодействия с пересылкой транзакций Gulf Stream, распространением данных Turbine и обновлением Alpenglow приведено в Главе III.

Типы финальности и их последствия

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

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

Экономическая финальность (Ethereum после Слияния, как обсуждалось в Главе II) означает, что отмена потребовала бы уничтожения значительной экономической ценности, что делает атаки экономически иррациональными для злоумышленников, стремящихся к прибыли. Механизм финальности Ethereum создает контрольные точки (checkpoints), отмена которых потребовала бы уничтожения как минимум одной трети всех застейканных ETH (что сейчас стоит десятки миллиардов долларов). Это делает отмену не просто вычислительно дорогой, но экономически катастрофической. Однако это предполагает рациональность атакующих; государственные или идеологически мотивированные атаки могут принять экономические потери ради достижения политических или стратегических целей.

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

Эти различия имеют практические последствия для всей экосистемы. DeFi-протоколы могут ждать от 6 до 12 блоков в Биткоине для транзакций с высокой стоимостью. В Ethereum некоторые приложения действуют на основе подтверждений в 1–2 блока для лучшего UX, но настоящая экономическая финальность наступает только спустя примерно 2 эпохи ($\sim 12{,}8$ минуты, когда сеть финализирует контрольную точку). BFT-цепи обеспечивают детерминированную финальность за секунды, позволяя создавать иные конструкции приложений. Межсетевые мосты должны тщательно выверять свои параметры безопасности в соответствии с этими моделями финальности. Как мы увидим в Разделе VI, несоответствие между вероятностной и детерминированной финальностью способствовало взломам мостов, когда системы не ждали достаточного количества подтверждений в исходной цепи.

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

Раздел IV: Виртуальные машины и модели программирования

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

Дилемма «Экосистема против Инноваций»

Выбор между виртуальными машинами представляет собой классическую дилемму инноватора. Создание на базе устоявшейся VM, такой как EVM, означает доступ к зрелой инфраструктуре: обширной документации, проверенным в боях библиотекам, опытным разработчикам, сложным инструментам отладки, комплексным фреймворкам для тестирования и аудиторским фирмам с глубокой экспертизой. Протокол типа Uniswap может развернуться в EVM-сетях с минимальными изменениями, принося проверенные DeFi-примитивы в разные сети. Новый DeFi-протокол может немедленно подключиться к ликвидности Uniswap, оракулам Chainlink и рынкам кредитования Aave. Этот общий прикладной слой, охватывающий EVM-цепи, создает преимущества компонуемости (обсуждаемые в Разделе II), которые альтернативным платформам трудно воспроизвести.

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

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

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

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

Гравитационный колодец EVM

Как было установлено в Разделе I, сетевые эффекты доминируют в принятии, и EVM (представленная в Главе II) иллюстрирует эту динамику. EVM-совместимые цепи, такие как BNB Chain, Avalanche и Polygon, могут мгновенно унаследовать эту экосистему. Однако архитектурные ограничения EVM становятся очевидными при масштабировании. Последовательное исполнение означает, что сложные транзакции блокируют простые, волатильность цен на газ создает непредсказуемые издержки, а отсутствие нативного параллельного исполнения ограничивает пропускную способность. Эти ограничения подстегнули инновации как в оптимизированных реализациях EVM, так и в альтернативных виртуальных машинах, пытающихся преодолеть эти врожденные барьеры.

Параллельное исполнение: подход SVM

Как подробно описано в Главе III, Виртуальная машина Solana (SVM) обеспечивает исполнение блокчейна через параллельную обработку. Требуя от транзакций заранее объявлять доступ к аккаунтам, SVM позволяет одновременно исполнять неконфликтующие транзакции, увеличивая пропускную способность. Её модель владения аккаунтами повышает безопасность, предотвращая многие атаки типа повторного входа (reentrancy).

Дизайн SVM привлек внимание новых блокчейн-проектов. Сети типа Solayer и Fogo строят совершенно новые L1-блокчейны поверх архитектуры SVM. Fogo идет еще дальше, пытаясь максимизировать производительность SVM через разрешенный (permissioned) набор валидаторов, работающих исключительно на клиенте Firedancer с мульти-локальным консенсусом, исследуя потенциал производительности модели SVM в контролируемой среде.

Move: Безопасность через дизайн языка

MoveVM, используемая в Aptos и Sui, выбирает другой путь, встраивая безопасность напрямую в язык программирования. Move рассматривает цифровые активы как «ресурсы» — специальные объекты, которые нельзя скопировать или случайно уничтожить, а можно только перемещать между аккаунтами.

Линейные типы в Move предотвращают случайное дублирование или уничтожение ресурсов, помогая избежать целых классов багов, таких как двойная трата из-за ошибок программирования. Однако политики выпуска (mint) и авторизации всё еще зависят от того, как написаны модули. Ресурсы могут существовать только в одном месте одновременно и должны быть явно потреблены или сохранены.

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

WASM и развивающиеся VM

WebAssembly (WASM) представляет собой цель компиляции, позволяющую использовать множество языков программирования в одном блокчейне. Этот подход предлагает «золотую середину»: лучшую производительность, чем у интерпретируемого байт-кода, при поддержке различных языков, хотя и ценой повышенной сложности.

CosmWasm в экосистеме Cosmos позволяет использовать Rust-контракты, компилируемые в WASM. Протокол NEAR использует WASM, сохраняя модель аккаунтов, привычную для разработчиков Ethereum, объединяя производительность и узнаваемость. Фреймворк Substrate в Polkadot использует WASM как формат для логики рантайма. Поскольку этот рантайм хранится в сети и обновляется через управление (governance), цепи могут заменять основную логику через «бесфорковые» (forkless) обновления рантайма вместо координации традиционных хардфорков. Этот подход мощен, но сложен.

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

Сокращая разрыв: подход Monad

Некоторые проекты стремятся сохранить совместимость с EVM, переосмысливая внутреннее устройство исполнения. Monad демонстрирует этот прагматичный путь в дилемме «экосистема против инноваций», поддерживая полную совместимость с байт-кодом EVM при полной переработке внутренних механизмов исполнения. Любой контракт на Solidity, написанный для Ethereum, развертывается в Monad без изменений, сохраняя доступ к знакомому инструментарию и проверенным библиотекам.

Под этим совместимым интерфейсом Monad достигает более 10 000 TPS за счет оптимистичного параллельного исполнения, асинхронного ввода-вывода и кастомной базы данных состояния. Разработчики используют привычные инструменты типа Foundry и Remix. Протоколы портируются бесшовно. Тем не менее, прирост производительности реален и обеспечивается архитектурными инновациями, абстрагированными от опыта разработчика.

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

Эти архитектурные паттерны — от выбора модульности до механизмов консенсуса и виртуальных машин — влияют на пропускную способность, но «сырая» емкость остается главной проблемой. Как отдельные цепи раздвигают границы своей производительности? Ответы дает вертикальное масштабирование через оптимизацию оборудования, дизайн рынков комиссий и умное управление данными.

Раздел V: Подходы к вертикальному масштабированию

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

Аппаратные требования

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

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

Ethereum после Слияния занимает промежуточную позицию. Хотя валидация требует более существенных ресурсов, чем Биткоин (рекомендуются 32 ГБ ОЗУ и 4 ТБ быстрого SSD-накопителя, наряду со стейком в 32 ETH), эти требования остаются достижимыми для домашних операторов. Этот баланс способствовал созданию географически распределенного набора валидаторов, поддерживающего около 20 TPS на Layer 1 (варьируется в зависимости от использования газа и 12-секундного времени блока).

Как упоминалось во введении, архитектура Solana ярко иллюстрирует этот компромисс. Сеть приоритезирует производительность через высокие спецификации: высокочастотные процессоры, 256+ ГБ ОЗУ, быстрые NVMe-накопители и сетевые соединения не менее 1 Гбит/с. Для управления хранилищем валидаторы обычно обрезают (prune) историю реестра по умолчанию. Взамен сеть поддерживает тысячи транзакций в секунду в штатном режиме. Однако эти жесткие требования концентрируют мощность валидации в руках хорошо обеспеченных ресурсами структур.

Этот аппаратный спектр наглядно иллюстрирует основной компромисс. Более высокие требования к производительности обеспечивают большую пропускную способность, но сужают круг потенциальных валидаторов, влияя как на текущее участие, так и на барьер входа для новичков. Децентрализация на практике существует как спектр; не существует четкого порога «достаточной децентрализации». Прагматичный взгляд — это стоимость и координация, необходимые для того, чтобы остановить сеть экономически, юридически и операционно. Каждая сеть выбрала свою точку на этой кривой.

Рынки комиссий и распределение ресурсов

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

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

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

Большие блоки и быстрые интервалы

Большие блоки — самый простой способ масштабирования. Они просто увеличивают объем данных транзакций, помещающихся в каждом блоке. Bitcoin Cash выбрал этот путь, начав с блоков 8 МБ в 2017 году и расширив их до 32 МБ в 2018 году. Сегодня у него нет жесткого лимита, хотя блоки редко превышают несколько МБ. BNB Chain масштабируется путем корректировки лимита газа в блоке, который сейчас составляет около 100 мегагаза (megagas). Есть предложение увеличить его в десять раз до 1 гигагаза.

Сокращение времени блока может повысить пропускную способность без увеличения размера каждого отдельного блока. 12-секундные слоты Ethereum обрабатывают больше транзакций в минуту, чем 10-минутные блоки Биткоина, даже если размеры блоков схожи. Но в цепях с Proof-of-Work есть подвох: очень короткие интервалы создают больше конкурирующих блоков (называемых «сиротами» или «дядями» — orphans/uncles). Это тратит впустую честную работу майнеров и снижает безопасность. Системы Proof-of-Stake, такие как Ethereum после Слияния, сталкиваются с другими проблемами. Когда слоты слишком коротки, сеть не успевает справляться. Это ведет к пропущенным аттестациям и пропущенным слотам, а не к «дядям», и усложняет процесс выбора форка.

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

Рост состояния и хранение

Хотя пропускная способность транзакций привлекает больше всего внимания, рост состояния (state growth) представляет собой не менее серьезную угрозу масштабируемости. Состояние — это полный снимок всех текущих данных блокчейна: балансов аккаунтов, переменных смарт-контрактов и сохраненной информации. В отличие от истории транзакций, состояние должно оставаться немедленно доступным для валидации.

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

Появились три основных подхода к управлению ростом состояния. Аренда состояния (State rent) взимает постоянную плату за хранение данных в сети, создавая экономическое давление для удаления ненужного состояния, хотя это рискует нарушить работу приложений, построенных на допущении о бесплатном вечном хранении. Истечение срока состояния (State expiry) автоматически удаляет данные, к которым не обращались в течение установленного периода (пользователи могут позже восстановить истекшее состояние с помощью криптографических доказательств), ограничивая размер состояния, но добавляя значительную сложность. Продвинутые структуры данных также могут помочь, резко сокращая размер доказательств, необходимых для проверки состояния. Ethereum реализует подход под названием деревья Веркла (Verkle trees), которые позволяют узлам доказывать факты о состоянии блокчейна, используя гораздо меньшие доказательства, чем нынешние методы. Это позволяет «легким» узлам участвовать в сети без хранения полного состояния, снижая барьер для запуска узла.

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

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

Раздел VI: Интероперабельность и межсетевая архитектура

Размножение блокчейнов первого уровня создает фундаментальную проблему фрагментации. Каждая цепь оптимизируется под свои приоритеты. Ethereum приоритезирует безопасность и децентрализацию, Solana делает упор на скорость и низкие затраты, Cosmos фокусируется на суверенитете отдельных приложений. Эта специализация привлекает конкретные приложения и пользователей, но достается дорогой ценой: ликвидность, пользователи и приложения оказываются разбросаны по несовместимым сетям, которые не могут нативно взаимодействовать.

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

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

Мосты стали самыми ценными мишенями в крипте — на них приходится примерно 2,5 миллиарда долларов потерь от крупных эксплойтов. Понимание их моделей безопасности необходимо для оценки межсетевых рисков. (В Разделе IV Главы V о исторических провалах кастодиального хранения рассматриваются несколько известных взломов мостов.)

Как работают мосты

Представь мост как механизм, который изымает активы из обращения в одной цепи и создает соответствующие копии в другой цепи. Чтобы сделать это, мост либо блокирует активы в контракте, либо сжигает их (в зависимости от конструкции). Затем он создает соответствующие представления (wrapped assets) в целевой цепи.

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

Если ты хочешь перевести 100 USDC из Ethereum в Solana, мост блокирует твои 100 USDC в смарт-контракте в Ethereum, а затем выпускает для тебя 100 «бриджированных USDC» в Solana. Когда ты хочешь вернуться, процесс идет в обратном порядке: твои токены в Solana сжигаются, а оригинальные USDC разблокируются в Ethereum. Это поддерживает стабильное общее предложение в обеих цепях.

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

Инфраструктура против Приложений

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

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

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

Появилось несколько протоколов обмена сообщениями, каждый со своим подходом к верификации. Экосистема Cosmos использует IBC (Inter-Blockchain Communication), который полагается на криптографическую верификацию легких клиентов, где цепи напрямую проверяют состояние друг друга. LayerZero выбирает другой путь, используя комбинацию оракулов и ретрансляторов для проверки сообщений во множестве различных цепей.Wormhole использует сеть «стражей» (guardians), где доверенные стороны подтверждают сообщения. CCIP от Chainlink добавляет дополнительные меры безопасности поверх своей инфраструктуры оракулов. CCTP от Circle предоставляет специализированный уровень обмена сообщениями специально для переводов USDC.

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

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

Ключевой вопрос безопасности

Любой дизайн моста должен отвечать на вопрос: кто проверяет, что блокировка в цепи А и выпуск в цепи Б произошли корректно?

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

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

Фундаментальный вызов моста

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

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

Однако эта защита действует только для того состояния, которое цепь может проверить нативно. Когда валидаторы начинают подтверждать события в других цепях, не предоставляя проверяемых доказательств, их подписи становятся «оракулом». Если протокол говорит: «Выпускай токены в цепи Б всякий раз, когда 2/3 или более валидаторов подпишут сообщение о том, что 100 токенов были заблокированы в цепи А», то сговорившееся супербольшинство может солгать об этом внешнем событии. У целевой цепи нет криптографического способа отличить правду от обмана, потому что само правило определяет «достаточное количество подписей» как истину.

Именно этого пытаются избежать мосты на базе легких клиентов и доказательств. Системы типа Cosmos IBC и Rainbow Bridge от NEAR заставляют целевую цепь проверять криптографические доказательства заголовков или состояния исходной цепи. Чтобы взломать такой мост, нужно фактически взломать или скомпрометировать консенсус исходной цепи, а не просто заставить комитет солгать. Сама архитектура Ethereum эволюционирует в этом направлении с обновлениями, позволяющими смарт-контрактам проверять данные уровня консенсуса напрямую вместо того, чтобы доверять внешним подтверждениям.

Иными словами, реальный риск — это не «валидаторы, говорящие о внешних цепях» в целом. Риск возникает тогда, когда мост или протокол рассматривает подписи валидаторов (или небольшого внешнего комитета) как авторитетное свидетельство о чем-то, что сама цепь проверить не может. Везде, где мы можем сделать внешние данные проверяемыми ончейн (через легкие клиенты, ZK-доказательства или выделенные хуки консенсуса и исполнения), это дополнительное предположение о доверии исчезает, и мы возвращаемся в область, где «51% не может сделать невалидный переход состояния валидным».

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

Модели безопасности мостов

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

Внешняя верификация: Доверие посредникам

Мосты с внешней верификацией полагаются на третьих лиц, которые наблюдают за обеими цепями и передают сообщения между ними. Доверенные/Мультисиг-мосты используют группу «стражей». Wormhole иллюстрирует это с помощью 19 Стражей, работающих по порогу 13-из-19. Мосты на базе набора валидаторов, такие как Axelar, создают выделенные PoS-сети специально для кроссчейн-сообщений: валидаторы стейкают токены и несут экономическую ответственность за плохое поведение.

Компромиссы: Простота сборки, высокая скорость и поддержка практически любого блокчейна. Недостаток: безопасность зависит от людей-операторов или отдельного набора валидаторов. Взлом Wormhole в 2022 году использовал баг в проверке подписи, позволивший несанкционированно выпустить около 120 000 WETH ($\sim 325$ млн долларов). Кража из моста Ronin произошла, когда злоумышленники скомпрометировали достаточно ключей валидаторов для одобрения мошеннических выводов.

Нативная верификация: Криптографические доказательства

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

Компромиссы: Защита соответствует безопасности самой исходной цепи без дополнительных предположений. Однако требуется значительная техническая сложность, и цепи должны осторожно обрабатывать тайминги финальности (вспомни обсуждение типов финальности в Разделе III). IBC в основном работает с цепями на базе Tendermint в Cosmos, хотя ведется разработка расширений для других механизмов консенсуса.

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

Оптимистичные мосты по умолчанию считают сообщения валидными, но позволяют любому оспорить их в течение окна споров. Ретранслятор отправляет сообщение через мост, заявляя: «100 токенов заблокированы в цепи А». Это сообщение предварительно принимается, но вступает в период оспаривания. «Наблюдатели» (watchers), мониторящие обе цепи, могут предоставить доказательства мошенничества (fraud proofs), если обнаружат, что сообщение неверно. Если в течение временного окна никто не подает жалобу, сообщение становится финальным. Across Protocol сейчас использует оптимистичную модель, где сторонние ретрансляторы обеспечивают немедленную ликвидность (fast fills), а окончательный расчет происходит после окна оспаривания с использованием Optimistic Oracle от UMA.

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

Практические уязвимости в реализации мостов

Межсетевая инфраструктура вводит поверхности атаки, которых не существует в одноцепочечных системах. Послужной список отрезвляет: громкие эксплойты включают Ronin Bridge (компрометация ключей валидаторов), Poly Network (ошибка в авторизации контракта), Wormhole (баг проверки подписи), Nomad (ошибка инициализации, превратившая определенный паттерн вызова в валидный вывод средств) и Harmony Horizon (компрометация ключей мультисига). Большинство этих инцидентов были связаны не с «недостаточным временем ожидания подтверждений», а с неверными предположениями о доверии, плохим управлением ключами и багами реализации в коде, управляющем огромными ценностями.

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

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

Новые вызовы и направления будущего

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

Фрагментация активов стала эндемичной. «Один и тот же» актив в разных цепях на самом деле не является одним и тем же. Нативный USDC, выпущенный Circle в Ethereum, несет в себе принципиально иной риск, чем USDC от Wormhole в Solana, несмотря на то, что оба отображаются как «USDC» в интерфейсах большинства кошельков. Разработчики DeFi-приложений не могут просто сказать: «мы поддерживаем USDC». Они должны уточнить: какой именно USDC, в какой цепи и через какой мост полученный. Пользователи должны отслеживать не просто «у меня есть 1000 USDC», а «у меня есть 500 нативных USDC в Ethereum, 300 бриджированных USDC в Arbitrum через мост X и 200 обернутых USDC в Solana через мост Y». Каждая версия имеет разную ликвидность, разный риск потери привязки (depegging) и разные механизмы вывода.

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

Трение в пользовательском опыте остается значительным. Перевод через мост обычно требует нескольких ончейн-действий: сначала одобрение (approve) контракта моста на использование твоих токенов в цепи А (газ), затем вызов функции блокировки/сжигания или депозита (еще газ), ожидание финализации и ретрансляции сообщения мостом, переключение кошелька на цепь Б и, в некоторых схемах, отправка там транзакции требования (claim), прежде чем токены станут доступны.

Путь вперед, вероятно, лежит через гибридные модели, сочетающие верифицированные через ZK легкие клиенты с экономическими доказательствами сбоев. Технология ZK может сделать нативную верификацию практичной там, где традиционные подходы с легкими клиентами были бы непомерно дорогими. Архитектуры на базе «намерений» (intents) могут абстрагировать сложность мостов, позволяя пользователям указывать желаемый результат, в то время как исполнители (solvers) занимаются кроссчейн-маршрутизацией. Стандартизация вокруг общих уровней ликвидности и универсальных стандартов мостов могла бы уменьшить фрагментацию. Однако эти решения привносят собственные компромиссы и сложности, что говорит о том, что межсетевая инфраструктура останется областью активных экспериментов, а не окончательно сформированного консенсуса.

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

Раздел I: Криптографический фундамент

Сдвиг парадигмы хранения

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

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

Открытые ключи, закрытые ключи и цифровые подписи

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

Закрытый ключ — это большое случайное число, обычно обладающее энтропией в 256 бит, которое служит секретом владельца. На практике закрытые ключи обычно выводятся из 12- или 24-словных мнемонических сид-фраз (seed phrases), а не генерируются напрямую. Из этого закрытого ключа математические операции генерируют соответствующий открытый ключ. Хотя вычислительно легко получить открытый ключ из закрытого, обратное практически невозможно при нынешних технологиях. (В Главе XIV рассматривается, как квантовые компьютеры могут изменить это уравнение).

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

Цифровые подписи обеспечивают неотрекаемость: как только кто-то подписал транзакцию, он не может позже заявить, что не авторизовывал её. Математика дает криптографическое доказательство авторизации.

Разные блокчейны используют разные алгоритмы подписи. Bitcoin и Ethereum полагаются на ECDSA (алгоритм цифровой подписи на эллиптических кривых), в то время как Solana использует EdDSA (алгоритм цифровой подписи на кривых Эдвардса). Обновление Taproot в Биткоине ввело подписи Шнорра, которые позволяют нескольким сторонам совместно подписывать транзакции так, что в сети они выглядят идентично транзакциям с одной подписью. Эти алгоритмические различия становятся важными при разработке схем многостороннего хранения, так как некоторые схемы работают с определенными типами подписей лучше, чем другие. Практические последствия станут яснее, когда мы изучим модели институционального хранения в Разделе III.

Адреса: публичные идентификаторы

Адреса служат публичными идентификаторами для получения криптовалюты, производными от открытых ключей через криптографическое хеширование. Разные блокчейны используют разные форматы адресов. В Биткоине существует несколько типов адресов, включая Legacy-адреса, начинающиеся с «1», адреса Script Hash, начинающиеся с «3», и современные форматы Bech32, начинающиеся с «bc1». Адреса Ethereum представляют собой 40-символьные шестнадцатеричные строки, которые всегда начинаются с 0x и выводятся из последних 20 байт хеша открытого ключа. Адреса Solana — это 44-символьные строки, представляющие открытые ключи Ed25519 напрямую.

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

Мнемонические сид-фразы: человекочитаемые ключи

Хотя криптографические примитивы, описанные выше, обеспечивают математическую основу хранения, они создают практическую проблему: как людям безопасно управлять этими ключами? «Сырые» закрытые ключи — это 64-символьные шестнадцатеричные строки типа e9873d79c6d87dc0fb6a5778633389f4453213303da61f20bd67fc233aa33262, которые невозможно запомнить, которые подвержены ошибкам при переписывании и которые трудно хранить безопасно.

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

BIP-39 (Bitcoin Improvement Proposal 39) стандартизирует мнемонические фразы, используя словарь из 2048 слов. 12-словная фраза кодирует примерно 128 бит энтропии, в то время как 24-словная — около 256 бит. Эти слова кодируют криптографическую энтропию плюс контрольную сумму для обнаружения ошибок при записи. Фраза обрабатывается через алгоритм «растягивания ключа», который применяет множество итераций криптографического хеширования для генерации мастер-сида, что делает атаки методом перебора (brute-force) вычислительно дорогими. На основе этого мастер-сида иерархически детерминированные (HD) кошелькивыводят неограниченное количество адресов и ключей, следуя сопутствующим стандартам BIP (BIP-32 определяет метод вывода, BIP-44 стандартизирует структуру путей для различных криптовалют).

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

25-е слово: К мнемонике можно добавить опциональную парольную фразу (passphrase), создав дополнительный уровень безопасности. Эта фраза фактически создает разные кошельки на основе одной и той же сид-фразы, обеспечивая «правдоподобное отрицание» и дополнительную защиту.

При создании сид-фраз важно использовать генерацию случайных чисел высокого качества. Слабая случайность может привести к предсказуемым ключам, которые злоумышленники смогут угадать. При восстановлении кошелька из сид-фразы использование того же пути вывода (derivation path — конкретного метода генерации адресов из сида), что и в оригинальном кошельке, гарантирует корректное восстановление всех адресов. Разные кошельки могут использовать разные пути вывода, поэтому совместимость имеет значение при переходе между программным обеспечением кошельков.

Раздел II: Индивидуальное самостоятельное хранение (Self-Custody)

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

Программные кошельки: удобство против безопасности

Программные («горячие») кошельки хранят закрытые ключи на устройствах общего назначения, таких как смартфоны или компьютеры. Популярные примеры включают MetaMask, Trust Wallet и Phantom. Эти кошельки предлагают отличный пользовательский опыт и бесшовную интеграцию с DeFi-приложениями, что делает их идеальными для активной торговли и частых транзакций.

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

Внешние злоумышленники представляют собой самую заметную категорию угроз. Вредоносное ПО и вирусы могут сканировать файлы кошельков или записывать нажатия клавиш для перехвата паролей. Целевые фишинговые кампании обманом заставляют пользователей вводить сид-фразы на поддельных сайтах, имитирующих интерфейсы легитимных кошельков. Атаки на цепочку поставок могут скомпрометировать ПО кошельков, расширения браузера или даже аппаратные устройства во время доставки. Кража устройства создает возможности для извлечения ключей с помощью криминалистических методов. «Клипборд-хакеры» незаметно заменяют скопированные адреса на адреса злоумышленников, перенаправляя средства во время обычных транзакций. Атаки типа «человек посередине» (man-in-the-middle) могут перехватывать и изменять транзакции до того, как они попадут в блокчейн. Эти противники варьируются от случайного вредоносного ПО до изощренных группировок с государственными возможностями, нацеленных на состоятельных лиц. Их методы постоянно эволюционируют, требуя многоуровневой технической защиты и высокой операционной осведомленности.

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

Аппаратные кошельки: золотой стандарт

Аппаратные кошельки представляют собой текущую лучшую практику для индивидуального хранения. Эти специализированные устройства хранят закрытые ключи в защищенном от взлома оборудовании, которое никогда не подвергает их воздействию потенциально скомпрометированных компьютеров или сетей. Базовая модель безопасности прямолинейна. Закрытые ключи генерируются и хранятся на устройстве (часто в защищенном элементе — Secure Element, в зависимости от модели), транзакции подписываются внутри, и только подписи передаются на хост-компьютеры. Пользователи сохраняют контроль, физически нажимая кнопки для подтверждения каждой транзакции, в то время как мнемоническая сид-фраза обеспечивает возможность восстановления.

Защищенный элемент (Secure Element) — это устойчивый к взлому чип, предназначенный для безопасного хранения криптографических ключей и выполнения конфиденциальных операций в изоляции от основного процессора. Он обеспечивает защиту на аппаратном уровне как от физических, так и от программных атак, гарантируя, что закрытые ключи не могут быть извлечены, даже если устройство скомпрометировано. На институциональном уровне аналогичные средства защиты обеспечиваются аппаратными модулями безопасности (HSM) и защищенными анклавами, которые рассматриваются в Разделе III.

Выбор между философиями безопасности

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

Несмотря на эти философские различия, и Ledger, и Trezor обеспечивают значительные преимущества в безопасности по сравнению с программным хранением. Закрытые ключи никогда не покидают защищенную аппаратную среду, что делает удаленные атаки практически невозможными. Устройства защищены от несанкционированного доступа и требуют ввода PIN-кода. Ledger стирает данные после трех неверных попыток ввода PIN-кода. Trezor применяет экспоненциальные задержки при неверном PIN-коде; пользователи могут дополнительно настроить «код уничтожения» (PIN-код, ввод которого стирает устройство). Обновления прошивки криптографически верифицируются для предотвращения вредоносных модификаций.

Операционные лучшие практики

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

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

Тестирование восстановления и обслуживание

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

Индивидуальное самостоятельное хранение с помощью аппаратных кошельков и проверенных процедур резервного копирования хорошо работает для личных активов. Однако когда капитал превышает 1 млн долларов, возрастает операционная сложность (активная торговля, DeFi, работа в нескольких сетях) или возникают организационные потребности (бизнес, DAO, инвестиционные фонды), индивидуальные модели хранения достигают своего предела. Эти ситуации требуют процессов многостороннего одобрения, мер безопасности институционального уровня, возможностей комплаенса и аудиторских следов, которые аппаратные кошельки обеспечить не могут. В Разделе III рассматриваются специализированные архитектуры хранения, предназначенные для решения этих принципиально иных задач.

Раздел III: Институциональные модели и архитектура хранения

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

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

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

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

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

Основные модели хранения

Мультисиг (Multisig): стандарт прозрачности

Мультиподпись обеспечивает соблюдение политик расходования непосредственно в блокчейне, где они становятся видимыми, открытыми и поддающимися аудиту. Требуя нескольких подписей от независимых ключей, организации создают высокую прозрачность. Стейкхолдеры могут проверять управленческие решения и проводить аудит точных условий движения средств казначейства. DeFi-протоколы и DAO особенно выигрывают от такой публичной верификации порогов одобрения, что укрепляет доверие сообщества. Реализация обычно опирается на нативные возможности Биткоина или контракты Safe (ранее Gnosis Safe) в Ethereum, которые защищают миллиарды долларов в тысячах организаций.

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

Недавние обновления протоколов решают эти ограничения. Как отмечалось в Главе I, обновление Taproot в Биткоине ввело подписи Шнорра, которые позволяют механизмам многостороннего хранения выглядеть в сети идентично транзакциям с одной подписью. Это значительно снижает издержки прозрачности традиционных мультисигов при сохранении тех же гарантий безопасности.

MPC и пороговые подписи (Threshold Signatures): конфиденциальность и скорость

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

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

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

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

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

Разделение секрета Шамира (SSS): хранение и восстановление

Схема разделения секрета Шамира (SSS) использует иной подход, чем MPC. Вместо генерации ключей распределенным способом, SSS разделяет уже существующий закрытый ключ на несколько долей (shares), при этом только подмножество долей может восстановить оригинал. Например, можно разделить ключ на пять частей так, чтобы любые три могли его восстановить. Это обеспечивает отказоустойчивость при потере части долей и позволяет распределенно хранить резервные копии в нескольких местах.

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

Квалифицированные кастодианы: регуляторная база

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

Операционно квалифицированные кастодианы используют многослойные подходы к безопасности. На уровне инфраструктуры они развертывают аппаратные модули безопасности (HSM). В то время как защищенные элементы в потребительских аппаратных кошельках защищают индивидуальные ключи, HSM — это аналоги промышленного класса, предназначенные для корпоративных масштабов. Эти устройства, монтируемые в стойки, управляют ключами для тысяч аккаунтов, обеспечивают соблюдение сложных политик одобрения и выполняют криптографические операции в изолированных средах. Кастодианы часто размещают HSM в физически защищенных помещениях, иногда глубоко под землей. Эти технические средства контроля часто сочетаются с MPC для распределенного управления ключами, создавая архитектуры глубокой защиты (defense-in-depth). Строгие политики температурной сегрегации поддерживают специфические пороги горячего, теплого и холодного хранения, в то время как автоматизированные системы обеспечивают соблюдение политик холодного хранения без вмешательства человека.

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

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

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

Основные институциональные кастодианы

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

Coinbase Custody (траст с ограниченными целями штата Нью-Йорк) делает упор на сегрегированное холодное хранение в рамках квалифицированного кастодиана с надзором инспекторов. Модель сосредоточена на оффлайн-хранении ключей, институциональных одобрениях и страховом покрытии. Комиссии являются многоуровневыми или договорными в зависимости от объема активов и предоставляемых услуг. Публичные соглашения показывают диапазоны примерно от 0,25% до 0,35% в год плюс минимальные платежи. Согласно правилам NYDFS, активы клиентов удерживаются в трасте с защитой банкротной удаленности, хотя юридическая трактовка специфики криптоактивов остается предметом дискуссий.

Anchorage Digital (банк с федеральной лицензией США) практикует «активное хранение», сочетая HSM, защищенные анклавы и биометрические подтверждения для операций в реальном времени. Защищенные анклавы (secure enclaves) — это изолированные среды исполнения внутри процессоров, которые защищают код и данные даже от привилегированного доступа к системе, обеспечивая дополнительный уровень защиты помимо традиционных HSM. Под надзором OCC активы клиентов должны быть сегрегированы. В сценарии неплатежеспособности порядок действий и сроки перевода зависят от внешнего управления и конкретных фактов дела.

BitGo (трастовые компании в Южной Дакоте и Нью-Йорке), исторически ассоциирующийся с ончейн-мультисигом, добавил схемы пороговых подписей для поддержки более широкого спектра активов. Предлагая как горячие, так и холодные рабочие процессы со страховым покрытием, компания варьирует цены от ежемесячных процентных уровней до комиссий, основанных на общем объеме активов под управлением. Законы штатов предусматривают внешнее управление с сегрегированными счетами, которые считаются банкротно-удаленными.

Платформы технологий хранения

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

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

Copper фокусируется на институциональной инфраструктуре с технологией MPC и сегрегированными счетами. Как и Fireblocks, она работает как технологическая платформа, при этом хранение может обеспечиваться через партнеров. Ценообразование тяготеет к плате за подписку и услуги.

Хранение на биржах: операционные соображения

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

Риски хранения на биржах

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

Доказательство резервов (Proof-of-Reserves)

Proof-of-Reserves (PoR) демонстрирует платежеспособность биржи через ончейн-аттестации или подтверждения от кастодианов в сочетании с доказательствами обязательств, которые могут проверить клиенты. Эффективный PoR включает четкие доказательства исключения и опубликованный объем проверок под надзором независимого аудитора; использование Kraken деревьев Меркла для обязательств с доказательствами включения каждого клиента служит примером лучшей практики.

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

Сегрегация

Профессиональное хранение реализует разделение активов по их стоимости с систематическим распределением по уровням. Иллюстративные целевые показатели политики включают: холодное хранение, теплое хранение для примерно и горячее хранение для . Фактические соотношения варьируются в зависимости от склонности к риску и состава продуктов. Это принудительные потолки, а не цели, при этом автоматизированные системы отслеживают пороги и поддерживают строгие границы между клиентскими и собственными (проприетарными) активами биржи.

Исторические провалы в хранении: уроки из практики

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

Mt. Gox (2014) продемонстрировал тяжелые последствия размытой сегрегации между горячим и холодным хранением и отсутствия процедур сверки. Биржа годами работала с неадекватным контролем и без видимости реальных балансов в реальном времени. Когда произошел крах, следователи обнаружили, что хакеры медленно выкачивали средства с 2011 года, пока биржа продолжала работать в обычном режиме. Изначально сообщалось о потере около 850 000 BTC; позже было найдено около 200 000 BTC, а примерно 650 000 BTC исчезли навсегда. Этих потерь можно было бы избежать или ограничить их через правильную сегрегацию и ежедневную сверку балансов.

Parity Multisig (2017) показал, как общие зависимости создают системные риски в системах смарт-контрактов. Parity Technologies разработала популярную реализацию мультисиг-кошелька, которую использовали многочисленные DAO, проекты и институциональные казначейства для хранения Ethereum. Ошибка в одной библиотеке затронула кошельки множества организаций одновременно, заморозив около 513 000 ETH в сотнях структур, включая такие крупные проекты, как Polkadot, Web3 Foundation и фонды развития Ethereum. Инцидент подчеркнул, что формальная верификация и тщательное управление зависимостями — это не роскошь, а важнейшие предохранители, когда смарт-контракты управляют значительной ценностью. Плохая реализация сделала возможными взломы, включая кражу 30 млн долларов в ETH из индивидуальных кошельков и последующую ошибку в библиотеке, которая навсегда заморозила более 300 млн долларов в казначействах организаций, подсветив специфические уязвимости протокола мультисиг и опасности общей инфраструктуры.

Ronin Bridge (2022) сконцентрировал контроль над валидаторами в слишком немногих руках, упустив важные возможности для обнаружения аномалий. Ronin — это сайдчейн Ethereum, созданный для Axie Infinity. Мост, обеспечивающий перемещение активов между Ethereum и Ronin, использовал мультисиг 5-из-9 для хранения. Злоумышленники скомпрометировали 5 из 9 ключей валидаторов (в основном четыре валидатора, контролируемых Sky Mavis из соображений производительности, плюс один валидатор Axie DAO из белого списка) и вывели около 173 600 ETH и 25,5 млн USDC ($\approx 615$ млн долларов на тот момент) в течение шести дней, прежде чем кто-то это заметил. Инцидент показал, как децентрализованные системы могут стать централизованными из-за операционных упрощений, и почему надежные системы мониторинга должны обнаруживать необычные паттерны, даже если они выглядят технически валидными.

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

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

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