Криптовалюта не може продовжувати так: ініціатива самодопомоги від працівника галузі блокчейн

Автор: Роберт Мао, засновник і генеральний директор ArcBlock

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

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

29 жовтня 2026 року на Binance сталася серйозна подія безпеки. Попереднє оголошення оцінювало, що близько 6,3 мільярда доларів активів постраждало, з яких близько 3 мільярдів доларів активів вже заморожено; розслідування спочатку вказувало на ноутбук інженера DevOps, а потім були виявлені інші можливі точки вторгнення. Binance також заявила, що не виявлено доказів витоку приватних ключів гаманців. Сума, що постраждала, не є остаточними чистими збитками, повна ланцюг атаки ще потребує розслідування.

Ця ініціатива адресована будівельникам блокчейн-проектів, таких як Ethereum, Solana, а також Binance, Coinbase, Kraken та всім біржам, гаманцям, протоколам і будівельникам безпеки, які готові долучитися: давайте разом відновимо основи захисту активів. Я готовий долучитися і сподіваюся, що більше людей також візьмуть участь.

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

Binance — це лише точка, з якою ми сьогодні повинні зіткнутися з проблемами. Відвернувши погляд, біржі, мости, протоколи на ланцюгу та гаманці вже залишили довгий список ран. Нові мережі та продукти постійно з'являються, але старі моделі збоїв повторюються знову і знову. Ми не можемо просто випустити оголошення, почекати деякий час, а потім сприймати наступний інцидент як звичне явище.

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

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

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

Ця хронологія інцидентів вже занадто довга

У 2008 році Сатоші Накамото запропонував систему електронних грошей з рівними можливостями, намагаючись зменшити залежність від довірених посередників.

Нижче наведено хронологію представницьких подій у сферах централізованих бірж (CEX), децентралізованих бірж (DEX), мостів та гаманців. Це не повний реєстр інцидентів і не статистика втрат за роками. Суми, якщо вказані, вказують на приблизний валовий вплив на момент інциденту; вкрадені, заморожені та повернені активи описуються окремо, їх не можна складати як постійні втрати.

2008 · Біла книга Bitcoin

• Початок
• Біла книга Bitcoin пропонує точкові платежі без посередництва фінансових установ.
• Джерело

2011--2014 · Тривала крадіжка Mt. Gox

• CEX
• Mt. Gox зазнала тривалої крадіжки і врешті-решт зупинила свою діяльність. Пізніше Міністерство юстиції США звинуватило, що в період з 2011 по 2014 рік було вкрадено близько 647 тисяч BTC. Це не була одноразова атака, що сталася в 2014 році.
• Джерело

2012 · Bitcoinica та Bitfloor

• CEX/інфраструктура зберігання
• Середовище зберігання Bitcoinica на Linode було зламано; того ж року незахищена резервна копія гаманця Bitfloor стала точкою входу для атаки. Сервери та резервні копії, що стоять за платформою, також є межами безпеки активів.
• Джерело

2015 · Гарячий гаманець Bitstamp

• CEX
• Гарячий гаманець Bitstamp був зламаний, після чого було відновлено середовище роботи. Офіційно було розмежовано обсяг інциденту та офлайн-резерви, що свідчить про те, що ізоляція може обмежити масштаб впливу.
• Джерело

2016 · Bitfinex

• CEX
• Близько 120 тисяч BTC було вкрадено з Bitfinex. Багатопідписна схема все ще потребує незалежного авторизації та перевірки з кінця в кінець.
• Джерело 1 · Джерело 2

2016 · The DAO

• Протокол на ланцюгу
• Контракт The DAO зазнав атаки повторного входу, в результаті чого близько 3,6 мільйона ETH було переведено в дочірній DAO, що призвело до розгалуження Ethereum. Легітимні шляхи виконання можуть призвести до катастрофічних бізнес-результатів.
• Джерело 1 · Джерело 2

2017 · Бібліотека спільного гаманця Parity

• Контрактний гаманець
• Бібліотека спільного гаманця Parity була знищена, близько 513 тисяч ETH було заморожено. Не було переведено, але може втратити можливість використання через спільну залежність коду.
• Джерело

2018 · Coincheck

• CEX
• Гарячий гаманець Coincheck був вкрадений. Межі між офлайн-резервами, правами доступу до гарячих гаманців та бізнес-потребами знову стали проблемою.
• Джерело

2019 · Binance

• CEX
• Binance оголосила, що 7000 BTC було виведено в одній транзакції. Великомасштабний вивід активів потребує обмеження перед підписанням.
• Джерело

2020 · KuCoin

• CEX
• Інцидент з гарячим гаманцем KuCoin, пізніше через багатосторонню співпрацю було повернуто велику кількість активів. Валові вкрадені суми та остаточні втрати не є однаковими.
• Джерело

2021 · Poly Network

• Протокол між ланцюгами
• Близько 612 мільйонів доларів активів було переведено з Poly Network, пізніше поступово повернуто. Міжланцюгова авторизація та контроль активів не можуть базуватися лише на нормальних бізнес-шляхах.
• Джерело

2022 · Міст Ronin

• Міст
• Права верифікаторів Ronin були зламані, 173 600 ETH та 25,5 мільйона USDC були переведені. Ключі кількох верифікаторів також можуть потрапити в одну ланцюг атаки.
• Джерело

2022 · Гаманець Slope

• Гаманець
• Інцидент з гаманцем Slope в екосистемі Solana. Офіційні представники Solana вказали, що інформація про приватні ключі була випадково передана до служби моніторингу додатків; це не було зломом консенсусу Solana.
• Джерело

2023 · Euler

• Протокол кредитування
• Близько 197 мільйонів доларів активів було переведено з Euler через вразливість протоколу, пізніше повернуто. Складні комбінації одноразових транзакцій можуть посилити логічні дефекти бізнесу.
• Джерело

2023 · Набір Ledger Connect

• Інструмент підключення гаманця
• Набір Ledger Connect зазнав атаки на ланцюг постачання, шкідливий код потрапив у фронт додатку. Безпека апаратних пристроїв не може замінити перевірку змісту транзакцій.
• Джерело

2024 · DMM Bitcoin

• CEX
• Близько 308 мільйонів доларів було вкрадено з DMM Bitcoin. Пізніше ФБР та інші органи розкрили соціальні атаки на відповідних осіб та ланцюги підписів.
• Джерело

2024 · Radiant Capital

• Протокол кредитування/підпис
• Близько 50 мільйонів доларів було вкрадено з Radiant Capital, кілька пристроїв розробників були зламані. Багато підписів все ще можуть спільно залежати від забрудненої інформації про транзакції.
• Джерело

2025 · Bybit/Safe

• CEX/фронт гаманця
• Інцидент на Bybit на суму близько 1,5 мільярда доларів, атака торкнулася середовища розробників Safe та фронту, підписувачі схвалили транзакцію, що змінила логіку контролю гаманця.
• Джерело 1 · Джерело 2

2025 · Cetus DEX

• DEX
• Інцидент на Cetus на Sui на суму близько 223 мільйонів доларів, дослідники вказали на дефект математичної бібліотеки. Не-EVM середовище також повинно перевіряти код та межі експозиції активів.
• Джерело

2026-07 · Дефект випадкових чисел COLDCARD

• Апаратура гаманця/генерація насіння
• Дефект прошивки послаблює генерацію насіння, зловмисник може відтворити відповідні приватні ключі, коли пристрій офлайн. Оновлення не може виправити вже згенеровані слабкі насіння, все ще потрібно мігрувати відповідно до оголошення.
• Джерело

2026-10 · Модифікація апаратного забезпечення Ledger

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

2026 · Багатоланцюговий інцидент Binance

• CEX/багатоланцюг
• Binance попередньо оцінила, що близько 6,3 мільярда доларів активів постраждало, розслідування інших можливих точок вторгнення триває. Єдина операційна система може одночасно піддавати активи на кількох мережах.
• Джерело 1 · Джерело 2 · Джерело 3

Тут є CEX, а також децентралізовані біржі, протоколи кредитування та мости; є вкрадені активи, а також заморожені активи. Атаки відбуваються на різних рівнях, і методи виправлення також різні. Я проти того, щоб все це зводити до фрази "користувачі не зберігали свої приватні ключі". Як користувач може знати, що певне середовище розробки інструменту, певна спільна бібліотека або незрозумілий дозвіл стануть входом до всіх його активів?

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

Давайте разом будувати безпечну основу з різними технологічними шляхами

Ethereum має великий внесок. Він дозволив більшій кількості людей створювати децентралізовані додатки, що призвело до формування багатого набору інструментів та досвіду розробки. Але сьогодні багато нових блокчейнів та L2 (другий рівень) ставлять сумісність з EVM (віртуальною машиною Ethereum) як пріоритетну мету. EVM, що виконує смарт-контракти Ethereum, стає технологічною основою, що широко копіюється. Сумісність дійсно полегшує міграцію додатків; документація проектів, таких як Unichain, чітко вказує на повторне використання інструментів Ethereum як цінність еквівалентного середовища виконання.

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

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

EIP-7702 чітко демонструє цю проблему. Звичайний переказ — це "скільки передати кому"; делегована авторизація може бути "дозволити цьому коду виконувати дії від мого облікового запису в майбутньому". Вона має на меті покращити досвід використання та деталізувати права, але сама установка делегування надає широкі можливості виконання, а детальні права повинні бути правильно реалізовані кодом делегування. Препринт Minfeng Qi та інших "EIP-7702 Phishing Attack" досліджує шляхи, що ведуть до тривалого контролю облікового запису після підписання такої авторизації. Зручність зростає, але відповідальність за безпеку також зростає, не можна просто покладати це на користувачів.

Інцидент з Binance охоплює кілька ланцюгів, розслідування ще не завершено, тому не можна повністю пов'язувати всі наслідки з EIP-7702 або EVM. Рекурсія, злом сервісів підпису та зміна фронтенду — це не одна й та ж вразливість. Але це розмежування не повинно бути виправданням для припинення запитів до архітектури: чому на нижньому рівні не зберігається більше обмежень, які не можна легко обійти, щоб захистити верхній рівень від помилок?

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

Я завжди вважав, що вплив Ethereum на криптовалюту схожий на вплив PHP на Інтернет: він дозволив багатьом людям створювати речі, але залишив довгострокові борги в інженерії. PHP все ще потребує виправлення серйозних вразливостей віддаленого виконання коду у жовтні 2026 року. Дозрілість і поширення не можуть замінити постійне зміцнення.

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

Отже, я закликаю екосистеми Bitcoin, Solana, Ripple/XRP Ledger, а також будівельників, включаючи ArcBlock, серйозно взяти участь у створенні спільної основи безпеки. Участь у стандартах та взаємодії не повинна вимагати від вас перетворення на Ethereum. Різноманітність повинна бути реалізована в контролі активів та способах верифікації, приймаючи відкриту перевірку. Інциденти Slope та Cetus вже нагадали нам, що не-EVM також не має безпечного імунітету.

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

Сім заходів, які можна почати для зміцнення безпеки

1. Дати базовим ризик-менеджментам контроль над правами на активи

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

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

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

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

2. Нехай гаманці несуть відповідальність за безпеку, а не просто передають мнемонічні фрази

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

Недавні інциденти поставили це питання дуже прямо. Ledger у жовтні 2026 року підтвердив, що зловмисники модифікували справжні пристрої, а потім повернули їх на ринок через дистриб'юторів у Південно-Східній Азії, вбудувавши компоненти, які під час ініціалізації крадуть відновлювальні слова. Ledger визначив це як часткову дистрибуційну атаку після виходу пристрою з заводу, а не як злом його чіпа, операційної системи чи сервера. Інцидент COLDCARD у липні також стосується зменшення генерації насіння: пристрій не потребує віддаленого контролю, зловмисник також може відтворити відповідні приватні ключі. Оновлення прошивки виправляє процес генерації в майбутньому, але вже згенероване слабке насіння все ще потрібно перенести.

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

Безпека чіпа не може замінити перевірку цілого пристрою та процесу доставки.

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

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

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

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

Система перевірених свідоцтв W3C вже має технологічні шляхи для вибіркового розкриття; але потрібно чітко визначити, як підтвердити справжність введених даних, як свідоцтво залишається дійсним і як статус може бути скасовано. Використання доказів нульового знання (ZK) також не автоматично приховує суми транзакцій та зв'язки, розширення доказів та захист конфіденційності є різними цілями.

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

Моя ініціатива полягає в тому, щоб спочатку чітко визначити "хто що має перевірити", а потім розробити дані, які потрібно оприлюднити. Ті, хто перевіряє право, можуть потребувати лише висновку про право; особи, які виконують певні обов'язки з аудиту, можуть отримати обмежені докази. Публічні перевіряємi обмеження повинні максимально зменшити постійне розкриття особистої інформації для всіх.

IV. Зменшення централізованого зберігання для торгових послуг

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

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

IBIT є продуктом торгівлі біткоїном від iShares, на ринку торгуються його частки. Його організація надає приклад часткової ізоляції: частки та основний Bitcoin записуються окремо, а відповідні приватні ключі Vault Balance (баланс зберігання) зберігаються в холодному зберіганні. Записи угод часток змінюються, не вимагаючи, щоб основний Bitcoin рухався з кожною транзакцією. Можна запозичити розділення прав на торгівлю та права на розпорядження резервами. Його Trading Balance (баланс торгових послуг) має різні налаштування, саме зберігання також має ризики; холодне зберігання повинно супроводжуватися незалежними інструкціями та перевіркою підписів.

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

V. Використання багаторівневої архітектури для ізоляції збоїв та збереження можливості заміни

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

Досвід Інтернету підтримує цю ідею. Марк Ноттінгем у RFC 9518 "Централізація, децентралізація та Інтернет-стандарти" спеціально обговорює ситуації, коли централізація може бути корисною, а також аналізує повноваження та ризики, які вона приносить. Це саме той підхід, який варто запозичити: дати архітектурі відповісти на питання, які обов'язки можуть бути централізованими, до якого ступеня централізованими та як запобігти розширенню цих повноважень. Один сервіс може централізовано виявляти аномалії, одночасно обмежуючи свої права доступу до активів; користувачі повинні мати можливість змінювати сервіси, не втрачаючи своїх стратегій активів та записів перевірки.

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

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

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

VI. Дати можливість користувачам легко перевіряти свої активи

Звичайні люди не повинні зберігати та виконувати всю історію ланцюга, щоб перевірити свій баланс і отримання; вони також не повинні покладатися лише на один сервер, що стоїть за гаманцем. Сатоші вже запропонував SPV, тобто спрощену перевірку платежів, у восьмому розділі свого білого паперу. BIP-157 Bitcoin продовжує досліджувати можливість завантаження фільтрів клієнтами, щоб знаходити блоки, що стосуються їх; Ethereum також має дизайн легкого клієнта. Отже, проблема не в тому, що ніхто ніколи не думав про це, а в тому, що нам потрібно реалізувати можливості перевірки з чіткими умовами безпеки в гаманцях, які користувачі використовують щодня.

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

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

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

VII. Створення загальної інфраструктури для виявлення аномалій та безпеки

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

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

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

Програмна інженерія з підтримкою ШІ: наша нова надія

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

Якщо оцінювати за старими методами виробництва програмного забезпечення, це питання є дуже реальним. Але до 2026 року я вважаю, що агенти кодування та програмна інженерія з підтримкою ШІ вже змінили наші можливості для будівництва. Тут під агенти кодування маються на увазі AI-помічники програмування, які можуть читати та писати код у середовищі розробки, викликати інструменти, виконувати тести та продовжувати працювати на основі зворотного зв'язку. Будівельники встановлюють цілі, визначають межі безпеки, використовуючи ці інструменти для реалізації та перевірки системи, а також несуть відповідальність за результати.

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

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

Одним із способів, який можна запустити зараз, є спільне будівництво AI Factory в режимі Build in Public. Галузеві експерти, науковці та практики відкрито пишуть вимоги та специфікації приймання (spec), пояснюючи, що потрібно захистити, які дії дозволені, які права потрібно зберегти, навіть якщо інші будуть втрачені, а потім ці вимоги перетворюються на тести приймання. Групи coding agents виконують основну роботу з кодування, тестування та налагодження; різні команди перевіряють дизайн та результати, а люди несуть відповідальність за оцінку та приймання.

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

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

Незалежні будівельники працюють разом з coding agents та AI інструментами. Космічна майстерня є метафорою для спільного будівництва.

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

Я не вірю, що в цій галузі не вистачає розумних людей, і не вірю, що в Crypto та AI індустрії немає ресурсів для підтримки цієї роботи. Складніше об'єднати таланти, фінанси та постійну відповідальність. Фонди та здатні підприємства повинні бути готові нести довгострокові витрати на базову роботу, яка не приносить безпосереднього доходу, але приносить користь усім.

Я сподіваюся, що ми зможемо спільно створити глобальну спільну криптоінфраструктуру. Різні мережі та команди можуть співпрацювати під спільними безпечними обмеженнями, реалізуючи та перевіряючи один одного, а користувачі можуть вибирати та мігрувати. Це може початися з одного компонента, але напрямок повинен бути достатньо великим, щоб вмістити спільне будівництво всього сектору. Учасники, включаючи ArcBlock, повинні внести перевірні внески.

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

Давайте діяти зараз

Я хочу запросити будівельників проектів, таких як Ethereum, Solana, Bitcoin, XRP Ledger, а також біржі, такі як Binance, Coinbase, Kraken, а також команди гаманців, протоколів, безпеки, AI та хмарних обчислень: почати з чітко визначеного пілотного проекту, спільно створити покращення, які можуть бути прийняті та перевірені іншими командами.

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

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

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

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

Ті, хто готовий взяти участь, ласкаво просимо публічно поширити або процитувати цю ініціативу в X, і @mave99a, розповісти про проблеми, які ви хочете вирішити, анонімні сценарії атак або ресурси, які ви можете внести. Я сподіваюся, що обговорення буде відкритим, щоб більше будівельників могли побачити та продовжити участь.

Crypto не може продовжуватися так. Ті, хто готовий діяти разом, давайте почнемо зараз з покращення, яке можна реалізувати та перевірити.

1. Binance, попереднє оголошення офіційного посту та подальші оновлення розслідування, 2026-10-30; TRM багатоланцюговий аналіз. Ця стаття перевірена станом на 2026-10-30; статус розслідування та повернення може змінюватися. \↩\
2. Сатоші Накамото, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. \↩\
3. Uniswap, Unichain EVM Equivalence. Спільні ризики, на які покладаються, є оцінкою автора цієї статті, а не висновком цього документа. \↩\
4. Віталік Бутерін, Сем Вілсон, Ансгар Дітріхс, lightclient, EIP-7702: Set Code for EOAs, створено 2024-05-07. \↩\
5. Мінфенг Ці, Цінь Ван, Руїцян Лі, Тяньцин Чжу, Шіпін Чен, EIP-7702 Phishing Attack, 2025-12-13, arXiv v1 препринт; не є оцінкою інциденту Binance. \↩\
6. Ethereum, Максимально витягувана вартість (MEV), механізми сортування, різні типи та негативні наслідки; "повинно розглядатися як виправлення помилок" є інженерною позицією автора щодо поведінки, що завдає шкоди користувачам. \↩\
7. Офіційний новинний архів PHP 2026; CISA 2026-10-26 оновлення відомих вразливостей, CVE-2026-109618, CVE-2026-109619. \↩\
8. Safe, Guards та Modules, опис функцій та ризиків прав доступу. \↩\
9. Apple, Apple розширить можливості ремонту з підтримкою використаних оригінальних частин, 2024-04-11; пояснення підтримки блокування поточних частин. \↩\
10. Ledger, Відповідь Ledger на атаку з апаратним імплантом, 2026-10, пояснення виробника щодо атак на етапі дистрибуції; Джо Гранд, зворотне дослідження апаратного імпланту. Не слід формулювати оцінки мережевих втрат без підтвердження виробника. \↩\
11. Coinkite, Поточний статус безпеки COLDCARD, 2026-10-30, огляд, постійно оновлювані записи про інциденти та виправлення 2026 року; оновлення та міграція насіння є двома різними операціями. \↩\
12. ERC-4337: Абстракція облікових записів за допомогою Alt Mempool; Trezor, SLIP39 FAQs, відновлення за порогом, сумісність та ризики додаткових паролів. Існуючий механізм є основою для будівництва, не означає, що кожне розгортання є надійним. \↩\
13. BIP-174: Формат частково підписаних біткойн-транзакцій, формат обміну транзакціями, що чекають на підпис, не є специфікацією для міжланцюгових загальних активів. \↩\
14. W3C, Огляд перевіряємих облікових даних v1.0, 2026-07-30 Групова записка; пояснення конфіденційності Ethereum. Стандартний статус технологій, описаних у огляді, є незалежним. \↩\
15. Документація CoW Protocol, наміри транзакцій та механізм рішень; ця стаття не надає всебічної безпеки для конкретного розгортання. \↩\
16. iShares, IBIT річний звіт 2025, PDF сторінки 8--10 плани зберігання та сторінка 45 опис ризиків. \↩\
17. Марк Ноттінгем, RFC 9518: Централізація, децентралізація та інтернет-стандарти, 2023-12, незалежна подача, пояснювальний RFC, не є стандартною специфікацією. \↩\
18. Розділ 8 Білого паперу Bitcoin Спрощена перевірка платежів; BIP-157: Фільтрація блоків на стороні клієнта; Ethereum, Легкі клієнти. Різні легкі клієнти мають різні обсяги перевірки та умови довіри. \↩\
19. Фонд Ethereum, Оголошення ініціативи безпеки на трильйон доларів, 2025-05-14. \↩\
20. Anthropic, Штучний інтелект для захисту критичної інфраструктури, 2026-01-08, дослідження в обмеженому середовищі у співпраці з PNNL. \↩\
21. Anthropic, Картування кіберзагроз, що активуються штучним інтелектом, дослідження реальних зловживань. \↩\
22. Lucasfilm, Зоряні війни: Нова надія (Епізод IV), 1977; ця стаття запозичує назву твору та образи колективного самозахисту. \↩\