Как 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, описываются как адреса класса B. Они относятся к обсуждению блокировки, тогда как изменения состояния в черновике ограничены адресами класса 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. Это более узкое утверждение, чем заявление о том, что средства стали невозможными для перемещения по любому мыслимому пути транзакции. Авторы сообщают, что средства были остановлены и что они не обнаружили обходного пути. Они указывают на ограничения подхода как часть своей аргументации в пользу более долговременного изменения.

Авторы описывают ожидающую транзакцию с необычно высокой предложенной комиссией и попытки заручиться помощью валидаторов. Попытка транзакции является свидетельством усилий по изменению статуса баланса. Она имеет иной доказательственный вес, чем исполненный перевод. В предложении также описывается неотвеченный ончейн-канал восстановления. Договорный возврат зависел бы от ответа стороны, способной авторизовать платёж, тогда как предложение о форке сработало бы через участников, принимающих новые правила.

Бессрочный список имеет практические последствия для людей, которые его администрируют. Им нужно было бы знать, какие записи всё ещё служат цели, как новые операторы получают правильную конфигурацию и кто отвечает за проверку старых записей. Предложение на форуме предусматривает проверку после восстановления, включая отдельную обработку дополнительных адресов. Это означает, что предложение касается как единовременного изменения баланса, так и того, что происходит с временными мерами контроля вокруг него.

Что меняется на блоке форка

Обычно перевод изменяет балансы счетов после того, как действительная транзакция принята по правилам сети. Вместо этого предложение требует, чтобы программное обеспечение, следующее обновлённым правилам, применило указанные списания и зачисления в рамках обработки определённого блока.

Соответствующие зачисления имеют значение. Описанная операция берёт такое же количество нативных токенов с указанных адресов, сколько даёт designated адресам восстановления. Область действия не распространяется на произвольные токены в кошельках.

Блок, который зафиксирует восстановление

Предлагаемое изменение состояния упорядочено вокруг блока активации, который в черновике называется F. Соответствующая сумма — это баланс после F минус один. Обновлённые узлы применили бы предписанные корректировки баланса перед обычными транзакциями в F. Эта последовательность важна, поскольку она определяет точную границу, которую проверяющий использовал бы для проверки результата.

Обычный перевод обычно даёт обозревателю запись транзакции для отображения. Изменение, применённое напрямую по правилам сети, может вместо этого быть видимым при сравнении балансов соседних блоков. Тот, кто смотрит только на список обычных переводов получателя, может его пропустить. Предлагаемая публикация скрипта проверки помогла бы связать состояние до и после со списком предполагаемых получателей.

Проверка должна охватывать обе стороны реестра. Она будет искать соответствующее списание и зачисление для каждого баланса. Если адрес восстановления также получил обычные транзакции в том же блоке, необработанная разница между двумя снимками состояния могла бы включать эти движения. Тогда проверяющему потребовалось бы отделить их от специального изменения состояния, а не рассматривать каждое приращение как восстановленные средства.

Блок активации — это координационный срок. Оператор, запускающий программное обеспечение, которое вычисляет старое состояние, и оператор, применяющий специальное правило баланса, могли бы вычислить разные результаты из одного и того же блока. Поэтому практическая работа включает публикацию изменения, предоставление операторам времени на его проверку и чёткое указание точки активации. Таблица предложения по-прежнему помечает блок как решение, которое должно быть принято после утверждения. Обсуждение в рамках управления — это возможность урегулировать этот план, тогда как состояние сети установило бы исполнение.

Кто обеспечивает вступление изменения в силу

Предложение на форуме описывает запрашиваемое изменение. Отдельной вехой стал бы выпуск, который его реализует и определяет блок активации. Затем операторам пришлось бы принять совместимое программное обеспечение, чтобы изменение вступило в силу в используемой ими сети.

Поэтому пользователь, следящий за предложением, должен различать сообщение на форуме, реализацию и блок, который фактически отражает новые балансы. Каждый из них отвечает на different вопрос о восстановлении.

Работа, стоящая за выбором блока активации

Номер блока может выглядеть как административная деталь. На практике именно в нём новое программное обеспечение и старое программное обеспечение начинают расходиться в отношении балансов затронутых счетов. Его выбор даёт операторам общий срок для установки обновления, а обозревателям, поставщикам инфраструктуры и затронутым фирмам — общую точку для проверки результата.

Подготовка, предложенная в сообщении на форуме, включает подтверждение адресов назначения, сохранение блокирующих механизмов до активации и публикацию свежего снимка балансов. Эти шаги касаются разных способов, которыми восстановление может пойти не так. Неправильно записанный адрес мог бы отправить активы куда-то не туда. Необъяснимое изменение баланса могло бы оставить читателей сравнивать результат с устаревшей цифрой. Задержанное обновление могло бы оставить оператора вычислять состояние по старым правилам.

Каждый из этих вопросов требует отдельной проверки. Для адреса назначения важным доказательством является то, как получатель демонстрирует контроль и как проверяется опубликованный адрес. Для суммы это баланс в конечной контрольной точке. Для сети это то, какие версии программного обеспечения фактически обрабатывают блоки после точки активации. Заявление о том, что операторы поддерживают восстановление, само по себе не ответило бы ни на один из этих вопросов реализации.

Есть также полезная проверка после события. Изменение состояния напрямую затронуло бы нативные балансы, тогда как обычный платёж, совершённый в том же блоке, мог бы затронуть того же получателя. Поэтому разницу балансов необходимо сверить с обычными транзакциями в этом блоке. Именно здесь был бы полезен скрипт проверки, предложенный авторами, особенно если он определяет как списание, так и соответствующее зачисление для каждого счёта.

Где клиенты входят в процесс

Получателем предлагаемого перевода является адрес восстановления, а не список клиентских счетов. Как только оператор контролирует средства, следующий вопрос — как его собственный процесс восстановления и возмещения их учитывает.

Соответствующие доказательства включали бы график подачи требований, инструкции по доказательству убытка и политику в отношении даты оценки. Платформа могла бы уже возместить некоторым пользователям средства из других фондов. Её бухгалтерский учёт должен был бы установить, куда в таких случаях направляется восстановленный POL.

Что считается возвратом клиентам

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

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

Различие между клиентскими балансами и потерями платформы особенно важно, когда отдельные инциденты объединяются в одном предложении. Справочная таблица распределяет балансы Polygon по инцидентам. Она не содержит объединённого пула требований или расчёта сумм, причитающихся отдельным пользователям. Даже если оба набора балансов изменятся в одном и том же блоке активации, платформы могут столкнуться с разными обязательствами и могут объявить о разных схемах выплат.

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

Кто может решить, сколько стоит восстановленный токен?

Предположим для иллюстрации, что платформа должна пользователю денежную стоимость баланса и получает POL после изменения цены. Существует как минимум три даты, на которые платформа могла бы ссылаться: момент кражи, момент получения восстановленных токенов и момент осуществления распределения. Денежная сумма, представленная одним и тем же количеством POL, может различаться в каждой из этих точек.

Политика требований могла бы вместо этого предусматривать выплату в единицах утраченного актива. Это позволяет избежать выбора рыночной цены для требования, выраженного в том же активе, но всё же оставляет вопросы о праве на получение и предыдущих возмещениях. Клиент, которому уже возместили ущерб, мог бы находиться в ином положении, чем тот, чьё требование остаётся неудовлетворённым. Сеть не играет никакой роли в принятии этих решений.

Клиенту необходимо заявление о том, что должна платформа, в каких единицах и как она учитывает всё, что было выплачено ранее. Цепь может установить, что адрес восстановления получил баланс, а платформа может сверить это со своими записями. Ни один документ не выполняет работу другого. Это одна из причин, по которой подтверждённое восстановление может быть новостью, даже если всё ещё существует отдельное ожидание подробностей распределения.

Сравнение отчётности может расположить цифры рядом. Первой была бы сумма нативного POL, восстановленного в результате изменения состояния. Второй была бы сумма, отнесённая к клиентским требованиям или к уже произведённым возмещениям. Третьей был бы любой баланс, остающийся на хранении, пока платформа урегулирует отдельные случаи. Единственная цифра в долларах, взятая из первого этапа, мало что сказала бы читателям о двух других.

Почему узкая сфера применения важна

Форк, изменяющий балансы, поднимает вопрос, которого не поднимает обычное обновление программного обеспечения. Какие факты должны были бы присутствовать, чтобы участники снова поддержали это вмешательство?

Само предложение описывает действие как экстремальное и ограничивает его перечисленными балансами нативного POL. Обоснование предложения и вопрос о прецеденте можно оценивать на основе одних и тех же конкретных деталей: идентифицированных адресов, предлагаемого места назначения и блока, в котором изменятся балансы.

Что сделало бы этот случай прецедентом?

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

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

Наиболее безопасное сравнение — между фактами, которые мог бы продемонстрировать другой запрос. Может ли он определить сумму на конкретном блоке? Может ли он связать эти средства с признанным инцидентом? Может ли он проверить получателя и указать, что происходит с уже заблокированными адресами? Эти вопросы напрямую следуют из опубликованного черновика и более полезны, чем описание каждого необычного изменения состояния как эквивалентного.

Предложение оставило бы некоторые из этих вопросов проверяемыми публично. Высота активации позволила бы наблюдателям определить точный переход состояния. Именованные адресаты позволили бы им проследить, что произошло после него. Авторы также предлагают пересмотреть записи в списке временной блокировки после активации, включая иной подход к дополнительным адресам, связанным с Binance. Этот окончательный пересмотр помог бы установить, какие чрезвычайные ограничения остаются в силе после завершения восстановления.

Что мог бы подтвердить реестр

Если предложение будет реализовано, первая проверка сравнила бы балансы указанных адресов по обе стороны от блока форка. Совпадающие зачисления показали бы, что реестр применил перевод в соответствии с указаниями. Для распределений клиентам потребовались бы доказательства от операторов восстановления.

Текущее предложение указывает пять адресов-источников и назначенные адреса восстановления для двух инцидентов.

Какие записи отвечают на какой вопрос восстановления

Инцидент может проходить через эти этапы с разной скоростью. Заморозка USDT, например, касается иного актива и иного механизма, чем предлагаемый форк POL. Последующее объявление о защищённых или возвращённых средствах должно было бы уточнить, какой актив учитывался и что с ним произошло.

Балансы также могут меняться между датами, использованными в отчётности. Предложение, которое приводит более ранний снимок, должно сохранять номер блока, чтобы читатели могли воспроизвести сумму, даже если текущий баланс изменится. Когда результат станет известен, сравнение блока исполнения с опубликованным снимком установило бы, отличается ли возвращённая сумма от суммы, обсуждавшейся в предложении.

Наиболее важная сверка для читателей — между списанной и зачисленной суммой. Публикация этой проверки отдельно для двух инцидентов позволила бы сравнить последующий отчёт каждой платформы о поступлениях с суммой, над которой она фактически получила контроль. Единый совокупный итог затруднил бы отслеживание того, какие поступления были доступны для удовлетворения каких требований.

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

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

Записи адресов также могут служить проверкой заявлений, сделанных после обновления. Если оператор утверждает, что средства были отправлены на опубликованный адрес назначения, цепочка должна показать соответствующее изменение баланса на высоте активации. Если утверждается, что клиентам возместили средства, более полезным доказательством является запись о распределении или четкий отчет о возмещениях. Одно — это заявление о сети, другое — об обязательствах платформы.

Именно поэтому доказательства из реестра особенно ценны, когда общественное обсуждение переходит к вопросу о том, сработал ли форк. Это дает наблюдателям узкий вопрос, который они могут проверить, не дожидаясь, пока каждая затронутая фирма завершит свой собственный учет. Предложение устанавливает процедуру публикации балансов, использованных при изменении состояния, и проверки зачислений получателям после него. Эти записи также дадут пользователям отправную точку для отслеживания того, что сделала каждая платформа, получив контроль над деньгами.

На что обратить внимание

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

Часто задаваемые вопросы