Архитектура платежного шлюза Stablecoin

Обзор архитектуры:

Платежный шлюз стейблкоина имеет пять основных уровней: (1) уровень платежных намерений, который создает и управляет адресами депозитов для каждого платежа, (2) уровень мониторинга цепочки, который отслеживает блокчейн на предмет входящих переводов, (3) механизм подтверждения, который проверяет квитанции и запускает события, (4) реестр, в котором регистрируются все состояния платежей, и (5) уровень расчетов, который управляет внеплановым и казначейским управлением.

В этом руководстве основное внимание уделяется проектированию системы, лежащей в основе производственного шлюза стабильной монеты: не только тому, какие компоненты существуют, но и тому, как они соединяются, где происходят сбои и какие проектные решения имеют значение для надежности в масштабе.

Уровень платежного намерения

Намерение платежа создается, когда плательщик инициирует платеж. Он хранит: ожидаемую сумму, стейблкоин и цепочку, назначенный адрес депозита, время истечения срока действия, а также ссылку на последующий заказ или счет-фактуру.

Получение адреса депозита

Адреса депозитов извлекаются из HD-кошелька с использованием BIP-44. Главное начальное число хранится в диспетчере секретов (AWS Secrets Manager, Vault). Каждому платежному намерению присваивается уникальный индекс пути деривации. Шлюз хранит: индекс деривации, ожидаемую сумму, стейблкоин, цепочку, срок действия и статус платежа.

В цепочках EVM один и тот же производный адрес работает во всех цепочках, совместимых с EVM. Один HD-кошелек может обслуживать Base, Ethereum, Polygon и Arbitrum с отдельными индексами адресов для каждого намерения.

Срок действия адреса и повторное использование

Депозитные адреса не должны использоваться повторно при различных платежных намерениях. После истечения срока действия или успешной оплаты адрес деактивируется на уровне мониторинга. Если просроченный платеж поступает на адрес с истекшим сроком действия, шлюз записывает его как несопоставленный для проверки вручную.

Уровень мониторинга цепочки

Уровень мониторинга цепочки отслеживает в блокчейне события ERC-20 (или эквивалентного) перевода на любой активный адрес депозита. Проект должен обеспечивать: большой объем событий (в загруженных цепочках), обнаружение в реальном времени, реорганизацию цепочки и мониторинг одновременно в нескольких цепочках.

EVM Мониторинг цепочки

Subscribe to ERC-20 Transfer events from the stablecoin contract address using WebSocket RPC (Alchemy, QuickNode). Filter by the to address matching any active deposit address. Use a bloom filter or database index on active addresses for O(1) lookup.

Fallback: poll for recent Transfer events every N seconds using eth_getLogs. WebSocket subscriptions are preferred but can drop connections — the polling fallback ensures no missed events.

Трон TRC-20 Мониторинг

TronGrid API предоставляет историю транзакций для адреса. Опросите историю переводов TRC-20 для каждого активного адреса депозита с помощью TronGrid REST API. Подписки WebSocket менее надежны в Tron — стандартным подходом является опрос.

Solana SPL Мониторинг токенов

Solana uses Associated Token Accounts (ATAs) — each wallet address has a corresponding ATA for each SPL token. Monitor the USDC ATA corresponding to each deposit address using WebSocket account subscriptions or polling getSignaturesForAddress.

Механизм подтверждения

Механизм подтверждения проверяет обнаруженные переводы и генерирует события оплаты. Ключевые обязанности:

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

Проверка суммы: Сравнивает полученную сумму с ожидаемой. Обрабатывает недоплаты (отметьте для проверки вручную или отклоните в зависимости от допуска продукта) и переплаты (полная сумма кредита, отметка превышения).

Обработка цепочки реорганизации: Если ранее обнаруженная транзакция удаляется при реорганизации цепочки, верните событие Payment_detected и повторно войдите в состояние ожидания. Используйте короткую глубину подтверждения, соответствующую риску реорганизации сети.

Идемпотентность: Хеш каждой подтвержденной транзакции сохраняется. Повтор того же события подтверждения невозможен.

Дизайн книги

Реестр платежей — это авторитетная запись всей платежной активности в стейблкоинах. Он должен быть доступен только для добавления (без обновлений, только вставки) и иметь источник событий — каждый переход состояния (созданный, обнаруженный, подтвержденный, истекший, очищенный) является записью в реестре.

Событие	Триггер	Последующие действия
платеж.создан	Платежное намерение создано.	Вернуть адрес депозита плательщику
платеж.обнаружен	Трансфер замечен в цепочке, ожидается	Уведомить плательщика; показать статус ожидания
платеж.подтвержден	Получены необходимые подтверждения	Активировать заказ/подписку; вызвать вебхук
платеж.истёк	Срок годности истек, оплаты нет.	Освободить адрес депозита; уведомить плательщика
оплата.недоплачено	Сумма меньше ожидаемой	Отметить на рассмотрение; обработка конкретного продукта
оплата.проведено	Средства поступили в казначейский кошелек	Обновить запись развертки; уменьшить баланс адреса

Развертка и управление казначейством

Для производственных развертываний казначейский кошелек должен иметь мультиподпись (например, Safe/Gnosis Safe) — для критически важных казначейских операций требуется несколько подписантов.

Газовое финансирование: Каждому депозитному адресу необходим собственный токен (ETH, TRX и т. д.) для покрытия комиссии за газ за транзакцию. Шлюз поддерживает службу финансирования газа, которая пополняет депозитные адреса перед очисткой.

Триггер развертки: Запускается по порогу баланса, расписанию или вручную. Пакетная очистка снижает общую стоимость газа.

Подтверждение проверки: Свип-транзакция отслеживается до подтверждения. В случае успеха событие очистки регистра записывается.

Архитектура внеплановой интеграции

Устройство конвертирует стейблкоины, хранящиеся в казначейском кошельке, в фиатные деньги. Схема интеграции:

Аккаунт провайдера вне рампы: Внешний провайдер (Bridge, Coinbase Prime и т. д.) предоставляет адрес назначения стейблкоина. Отправка USDC на этот адрес инициирует перевод средств на настроенный банковский счет.

Инструкция по переводу: Шлюз создает и подписывает перевод из казначейского кошелька на внешний адрес. Для этого требуется доступ к ключу подписи казначейского кошелька — обычно требуется одобрение с несколькими подписями.

Подтверждение расчета: Поставщики услуг вне рампы отправляют веб-перехватчики или предоставляют APIs для подтверждения распоряжения расчетом. Шлюз записывает событие расчета по распоряжению относительно передачи вне рампы.

Производственные аспекты

Архитектурные решения, важные для надежности производства:

Запускайте резервные соединения узлов RPC (основной Alchemy + резервный QuickNode) — единичные сбои RPC не должны приводить к пропущенным платежам.
Очередь событий (Kafka, SQS или Redis Streams) между мониторингом цепочки и механизмом подтверждения — отделяет прием от обработки и обеспечивает воспроизведение
Транзакции базы данных, связанные с записью в реестр — событие подтверждения и последующие действия должны либо фиксироваться, либо откатиться.
Очередь недоставленных писем для неудачных доставок через веб-перехватчик — повторите попытку с экспоненциальной задержкой, оповещение о повторных неудачах
Мониторинг и оповещение о: задержке мониторинга цепочки, несовпадающих платежах, сбоях проверки, задержках расчетов вне рампы.
Отделение управления ключами подписи от логики приложения шлюза — казначейские операции должны требовать утверждения с несколькими подписями.

Часто задаваемые вопросы

Должен ли шлюз быть отдельной службой или встроен в основное приложение?

Для производства настоятельно рекомендуется использовать автономную службу шлюза. Он изолирует логику мониторинга цепочки и подписи от основного приложения, может быть развернут и масштабирован независимо и имеет четкую границу безопасности. Шлюз публикует события платежей; основное приложение их потребляет.

Как мне поступить с пользователями, отправляющими неправильную сумму или неправильный стейблкоин?

Неправильные переводы стейблкоинов (например, DAI вместо USDC) на адрес депозита записываются как несовпадающие и ставятся в очередь для проверки вручную. Отмечаются недоплаты — продукт определяет, следует ли принимать частичные платежи, отклонять их или предлагать плательщику пополнить счет. Переплаты могут быть зачтены в полном объеме, а излишек будет возвращен внутри сети.

Что произойдет, если узел RPC выйдет из строя?

Уровень мониторинга должен работать с резервными поставщиками RPC. Если все не удается, шлюз переходит в ухудшенное состояние — новые подтверждения платежей задерживаются, но не теряются. Когда соединение будет восстановлено, воспроизведите последний подтвержденный блок, чтобы отследить все пропущенные события передачи. Очередь событий между мониторингом и механизмом подтверждения гарантирует, что события не будут потеряны во время кратковременных простоев.

Как эта архитектура масштабируется до больших объемов?

Горизонтальное масштабирование работников мониторинга цепочки (один работник на цепочку или сегмент цепочки). Очередь событий поглощает пакетный объем. Механизм подтверждения масштабируется горизонтально, пока записи в реестре идемпотентны. Получение адреса и масштаб поиска с правильным индексом базы данных по активным адресам. Узким местом обычно являются ограничения скорости RPC — планируйте выделенные конечные точки RPC в масштабе.

Краткое описание архитектуры

Пять уровней: намерение платежа (управление адресами), мониторинг цепочки, механизм подтверждения, реестр и расчет (очистка + отклонение).

Создание HD-кошелька дает уникальные детерминированные адреса депозитов без хранения личных ключей для каждого адреса.

Очередь событий между механизмом мониторинга и подтверждения имеет решающее значение для надежности и воспроизведения.

Ledger должен быть доступен только для добавления и иметь источник событий — каждый переход состояния является записью, а не обновлением.

Казначейская интеграция с несколькими подписями и внешняя интеграция являются оперативно чувствительными компонентами — проектируйте с соответствующими элементами управления подписями.