Что такое NEAR Protocol? Безстатусная валидация

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

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

Содержание

• Что такое NEAR Protocol?
• Проблемы, которые решает NEAR
• Как работает NEAR: объяснение шардинга Nightshade
• Что такое безгосударственная валидация (Stateless Validation) в NEAR?
• Почему безгосударственная валидация имеет значение
• Динамический решардинг: что следует за безгосударственной валидацией
• NEAR против Ethereum и Solana
• Экосистема NEAR
• Токен NEAR, стейкинг и экономика валидаторов
• Что безгосударственная валидация значит для валидаторов
• Часто задаваемые вопросы
• Заключение

Что такое NEAR Protocol?

NEAR Protocol — это блокчейн уровня 1 с доказательством доли владения (proof-of-stake), разработанный для обеспечения высокой масштабируемости, низких транзакционных издержек и доступности для разработчиков. Блокчейн NEAR использует архитектуру шардинга под названием Nightshade sharding, которая разделяет сеть на параллельные каналы обработки, и развернула безстатусную валидацию (stateless validation) в рамках обновления Nightshade Phase 2 для обеспечения децентрализованной высокопроизводительной обработки транзакций. NEAR Protocol (сеть блокчейна) использует NEAR (нативный токен) для оплаты комиссий за транзакции и стейкинга.

NEAR Protocol был сооснован Ильей Полосухиным (соавтором статьи 2017 года «Attention Is All You Need», представившей архитектуру Transformer, лежащую в основе современных больших языковых моделей) и Алексом Скидановым (бывшим инженером-программистом Microsoft и соавтором дизайна шардинга Nightshade).

Ключевые особенности NEAR Protocol:

• Шардинг Nightshade: параллельная обработка транзакций в нескольких шардах, каждый из которых создает сегмент блока на уровне шарда, называемый чанком (chunk)
• Валидация без хранения состояния (Фаза 2, запущена): валидаторы чанков проверяют транзакции без хранения локального состояния шарда, используя вместо этого стейт-витнесы (state witnesses)
• Среда выполнения WebAssembly (Wasm): смарт-контракты компилируются в Wasm, поддерживаются языки разработки Rust и JavaScript
• Читаемые имена аккаунтов: аккаунты используют текстовый формат имен (например, yourname.near) вместо необработанных криптографических адресов
• Низкие комиссии за транзакции: модель комиссий NEAR разработана таким образом, чтобы оставаться предсказуемой по мере масштабирования пропускной способности сети через шардинг
• Гранты для разработчиков: NEAR Foundation распределяет финансирование экосистемы для поддержки проектов, смежных с протоколом

NEAR использует Thresholded Proof of Stake (вариант, в котором валидаторы выбираются на основе минимального порога стейкинга, а не строгого ранжирования топ-N). Это отличает консенсус NEAR от стандартного Delegated Proof of Stake. NEAR имеет примерно 100 активных валидаторов за эпоху, и держатели токенов NEAR могут делегировать стейк валидаторам, не запуская свои собственные узлы.

Среда выполнения WebAssembly (Wasm) в NEAR исполняет смарт-контракты в изолированном, детерминированном и независимом от языка программирования формате. Разработчики пишут контракты на Rust или JavaScript — популярных языках с огромными сообществами — и компилируют их в Wasm для исполнения. Детерминированное исполнение критически важно для работы безгосударственной валидации (stateless validation): при получении одинаковых входных данных состояния через свидетеля состояния (state witness) каждый валидатор выдает идентичный результат, что делает безгосударственную проверку математически обоснованной. Разработчикам, изучающим NEAR, рекомендуется ознакомиться с разделом Что такое безгосударственная валидация NEAR?, чтобы понять, как эта архитектура влияет на работу сети.

NEAR используется для смарт-контрактов, децентрализованных приложений (dApps), DeFi протоколов, NFT платформ, игровых приложений и кросс-чейн взаимодействия с Ethereum через проект экосистемы Aurora.

Проблема, которую решает NEAR

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

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

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

Как работает NEAR: Объяснение шардинга Nightshade

Шардинг Nightshade — это архитектура NEAR Protocol для параллельной обработки транзакций. Он разделяет блокчейн на отдельные вычислительные параллельные линии, называемые шардами (параллельные вычислительные линии, каждая из которых одновременно обрабатывает подмножество сетевых транзакций). Результат работы каждого шарда для блока называется чанком (часть блока на уровне шарда; каждый шард создает один чанк за интервал блока). Валидаторы назначаются на конкретные шарды каждую эпоху, и результирующие чанки собираются в единый финальный блок. (Блог-пост о шардинге Nightshade)))

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

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

1. Входящие транзакции направляются в шард, отвечающий за аккаунт отправителя
2. Каждый шард обрабатывает назначенные ему транзакции параллельно со всеми остальными шардами
3. Набор валидаторов каждого шарда создает чанк, содержащий обработанные им транзакции
4. Валидаторы чанков проверяют, что транзакции в каждом чанке действительны
5. Производители блоков объединяют все чанки изо всех шардов в единый финальный блок
6. Финальный блок добавляется в цепочку, и рассчитываются вознаграждения валидаторов

Распределение валидаторов по шардам меняется на каждой границе эпохи. До появления безстейтовой валидации переход в новый шард требовал загрузки и синхронизации полного состояния этого шарда — трудоемкой операции с высокой нагрузкой на ввод-вывод (I/O). Безстейтовая валидация меняет этот процесс, как описано в таблице Дорожная карта Nightshade ниже.

Дорожная карта Nightshade

Nightshade — это многоэтапное обновление. Каждый этап основывается на предыдущем, а валидация без хранения состояния (stateless validation) является вторым из трех запланированных этапов.

Последняя проверка: 2025. Статус текущей дорожной карты см. на near.org.

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

Что такое валидация NEAR без состояний?

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

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

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

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

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

Для ознакомления с пошаговым процессом работы валидации без хранения состояния см. раздел Пошаговое описание работы валидации без хранения состояния в NEAR. О конкретных ролях валидаторов чанков и производителей чанков см. раздел Валидаторы чанков против производителей чанков.

Пошаговое описание работы валидации без хранения состояния в NEAR

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

1. Транзакция отправляется в сеть и направляется в шард, отвечающий за аккаунт отправителя
2. Продюсер чанка выполняет транзакции в назначенном ему шарде, используя локальную базу данных состояния шарда
3. Продюсер чанка генерирует свидетельство состояния (state witness), содержащее только те записи состояния, которые были задействованы транзакциями этого чанка, а также доказательства Меркла их включения в дерево состояний (state trie) шарда
4. Продюсер чанка транслирует чанк и свидетельство состояния назначенным валидаторам чанков для этого шарда
5. Валидаторы чанков получают свидетельство состояния и проверяют, что транзакции в чанке корректно применяются к засвидетельствованному состоянию, при этом локальная база данных состояния не требуется
6. Проверенный чанк передается продюсерам блоков, которые объединяют чанки всех шардов в итоговый блок

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

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

Что такое State Witness?

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

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

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

Как генерируется и используется государственный свидетель:

["Производитель чанков выполняет все транзакции из своего чанка против состояния своей локальной шарды.","Во время выполнения он записывает каждый элемент три состояния, который был прочитан или записан.","Он генерирует доказательства Меркла, доказывающие, что каждая записанная запись принадлежит корневому дереву состояния шарды.","Он упаковывает эти записи и доказательства в «свидетельство состояния» (state witness).","Валидаторы чанков получают свидетельство, проверяют доказательства Меркла и повторно выполняют транзакции против предоставленных записей."]

Одно уточнение, важное для технических специалистов: свидетели состояния (state witnesses) в NEAR — это аттестации данных состояния на основе доказательств Меркла. Они не являются доказательствами с нулевым разглашением (ZKP). Механизм не использует ZK-схемы или системы доказательств; он применяет стандартные доказательства включения в дерево Меркла для подтверждения того, что конкретные записи состояния являются подлинными частями состояния шарда.

Что это значит для валидаторов: Свидетельство состояния (state witness) — это пакет данных, который делает возможной вашу безгосударственную валидацию. Вам не нужно доверять базе данных состояния продюсера чанка; вы самостоятельно проверяете доказательства Меркла, включенные в свидетельство. Если доказательства проходят проверку и транзакции корректно выполняются повторно на основе предоставленных записей, чанк считается валидным.

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

Валидаторы фрагментов против производителей фрагментов

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

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

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

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

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

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

Почему валидация без состояния имеет значение

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

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

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

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

Динамический решардинг: что будет после валидации без состояния

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

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

Безстейт-валидация устраняет это «узкое место». Поскольку валидаторам чанков больше не нужно предварительно загружать состояние шарда, они могут быть мгновенно назначены в новый, разделенный или объединенный шард и сразу приступить к валидации; свидетели состояния предоставляют всё необходимое для каждого чанка. Фаза 3 призвана использовать это свойство, чтобы позволить протоколу автоматически увеличивать количество шардов, когда отдельные шарды приближаются к пределу своей пропускной способности, и уменьшать их число при снижении спроса.

Фаза 3 динамического шардирования еще не запущена. Дорожная карта NEAR описывает ее как запланированное обновление. Дорожные карты протоколов могут меняться; проверьте near.org для получения информации о текущем статусе разработки.

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

NEAR против Ethereum и Solana

NEAR отличается от Ethereum по трем измеримым параметрам: NEAR использует шардинг Nightshade для обработки транзакций в параллельных шардах, в то время как Ethereum работает как единая цепочка исполнения; NEAR развернул безстатусную валидацию (stateless validation) как действующую функцию протокола, в то время как эквивалентное предложение Ethereum (EIP-4762) остается на этапе исследований и разработок по состоянию на 2025 год; а смарт-контракты NEAR компилируются в WebAssembly и могут быть написаны на Rust или JavaScript, в то время как основная среда смарт-контрактов Ethereum — это Solidity на виртуальной машине Ethereum (EVM).

Предложение по клиентам с отсутствием состояния в Ethereum: Исследования Ethereum в области безгосударственных (stateless) клиентов преследуют ту же концептуальную цель, что и обновление NEAR Фазы 2 — позволить узлам проверять блоки без хранения полного состояния. Предложенный подход Ethereum, описанный в EIP-4762,), требует перехода от деревьев Merkle Patricia к деревьям Verkle в качестве базовой структуры состояния. Это многолетняя миграция протокола, которая по состоянию на 2025 год все еще находится на стадии исследований и разработок. NEAR уже развернул свою реализацию безгосударственной валидации как активную функцию протокола; эквивалент Ethereum предложен, но еще не внедрен. Это разные реализации, преследующие схожую архитектурную цель на разных стадиях разработки.

Архитектурный компромисс Solana: Solana обеспечивает высокую пропускную способность транзакций за счет одношардовой архитектуры, в которой все валидаторы обрабатывают все транзакции относительно полного глобального состояния. Этот подход обеспечивает высокую производительность, но требует от валидаторов наличия мощного оборудования (высокопроизводительные процессоры, большой объем оперативной памяти, быстрые NVMe SSD), что концентрирует участие валидаторов среди операторов со значительными инфраструктурными ресурсами. Подход NEAR, сочетающий шардинг и отсутствие состояния (stateless), направлен на достижение сопоставимой пропускной способности, позволяя валидаторам чанков работать с более низкими требованиями к оборудованию. NEAR также конкурирует на рынке платформ первого уровня (Layer-1) наряду с Avalanche и сетями на базе Move, такими как Aptos и Sui, хотя эти архитектуры существенно отличаются от подхода NEAR к шардингу.

NEAR: текущие сильные стороны и ограничения

["Преимущества:","- Шардинг Nightshade запущен и обрабатывает транзакции в параллельных шардах","- Развернута stateless валидация (Фаза 2), снижающая аппаратные требования для валидаторов чанков","- Среда выполнения WebAssembly поддерживает Rust и JavaScript, что снижает кривую обучения разработчиков по сравнению с окружениями, ориентированными только на Solidity","- Низкие комиссии за транзакции по своей природе, с моделью комиссий, разработанной для масштабирования за счет шардинга","- Доступны гранты для разработчиков от NEAR Foundation"]

Ограничения:

• Экосистема NEAR меньше, чем у Ethereum, по общему объему заблокированных средств (TVL) и активности разработчиков
• Динамический шардинг Фазы 3 еще не запущен
• Размер сообщества разработчиков меньше, чем у Solana

Экосистема NEAR

Фонд NEAR — это швейцарская некоммерческая организация, которая курирует развитие экосистемы, гранты для разработчиков, партнерства и управление протоколом для NEAR Protocol. Она отличается от основных инженерных команд, ответственных за разработку протокола. Фонд выделяет гранты для проектов, строящихся на инфраструктуре NEAR, и поддерживает адаптацию (онбординг) разработчиков.

NEAR Protocol поддерживает ряд категорий приложений, включая протоколы DeFi, платформы NFT, игровые приложения и платформы социальных сетей. Инструментарий NEAR для разработчиков разработан с учетом доступности: поддержка Rust и JavaScript (оба являются мейнстримными языками), понятные человеку имена учетных записей и документация на docs.near.org.

Aurora — это совместимый с виртуальной машиной Ethereum (EVM) уровень исполнения, построенный на инфраструктуре NEAR, который позволяет разработчикам развертывать смарт-контракты Solidity в сети NEAR без необходимости переписывания кода. Aurora является отдельным проектом экосистемы, а не функцией протокола NEAR. Rainbow Bridge обеспечивает бездоверительную передачу активов специально между NEAR и Ethereum, позволяя пользователям перемещать токены ETH и ERC-20 между двумя сетями. NEAR также предлагает сервис доступности данных (NEAR DA), используемый Ethereum роллапами и сетями второго уровня (Layer-2), которым требуются недорогие уровни доступности данных с высокой пропускной способностью.

Для разработчиков, рассматривающих NEAR в качестве платформы: поддержка Rust и JavaScript средой выполнения Wasm снижает порог вхождения по сравнению с средами, поддерживающими только EVM, а проект экосистемы Aurora предоставляет путь миграции для существующих кодовых баз Solidity.

Токен NEAR, стейкинг и экономика валидаторов

Токен NEAR выполняет четыре функции в рамках протокола:

• Комиссии за транзакции (газ): NEAR оплачивает вычисления в сети; часть сжигается, а часть распределяется среди валидаторов.
• Стейкинг: валидаторы и делегаторы блокируют NEAR для обеспечения безопасности сети и получения наград за стейкинг.
• Управление: держатели токенов NEAR участвуют в принятии решений по управлению протоколом.
• Гранты для экосистемы: NEAR Foundation распределяет токены NEAR в качестве грантов на развитие экосистемы.

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

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

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

Что означает валидация без состояния для валидаторов

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

1. Хранение состояния шарда не требуется: валидаторы чанков больше не поддерживают локальное использование состояния назначенной им шарды.
2. Свидетельства состояния заменяют синхронизацию состояния: валидаторы чанков получают свидетельство состояния с каждым чанком, содержащее все необходимые данные состояния для проверки.
3. Свободная ротация шарда: при назначении на новый шард в границе эпохи валидаторы немедленно начинают получать свидетельства состояния этого шарда, без необходимости загрузки состояния.
4. Снижение требований к оборудованию для хранения данных: обязательство по хранению данных, которое ранее представляло собой самую большую аппаратную стоимость для роли валидатора чанков, было устранено.
5. Продюсеры чанков сохраняют полное состояние: роль продюсера чанков по-прежнему требует полного поддержания состояния шарда и повышенного аппаратного обеспечения, и это различие имеет значение для планирования инфраструктуры.

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

Валидаторам чанков в рамках модели stateless-валидации не требуется SSD-накопитель большой емкости для хранения стейта шарда. В предыдущей модели это хранилище было основной статьей расходов на оборудование для роли валидатора; теперь это требование отсутствует. Продюсеры чанков поддерживают полный стейт шарда, и им требуется оборудование для хранения данных, пропорциональное размеру стейта их шарда; операторам, планирующим запуск продюсеров чанков, следует это учитывать. Официальные спецификации оборудования для обеих ролей опубликованы на docs.near.org/concepts/basics/validators.

Распределение шардов происходит эпохами длительностью около 12 часов. На границе каждой эпохи механизм выбора валидаторов NEAR перераспределяет валидаторов чанков по шардам. При безгосударственной валидации (stateless validation) это перераспределение происходит плавно: вновь назначенный валидатор получает доказательства состояния (state witnesses) для чанков своего нового шарда от производителя чанков и немедленно приступает к валидации. Предыдущая модель требовала синхронизации состояния, которая могла занимать часы; для валидаторов чанков эти издержки устранены. Подробности механизмов эпох и распределения вознаграждений задокументированы на docs.near.org/concepts/basics/epoch.

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

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

Что такое NEAR Protocol?

NEAR Protocol — это блокчейн первого уровня (Layer-1) на алгоритме proof-of-stake, использующий шардинг Nightshade для обработки транзакций в параллельных шардах. В рамках обновления «Фаза 2» была внедрена валидация без сохранения состояния (stateless validation), позволяющая валидаторам чанков проверять транзакции без локального хранения состояния шарда. NEAR Protocol использует токен NEAR для оплаты комиссий за транзакции, стейкинга и управления. Для получения полной информации см.: Что такое NEAR Protocol?

Кто создал NEAR Protocol?

NEAR Protocol был сооснован Ильей Полосухиным, соавтором статьи 2017 года «Attention Is All You Need», представившей архитектуру Transformer, лежащую в основе современных больших языковых моделей, и Алексом Скидановым, бывшим инженером-программистом Microsoft и соавтором дизайна шардинга Nightshade. Оба основателя привнесли уникальный технический опыт, который сформировал архитектуру NEAR, ориентированную на исследования. Полную информацию можно найти: Что такое NEAR Protocol?

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

Безстатусная валидация — это модель архитектуры блокчейна, в которой валидаторы проверяют транзакции, не поддерживая локальную копию состояния сети. Вместо хранения состояния валидаторы получают «свидетельство состояния» (state witness) — криптографическое доказательство, содержащее только данные состояния, необходимые для проверки конкретного блока или фрагмента. NEAR развернула безстанутсую валидацию в рамках Nightshade Phase 2; это первый крупный Layer-1, внедривший эту модель в продакшен. Полное описание см.: Что такое безстатусная валидация NEAR?

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

Шардинг Nightshade в сети NEAR разделяет блокчейн на параллельные потоки обработки, называемые шардами. Каждый шард одновременно обрабатывает подмножество транзакций и создает сегмент блока на уровне шарда, называемый чанком (chunk). Валидаторы назначаются на определенные шарды на каждую эпоху, а производители блоков объединяют все чанки из всех шардов в единый финальный блок. Для получения полной информации см.: Как работает NEAR: объяснение шардинга Nightshade

Что такое свидетель состояния (State Witness) в NEAR?

Свидетель состояния в NEAR — это компактное криптографическое доказательство, создаваемое продюсером чанка и содержащее все данные о состоянии шарда, которые необходимы валидатору чанка для проверки конкретного чанка. Оно включает записи дерева состояний (state trie), затронутые транзакциями чанка, а также доказательства Меркла их включения в дерево состояний шарда. Свидетели состояния — это аттестации на основе доказательств Меркла; они не являются доказательствами с нулевым разглашением. Для получения полной информации см.: Что такое свидетель состояния?

Кто такие валидаторы чанков в NEAR?

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

Использует ли NEAR Proof of Stake?

Да. NEAR использует Thresholded Proof of Stake (вариант Proof of Stake с пороговыми значениями), в котором валидаторы выбираются на основе минимального порога доли (stake), а не по строгому ранжированию топ-N по размеру доли. NEAR имеет примерно 100 активных валидаторов за эпоху. Держатели токенов NEAR могут делегировать свою долю в стейкинг валидаторам, не запуская собственную инфраструктуру. Полное описание см.: Что такое NEAR Protocol?

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

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

Что такое динамический решардинг?

Динамический репарционинг (Dynamic resharding) — это запланированное обновление NEAR в рамках Фазы 3, цель которого — позволить сети автоматически разделять или объединять шарды на основе спроса на транзакции в реальном времени, масштабируя пропускную способность вверх или вниз без простоев валидаторов или ручной переконфигурации. На данный момент оно еще не запущено. Валидация без состояния (Stateless validation) является архитектурным обязательным условием для динамического репарционинга, так как валидаторы без состояния могут мгновенно назначаться на новые или переконфигурированные шарды без операции синхронизации состояния. Полный обзор см. в разделе: Динамический репарционинг: что будет после валидации без состояния

Каковы требования к оборудованию для валидаторов NEAR после валидации без состояния?

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

Заключение

Обновление NEAR Protocol, связанное с валидацией без сохранения состояния, разделяет валидацию чанков и хранение состояния, снижая аппаратные требования для валидаторов чанков и создавая техническую основу для динамического шардинга Фазы 3. Валидаторы чанков теперь получают свидетельство состояния (state witness) для каждого чанка, а не поддерживают локальную базу данных состояния шарда. Ротация шардов на границах эпох происходит беспрепятственно. Пул валидаторов разработан для расширения по мере снижения минимальных аппаратных требований для валидации чанков.

Дорожная карта Nightshade представляет это как последовательную разработку: Фаза 1 реализовала контроль перегрузок между шардами, Фаза 2 обеспечила валидацию без состояния, а Фаза 3 нацелена на внедрение динамического решардинга, как только модель валидаторов без состояния сделает мгновенное перераспределение шардов технически осуществимым.

Следующие шаги для разработчиков и валидаторов:

• Документация разработчика NEAR для полных спецификаций протокола, руководств по SDK и настройки валидатора
• Rust SDK NEAR) для создания смарт-контрактов на Rust
• JavaScript SDK NEAR) для создания смарт-контрактов на JavaScript
• Обзор стейкинга валидаторов NEAR) для настройки стейкинга и делегирования
• Гранты NEAR Foundation для финансирования проектов экосистемы