THORChain призупиняє ротацію сховища, доки не буде випущено оновлення v3.20

THORChain призупинив усі операції ротації сховищ після того, як розробники виявили проблему консенсусу, яка проявляється саме під час процесу churning. Команда мережі переформатувала свою дорожню карту навколо одного релізу — оновлення v3.20 — яке об’єднує патчі безпеки, інтеграцію Monero та розгортання router V6 в один узгоджений апгрейд із метою запустити його наступного тижня. Призупинення пов’язане з уразливістю, що потребує змін глибоко в Thornode і не може бути виконана через точковий реліз. Консолідація закриває критичні прогалини у безпеці, одночасно обмежуючи кількість високоризикових сценаріїв оновлень, які мережі доведеться виконати — особливо важливо з огляду на вичерпання пропускної здатності рецензентів у команді розробки.

THORChain призупиняє ротацію сховищ до розгортання v3.20

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

Команда зібралася, щоб випустити v3.20, орієнтуючись на висоту апгрейду наступного тижня. Після виходу релізу план такий: спершу повторно ввімкнути Solana, а потім відновити churning. Усе, що було закладено в обсяг для v3.19.4 — зокрема робота з Monero — тепер переходить у той самий більший реліз разом із новим кодом router V6, який уже готовий і розгортається поступово. Для користувачів після оновлення досвід не змінюється: свопи, як і раніше, маршрутизуються через THORChain Swap.

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

Три послідовно з’єднані баги дали змогу нещодавньому експлойту

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

«Це були три баги, які, зчепившись, стали експлуатованими. Кожен із них окремо був безпечним», — заявив Aaluxx.

Він описав ранок, коли експлойт зламав систему, як «холодний». Команда нещодавно злила патчі TSS із приватного репозиторію, і його перший страх полягав у тому, що помилка в цьому мерджі внесла вразливість. Швидка перевірка це спростувала: коміт був незмінним, а першопричину вдалося відстежити до набагато старішого коду. Насправді команда ще кілька місяців тому вже ловила подібний зчеплений баг — потенційний double-spend, тож базова схема вже була в полі зору.

Команда виявила компрометацію сховища через аналіз криптографічних параметрів

Детекція технічно була вишуканою. Шляхом факторизації одного з криптографічних параметрів налаштування TSS і сканування малих простих чисел, яких не мало бути, розробники могли визначити, чи було будь-яке конкретне сховище отруєне. У THORChain виявилося, що скомпрометованим є одне зі п’яти сховищ, і це пояснює, чому було вилито приблизно 20% TVL, а не всю суму. Метод дав команді надійний діагностичний інструмент у ситуації, де швидкість тріажу була критичною.

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

Maya Protocol зберігала свопи під час місячної паузи THORChain

Під час приблизно місяця, коли THORChain був призупинений, Maya Protocol продовжувала здійснювати свопи. Той самий прихований баг існував у кодовій базі Maya, але його так і не вдалося спровокувати. Більш важливо: Maya працювала з одним сховищем, яке команда могла незалежно перевірити як безпечне — тож вони залишили його в роботі, поки призупиняли churning як запобіжний захід, оскільки churn міг відкрити той самий шлях до експлойту.

Практичний наслідок був реальним: нативні свопи BTC-to-ETH залишалися недоступними в THORChain упродовж того періоду, але були доступні на Maya. Це й є аргумент із надмірності, доведений на практиці.

«Ми маємо літати на літаку з двома двигунами», — заявив Aaluxx.

Після експлойту й під час раннішого TCY періоду деякі голоси пропонували об’єднати THORChain і Maya — використавши RUNE, щоб викупити CACAO і консолідуватися в один більший DEX. Aaluxx визнав, що це було б розумним бізнес-рішенням, але відхилив його в будь-якому разі. Два незалежні permissionless DEX, які поділяють однакові ідеали, — це навмисний дизайн-підхід, а не неефективність, яку потрібно оптимізувати. Вартість надмірності реальна, але так само реальна й ціна єдиної точки відмови.

Обмеження рецензійної спроможності гальмує швидкість розробки

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

«Наш обмежувальний фактор — не створення коду, а його рецензування та розгортання», — заявив Aaluxx.

Наразі лише близько трьох людей мають глибину експертизи, необхідну для рецензування та розгортання змін для THORChain. Додавання більшої кількості розробників або більшої кількості pull request не автоматично прискорює доставку — це додає навантаження на рецензії в і без того вузьке горлечко. Команда працює за навмисним співвідношенням «два до одного»: кожна частина коду, яку пишуть, має щонайменше пройти дві рецензії, перш ніж її буде просунуто далі.

Команда пропонує розділити етап ідеї від ADR-процесу

З боку керування (governance) виникла структурна проблема. Оскільки пропозиції тепер надходять від багатьох учасників, а не від єдиного координуючого органу на кшталт Nine Realms, номери ADR зіткнулися, і «сирі» ідеї були оформлені як формальні ADR до того, як вони були готові до створення.

Запропоноване рішення — повністю розділити етап ідеї та етап ADR. ADR, як сформулював Aaluxx, має бути вже готовим рецептом: стислим, технічним і таким, що можна реалізувати з наявними ресурсами. Чого бракує, — це «верхньої» зони простору — своєрідного поля бою — де сирі ідеї отримують виклики, доопрацювання або відкидаються, перш ніж вони зможуть претендувати на статус ADR.

«Дехто думає, що “я хочу пасту” — це ADR. Ні, це не ADR — це проблема. Приходьте до нас із рецептом», — сказав Aaluxx.

Згодом номери ADR можна було б запитувати й призначати on-chain через node relay, а перший підтверджувальний нод призначав би наступний послідовний номер. Це зробило б володіння пропозицією однозначним, не створюючи централізованого воротаря. ADR, варто повторити, не є передумовою для релізу коду — сьогодні будь-хто може відкривати issues і pull requests на GitLab. ADR — це термометр: він показує операторам нод, чи хочуть вони виділяти платний час розробників на щось.

ShapeShift приєднується до динамічної моделі комісій у міру розширення інтеграцій

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

Порада від спільноти знову відкрила дві більші дискусії щодо інтеграцій. Холодне DM до Randy Bechtold виявило Robinhood Chain як потенційну ціль — а швидкий погляд показав, що він побудований на Arbitrum, мережі, яку THORChain уже намагався опрацювати. Це створило можливість «два за ціною одного»: у Bechtold запланований дзвінок із командою Arbitrum, і він планує попросити теплу інтродукцію до Robinhood під час цього.

Aaluxx додав технічну нотатку обережності щодо Arbitrum: він працює приблизно з чотирма блоками за секунду, що затоплює ноди обсягом повідомлень подібно до Solana. Maya провела близько року, стабілізуючи підтримку Arbitrum. Плюс у тому, що складну «важку роботу» здебільшого вже виконано на стороні Maya, тож для THORChain шлях коротший.

Інтеграція Monero просувається до етапу аудиту з принципом мінімальних привілеїв

Інтеграція XMR — це найближча до релізу велика функція. Aaluxx веде перемовини з Least Authority щодо security audit — компанії, яку він оцінює як одну з топових для роботи з privacy-ланцюгами. Є прямий прецедент: Zcash профінансував аудит Least Authority для своєї інтеграції ZEC-into-Maya, який нещодавно завершився лише незначними знахідками щодо denial-of-service і якості життя (QoL), без серйозних багів. Робота над Monero вже пройшла chain-net тестування і перевірку розробником.

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

«Ламай речі, але ламай маленькими шматочками», — сказав Aaluxx.

ZEC на стороні THORChain не має таймлайну. Вузьке місце — пропускна здатність: рефанди, робота з безпекою, перезапуск мережі та запуск Monero змагаються за те саме вузьке «вікно» рецензування й розгортання, а churning приходить першим.

Moca запускає бета-версію crypto point-of-sale через Maya і THORChain

Платіжний напрямок екосистеми отримав власне оновлення. Moca — crypto point-of-sale і платіжна мережа — проводить розрахунки за транзакціями через Maya Protocol, THORChain та кілька інших бекендів. Мета — дати звичайним мерчантам приймати криптовалюту й проводити розрахунки в криптовалюті без тертя — щоб реальні обсяги в потоці повернулися через протоколи.

Бета навмисно тихенька: запуск у понеділок після наступного, без маркетингового поштовху на старті. План: відкрити акаунти для бізнесу, зібрати фідбек, провести реальні тестові платежі й виправити баги перед ширшим розгортанням.

«Платіжна сторона Maya вже тут», — заявив EricOnchain, Moca.

Будівничі, зацікавлені в ранньому доступі до API, можуть напряму звернутися до EricOnchain або до акаунту Moca.

FAQ

Чому ротація сховищ THORChain зараз призупинена?
Проблема консенсусу, яка прямо пов’язана з процесом churning, потребує виправлень на рівні Thornode. Ці зміни надто глибокі для точкового релізу, тому ротація сховищ залишається призупиненою, доки повне оновлення v3.20 не буде розгорнуте.

Що стало причиною нещодавнього експлойту THORChain?
Три старіші баги, кожен з яких окремо був безпечним, стали експлуатованими, коли їх спровокували послідовно. Комбінація дозволила скомпрометувати одне зі п’яти сховищ THORChain, що призвело до вилиття приблизно 20% TVL.

Як Maya Protocol підтримувала свопи під час простою THORChain?
Maya працювала з одним сховищем, яке команда могла незалежно верифікувати як безпечне. Зберігаючи його в роботі — паралельно з паузою churning як запобіжним заходом — Maya продовжувала обробляти свопи протягом усього місяця простою THORChain.

Застереження: інформація на цій сторінці може походити зі сторонніх джерел і надається виключно для ознайомлення. Вона не відображає позицію чи думку Gate і не є фінансовою, інвестиційною чи юридичною консультацією. Торгівля віртуальними активами пов’язана з високим ризиком. Будь ласка, не покладайтеся лише на інформацію з цієї сторінки під час прийняття рішень. Детальніше дивіться у Застереженні.
Прокоментувати
0/400
Немає коментарів