Що таке NEAR Protocol? Валідація без стану

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

Ця стаття охоплює всі три аспекти, починаючи з того, що таке NEAR, і переходячи до того, як працює валідація без стану, що таке свідок стану, як валідатори чанків та виробники чанків розподіляють свої обов'язки, а також яких цілей прагне досягти динамічний решардинг Фази 3, коли валідація без стану закладе для нього основу.

Зміст

• Що таке NEAR Protocol?
• Яку проблему вирішує NEAR
• Як працює NEAR: пояснення шардингу Nightshade
• Що таке безстейт-валідація 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:

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

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

Середовище виконання WebAssembly (Wasm) від NEAR виконує смарт-контракти у ізольованому, детермінованому, мовно-незалежному форматі. Розробники пишуть контракти на Rust або JavaScript, які є мейнстрімними мовами з великими спільнотами, і компілюють їх до Wasm для виконання. Детерміноване виконання має особливе значення для безстейтової валідації: за однакових вхідних даних стану, доставлених через свідка стану, кожен валідатор генерує однаковий вивід, що робить безстейтову перевірку математично обґрунтованою. Для розробників, які оцінюють 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 — це багатофазне оновлення. Кожен етап спирається на попередній, а безстатусна валідація є другим із трьох запланованих етапів.

Останнє оновлення: 2025. Перевірте near.org щодо поточного статусу дорожньої карти.

Фаза 1 впровадила механізми контролю перевантажень для управління потоком транзакцій між шардами, гарантуючи, що перевантаження шарду не поширюватиметься каскадно мережею. Фаза 2 (stateless-валідація) — це оперативне оновлення, яке детально розглядається в цій статті. Фаза 3 (динамічний решардинг) є запланованою; див. Динамічний решардинг: Що буде після stateless-валідації, щоб зрозуміти, чому Фаза 2 є необхідною передумовою для Фази 3.

Що таке безстанова валідація NEAR?

Безстейтова валідація NEAR — це модель архітектури блокчейну, в якій валідатори чанків перевіряють транзакції шарду, не зберігаючи локальну копію стану шарду. Натомість валідатори отримують «свідок стану» (стислий криптографічний доказ, згенерований продюсером чанку), що містить лише дані стану, необхідні для перевірки певного чанку. Це Nightshade Phase 2, розгорнутий як оновлення протоколу. (допис у блозі про Nightshade Phase 2))

До безстейтової валідації кожен валідатор, призначений до шарду, мусив підтримувати локальну копію стану цього шарду, що постійно оновлюється. Зберігання всіх балансів облікових записів, значень сховища смартконтрактів та інших записів стану для кожного облікового запису в межах шарду було основним апаратним зобов'язанням. Коли валідатори переходили до нового призначення шарду на межі епохи, вони мусили завантажити та синхронізувати весь стан нового шарду, перш ніж могли почати валідацію, процес, який часто займав години роботи з введення-виведення.

Безстатусна валідація повністю усуває цю вимогу для валідаторів чанків. Виробник чанків, вузол зі станом, який підтримує повний стан шарду, генерує свідок стану разом із кожним чанком і транслює обидва компоненти валідаторам чанків. Валідатори чанків перевіряють чанк відносно свідка без будь-якого локального зберігання стану. Для точного пояснення того, що містить свідок стану та як він генерується, див. Що таке свідок стану?

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

Чому це важливо: NEAR може підтримувати більше валідаторів з меншими витратами на інфраструктуру, що є безпосереднім покращенням децентралізації мережі.

Для покрокового опису роботи безстатусної валідації див. Як безстатусна валідація NEAR працює покроково. Щодо конкретної ролі валідаторів чанків порівняно з продюсерами чанків, див. Валідатори чанків проти продюсерів чанків.

Як безстатусна валідація NEAR працює покроково

Процес безстатусної валідації відбувається наступним чином для кожного чанку, обробленого в мережі NEAR:

["1. Транзакція надсилається до мережі та маршрутизується до шарду, відповідального за обліковий запис відправника","2. Виробник чанків виконує транзакції у своєму призначеному шарді проти своєї локальної бази даних стану шарду","3. Виробник чанків генерує доказ стану, що містить лише записи стану, на які вплинули транзакції цього чанку, плюс докази Меркла їх включення до трієра стану шарду","4. Виробник чанків транслює чанк та доказ стану разом призначеним валідаторам чанків для цього шарду","5. Валідатори чанків отримують доказ стану та перевіряють, чи транзакції в чанку правильно застосовуються до наданого стану, без необхідності локальної бази даних стану","6. Валідований чанк пересилається виробникам блоків, які агрегують усі чанки шарду у фінальний блок"]

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

Чому це важливо: розподіл між зберіганням стану (виробники чанків) та верифікацією стану (валідатори чанків) дозволяє пулу валідаторів зростати без пропорційного збільшення витрат на обладнання.

Що таке State Witness?

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

Уявіть свідка стану як нотаріально засвідчений витяг із картотеки. Замість того, щоб відправляти всю картотеку кожному валідатору, виробник чанка витягує лише сторінки, що стосуються транзакцій цього чанка, засвідчує їх криптографічно і надсилає лише те, що необхідно. Ця аналогія справджується і на практичному рівні: валідатор отримує самодостатній пакет доказів, а не повну копію стану.

Технічною мовою: свідок стану містить записи дерева станів (баланси рахунків, значення сховища контрактів), задіяні транзакціями у певному чанку, а також докази Меркла їхнього включення в поточне дерево станів шарду. Валідатор, що отримує свідок, може перевірити кожен доказ Меркла, щоб підтвердити достовірність записів стану, а потім виконати транзакції на основі цих записів, щоб підтвердити правильність результатів чанку.

Як генерується і використовується свідок стану:

["1. Виробник фрагмента виконує всі транзакції у своєму фрагменті відносно свого локального стану шарду","2. Під час виконання він записує кожен запис у дереві станів, який був прочитаний або записаний","3. Він генерує меркл-докази, що доводять належність кожного записаного запису до дерева станів шарду","4. Він пакує ці записи та докази у свідчення стану","5. Валідатори фрагментів отримують свідоцтво, перевіряють меркл-докази та повторно виконують транзакції відносно наданих записів"]

Важливе уточнення для технічних читачів: свідчення стану NEAR є підтвердженнями даних стану на основі доказів Меркла. Це не докази з нульовим розголошенням. Механізм не залучає схеми ZK або системи доведення; він використовує стандартні докази включення дерева Меркла для засвідчення того, що конкретні записи стану є справжніми частинами стану шарду.

Що це означає для валідаторів: Стейт-свідок — це пакет даних, який робить можливою вашу безстанову валідацію. Вам не потрібно довіряти базі даних стану продюсера чанків; ви самостійно перевіряєте Merkle-докази, що містяться у свідку. Якщо докази підтверджуються, а транзакції коректно повторно виконуються на основі наданих записів, чанк є дійсним.

Чому це важливо: оскільки свідки стану є самодостатніми та перевіряються, будь-який валідатор може перевірити будь-який фрагмент без попереднього знання історії шарду, відкриваючи двері для частого, безперешкодного перепризначення шардів.

Валідатори фрагментів проти Виробників фрагментів

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

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

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

NEAR використовує епоху (одиниця часу в мережі NEAR, приблизно 12 годин, наприкінці якої відбувається ротація призначень валідаторів у шардах) для керування ротацією валідаторів. На кожній межі епохи валідатори чанків (chunk validators) перепризначаються до шардів. У попередній стейтфул-моделі (stateful model) ця ротація вимагала завантаження та синхронізації повного стану нового шарда — це дорога операція, яка уповільнювала перепризначення валідаторів і призводила до концентрації набору валідаторів. У безстейтовій валідації (stateless validation) валідатор, перепризначений до нового шарда, просто починає отримувати свідчення стану (state witnesses) для чанків цього шарда і миттєво розпочинає перевірку. Винагороди за стейкінг розраховуються та розподіляються на межах епох. (Документація для валідаторів NEAR, Документація про епохи NEAR)

Що це означає для валідаторів: Ротація шардів на межі епохи більше не потребує завантаження стану. Якщо ваш валідатор буде перепризначений з Шарду A на Шард B у наступній епосі, ви почнете отримувати свідків стану для чанків Шарду B і зможете почати валідацію вже за кілька секунд після початку нової епохи.

Чому це важливо: безпроблемна ротація шардами робить практичною участь значно більшої кількості валідаторів, адже операційні витрати на перепризначення є майже нульовими в моделі без стану.

Чому безстанова валідація важлива

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

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

Валідація без стану сама по собі не змінює модель комісії за газ мережі NEAR; комісії за транзакції все ще визначаються обчислювальною складністю та попитом у мережі. Однак, створюючи архітектурну передумову для динамічного решардингу Фази 3, валідація без стану закладає фундамент для стабільності комісій зі зростанням обсягу транзакцій: більше шардів означає більшу пропускну здатність, і ця потужність може розширюватися без пропорційного зростання комісій. Про те, як динамічний решардинг базується на цьому, дивіться у розділі Динамічний решардинг: Що йде після валідації без стану.

Оновлення NEAR до валідації без стану зміцнює її технічну основу шляхом відокремлення зберігання стану від верифікації стану — це структурна зміна, що впливає на економіку валідаторів, децентралізацію мережі та можливість еластичного масштабування пропускної здатності.

Динамічне перешардування: Що далі після безстатусної валідації

Динамічний решардинг — це заплановане оновлення Фази 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 щодо безстанових клієнтів має ту саму концептуальну мету, що й оновлення NEAR Phase 2, дозволяючи вузлам перевіряти блоки без зберігання повного стану. Запропонований Ethereum підхід, викладений у EIP-4762,), вимагає переходу від Merkle Patricia Tries до Verkle Trees як базової структури стану. Це багаторічна міграція протоколу, яка станом на 2025 рік залишається на стадії досліджень та розробки. NEAR впровадила свою реалізацію безстанової валідації як функцію живого протоколу; еквівалент Ethereum запропонований, але ще не впроваджений. Це різні реалізації, що переслідують подібну архітектурну мету на різних стадіях розробки.

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

NEAR: поточні сильні сторони та обмеження

Сильні сторони:

• Шардинг Nightshade вже запущений і обробляє транзакції в паралельних шардах
• Впроваджено безстейтову валідацію (Фаза 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](https://docs.near.org

Aurora — це сумісний з Віртуальною машиною Ethereum (EVM) рівень виконання, побудований на інфраструктурі NEAR, який дозволяє розробникам розгортати смарт-контракти Solidity на NEAR без переписування коду. Aurora — це окремий екосистемний проєкт, а не функція NEAR Protocol. 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.

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

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

Що безстейтова валідація означає для валідаторів

За безстатусної валідації операційна модель валідаторів фрагментів змінюється п’ятьма специфічними способами:

1. Зберігання стану шарду не потрібне: валідатори чанків більше не зберігають локальну копію стану призначеного їм шарду
2. Свідки стану замінюють синхронізацію стану: валідатори чанків отримують свідка стану з кожним чанком, що містить усі дані стану, необхідні для верифікації
3. Безперешкодна ротація шардів: при призначенні до нового шарду на межі епох валідатори негайно починають отримувати свідків стану цього шарду без необхідності завантаження стану
4. Знижені вимоги до обладнання для зберігання: вимоги до сховища, які раніше становили найбільшу частину витрат на обладнання для ролі валідації чанків, були усунуті
5. Виробники чанків зберігають повний стан: роль виробника чанків все ще вимагає підтримки повного стану шарду та потужнішого обладнання, і ця відмінність є важливою для планування інфраструктури

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

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

Призначення шардів базується на епохах тривалістю приблизно 12 годин. На кожній межі епохи механізм вибору валідаторів NEAR перепризначає валідаторів чанків між шардами. За умов безстейтової валідації це перепризначення відбувається безперешкодно: новопризначений валідатор отримує стейт-вітнеси для чанків свого нового шарду від продюсера чанків і негайно розпочинає валідацію. Попередня модель вимагала синхронізації стану, яка могла тривати годинами; ці витрати для валідаторів чанків було усунено. Механіка епох та деталі розподілу винагород задокументовані за посиланням 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 впровадив безстатусну валідацію як Фазу 2 Nightshade; це перша велика Layer-1, яка реалізувала цю модель у продакшні. Для повного огляду див.: Що таке безстатусна валідація NEAR?

Як працює шардинг NEAR?

Шардинг Nightshade від NEAR розділяє блокчейн на паралельні шляхи обробки, які називаються шардами. Кожен шард одночасно обробляє підмножину транзакцій і створює сегмент блоку на рівні шарду, який називається чанком. Валідатори призначаються до певних шардів на кожну епоху, а продюсери блоків агрегують усі чанки з усіх шардів в один фінальний блок. Для повного огляду див.: Як працює NEAR: Пояснення шардингу Nightshade

Що таке Свідок стану в NEAR?

Державний свідок (state witness) у NEAR — це компактне криптографічне підтвердження, згенероване виробником чанків (chunk producer), яке містить усі дані стану шарду, необхідні валідатору чанків (chunk validator) для перевірки конкретного чанку. Воно включає записи префіксного дерева стану (state trie), яких торкнулися транзакції чанку, а також докази Меркла їхнього включення в дерево стану шарду. Державні свідки — це атестації на основі доказів Меркла; вони не є доказами з нульовим розголошенням. Для повного ознайомлення див.: Що таке державний свідок?

Що таке валідатори чанків у NEAR?

Валідатори чанків у NEAR — це вузли, відповідальні за валідацію окремих шард-чанків, частин кожного блоку на рівні шарду. При безстановому валідуванні вони не зберігають локальний стан шарду; вони отримують свідчення стану від виробника чанку та перевіряють, що транзакції чанку правильно застосовуються до наданого свідчення стану. Валідатори чанків відрізняються від виробників чанків (які створюють чанки та підтримують стан) і виробників блоків (які збирають остаточні блоки). Для повного огляду див.: Валідатори чанків проти виробників чанків

Чи використовує NEAR Proof of Stake?

NEAR використовує Proof of Stake із пороговим значенням — варіант, у якому валідаторів обирають на основі мінімального порогу для внесення в стейкінг, а не за суворим ранжуванням топ-N за розміром внесених у стейкінг коштів. NEAR має приблизно 100 активних валідаторів за епоху. Власники токенів NEAR можуть делегувати внесення в стейкінг валідаторам, не керуючи власною інфраструктурою. Для повного огляду див.: Що таке NEAR Protocol?

Як статичне валідування покращує децентралізацію?

Безстатусна валідація покращує децентралізацію, усуваючи вимогу зберігати стан шарду від валідаторів чанків. Нижчі апаратні вимоги знижують економічний бар'єр для запуску валідаційного вузла. Оскільки більше учасників можуть дозволити собі керувати валідаторами, набір валідаторів розширюється, розподіляючи безпеку мережі серед більшої та географічно різноманітнішої групи операторів. Для повного огляду див.: Чому безстатусна валідація має значення

Що таке динамічне перешардування?

Динамічний решардинг — це заплановане оновлення Фази 3 мережі NEAR, яке має на меті дозволити мережі автоматично розділяти або об'єднувати шарди на основі попиту на транзакції в реальному часі, масштабуючи пропускну здатність вгору або вниз без простоїв валідаторів чи ручного переналаштування. Воно ще не запущене. Безстейтова валідація є архітектурною передумовою для динамічного решардингу, оскільки безстейтові валідатори можуть бути миттєво призначені до нових або переналаштованих шардів без операції синхронізації стану. Для отримання повної інформації див.: Динамічний решардинг: що буде після безстейтової валідації

Які апаратні вимоги до валідаторів NEAR після безстейтової валідації?

Валідаторам чанків більше не потрібні SSD-накопичувачі великої місткості для стану шарду при безстейтовій валідації; основна стаття витрат на обладнання для ролі валідатора чанків була усунута. Продюсери чанків все ще потребують зберігання повного стану шарду та мають підвищені вимоги до обладнання. Конкретні специфікації обладнання для обох ролей опубліковані в документації валідатора NEAR. Для операційного контексту див.: Що безстейтова валідація означає для валідаторів

Висновок

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

Дорожня карта Nightshade позиціонує це як послідовну розробку: Етап 1 запровадив контроль перевантаження між шардами, Етап 2 забезпечив валідацію без збереження стану (stateless validation), а Етап 3 має на меті додати динамічне решардування, щойно модель валідації без збереження стану зробить миттєве перепризначення шардів операційно життєздатним.

Наступні кроки для розробників та валідаторів:

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