MegaETH епічна катастрофа! Неправильний контракт зіпсував 500 мільйонів доларів попереднього продажу, які будуть повернуті.

MegaETH поверне всі кошти, які користувачі внесли у свій попередній «попередній міст», тим самим скасувавши раніше заплановану активність для попереднього завантаження ліквідності для USDm, яка перетворилася на одну з найхаотичніших спроб фінансування цього року. Команда заявила, що виконання було «дуже неакуратним», і очікування користувачів щодо ліміту в 250 мільйонів доларів не відповідало їхнім внутрішнім цілям попереднього введення забезпечення. Усі депозити будуть повернені через новий смартконтракт, який наразі проходить аудит.

Помилка, викликана неправильним SaleUUID

! Попередній продаж MegaETH

（джерело：MegaETH）

Хоча MegaETH підкреслює, що жодні кошти не піддаються ризику, це рішення було прийнято після детального аналізу команди низки невеликих технічних збоїв (додатково до операційних помилок і помилок у конфігурації інфраструктури), які призвели до хаотичного та несправедливого процесу продажу. Проблема виникла відразу після випуску, оскільки в контракті містився неправильний SaleUUID, що призвело до невдачі транзакції, яка вимагала оновлення 4 з 6 підписів мультипідпису.

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

Гірше того, для виправлення цієї помилки потрібно провести оновлення мультипідпису. Мультипідпис — це механізм безпеки, який вимагає, щоб кілька уповноважених осіб підписали спільно, щоб виконати критично важливі операції. У налаштуваннях MegaETH потрібно, щоб 4 з 6 підписантів погодилися на оновлення контракту. Хоча цей механізм забезпечує безпеку, в екстрених ситуаціях він також значно знижує швидкість реагування. Коли користувачі масово намагаються внести депозит, команда в той час тривожно чекає, щоб достатня кількість підписантів підключилася для затвердження виправлення.

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

KYC обмеження потоку та контроль часу зазнали подвійного удару

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

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

Серйозність цієї проблеми полягає в тому, що вона не рівномірно впливає на всіх користувачів, а викликає випадкову несправедливість. Деякі користувачі змогли подати свої запити безпосередньо перед активацією обмежень, успішно завершивши KYC та зробивши депозит. Тим часом інші користувачі були відхилені системою, навіть якщо вони подали запити в той же час. Ця випадковість повністю суперечить принципу “перший прийшов - перший обслужений”, перетворюючи попередній продаж на гру удачі.

П'ять основних технічних помилок у провалі попереднього продажу MegaETH

Помилковий SaleUUID: смартконтракти містять помилковий ідентифікатор продажу, що призводить до невдачі всіх угод

KYC обмеження трафіку: суворі обмеження трафіку, встановлені Sonar, перехопили велику кількість запитів від користувачів

Затримка багатопідпису: потрібно 4 з 6 підписів для затвердження оновлення, швидкість реакції низька

Втрата контролю над часом: Транзакції без обмежень виконуються раніше, втрачаючи контроль над часом

Не вдалося змінити ліміт: спроба змінити ліміт депозиту, але швидкість надходження коштів перевищує швидкість підтвердження угод.

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

Вихід з-під контролю розширення від 250 мільйонів до 500 мільйонів доларів

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

Цей опис розкриває паніку та відсутність контролю команди MegaETH протягом усього процесу. Спочатку встановлений ліміт у 250 мільйонів доларів був заповнений за кілька хвилин, команда поспішно вирішила підвищити ліміт до 1 мільярда доларів. Однак, усвідомивши, що це може бути надмірно, вона знову намагалася знизити його до 400 мільйонів доларів. Коли ця спроба зазнала невдачі, вони знову намагалися встановити ліміт у 500 мільйонів доларів.

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

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

Обіцянка повного повернення коштів та повторного запуску

MegaETH повідомив, що пізніше буде підтверджено права депозитарів, але не було розкрито конкретних деталей. Тому міст для конвертації USDM та USDC в USDM буде повторно відкрито перед запуском основної мережі Frontier, щоб створити ліквідність у більш контрольованому середовищі. Всі депозити будуть повернені через новий смартконтракт, який наразі проходить аудит.

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

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