Недавно, изучая процесс разработки децентрализованных бирж, я обнаружил некоторые интересные приемы разработки контрактов. Эти приемы основаны на исследовании кода известного DEX и должны быть полезны новичкам, желающим начать разработку смарт-контрактов.
Предсказуемый адрес контракта
Адреса, полученные при развертывании контрактов, обычно выглядят случайными и трудно предсказуемыми. Однако в некоторых ситуациях нам нужно вывести адрес контракта на основе информации о сделках, что полезно для оценки прав на сделки или получения адреса пула и т.д.
Можно создать контракт с помощью метода CREATE2, добавив параметр salt, что делает адрес предсказуемым. Логика вычисления нового адреса: hash("0xFF", адрес создателя, salt, initcode).
Умное использование функций обратного вызова
В некоторых сценариях вызов метода контракта A из контракта B, а затем обратный вызов метода A очень полезен. Например, во время сделки контракт пула будет вызывать swapCallback, передавая фактическое количество необходимых токенов, а вызывающая сторона будет переводить токены в обратном вызове. Это обеспечивает целостность и безопасность всей логики сделки.
Использование исключений для передачи информации
При оценке сделки можно обернуть выполнение метода swap в блок try-catch. Поскольку оценка не приведет к фактическому обмену токенов, будет выдана ошибка. Можно выбрасывать специфическую ошибку в обратном вызове, а затем поймать её и извлечь необходимые данные из сообщения об ошибке. Таким образом, нет необходимости специально модифицировать метод swap для оценки, логика становится более простой.
Решение проблемы точности больших чисел
При вычислении цен и ликвидности, чтобы избежать потери точности при делении, можно сначала сдвинуть влево на 96 бит (, что эквивалентно умножению на 2^96), а затем проводить расчеты. Это позволяет обеспечить точность без переполнения. Хотя теоретически всё равно будет минимальная потеря точности, это приемлемо в практическом применении.
Вычисление доходов в режиме Share
При учете доходов от сборов LP нельзя фиксировать каждую сделку для каждого LP, так как это потребует больших затрат газа. Можно зафиксировать только общие сборы и сборы, причитающиеся на единицу ликвидности, а при выводе LP затем рассчитать сумму, которую можно вывести, исходя из удерживаемой ликвидности. Это похоже на принцип дивидендов по акциям.
Хранение данных вне цепи
Не вся информация должна быть записана в блокчейне или получена из него. Списки торговых пулов, информация о пулах и т.д. могут храниться в традиционных базах данных и периодически синхронизироваться с блокчейном. Это может повысить эффективность доступа и снизить затраты. Конечно, ключевые сделки по-прежнему должны осуществляться в блокчейне.
Разделение и повторное использование контрактов
Можно разделить проект на несколько фактических развернутых контрактов, или разделить код на несколько контрактов для поддержки с помощью наследования. Также следует эффективно использовать существующие стандартные контракты, такие как ERC721 и т.д., чтобы повысить эффективность разработки.
Смотреть на теорию — это не так полезно, как практиковаться на практике. Попытка реализовать простую версию DEX поможет вам лучше понять различные техники разработки контрактов. Надеюсь, эти небольшие советы помогут вам на вашем пути разработки смарт-контрактов.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
12 Лайков
Награда
12
8
Поделиться
комментарий
0/400
CryptoGoldmine
· 11ч назад
Контракт является ключевым, стабильность приносит ROI
Посмотреть ОригиналОтветить0
DecentralizedElder
· 12ч назад
Все время застреваю на изучении Solidity
Посмотреть ОригиналОтветить0
OnchainDetective
· 12ч назад
Правда неплохо, сначала кодируем, потом скачок!
Посмотреть ОригиналОтветить0
HalfBuddhaMoney
· 12ч назад
С помощью этих приемов можно уверенно зарабатывать на DEX.
7 контрактов разработают удивительные технологии, которые помогут вам стать мастером DEX.
Умения и хитрости разработки контрактов
Недавно, изучая процесс разработки децентрализованных бирж, я обнаружил некоторые интересные приемы разработки контрактов. Эти приемы основаны на исследовании кода известного DEX и должны быть полезны новичкам, желающим начать разработку смарт-контрактов.
Предсказуемый адрес контракта
Адреса, полученные при развертывании контрактов, обычно выглядят случайными и трудно предсказуемыми. Однако в некоторых ситуациях нам нужно вывести адрес контракта на основе информации о сделках, что полезно для оценки прав на сделки или получения адреса пула и т.д.
Можно создать контракт с помощью метода CREATE2, добавив параметр salt, что делает адрес предсказуемым. Логика вычисления нового адреса: hash("0xFF", адрес создателя, salt, initcode).
Умное использование функций обратного вызова
В некоторых сценариях вызов метода контракта A из контракта B, а затем обратный вызов метода A очень полезен. Например, во время сделки контракт пула будет вызывать swapCallback, передавая фактическое количество необходимых токенов, а вызывающая сторона будет переводить токены в обратном вызове. Это обеспечивает целостность и безопасность всей логики сделки.
Использование исключений для передачи информации
При оценке сделки можно обернуть выполнение метода swap в блок try-catch. Поскольку оценка не приведет к фактическому обмену токенов, будет выдана ошибка. Можно выбрасывать специфическую ошибку в обратном вызове, а затем поймать её и извлечь необходимые данные из сообщения об ошибке. Таким образом, нет необходимости специально модифицировать метод swap для оценки, логика становится более простой.
Решение проблемы точности больших чисел
При вычислении цен и ликвидности, чтобы избежать потери точности при делении, можно сначала сдвинуть влево на 96 бит (, что эквивалентно умножению на 2^96), а затем проводить расчеты. Это позволяет обеспечить точность без переполнения. Хотя теоретически всё равно будет минимальная потеря точности, это приемлемо в практическом применении.
Вычисление доходов в режиме Share
При учете доходов от сборов LP нельзя фиксировать каждую сделку для каждого LP, так как это потребует больших затрат газа. Можно зафиксировать только общие сборы и сборы, причитающиеся на единицу ликвидности, а при выводе LP затем рассчитать сумму, которую можно вывести, исходя из удерживаемой ликвидности. Это похоже на принцип дивидендов по акциям.
Хранение данных вне цепи
Не вся информация должна быть записана в блокчейне или получена из него. Списки торговых пулов, информация о пулах и т.д. могут храниться в традиционных базах данных и периодически синхронизироваться с блокчейном. Это может повысить эффективность доступа и снизить затраты. Конечно, ключевые сделки по-прежнему должны осуществляться в блокчейне.
Разделение и повторное использование контрактов
Можно разделить проект на несколько фактических развернутых контрактов, или разделить код на несколько контрактов для поддержки с помощью наследования. Также следует эффективно использовать существующие стандартные контракты, такие как ERC721 и т.д., чтобы повысить эффективность разработки.
Смотреть на теорию — это не так полезно, как практиковаться на практике. Попытка реализовать простую версию DEX поможет вам лучше понять различные техники разработки контрактов. Надеюсь, эти небольшие советы помогут вам на вашем пути разработки смарт-контрактов.