PayChain 0 to 1 (2) - 결제에서 검증 가능한 증거까지

지난 글에서는 온체인 결제가 실제 사업에 쓰이려면 결제 이후를 다루는 체계가 필요하다고 이야기했다. 이번 글에서는 PayChain이 그 체계를 어떻게 만들었는지 다룬다. PayChain 네트워크에서 이 역할은 정산 프로토콜이 맡는다. 1편에서 Settlement OS라고 부른 것이 바로 이 정산 프로토콜이다.

정산 프로토콜의 중심에는 Receipt가 있다. PayChain에서 디지털 전표 역할을 하는 기록 단위다. Receipt에 무엇이 담기는지, 어떤 단계를 거쳐 정산이 끝나는지, 그리고 어떻게 검증 가능한 증거가 되는지를 차례로 살펴본다.

결제 완료와 정산 완료 사이

블록체인에서 개인이 개인에게 자산을 보내는 거래는 트랜잭션이 확정되는 순간 끝난다. 즉, 전송이 곧 정산이고, 당사자는 둘뿐이다. 이런 거래에서는 트랜잭션 기록만으로 충분하다. 100 USDC가 물건값인지 환불인지 빌린 돈을 갚은 것인지는 보낸 사람과 받은 사람이 이미 알고 있기 때문이다.

반대로 기업이 여러 가맹점에 크립토 결제를 서비스로 제공하면 구조가 달라진다. 가맹점이 체인마다 지갑과 키를 관리하고, 입금을 주문과 맞추고, 취소·환불·회계 처리까지 직접 하는 것은 사실상 결제 시스템 전체를운영하는 일이다. 그래서 크립토 결제 서비스는 수취·집금 구조를 취한다. 결제사업자가 고객의 자산을 먼저 받아 거래를 확인한 뒤, 가맹점별로 금액을 나눠 계약된 주기에 지급하는 방식이다. 1편에서 본 카드 결제와 같은 뼈대다.

여기서 “완료”가 둘로 갈라진다. 먼저, “결제 완료”는 고객이 보낸 자산이 지정된 수취처에 도착해 거래가 확정된 상태다. 그리고 “정산 완료”는 취소, 환불, 지급보류 등 상태값을 반영한 최종 수수료를 가맹점에 지급된 상태다. 따라서 온체인 전송이 끝난 뒤에도 가맹점에 줄 금액과 자산, 지급 시기와 처리 상태는 따로 관리해야 한다. 지금까지는 기업마다 백엔드에서 그 사이를 직접 메워 왔다. 바로 이 구간을 다루는 체계가 PayChain이고, 이 구간을 기록하는 단위가 Receipt다.

PayChain의 전표, Receipt

정산 프로토콜은 접수된 결제 이벤트를 모두 Receipt 단위로 기록한다. Receipt 한 건에는 다음 정보가 들어간다.

• 식별 정보: PayChain이 붙인 Receipt ID와 연동사가 거래마다 붙인 고유 ID(requestId)다. 연동사 내부의 주문과 결제 기록은 이 ID로 연결된다.
• 기록 내용(payload): 거래 유형, 금액, 자산, 가맹점, 결제 경로 등 연동사의 원본 결제 정보다. 원천 체인의 트랜잭션 해시나 수수료 내역 등 연동 시 필요에 따라 더 담을 수 있다.
• 현재 상태: 승인 여부, 기록 확정 여부, 앵커링 완료 여부, 정산 완료 여부 등을 나타내는 상태값이다.
• 증거 연결 정보: Receipt가 들어간 배치와 온체인에 기록한 해당 배치의 앵커 트랜잭션 해시다. 환불 Receipt의 경우 원거래 Receipt를 참조한다.

단순화한 예시는 다음과 같다.

위 코드에서 트랜잭션 해시가 두 개라는 점을 눈여겨보자. 기록 내용 안의 sourceTxHash는 이 예시에서 소비자의 자산이 실제로 움직인 원천 체인의 트랜잭션 해시다. 맨 아래 txHash는 이 Receipt가 속한 배치의 요약값을 PayChain에 기록한 앵커 트랜잭션의 해시로, 앵커링이 끝난 뒤에 채워진다. PayChain에서 자산 이동은 거래 기록의 한 부분이다. 즉, 위Receipt 한 건만 읽어도 연동사의 거래 pay-1042, 즉 1042번 주문의 대금 100 USDC가 가맹점 A 앞으로 결제됐고, 기록이 확정돼 다음 배치를 기다리는 중임을 알 수 있다. 원천 체인의 기록이 필요하면 기록 내용에 적힌 트랜잭션 해시를, 온체인 증거가 필요하면 앵커 트랜잭션을 따라가면 된다.

개발자 입장에서는 출발점이 달라진다. 지금까지는 개발자가 결제 다음 주문 상태 갱신, 환불 연결, 대사, 감사용 증빙 보관까지 전부 직접 구현해야 했다. 그러나 PayChain에서는 결제 결과를 Receipt로 접수하고 나면 상태 추적과 증빙 확보가 Receipt 조회와 Proof API 호출로 간단하게 끝난다.

Receipt의 여섯 단계

Receipt는 생성부터 정산 완료까지 상태가 여섯 단계로 나뉜다. 각 단계를 넘어가면서 거래의 책임과 증빙이 달라지고, 누가 언제 어떤 사유로 바꿨는지가 감사 로그에 남는다. 앞의 세 단계는 연동사가, 이후 두 단계는 PayChain이 진행하고, 마지막 단계로는 이의 제기 기간이 지나거나 정산 결과가 들어오면 자동으로 넘어간다.

• 생성은 결제 결과가 정산 프로토콜에 접수된 단계다. 예를 들어소비자가 온라인 스토어에서 100 USDC를 결제하고 전송이 원천 체인에서 확정되면, 연동사 시스템이 결제 결과를 Receipt로 기록한다. 접수할 때는 자산·결제 경로 등 정책 검사를 거치고, 거래마다 붙은 고유 ID를 대조해 네트워크 오류로 생길 수 있는 중복 Receipt를 걸러 이중 정산을 막는다.
• 승인은 연동사의 담당자나 시스템이 접수된 기록을 유효한 거래로 인정한 단계다. 누가 어떤 사유로 승인했는지가 함께 기록으로 남는다. 소비자에게는 결제가 이미 끝난 일이지만, 정산 쪽에서는 이제 막 지급 대상 후보에 오른 셈이다.
• 기록 확정은 연동사가 기록 내용을 확정하는 단계다. 이때부터 Receipt의 내용은 그대로 고정되고, 다음 배치에 들어갈 차례를 기다린다. 여기서부터 배치를 편입하고 앵커링하는 일은 PayChain의 몫이다.
• 배치 편입과 앵커링은 확정된 Receipt가 배치에 들어가고, 그 배치의 해시값을 온체인에 기록하는 단계다. 이 부분은 PayChain 설계의 핵심이므로 아래에서 따로 설명한다.
• 정산 완료는 앵커링 뒤, 정해진 이의 제기 기간이 지나거나 정산 결과가 들어와 거래가 Settlement OS에서 닫히는 단계다. 앞선 다섯 단계가 기록을 만들고 증거를 확정하는 과정이라면, 마지막 단계인 정산 완료는 그 기록을 바탕으로 거래를 마감한다.

위와 같은정해진 흐름을 벗어나는 예외적인 경우에도 처리 방식이 정해져 있다. 동결이나 분쟁이 걸린 거래는 별도 조치가 내려질 때까지 그 상태에 머물게 된다. 환불은 원거래를 가리키는 환불 Receipt를 새로 만들고, 이 Receipt는 원거래와 별도로 기록된다. 다시말해 어느 경우에도 원본 기록은 그대로 남는다. 환불과 분쟁을 이렇게 정식으로 기록하느냐에서 금융 운영의 신뢰가 갈린다.

배치와 앵커링

앞서 언급한 PayChain 설계의 핵심인 배치 편입과 앵커링으로 돌아가자. PayChain은 기록이 확정된 Receipt를 한 건씩 체인에 올리는 대신 배치(Batch)로 모으고, 배치 전체를 대표하는 해시값 하나만 체인에 올린다. 이 구조는 결제 인프라가 안고 있는 두 가지 문제를 풀려는 선택이다.

첫번째는 비용 문제다. Receipt를 하나하나 앵커링하면 앵커 트랜잭션이 거래 수만큼 생기고, 결제 규모가 커질수록 비용 부담도 그만큼 커진다. 반면, 여러 Receipt를 배치로 모아 한 번에 올리면 앵커 트랜잭션은 배치 수만큼만 생기므로, 하루 결제가 수만 건으로 늘어도 체인에 올리는 비용과 부하는 배치 수만큼에 그친다.

두 번째는 프라이버시 문제다. Receipt 내용을 그대로 체인에 올리면 주문과 가맹점, 금액과 계약 조건, 파트너별 정산 조건이 공개 원장에 실리고, 한번 올라간 데이터는 영원히 남아 누구나 조회할 수 있다. 하지만 배치의 해시값만 올리면 Receipt 본문은 정산 프로토콜 안에 머물고 권한이 있는 참여자만 열어볼 수 있으며, 공개 원장에는 해시값과 배치를 식별하는 최소한의 정보만 올라가게 된다. 결국,해시값만으로는 원본을 알아낼 수 없기 때문에, 외부에 감춰야 하는 정보는 노출되지 않는다.

이렇게 모은 배치 하나는 그 안에 든 기록이 언제 어떤 내용이었는지를 온체인에 못 박는 단위가 되고, 그 해시값은 머클 트리로 만든다. 먼저 배치에 속한 Receipt마다 식별자와 기록 내용으로 해시를 뽑는데, 이 해시는 상태값을 제외한 기록 내용 중 한 글자만 달라져도 값이 바뀐다. 이렇게 뽑은 해시를 둘씩 짝지어 다시 해시값을 구하고 값이 하나 남을 때까지 반복하면, 마지막에 남는 값이 해당 배치의 해시값인 머클 루트(Merkle root)가 구해진다. 이 머클 루트는 배치 하나를 대표하는 값이고, 이 값을 PayChain의 정산 컨트랙트에 기록하면 앵커링이 끝난다.

이러한 머클 루트 하나로 개별 거래는 어떻게 증명할까. 예컨대, 가맹점이 어제 결제된 주문 하나가 이번 배치에 제대로 들어갔는지 확인하고 싶다고 하자. 가맹점은 결제사업자를 통해 그 거래의 Receipt 본문과 Proof를 조회할 수 있다. Proof에는 해당 Receipt의 해시에서 머클 루트까지 올라가는 계산 경로가 담겨 있어서, 가맹점은 같은 배치의 다른 거래는 제쳐 두고 Receipt 본문으로 해시를 다시 만들고, Proof를 따라 루트를 계산한 다음, 체인에 기록된 루트와 대조하면 된다. 만약 두 값이 다르다면 해당 Receipt가 변조되었거나 해당 배치에 포함되지 않았다는 뜻이고, 두 값이 일치하면문제 없이 배치에 기록되어 있다는 뜻이다. 체인에 올린 루트는 공개 데이터라 누구나 조회 가능하기 때문에, 감사인에게 증빙을 제출 할때도 같은 방식으로 증명할 수 있다.

결국 거래 내용은 정산 프로토콜 안에 그대로 두고, 체인에는 배치마다 해시값 하나만 남겨 그 안에 든 모든 거래를 증명한다. 이와 같이 배치와 앵커링을 활용해 데이터는 감추고, 기록은 증명 가능한 방식으로 설계하여 비용 절감과 프라이버시, 검증 가능성을 한꺼번에 얻는다.

같은 기록, 같은 기준

정산에는 참여자가 많다. 결제사업자, 지갑 서비스, 자산 교환 사업자, 정산 파트너, 가맹점 시스템, 그리고 감사인까지. 지금까지 이들은 각자의 장부를 갖고 있었고, 정산이란 그 장부를 서로 맞추는 일이었다. 숫자가 하나라도 어긋나면 누구 장부가 맞는지부터 따져야 했다.

Receipt는 모든 참여자들이같이 보는 기록이다. 결제사업자가 접수하고, PayChain Settlement OS가 체인에 기록하고, 정산 파트너가 지급 결과를 반영하고, 감사인이 검증할 수 있는 기록이다. 1편에서 재무팀이 던진 질문도 답은 이 Receipt에서 출발한다. 어떤 주문의 대금인지, 환불은 원거래와 어떻게 이어지는지, 감사에 무엇을 낼지는 Receipt만 있으면 답이 나오고, 정산액과 수수료 계산 또한 이 기록을 근거로 한다. PayChain은 서로 다른 장부를 맞대는 대신 같은 기록을 기준으로 각자 맞추는 구조를 겨냥한다.

지난 1편에서 카드 네트워크의 핵심은 참여자가 따르는 규칙에 있다고 했다. 이와 비슷하게 PayChain에서는 그 규칙이 Receipt에서 시작한다. 검증 가능한 기록이 먼저 있어야 여러 회사가 협력하고, 결제와 금융 서비스도 그 위에 쌓일 수 있다. 정산이 PayChain의 출발점인 이유다.

다음 글에서는 이 기록이 올라가는 체인을 다룬다. Receipt의 해시값이 기록되는 PayChain은 왜 자체 체인을 구축했는지, 누가 네트워크에 참여 가능하고 PCI는 그 안에서 무엇을 하는지 살펴본다.