Що таке Nervos Network: CKB, комірки та Layer 1, зосереджений на перевірці

2026-08-24

Базовий шар Nervos Network називається CKB, тобто Common Knowledge Base. Він використовує модель Cell для on-chain стану, виконує скрипти у сумісній з RISC-V CKB-VM і застосовує консенсус Proof of Work. Цей матеріал пояснює задокументовані ролі, а не спонукає до дій щодо мережі чи її нативного активу.

Щоб зрозуміти екосистему й сценарії використання Nervos, сам Nervos Network та принцип його роботи, слід відокремити базовий шар, нативний актив місткості й застосунки або протоколи, що можуть використовувати цей шар. Документація Nervos подає CKB як основу для зберігання стану та перевірки правил, пов'язаних із цим станом.

Це розмежування важливе, бо назва проєкту, мережа, тикер і конкретний застосунок не є взаємозамінними. CKB — нативний CKByte базового шару, Cell — контейнер стану, а Script — код, який може обмежувати використання Cell. Поточний стан окремого застосунку, інструмента чи інтеграції потребує власних джерел і власної on-chain перевірки.

Що таке Nervos Network?

Nervos Network — ширша система навколо CKB, Common Knowledge Base. Офіційна документація описує CKB як фундаментальний шар Nervos Network і публічний permissionless блокчейн Layer 1. Його призначення — надати іншим шарам та застосункам безпечне, децентралізоване середовище для стану й перевірки.

Назва Common Knowledge Base описує архітектуру, а не підтверджує кожне твердження застосунку. Базовий шар записує та перевіряє визначені зміни стану за правилами консенсусу, але не вирішує, чи точний зовнішній опис, чи надійний інтерфейс, або чи розумне правило застосунку. Прийняття транзакції протоколом саме по собі не відповідає на ці питання.

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

Тому на запитання, що таке Nervos Network, варто спершу відповісти стримано: це система навколо програмованого базового шару CKB із Proof of Work. Далі потрібно з'ясувати, які Cells задіяні, які Scripts ними керують, про яку мережу йдеться та які офіційні документи або публічні записи ланцюга підтверджують конкретне твердження.

Яку проблему вирішує Nervos Network?

Публічний ланцюг має дозволяти незалежним учасникам перевіряти зміни стану. Якщо правило визначає, хто може використати актив або які дані розпізнає програма, вузли повинні валідовувати його без довіри до бази даних одного оператора. Nervos виконує це базове завдання через Cells, Scripts, транзакції та консенсус Proof of Work, а не через єдину спільну модель балансу для всієї логіки застосунків.

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

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

Proof of Work покриває іншу частину задачі: узгодження розподіленими учасниками коректної історії та порядку транзакцій. Офіційні матеріали Nervos описують NC-MAX як розвиток консенсусу Накамото з процесом пропозиції та підтвердження. Це властивості мережевої перевірки, а не причина вважати справжніми будь-який сайт, позначку адреси або повідомлення застосунку.

Як працює Nervos Network?

На високому рівні Nervos подає повторно використовуваний on-chain стан як Live Cells. Транзакція вибирає наявні Live Cells як входи та створює нові output Cells. Вхідні Cells споживаються, а вихідні стають кандидатом на наступний стан. Отже, питання, як працює Nervos Network, є точнішим, коли вказано, які Cells споживаються, які створюються і які Scripts мають прийняти перехід.

Кожна Cell має місткість, виміряну в CKBytes, і може містити дані та посилання на Scripts. Офіційна документація пояснює, що пов'язаний Lock Script керує власністю й доступом до Cell, тоді як Type Script може визначати допустиме використання або зміну Cell у транзакції. Перший зазвичай стосується права спожити Cell, а другий може додати правила для типу Cells або стану застосунку.

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

CKB-VM використовує набір інструкцій RISC-V. Документи Nervos описують її як середовище виконання Scripts і згадують облік cycles та обмеження на рівні блоку. Для читача важливо, що протокол перевіряє виконувані правила зазначеного переходу; для розробника чи ревізора визначальними залишаються точні code hash, аргументи, залежності, дані транзакції й версія мережі.

Яку роль CKB відіграє в Nervos Network?

CKB — офіційний тикер CKByte, нативного активу базового шару Nervos. Офіційна документація Nervos зазначає, що один CKByte відповідає одному байту місткості для on-chain зберігання даних. Місткість, яку займає Cell, безпосередньо пов'язує CKB зі зберіганням стану, а не лише з умовною одиницею переказу.

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

У моделі Cell місткість має практичний наслідок: поки стан займає байти, відповідні CKBytes лишаються з ним пов'язаними. Коли стан вилучається через коректний перехід, пов'язана місткість може стати доступною для іншої мети. Це пояснює, чому CKB присутній і в моделі зберігання, і в моделі комісій, але не замінює перевірку даних Cell та Scripts конкретного запису.

CKB є нативним для базового шару Nervos, тому цей матеріал не вигадує єдину адресу token contract. Нативний актив слід відокремлювати від іншого представлення, яке може існувати в іншому контексті. Надійний перший крок — визначити мережу, а потім перевірити заявлені адресу, транзакцію, Cell або script hash в офіційній документації та CKB Explorer.

Екосистема Nervos і сценарії використання

Схема Nervos CKB: транзакція споживає Live Cells, створює нові Cells, виконує Scripts у CKB-VM і перевіряється базовим шаром.

Екосистему Nervos і сценарії використання найкраще пояснювати через складові, які показує офіційна документація, а не через змінний список назв. Документація містить матеріали про Cells, Scripts, SDK, активи й цифрові об'єкти. Сценарій має конкретний сенс тоді, коли названі мережа, структура Cell, Scripts, дані та шлях перевірки.

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

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

Оцінюючи заявлений сценарій, варто поставити чотири питання: які Cells зберігають відповідний стан, які Lock Scripts і Type Scripts беруть участь, який точний transaction hash або script hash можна перевірити і який офіційний документ пов'язує ці записи з заявленою функцією? Такий підхід надійніший за висновок лише з назви мережі.

Як влаштована багаторівнева архітектура Nervos?

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

Усередині базового шару Cell Model, Scripts, CKB-VM, транзакції та консенсус мають різні завдання. Cells представляють стан, Scripts обмежують конкретні переходи, віртуальна машина виконує Scripts, транзакція пропонує перехід, а вузли й майнери беруть участь у перевірці та формуванні історії за протоколом консенсусу. Поділ ролей допомагає знайти місце можливої помилки.

Офіційний репозиторій вузла CKB описує програмне забезпечення як реалізацію публічного permissionless Layer 1 і вказує сумісність CKB-VM з RISC-V. Доступний вихідний код цінний для перегляду, але видимий репозиторій не є висновком аудиту. Потрібно зіставити конкретні release, конфігурацію мережі, бінарний Script або розгортання з точним об'єктом, на який спирається твердження.

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

Ризики й обмеження

Головний ризик — сплутати валідність протоколу з безпекою застосунку. Транзакція може відповідати розгорнутим Lock Scripts і Type Scripts, хоча дизайн застосунку, інтерфейс, інтерпретація даних або зовнішній сервіс і далі містять ваду. Scripts є програмами, а програми можуть мати помилки, залежати від припущень або бути розгорнутими з неочікуваною конфігурацією.

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

Деталі мережі й протоколу можуть змінюватися з release або процесами оновлення. Документація має дати, а офіційні джерела описують hard fork як зміну, що вимагає від вузлів дотримуватися оновлених правил. Поточну поведінку слід звіряти з відповідними release, мережею і датованою технічною документацією, а не виводити зі старого посібника або непов'язаної гілки коду.

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

У цьому розділі доречний конкретний інцидент безпеки. У червні 2025 року міжмережевий міст проєкту Force Bridge було зламано через хибу контролю прав доступу; компанії з безпеки та видання, які про це писали, подавали втрату як діапазон приблизно від 3 до 3,9 млн доларів, а не як одну узгоджену цифру, і повідомляли, що виведені активи обміняли на ETH і провели через міксер Tornado Cash. На час розслідування роботу мосту зупинили. Коли незалежні повідомлення розходяться щодо розміру втрати, опис проєкту має зберігати діапазон, а не обирати одне число.

Інцидент мав наслідок і поза протоколом. 2 червня 2025 року Digital Asset eXchange Alliance, об'єднання ліцензованих південнокорейських бірж, відоме як DAXA, випустило попередження щодо CKB після підтвердження, що активи в екосистемі Nervos були скомпрометовані через міст. Таке попередження є заходом захисту інвесторів, а не встановленням порушення, і дозволяє біржам-учасницям діяти далі, наприклад позначити актив як такий, що потребує обережності, або припинити його торгову підтримку. Поточний статус варто перевіряти на біржах, які його випустили, а не вважати незмінним.

Як самостійно перевірити Nervos Network?

Почніть з офіційної документації Nervos і підтвердьте дату, охоплення сторінки та мережу, яких стосується твердження. Документація встановлює словник: CKB є нативним CKByte, Cell несе стан і місткість, а Scripts визначають відповідні правила перевірки. Якщо твердження не можна пов'язати з офіційною сторінкою, репозиторієм або впізнаваним записом ланцюга, його слід вважати неперевіреним.

Для публічних даних ланцюга використайте офіційний оглядач блоків CKB, щоб перевірити адресу CKB, transaction hash, висоту блоку або script hash. Порівняйте точну мережу, ідентифікатор, входи та виходи транзакції й показані деталі Cell або Script з документацією. Це шлях лише для читання, який не вимагає підпису чи подання транзакції.

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

Для тверджень про програмне забезпечення або протокол використайте офіційний репозиторій Nervos Network і зіставте гілку, release, версію документації та мережу. Зміни й відомості про безпеку слід читати в контексті. Офіційний репозиторій є надійним джерелом опублікованого коду, але сам не доводить, що сторонній сайт запускає той самий код або що конкретне розгортання не має вад.

Підсумок

Nervos Network найкраще розуміти через базовий шар CKB, зосереджений на перевірці. Він поєднує консенсус Proof of Work, модель Cell для стану, Scripts, що керують переходами, та сумісну з RISC-V віртуальну машину, яка виконує ці Scripts. Дизайн точно пояснює перевірку переходу стану, але не перетворює кожне твердження застосунку на встановлений факт.

CKB є нативним активом CKByte. Його задокументовані ролі містять надання місткості зберігання та покриття комісій, пов'язаних із транзакціями й обчисленнями. Ці ролі пояснюють зв'язок CKB із моделлю стану, але не відповідають, чи є надійними конкретний застосунок, інтерфейс або окреме представлення. Перед тим як покладатися на твердження, перевіряйте мережу, Cells, Scripts, ідентифікатори, поточні офіційні документи й офіційний оглядач блоків.

Пов'язані ринкові сторінки

Сторінки Bitbase для токенів, згаданих у цій статті:

- CKB: Переглянути ціну · Ринок безстрокових контрактів

Схожі матеріали

Інші матеріали Bitbase на цю тему:

- Ончейн-метрики пропозиції та прибутку

- Настрої та активність розробників

- Що таке майнінг криптовалют?

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