Поради з розробки контрактів, отримані з коду Uniswap
Нещодавно, під час написання посібника з розробки децентралізованих бірж, я звертався до коду реалізації Uniswap V3 і дізнався багато цінних знань. Як розробник, який вперше намагається розробити контракти Defi, ці навички будуть дуже корисними для новачків, які хочуть навчитися розробці контрактів.
Прогнозована адреса розгортання контракту
Зазвичай адреса, отримана при розгортанні контракту, виглядає випадковою, оскільки пов'язана з nonce. Але в деяких випадках нам потрібно зробити висновки про адресу контракту через інформацію про угоду та пов'язані дані, наприклад, визначити права на угоду або отримати адресу пулу.
Uniswap використовує метод CREATE2 для створення контрактів, додаючи параметр salt, що робить згенеровану адресу передбачуваною. Логіка обчислення нової адреси: hash("0xFF", адреса творця, salt, initcode).
Розумне використання функцій зворотного виклику
Контракти в Solidity можуть викликати один одного. У деяких випадках викликати методи B з A і повернення до A з методу B є дуже корисним.
У Uniswap, під час виклику метода swap контракту UniswapV3Pool для торгівлі, він викликає swapCallback, передаючи токен, який насправді потрібен для цієї угоди. Викликач має перевести необхідний токен в UniswapV3Pool в колбеку, а не розділяти метод swap на дві частини. Це забезпечує безпеку метода swap і його повне виконання без громіздкого ведення записів змінних.
Використання винятків для передачі інформації, реалізація оцінки угод за допомогою try catch
У контракті Quoter Uniswap метод swap UniswapV3Pool обгорнутий у конструкцію try catch. Це робиться для моделювання методу swap, щоб оцінити необхідні токени для торгівлі, але під час оцінки фактичний обмін токенів не відбувається, тому виникає помилка.
Uniswap кидає спеціальну помилку в функції зворотного виклику торгівлі, а потім ловить цю помилку, щоб витягти необхідну інформацію з повідомлення про помилку. Цей підхід здається хитрим, але він дуже практичний, оскільки не вимагає переробки методу swap для оцінки торгових потреб, а логіка є більш простою.
Використання великих чисел для вирішення проблеми точності
У коді Uniswap є безліч обчислювальної логіки, наприклад, обчислення токена, що обмінюється, на основі поточної ціни та ліквідності. Щоб уникнути втрати точності при діленні, в обчислювальному процесі часто використовують операцію "<< FixedPoint96.RESOLUTION", тобто зсув вліво на 96 біт, що еквівалентно множенню на 2^96.
Після зсуву вліво, виконуючи операцію ділення, можна гарантувати точність за умов, що нормальні угоди не призводять до переповнення. Хоча теоретично все ще може бути втрата точності найменшої одиниці, це прийнятно.
Розрахунок прибутку за допомогою Share
Uniswap потрібно зафіксувати дохід від комісій ліквіднісного провайдера LP( ). Щоб уникнути витрат на газ під час запису комісій для кожного LP під час кожної угоди, Uniswap використовує хитрий метод.
Структура Position містить feeGrowthInside0LastX128 та feeGrowthInside1LastX128, які фіксують, які комісії повинні були отримати кожен ліквідність під час останнього виведення комісії. Достатньо зафіксувати загальну комісію та комісії, які повинні бути розподілені між кожною ліквідністю, а комісії, які можна вивести під час витягування LP, розраховуються відповідно до утримуваної ліквідності.
Стратегія отримання інформації з блокчейну
Не вся інформація повинна отримуватися з блокчейну. Зберігання в блокчейні відносно дороге, багато інформації можна зберігати в звичайних базах даних і періодично синхронізувати з блокчейном.
Такі речі, як список торгових пулів, інформація про торгові пули тощо можуть зберігатися в звичайній базі даних, без необхідності в реальному виклику RPC-інтерфейсу ланцюга або вузлів. Звичайно, ключові угоди все ще здійснюються в ланцюзі.
Розподіл контрактів та використання стандартних контрактів
Проект може містити кілька фактично розгорнутими контрактами. Навіть якщо фактично розгорнутий лише один контракт, код може бути розділений на кілька контрактів для обслуговування шляхом наслідування.
Наприклад, контракт NonfungiblePositionManager Uniswap успадковує кілька контрактів. Використання контракту ERC721 від OpenZeppelin полегшує управління позиціями через NFT та підвищує ефективність розробки.
Висновок
Практика є найкращим методом навчання. Спробуйте реалізувати просту версію децентралізованої біржі, щоб глибше зрозуміти реалізацію коду Uniswap і дізнатися більше про знання, які можна застосувати в реальних проектах. Якщо вас цікавить розробка проектів Web3 та DeFi, можна звернутися до відповідних практичних курсів, поступово завершуючи просту версію біржі.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Розкриття коду Uniswap: 7 великих порад щодо розробки контрактів для підтримки новачків у DeFi
Поради з розробки контрактів, отримані з коду Uniswap
Нещодавно, під час написання посібника з розробки децентралізованих бірж, я звертався до коду реалізації Uniswap V3 і дізнався багато цінних знань. Як розробник, який вперше намагається розробити контракти Defi, ці навички будуть дуже корисними для новачків, які хочуть навчитися розробці контрактів.
Прогнозована адреса розгортання контракту
Зазвичай адреса, отримана при розгортанні контракту, виглядає випадковою, оскільки пов'язана з nonce. Але в деяких випадках нам потрібно зробити висновки про адресу контракту через інформацію про угоду та пов'язані дані, наприклад, визначити права на угоду або отримати адресу пулу.
Uniswap використовує метод CREATE2 для створення контрактів, додаючи параметр salt, що робить згенеровану адресу передбачуваною. Логіка обчислення нової адреси: hash("0xFF", адреса творця, salt, initcode).
Розумне використання функцій зворотного виклику
Контракти в Solidity можуть викликати один одного. У деяких випадках викликати методи B з A і повернення до A з методу B є дуже корисним.
У Uniswap, під час виклику метода swap контракту UniswapV3Pool для торгівлі, він викликає swapCallback, передаючи токен, який насправді потрібен для цієї угоди. Викликач має перевести необхідний токен в UniswapV3Pool в колбеку, а не розділяти метод swap на дві частини. Це забезпечує безпеку метода swap і його повне виконання без громіздкого ведення записів змінних.
Використання винятків для передачі інформації, реалізація оцінки угод за допомогою try catch
У контракті Quoter Uniswap метод swap UniswapV3Pool обгорнутий у конструкцію try catch. Це робиться для моделювання методу swap, щоб оцінити необхідні токени для торгівлі, але під час оцінки фактичний обмін токенів не відбувається, тому виникає помилка.
Uniswap кидає спеціальну помилку в функції зворотного виклику торгівлі, а потім ловить цю помилку, щоб витягти необхідну інформацію з повідомлення про помилку. Цей підхід здається хитрим, але він дуже практичний, оскільки не вимагає переробки методу swap для оцінки торгових потреб, а логіка є більш простою.
Використання великих чисел для вирішення проблеми точності
У коді Uniswap є безліч обчислювальної логіки, наприклад, обчислення токена, що обмінюється, на основі поточної ціни та ліквідності. Щоб уникнути втрати точності при діленні, в обчислювальному процесі часто використовують операцію "<< FixedPoint96.RESOLUTION", тобто зсув вліво на 96 біт, що еквівалентно множенню на 2^96.
Після зсуву вліво, виконуючи операцію ділення, можна гарантувати точність за умов, що нормальні угоди не призводять до переповнення. Хоча теоретично все ще може бути втрата точності найменшої одиниці, це прийнятно.
Розрахунок прибутку за допомогою Share
Uniswap потрібно зафіксувати дохід від комісій ліквіднісного провайдера LP( ). Щоб уникнути витрат на газ під час запису комісій для кожного LP під час кожної угоди, Uniswap використовує хитрий метод.
Структура Position містить feeGrowthInside0LastX128 та feeGrowthInside1LastX128, які фіксують, які комісії повинні були отримати кожен ліквідність під час останнього виведення комісії. Достатньо зафіксувати загальну комісію та комісії, які повинні бути розподілені між кожною ліквідністю, а комісії, які можна вивести під час витягування LP, розраховуються відповідно до утримуваної ліквідності.
Стратегія отримання інформації з блокчейну
Не вся інформація повинна отримуватися з блокчейну. Зберігання в блокчейні відносно дороге, багато інформації можна зберігати в звичайних базах даних і періодично синхронізувати з блокчейном.
Такі речі, як список торгових пулів, інформація про торгові пули тощо можуть зберігатися в звичайній базі даних, без необхідності в реальному виклику RPC-інтерфейсу ланцюга або вузлів. Звичайно, ключові угоди все ще здійснюються в ланцюзі.
Розподіл контрактів та використання стандартних контрактів
Проект може містити кілька фактично розгорнутими контрактами. Навіть якщо фактично розгорнутий лише один контракт, код може бути розділений на кілька контрактів для обслуговування шляхом наслідування.
Наприклад, контракт NonfungiblePositionManager Uniswap успадковує кілька контрактів. Використання контракту ERC721 від OpenZeppelin полегшує управління позиціями через NFT та підвищує ефективність розробки.
Висновок
Практика є найкращим методом навчання. Спробуйте реалізувати просту версію децентралізованої біржі, щоб глибше зрозуміти реалізацію коду Uniswap і дізнатися більше про знання, які можна застосувати в реальних проектах. Якщо вас цікавить розробка проектів Web3 та DeFi, можна звернутися до відповідних практичних курсів, поступово завершуючи просту версію біржі.