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

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

Прогнозована адреса контракту

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Розумне використання позамережевих даних

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

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

Навчіться розподіляти контракти та використовувати стандартні контракти

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

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

Підсумок

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