NEAR – proof-of-stake блокчейн первого уровня, который разделяет состояние на шарды, но собирает их результаты в одну цепочку блоков. В Nightshade каждый шард производит chunk, а блок содержит заголовки chunks всех шардов. Пользователь видит единую сеть с аккаунтами и асинхронными вызовами, хотя вычисление и хранение распределены между разными группами валидаторов.
Вторая важная часть современного NEAR – chain abstraction. Chain Signatures позволяют контракту совместно с пороговой сетью подписывать операции для других блокчейнов, а NEAR Intents дают пользователю описать желаемый результат и выбрать конкурирующего исполнителя. Это отдельные прикладные механизмы поверх L1, а не замена консенсуса или безусловная гарантия лучшего курса.
Nightshade и chunks
Состояние аккаунтов распределяется по шардам. В каждом блоке назначенные chunk producers обрабатывают транзакции и входящие receipts своей части состояния. Block producer объединяет заголовки chunks в общий блок. Поэтому у сети одна последовательность блоков, а не несколько независимых shard chains с разной финальностью.
Транзакция начинается в шарде отправителя. Вызов контракта может создать receipt для другого аккаунта. Если получатель находится в ином шарде, сообщение попадает в очередь межшардовой доставки и исполняется позже. Результат может породить следующий receipt или callback. Асинхронность означает, что сложный вызов не обязан завершиться в одном блоке.
Разработчик должен обрабатывать частичный успех. Например, первый контракт мог списать внутреннюю запись, а удалённый вызов завершился ошибкой. Без правильно написанного callback нельзя считать всю цепочку атомарной, как одну транзакцию в обычной EVM.
Stateless validation
Nightshade 2.0 активировал stateless validation в mainnet в августе 2024 года. Chunk producer передаёт Chunk State Witness – доказательство и необходимые фрагменты состояния для повторного исполнения chunk. Валидатор способен проверить переход, не сохраняя полный state этого шарда постоянно.
Это уменьшает требования к каждому участнику при увеличении числа шардов и позволяет перераспределять проверяющих. Но данные witness нужно вовремя распространить по сети. Слишком большой межшардовый трафик создаёт риск пропущенных chunks, поэтому протокол ограничивает и планирует bandwidth между парами шардов.
Dynamic resharding развивает эту модель: сеть должна разделять загруженный шард или объединять менее активные автоматически. Это сложная миграция состояния, и её реальный эффект следует оценивать по активированным версиям протокола, а не по одной дорожной карте.
Консенсус и финальность
Валидаторы выбираются по proof of stake на эпоху. Отдельные роли производят блоки и chunks, а остальные участники проверяют переходы и подписывают решения. Doomslug даёт быструю практическую финальность при достаточном числе подтверждений, а BFT-механизм закрепляет блок так, что альтернативная история потребовала бы нарушения условий и значительной доли стейка.
NEAR использует slashing и kickout за определённые нарушения или плохую работу. Делегатор не управляет сервером, но выбирает staking pool и разделяет экономический результат. Доходность зависит от эмиссии, доли стейка, комиссии и аптайма, а не является фиксированной ставкой.
Аккаунты и access keys
Аккаунт NEAR может иметь читаемое имя, например подаккаунт проекта, либо неявный криптографический адрес. Один аккаунт способен хранить контракт, баланс, данные и несколько access keys. Full access key подписывает любые допустимые действия. Function-call key ограничивается указанным контрактом, набором методов и allowance для gas.
Ограниченный ключ полезен для приложения: компрометация сессии не обязана давать право перевести весь баланс. Но ограничения нужно проверять до подписи. Если ключ разрешает опасный метод контракта или слишком большой allowance, формальная категория function-call не делает его безопасным.
Хранение состояния оплачивается через заблокированный баланс NEAR. Аккаунт должен поддерживать достаточный остаток для своих байтов. Это не разовая комиссия: токены остаются привязаны к состоянию, пока данные не удалены.
Chain Signatures и Intents
Chain Signatures используют multi-party computation: группа участников совместно формирует подпись для ключа, которым ни один узел не владеет целиком. Контракт NEAR задаёт полезную нагрузку и путь деривации, а результат можно применить в поддерживаемой внешней сети. Безопасность зависит от пороговой схемы, участников, контракта и корректности транзакции назначения.
Intent описывает результат, например обмен одного актива на другой. Solvers предлагают маршруты и исполняют операцию, после чего контракт проверяет условия расчёта. Пользователь делегирует исполнение, но не должен делегировать неограниченное право тратить активы. Нужно проверять минимально получаемую сумму, срок, допустимые токены и способ возврата.
Кроссчейн-операция остаётся зависимой от нескольких сетей. Подпись не ускоряет финальность Bitcoin или Ethereum и не устраняет риск обёрнутого токена. Когда маршрут включает мост, полезно различать канонический и сторонний вариант.
История
Илья Полосухин и Александр Скиданов начали совместную работу в 2017–2018 годах с проекта NEAR AI, который пытался обучать модели программированию. Международные выплаты участникам и ограничения ранней инфраструктуры привели команду к задаче масштабируемого блокчейна. В 2018 году был основан NEAR Protocol.
Mainnet запустилась поэтапно 22 апреля 2020 года: сначала в proof-of-authority режиме, затем с независимыми валидаторами и ограниченными переводами. В октябре сообщество проголосовало за снятие ограничений, и сеть перешла к полностью рабочему состоянию.
В 2021 году появились первые стадии шардинга и Rainbow Bridge, Aurora дала EVM-совместимую среду. В 2023 году проект сформулировал стратегию chain abstraction и запустил NEAR DA. В 2024 году Nightshade 2.0 принёс stateless validation, Chain Signatures вышли в mainnet, а NEAR Intents начали работать как инфраструктура исполнения желаемых результатов.
В 2025–2026 годах управление House of Stake и предложения по токеномике расширили роль on-chain координации, а Intents, конфиденциальное исполнение и AI-агенты стали центральной продуктовой темой. Это расширяет потенциальный спрос на сеть, но также отдаляет проект от простого образа одного L1.
Команда
Илья Полосухин ранее работал в Google и был соавтором исследования Transformer, Александр Скиданов создавал распределённые базы данных в MemSQL. Их сочетание опыта машинного обучения и системного программирования определило ранний акцент на удобстве и масштабировании.
Разработка распределена между несколькими организациями. NEAR Foundation поддерживает экосистему и управление, NEAR One развивает nearcore и протокол, отдельные команды создают Intents, кошельки и приложения. Валидаторы принимают обновления сети, поэтому юридическая организация не может единолично заменить работающий консенсус, хотя финансирование и основная экспертиза всё ещё концентрированы.
Токен NEAR
NEAR оплачивает gas и хранение, используется в стейкинге и как базовый актив приложений. Начальное предложение составляло один миллиард токенов. К 2026 году исходный график разблокировок был завершён, поэтому основное изменение предложения связано с эмиссией, сжиганием комиссий и решениями управления.
При запуске максимальная годовая эмиссия составляла 5% общего предложения. В 2025 году сообщество поддержало её сокращение вдвое до 2,5%. Часть комиссий сжигается, а протокол и продукты Intents направляют выручку на выкуп NEAR. Фактическая чистая инфляция зависит от текущего protocol config, объёма комиссий и выполненных выкупов.
Документация gas описывает вознаграждение контракту частью комиссии за исполнение, но этот параметр стал предметом решения House of Stake в 2026 году. Поэтому фиксированный процент нельзя считать вечным свойством. Перед расчётом экономики приложения нужно проверять действующий burnt_gas_reward в конфигурации сети.
Главные риски
- Асинхронные вызовы. Межшардовый сценарий может завершиться частично, если контракт неправильно обрабатывает callback.
- Сложность шардинга. Witness, bandwidth scheduler и resharding увеличивают поверхность ошибок клиента.
- Access keys. Ограниченный ключ безопасен только в пределах реально заданных методов и allowance.
- Chain Signatures. Пороговая сеть и контракт добавляют доверенные компоненты к безопасности внешней операции.
- Intents. Solver может выбрать невыгодный маршрут, если пользователь подписал слабые ограничения результата.
- Управление и экономика. Эмиссия, rebate, выкупы и бюджет меняются решениями сообщества и активными конфигурациями.
Как проверять операцию
Для обычной транзакции нужно сверить signer, receiver, список actions, access key и итоговые execution outcomes. У кросс-контрактного вызова проверить не только первый transaction hash, но и все созданные receipts. Статус первого шага не доказывает успех последнего callback.
Для нового dApp разумно использовать отдельный function-call key с минимальным allowance и сверить разрешённые методы. Общая логика ограниченных полномочий разобрана в материале о сессионном ключе для dApp. Для внешней цепочки сначала провести тестовую сумму по инструкции о безопасном кроссчейн-переводе.
При оценке токена отдельно учитывать эмиссию, долю стейка, сжигание и выкупы, следуя руководству о том, как разбирать токеномику проекта.
Итог: NEAR объединяет одну цепочку блоков с параллельными chunks и асинхронными receipts. Stateless validation делает рост числа шардов практичнее, а Chain Signatures и Intents превращают сеть в слой координации других блокчейнов. Главный компромисс – сложность: пользователь и разработчик должны понимать границы атомарности, полномочия access keys и отдельные риски solver, MPC и внешней финальности.
