Изученные при чтении кода Uniswap контракты и разработческие навыки гораздо интереснее учебников

Недавно, занимаясь разработкой учебных материалов по децентрализованным биржам, я глубоко исследовал реализацию Uniswap V3 и обнаружил действительно гениальные подходы. Ранее я писал только простые NFT-контракты, а в этот раз впервые всерьез взялся за DeFi-контракты и нашел много полезных вещей, которыми хочу поделиться с теми, кто хочет изучать Uniswap.

Начну с самого удивительного — адрес контракта можно предсказать?

Обычно адрес развернутого контракта кажется случайным, но Uniswap использует умный способ. Он через параметр salt при создании контракта использует команду CREATE2, что позволяет предсказать адрес. Конкретный пример — «pool = address(new UniswapV3Pool{salt: keccak256(abi.encode(token0, token1, fee))}());». Такой код. Благодаря этому, зная торговую пару и комиссию, можно вычислить адрес пула, не развертывая контракт. Это особенно полезно для проверки прав доступа или быстрого поиска пула.

Дизайн callback-функции тоже очень продуманный.

Когда вызываешь метод swap для обмена, он вызывает функцию swapCallback, передавая туда рассчитанное количество токенов, которые нужно перевести, а в callback ты переводишь токены. Такой подход обеспечивает, что вся логика сделки выполняется целиком, без разбивки на несколько шагов или сложных переменных для безопасности. Проще говоря, A вызывает B, а B в свою очередь вызывает A, образуя цикл.

Метод оценки сделки тоже очень хитрый — используют исключения для передачи информации.

Поскольку при оценки сделки фактически не происходит обмен токенами, возникает ошибка. В Uniswap реализовано так, что в callback выбрасывается специальная ошибка, которую ловит try-catch, и из сообщения ошибки извлекаются нужные данные. Это кажется немного грубым, но очень удобно — без особых изменений метода swap можно реализовать функцию оценки.

Решение проблем с точностью тоже заслуживает внимания.

При расчетах обмена токенов деление напрямую ведет к потере точности. Uniswap делает так: сначала сдвигает число влево на 96 бит (умножает на 2^96), затем делит, и в конце возвращает результат, делая обратное преобразование. Таким образом, в диапазоне uint256 сохраняется точность и избегается переполнение. В коде это реализовано через переменные sqrtRatioAX96 и sqrtRatioBX96 — выглядит сложно, но логика ясна.

Способ расчета дохода от комиссий тоже очень умный.

Вместо того, чтобы при каждой сделке записывать комиссию для каждого LP (что дорого по Gas), лучше хранить общую сумму комиссий и долю, которая должна быть распределена каждому. При выводе LP просто умножает свою ликвидность на историческую сумму комиссий на акцию — как дивиденды по акциям. Такой способ учета долей широко применяется во многих проектах.

Также важно, что не вся информация должна храниться на блокчейне.

Списки пулов, базовые сведения — всё это можно держать в традиционных базах данных и периодически синхронизировать с блокчейном, не вызывая RPC постоянно. Многие блокчейн-сервисы сейчас предоставляют расширенные API, позволяющие получать данные быстрее и дешевле — это тот же принцип.

И наконец, организация кода.

Большие проекты обычно делят контракт на части для удобства поддержки, и Uniswap тоже использует наследование. Также важно использовать стандартные решения, например, OpenZeppelin ERC721 для управления позициями — это повышает эффективность разработки и качество кода.

Честно говоря, читать статьи полезно, но лучше самому попробовать реализовать. Создавая простую децентрализованную биржу, ты по-настоящему поймешь, зачем Uniswap так спроектирован. Курсы типа WTF-DApp основаны на этом подходе — шаг за шагом ведут к созданию практического проекта по Uniswap, что точно поможет в разработке контрактов.