Розробка системи умовного платежу (conditional payment) на блокчейні

Розробка системи умовного платежу (conditional payment) на блокчейні

Ми розробляємо escrow-контракти, які блокують кошти та звільняють їх лише при виконанні заданих умов. Жодних посередників, повна прозорість on-chain. Маємо значний досвід у понад 50 проектах, і ми знаємо: головне — правильно вибрати механізм підтвердження та закласти захист від типових атак. Отримайте консультацію — ми допоможемо визначити оптимальну архітектуру для вашого сценарію.

Умовний платіж — це escrow на стероїдах. Кошти заблоковані в контракті та звільняються лише при виконанні заздалегідь визначених умов. Звучить просто, але диявол у деталях: хто верифікує виконання умови, що відбувається при спорі, як контракт знає про події off-chain. Саме останнє питання робить це завдання нетривіальним — блокчейн-контракт ізольований і не може сам перевірити «завдання виконано» або «KPI досягнуто». Йому потрібен оракул.

Чому conditional payment потребує оракула?

Контракт не має доступу до зовнішнього світу. Якщо умова — «товар доставлено» або «результат із сервера», то потрібне джерело даних, якому довіряють обидві сторони. Варіантів три: централізований арбітр, децентралізований оракул (Chainlink) або криптографічний підпис від заздалегідь узгодженого верифікатора. Кожен варіант диктує архітектуру та рівень довіри.

Як вибрати механізм підтвердження?

Арбітр (trusted third party)

Класичний escrow: покупець, продавець, арбітр. Arbirator — address із правом викликати release() або refund(). Найпростіша реалізація, підходить для більшості B2B випадків. Проблема: арбітр централізований. Якщо це адреса однієї людини — single point of failure та довіри. Рішення: арбітр — мультисиг або DAO.

Оракул (Chainlink або кастомний)

Для умов, які можна отримати on-chain: ціна активу, результат події, on-chain дані з іншого протоколу. Chainlink AnyAPI дозволяє запитати будь-які HTTP-дані та доставити їх у контракт.

// Запит даних через Chainlink Functions function requestVerification(bytes32 jobId, string calldata apiUrl) external { Chainlink.Request memory req = buildChainlinkRequest( jobId, address(this), this.fulfill.selector ); req.add("get", apiUrl); req.add("path", "result.completed"); sendChainlinkRequest(req, fee); } function fulfill(bytes32 requestId, bool completed) external recordChainlinkFulfillment(requestId) { if (completed) { _releaseFunds(); } } 

Для простих числових умов (price threshold) — Chainlink Price Feeds без додаткової інтеграції.

Підпис отримувача (cryptographic proof)

Умова підтверджується цифровим підписом довіреної сторони. Наприклад, платіжна система підписує підтвердження транзакції, а контракт верифікує підпис через ecrecover. Це працює без on-chain оракула — підпис містить всю необхідну інформацію.

function releaseWithSignature( uint256 paymentId, bytes memory signature ) external { bytes32 hash = keccak256(abi.encodePacked(paymentId, address(this))); bytes32 ethHash = hash.toEthSignedMessageHash(); address signer = ethHash.recover(signature); require(signer == trustedVerifier, "Invalid signature"); _release(paymentId); } 

Багатостороння верифікація

Комбінація: 2-of-3 між покупцем, продавцем і арбітром. Будь-які два з трьох можуть звільнити кошти. Це знижує ризик змови однієї сторони з арбітром.

Механізм вирішення спорів

Ми впроваджуємо механізм оскарження зі зберіганням доказів (IPFS-хеші в контракті). Кожна сторона може завантажити хеш свого твердження, і арбітр (або DAO) приймає рішення на основі цих даних. Час на оскарження обмежений — наприклад, 7 днів.

Базова структура контракту

struct Payment { address payer; address payee; uint256 amount; address token; // address(0) для ETH uint256 deadline; // timestamp завершення PaymentState state; // Pending, Released, Refunded, Disputed bytes32 conditionHash; // хеш умови (off-chain документ) } enum PaymentState { Pending, Released, Refunded, Disputed } 

Deadline критичний. Якщо умова не виконана до deadline, платник повинен мати можливість повернути кошти. Без deadline кошти можуть застрягти назавжди.

Як впровадити умовний платіж: 5 кроків

1. Аналіз сценарію. Визначте учасників, умову та механізм підтвердження. Наприклад, для KPI-платежу потрібен оракул, для фрілансу — арбітр.
2. Проектування контракту. Виберіть патерн (арбітр, оракул, підпис) та задайте параметри: deadline, token, сума.
3. Реалізація. Напишіть код на Solidity з використанням Foundry або Hardhat. Включіть тести з покриттям >95%.
4. Аудит безпеки. Перевірте на reentrancy, oracle manipulation, front-running. Використовуйте Slither та Echidna.
5. Деплой та моніторинг. Розгорніть у тестовій мережі, проведіть інтеграційне тестування, потім у mainnet.

Типові кейси та їх специфіка

З нашої практики:

• Freelance-платіж. Умова: підтвердження замовника. Арбітр: DAO або мультисиг. Строк: 14-30 днів. Особливість: потрібен механізм оскарження зі зберіганням доказів.
• DeFi-опціон. Умова: досягнення цінового рівня. Оракул: Chainlink Price Feed. Строк: expiry опціону. Особливість: oracle manipulation risk — flash loan може тимчасово змінити ціну. Рішення: TWAP замість spot price. Chainlink з TWAP у 2 рази надійніший за spot price для цінових умов — це знижує операційні витрати до 30%.
• Вендор-платіж з KPI. Умова: on-chain дані (TVL, обсяг транзакцій). Оракул: The Graph + кастомний оракул. Строк: квартальний. Особливість: дані з The Graph не push, а pull — контракт запитує їх через Chainlink.
• Ігрові досягнення. Умова: on-chain подія в ігровому контракті. Верифікація: прямий виклик від ігрового контракту.

Як захиститися від атак?

Reentrancy при release. _release() переводить ETH або токени. Якщо recipient — контракт, він може викликати _release() повторно. Захист: ReentrancyGuard від OpenZeppelin + checks-effects-interactions патерн (спочатку змінюємо state, потім переводимо).

Oracle manipulation. Flash loan атакуючий за один блок маніпулює ціною на DEX → оракул читає змінену ціну → умова виконана → кошти звільнені. Для цінових умов — тільки Chainlink з TWAP, не DEX spot price.

Front-running на fulfill. MEV-бот бачить транзакцію fulfillment у mempool і вставляє свою транзакцію перед нею. Для escrow це зазвичай не критично (отримувач визначений заздалегідь), але в аукціонних схемах потрібна commit-reveal.

Закінчення строку при валідній умові. Умова виконана, але транзакція confirmation застрягла, і deadline минув. Потрібен розумний grace period або off-chain моніторинг з алертами.

Що входить у роботу (deliverables)

• Аудит та доопрацювання вимог під ваш бізнес-сценарій.
• Вихідний код смарт-контрактів на Solidity (Foundry/Hardhat) з юніт- та інтеграційними тестами (покриття >95%).
• Документація API та схеми взаємодії.
• Розгортання в тестовій мережі (Sepolia, Goerli), повний тест-раунд.
• Інструкція з експлуатації та підтримки.
• Код-рев’ю від нашого старшого інженера (багаторічний досвід у блокчейні).

Ми супроводжуємо проекти після деплою: моніторинг, апгрейди контрактів при необхідності. Оцінимо ваш проект протягом 24 годин. Зв'яжіться з нами для консультації. Замовте розробку — обговоримо деталі. Отримайте консультацію: ми допоможемо визначитися з архітектурою та оцінити бюджет.

Строки

Точний термін визначаємо після аналізу вашого сценарію.