Поради щодо розробки контрактів: цінний досвід з коду Uniswap

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

Давайте подивимося на ці корисні маленькі поради, деякі з яких можна вважати справжніми хитрощами.

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

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

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

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

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

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

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

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

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

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

Обчислення доходу за допомогою Share

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

Зберігання частини інформації поза ланцюгом

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

Розумний розподіл контракту, використання існуючих стандартів

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

Узагальнення

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