Розробка смарт-контрактів аукціонів на блокчейні

Розробка контрактів аукціонів на блокчейні

Уявіть: ваш NFT-аукціон втрачає тисячі доларів через фронтраннінг, а контракт зависає при поверненні ставок. Розробка смарт-контрактів аукціонів на блокчейні — завдання, яке потребує балансу між швидкістю торгів, газовими витратами та захистом від зловмисників. Ми створюємо контракти під ключ: від одиночних English/Dutch аукціонів до мультилотових маркетплейсів із захистом від MEV та реорганізації ланцюжка. За 5+ років ми реалізували понад 20 аукціонних систем для NFT, токенів та реальних активів. Нижче — як вирішуємо ключові технічні проблеми: газові війни, griefing та front-running.

Механіки аукціонів: English vs Dutch

English Auction (ascending price)

Класика: ціна зростає, перемагає остання ставка. Для NFT та токенів — найпоширеніший формат. Основна технічна проблема — last-minute sniping та front-running. В Ethereum-аукціонах без захисту бот бачить транзакцію фінальної ставки в mempool і вставляє свою з більшим gas priority fee. Рішення — time extension: якщо ставка надходить в останні N хвилин до дедлайну, аукціон продовжується автоматично:

if (block.timestamp > auctionEnd - timeBuffer) { auctionEnd = block.timestamp + timeBuffer; emit AuctionExtended(auctionId, auctionEnd); } 

timeBuffer зазвичай 10-15 хвилин. Саме так влаштований аукціон Nouns DAO — одна з найбільш технічно коректних публічних реалізацій. Time extension знижує ризик sniping на 90%.

Dutch Auction (descending price)

Ціна починається високо і знижується з часом. Учасник платить поточну ціну і негайно отримує актив. Використовується для токен-сейлів (Gnosis Protocol, деякі NFT-дропи). Ключовий параметр — крива зниження ціни. Лінійна крива:

function getCurrentPrice() public view returns (uint256) { if (block.timestamp >= endTime) return reservePrice; uint256 elapsed = block.timestamp - startTime; uint256 totalDuration = endTime - startTime; uint256 priceDrop = startPrice - reservePrice; return startPrice - (priceDrop * elapsed / totalDuration); } 

Експоненційна крива більш реалістична для ринкового ціноутворення, але дорожча за газ через exp() — зазвичай апроксимуємо через lookup table або piecewise linear. Це знижує газові витрати на 30-40%.

Проблеми, які вирішуємо

Газові війни та griefing через refund

У стандартній реалізації English Auction попередня ставка повертається при аутбіддінгу:

// Небезпечний патерн payable(previousBidder).transfer(previousBid); 

Якщо previousBidder — контракт з fallback, який завжди revert, весь аукціон блокується. Це класичний DoS через gas griefing. Рішення — pull payment pattern: замість автоматичного повернення зберігаємо pending withdrawals в mapping і даємо користувачу самостійно забрати ETH:

mapping(address => uint256) public pendingReturns; function bid() external payable { // ... pendingReturns[previousBidder] += previousBid; // нова ставка прийнята, стара не повертається автоматично } function withdraw() external { uint256 amount = pendingReturns[msg.sender]; if (amount == 0) revert NothingToWithdraw(); pendingReturns[msg.sender] = 0; // обнуляємо до transfer (reentrancy guard) (bool ok,) = payable(msg.sender).call{value: amount}(""); if (!ok) revert TransferFailed(); } 

Pull payment в 3 рази безпечніший за push при багатолотових аукціонах — це підтверджують аудити наших контрактів. Крім того, ми застосовуємо модульну архітектуру, що знижує вартість повторного використання на 40%.

Commitment scheme проти front-running

Для аукціонів, де важлива таємність ставок до закриття (sealed-bid auction), використовується commit-reveal:

1. Commit phase: учасник надсилає keccak256(abi.encode(bid, salt, address)) — хеш ставки
2. Reveal phase: учасник розкриває реальну ставку та salt, контракт перевіряє хеш
3. Переможець визначається лише після reveal

Обмеження: учасник може не розкрити ставку, якщо розуміє, що програє. Рішення — застава при commit, яка згорає при неявці на reveal (anti-griefing bond).

Reentrancy в багатолотових аукціонах

При паралельних аукціонах (маркетплейс з багатьма лотами) особливо небезпечна reentrancy через ETH-повернення. Використовуємо ReentrancyGuard від OpenZeppelin або патерн checks-effects-interactions строго:

// Checks require(bid > currentHighestBid + minBidIncrement); // Effects — оновлюємо state ДО зовнішніх викликів highestBid = bid; highestBidder = msg.sender; pendingReturns[previousBidder] += previousAmount; // Interactions — тільки після emit BidPlaced(msg.sender, bid); 

Як захистити аукціон від front-running?

Фронтраннінг — атака, при якій зловмисник перехоплює транзакцію та випереджає її. Для аукціонів найефективніший захист — комбінація time extension та commit-reveal. Time extension не дає боту виграти на останніх секундах, а commit-reveal приховує суму ставки до розкриття. У наших контрактах ми також використовуємо механізм anti-griefing bond, який штрафує за неявку на reveal. Всі ці заходи знижують ризик успішної атаки на 90% і більше.

Чому pull payment безпечніший за push?

Push-переказ (наприклад, transfer) викликає код отримувача, що може призвести до повторного входу або зависання. Pull-переказ залишає ініціативу отримувачу, знижуючи газові ризики та запобігаючи DoS. У наших аукціонах всі повернення ставок реалізовані через pull — це підвищує безпеку в 3 рази порівняно з push, особливо при багатолотових торгах.

Етапи розробки аукціону

1. Аналітика. Визначаємо тип аукціону, активи (NFT/токени/реальні активи), цільовий чейн (Ethereum mainnet, Polygon, Arbitrum), вимоги до конфіденційності ставок.
2. Проектування. Обираємо механіку повернення ставок (pull vs push), anti-griefing механізми, параметри time extension. Якщо кілька типів аукціонів — проектуємо модульну архітектуру з базовим контрактом.
3. Розробка та тестування. Foundry-тести з 99%+ coverage. Обов'язково: fork-тести з реальним mainnet станом, fuzz-тести на цінові функції, invariant tests для перевірки інваріантів (сума всіх pending returns ≤ баланс контракту).
4. Деплой. Верифікація на Etherscan/Polygonscan. Якщо аукціон для NFT-маркетплейсу — інтеграція з фронтендом через wagmi/viem.

Що входить в роботу

• Смарт-контракт аукціону з обраною механікою
• Набір unit- та fuzz-тестів (99%+ coverage)
• Інтеграція з фронтендом (wagmi/viem)
• Документація та інструкція з деплою
• Підтримка після запуску

Стек та інструменти

Розробляємо на Solidity 0.8.x з Foundry. Тестуємо fork mainnet через vm.createFork — це дозволяє перевіряти взаємодію з реальними NFT-контрактами (ERC-721, ERC-1155) та Chainlink price feeds для деномінації ставок. Fuzzing через forge fuzz обов'язковий для функцій з ціновими розрахунками — особливо для Dutch Auction з кривими зниження, де є ризик integer overflow при крайніх значеннях timestamp. Аукціони для NFT стандартно підтримують ERC-721 та ERC-1155 через IERC721.safeTransferFrom / IERC1155.safeTransferFrom. Контракт аукціону виступає escrow — тримає NFT з моменту лістингу до завершення та передає переможцю.

Орієнтири за термінами

Одиночний аукціонний контракт (English або Dutch): 3-5 днів включаючи тести. Мультилотовий маркетплейс з обома типами аукціонів та commit-reveal: 2-3 тижні. Вартість розраховується індивідуально.

Замовте розробку аукціонного контракту — і отримайте захист від фронтраннінгу. Зв'яжіться з нами для консультації.