NEAR Безстанова валідація: Фаза 2 Шардинг

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

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

Що таке NEAR Protocol?

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

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

NEAR працює як мережа proof-of-stake, у якій валідатори вносять у стейкінг токени NEAR для участі в консенсусі та випадковим чином призначаються до шардів кожної епохи — фіксованого періоду часу, що приблизно дорівнює половині доби. Протокол NEAR був заснований Іллею Полосухіним, співавтором визначної наукової роботи з машинного навчання «Attention Is All You Need», та Олександром Скідановим; NEAR Foundation здійснює нагляд за поточною розробкою протоколу та грантами для екосистеми.

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

Чим NEAR відрізняється від інших блокчейнів L1?

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

• Шардинг виконання Nightshade: NEAR шардує як стан, так і обчислення, а не лише доступність даних. Це відрізняється від підходу Ethereum Danksharding (EIP-4844), який спрямований на шардинг доступності даних для ролапів Рівня 2, а не на шардинг виконання.
• Безстатусна валідація (Фаза 2): Валідатори фрагментів працюють без локального зберігання стану, що є дизайнерським рішенням з прямими наслідками для децентралізації та масштабованості шарду, детально розглянутими в цій статті.
• Середовище виконання смартконтрактів WASM: Контракти виконуються в пісочниці WASM, підтримуючи Rust та JavaScript як основні мови розробки.
• Зрозумілі імена облікових записів: Облікові записи NEAR використовують іменовані ідентифікатори замість хешів відкритого ключа.
• Модель стейкінгу сховища: Контракти оплачують ончейн-сховище шляхом стейкінгу токенів NEAR, пов'язуючи витрати на зберігання зі стейкнутою заставою, а не з платою за байт.
• Практично нульові комісії за транзакції: Структура комісій NEAR розроблена таким чином, щоб залишатися доступною навіть при помірному навантаженні на мережу.

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

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

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

Stateful vs. Stateless Validation: The Key Difference

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

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

Чому NEAR потребував валідації без збереження стану

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

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

Розуміння шардингу: основа масштабованості NEAR

Безстейт валідація (stateless validation) NEAR працює в межах архітектури шардингу Nightshade, яка розподіляє глобальний стан мережі та обробку транзакцій між декількома паралельними шардами. Розуміння цієї архітектури є необхідною умовою для подальшого пояснення механізму, оскільки безстейт валідація є специфічним оновленням того, як валідатори беруть участь у структурі Nightshade.

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

Nightshade — це фреймворк шардингу NEAR Protocol, у якому глобальний стан блокчейну розділений між кількома шардами, кожен з яких створює чанк (блок рівня шарду) у кожному інтервалі блоку. Кілька чанків створюються паралельно у всіх активних шардах і об'єднуються в один канонічний блок виробником блоку для цього інтервалу.

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

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

Повноцінна реалізація Nightshade відбувається у три фази. Фаза 1 встановила базовий шардинг з обробкою частин (chunk processing), де валідатори зберігали повні локальні копії стану. Фаза 2 — це валідація без стану (stateless validation), яка є предметом цієї статті. Фаза 3 — це динамічний решардинг (dynamic resharding), який надає NEAR можливість автоматично регулювати кількість своїх шардів залежно від попиту мережі в реальному часі. Для повної технічної документації щодо моделі шардингу NEAR дивіться docs.near.org/concepts/advanced/sharding.

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

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

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

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

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

Життєвий цикл свідка стану охоплює п'ять чітких етапів:

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

2. Генерація: Виробник блоків (chunk producer), роль валідатора, відповідальна за створення блоку, читає відповідні записи стану зі свого локального копіювати стану шарду та пакує їх у свідок стану (state witness). Виробник блоків зберігає свій локальний стан, оскільки він повинен мати можливість генерувати свідків для майбутніх блоків.

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

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

5. Відкидання: Після завершення валідації валідатор чанка відкидає свідок стану. Свідок не зберігається, не записується і не використовується для оновлення будь-якої локальної бази даних стану.

Структура свідка стану формально визначена як NEAR Enhancement Proposal (NEP). Щоб отримати точну специфікацію та поточний номер NEP, перегляньте репозиторій NEAR NEPs на GitHub. Щодо деталей реалізації у клієнті основного протоколу, перегляньте репозиторій nearcore на GitHub.

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

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

Ключовим структурним моментом є те, що валідатори чанків (chunks) є найчисленнішим класом у мережі, і за умови безстейтового (stateless) підтвердження їм більше не потрібне дороге обладнання для зберігання даних. Лише виробники чанків — значно менша група — зберігають вимогу до зберігання стейту (стану), оскільки вони повинні зчитувати локальний стейт для генерації свідка (witness) для кожного чанку. Ця асиметрія — саме те, що дозволяє набору валідаторів зростати без пропорційного збільшення загальних витрат на зберігання в мережі. Переваги децентралізації зосереджені саме в найбільшому класі валідаторів.

Процес валідації в умовах безстейтового підтвердження

Наступні кроки описують процес від початку нового інтервалу блоку до моменту фіналізації валідованого блоку в мережі NEAR.

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

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

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

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

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

Жодного разу на кроках 3 і 4 валідатор чанків не потребує локального сховища стану. Свідок стану надає весь необхідний доступ до стану протягом операції валідації.

Переваги безстейтової валідації NEAR

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

Нижчі вимоги до обладнання та більша децентралізація

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

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

Ефект децентралізації випливає безпосередньо з цієї зміни обладнання. Нижчі витрати на зберігання зменшують загальні експлуатаційні витрати на роботу валідатора шматка, знижуючи ефективний економічний бар'єр для участі. Це дозволяє створити більший і географічно різноманітніший набір валідаторів, що, у свою чергу, зменшує ризик концентрації валідаторів. Мережа, чиї найчисленніші валідатори можуть працювати на стандартному обладнанні, є структурно стійкішою до централізації, ніж та, де право участі як валідатора вимагає значних капітальних витрат на інфраструктуру зберігання даних. Поточні вимоги до апаратного забезпечення для валідаторів шматків у режимі stateless validation підтримуються за адресою docs.near.org/validator;) ознайомтеся з цією документацією для отримання актуальних даних.

Масштабованість без шкоди для безпеки

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

Пропускна здатність мережі NEAR масштабується приблизно пропорційно до кількості шардів. Більша кількість активних шардів означає більше чанків, що обробляються паралельно протягом інтервалу блоку, що збільшує кількість транзакцій, які мережа може підтвердити за секунду. Безстейтова валідація є необхідною передумовою для досягнення NEAR більшої кількості шардів у великих масштабах. У документації NEAR Foundation наводяться актуальні показники пропускної здатності в міру їх оновлення; для отримання поточних даних TPS, пов'язаних з конкретними конфігураціями шардів, див. docs.near.org.

Це безпосередньо вирішує проблему масштабованості в межах трилеми масштабованості блокчейну. Історичне протиріччя між масштабованістю та децентралізацією в шардованих мережах виникає через те, що збільшення пропускної здатності зазвичай підвищує вимоги до апаратного забезпечення валідаторів, що знижує децентралізацію. Валідація без стану (stateless validation) усуває механізм, що спричиняв цей компроміс, дозволяючи NEAR збільшувати кількість шардів без відповідного тиску в бік централізації. Модель масштабованості досягає свого повного втілення на Фазі 3 — динамічному решардингу, де NEAR отримує можливість автоматично коригувати кількість шардів залежно від навантаження на мережу в реальному часі без будь-якої ручної координації.

Що це означає для розробників, які будують на NEAR

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

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

Вища пропускна здатність зі зростанням кількості шардів. Оскільки NEAR додає більше шардів з підтримкою stateless validation, загальна транзакційна спроможність мережі зростає. Для вашого dApp це означає меншу ймовірність перевантаження у періоди високого попиту та більш стабільні, передбачувані витрати на транзакції у міру масштабування мережі.

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

Шлях розробника Ethereum. NEAR підтримує Aurora, сумісне з EVM середовище виконання, що дозволяє розробникам Ethereum розгортати контракти Solidity на NEAR без переписування їх на Rust або JavaScript. Ці контракти працюють у тій самій базовій мережі та користуються перевагами тих самих покращень інфраструктури без стану валідації.

Безстейтова валідація NEAR проти дорожньої карти безстейтовості Ethereum

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

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

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

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

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

Три фази Nightshade: Пояснення

Повна реалізація Nightshade здійснюється у три окремі етапи, кожен з яких ґрунтується на попередньому та створює передумови для наступного.

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

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

Етап 2: Безстейтова валідація (Поточний етап)

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

Фаза 3: Динамічне перешардування (Заплановано)

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

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

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

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

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

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

Безстейтова валідація змінює апаратні вимоги для валідаторів чанків, але не змінює фундаментальні механіки стейкінг-контракту. Валідатори все ще вносять в стейкінг токени NEAR понад поріг місця для участі в консенсусі, і вони залишаються під загрозою слешингу за неналежну поведінку валідатора. Вартість апаратного забезпечення для виконання цієї вимоги щодо участі знижується для валідаторів чанків, що розширює коло учасників, які можуть запускати ноду валідатора чанків за економічно вигідних операційних витрат. Поточні апаратні характеристики та пороги місць стейкінгу дивіться на 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 Protocol свідок стану для чанку включає баланси акаунтів, записи сховища контрактів та ключі доступу, які задіяні в транзакціях цього чанку. Продюсер чанку генерує свідок стану та передає його разом із чанком валідаторам чанку, які виконують транзакції за допомогою даних свідка, а потім видаляють їх після створення свого підтвердження (attestation).

Як працюють валідатори NEAR?

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

Як безстейтове валідування покращує масштабованість?

Безстанова валідація покращує масштабованість, відокремлюючи кількість шардів від вимог до обладнання валідаторів. За умови станової валідації, додавання більшої кількості шардів вимагало від валідаторів, призначених для кожного нового шарду, підтримувати пропорційне локальне зберігання даних, створюючи апаратний ліміт щодо того, скільки шардів мережа могла практично підтримувати. Завдяки безстановій валідації валідатори частин (chunk validators) отримують усі необхідні дані стану для кожної частини як свідоцтво стану (state witness) і видаляють їх після використання, тому додавання шардів не збільшує вимоги до сховища для кожного валідатора, дозволяючи 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, що є безстановою валідацією, активована на NEAR Основній мережі. Фази протоколу розгортаються поступово, а документація оновлюється NEAR Foundation, коли кожна фаза досягає повної активації. Щоб дізнатися про найактуальніший статус розгортання, включно з точною датою активації та будь-якими примітками щодо фази, зверніться до блогу NEAR Foundation) та офіційної документації NEAR Protocol.