Приём платежей XMR: настройка узла и RPC-шлюза

Технические сложности Monero-платежей: конфиденциальность на уровне протокола

Организация приёма Monero-платежей упирается в архитектуру конфиденциальности: каждая транзакция использует stealth-адреса, кольцевые подписи (Ring Signatures) и скрытые суммы (RingCT). Без RPC-кошелька вы не увидите входящие транзакции — стандартные подходы вроде мониторинга адреса в блокчейне здесь не работают. Мы, команда блокчейн-инженеров с опытом интеграции Monero, разберём инженерное решение от синхронизации узла до мониторинга subaddress. Получите консультацию по внедрению — обсудим вашу архитектуру.

Сложность интеграции Monero проистекает из самой его сути. Адрес состоит из двух пар ключей: (public spend key, private spend key) и (public view key, private view key). Отправитель генерирует одноразовый stealth-адрес, используя ваш public view key и случайный scalar. Только владелец private view key может вычислить, что транзакция принадлежит ему. RingCT скрывает суммы с помощью Pedersen commitments — только отправитель и получатель знают реальное количество XMR. Средняя комиссия за транзакцию составляет около 0.0001 XMR, что существенно ниже, чем у банковских переводов.

Что это значит для приёма входящих платежей

Вы не можете просто сканировать блокчейн — для мониторинга нужен private view key. На практике это означает запуск полного узла с monero-wallet-rpc или использование view key на сервере (позволяет видеть входящие, но не тратить). Субъективно, Monero даёт 15 decoys на каждый input (начиная с HF v15), а среднее время блока — 2 минуты. Для production критично настроить monero-wallet-rpc с TLS и авторизацией.

Monero разработчики подчёркивают, что subaddress — стандарт де-факто для платёжных шлюзов. Кошелёк может создавать до 2^64 subaddress'ов, что достаточно для любой нагрузки.

Архитектура: monero-wallet-rpc

Стандартный инструмент интеграции — monero-wallet-rpc из официального набора. Он предоставляет JSON-RPC интерфейс для всех операций: создание subaddress, просмотр баланса, формирование транзакций.

Развёртывание узла

Сначала синхронизируем monerod. Размер блокчейна ~180 GB (pruned ~60 GB), первая синхронизация — 12–48 часов. Используйте SSD и 4 ГБ RAM минимум.

# Запуск monerod с pruning monerod --data-dir /var/lib/monero \ --prune-blockchain \ --db-sync-mode fast \ --rpc-bind-ip 127.0.0.1 \ --rpc-bind-port 18081 \ --no-igd \ --detach # Запуск monero-wallet-rpc monero-wallet-rpc \ --daemon-address 127.0.0.1:18081 \ --rpc-bind-port 18083 \ --wallet-file /etc/monero/payment-wallet \ --password-file /etc/monero/wallet.pass \ --rpc-login payment_server:$(cat /etc/monero/rpc.pass) \ --disable-rpc-login false \ --trusted-daemon \ --non-interactive 

Для production — отдельный кошелёк на окружение, nginx с TLS, HTTP Basic. Обратитесь к нам за готовой конфигурацией — поможем настроить.

Как правильно назначить subaddress каждому заказу?

Monero поддерживает subaddresses — производные адреса, полностью независимые на уровне блокчейна. Это ключевая фича для payment processing.

Процесс из четырёх шагов:

1. Кошелёк через monero-wallet-rpc.
2. Создать subaddress для каждого заказа (create_address).
3. Привязать subaddress к заказу в БД.
4. Мониторить входящие транзакции на этот subaddress.

Пример:

import requests RPC_URL = "http://127.0.0.1:18083/json_rpc" AUTH = ("payment_server", "rpc_password") def create_payment_address(order_id: str) -> dict: response = requests.post(RPC_URL, auth=AUTH, json={ "jsonrpc": "2.0", "id": "0", "method": "create_address", "params": { "account_index": 0, "label": f"order_{order_id}" } }) result = response.json()["result"] return { "address": result["address"], "address_index": result["address_index"] } def check_incoming_transfers(min_amount_xmr: float) -> list: response = requests.post(RPC_URL, auth=AUTH, json={ "jsonrpc": "2.0", "id": "0", "method": "get_transfers", "params": { "in": True, "pending": False, "min_height": 0 } }) transfers = response.json()["result"].get("in", []) return [t for t in transfers if t["amount"] / 1e12 >= min_amount_xmr] 

Subaddress стали стандартом де-факто несколько лет назад и теперь рекомендуются для всех новых интеграций. Они выглядят как независимые адреса, лучше для приватности, чем payment ID. Monero wallet RPC документация подтверждает эффективность этого подхода.

Как организовать мониторинг входящих Monero-платежей?

Monero использует концепцию unlocked balance — средства становятся доступными после 10 подтверждений (~20 минут при blocktime 2 минуты). Для платёжной системы:

def poll_payments(expected_payments: dict) -> None: """ expected_payments: {address_index: {"order_id": str, "amount_xmr": float}} """ response = requests.post(RPC_URL, auth=AUTH, json={ "jsonrpc": "2.0", "id": "0", "method": "get_transfers", "params": {"in": True, "pending": True} }) for transfer in response.json()["result"].get("in", []): addr_idx = transfer["subaddr_index"]["minor"] confirmations = transfer["confirmations"] amount_xmr = transfer["amount"] / 1e12 # 1 piconero = 1e-12 XMR if addr_idx in expected_payments: expected = expected_payments[addr_idx] if amount_xmr >= expected["amount_xmr"] * 0.99: # допуск 1% на округление if confirmations >= 10: mark_order_paid(expected["order_id"], amount_xmr) else: update_order_status(expected["order_id"], "pending_confirmations", confirmations) 

Следите за тем, чтобы после 10 подтверждений средства попадали на cold wallet. View-only wallet для мониторинга исключает риск кражи.

Как обеспечить безопасность при автоматических выплатах?

Приватный spend key храните в изолированной среде. Для автоматических выплат используйте отдельный hot wallet с минимальным балансом. Основные средства — в cold wallet, периодический ручной sweep.

View-only wallet (public spend key + private view key) безопасно держать на сервере мониторинга:

monero-wallet-cli --generate-from-view-key view-only-wallet \ --address <main_address> \ --viewkey <private_view_key> 

Даже при компрометации сервера злоумышленник не сможет вывести средства. Такой подход снижает операционные затраты примерно на 40% по сравнению с традиционными платёжными системами.

Что входит в работу

• Развёртывание и синхронизация monerod (full node или pruned)
• Настройка monero-wallet-rpc с аутентификацией и TLS
• Реализация subaddress-based payment flow
• Polling сервис для мониторинга входящих транзакций с логикой подтверждений
• Sweep автоматизация и разделение hot/cold storage
• Интеграция с существующей платёжной системой через webhook или callback

Распространённые проблемы при интеграции Monero

Забывают учесть порог комиссии: Monero использует динамические комиссии, и если клиент заплатит сумму, меньшую ожидаемой из-за комиссии сети, платёж не пройдёт. Решение — указывать сумму получения нетто, а не gross. Также путают subaddress с payment ID, хотя последний не используется с 2018 года и раскрывает связь кошельков. Недостаточный период подтверждений — 10 блоков минимум, для крупных сумм используйте 30+. Отсутствие мониторинга pending-транзакций: при высокой нагрузке сети некоторые транзакции зависают, нужен механизм пересканирования.

Средняя экономия на комиссиях при переходе на Monero составляет около 30%, а стоимость разработки шлюза окупается в среднем за 2–3 месяца. Получите консультацию по внедрению — обсудим вашу архитектуру.

server { listen 443 ssl; server_name payment.example.com; ssl_certificate /etc/nginx/certs/fullchain.pem; ssl_certificate_key /etc/nginx/certs/privkey.pem; location /json_rpc { proxy_pass http://127.0.0.1:18083; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }