Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 81
Удивительно, не так ли? Вау. Вот это неожиданность
Опять LLM изнасиловал журналиста...
Основатель компании SlowMist назвал ошибку "очень простой" — по сути, пропущенное умножение, которое должен был поймать обычный аудит.
Где они видели чтобв аудит тесты заменял
Посмотрел код: в целом тут сложно написать тест на такой случай на foundry, а они его используют. Потребовалось бы написать тест на майннет-форке, который проводил бы обновление ценового оракула, после чего дожидался вступления изменений в силу, обновил значения ценовых оракулов и проводил был ликвидацию необеспеченных позиций (то есть нужно было бы написать полноценного ликвидатора на Solidity с итерацией по существующим позициям, которых неопределённо много, и их список постоянно меняется). Сходу не вижу хорошего способа грамотно тестировать такие изменения,- возможно через Tenderly Virtual Testnet можно было бы такое изящно реализовать
На самом деле проблема решается относительно просто: нужно у оракулов ввести указание названий монет - что с чем сравнивается (если их еще нет). Как размерность в физике - если размерность не сходится, то в расчетах явно ошибка. Так и тут - если в конфигурации начинаем сравнивать ETH со слонами - то сразу можно падать в ошибку.
Посмотрел: оракул достаточно старый и один для всех криптоактивов сразу (кстати, не самая распространённая практика), так что размерность там считать в умном контракте нельзя. Впрочем даже там, где можно, ни разу не видел такой валидации при чтении цен из оракула (наверное, потому что работа со строками и их сравнением в Solidity крайне газозатратна + в именах активов настоящий хаос и они могут не биться между собой и даже меняться), а по адресам тоже делать это не получится, так как quote asset зачастую USD, а он не имеет собственного адреса ончейн.
Так можно не строки сравнивать, а числа (коды), а то и хеши - в "нативные" 256 бит влазит.
Более того - если проблема уже встречалась (а сколько таких моментов успели "поймать" до релиза?), эту валидацию можно и вне сети делать, каким-нибудь статическим анализатором (самописным).
И да, нужно "нормализовать" имена активов, что может быть непросто. Но в рамках одной платформы это вполне посильная задача.
P.S. при чтении можно и не сравнивать. Я предлагаю именно при инициализации оракула проверять. А то и до инициализации, вне сети.
P.P.S. может со строками и "дорого" работать а EVM, но конфиг оракула именно через строки задается )
Так можно не строки сравнивать, а числа (коды), а то и хеши - в "нативные" 256 бит влазит.
Очень дорого: чтение имени/тикера токена из другого контракта - это всегда строка + её хеширование. Транзакции будут тяжёлыми и стоимость вырастет ощутимо.
эту валидацию можно и вне сети делать, каким-нибудь статическим анализатором (самописным).
Вот тут согласен, хорошая идея, но готового инструмента сейчас никакого нет (особенно универсального под оракулы от разных поставщиков, особенно фреймворконезависимого, что можно будет использовать и в foundry, и в wake, и в hardhat etc).
И да, нужно "нормализовать" имена активов, что может быть непросто. Но в рамках одной платформы это вполне посильная задача.
Вот это не выйдет сделать, так как имя актива задаётся в контракте токена и может меняться его владельцем. Например, у USDT раньше был тикер USDT, а сейчас они переименовали его в контрактах на USDT0, USD₮0, USD₮ и даже BSC-USD (после того как они продали токен и бизнес в сети BSC бинансу). У Circe вообще есть два действующих официальных токена в сети Arbitrum и оба с ончейновым тикером USDC (отличить их можно только по адресам). В общем проблема с идентификацией криптоактивов ончейн старая, известная и пока никак эффективно на уровне умных контрактов нерешаемая (впрочем и оффчейн есть достаточно проблем, с которыми каждый раз сталкиваешься при разработке).
Кажется вы какой-то end-to-end тест уже хотите придумать. Но если что-то где-то забыли умножить, разве это просто юнит-тестом не покрывается? Ведь это же их код раз они там забыли умножить.
Апд. Или там всё-таки конфиги, как вы пишете ниже.
"Забыли умножить" - это очень упрощенное представление. Там скорее "перепутали оракул" и он выдавал не те значения на выходе.
Т.е. это ошибка конфигурации, а не арифметики.
Да, там ошибка конфигурации и юнит-тестом её не проверишь. Даже не смотря на то, что конфигурация осуществляется в коде на Solidity.
а там есть какой те тест энвайромент, куда сначала все эти конфиги выкатываются? там нельзя прогнать сценарий было?
Нет, адекватного тестового окружения и тестового прогона не было (по крайней мере такого, который бы проверял именно возможность произошедшей ситуации). В целом на их технологическом стеке это довольно проблематично из-за того, что тесты пишутся на Solidity. Если бы взяли wake, то я думаю можно было бы на практике написать подходящий тесткейс с проверкой на то, что описанный в статье случай не произойдёт.
Получается ещё что проблема в том что название пр немного мислидинг, если они там не только активировали рапер но и конфиги меняли
Торговые боты отреагировали мгновенно: по правилам платформы они погашали ~$1 долга и забирали взамен один cbETH стоимостью $2200.
Затем прибыль поделили с Claude.
Claude написал код с ошибкой
Кто сказал что это была ошибка? Это была возможность.
Согласно приказу имею на свадьбу феноменальную музыку в лице данного вундеркинда.
Нажми на клавиши, продай талант!
Гриша! Он же бьётся, Гриша!!!
Хочешь сто мильонов? Да бери усе, я себе еще нарисую!
Гриша, ты наблюдал, как эта врангелевская морда била меня в морду?
Чует мое сердце, что мы накануне грандиозного шухера.
Буквально подряд идущие строчки с викицитатника описывают весь схематоз.
Совпадение? Не думаю! (c)
Неужели "А я же говорил" ? Очень быстро, я думал дольше ждать придется.
Разумеется виноват ИИ, который сгенерировал код, а не человек, который этот код смотрел
ИИ способен генерировать код гораздо быстрее, чем человек способен его проверять. Поэтому либо надо будет к каждому ИИ-разработчику приставлять толпу двуногих "смотрящих" за ИИ (причем с очень приличными скиллами, так как качественно ревюить сложный код не проще, чем его писать самому), либо придется следовать принципу "и так сойдет" (максимум, посадить на тестирование еще один ИИ) и дальше молиться чтобы "прокатило". Очевидно, что бизнес чаще всего выберет второй вариант, или,если даже первый вариант, то все равно плавно мигрирующий ко второму. Ибо первый вариант обойдется не дешевле и не быстрее "ламповой" ручной разработки.
Классика, от нее не уйти, всегда приходится за что-то платить. Tреугольник управления проектами (быстро, дешево, качественно):
Быстро + Дешево = Не качественно.
Быстро + Качественно = Не дешево.
Дешево + Качественно = Не быстро.
@Быстро + Дешево = Не качественно.
Сейчас ситуация существенно усугубилась. Стало можно почти мгновенно, почти бесплатно, и почти абсолютно без собственных знаний и умений, но абсолютно непроверяемо (за разумные деньги и время) насколько качественно (ИИ умеет хорошо маскировтаь халтуру и бредни под профессионально выглядящий результат). По моему личному опыту, "подчищать" за ИИ в сколько-нибудь сложных и отвественных задачах выходит дороже и дольше, чем сделать все самому. Заметный профит может быть только на тех задачах, где допустим подход "вроде как-то работает, ну и так сойдет".
Я довольно часто использую агентов. За несколько лет использования пришел к выводу, что на агентов норм сваливать бойлерплейт, а вот какие-то ключевые моменты и бизнес-функционал лучше всегда писать ручками. Можно с авто комплитом, но построчно проверяя каждый такой авто комплит.
Выходит, что хороший разработчик в эпоху Ии, это прежде всего архитектор решений, умеющий понимать какая часть кода бойлерплейт, а какая часть - специфика проекта. Ну и естественно навык чтения и понимания кода обязателен, как и умение его писать (пусть даже с автокомплитом).
Я тоже могу писать код ооооочень быстро. Правда, такая фигня получается...
фишка в том, что ошибки ии не просто опечатки. они очень похожи на реальный код.
я слышал, что человеку больше не нужно ничего смотреть и понимать, ии все сам делает, и код пишет и ревью проводит, и тестирование. А теперь внезапно оказывается, что еще человек что-то там смотреть должен?
Судя по радостным комментариям, люди вообще ошибок (в том числе именно таких) никогда не совершают. Вот здорово!
Люди радуются, потому что это очередной аргумент против вайбкодеров-сектантов, утверждающих, что с появлением нейросетей больше не нужны никакие навыки и знания программирования, можно просто генерировать в ней код и сразу деплоить в прод.
На моей памяти это первый такой случай, когда в крупном лендинг-протоколе был криво сконфигурирован ценовой оракул. Так что нет, ранее люди такого рода ошибок при конфигурации лендинг-протоколов (особенно столь крупных) не совершали и в целом хейт слепого использования LLM в данном случае оправдан. Вопрос к чему этот приведёт в нашей индустрии: будем меньше пользовать LLM и писать критические участки кода по старинке или сосредоточимся на усилении безопасности за счёт добавления формальной верификации, фазинга, тестов и так далее
Ну были другие проколы еще масштабнее чем этот, например The DAO повлекший за собой форк Эфира и виляние задницами основателей заявлявших что код==контракт. Видимо ошибки кода это не часть корабля контракта.
Безусловно, но техническая сложность уязвимости в The DAO (до взлома вообще не подозревали, что reetrancy-атаки возможны) и текущая ошибка конфигурации рынка кредитования даже близко не сопоставимы. Если бы LLM существовали во времена разработки The DAO, то была бы допущена точно такая же ошибка, что допустили люди, так как просто не было даже близко подходящей релевантной выборки для обучения противодействию reetrancy-атакам. В случае с The DAO разве что формальная верификация и фазинг-тестирование могли бы помочь, но тогда не было таких развитых инструментов для кода на Solidity.
Это уже второй сбой оракулов у Moonwell: в ноябре 2025 года платформа теряла более $1 млн из-за похожей ошибки.
Это не вопрос к LLM. Это вопрос кривости кода и отсутствия строгого аудита.
P.S. я сильно сомневаюсь, что код контракта писался LLM - слишком много закоменченных кусков кода, LLM так не пишет. Скорее LLM применялась для написания документации.
Это естественная реакция на многочисленные статьи с названиями типа такого "ИИ-инструмент нашёл неизвестные магнитные материалы", "GPT за 2 минуты решил очередную математическую проблему". Там ведь тоже исследователь, умело использующий инструмент, как-бы не причём.
С тем, что ответственность на человеке, полностью согласен. Нейросеть может сгенерировать код, но контроль качества никто не отменял
Посмотрел я этот код... Это яркий пример того, почему надо удалять неиспользуемый код, а не комментариями его оформлять. Да и в целом, почему надо писать понятный и прозрачный код.
Другой вопрос - а где тесты, тем более что это не первый подобный случай.
P.S. к LLM вопросов как раз особых нет. Если в коде "черт ногу сломит", то и "LLM ногу сломит".
Хорошая новость! Спасибо
Прочел, всё что вынес,даль меня не было на этой бирже, скупил бы, да потом через дефи на другие гкошели отправил бы, или в монеро и досвидос, но увы... как там такой шанс выпадает не всем , думаю эта мун дорога не обеднела, думаю там среди наших мало у кого акки есть, у нас вон опять надумали все ихние) по определению неправильные биржи запретить, сделаем свою которую во всем мире забанят))) будет свой чебурнкт и свойчебуркоин))
Ряяяяя глупый ИИ
Смоки тесты не?
Минус статье не ставлю, так как тема очень важная, но по фактам не совсем так:
Ошибка в ценовом оракуле
Ошибка была не в ценовом оракуле,— он работал и работает корректно. Ошибка была в том как сконфигурировали использование ценовых оракулов лендинг‑протоколом: вместо двух ценовых оракулов использовался лишь один.
Торговые боты воспользовались этим за считаные минуты.
Только не торговые боты, а боты-ликвидаторы. Часть из них потом продала обеспечение из ликвидированных позиций, а часть нет.
платформа осталась с безнадежным долгом в $1,78 млн.
Только безнадёжного дола не образовалось: bad debt в этот раз у Moonwell не возник, так как все позиции были успешно ликвидированы (обеспечение по позициям ушло ликвидаторам, которые погасили все долги по позициям). Но у Moonwell действительно сейчас есть большой безнадёжный долг, но он образовался ещё в прошлый раз во время взлома моста Nomad, когда ликвидаторы как раз не провели ликвидацию позиций из-за того, что это было им невыгодно (поэтому образовался безнадёжный долг),— в этот раз такого не было.
Получается Клод вообще ни при чём, если это ошибка конфигов, или конфиги тоже он писал?
Конфигурация осуществляется в таких случаях как правило через код на Solidity. Есть подозрения, что его писала LLM, но проверить полагаю не представляется возможным.
До уровня разрабов из Knight Capital Клоду ещё далековато конечно.
Написал про этот случай другу в телегу. А потом что то стрельнуло - думаю и сюда скину.
Я тут ram mаnаger писал свой. На днях. Супер быстрый. Супер эффективный.
Написал костяк. И решил доверить искать баги новомодному sonet 4.6/ И скажу это было эпично. Он находил реальные логические баги. но сука описывал их так что я был выжат как лимон пытаясь понять что он описывает. Код строчек 100 наверно. Но дичайший хардкор из ссылок
Короче раз 10 кидал код на проверку.
И с каждым разом мне всё труднее и труднее становилось понять что он мне говорит
В конце просто тупо по инерции правил что он говорит
Дальше конечно буду тестить как это всё работает
Но знаешь какой вывод главный
Каким бы умным claud не был - ты должен быть погружён в код ещё умнее
Иначе это просто дорога в никуда.
У меня есть код реализации индексов со своей хитрожопой архитектурой
Я её наверно месяц 3 отлаживал
там строк кода больше 1000
И могу с казать с claud я наверное бы год это всё делал и баги бы остались
Это мало кто понимает
Я про эту проблему писал даже статью на хабре
Мы подменяем сложность загрузки в мозг текущей архитектуры проекта - отдавая всё это на откуп LLM
А когда мы полностью теряем понимание что делает код - это всё. Дорога в никуда
Кто ещё прочитал этот коммент с интонациями Маяковского? )
Как я говорил - реальные тесты никогда (по крайней мере сейчас) не заменят код с генерированный и 100 раз проверенный LLM.
Написал тест. Запускаю - и сразу же получаю неправильное поведение логики. Сообщаю это sonnet - а она в свою очередь запускает свою стандартную шарманку. Да вы правы... траляля... и описывает этот логический баг
Что её мешало раньше его найти? А она просто не могла это сделать. Она может находить и описывать баги только из наших уточняющих промтов.
Если кому интересно что за баг. Вот мой промт.
Я целый день проводил с тобой тесты программы и в конечном счёте ты мне сказал что всё работает идеально. А теперь ответь мне на вопрос. Как может сработать ветка которая считает все страницы как пустые по алгоритму проверки всей битовой маски на 0 если страница которая отдана под sett_area всегда будет помечена как занятая
Вот ответ sonnet
Если что - то она советует пургу как исправить. Я сам всё нормально исправлю.
Короче к чему это я. Имеем следующую картину - да помогает. Да ищет баги. Но время на это затрачивается столько же сколько бы и сам искал. Плюс выжимает как лимон
Реально трудно понимать что она там про баги пишет
Но в результате она всегда не находит все баги. всё равно приходится писать тесты и тестировать все участки кода.
А при таком случае теряется вообще смысл этапа обсуждения кода с LLM. Короче истина по середине. Пользоваться я конечно буду (ну собственно уже плотно пользуюсь почти всегда и давно). Но квалификация и энергозатраты на пользование очень высокие
Хз как всякие вкатуны смогут грамотно это использовать
1890-й год.
Пьяный мужик попал под автомобиль.
Возвращаемся обратно на гужевой транспорт.
В оригинале отчёта Moonwell ни слова про Claude. Это первое. Claude is AI and can make mistakes. Please double-check responses. Это втрое.
Новость про что? Что люди читать не умеют. Или про то, что кто-то не умеет пользоваться Claude Code?
назвал ошибку "очень простой" — по сути, пропущенное умножение, которое должен был поймать обычный аудит.
По опыту использования нейросетей, обратил внимание что они склонны совершать детские ошибки, которые даже джун не допустит. От чего их сложней замечать.
Из последнего это перестановка параметра x и y в вызове функции, из-за чего передаются ошибочные координаты. Заметил на ревью так как был нестандартный порядок передачи параметров. Хобби проект, поэтому тестов не было.
Все еще скептично настроен на полную замену программистов. Так как в фундаменте нейросети это модель которая пытается из энтропии подобрать наиболее подходящий для нее результат, а там может быть что угодно.
Это даже не детские ошибки, это "подвох возможен в любом слове".
С опытом примерно понимаешь, где и как можно ошибиться - там и проверяешь в первую очередь.
LLM же очень и очень правдоподобный код пишет с ошибками в самых неожиданных местах.
Это не "детский" код. Это скорее код из серии "вредные советы"
#define TRUE FALSE //счастливой отладки суки
Моё любимое — это когда ИИ в запросе зачем-то вписал совершенно ненужный DISTINCT в условие in:
... where FIELD in (select distinct field_name from mytable)Указываю ему, мол, зачем тут дистинкт? Он такой: "Да! Вы абсолютно правы! DISTINCT в данном случае избыточен!"
Думаю: "ну классно, а чего ж ты сразу сообразить не мог?". Вопрос, конечно же, риторический.
Пока радует то, что за конечный результат может отвечать только человек
Это всё промт виноват! ИИ не может делать ошибки!
Человек тоже мог ошибиться. И скорее всего он и ошибся тут, давая задание AI. Обычно перед релизом тестируют. Но и там бывают что что-то упустят. Так что обычная ситуация. AI так вообще не понимает что пишет, просто согласно выборке ему показалось так правильно
Не особо удивительно, что даже в блокчейн пробрались нейронки и их начали привлекать писать код, вполне себе рабочее решение, особенно для PoC, беда таится немного в другом, в том как построен процесс доказуемой безопасности, ведь как оно выглядит в хорошем случае, вы пишите код, затем тесты, а после проходите в какой то конторе аудит, и вроде все нормально, если бы не хитрые аудиторы, которые в договорах всегда включают пункт, что они могут что-то проглядеть и вы не имеете претензий к ним, вот здесь круг замкнулся и начинается путь в ад. Учитывая сколько стоит аудит, использование нейронок дает просто бешеный прирост чистой прибыли.
А есть у кого ссылка на коммит? Интересно посмотреть, что там на вайбкожено было.
"Навабкодили" там от силы документацию.
https://github.com/moonwell-fi/moonwell-contracts-v2/pull/578
Ребята, я знаю кто на самом деле виноват. Это HR, который нанял того чела, который писал код совместно с Клавдией потом и не читал за ней!
И это только начало. Учитывая растущее количество вайб-кодеров, и постепенное вымирание настоящих программистов.
Ну да виноват Клод, хотя там во всех комитах был человек
https://github.com/moonwell-fi/moonwell-contracts-v2/pull/578/commits
И старый конфиг оставили закомментированным - как будто бы подчерк человека
Винить стоит разработчиков, тестирование и лидов, кто это сделал, а не инструмент Винить AI агента/модель - это всё равно, что обвинять в причине бага IDE или браузер
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Claude написал код с ошибкой — криптоплатформа потеряла $1,78 млн за минуты