Дивовижні хитрощі розробки контрактів

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

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

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

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

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

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

Передача інформації за допомогою винятків

Під час оцінки угод можна обгорнути виконання методу swap у блок try-catch. Оскільки оцінка не призведе до фактичного обміну токенів, буде виникати помилка. Можна вивести спеціальну помилку в зворотному виклику, а потім захопити та проаналізувати необхідні дані з повідомлення про помилку. Таким чином, не потрібно спеціально модифікувати метод swap для потреб оцінки, логіка буде більш зрозумілою.

Велике число вирішує проблему точності

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

Режим Share обчислення прибутку

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

Зберігання даних поза ланцюгом

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

Розподіл та повторне використання контракту

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

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