Частичные платежи (Partial Payments)

Нативная функция платежей XRPL, которая также исторически становилась источником хорошо задокументированной уязвимости в интеграциях бирж.

Что такое частичный платёж

Обычно платёж в XRP Ledger либо доставляет полную указанную сумму, либо полностью проваливается. Частичный платёж — это специальный режим платежа (включаемый установкой флага tfPartialPayment), который вместо этого позволяет платежу доставить меньше запрошенной суммы и всё равно считаться успешным — полезно в законных случаях, таких как кросс-валютные платежи, где доступная ликвидность может не покрывать всю запрошенную сумму, позволяя платежу доставить столько, сколько возможно, вместо полного провала.

Зачем существует эта функция

Без частичных платежей кросс-валютный платёж, маршрутизированный через неглубокий рынок, мог бы полностью провалиться, если ликвидность хоть немного сдвинулась между моментом отправки платежа и моментом его расчёта. Частичные платежи позволяют приложениям выбирать вариант «доставить сколько сейчас возможно» вместо этого, что по-настоящему полезно для определённых сценариев маршрутизации платежей.

Исторический паттерн эксплойта

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

1. Атакующий вносит XRP на адрес биржи, используя транзакцию с флагом частичного платежа, но запрашивая намного большую сумму, чем фактически отправляет.
2. Уязвимая система обработки депозитов биржи проверяет поле запрошенной/предполагаемой суммы транзакции — вместо поля delivered_amount, отражающего то, что было фактически доставлено, — и зачисляет на счёт клиента сумму на основе большей, некорректной цифры.
3. В итоге атакующему зачисляется гораздо больше, чем он реально внёс.

Почему это важно, даже если вы не разрабатываете биржевое ПО

Понимание этой истории полезно по двум причинам:

• Это конкретная иллюстрация более широкого урока в безопасности блокчейн-приложений: всегда проверяйте фактический, доставленный результат транзакции, а не только параметры, заявленные отправителем, — принцип, который хорошо обобщается далеко за пределы конкретно XRPL.
• Это объясняет, почему легитимные системы обработки депозитов специально проверяют поле delivered_amount (сообщаемое напрямую данными валидированного леджера, не контролируемое атакующим), а не запрошенную сумму платежа, — деталь, которая теперь является стандартной практикой среди зрелых бирж и сервисов, интегрированных с XRPL.

Текущее состояние

Это известная, хорошо изученная ловушка интеграции, а не действующая уязвимость протокола — сам XRP Ledger ведёт себя именно так, как задумано; риск целиком заключён в том, как принимающее приложение решает интерпретировать данные транзакции. Современные, корректно реализованные системы обработки депозитов проверяют delivered_amount и не подвержены этому паттерну. Тем не менее это остаётся часто цитируемым примером в более широких обсуждениях безопасности блокчейн-интеграций — о других категориях риска на уровне приложения (а не протокола) см. статью Smart Contract and Sidechain Risks (на английском).