부분 결제(Partial Payments)

XRPL의 네이티브 결제 기능이면서도, 역사적으로 잘 알려진 거래소 통합 악용 사례의 원인이 되기도 했던 기능을 설명합니다.

부분 결제란 무엇인가

일반적으로 XRP 레저 결제는 지정된 전체 금액을 전달하거나 완전히 실패하거나 둘 중 하나입니다. 부분 결제는 (tfPartialPayment 플래그를 설정하여 활성화되는) 특정 결제 모드로, 대신 요청된 금액보다 적은 금액을 전달하고도 성공으로 처리될 수 있게 합니다 — 이용 가능한 유동성이 요청된 전체 금액을 감당하지 못할 수 있는 교차 통화 결제와 같은 정당한 경우에 유용하며, 결제를 완전히 실패시키는 대신 가능한 만큼 전달할 수 있게 해줍니다.

이 기능이 존재하는 이유

부분 결제가 없다면, 유동성이 얕은 시장을 거치는 교차 통화 결제는 결제가 제출된 시점과 체결된 시점 사이에 유동성이 조금만 변해도 완전히 실패할 수 있습니다. 부분 결제를 통해 애플리케이션은 "현재 가능한 만큼 전달"하는 것을 받아들이도록 선택할 수 있으며, 이는 특정 결제 라우팅 사용 사례에 진정으로 유용합니다.

역사적인 악용 패턴

이러한 유연성은 이를 신중하게 고려하지 않은 거래소와 서비스에 대한 잘 문서화된 공격 벡터가 되었습니다. 이 악용 패턴은 대략 다음과 같이 작동했습니다.

공격자가 부분 결제로 플래그가 지정된 거래를 사용해 거래소 주소에 XRP를 입금하지만, 실제로 보내는 금액보다 훨씬 큰 금액을 요청합니다.
취약한 거래소의 입금 처리 시스템이 거래에서 실제로 전달된 금액을 반영하는 delivered_amount 필드 대신 요청된/의도된 금액 필드를 확인하고, 더 크고 잘못된 수치를 기준으로 고객 계정에 입금 처리합니다.
공격자는 실제로 입금한 것보다 훨씬 많은 금액을 입금받은 것으로 처리됩니다.

거래소 소프트웨어를 만들지 않더라도 이것이 중요한 이유

이 역사를 이해하는 것은 두 가지 이유로 유용한 배경지식이 됩니다.

이는 블록체인 애플리케이션 보안의 더 넓은 교훈을 구체적으로 보여줍니다: 발신자가 주장하는 파라미터만이 아니라 거래의 실제로 전달된 결과를 항상 검증하라는 원칙은 XRPL을 넘어 폭넓게 일반화됩니다.
이는 정당한 입금 처리 시스템이 결제의 요청 금액이 아니라 (검증된 레저 데이터에서 직접 보고되며 공격자가 조작할 수 없는) delivered_amount 필드를 특별히 확인하는 이유를 설명합니다 — 이는 현재 성숙한 XRPL 연동 거래소와 서비스 전반에서 표준 관행입니다.

현재 상태

이는 살아 있는 프로토콜 취약점이 아니라 잘 알려지고 잘 이해된 통합상의 함정입니다 — XRP 레저 자체는 설계된 대로 정확히 작동합니다. 위험은 전적으로 수신 측 애플리케이션이 거래 데이터를 어떻게 해석하기로 선택하는지에 있습니다. 올바르게 구현된 현대의 입금 처리 시스템은 delivered_amount를 확인하며 이 패턴에 노출되지 않습니다. 그럼에도 이는 블록체인 통합 보안을 더 폭넓게 논의할 때 자주 인용되는 사례 연구로 남아 있습니다 — 애플리케이션 수준(프로토콜 수준이 아닌)의 다른 리스크 범주는 Smart Contract and Sidechain Risks(영어)를 참고하세요.