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

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

Мы разрабатываем escrow-контракты, которые блокируют средства и освобождают их только при выполнении заданных условий. Никаких посредников, полная прозрачность on-chain. За 5 лет работы над 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), полный тест-раунд.
• Инструкция по эксплуатации и поддержке.
• Код-ревью от нашего старшего инженера (10+ лет в блокчейне).

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

Сроки

Точный срок определяем после анализа вашего сценария.