거래소에 보유량 증명이 있는지 어떻게 확인하나요?

준비금 증명 이해하기

1. PoR(지분 증명)은 거래소가 모든 사용자 잔액을 감당할 만큼 충분한 온체인 자산을 보유하고 있음을 입증하는 암호화 감사 메커니즘입니다.

2. 이는 공개 블록체인 데이터, 머클 트리 구조, 독립 감사인의 서명된 증명 또는 거래소 자체 다중 서명 지갑에 의존합니다.

3. 유효한 PoR 보고서에는 스냅샷 시간, 거래소가 관리하는 전체 지갑 주소 목록, 내부 사용자 잔액 기록에서 파생된 일치 부채 계산이 포함되어야 합니다.

4. 거래소의 개인 키는 절대 노출되지 않습니다. 대신 스냅샷 시점의 총 자산 가치를 약속하는 메시지에 서명합니다.

5. 사용자는 오픈 소스 도구나 Arkham 또는 Chainalytic Explorer와 같은 제3자 검증 도구를 사용하여 Merkle 트리에 자신의 계정이 포함되었는지 독립적으로 확인할 수 있습니다.

정품 PoR 보고서의 주요 구성 요소

1. 거래소의 콜드월렛에서 발행한 타임스탬프가 있는 암호화 서명으로, 예비 잔고를 특정 블록 높이에 연결합니다.

2. JSON 또는 CSV 파일로 게시되고 IPFS 또는 변조 방지 CDN에 호스팅되는 해당 잔액이 포함된 관리 주소의 전체 목록입니다.

3. 사용자가 신원이나 정확한 금액을 공개하지 않고도 잔액이 포함되어 있는지 확인할 수 있도록 하는 부채 데이터세트(종종 익명화되고 해시됨).

4. 방법론, 범위 제한 및 수행된 검증 단계를 자세히 설명하는 평판이 좋은 감사자가 작성한 독립적인 인증 진술서.

5. 총 사용자 책임 수치와 함께 자산 유형별로 구분된 순자산가치(NAV)를 표시하는 조정 표와 부족액이 명확하게 공개됩니다.

PoR 문서의 위험 신호

1. 특정 블록 해시 및 타임스탬프와 연결된 검증 가능한 암호화 서명이 없습니다.

2. 거래 내역 링크나 잔액 증명 없이 나열된 지갑 주소 - 정적 스크린샷 또는 확인할 수 없는 PDF만 가능합니다.

3. 개별 계정에 대한 지원 구조, 해싱 또는 포함 증명 없이 집계된 총계로 표시되는 부채 데이터입니다.

4. 무담보 대출, 스테이킹 파생상품 또는 합성 자산의 포함 여부를 명시하지 않고 “100% 준비금”을 주장합니다.

5. 게시 지연(청구된 스냅샷 시간으로부터 72시간 이상 경과) 또는 보고 기간 전반에 걸쳐 빈도가 일관되지 않습니다.

온체인 검증 단계

1. 거래소의 공식 PoR 발표를 찾아 서명된 메시지, 공개 키, 블록 높이 참조를 추출합니다.

2. Etherscan, Blockchair 또는 Mempool.space를 사용하여 각 지갑 주소를 쿼리하고 잔고가 명시된 블록 높이에서 보고된 값과 일치하는지 확인합니다.

3. 머클 트리 루트 및 리프 세트를 다운로드한 다음 오픈 소스 검증 스크립트(예: GitHub의 PoR 워킹 그룹에서 유지 관리하는 스크립트)를 실행하여 포함 증명을 검증합니다.

4. 특히 USDT 또는 USDC의 경우 알려진 온체인 스테이블코인 채굴 데이터와 부채 수치를 대조 확인하여 보고된 보유량과 공급량의 불일치를 감지합니다.

5. 스냅샷 직전이나 직후에 발생하는 지갑 간 전송을 블록체인 탐색기에서 검색합니다. 이는 잔액 조작이나 세탁 움직임을 나타낼 수 있습니다.

자주 묻는 질문

Q: 거래소가 머클 루트를 위조할 수 있나요? 그렇습니다. 부채 데이터 세트와 지갑 잔액을 모두 제어하는 ​​경우 일관되지만 오해의 소지가 있는 루트를 생성할 수 있습니다. 제3자가 사용자 잔액을 독립적으로 해싱하면 이를 방지할 수 있습니다.

Q: 지급 준비금 증명은 지급 능력을 보장합니까? 아니요. 순간적으로 자산 보관을 확인하지만 유동성, 대출 노출 또는 선물 부채나 마진 부채와 같은 오프체인 의무는 반영하지 않습니다.

Q: 왜 일부 거래소에서는 BTC 및 ETH에 대해서만 PoR을 게시하고 스테이블 코인은 생략합니까? Stablecoin 준비금에는 종종 오프체인 은행 관계 또는 토큰화된 재무부 지폐가 포함됩니다. 이러한 세부 정보를 공개하면 기밀 유지 계약을 위반하거나 규제 위험에 노출될 수 있습니다.

Q: 실시간 PoR이 가능한가요? 실제로는 아닙니다. 실시간 업데이트에는 Merkle 루트의 지속적인 재서명 및 재게시가 필요하므로 대기 시간 및 조정 오버헤드가 발생합니다. 가장 신뢰할 수 있는 구현에서는 시간별 또는 일일 스냅샷을 사용합니다.