Безпека — це протокол.
Шість нейромереж — ConsensusAI, VMGuardian, SmartForge, NetOptimizer, Sentinel і SentinelDex — працюють безперервно як ключові компоненти протоколу, а не як необовʼязкові плагіни. Ланцюжок поєднує постквантову криптографію (NIST FIPS 204, ML-DSA-65), обовʼязковий шлюз безпеки WASM перед деплоєм, безперервний моніторинг після деплою з NFT-сертифікатами в ланцюжку, нативну абстракцію акаунтів на сесійних ключах і браузерний WASM-модуль для перевірки на боці клієнта без довіри.
Він спрямований на чотири структурні вади безпеки Web3: вартість аудитів, квантову вразливість, відсутність безперервного моніторингу після деплою і припущення, що будь-яка дія в ланцюжку завжди вимагає людини з майстер-ключем у циклі.
Аудит буває один раз. Експлойти — ні.
Більшість інфраструктури Web3 використовує ECDSA або Ed25519 — їх ламає алгоритм Шора на достатньо великому квантовому компʼютері. NIST затвердив постквантові стандарти у 2024 році (FIPS 203/204/205). NeuroChain використовує ML-DSA-65 (Dilithium3) з першого дня.
Професійний аудит коштує тисячі доларів і триває тижнями; більшість задеплоєних контрактів виходять без аудиту. NeuroChain робить аудит обовʼязковим, автоматичним і миттєвим — перед кожним деплоєм, майже безкоштовно.
Традиційний аудит — це знімок на певний момент. VMGuardian безперервно повторно перевіряє кожен задеплоєний контракт і видає сертифікати в ланцюжку, що відображають поточний бал безпеки.
Дозволити програмі проводити транзакції від вашого імені зазвичай означає просто віддати їй приватний ключ. NeuroChain натомість робить обмежені сесійні ключі, які можна відкликати, нативним примітивом.
Шість моделей, один протокол.
Оцінює довіру до валідаторів — перераховує її в ланцюжку за запропонованими блоками, поданими голосами й давністю — і керує jail/slash. Сам пропозер обирається за стейком, детерміновано, тож усі валідатори з ним згодні; модель ніколи не торкається кворуму безпеки 2/3.
Безпека байткоду WASM. MLP 10→32→16→1, вбудований у Rust/WASM (без ONNX/libm), навчений на реальних контрактах CosmWasm і шаблонах експлойтів. Лінійний декодер ознак, що розуміє інструкції. 0.3×ML + 0.7×евристика із захистом від даних поза розподілом.
Генерація контрактів за описом природною мовою. Повертає WASM-шаблон, що відповідає наміру, з анотаціями безпеки, готовий до шлюзу перед деплоєм.
P2P-маршрутизація та балансування навантаження шардів — мінімізує кількість переходів повідомлень і вирівнює навантаження валідаторів між шардами.
Ризик транзакцій. Оцінює кожну TX за сумою, газом, розривом nonce, швидкістю та новизною отримувача — детерміновано, з підтверджених блоків. Відповідь градуйована: низький ризик проходить, підвищений утримується з вікном скасування, високий потребує власного ключа власника.
Біржовий ризик. Оцінює кожен своп, переказ активу й виведення за впливом на ціну, часткою резервів, запасом min_out і швидкістю; навчений на класах атак з опублікованих розборів інцидентів. Вона ніколи не відмовляє: високий бал утримує операцію або просить ключ власника.
NeuroConsensus — Malachite (Tendermint BFT)
Консенсус — це Malachite (Informal Systems): Tendermint BFT як вбудована бібліотека Rust з доведеними безпекою та живучістю. Вона узагальнена щодо схеми підпису, тож квантовостійкий ML-DSA-65 підключається напряму. Вибір пропозера зважений за стейком і детермінований, тож кожен валідатор обчислює того самого пропозера для висоти й раунду; AI діє лише там, де вилучення валідатора безпечне — jail і slash зводять силу голосу до нуля. AI ніколи не змінює кворум коміту 2/3 — доказ візантійської безпеки зберігається.
Консенсус: Malachite (informalsystems-malachitebft-*), один інстанс на шард Підписи: ML-DSA-65 (Dilithium3) — підключено як Context::SigningScheme Пропозер: вага = стейк; детермінований seed = height·1_000_003 + round Валідатори: ключ консенсусу підписує лише блоки; валідатором керує гаманець власника Докази: детектор еквівокації через gossip → спалення + jail Застосунок: модуль стану (apply_tx, Merkle state root, мемпул) = машина станів
Шардинг — один шард на старті, багато за задумом
Мережа стартує на одному шарді. Рушій шардингу лишається в коді та в серії тестів на двох шардах: кожен шард запускає власний інстанс Malachite з власною підмножиною валідаторів, а міжшардовий переказ стає транзакцією в блоці шарда-отримувача і зараховується лише після того, як його списання перевірено за блоком, який сертифікували валідатори шарда-джерела. Перехід на більше шардів — запланована міграція, а не перемикач.
account_shard = FNV-1a(addr) % n_shards висоти кожного шарда відстежуються незалежно міжшардово: списання (блок джерела, сертифікований) → receive tx (блок отримувача) → ack | refund global root = SHA3-256(shard_0_root || … || shard_n_root)
Стан — RocksDB, Jellyfish Merkle-дерево та сертифіковані знімки
Accounts · Blocks · Txs (+ from/to/block/ts) · Stakes · Delegations · Rewards Nodes · Humans · Contracts · Contract-state · Events · Models · Proposals · Votes Certs · Oracle · Vault · Cross-shard (+ index) · Params · NFT · Slashes · Evidence Checkpoints · Templates · Meta — усього 41 CF Jellyfish Merkle-дерево акаунтів, оновлюється за кожною зміною (без повної перебудови на блок) lattice-hash комітмент над кожною колонкою консенсусу → один state root на блок state sync: нова нода відновлює знімок, перевірений сертифікатом коміту (>2/3 стейку) захист від подвійного підпису: валідатор ніколи не підписує висоту двічі, навіть після відновлення інваріант пропозиції: кожна нода перевіряє, що її реєстр дорівнює її залишкам
Нативні активи та біржа з пакетними аукціонами
Активи нативні для ланцюжка, а не контракти. Свопи стають у чергу в пакет на кожен блок, і обидва напрямки пулу виконуються за однією єдиною ціною — порядок усередині блока не можна використати для сендвіч-атаки. Кожен своп має мінімальний вихід. NRO — валюта комісій, а не актив пулу; голосування може це змінити. SentinelDex, окрема модель, оцінює кожну DEX-операцію в консенсусі: ризикована чекає завершення вікна скасування або потребує підтвердження власника.
Постквантова криптографія
Підписи TX + BFT: ML-DSA-65 (Dilithium3) — NIST FIPS 204, без запасного варіанта
Деривація адреси: слова → SHA3-256 → пара ключів ML-DSA-65
address = neuro:<SHA3-256(pubkey)[..15]>.human (address = f(pubkey))
Перевірка в браузері: ML-DSA-65 у WASM
Дорожня карта: ML-KEM (FIPS 203) · SLH-DSA (FIPS 205)Кожен деплой перевіряє AI.
VMGuardian — обовʼязковий шлюз перед деплоєм усередині ноди на Rust, без обходу на рівні API. Модель — MLP на 897 параметрів, вбудований у Rust/WASM без ONNX чи libm, навчений на реальних контрактах mainnet і відомих шаблонах експлойтів. Бал поєднує невелику ML-складову з евристичним рушієм правил, а захист від даних поза розподілом повертається до чистої евристики, коли вони розходяться.
deploy TX → apply_tx:
1. перевірити WASM magic + граничний розмір
2. hash(bytecode); у whitelist? → пропустити шлюз, максимальний бал
3. analyze(bytecode) → risk_score + violations[] (ML-суміш + лінійний декодер)
4. risk ≥ deploy_risk_threshold? → відмова + журнал | інакше деплой
security_score = виводиться з (1 − risk_score)Правила виявлення
Динамічний call_indirect, за яким іде запис у сховище, — класичний вектор виведення коштів, що стоїть за зломом DAO і десятками DeFi-експлойтів.
Цикл без структурної межі — gas griefing / DoS. Виявляється O(n)-аналізом стека керування (замінив попереднє O(n²)-сканування).
Присутній memory.grow — контракт може виділяти довільну памʼять під час виконання, ризикуючи OOM хоста або gas griefing.
Багато імпортів хост-функцій — більша поверхня атаки, якщо будь-яка окрема хост-функція вразлива.
Екстрактор ознак — лінійний WASM-декодер, що розуміє інструкції: один прохід, який коректно пропускає immediate-значення та родини префіксних опкодів і закриває вектор відмови в обслуговуванні з попереднього підходу з побайтовим скануванням.
Справжній WASM з обліком fuel.
Контракти — це справжній WebAssembly, який виконує інтерпретатор wasmi з газом на основі fuel, а не симуляція. Хост-функції дають реальне сховище, баланси, перекази, виклики між контрактами та перевірений нодою контекст (викликач, висота блока, історичний стейк).
get_storage / set_storage — ціна за байт, обмеження проти роздування стану get_balance / transfer — переказ перевіряється за балансом контракту emit_event / set_return — події / дані повернення виклику call_contract — синхронний виклик іншого контракту (обмежена глибина) get_caller() — підписант TX, перевірений нодою (не поле від клієнта) get_block_height() — висота, перевірена хостом (таймлоки не підробити) get_stake / get_stake_at — поточний + історичний стейк (snapshot-голосування)
Out-of-gas → trap → revert, менше 100 мс Сховище оплачується за байти, тож «дешево за газом, дорого за диском» не дає DoS Суфікси адрес: .human · .node · .app · .vault · .agent — типізовані за роллю, не косметика
Комісії, що самостабілізуються.
Адаптивний ринок комісій у стилі EIP-1559. Кожен блок записує базову комісію, яка рухається відносно цільової заповненості. Комісії діляться між спалюванням (дефляційним) і пропозером блока. Уся внутрішня арифметика ведеться в найменшій деномінації; сервер додає до кожного грошового поля зрозуміле людині значення, тож фронтенд ніколи сам не конвертує одиниці.
base_fee: вище цілі → зростає · нижче цілі → знижується · на цілі → без змін fee = gas_used × (base_fee + priority) → base ділиться спалення/пропозер, priority пропозеру
Перевірте це в браузері.
Один компактний WASM-модуль виконує ту саму логіку перевірки на Rust, що й нода, тож результат клієнта не може підробити сервер. Він містить перевірку підписів ML-DSA-65 для атестацій.
Перевіряє TX локально перед надсиланням: баланс, послідовність nonce, оцінку газу. Повертає null у разі успіху або рядок помилки.
Запускає суміш analyze_v2 (ML + евристика) на байткоді WASM — risk_score, model, ml_score, issues[]. Результат у браузері зʼявляється раніше за будь-який запит до API.
Перевіряє підпис ML-DSA-65 ноди над балом VMGuardian — доказ без довіри, що стоїть за значком, атестованим сервером.
Перевірка Merkle-шляху SHA3-256, ідентична власному модулю стану ноди. Перехресна перевірка за чекпоінтом отримує незалежний root, щоб спіймати ноду, яка бреше.
~115 КБ · той самий код Rust, що й власний модуль стану ноди ліниве завантаження + прогрів · кеш IndexedDB (ключ за хешем) · самоперевірка за маніфестом версії
Ваш агент може діяти в ланцюжку. Він ніколи не бачить вашого майстер-ключа.
Більшість ланцюжків прикручують абстракцію акаунтів як стандарт гаманця на смартконтракті. NeuroChain розглядає сесійні ключі, спонсорований газ та ідентичність агента як примітиви протоколу — на тому самому рівні, що обробляє звичайні перекази.
Акаунт .human або .agent видає обмежений ключ, який можна відкликати, з власними лімітами витрат. Кожна операція сесійним ключем так само підписується і так само перевіряється на шляху консенсусу — сесійний ключ є обмеженим обліковим засобом, а не обходом.
Адреси типізовані за роллю: .human, .node, .app, .vault і .agent. Адреса .agent — це ідентичність у ланцюжку, створена для автономних або напівавтономних учасників, а не людський гаманець, перевдягнений для нагоди.
Примітив газового пулу в стані дозволяє агенту проводити транзакції без власного балансу на старті — це прибирає класичний крок онбордингу «спершу поповніть бота, інакше він нічого не зможе».
Повноваження сесійного ключа обмежені дозволом, а не довірою до програми, яка його тримає. Відкликання дозволу — підписана операція в ланцюжку, а не звернення до підтримки.
Найризикованіші операції, які агент може почати, — саме ті, які він не може завершити: підтвердження доступне лише з майстер-ключем власника, а сесійному ключу воно заборонене в самій перевірці консенсусу. Делегування лишається делегуванням — агент діє, власник і далі вирішує.
Окремий MCP-сервер надає інструменти читання (баланси, дані експлорера, реєстр моделей) та запису (переказ, стейк, виклики контрактів), обмежені сесійним ключем, — тож агент на основі LLM може діяти в ланцюжку в межах, які людина задала заздалегідь.
Як авторизується переказ сесійним ключем
grant: власник підписує { session_pubkey, scope, spend_limit, expiry } → записано консенсусом
agent tx: підписано сесійним ключем → apply_tx перевіряє, що дозвіл активний, у межах scope, під лімітом
revoke: власник підписує операцію revoke → дозвіл неактивний з наступного блока, expiry не потрібенПривілейовані операції — видача, відкликання, підвищення ліміту — і далі вимагають майстер-ключа власника. Сесійний ключ може робити лише те, на що його обмежено, і лише поки дозвіл активний. MCP-сервер надає це AI-агентам напряму: інструменти читання стану ланцюжка та інструменти запису (переказ, стейк, виклики контрактів), що підписують сесійним ключем, — тож агент на основі LLM проводить транзакції в межах, які людина задала заздалегідь, а не постфактум.
NRO — кредит на аудит.
Символ NRO · фіксована пропозиція · базова одиниця uNRO (1 NRO = 1,000,000 uNRO) Частка всіх базових комісій за газ спалюється в кожному блоці (дефляційно) · нативна одиниця L1
NRO оплачує газ, стейкінг валідаторів, врядування, зважене за стейком, реєстрацію преміальних адрес і генерацію контрактів. Адреси .human безкоштовні — вони виводяться із сид-фрази, NRO не потрібен. Куплене імʼя — це NFT і аліас адреси власника: усе, що на нього надіслано, потрапляє на адресу власника, і воно переходить разом з NFT. Його ціна залежно від довжини та найкоротше імʼя в продажу — параметри врядування: імена доступні від пʼяти символів, коротші — за голосуванням.
Зважене за стейком, захищене від flash-атак.
Делегування: обмежена комісія; делегатор отримує reward × (1 − commission) Слешинг: подвійний підпис → спалення + jail (сила голосу нуль); розподіл спалення/винагорода репортеру
Snapshot-голосування
Врядування читає стейк виборця станом на минулий блок — з історії чекпоінтів лише для дописування, яка записується при кожному stake/unstake/register/slash. Пропозиція фіксує свій snapshot-блок під час створення, тож стейкінг безпосередньо перед голосуванням не дає жодної додаткової ваги.
DAO для врядування
Шаблон DAO в ланцюжку реалізує таймлок, snapshot-голосування та guardian (лише скасування). Ідентичність виборця береться з перевіреної нодою ідентичності викликача, ніколи з поля payload. Виконання атомарне — невдала дія відкочує всю пропозицію.
propose → cast_vote (вага = стейк на snapshot) → queue → timelock → execute quorum = увесь стейк на snapshot × quorum_bps · approval = for / (for + against) guardian скасовує шкідливу пропозицію; будь-хто скасовує, якщо стейк автора впав нижче порога
Підпис доводить володіння.
Адреса .human математично привʼязана до свого ключа (address = SHA3-256(pubkey)[..15]), і підписує та сама пара ключів ML-DSA-65 — тож дійсний підпис переказу доводить володіння без довіри за першим використанням. Перекази перевіряються всередині apply_tx на кожній ноді (на рівні консенсусу, стійко до візантійських збоїв). Кожна інша операція підписується повністю: підпис охоплює кожне поле, з яким вона працює, тож ні пропозер блока, ні нода-ретранслятор не можуть змінити отримувача, суму чи голос, а гаманець показує операцію до підпису.
Адреса виводиться з публічного ключа, але набір ключів, що нею керують, живе в реплікованому стані. Ключ можна ротувати або замінити без втрати ідентичності: ротація — це транзакція, чий підпис має і контролювати ідентичність сьогодні, і охоплювати точну зміну, тож пропозер не може ні підробити її, ні підмінити.
Власник, який втратив усі ключі, заздалегідь призначає guardians; відновлення запитують і схвалюють вони через консенсус, а не служба підтримки. Ніхто, зокрема валідатор, не може почати його для ідентичності, яка їх не призначила.
Привілейовану операцію — голос, переказ NFT, видачу сесійного ключа, платіж з vault — готує нода і підписує над кожним полем, з яким вона працює, у власному домені. Пропозер або нода-ретранслятор, що змінює одне поле, ламає підпис; консенсус її відхиляє. Те саме стосується кожної операції з активами та DEX, суми яких нода конвертує до того, як гаманець підпише.
Гаманець підписує те, що показує. Операції з активами та DEX супроводжуються зрозумілим людині описом, який нода формує з точного payload; нічого не підписується наосліп, а запит для іншого гаманця, ніж розблокований, відхиляється.
Ключ консенсусу підписує лише блоки. Кожним валідатором — і генезисними теж — керує гаманець власника, вказаний у конфігурації генезису, так само як працює операторський акаунт Cosmos чи withdrawal credential в Ethereum; платна адреса без власника не приймає жодного ключа.
Куплене імʼя — аліас свого власника, оплачений власником і переданий як NFT. Протокольні імена та реєстр зарезервованих імен, який веде врядування, закриті для всіх, крім власників, яких дозволяє голосування; імʼя, схоже за формою на адресу, виведену з ключа, купити неможливо. Тікери й назви активів перевіряються так само.
apply_tx перевіряє підпис і закріплює ключ для кожного підписаного переказу на кожній ноді — візантійський пропозер не може протягнути підроблений переказ повз послідовників.
VMGuardian сканує кожен WASM-контракт до потрапляння в стан. Ризик на рівні порога або вище відхиляється одразу. Обходу через API немає; аварійний вимикач врядування та whitelist за хешем існують лише для надзвичайних ситуацій.
Фоновий цикл повторно перевіряє задеплоєні контракти; суттєвий дрейф бала створює транзакцію оновлення сертифіката через консенсус. Sentinel оцінює кожну транзакцію до потрапляння в мемпул, детерміновано з підтверджених блоків, тож кожна нода отримує ту саму цифру.
Вага голосу — це стейк на snapshot-блоці пропозиції з історії чекпоінтів лише для дописування — стейкінг безпосередньо перед голосуванням не дає жодної додаткової ваги.
Версії AI-моделей реєструються BFT-транзакцією зі шлюзом лише для валідаторів і кворумом голосування кваліфікованої більшості; ваги синхронізуються через P2P та активуються автоматично.
Компактний WASM-модуль виконує власну логіку перевірки ноди на Rust — перевірки TX, сканування байткоду, Merkle-доказ і атестацію ML-DSA-65 — тож результат на боці клієнта не може підробити нечесний сервер.
NFT-сертифікат безпеки в ланцюжку
{ "contract_hash": "sha3-256 байткоду WASM",
"security_score": 92, // обчислює VMGuardian, не клієнт
"violations": [], // порожньо для чистих контрактів
"certified_by": "neuro:vmguardian.node",
"level": "Bronze | Silver | Gold" }
Карбується під час деплою, оновлюється циклом моніторингу при суттєвому дрейфі бала
Посилання з транзакції деплою в експлореріПостачається однією командою.
docker-compose up -d # нода + gateway + web docker-compose --profile monitoring up # + Prometheus + Grafana уся конфігурація через змінні середовища, без захардкоджених значень
Метрики: висота блока · кількість пірів · розмір мемпулу · усього в стейку
базова комісія · спалені комісії · відмови в деплої за правилом · стан реєстру моделей
Ліміти: ліміти частоти RPC і P2P на IP · ліміти gateway · насичувальна арифметика всюдиЩо вже випущено, що далі.
Моделі, що захищають ланцюжок, достатньо малі, щоб їх довести. Такий напрямок: аудит безпеки, результат якого несе криптографічний доказ замість підпису довіреної сторони, і доказ, що подорожує з активом між ланцюжками, а не лишається привʼязаним до того, де його створено, — верифікований AI зустрічається з інтероперабельністю.