모네로 Payment ID: 왜 폐지되었고 무엇이 대체했는가

Payment ID의 흥망성쇠

Payment ID는 한때 모네로 생태계에서 어디서나 볼 수 있는 기능이었습니다. 2019년 이전에 모네로를 사용했다면, 거래소에 입금하거나 상인에게 결제할 때 거의 확실히 이를 접했을 것입니다. 이 추가 식별자는 수신자가 여러 수신 결제를 구분하는 데 도움을 주기 위해 트랜잭션에 첨부되었습니다. 유용성에도 불구하고, Payment ID는 심각한 프라이버시 및 사용성 문제를 도입하여 결국 폐지로 이어졌습니다.

이 역사를 이해하는 것은 오늘날 모네로를 사용하는 모든 사람에게 중요하며, 특히 여전히 Payment ID를 참조하는 이전 서비스와 상호작용할 때 그렇습니다. MoneroSwapper를 통해 교환하거나 자체 지갑을 관리하든, Payment ID를 대체한 것과 그 이유를 아는 것은 더 안전하게 거래하는 데 도움이 됩니다.

Payment ID란 무엇이었는가?

Payment ID는 모네로 트랜잭션에 첨부할 수 있는 64자 16진수 문자열(32바이트)이었습니다. 블록체인 트랜잭션에 직접 내장된 참조 번호나 인보이스 ID로 생각할 수 있습니다. 두 가지 유형이 있었습니다:

긴 Payment ID (비암호화)

원래 Payment ID 형식은 트랜잭션의 추가 필드의 일부로 평문으로 전송되는 32바이트 문자열이었습니다. 긴 Payment ID로 트랜잭션을 보내면, 블록체인을 보는 누구나 Payment ID 값을 볼 수 있었습니다. 이것은 가장 초기의 방법이었으며 거래소와 결제 처리기에서 널리 사용되었습니다.

프라이버시 관점에서 문제는 즉시 명백했습니다: 거래소가 입금 주소를 공개하고 각 사용자에게 고유한 Payment ID를 할당하면, 관찰자는 해당 거래소의 모든 입금을 식별하고 타이밍이나 금액 분석을 통해 Payment ID를 특정 사용자와 연결할 수 있었습니다.

암호화된 Payment ID (짧은 Payment ID)

평문 문제를 해결하기 위해, 모네로는 2017년에 암호화된 Payment ID를 도입했습니다. 이것은 트랜잭션의 일회성 키에서 파생된 공유 비밀로 암호화된 8바이트 값이었습니다. 수신자만이 자신의 개인 뷰 키를 사용하여 Payment ID를 복호화할 수 있었습니다. 블록체인에서 암호화된 Payment ID는 다른 모든 사람에게 랜덤 데이터로 나타났습니다.

암호화된 Payment ID는 통합 주소와 번들되었으며, 표준 모네로 주소와 8바이트 Payment ID를 단일 주소 문자열로 결합했습니다. 발신자가 별도의 Payment ID 필드를 수동으로 복사하여 붙여넣을 필요가 없었기 때문에 사용하기가 더 쉬웠습니다.

거래소와 서비스가 Payment ID를 사용한 이유

Payment ID의 실질적 이유는 간단했습니다: 거래소와 상인은 수신 결제를 특정 사용자나 주문에 귀속시킬 필요가 있었습니다. 모네로가 모든 트랜잭션 출력을 고유하게 만드는 스텔스 주소를 사용하기 때문에, 매일 수천 건의 입금을 받는 서비스는 어떤 입금이 어떤 고객에게 속하는지 결정하는 메커니즘이 필요했습니다.

일반적인 워크플로우는 다음과 같았습니다:

• 거래소는 모든 사용자에게 같은 입금 주소를 주되, 각 사용자에게 고유한 Payment ID를 할당
• 사용자는 할당된 Payment ID와 함께 거래소 주소로 XMR을 전송
• 거래소는 수신 트랜잭션에서 Payment ID를 스캔하여 올바른 계정에 입금

이 시스템은 작동했지만 취약했습니다. 사용자들이 Payment ID를 포함하는 것을 자주 잊어 입금이 분실되었고, 거래소 지원 팀의 수동 복구가 필요했습니다. 이것은 모네로를 지원하는 거래소에서 가장 흔한 지원 문제 중 하나였으며 사용자 불만의 주요 원인이었습니다.

Payment ID의 프라이버시 문제

암호화된 Payment ID조차 모네로의 핵심 프라이버시 보장을 약화시키는 여러 프라이버시 취약점을 도입했습니다:

메타데이터를 통한 연결 가능성

거래소의 모든 사용자가 같은 주소로 보낼 때, 스텔스 주소 메커니즘이 약화되었습니다. 관찰자는 공개 주소를 인식하여 트랜잭션이 특정 거래소로 향하는 것을 식별할 수 있었습니다. Payment ID는 암호화되더라도 트랜잭션에 구별되는 메타데이터를 추가했습니다. Payment ID가 있는 트랜잭션은 없는 트랜잭션과 다르게 보여, 익명성 집합을 줄이는 두 가지 클래스의 트랜잭션을 생성했습니다.

이중 풀 문제

Payment ID가 있는 트랜잭션과 없는 트랜잭션은 블록체인에서 시각적으로 구별되는 두 개의 풀을 형성했습니다. 이 구별은 체인 분석가에게 정보를 제공했습니다. 트랜잭션에 암호화된 Payment ID가 포함되어 있으면 거래소나 상인에게 가는 것이 매우 가능성이 높아, 가능한 수신자를 크게 좁혔습니다.

타이밍 및 패턴 분석

거래소는 일반적으로 입금을 배치로 처리하거나 예측 가능한 타이밍으로 처리했습니다. 단일 입금 주소 모델과 결합하면, 이는 정교한 분석가가 이용할 수 있는 패턴을 만들었습니다. 알려진 주소, 타이밍 패턴, Payment ID의 존재가 결합되어 상관 공격이 더 실행 가능해졌습니다.

사용자 오류에 의한 프라이버시 누출

사용자가 Payment ID를 잊었을 때, 종종 지원에 연락하여 트랜잭션이 자신의 것임을 증명해야 했습니다. 이는 일반적으로 트랜잭션 개인 키나 뷰 키 정보를 공유하는 것을 포함하여, 추가적인 프라이버시 누출과 신원을 트랜잭션에 연결하는 기록을 생성했습니다.

폐지 타임라인

모네로 커뮤니티는 이러한 문제를 인식하고 여러 프로토콜 업그레이드를 통해 조치를 취했습니다:

• 2018년 (v0.13, Beryllium Bullet) — 긴 (비암호화) Payment ID가 폐지되고, 사용자가 사용하려 할 때 지갑 소프트웨어가 경고를 표시하기 시작
• 2019년 (v0.15, Carbon Chamaeleon) — 긴 Payment ID가 프로토콜 수준에서 금지됨. 비암호화 Payment ID가 있는 트랜잭션은 네트워크에서 거부
• 지갑 소프트웨어 업데이트 — GUI 및 CLI 지갑이 점진적으로 Payment ID 필드를 제거하고 서브어드레스 사용을 권장
• 거래소 마이그레이션 — 주요 거래소가 2019년과 2020년에 Payment ID에서 서브어드레스로 마이그레이션, 일부 후발 주자는 더 오래 걸림

통합 주소를 통한 암호화된 (짧은) Payment ID는 기술적으로 프로토콜 수준에서 여전히 작동하지만, 강력히 비권장됩니다. 현대 지갑 소프트웨어는 해당 옵션을 완전히 숨기거나 명확한 경고를 표시합니다. 커뮤니티 합의는 서브어드레스가 올바른 대체안이라는 것입니다.

서브어드레스: 우수한 대체안

서브어드레스는 Payment ID의 권장 대체안으로 도입되었습니다. 서브어드레스는 지갑만이 계산할 수 있는 수학적 관계를 사용하여 주 지갑 주소에서 파생된 고유한 주소입니다. 각 서브어드레스는 주소에 암호학적으로 연결되어 있지만, 이 연결은 외부 관찰자에게 보이지 않습니다.

서브어드레스 작동 방식

모네로 지갑은 기본 주소에서 실질적으로 무제한의 서브어드레스를 생성할 수 있습니다. 각 서브어드레스는 블록체인을 보는 누구에게나 완전히 독립적인 모네로 주소처럼 보입니다. 누군가 서브어드레스로 XMR을 보내면, 트랜잭션 출력은 서브어드레스의 공개 키를 사용하여 스텔스 주소를 생성하여, 지갑만이 결제를 식별할 수 있도록 합니다.

Payment ID 대비 서브어드레스의 주요 장점은 다음과 같습니다:

• 공유 주소 없음 — 각 고객이나 결제에 고유한 주소가 제공되어, 단일 주소 문제를 완전히 제거
• 메타데이터 누출 없음 — 서브어드레스로의 트랜잭션은 블록체인에서 주 주소로의 트랜잭션과 동일하게 보임
• 사용자 오류 없음 — 사용자는 제공된 주소로 보내기만 하면 되며 추가 Payment ID 필드를 기억할 필요 없음
• 연결 불가 — 관찰자는 두 서브어드레스가 같은 지갑에 속하는지 결정할 수 없음
• 이중 풀 문제 없음 — 주 주소든 서브어드레스든 모든 트랜잭션이 동일하게 보임

거래소를 위한 서브어드레스

이전에 Payment ID를 사용하던 거래소의 경우, 서브어드레스로의 마이그레이션은 보안과 사용자 경험 모두를 개선했습니다. 모든 사용자에게 다른 Payment ID와 함께 같은 주소를 주는 대신, 거래소는 이제 각 사용자에게 고유한 서브어드레스를 생성합니다. 거래소의 지갑은 어떤 서브어드레스가 입금을 받았는지 자동으로 식별하고 올바른 계정에 입금합니다.

이 접근 방식은 가장 흔한 지원 문제(잊어버린 Payment ID)를 제거하면서 동시에 모든 사용자의 프라이버시를 개선했습니다. 더 프라이빗한 솔루션이 더 사용자 친화적인 솔루션이기도 한 드문 경우였습니다.

여전히 Payment ID를 사용하는 서비스를 위한 마이그레이션 가이드

여전히 Payment ID를 사용하는 서비스를 운영하고 있다면, 서브어드레스로의 마이그레이션은 간단합니다:

• 서브어드레스 생성 — 지갑 RPC 메서드 create_address를 사용하여 각 사용자 계정에 고유한 서브어드레스 생성
• 매핑 저장 — 사용자 계정과 할당된 서브어드레스 간의 데이터베이스 매핑 유지
• 입금 안내 업데이트 — 입금 인터페이스에서 Payment ID 필드를 제거하고 서브어드레스만 표시
• 수신 트랜잭션 모니터링 — 각 수신 트랜잭션에 대해 서브어드레스 인덱스를 자동으로 보고하는 get_transfers RPC 메서드 사용
• 하위 호환성 유지 — 전환 기간 동안, 오래된 입금 안내를 캐시한 사용자가 영향받지 않도록 이전 Payment ID 트랜잭션을 계속 스캔

Payment ID를 요청하는 서비스를 만났을 때

폐지된 지 수년이 지났음에도, 일부 소규모 거래소와 서비스는 여전히 Payment ID를 요청합니다. 이 상황을 만나면 다음을 알아야 합니다:

주의하여 진행하세요. 2026년에도 여전히 Payment ID를 사용하는 서비스는 모네로 프로토콜 변경을 따라가지 않을 수 있으며, 이는 더 광범위한 유지보수 및 보안 우려를 나타낼 수 있습니다. 해당 서비스가 신뢰할 수 있는지 고려하세요.

제공되면 통합 주소를 사용하세요. 서비스가 통합 주소(Payment ID가 내장됨)를 제공하면, 지갑이 Payment ID를 자동으로 처리합니다. 긴 Payment ID를 수동으로 입력하는 것보다 바람직합니다.

Payment ID를 재확인하세요. 수동으로 Payment ID를 입력해야 하는 경우, 주의깊게 복사하여 붙여넣으세요. 모든 문자를 확인하세요. 잘못된 Payment ID는 복구하기 어려울 수 있는 자금 손실을 의미합니다.

대안을 고려하세요. 서비스가 긴 (비암호화) Payment ID를 요구하면, 현대 모네로 소프트웨어는 트랜잭션을 거부할 가능성이 높습니다. 다른 서비스를 사용하거나 서브어드레스로 업데이트하도록 요청해야 할 수 있습니다. MoneroSwapper와 같은 서비스는 Payment ID가 필요 없는 현대적인 인프라를 사용합니다.

더 넓은 교훈

Payment ID의 폐지는 모네로 개발 철학의 핵심 원칙을 보여줍니다: 프라이버시는 암호화 기본 요소뿐만 아니라 프로토콜 설계와 실제 사용 패턴에 관한 것입니다. 강력한 암호화에도 불구하고, Payment ID가 만든 메타데이터와 행동 패턴은 프라이버시 보장을 약화시키기에 충분했습니다.

Payment ID를 서브어드레스로 대체함으로써, 모네로는 사용성을 개선하면서 전체 프라이버시 누출 범주를 제거했습니다. 실제 프라이버시 분석에 기반한 이러한 프로토콜의 반복적 개선은 프라이버시를 기본 요구 사항이 아닌 기능으로 취급하는 프로젝트와 모네로를 구별짓는 것입니다. Payment ID의 제거는 구별되는 메타데이터를 제거하고 더 균일한 트랜잭션 풀을 생성하여 모든 모네로 트랜잭션을 더 프라이빗하게 만들었습니다.

오늘날 사용자에게 실질적인 메시지는 간단합니다: 모든 것에 서브어드레스를 사용하고, 가능하면 여전히 Payment ID를 요구하는 서비스를 피하며, 이 겉보기에 작은 프로토콜 변경이 모든 사람의 모네로 프라이버시를 강화하기 위한 수년간의 연구와 커뮤니티 노력을 나타낸다는 것에 감사하세요.