Як Polygon планує повернути 70 мільйонів викрадених POL на гаманці відновлення

Дві крадіжки залишили мільйони POL на п'яти заблокованих адресах. Пропозиція Polygon перемістила б ці баланси до відновлювальних гаманців шляхом зміни правил мережі на конкретному блоці. Отримання токенів туди вирішило б одну частину відновлення. Повернення їх клієнтам — це окрема робота.

Пропозиція щодо покращення Polygon визначила 70,49 мільйона POL на п'яти заблокованих адресах, які скоординований хардфорк міг би перемістити до відновлювальних гаманців, призначених для Binance та Polymarket.

Пропозиція описує зміну балансів рідних POL на фіксованому блоці. Програмне забезпечення обнулило б п'ять перелічених балансів і зарахувало б відповідні суми на перевірені відновлювальні адреси.

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

Як складаються два інциденти

Пропозиція відносить 46,63 мільйона POL на одній адресі до інциденту з Binance, а 23,86 мільйона на чотирьох адресах — до інциденту з Polymarket. Додавання цих округлених цифр дає 70,49 мільйона POL. Поділивши кожну на цю суму, частка Binance становить близько 66,2%, а Polymarket — 33,8%.

Це частки запропонованого відновлення, а не показники загальних втрат двох інцидентів. Оцінка в доларах також залежить від використаної позначки часу та ціни. Кількості в пропозиції номіновані в POL.

Адреси важливіші за заголовну суму в доларах

Довідкові баланси в пропозиції становлять загалом 70 489 329,34 POL. Адреса Binance становить 46 626 593,27 POL, тоді як чотири адреси Polymarket становлять 23 862 736,07 POL. Це баланси на довідкових блоках, обраних авторами. Попередній переказ з гарячого гаманця Binance був трохи меншим за баланс, згодом зафіксований на адресі одержувача.

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

Показник Polymarket становить окрему проблему вимірювання. У пропозиції інцидент оцінюється приблизно в 28 мільйонів POL, а чотири вибрані баланси — приблизно в 23,86 мільйона POL. Відносно цієї округленої оцінки інциденту вибрана сума становить приблизно 85%, залишаючи різницю приблизно в 4,14 мільйона POL. Це віднімання вимірює розрив між оцінкою інциденту та вибраними балансами. Воно не може встановити, де опинилися решта токенів або чи деякі з них можна було б повернути іншим шляхом.

Перерахунок у долари додає ще одну змінну. За ціною $0,092 за POL еталонний баланс коштував би близько $6,49 мільйона. За ціною $0,096 ті самі токени коштували б близько $6,77 мільйона. Розрахунок множить еталонну кількість із пропозиції на дві ілюстративні ціни. Він пояснює, як доларові цифри близько $6,5 мільйона та $6,8 мільйона могли б описувати майже той самий запропонований переказ. Початкове висвітлення оцінювало вартість приблизно в $6,5 мільйона. Рішення про виплату потребувало б чіткої дати оцінки та джерела ціни.

Що залишила б запропонована вилка

Запропоноване відшкодування охоплює близько 85% з приблизно 28 мільйонів POL, приписуваних інциденту Polymarket у дописі на форумі. Спокусливо описати решту 15% як суму, яку вилка не змогла б відшкодувати. Точніше порівняння — між приблизною цифрою інциденту та балансами, які, за словами авторів, досі зберігаються на чотирьох адресах. Для пояснення різниці знадобилося б окреме трасування.

Порівняння з Binance інше. У пропозиції вказано один переказ 46 626 589,6 POL з гарячого гаманця та баланс 46 626 593,27 POL на адресі одержувача на момент зняття еталонного знімка. Баланс призначення був приблизно на 3,67 POL більшим за цей переказ. Різниця достатньо мала, щоб зникнути в будь-якому округленому заголовку, але вона допомагає пояснити, чому знімок, зроблений на вказаному блоці, корисніший, ніж цитування суми з оригінальної транзакції.

Другий урок полягає в одиницях. Еталонна таблиця використовує нативний POL, тоді як попередній переказ Binance також включав 6 185 900,1 USDT. Доларовий підсумок, що включає обидва, охоплював би інший набір активів, ніж запропонована вилка. Звіт про заблоковані кошти цілком міг би обговорювати обидва, за умови чіткого зазначення, яка організація вжила кожну дію і чи згодом кошти переміщувалися.

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

Що може розповісти заблокований баланс

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

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

Що може встановити запис про перекази

У пропозиції описано два нативні перекази о 18:30:34 та 18:35:59 UTC 29 жовтня. Разом вони перемістили 3 282 275,71 POL з однієї адреси на іншу. Два часові позначки важливі, оскільки допомагають встановити послідовність, у якій баланси розподілялися між гаманцями. Історія транзакцій може показати рух і суми, навіть коли людей, які контролюють ключі, важче ідентифікувати.

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

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

У пропозиції додаткові адреси, надані Binance, описано як Class B. Вони належать до дискусії про блокування, тоді як зміни стану в чернетці обмежуються адресами Class A, визначеними для відновлення. Якщо вважати кожну заблоковану адресу гаманцем, який буде спорожнено, це завищило б масштаб. Це також затьмарило б важливе питання управління: блокування транзакції — це одна дія, тоді як рішення про те, що конкретний баланс має перейти до названого одержувача, — це інша.

Чому два активи вимагали різних відповідей

Хронологія пропозиції Polygon простежує 46 626 589,6 нативних POL і 6 185 900,1 USDT від гарячого гаманця Binance до того самого одержувача в блоці 96 406 484. Tether заморозив USDT. POL залишався предметом запропонованого втручання мережі.

Запропонований переказ стосується різних механізмів контролю, доступних для цих двох активів. Емітент може накладати обмеження через систему, яку він керує для свого токена. У цьому випадку виробники блоків Polygon натомість використали фільтр транзакцій Bor для нативних POL, і пропозиція описує цей фільтр як тимчасовий захід.

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

Чому фільтр транзакцій може діяти днями й усе одно залишатися тимчасовим

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

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

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

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

Що змінюється на блоці форку

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

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

Блок, який зафіксує відновлення

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

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

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

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

Хто забезпечує набуття чинності зміни

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

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

Робота, що стоїть за вибором блоку активації

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

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

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

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

Де клієнти входять у процес

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

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

Що вважається поверненням клієнтам

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

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

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

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

Хто може визначити, скільки коштує відновлений токен?

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

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

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

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

Чому вузька сфера застосування має значення

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

Сама пропозиція описує дію як екстремальну та обмежує її переліченими нативними балансами POL. Аргументи на користь пропозиції та питання прецеденту можна оцінювати за одними й тими самими конкретними деталями: ідентифіковані адреси, запропоноване призначення та блок, у якому змінилися б баланси.

Що зробило б цей випадок прецедентом?

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

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

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

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

Що міг би підтвердити реєстр

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

Поточна пропозиція визначає п'ять адрес-джерел і призначені адреси відновлення для двох інцидентів.

Які записи відповідають на яке питання відновлення

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

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

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

Вузьке відновлення також дає платформам спосіб повідомити, що сталося з активами поза межами розгалуження. Показник Polymarket у дописі на форумі включає більше POL, ніж зазначено в запропонованій зміні стану. Переказ Binance включав USDT, з яким Tether працював окремо. Оновлення про відновлення, яке визначає відповідний актив, адресу та вжиті заходи, дозволило б читачам звірити обидва інциденти, не припускаючи, що всі викрадені кошти пішли одним шляхом.

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

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

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

На що звернути увагу

• Пропозиція щодо випуску: обсяги, специфічні для інциденту, запропоновані адреси одержувачів та виконувані інструкції, подані на розгляд управління.
• Блок активації: підтверджена висота блоку та випуск програмного забезпечення, який операторам Polygon потрібно буде встановити до нього.
• Кредити відновлення: нативний POL, списаний з кожної заблокованої адреси, та відповідний кредит, зафіксований на призначеній для нього адресі одержувача.
• Претензії клієнтів: інструкції кожної платформи щодо права на отримання, оцінки та того, як вона враховуватиме попередні відшкодування.

Поширені запитання