Поділитися маленькими порадами з розробки контрактів
Нещодавно, беручи участь у проекті розробки децентралізованої біржі, я звернувся до коду реалізації відомого DEX і навчився багатьом корисним технікам розробки контрактів. Як розробник, який раніше в основному займався розробкою NFT контрактів, це моя перша спроба розробки Defi контрактів. Тут я поділюсь деякими маленькими порадами, які можуть бути корисними для новачків у розробці.
Прогнозована адреса контракту
Зазвичай адреса, отримана при розгортанні контракту, виглядає випадковою, оскільки вона пов'язана з nonce. Але в деяких випадках нам потрібно вивести адресу контракту за інформацією про транзакцію, що є корисним при перевірці прав на транзакцію або отриманні адреси пулу.
Один із способів - це використання CREATE2 для створення контракту, шляхом додавання параметра salt, що робить згенеровану адресу передбачуваною. Формула обчислення нової адреси є:
Нова адреса = hash("0xFF", адреса творця, сіль, initcode)
Розумне використання функцій зворотного виклику
У Solidity контракти можуть взаємно викликати один одного. У деяких сценаріях метод A викликає метод B, а B у викликаному методі викликає A, ця модель є дуже корисною.
Наприклад, під час торгівлі на певному DEX, метод swap контракту пулу викликає swapCallback, передаючи фактичну кількість токенів, які потрібні. Викликаюча сторона повинна передати токени в зворотному виклику, а не розділяти swap на кілька викликів. Це забезпечує цілісність та безпеку методу swap.
Використання виключень для передачі інформації
У коді певного DEX використовується блок try-catch для обгортання методу swap контракту пулу, щоб моделювати торгівлю та оцінювати необхідні токени. Оскільки під час оцінки токени фактично не обмінюються, виникає помилка. Викинувши спеціальну помилку в зворотному виклику, а потім перехоплюючи та розбираючи інформацію про помилку, можна отримати оцінений результат.
Ця техніка дозволяє уникнути спеціальних модифікацій методу свопу для оцінки попиту, зберігаючи логіку простою.
Проблема точності обробки великих чисел
При обчисленні цін та ліквідності, щоб уникнути втрати точності при діленні, можна спочатку зсунути вліво на 96 біт (, що еквівалентно множенню на 2^96), а потім виконати обчислення. Таким чином, при нормальній торгівлі, без переповнення, можна забезпечити точність.
Розрахунок доходу в режимі Share
При обліку доходу від комісії LP не слід фіксувати комісію для кожного LP при кожній транзакції, оскільки це споживатиме велику кількість Gas. Одним із рішень є облік загальної комісії та комісії, що підлягає розподілу на одиницю ліквідності. Коли LP здійснює вилучення, комісія, яку можна вилучити, обчислюється на основі утримуваної ліквідності, подібно до дивідендів акцій.
Поєднання даних на ланцюгу та поза ним
Не вся інформація має бути записана в блокчейн або отримана з нього. Наприклад, списки торгових пулів, інформація про пул можна зберігати в звичайній базі даних, регулярно синхронізуючи з блокчейном. Це може підвищити продуктивність і ефективність. Звичайно, ключові транзакції все ще повинні проводитися в блокчейні.
Розділення та повторне використання контрактів
Великі проекти можуть містити кілька контрактів, які насправді розгорнуті. Навіть якщо розгорнуто лише один контракт, його можна розділити на кілька контрактів для полегшення обслуговування шляхом успадкування. Одночасно, навчання використання існуючих стандартних контрактів, таких як ERC721, може підвищити ефективність розробки.
Практика — найкращий спосіб навчання. Реалізувавши просту версію DEX, можна глибше зрозуміти код реалізації деяких складних проектів та дізнатися більше про знання, що застосовуються в реальних проектах. Сподіваюся, ці маленькі поради стануть в нагоді новачкам, які хочуть навчитися розробці контрактів.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
DEX контракт розробки обов'язкові сім основних порад Новачок обов'язково до прочитання
Поділитися маленькими порадами з розробки контрактів
Нещодавно, беручи участь у проекті розробки децентралізованої біржі, я звернувся до коду реалізації відомого DEX і навчився багатьом корисним технікам розробки контрактів. Як розробник, який раніше в основному займався розробкою NFT контрактів, це моя перша спроба розробки Defi контрактів. Тут я поділюсь деякими маленькими порадами, які можуть бути корисними для новачків у розробці.
Прогнозована адреса контракту
Зазвичай адреса, отримана при розгортанні контракту, виглядає випадковою, оскільки вона пов'язана з nonce. Але в деяких випадках нам потрібно вивести адресу контракту за інформацією про транзакцію, що є корисним при перевірці прав на транзакцію або отриманні адреси пулу.
Один із способів - це використання CREATE2 для створення контракту, шляхом додавання параметра salt, що робить згенеровану адресу передбачуваною. Формула обчислення нової адреси є:
Нова адреса = hash("0xFF", адреса творця, сіль, initcode)
Розумне використання функцій зворотного виклику
У Solidity контракти можуть взаємно викликати один одного. У деяких сценаріях метод A викликає метод B, а B у викликаному методі викликає A, ця модель є дуже корисною.
Наприклад, під час торгівлі на певному DEX, метод swap контракту пулу викликає swapCallback, передаючи фактичну кількість токенів, які потрібні. Викликаюча сторона повинна передати токени в зворотному виклику, а не розділяти swap на кілька викликів. Це забезпечує цілісність та безпеку методу swap.
Використання виключень для передачі інформації
У коді певного DEX використовується блок try-catch для обгортання методу swap контракту пулу, щоб моделювати торгівлю та оцінювати необхідні токени. Оскільки під час оцінки токени фактично не обмінюються, виникає помилка. Викинувши спеціальну помилку в зворотному виклику, а потім перехоплюючи та розбираючи інформацію про помилку, можна отримати оцінений результат.
Ця техніка дозволяє уникнути спеціальних модифікацій методу свопу для оцінки попиту, зберігаючи логіку простою.
Проблема точності обробки великих чисел
При обчисленні цін та ліквідності, щоб уникнути втрати точності при діленні, можна спочатку зсунути вліво на 96 біт (, що еквівалентно множенню на 2^96), а потім виконати обчислення. Таким чином, при нормальній торгівлі, без переповнення, можна забезпечити точність.
Розрахунок доходу в режимі Share
При обліку доходу від комісії LP не слід фіксувати комісію для кожного LP при кожній транзакції, оскільки це споживатиме велику кількість Gas. Одним із рішень є облік загальної комісії та комісії, що підлягає розподілу на одиницю ліквідності. Коли LP здійснює вилучення, комісія, яку можна вилучити, обчислюється на основі утримуваної ліквідності, подібно до дивідендів акцій.
Поєднання даних на ланцюгу та поза ним
Не вся інформація має бути записана в блокчейн або отримана з нього. Наприклад, списки торгових пулів, інформація про пул можна зберігати в звичайній базі даних, регулярно синхронізуючи з блокчейном. Це може підвищити продуктивність і ефективність. Звичайно, ключові транзакції все ще повинні проводитися в блокчейні.
Розділення та повторне використання контрактів
Великі проекти можуть містити кілька контрактів, які насправді розгорнуті. Навіть якщо розгорнуто лише один контракт, його можна розділити на кілька контрактів для полегшення обслуговування шляхом успадкування. Одночасно, навчання використання існуючих стандартних контрактів, таких як ERC721, може підвищити ефективність розробки.
Практика — найкращий спосіб навчання. Реалізувавши просту версію DEX, можна глибше зрозуміти код реалізації деяких складних проектів та дізнатися більше про знання, що застосовуються в реальних проектах. Сподіваюся, ці маленькі поради стануть в нагоді новачкам, які хочуть навчитися розробці контрактів.