Що повинні знати розробники Web3: цінний досвід, отриманий з контрактів Uniswap
Нещодавно, коли я писав посібник з розробки децентралізованої біржі, я глибоко вивчив кодове впровадження Uniswap V3 і отримав багато корисної інформації. Як новачок, який тільки починає займатися розробкою Defi-контрактів, ці поради безсумнівно стали для мене просвітленням. Впевнений, що цей досвід також буде корисним для інших, хто хоче почати розробку смарт-контрактів.
Хитрощі для прогнозування адреси контракту
Зазвичай, адреса, що отримується після розгортання контракту, здається випадковою і важко передбачуваною. Але в Uniswap ми можемо вивести адресу контракту через торгову пару та відповідну інформацію. Це дуже корисно в таких ситуаціях, як визначення прав на торгівлю або отримання адреси пулу.
Uniswap використовує метод CREATE2 для створення контракту, додаючи параметр "salt", що робить згенеровану адресу передбачуваною. Конкретна логіка генерування адреси: нова адреса = hash("0xFF", адреса творця, salt, initcode).
Розумне використання функцій зворотного виклику
У деяких сценаріях взаємні виклики між контрактами є дуже корисними. Наприклад, метод A викликає B, а B у викликаному методі зворотно викликає A.
В Uniswap, коли викликається метод swap контракту UniswapV3Pool для здійснення угоди, він викликає swapCallback, передаючи обчислену фактичну кількість необхідних токенів. Викликач повинен під час зворотного виклику перевести необхідні токени в UniswapV3Pool. Такий дизайн забезпечує безпеку методу swap та логічну цілісність, не потребуючи складних записів змінних.
Передача інформації про аномалії, реалізація оцінки угоди через try-catch
У контракті Quoter Uniswap, метод swap UniswapV3Pool виконується за допомогою конструкції try-catch. Це робиться для симуляції обміну, щоб оцінити необхідні токени для угоди. Оскільки під час оцінки токени фактично не обмінюються, виникає помилка. Uniswap викидає спеціальну помилку у функції зворотного виклику угоди, а потім перехоплює цю помилку і розшифровує з неї необхідну інформацію.
Цей метод здається хитрим, але є дуже практичним. Не потрібно спеціально модифікувати метод swap для оцінки торгових потреб, логіка є більш простою.
Вирішення проблеми точності великими числами
У коді Uniswap залучено велику кількість обчислювальної логіки, такої як обчислення кількості токенів для обміну на основі поточної ціни та ліквідності. Щоб уникнути втрат точності через ділення, у процесі обчислення часто використовується операція "<< FixedPoint96.RESOLUTION", тобто зсув вліво на 96 біт, що відповідає множенню на 2^96. За умови, що нормальна торгівля не перевищує межі, ( зазвичай обчислюється за допомогою uint256 ), цей метод ефективно забезпечує точність.
Розрахунок доходу за механізмом Share
Uniswap потребує зафіксувати дохід від комісій LP( постачальника ліквідності ). Очевидно, що не можна окремо фіксувати комісії для кожного LP під час кожної угоди, це витрачатиме велику кількість Gas.
Рішення Uniswap полягає в визначенні feeGrowthInside0LastX128 та feeGrowthInside1LastX128 у структурі Position, які фіксують, яку комісію за кожну одиницю ліквідності слід отримати під час останнього виведення комісії з кожної позиції.
Цей метод вимагає лише записувати загальну комісію та комісію, яку слід розподілити на одиницю ліквідності. Коли LP здійснює вилучення, можна обчислити вилучену комісію на основі утримуваної ліквідності. Це подібно до того, як акціонери обчислюють поточний дохід для вилучення на основі історичного доходу на акцію компанії та доходу під час останнього вилучення.
Торгівля отриманням інформації в ланцюзі
Зберігання на ланцюгу відносно дороге, і не вся інформація повинна бути на ланцюгу або отримуватись з ланцюга. Наприклад, багато інтерфейсів, які викликає фронтенд-сайт Uniswap, є традиційними Web2 інтерфейсами.
Список торгових пулів, інформація про торгові пули тощо можуть зберігатися в звичайній базі даних, частина з них може потребувати періодичної синхронізації з блокчейном. Не потрібно в реальному часі викликати RPC-інтерфейси блокчейну або вузлів для отримання відповідних даних.
Звичайно, ключові угоди повинні здійснюватися в мережі. Зараз багато постачальників RPC для блокчейнів пропонують розширені інтерфейси, які дозволяють швидше і економніше отримувати певні дані.
Розділ контрактів та повторне використання стандартних контрактів
Проект може містити кілька фактичних розгорнутих контрактів. Навіть якщо фактично розгорнуто лише один контракт, ми можемо розділити код на кілька контрактів за допомогою успадкування.
Наприклад, контракт NonfungiblePositionManager Uniswap успадковує кілька контрактів. Крім того, контракт ERC721Permit безпосередньо використовує стандартний контракт ERC721 від OpenZeppelin. Це не тільки полегшує управління позиціями за допомогою NFT, але й дозволяє підвищити ефективність розробки, використовуючи наявні стандартні контракти.
Висновок
Практика приносить справжнє знання. Особиста участь у розробці спрощеної версії децентралізованої біржі дозволить вам глибше зрозуміти реалізацію коду Uniswap, а також дізнатися більше про важливі аспекти реальних проектів. Якщо ви зацікавлені в розробці проектів Web3 і DeFi, варто звернутися до відповідних практичних курсів, щоб крок за кроком створити спрощену версію біржі. Вірю, що це значно допоможе у вашому навчанні.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
6 лайків
Нагородити
6
4
Поділіться
Прокоментувати
0/400
AirdropHunter9000
· 08-04 14:09
Defi не є нічим іншим, як грою на падіння до нуля... ті, хто розуміє, знають.
Переглянути оригіналвідповісти на0
TokenAlchemist
· 08-04 14:09
лмао уявіть, що не знаєте про CREATE2 для детермінованих адрес... ngmi тбх
Переглянути оригіналвідповісти на0
RugpullAlertOfficer
· 08-04 14:08
Це точно навчальний посібник для новичка без базових знань.
Переглянути оригіналвідповісти на0
AllTalkLongTrader
· 08-04 14:02
Не дивитися на код, а дивитися на адресу: це лінощі чи висока майстерність?
7 великих порад щодо аналізу смартконтрактів Uniswap: обов'язкове читання для розробників Web3
Що повинні знати розробники Web3: цінний досвід, отриманий з контрактів Uniswap
Нещодавно, коли я писав посібник з розробки децентралізованої біржі, я глибоко вивчив кодове впровадження Uniswap V3 і отримав багато корисної інформації. Як новачок, який тільки починає займатися розробкою Defi-контрактів, ці поради безсумнівно стали для мене просвітленням. Впевнений, що цей досвід також буде корисним для інших, хто хоче почати розробку смарт-контрактів.
Хитрощі для прогнозування адреси контракту
Зазвичай, адреса, що отримується після розгортання контракту, здається випадковою і важко передбачуваною. Але в Uniswap ми можемо вивести адресу контракту через торгову пару та відповідну інформацію. Це дуже корисно в таких ситуаціях, як визначення прав на торгівлю або отримання адреси пулу.
Uniswap використовує метод CREATE2 для створення контракту, додаючи параметр "salt", що робить згенеровану адресу передбачуваною. Конкретна логіка генерування адреси: нова адреса = hash("0xFF", адреса творця, salt, initcode).
Розумне використання функцій зворотного виклику
У деяких сценаріях взаємні виклики між контрактами є дуже корисними. Наприклад, метод A викликає B, а B у викликаному методі зворотно викликає A.
В Uniswap, коли викликається метод swap контракту UniswapV3Pool для здійснення угоди, він викликає swapCallback, передаючи обчислену фактичну кількість необхідних токенів. Викликач повинен під час зворотного виклику перевести необхідні токени в UniswapV3Pool. Такий дизайн забезпечує безпеку методу swap та логічну цілісність, не потребуючи складних записів змінних.
Передача інформації про аномалії, реалізація оцінки угоди через try-catch
У контракті Quoter Uniswap, метод swap UniswapV3Pool виконується за допомогою конструкції try-catch. Це робиться для симуляції обміну, щоб оцінити необхідні токени для угоди. Оскільки під час оцінки токени фактично не обмінюються, виникає помилка. Uniswap викидає спеціальну помилку у функції зворотного виклику угоди, а потім перехоплює цю помилку і розшифровує з неї необхідну інформацію.
Цей метод здається хитрим, але є дуже практичним. Не потрібно спеціально модифікувати метод swap для оцінки торгових потреб, логіка є більш простою.
Вирішення проблеми точності великими числами
У коді Uniswap залучено велику кількість обчислювальної логіки, такої як обчислення кількості токенів для обміну на основі поточної ціни та ліквідності. Щоб уникнути втрат точності через ділення, у процесі обчислення часто використовується операція "<< FixedPoint96.RESOLUTION", тобто зсув вліво на 96 біт, що відповідає множенню на 2^96. За умови, що нормальна торгівля не перевищує межі, ( зазвичай обчислюється за допомогою uint256 ), цей метод ефективно забезпечує точність.
Розрахунок доходу за механізмом Share
Uniswap потребує зафіксувати дохід від комісій LP( постачальника ліквідності ). Очевидно, що не можна окремо фіксувати комісії для кожного LP під час кожної угоди, це витрачатиме велику кількість Gas.
Рішення Uniswap полягає в визначенні feeGrowthInside0LastX128 та feeGrowthInside1LastX128 у структурі Position, які фіксують, яку комісію за кожну одиницю ліквідності слід отримати під час останнього виведення комісії з кожної позиції.
Цей метод вимагає лише записувати загальну комісію та комісію, яку слід розподілити на одиницю ліквідності. Коли LP здійснює вилучення, можна обчислити вилучену комісію на основі утримуваної ліквідності. Це подібно до того, як акціонери обчислюють поточний дохід для вилучення на основі історичного доходу на акцію компанії та доходу під час останнього вилучення.
Торгівля отриманням інформації в ланцюзі
Зберігання на ланцюгу відносно дороге, і не вся інформація повинна бути на ланцюгу або отримуватись з ланцюга. Наприклад, багато інтерфейсів, які викликає фронтенд-сайт Uniswap, є традиційними Web2 інтерфейсами.
Список торгових пулів, інформація про торгові пули тощо можуть зберігатися в звичайній базі даних, частина з них може потребувати періодичної синхронізації з блокчейном. Не потрібно в реальному часі викликати RPC-інтерфейси блокчейну або вузлів для отримання відповідних даних.
Звичайно, ключові угоди повинні здійснюватися в мережі. Зараз багато постачальників RPC для блокчейнів пропонують розширені інтерфейси, які дозволяють швидше і економніше отримувати певні дані.
Розділ контрактів та повторне використання стандартних контрактів
Проект може містити кілька фактичних розгорнутих контрактів. Навіть якщо фактично розгорнуто лише один контракт, ми можемо розділити код на кілька контрактів за допомогою успадкування.
Наприклад, контракт NonfungiblePositionManager Uniswap успадковує кілька контрактів. Крім того, контракт ERC721Permit безпосередньо використовує стандартний контракт ERC721 від OpenZeppelin. Це не тільки полегшує управління позиціями за допомогою NFT, але й дозволяє підвищити ефективність розробки, використовуючи наявні стандартні контракти.
Висновок
Практика приносить справжнє знання. Особиста участь у розробці спрощеної версії децентралізованої біржі дозволить вам глибше зрозуміти реалізацію коду Uniswap, а також дізнатися більше про важливі аспекти реальних проектів. Якщо ви зацікавлені в розробці проектів Web3 і DeFi, варто звернутися до відповідних практичних курсів, щоб крок за кроком створити спрощену версію біржі. Вірю, що це значно допоможе у вашому навчанні.