Засвоєні під час читання коди Uniswap та отримані навички розробки контрактів набагато цікавіше за підручники

Останнім часом, коли я займався навчанням розробки децентралізованих бірж, глибоко досліджував реалізацію Uniswap V3 і зрозумів, що деякі підходи дійсно геніальні. Раніше я писав лише прості NFT-контракти, а цього разу вперше серйозно занурився у код DeFi-контрактів і знайшов багато цікавого, що хочу поділитися з тими, хто хоче вивчати уроки по Uniswap.

Почну з найбільш вражаючого — чи можна передбачити адресу контракту?

Зазвичай, при розгортанні контракту адреса здається випадковою, але Uniswap використовує хитрий спосіб. Він через додавання параметра salt при створенні контракту, використовуючи команду CREATE2, робить адресу передбачуваною. Конкретний приклад — «pool = address(new UniswapV3Pool{salt: keccak256(abi.encode(token0, token1, fee))}());». Такий код. Перевага в тому, що, знаючи торгову пару і комісію, можна обчислити адресу пулу ще до його розгортання, що особливо корисно для перевірки прав або швидкого пошуку пулу.

Дизайн колбек-функцій теж дуже продуманий.

У Uniswap, коли викликаєш метод swap для обміну, він викликає функцію swapCallback, передаючи туди обчислену кількість потрібних токенів, а ти у колбеку переводиш ці токени. Це дозволяє виконати всю логіку обміну в одному виклику без розбиття на кілька кроків або складних змінних для безпеки. Простими словами — А викликає Б, а Б у свою чергу викликає А, утворюючи замкнене коло.

Метод оцінки обміну теж досить хитрий — використовує виключення для передачі інформації.

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

Рішення щодо точності обчислень теж варто вивчити.

При обчисленні обміну токенів, якщо просто ділити, втрачається точність. Uniswap робить так: спочатку зсуває число вліво на 96 біт (еквівалент множення на 2^96), потім ділить, і в процесі знову ділить на 2^96, щоб повернути масштаб. Це дозволяє зберегти точність у межах uint256 і уникнути переповнення. У коді це реалізовано через змінні sqrtRatioAX96 і sqrtRatioBX96 — виглядає складно, але логіка зрозуміла.

Ще один цікавий момент — спосіб обчислення доходу від комісій.

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

Не всі дані потрібно зберігати на ланцюгу — це теж важливо.

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

І нарешті, організація коду.

Зазвичай складні проекти розбивають контракти на кілька частин для зручності підтримки, і Uniswap теж використовує таку ієрархію. Також важливо використовувати стандартні контракти, наприклад, OpenZeppelin ERC721 для управління позиціями — це підвищує швидкість розробки і якість коду.

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