#GIWA #跨链安全 Самое простое, что может ввести в заблуждение один лишь числовой аргумент — это история вокруг DYORSWAP: компания заявляет, что уже компенсировала более 200 ETH, и у людей возникает вопрос — неужели потери почти уже «закрыты»? Я считаю, что сейчас важнее не посчитать красивый процент компенсации, а разобраться, какие активы относятся к какой группе пострадавших, и действительно ли каждая выплата дошла до адресата.
Хронология как раз и объясняет, почему эти вопросы нельзя смешивать. В новом раскрытии проекта говорится: сеть и мост, использующие подменённый GIWA Chain ID 9134, были развернуты 27 сентября в 02:10 по пекинскому времени. Эта сеть работала — она могла записывать пакетные транзакции в Ethereum, и пользователи могли там проводить операции. Это не просто «всплывающая» фальш-страница. Около 1 335 адресов завели на мост примерно 767,65 ETH; проект утверждает, что около 766,25 ETH позже были выведены. Эти цифры — суммарный объём по методике моста, и они не равны «чистым» потерям, подтверждённым пострадавшими в разрезе по адресам.
Ранее информация ограничивалась обещанием «мы компенсируем» и правилами: затронутые адреса с суммами ниже 5 ETH обрабатываются по ставке 40% от суммы моста, а для более крупных сумм требуется отдельная верификация. Сегодняшний длинный текст делает следующий шаг: DYORSWAP заявляет о распределении свыше 200 ETH среди пользователей и даёт точку входа, по которой можно проверить выплаты on-chain. Но «проект заявляет, что распределил» и «фактическая недостача каждого пострадавшего подтверждена» — это всё ещё разные вещи; и деление 200 на 766,25 не даёт автоматически «общий коэффициент компенсации» — числитель и знаменатель могут относиться к разным объектам и различаться по методике расчёта.
Самое важное — ещё и то, что команда утверждает: с помощью поддельной цепочки, ранее опубликованные в Ethereum пакетные транзакции, были использованы для воссоздания состояния моста, торговли и фондов; при этом транзакции за примерно две минуты до остановки не были записаны on-chain, из-за чего осталась «дыра» в данных. Мой вывод таков: ключевой момент на следующем этапе этого события — не повторять, насколько правдоподобным был поддельный чейн, а сможет ли верификация выплат быть выполнена извне по каждой операции: совокупность пострадавших адресов, основания исключения, результаты по обращениям на крупные суммы и сами транзакции поступления — смогут ли они сложиться в единую, пригодную к проверке бухгалтерию.
Есть и границы. Все цифры, которые пока приводит проект — 1335, 767,65, 766,25 и «компенсировано более 200 ETH» — следует прежде всего считать их раскрытыми методиками. Поведение кошельков может дать подсказки, но нельзя лишь по одному раннему депозиту или по крупному переводу через мост автоматически решать, что адрес — атакующий. Если дальнейшие публичные транзакции по каждому кейсу смогут соответствовать полному списку пострадавших, я повышу оценку прогресса исполнения; если же со временем так и не удастся свести списки, даже увеличение общей суммы компенсации будет трудно доказать как справедливое завершение.
Если вы — пользователь, который пострадал, вы считаете, что важнее сначала раскрыть обезличенную расчётную методику по каждому адресу, или сначала ускорить фактические выплаты? Особенно в условиях, когда данных не хватает за последние две минуты — какой стандарт подтверждений вы сочтёте приемлемым?
Хронология как раз и объясняет, почему эти вопросы нельзя смешивать. В новом раскрытии проекта говорится: сеть и мост, использующие подменённый GIWA Chain ID 9134, были развернуты 27 сентября в 02:10 по пекинскому времени. Эта сеть работала — она могла записывать пакетные транзакции в Ethereum, и пользователи могли там проводить операции. Это не просто «всплывающая» фальш-страница. Около 1 335 адресов завели на мост примерно 767,65 ETH; проект утверждает, что около 766,25 ETH позже были выведены. Эти цифры — суммарный объём по методике моста, и они не равны «чистым» потерям, подтверждённым пострадавшими в разрезе по адресам.
Ранее информация ограничивалась обещанием «мы компенсируем» и правилами: затронутые адреса с суммами ниже 5 ETH обрабатываются по ставке 40% от суммы моста, а для более крупных сумм требуется отдельная верификация. Сегодняшний длинный текст делает следующий шаг: DYORSWAP заявляет о распределении свыше 200 ETH среди пользователей и даёт точку входа, по которой можно проверить выплаты on-chain. Но «проект заявляет, что распределил» и «фактическая недостача каждого пострадавшего подтверждена» — это всё ещё разные вещи; и деление 200 на 766,25 не даёт автоматически «общий коэффициент компенсации» — числитель и знаменатель могут относиться к разным объектам и различаться по методике расчёта.
Самое важное — ещё и то, что команда утверждает: с помощью поддельной цепочки, ранее опубликованные в Ethereum пакетные транзакции, были использованы для воссоздания состояния моста, торговли и фондов; при этом транзакции за примерно две минуты до остановки не были записаны on-chain, из-за чего осталась «дыра» в данных. Мой вывод таков: ключевой момент на следующем этапе этого события — не повторять, насколько правдоподобным был поддельный чейн, а сможет ли верификация выплат быть выполнена извне по каждой операции: совокупность пострадавших адресов, основания исключения, результаты по обращениям на крупные суммы и сами транзакции поступления — смогут ли они сложиться в единую, пригодную к проверке бухгалтерию.
Есть и границы. Все цифры, которые пока приводит проект — 1335, 767,65, 766,25 и «компенсировано более 200 ETH» — следует прежде всего считать их раскрытыми методиками. Поведение кошельков может дать подсказки, но нельзя лишь по одному раннему депозиту или по крупному переводу через мост автоматически решать, что адрес — атакующий. Если дальнейшие публичные транзакции по каждому кейсу смогут соответствовать полному списку пострадавших, я повышу оценку прогресса исполнения; если же со временем так и не удастся свести списки, даже увеличение общей суммы компенсации будет трудно доказать как справедливое завершение.
Если вы — пользователь, который пострадал, вы считаете, что важнее сначала раскрыть обезличенную расчётную методику по каждому адресу, или сначала ускорить фактические выплаты? Особенно в условиях, когда данных не хватает за последние две минуты — какой стандарт подтверждений вы сочтёте приемлемым?
