가장 비용이 많이 드는 x402 오류 유형 세 번째: 이미 성공한 결제를 재시도하는 경우

결제는 완료되었습니다. 체인에서 확인할 수 있습니다. 하지만 결과가 돌아오지 않았습니다. 도구가 실행되지 않았거나, 실행되었더라도 정산 후에 타임아웃, 프록시 또는 충돌로 인해 응답이 손실된 것입니다.

가장 비용이 많이 드는 x402 오류 유형 세 번째는 바로 그 결제를 재시도하는 것입니다. 그것만이 유일한 선택지처럼 느껴지지만, 이는 하나의 손실된 결과를 두 개의 결제로 만드는 정확한 행동입니다.

사람들이 빠지는 두 가지 함정이 있습니다:

1. 이중 결제 함정(The double-payment trap). 재시도는 동일한 의도에 대한 새로운 EIP-3009 승인 서명(authorization)을 합니다. 만약 첫 번째 시도가 정산되었지만 (그리고 타임아웃이나 모호한 오류가 그것에 대해 아무것도 알려주지 않았다면), 당신은 이제 두 번 지불한 것입니다. 이 프로토콜은 모호함에 대해 명확합니다: 동일한 승인을 중복 제출하면 계약 수준의 AuthorizationUsed revert로 나타날 수 있으며, 이는 실제 실패와 구별하기 어려워

이 두 가지 아래에는 프로토콜 레벨의 격차가 존재합니다. x402는 판매자에게 돈을 신뢰성 있게 이동시킨 후, 실제로 무언가를 돌려받았는지에 대해서는 침묵합니다. x402 트래커에서 가장 많이 논의된 문제점처럼 말하자면 다음과 같습니다: "x402는 에이전트가 어떻게 지불하는지 해결한다... 이 계층들 중 어느 것도 전달(delivery)을 증명하지 못한다." 에스크로, 평판, 오케스트레이션 모두 "에이전트가 실제로 비용을 지불한 만큼의 것을 전달했는지"에 답해야 하며, 현재 각 시스템은 확인 절차를 건너뛰거나 자체 보고(self-reporting)를 신뢰합니다(x402-foundation/x402#1195). 온체인 정산은 지불을 증명할 뿐입니다. 실행(execution)을 증명하지 못하며, 확실히 그 결과가 사용자에게 도달했는지도 증명하지 못합니다. 확인된 거래를 전달의 증거로 취급하는 것이 '지불했지만 결과는 없는' 상황을 감지 불가능하게 만들고, 이는 기사 #1의 두 번 서명 실수에 새로운 옷을 입힌 것과 같습니다.

안전한 순서:

1. 세 가지 영역을 분리하세요. 세 가지 별개의 질문을 하세요: 지불이 정산되었는지(정확한 금액으로 올바른 수신자에게 확인된 전송 기록을 체인에서 확인)? 실행이 발생했는지(서버의 기록을 확인하거나 운영자에게 문의)? 전달이 발생했는지(사용자가 그 결과를 보유하고 있는가)? '지불했지만 아무 일도 일어나지 않은' 사고 대부분은 실행 실패가 아니라 전달 실패이며, 재실행은 전달 실패에 대한 잘못된 해결책입니다.
2. 정산 영수증을 보관하세요. 명세의 PAYMENT-RESPONSE에는 거래 해시(transaction hash)가 포함되어 있습니다. 이것이 지불 증거이자 조정 처리 수단입니다. 재시도하기 전에 이를 가지고 리소스 운영자에게 연락하여 실행이 발생했는지 문의해야 합니다.
3. 실행이 일어나지 않았음이 입증되었거나, 해당 작업이 명백히 Idempotent(멱등성)한 경우에만 재실행하세요. 증거가 먼저, 서명이 나중입니다. 첫 번째 서명이 무엇을 했는지 확인하기 전에 절대 서명하지 마세요.
4. 에이전트의 경우: 지불했지만 결과는 없는 상황을 절대로 자동 재시도해서는 안 됩니다. 해당 작업을 인간 검토를 위해 보류하거나 증거 기반 복구를 수행해야 합니다. 자체적으로 지불된 작업을 재시도하는 에이전트는 이중 지출(double-spend) 기계입니다.

이것은 failure class callx402 recover가 만들어진 용도입니다. 기록된 작업(recorded operation)을 전달하면 재시도가 안전한지에 대한 읽기 전용 판정(read-only verdict)을 내려줍니다:

callx402 evidence op_abc123   # 무슨 일이 일어났는지, 각 단계별로
callx402 recover op_abc123    # 안전한 재시도 판정: retry, wait, 또는 ask

이것은 의도적으로 청구(charge), 실행(execute), 재시도(retry), 또는 상환(repay)하는 것을 거부합니다. 서명을 다시 할 수 있는 복구 도구는 이중 결제(double-pay)를 할 수 있는 복구 도구가 되기 때문에, recover는 설계상 읽기 전용입니다. 두 가지 정직한 한계가 있습니다: 판정은 당신이 제공하는 증거만큼만 유효하며, 프로토콜이 절대 생성하지 못한 배송 증명(delivery proof)을 만들어낼 수는 없습니다. 위 세 단계 검사는 이를 위한 좁히는 도구이며; recover는 어떤 단계가 아직 열려 있는지 알려줍니다.

소스와 함께 전체 설명은 callx402 문제 해결 문서에서 확인할 수 있습니다: 결제되었으나 결과 없음 및 재시도가 안전할 때. x402가 작동하지 않을 때는 callx402를 사용하세요.