Практичні поради щодо розробки контрактів: досвід, отриманий з коду Uniswap

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

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

Адреса розгортання ф'ючерсного контракту

Зазвичай адреса, отримана під час розгортання контракту, виглядає випадковою через зв'язок з nonce, що ускладнює її прогнозування. Але в деяких сценаріях нам потрібно вивести адреси контракту через торгові пари та відповідну інформацію. Це корисно в ситуаціях, коли потрібно визначити права на торгівлю або отримати адреси пулу.

Uniswap використовує метод CREATE2 для створення контракту, додаючи параметр salt, що робить адресу створеного контракту передбачуваною. Логіка генерації нової адреси полягає в наступному: hash("0xFF", адреса творця, salt, initcode). Цей метод робить адресу контракту передбачуваною, що полегшує подальші дії.

Розумне використання функцій зворотного виклику

У Solidity контракти можуть викликати один одного. Один із звичних сценаріїв - це виклик методу A методом B, де B у викликаному методі викликає зворотний зв'язок до A. Це дуже корисно в деяких випадках.

Наприклад, якщо взяти Uniswap, коли викликається метод swap контракту UniswapV3Pool для проведення угоди, він викликає swapCallback, передаючи обчислений токен, необхідний для цієї угоди. Викликач повинен під час зворотного виклику перевести токен, необхідний для угоди, в UniswapV3Pool. Такий дизайн забезпечує повне виконання та безпеку методу swap без необхідності у складному веденні записів змінних.

Використання аномалій для передачі інформації, реалізація оцінки угоди за допомогою try catch

У контракті Quoter Uniswap використовується блок try catch для виконання методу swap UniswapV3Pool. Це робиться для симуляції методу swap з метою оцінки необхідних токенів для угоди. Оскільки під час оцінки фактичний обмін токенів не відбувається, виникає помилка. Uniswap викидає спеціальну помилку в функції зворотного виклику угоди, а потім ловить цю помилку і витягує з неї необхідну інформацію.

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

Вирішення проблеми точності за допомогою великих чисел

У коді Uniswap є багато обчислювальної логіки, наприклад, розрахунок токенів для обміну на основі поточної ціни та ліквідності. Щоб уникнути втрати точності через операції ділення, Uniswap часто використовує "<< FixedPoint96.RESOLUTION" операцію, тобто зсув вліво на 96 біт, що еквівалентно множенню на 2^96. Спочатку виконується зсув вліво, а потім виконуються операції ділення, що дозволяє гарантовано зберігати точність при нормальних операціях обміну без переповнення (, зазвичай використовуючи uint256 для обчислень ).

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

Розрахунок доходу за допомогою Share

Uniswap потрібно зафіксувати дохід від комісій LP( для постачальників ліквідності ). Щоб уникнути витрат великої кількості Gas на фіксацію комісій для кожного LP під час кожної угоди, Uniswap використовує хитрий метод.

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

Розумний вибір шляхів отримання інформації

Зберігання в ланцюгу відносно дороге, тому не вся інформація повинна бути в ланцюзі або отримуватися з ланцюга. Наприклад, багато інтерфейсів, які викликає фронтенд-сайт Uniswap, є традиційними Web2 інтерфейсами.

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

Деякі постачальники RPC для блокчейну пропонують розширені інтерфейси, які дозволяють швидше та економніше отримувати певні дані. Ці інтерфейси зазвичай використовують кеш для підвищення продуктивності та ефективності.

Звичайно, ключові транзакції все ще повинні проводитися в мережі.

Вивчення розподілу контрактів та використання існуючих стандартних контрактів

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

Наприклад, контракт NonfungiblePositionManager Uniswap успадковує кілька контрактів. При реалізації контракту ERC721Permit безпосередньо використовується контракт @openzeppelin/contracts/token/ERC721/ERC721.sol. Це не лише спрощує управління позиціями за допомогою NFT, але й дозволяє використовувати існуючі стандартні контракти для підвищення ефективності розробки.

Резюме

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