Узагальнені тести властивостей для сховищ ERC4626

Оскільки DeFi росте та розвивається, масштабована інфраструктура та можливість компонування є головними для розробників. Запити Ethereum на коментарі (або ERC) — стандартизовані набори інструментів для створення додатків на основі Ethereum, наприклад широко використовуваний стандарт токенів ERC20 — виконувати важливу роль у забезпеченні узгоджених інструкцій для розробників, щоб зробити внесок в екосистему, не починаючи з нуля. Раніше в цьому році, токенізований стандарт сховища ERC4626 було створено для заохочення перехресної сумісності між прибутковими токенами. Стандартизація деталей реалізацій також може вирішити нагальні проблеми компонування, полегшуючи інтеграцію протоколу та, зрештою, менш схильну до помилок.

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

На щастя, прості помилки можуть мати відносно прості рішення, якщо їх виявляють задовго до того, як їх використають (а в ідеалі ще до їх розгортання). З цією метою ми звільнили Тести властивості ERC4626 для фаззингу та символічного виконання, щоб допомогти розробникам сховищ виявляти стандартні порушення, які можуть порушити інтеграцію або призвести до вразливостей. У цьому дописі ми пояснюємо проблему мотивації, розповідаємо про наш підхід і на завершення даємо кілька практичних порад.

Спочатку трохи передісторії стандарту ERC4626

Завершено в березні, ERC4626 є стандартом для токенізованих сховищ. Це було введено з метою розширення широкого використання ERC20 стандарт (на даний момент є основою для сотень токенів), заохочувати стандартизацію в сховищах, що несуть прибуток, і забезпечувати можливість комбінування для програм і протоколів (наприклад, агрегаторів дохідності), які повинні з ними взаємодіяти. Це означає, що будь-яку програму, створену на основі сховища ERC4626, можна легко розширити для роботи з будь-яким іншим сховищем ERC4626. 

Токенізовані сховища дозволяють користувачам вільно розміщувати активи для карбування акцій сховища, а потім викуповувати ці акції, щоб зняти основну суму та відсотки зі сховища. Ці акції сховища є токенами ERC20, і, отже, ними можна легко торгувати або використовувати як заставу для запозичення інших активів. Наприклад, користувачі можуть розміщувати свої активи в сховищах Yearn, щоб карбувати токени yVault, якими потім можна торгувати на Uniswap, робити ставки для додаткового прибутку або використовувати як заставу для протоколів кредитування.

Бізнес-логіка генерування та розподілу прибутку (і визначення ціни акцій) може відрізнятися залежно від реалізації. Щоб охопити якомога більше сховищ (з метою зробити їх сумісними, а не ідентичними), стандарт ERC4626 фокусується на описі інтерфейсу користувача, залишаючи більшість деталей реалізації невизначеними. Це дозволяє варіювати бізнес-логіку, якщо сховище відповідає конкретним вимогам інтерфейсу та заохочує сумісність між багатьма різними видами програм і типами сховищ ERC4626.

Оскільки буде створено більше сховищ, ми очікуємо, що вони з самого початку будуть реалізовані відповідно до стандарту ERC4626; але зараз ми перебуваємо на дещо перехідній стадії, коли розробникам, які бажають скористатися перевагами кращої компонування, потрібно буде оновити існуючі сховища, програми та протоколи, щоб вони відповідали стандарту. І під час оновлення вони стикаються з низкою складнощів і викликів. 

Проблеми відповідності стандартам (і підводні камені невідповідності)

Слідувати новому стандарту не завжди просто. Кожне сховище ERC4626 має сумлінно (і точно) виконувати вимоги стандарту, як описано. В іншому випадку інтеграція сховищ ERC4626 стає дедалі складнішою для врахування різних варіацій. Ця складність робить інтеграцію за своєю суттю схильною до помилок; і оскільки вони недостатньо стійкі до майбутнього, з часом можуть призвести до вразливості системи безпеки.

Нестандартні токени ERC20 (наприклад, Tether USD) вимагають, щоб багато систем DeFi використовували додаткову бібліотеку (наприклад, SafeERC20) під час передачі токенів, щоб безпечно впоратися з різною поведінкою (наприклад, не повертати нічого, коли передача вдається замість повернення true). Це означає, що будь-які системи, які взаємодіють із цими маркерами, можуть стати вразливими, якщо система не розроблена для належної обробки випадків «відсутніх повернень». Ці сценарії потенційно можуть створити загальну пастку безпеки та збільшити загальні витрати на розробку та обслуговування (з урахуванням додаткової логіки та залежностей, необхідних для пом’якшення проблем). Тому відповідність стандарту має вирішальне значення не лише для окремих реалізацій, але й для безпеки всієї екосистеми. Одна вразливість в одній системі або залежності може спричинити масові проблеми.

В ідеалі стандарти повинні бути формально визначені без двозначності (наприклад, формальна специфікація ERC20), і кожна реалізація може бути офіційно перевірена на відповідність стандартній специфікації. Однак на практиці цього непросто досягти за короткий проміжок часу через витрати та зусилля, які вимагає від громади.

Представляємо виконувані властивості ERC4626 для виявлення проблем відповідності 

Оскільки ми працюємо над ідеальним станом (кожне сховище офіційно перевіряється на відповідність строгим формальним специфікаціям), ми написали стандарт ERC4626 властивості вловлювати розбіжності в тонких деталях стандартних вимог, які легко пропустити.  

Розробники Vault можуть запускати тести, щоб виявити потенційні порушення стандартів у своїх реалізаціях перед розгортанням. І інтегратори сховищ можуть перевірити, чи відповідають дані сховища стандарту, перш ніж інтегрувати їх у свою систему. Властивості також можна перевірити на живих сховищах, уже розгорнутих у основній мережі, за допомогою тестування розгалуження основної мережі. Тестування живих сховищ може бути корисним — особливо якщо сховища нещодавно розгорнуто або оновлено — щоб переконатися, що всі системні параметри встановлено правильно. 

Ми вибрали тести на основі властивостей — написані на Foundry і готові до запуску його фаззером — щоб зробити властивості виконуваними (і, отже, перевіреними). У майбутньому їх також можна запускати за допомогою інструментів символічного виконання або перевірки моделі, щоб формально перевірити, що дане сховище задовольняє властивості для всіх можливих входів і умов.

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

Наприклад, наступна властивість відповідає одній із вимог convertToShares() функція, "НЕ ПОВИННО відображати будь-які варіації залежно від абонента.” Враховуючи дві адреси рахунків і суму, він робить виклик кожного з рахунків convertToShares() з однаковою сумою та забезпечує рівність двох повернених значень. Ця властивість не залежить від деталей реалізації convertToShares(), який різниться в різних сховищах і повинен відповідати будь-яким сховищам, які реалізують ERC4626. Ця властивість може бути виконана шляхом надання конкретних вхідних значень (для модульного тестування), багатьох випадкових вхідних даних (для тестування фаззів) або символьних значень (для символічного виконання та формальної перевірки). Його також можна запускати локально або на розгалуженні основної мережі (для тестування інтеграції).

Випадок використання: властивості, які перевіряють помилки округлення

Помилки округлення, наприклад, є важливим класом (здавалося б, незначних) помилок, які можуть мати ряд наслідків. Основна бухгалтерська логіка ERC4626, наприклад, обчислення кількості акцій, які будуть викарбувані, або суми активів, які будуть виведені, реалізовано за допомогою арифметики з фіксованою комою — помилки округлення неминучі. для безпеку, однак стандарт явно вказує бажаний напрямок округлення для кожної функції інтерфейсу, залишаючи межі помилок невизначеними та залежними від реалізації. Зокрема, deposit() та redeem() функції мають повертати an при-наближення до точного значення, при цьому mint() та withdraw() функції мають повертати an над-наближення. Наприклад, якщо поточна ціна акції (тобто сума активів на акцію) дорівнює 2, тоді deposit() з 3 вей активів слід карбувати лише до 1 вей акцій (тобто, floor(3/2)), в той час withdraw() з 3 вей активів має спалити принаймні 2 вей акцій (тобто, ceil(3/2)).

Ми записали властивості, пов’язані з округленням, незалежними від основної логіки обліку, розглядаючи їх як чорний ящик. Зокрема, ми сформулювали їх як так звані властивості «туди й назад», які описують зв’язок між двома протилежними функціями. Наприклад, наступна властивість визначає, що вилучення активів, які щойно були депоновані шляхом карбування N акцій, має спалити не менше ніж N акцій. Іншими словами, ніхто не може отримати безкоштовний прибуток, конвертуючи активи та акції сховища туди й назад шляхом повторного карбування та вилучення.

Дійсно, ми виявили, що кілька сховищ ERC4626 у головній мережі не задовольняють наведену вище властивість через помилки округлення. Це означає, що будь-хто може заробити, наприклад, пару сатоші BTC (1 сатоші ~= 0.02 цента на момент написання), просто (і багаторазово) карбуючи та виводячи, повільно виснажуючи сховище. Це може фактично принести прибуток мережам, які мають дуже низькі збори за газ (наприклад, Fantom), або якщо ціна активу стане достатньо високою в майбутньому.

Тестування стандарту ERC4626 у природі

Ми перевірили наші властивості на ~100 сховищах ERC4626 у головній мережі та знайшли багато сховищ, які не відповідали стандартним вимогам — переважно через помилки округлення (наприклад, використання округлення підлоги, де бажана стеля, як ми описали). Зокрема, деякі сховища не змогли викарбувати точну кількість акцій, яку запитував mint() функції, хоча стандарт явно вимагає це. Деякі з них також видавали непослідовні Deposit подія, коли зареєстровані дані відрізняються від фактично викарбуваних. На наш подив, деякі сховища взагалі ніколи не карбувалися на місці; замість цього вони просто ставлять запити на монетний двір у чергу та обробляють їх пізніше в пакеті як окрему транзакцію.

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

Використовуючи наші тести властивостей та інші дієві кроки для досягнення стандартної відповідності

Точне дотримання стандарту може запобігти різним поведінкам (в ідеалі, перш ніж їх розгортати). Ми сподіваємося, що наші властивості допоможуть, а також кілька додаткових дій. Для тих, хто розробляє та/або інтегрує сховища ERC4626:

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

***
Сховища ERC4626 мають потенціал стати важливим будівельним блоком для DeFi у доступному для огляду майбутньому — і для зручності компонування важливо, щоб як нові, так і існуючі сховища відповідали стандарту. Нові впровадження з’являться відповідно до стандарту, тому немає кращого часу, ніж теперішній, щоб стандартизувати існуючі сховища. 

Оскільки ми працюємо над ідеальним станом (де різні сховища однаково комбінуються), тести властивостей ERC4626 можна запускати, щоб легше виявляти порушення стандартів у реалізаціях сховищ. Тести властивостей (з документацією та прикладами) є загальнодоступними на нашому Github Сховище. Ми вітаємо ваші відгуки та внески!

***
Погляди, висловлені тут, є поглядами окремих співробітників AH Capital Management, LLC («a16z»), які цитуються, і не є поглядами a16z або його філій. Певна інформація, що міститься тут, була отримана зі сторонніх джерел, зокрема від портфельних компаній фондів, якими керує a16z. Хоча отримано з джерел, які вважаються надійними, a16z не перевіряв таку інформацію незалежно та не робить жодних заяв щодо поточної чи довгострокової точності інформації чи її відповідності певній ситуації. Крім того, цей вміст може містити рекламу третіх сторін; a16z не переглядав такі оголошення та не схвалює будь-який рекламний вміст, що міститься в них.

Цей вміст надається лише в інформаційних цілях, і на нього не можна покладатися як на юридичну, ділову, інвестиційну чи податкову консультацію. Ви повинні проконсультуватися з власними радниками щодо цих питань. Посилання на будь-які цінні папери чи цифрові активи наведено лише з метою ілюстрації та не є інвестиційною рекомендацією чи пропозицією надати інвестиційні консультаційні послуги. Крім того, цей вміст не призначений для будь-яких інвесторів чи потенційних інвесторів і не призначений для використання ними, і за жодних обставин на нього не можна покладатися при прийнятті рішення інвестувати в будь-який фонд, яким керує a16z. (Пропозиція інвестувати у фонд a16z буде зроблена лише на підставі меморандуму про приватне розміщення, угоди про підписку та іншої відповідної документації будь-якого такого фонду, і її слід читати повністю.) Будь-які інвестиційні чи портфельні компанії, згадані, згадані або описані не є репрезентативними для всіх інвестицій у транспортні засоби, якими керує a16z, і не може бути гарантії, що інвестиції будуть прибутковими або що інші інвестиції, здійснені в майбутньому, матимуть подібні характеристики чи результати. Список інвестицій, здійснених фондами під управлінням Andreessen Horowitz (за винятком інвестицій, щодо яких емітент не надав дозволу a16z на оприлюднення, а також неоголошених інвестицій у публічні цифрові активи) доступний за адресою https://a16z.com/investments /.

Наведені в ньому діаграми та графіки призначені виключно для інформаційних цілей, і на них не слід покладатися під час прийняття інвестиційних рішень. Минулі результати не вказують на майбутні результати. Зміст відповідає лише вказаній даті. Будь-які прогнози, оцінки, прогнози, цілі, перспективи та/або думки, висловлені в цих матеріалах, можуть бути змінені без попередження та можуть відрізнятися або суперечити думкам, висловленим іншими. Додаткову важливу інформацію можна знайти на сторінці https://a16z.com/disclosures