Співзасновник Rootstock Серхіо Лернер закликав Bitcoin-мости запровадити обов'язкові затримки виведення після того, як близько 4 000 BTC залишили федеративний гаманець Liquid Network через несанкціонований peg-out.
Резюме
- Блокування з часовою затримкою могло б дати операторам мосту кілька годин, щоб виявити та зупинити несанкціоноване виведення.
- PowHSM Rootstock чекають 4 000 блоків, або близько 36 годин, перш ніж підписати peg-out.
- Лернер сказав, що скомпрометовані функціонери Rootstock могли б зупинити peg, але не могли б змусити дострокове виведення.
- Чернетка пропозиції Bitcoin BIP-443 могла б підтримати конструкції сховищ, які розміщують контроль виведення в правилах консенсусу.
Серхіо Лернер, головний науковий співробітник і співзасновник RootstockLabs, сказав crypto.news, що негайний розрахунок може перетворити одну помилку валідації на втрату, перш ніж оператори мосту встигнуть відреагувати.
«Без блокування з часовою затримкою одна помилка валідації та повна втрата стають однією й тією ж подією, тому що кошти рухаються в ту мить, коли програмне забезпечення каже "так"», — сказав Лернер.
Його коментарі прозвучали після інциденту, в якому дійові особи створили незабезпечені L-BTC і використали послугу peg-out SideSwap, щоб вивести майже 4 000 BTC з гаманця Liquid Federation. Liquid описала цих дійових осіб як імовірних хакерів-«білих капелюхів», тоді як SideSwap заявила, що її послуга обробила запит, оскільки L-BTC виглядали дійсними.
Пізніше дійові особи повернули 3 400 BTC після того, як Blockstream підтвердила, що уражені вузли мосту були виправлені. Близько 598 BTC залишилися неповернутими, тоді як Liquid відновила виробництво блоків без відновлення транзакцій або операцій peg станом на 10 вересня.
Блокування з часовою затримкою могло б створити вікно для втручання
Лернер сказав, що обов'язкова затримка між створенням незабезпечених L-BTC і випуском справжніх BTC могла б зменшити шкоду.
За такої системи схвалення програмним забезпеченням запускало б період очікування, а не завершувало виведення. Автоматизовані інструменти моніторингу могли б порівняти запитаний peg-out із BTC, що забезпечують L-BTC, і позначити будь-який дисбаланс до розрахунку.
«Якби Liquid мала блокування з часовою затримкою — де кошти не можуть рухатися протягом визначеного періоду, незалежно від того, що каже програмне забезпечення чи оператори — помилка призвела б до керованого інциденту, а не до негайної, повномасштабної катастрофи».
За словами Лернера, затримка дала б операторам багатогодинне вікно для реагування після створення незабезпечених токенів. Системи моніторингу, що працюють цілодобово, могли б виявити, що peg-out пройшов перші перевірки програмного забезпечення, незважаючи на відсутність відповідного забезпечення.
Потім функціонери могли б призупинити peg, перш ніж апаратне забезпечення підписало транзакцію або випустило BTC з федеративного гаманця, додав він.
Система Liquid не повідомила про викрадений ключ авторизації Peg-out. SideSwap заявила, що клієнт надіслав 4 000 L-BTC до її послуги peg-out, яка обробила запит за своїм звичайним процесом, оскільки токени неможливо було відрізнити від забезпечених L-BTC. Федерація виплатила 3 996 BTC на надану Bitcoin-адресу приблизно через 23 хвилини.
Пропозиція Лернера розмістила б додатковий контроль після першого етапу валідації. Навіть якщо програмне забезпечення помилково схвалило виведення, затримка запобігла б негайному виходу відповідних BTC.
Rootstock забезпечує затримку виведення Bitcoin у 4 000 блоків
Rootstock вже використовує механізм затримки для виведення BTC через свій двосторонній peg, хоча правила консенсусу Bitcoin не забезпечують період очікування.
Система покладається на спеціалізовані апаратні модулі безпеки під назвою PowHSM. Перш ніж підписати peg-out, пристрої незалежно перевіряють, що минуло 4 000 блоків Rootstock, що становить близько 36 годин сукупного proof-of-work.
Згідно з Лернером, приватні ключі залишаються всередині пристроїв, і функціонери не можуть наказати апаратному забезпеченню обійти необхідний період. Rootstock поєднує правила HSM із merge-mining, за допомогою якого Bitcoin-майнери вносять proof-of-work у сайдчейн.
«Навіть змова більшості pegnatories не може вкрасти кошти, тому що приватні ключі ніколи не залишають PowHSM, а HSM незалежно перевіряють, що минуло 4 000 блоків Rootstock, перш ніж вони підпишуть», — сказав Лернер.
Модель Rootstock припускає, що більшість хешрейту Bitcoin, який бере участь через merge-mining, і функціонери федерації не діятимуть разом, щоб зупинити мережу. Лернер сказав, що скомпрометовані функціонери могли б перервати операції прив’язки, створивши проблему живучості, але правила HSM завадили б їм змусити до несанкціонованого дострокового виведення.
Коли інструменти моніторингу виявляють підозрілу активність, функціонери можуть вимкнути свої HSM, щоб очікуване виведення з прив’язки не отримало підпису. Лернер описав цю паузу як спосіб захистити базовий BTC, поки оператори вивчають проблему та вирішують, як діяти далі.
«Змова більшості може, у гіршому випадку, зупинити прив’язку, але вони не можуть змусити до несанкціонованого виведення», — сказав він.
Розподілені засоби контролю відкликання могли б обмежити повноваження щодо заморожування
Зупинка очікуваного виведення створює ще один ризик, оскільки ту саму владу можна було б використати для затримки законних користувачів. Лернер сказав, що жодна окрема компанія, оператор чи адміністратор не повинні контролювати механізм відкликання.
Замість цього незалежні функціонери повинні розділяти повноваження через багатосторонню структуру, а апаратні правила обмежуватимуть те, що вони можуть робити. За його запропонованою моделлю функціонери могли б призупинити обробку, але не могли б перенаправити BTC на іншу адресу або конфіскувати його.
«Щоб запобігти єдиним точкам відмови або централізованій цензурі, засоби контролю відкликання повинні бути розподілені між незалежними багатосторонніми функціонерами з використанням правил, що забезпечуються апаратним забезпеченням, а не централізованих адміністративних ключів».
Такі засоби контролю все ще дозволяли б групі функціонерів переривати виведення, якби достатньо учасників діяли разом. Розмежування Лернера ґрунтується на обсязі цих повноважень: оператори могли б тимчасово утримувати підписи, поки аномалію переглядають, але вони не могли б створити дійсну транзакцію, яка переказує заставу їм самим.
Часові затримки також повинні враховувати вартість і призначення кожної транзакції. 36-годинне очікування може бути непридатним для рутинних платежів, тоді як міст, що утримує великі обсяги BTC, має інший профіль ризику.
Лернер сказав, що системи розрахунків високої вартості повинні розглядати час як засіб безпеки, подібно до механізмів затримки, які використовуються у фізичних банківських сховищах. Періоди виведення могли б відрізнятися залежно від розміру транзакції або вимагати різних сукупних порогів доказу виконаної роботи відповідно до застави, що перебуває під ризиком.
Коротший період міг би застосовуватися до менших переказів, тоді як довша затримка могла б дати автоматизованим системам і людям-реагувальникам більше часу для перевірки незвично великого запиту. Лернер не приписував одну затримку для кожного моста, але навів вимогу Rootstock у 4000 блоків як ефективний період для інфраструктури, що захищає великі баланси BTC.
Нативні сховища Bitcoin могли б розмістити запобіжні заходи в консенсусі
Поточний захист Rootstock залежить від його HSM і федерації, а не від правил, що забезпечуються мережею Bitcoin. Лернер сказав, що нативні сховища Bitcoin і ключі відкликання могли б перенести порівнянні засоби контролю в базовий протокол.
Одним із можливих будівельних блоків є BIP-443, чернетка пропозиції щодо опкоду під назвою OP_CHECKCONTRACTVERIFY, або OP_CCV. Пропозиція дозволила б виходу Bitcoin нести дані та обмежувати, як його кошти можуть переміщатися через майбутні транзакції.
BIP-443 описує OP_CCV як консенсусну зміну, що вимагає soft fork. До перелічених варіантів використання належать виходи Bitcoin, що несуть стан, сайдчейни та двоетапні структури виведення, які дозволяють реактивну безпеку. Пропозиція залишається в статусі чернетки, і її процес активації не визначено.
Лернер навів OP_CCV і BIP-443 як приклади того, як нативні сховища могли б дати користувачам або визначеним сторонам час скасувати виведення після виявлення викрадених облікових даних, зміненого програмного забезпечення або іншої аномальної події.
Перенесення механізму в консенсус Bitcoin зменшило б залежність від специфічних для моста політик HSM, за словами Лернера. Майнери, функціонери або адміністратори повинні були б дотримуватися умов витрачання, прикріплених до виходу Bitcoin, а не застосовувати дискреційну паузу після того, як кошти вже переміщено.
Для великих виведень через міст Лернер сказав, що затримка повинна тривати достатньо довго, щоб автоматизовані сповіщення та люди-оператори могли виявити проблему, зупинити обробку та перевірити уражене програмне забезпечення, перш ніж BTC стане остаточно витратним для одержувача.
