NEAR Stateless Validation: Фаза 2 Шардинг

Валидация NEAR без сохранения состояния — это обновление Фазы 2 фреймворка шардинга Nightshade протокола NEAR, при котором валидаторы чанков больше не хранят состояние шарда, чтобы постоянно локально его использовать. Вместо этого производитель чанков упаковывает все необходимые данные о состоянии в «свидетеля состояния» (state witness) — криптографическую структуру данных, содержащую баланс каждого аккаунта, запись в хранилище контракта и ключ доступа, необходимые для выполнения конкретного чанка, и передает её валидаторам вместе с чанком. Эта архитектура отделяет требования к оборудованию валидаторов от размера состояния сети, позволяя NEAR масштабироваться горизонтально за счет добавления новых шардов без пропорционального увеличения затрат на хранение данных для набора валидаторов.

В этой статье рассматривается, что такое NEAR Protocol, как работает шардинг Nightshade, точные механизмы валидации без хранения состояния (stateless validation), включая жизненный цикл свидетеля состояния (state witness) и иерархию ролей валидаторов, преимущества для децентрализации и масштабируемости, прямое сравнение с дорожной картой Ethereum по внедрению stateless-технологий, а также значение этих изменений для валидаторов, стейкеров, разработчиков и всех, кто оценивает NEAR для развертывания dApp.

Что такое NEAR Protocol?

NEAR Protocol — это L1 блокчейн на основе Proof-of-Stake, который использует шардинг Nightshade (проприетарную систему шардинга NEAR) для разделения обработки транзакций между несколькими параллельными шардами, обеспечивая высокую пропускную способность при практически нулевых комиссиях за транзакции. NEAR разработан для развертывания децентрализованных приложений в масштабе, с инструментами для разработчиков и архитектурой консенсуса, построенной на предположении, что количество шардов будет расти со временем.

Основная архитектура NEAR

NEAR работает как сеть proof-of-stake, в которой валидаторы вносят токены NEAR в стейкинг для участия в консенсусе и случайным образом назначаются в шарды (shards) на каждую эпоху — фиксированный период времени, примерно равный половине дня. NEAR Protocol был основан Иллией Полосухиным, соавтором знаковой работы по машинному обучению «Attention Is All You Need», и Александром Скидановым; Фонд NEAR курирует текущую разработку протокола и гранты для экосистемы.

Токен NEAR выполняет две основные функции: оплата сетевых сборов (gas) за транзакции и выполнение контрактов, а также стейкинг в качестве залога для валидаторов, дающий право на участие в консенсусе. Смарт-контракты NEAR компилируются в WebAssembly (WASM) — переносимый бинарный формат, который позволяет контрактам, написанным на Rust или JavaScript, выполняться в детерминированной среде выполнения. Обработка транзакций в NEAR следует модели на основе чанков (chunks), где каждый шард создает чанк (блок уровня шарда, обрабатываемый параллельно) в каждом интервале блока, а все чанки затем агрегируются в единый канонический блок.

Что отличает NEAR от других блокчейнов первого уровня (L1)?

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

• Шардинг исполнения Nightshade: NEAR шардирует как состояние, так и вычисления, а не только доступность данных. Это отличается от подхода Danksharding в Ethereum (EIP-4844), который нацелен на шардинг доступности данных для роллапов уровня 2, а не на шардинг исполнения.
• Валидация без сохранения состояния (Фаза 2): Валидаторы чанков работают без локального хранения состояния — это проектное решение, имеющее прямые последствия для децентрализации и масштабируемости шардов, подробно рассматриваемое в этой статье.
• Среда выполнения смарт-контрактов WASM: Смарт-контракты выполняются в песочнице WASM, поддерживая Rust и JavaScript в качестве основных языков разработки.
• Читаемые имена аккаунтов: Аккаунты NEAR используют именованные идентификаторы вместо необработанных хешей публичных ключей.
• Модель стейкинга хранилища: Смарт-контракты оплачивают ончейн-хранение путем стейкинга токенов NEAR, привязывая стоимость хранения к заложенному обеспечению, а не к комиссиям за байт.
• Почти нулевые комиссии за транзакции: Структура комиссий NEAR разработана таким образом, чтобы оставаться доступной даже при умеренной нагрузке на сеть.

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

Что такое stateless валидация?

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

Stateful vs. Stateless Validation: The Key Difference

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

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

Почему NEAR потребовалась стейтлесс-валидация

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

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

Понимание шардинга: Основа масштабируемости NEAR

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

Как шардинг Nightshade работает на NEAR

Nightshade — это архитектура шардинга протокола NEAR, в которой глобальное состояние блокчейна разделено между несколькими шардами, каждый из которых создает чанк (блок уровня шарда) в каждом интервале блока. Несколько чанков создаются параллельно во всех активных шардах и агрегируются в единый канонический блок производителем блока для данного интервала.

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

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

Полная реализация Nightshade проходит в три этапа. Этап 1 установил базовый шардинг с обработкой чанков, при котором валидаторы поддерживали полные локальные копии состояния. Этап 2 — это валидация без сохранения состояния (stateless validation), тема этой статьи. Этап 3 — динамический решардинг, который дает NEAR возможность автоматически регулировать количество шардов в зависимости от спроса на сеть в реальном времени. Для ознакомления с полной технической документацией по модели шардинга NEAR см. docs.near.org/concepts/advanced/sharding.

--- ## Как работает безгосударственная валидация NEAR

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

Что такое свидетель состояния?

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

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

Жизненный цикл свидетеля состояния охватывает пять отдельных этапов:

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

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

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

4. Выполнение: Каждый валидатор чанка выполняет транзакции чанка, используя исключительно данные свидетельства состояния. Локальный поиск состояния не производится ни на каком этапе. После выполнения валидатор чанка выдает аттестацию, подтверждающую валидность чанка.

5. Удаление: После завершения валидации валидатор чанка отбрасывает свидетеля состояния. Свидетель не сохраняется, не записывается и не используется для обновления какой-либо локальной базы данных состояний.

Структура свидетеля состояния формально определена как Предложение по улучшению NEAR (NEP). Для ознакомления с точной спецификацией и текущим номером NEP см. репозиторий NEAR NEP на GitHub. Для получения подробностей о реализации в клиенте основного протокола см. репозиторий nearcore на GitHub.

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

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

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

Поток валидации при stateless валидации

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

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

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

3. Передача валидаторам чанков: Продуцент чанка рассылает чанк и его свидетеля состояния (state witness) валидаторам чанков, случайным образом назначенным этому шарду на данный интервал блока.

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

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

Ни на одном из этапов 3 и 4 валидатору чанков не требуется локальное хранение состояния. Свидетельство состояния предоставляет весь необходимый доступ к состоянию на время проведения операции валидации.

Преимущества безстатейной валидации NEAR

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

Более низкие требования к оборудованию и большая децентрализация

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

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

Эффект децентрализации напрямую вытекает из этого изменения в аппаратном обеспечении. Более низкие затраты на хранение данных снижают общие операционные расходы на выполнение функций валидатора чанков, понижая эффективный экономический барьер для участия. Это обеспечивает большее и более географически разнообразное множество валидаторов, что, в свою очередь, снижает риск концентрации валидаторов. Сеть, чьи наиболее многочисленные валидаторы могут работать на стандартном оборудовании, структурно более устойчива к централизации, чем та, где право на участие в качестве валидатора требует значительных капитальных вложений в инфраструктуру хранения данных. Текущие спецификации требований к аппаратному обеспечению для валидаторов чанков при безстатусной валидации поддерживаются по адресу docs.near.org/validator; обратитесь к соответствующей документации для получения актуальных данных.

Масштабируемость без ущерба для безопасности

Бессерверная валидация (stateless validation) отделяет количество шардов NEAR от аппаратных требований к валидаторам, что устраняет потолок масштабирования, который накладывала валидация с сохранением состояния (stateful validation) на пропускную способность сети. В рамках предыдущей модели с сохранением состояния удвоение количества шардов потребовало бы от каждого валидатора, назначенного на эти новые шарды, выделения пропорционального дополнительного объема хранилища, что делало большое количество шардов экономически невыгодным. Бессерверная валидация разрывает эту связь: добавление шардов увеличивает мощность сети без увеличения обязательств по хранению данных для каждого валидатора.

Пропускная способность сети NEAR масштабируется примерно пропорционально количеству шардов. Большее количество активных шардов означает большее количество чанков, обрабатываемых параллельно в каждом интервале блока, что увеличивает число транзакций, которые сеть может подтверждать в секунду. Безгосударственная валидация (stateless validation) является необходимым условием для достижения NEAR большего количества шардов при масштабировании. В документации NEAR Foundation приводятся актуальные показатели пропускной способности по мере их обновления; для получения текущих данных о TPS, привязанных к конкретным конфигурациям шардов, см. docs.near.org.

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

Что это значит для разработчиков, создающих на NEAR

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

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

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

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

Путь разработчика Ethereum. NEAR поддерживает Aurora, совместимое с EVM исполняющее окружение, которое позволяет разработчикам Ethereum развертывать контракты Solidity на NEAR без их переписывания на Rust или JavaScript. Эти контракты работают в той же базовой сети и пользуются преимуществами тех же улучшений инфраструктуры stateless-валидации.

Stateless-валидация NEAR против дорожной карты Ethereum по переходу к модели без состояния

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

Оба подхода упаковывают данные состояния, которые требуются валидатору или клиенту, вместе с блоком или чанком для проверки, так что исполняющая сторона никогда не нуждается в локальной базе данных состояния. Структурное отличие заключается в том, что безстатусная проверка NEAR применяется в шардированной системе, нацеливаясь на валидаторов на уровне чанков, которые составляют большинство ее сети. Дорожная карта Ethereum по достижению безстатусности нацелена на полные узлы на монолитном уровне исполнения, где состояние всей цепочки в конечном итоге должно быть доступно через свидетельства деревьев Веркле, а не через локальное дерево состояний (state trie).

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

Какое место занимает валидация без состояния в дорожной карте NEAR?

Фаза 2 Nightshade представляет собой валидацию без сохранения состояния (stateless validation). Эту эквивалентность стоит проговорить прямо, так как в документации NEAR и обсуждениях сообщества термины «Фаза 2» и «stateless validation» иногда используются как взаимозаменяемые, и понимание того, какая фаза является текущей, дает представление о состоянии архитектуры масштабирования сети.

Три фазы Nightshade: объяснение

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

Фаза 1: Базовый шардинг (Завершено)

NEAR разделил состояние своей сети на несколько шардов, причем каждый шард обрабатывал транзакции параллельно. Валидаторы поддерживали полные локальные копии состояния своего назначенного шарда. Производители блоков агрегировали чанки из всех шардов в единые канонические блоки. Фаза 1 установила архитектуру Nightshade на основе чанков, но оставила аппаратные требования напрямую связанными с размером состояния шарда, что создало потолок масштабируемости, который устраняется Фазой 2.

Этап 2: Безстатусная валидация (Текущий этап)

Валидаторы чанков больше не поддерживают локальное состояние шарда. Производители чанков генерируют свидетельства состояния и доставляют их вместе с чанками. Это отделяет требования к аппаратному обеспечению валидаторов чанков от размера состояния шарда и позволяет сети масштабироваться до большего количества шардов без пропорционального увеличения затрат на аппаратное обеспечение валидаторов. На момент написания статьи Фаза 2 была активирована на мейннет NEAR; точную дату активации и текущий статус сети можно узнать в блоге NEAR Foundation) и docs.near.org, поскольку фазы протокола активируются постепенно, а документация обновляется соответствующим образом.

Фаза 3: Динамическое перераспределение шардов (Планируется)

NEAR получит возможность автоматически увеличивать или уменьшать количество шардов на основе сетевого спроса в реальном времени, без ручной координации или обновления оборудования валидаторов. Безгосударственная валидация (Stateless validation) является прямым предварительным условием для динамического решардинга: без активации Фазы 2 добавление шардов привело бы к пропорциональному увеличению затрат на хранение для валидаторов, что сделало бы автоматическую корректировку шардов экономически нецелесообразной. Фаза 3 — это архитектурный этап, который обеспечивает теоретически неограниченное горизонтальное масштабирование в NEAR.

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

Безстейт-валидация NEAR: последствия для валидаторов и стейкеров

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

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

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

Бессерверная (stateless) валидация меняет аппаратные требования для валидаторов чанков (chunk validators), но не изменяет фундаментальную механику смарт-контракта стейкинга. Валидаторы по-прежнему должны внести в стейкинг токены NEAR в объеме, превышающем пороговое значение (seat threshold), для участия в консенсусе, и они по-прежнему подлежат слэшингу за ненадлежащее поведение. Стоимость оборудования, необходимого для соответствия этим требованиям участия, снижается для валидаторов чанков, что в конечном итоге расширяет пул участников, способных запустить узел валидатора чанков при экономически целесообразных операционных расходах. Актуальные спецификации оборудования и пороговые значения для стейкинга можно найти на docs.near.org/validator.

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

Чтобы стать валидатором NEAR, участник должен застейкать токены NEAR выше текущего порога места и запустить программное обеспечение валидатора. Полные инструкции по настройке и текущие аппаратные требования, обновленные с учетом требований безстатусной валидации, см. непосредственно на docs.near.org/validator.

Часто задаваемые вопросы

Для чего используется NEAR Protocol?

NEAR Protocol — это блокчейн первого уровня (layer-1), предназначенный для развертывания децентрализованных приложений, включая протоколы DeFi, платформы NFT, игровые приложения и инструменты для разработчиков. Он использует шардинг Nightshade для обработки транзакций в нескольких параллельных шардах, обеспечивая высокую пропускную способность с практически нулевыми комиссиями за транзакции. Токен NEAR используется для оплаты комиссий за газ при выполнении транзакций и контрактов, а валидаторы вносят в стейкинг токены NEAR в качестве залога для участия в консенсусе.

Как работает NEAR Protocol?

По своей сути NEAR работает как блокчейн на базе Proof-of-Stake, разделенный на несколько шардов, каждый из которых обрабатывает транзакции параллельно. Каждый шард создает чанк (блок уровня шарда) в каждом интервале блоков; производитель блоков объединяет эти чанки в единый канонический блок. Валидаторы случайным образом назначаются в шарды каждую эпоху и отвечают за выполнение и подтверждение транзакций в чанке назначенного им шарда, при этом валидация без сохранения состояния (stateless validation) позволяет валидаторам чанков выполнять эту роль без поддержания локального состояния шарда.

Что такое шардинг Nightshade?

Nightshade — это фреймворк шардинга NEAR Protocol, в котором глобальное состояние сети и обработка транзакций разделяются между несколькими параллельными шардами. В отличие от решений, где каждый шард рассматривается как отдельный блокчейн, Nightshade считает все шарды компонентами единого логического блокчейна, при этом каждый блок содержит по одному фрагменту от каждого активного шарда. Nightshade реализуется в три фазы: базовый шардинг (Фаза 1), безстатусная валидация (Фаза 2) и динамическое перешардирование (Фаза 3).

Что такое свидетель состояния в блокчейне?

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

Как работают валидаторы NEAR?

Валидаторы NEAR выполняют три различные роли в условиях безгосударственной валидации (stateless validation): производители чанков, валидаторы чанков и производители блоков. Производители чанков создают чанки (блоки уровня шарда) и генерируют свидетелей состояния (state witnesses), считывая соответствующее состояние из своей локальной использовать состояния шарда. Валидаторы чанков получают чанк и свидетеля состояния, выполняют транзакции, используя только данные свидетеля без локального хранения состояния, подтверждают валидность чанка и удаляют свидетеля. Производители блоков объединяют подтвержденные чанки из всех активных шардов в единый канонический блок. Валидаторы вносят в стейкинг токены NEAR выше порога входа (seat threshold) для участия в консенсусе и случайным образом распределяются по шардам каждую эпоху.

Как безгосударственная валидация улучшает масштабируемость?

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

Является ли NEAR подходящим блокчейном для разработчиков?

NEAR Protocol предлагает разработчикам смарт-контракты на базе WASM, которые можно писать на Rust или JavaScript, модель стейкинга хранилища, связывающую стоимость хранения данных контракта с заблокированными токенами NEAR, совместимость с Aurora EVM для разработчиков Ethereum, развертывающих контракты на Solidity, и понятные человеку имена аккаунтов. Валидация без состояния (Stateless validation) — это улучшение инфраструктуры на уровне протокола, которое автоматически приносит пользу всем развернутым контрактам без необходимости внесения изменений в код. По мере увеличения количества шардов пропускная способность сети растет, а контракты выигрывают от снижения перегрузок. Разработчикам, рассматривающим NEAR для развертывания рабочих dApp, следует обратиться к docs.near.org за актуальными спецификациями SDK и документацией по инструментам.

Запущена ли валидация без состояния (stateless validation) в NEAR?

Фаза 2 Nightshade, представляющая собой валидацию без сохранения состояния (stateless validation), была активирована в мейннете NEAR. Фазы протокола внедряются постепенно, и NEAR Foundation обновляет документацию по мере полной активации каждой фазы. Для получения самой актуальной информации о статусе развертывания, включая точную дату активации и примечания к конкретным фазам, обращайтесь к блогу NEAR Foundation и официальной документации NEAR Protocol.