Поділ досвідом розробки контрактів

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

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

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

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

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

У деяких випадках виклик методу контракту B з контракту A, а потім зворотний виклик методу A є дуже корисним.

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

Використання винятків для передачі інформації

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

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

У ситуаціях, пов'язаних з обчисленнями, щоб уникнути втрати точності при діленні, можна спочатку зсунути вліво на 96 біт (, що еквівалентно множенню на 2^96), а потім виконати операцію ділення. Таким чином, можна забезпечити точність без переповнення.

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

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

Зберігання допоміжної інформації поза ланцюгом

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

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

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

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