Ethereum Foundation досліджує твердження щодо транзакцій, які дадуть користувачам змогу додавати до транзакції умови, обов’язкові для виконання щодо її кінцевого результату, замість того щоб покладатися лише на схвалення запитаної дії. Це дослідження в межах ініціативи Trillion Dollar Security спрямоване на усунення прогалини в безпеці транзакцій: дійсний підпис не гарантує, що отримані баланси, дозволи або засоби контролю облікового запису відповідатимуть намірам підписанта.

Ключові висновки

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

Зміст

Чому схвалення транзакції все одно може призвести до збитків

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

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

Як приклад фонд наводить заставний своп між Aave і CoW на суму близько $50.4 млн в aEthUSDT. Низька ліквідність AAVE та ліміт газу CoW обмежили виконання підтвердженою котировкою приблизно на 329 aEthAAVE. Попри попередження про вплив на ціну в 99.9 відсотка та підтвердження того, що всю вартість можна втратити, користувач підписав транзакцію й отримав токени вартістю близько $36,000.

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

ПунктДеталі
TXTRACEПерелічує чисті зміни стану та згенеровані події транзакції.
TXDIFFОтримує початкові й кінцеві значення для вказаних адрес і слотів сховища.
EVENTDATACOPYКопіює дані події в пам’ять для перевірки.
Відомості про розгортанняЗапропоновані дані про зміни стану охоплюють новорозгорнуті контракти та хеші їхнього коду.

Як твердження щодо транзакцій перевірятимуть результат

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

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

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

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

Які дані відкриватиме запропонована реалізація

В оголошенні Ethereum Foundation про вбудовані твердження щодо транзакцій EIP-7906 описано як можливий варіант реалізації, а не як остаточний дизайн. Він спирається на транзакції з фреймами, передбачені EIP-8141, які впорядковують етапи перевірки та виконання дій. Впровадження EIP-8141 заплановано для Hegotá; EIP-7906 отримав статус Considered for Inclusion, але його включення до цього оновлення не підтверджено.

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

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

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

Що потрібно буде змінити в гаманцях і протоколах

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

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

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

Що можуть отримати агенти та робочі процеси солверів

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

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

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

Висновок

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

Читайте більше новин

Більше новин FinanceVelix

Застереження

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