먼저, 증명해야 할 문제를 명확하게 명시해야 합니다.
블록을 검토할 때 흔히 묻는 질문에는 거래가 포함되어 있는지 여부, 실행 결과, 특정 블록에서 계정의 상태 등이 있습니다. 이러한 질문들은 각각 다른 데이터와 증명을 필요로 합니다. 블록 헤더의 루트 해시는 해당 데이터 구조에 대한 확약을 제공하지만, 루트 해시 자체는 계정 목록을 직접 읽을 수 있는 형태가 아니며, 거래가 특정 비즈니스 결과를 생성하는 이유를 설명하지도 않습니다.
트랜잭션 루트는 트랜잭션 집합에 해당합니다.
트랜잭션 루트는 블록 내에서 순차적으로 정리된 트랜잭션과 관련이 있습니다. 트랜잭션의 포함 관계를 검증할 때는 네트워크, 블록 헤더, 그리고 해당 증명 구조를 동시에 알아야 합니다. 트랜잭션이 포함되었다고 해서 실행이 성공적으로 완료되었다는 것을 보장하는 것은 아니며, 수신 플랫폼이 해당 트랜잭션을 고객 계정에 입금했다는 것을 의미하는 것도 아닙니다. 브라우저 링크는 단순히 쿼리 진입점만 제공합니다. 공식적인 검증을 위해서는 노드, 브라우저, 또는 검증된 블록 헤더 중 어느 것을 신뢰하는지 명확히 하는 것이 중요합니다.
영수증 루트는 실행 결과에 해당합니다.
영수증에는 일반적으로 실행 상태, 누적 가스 사용량, 로그와 같은 정보가 포함됩니다. 영수증 루트는 이러한 실행 결과를 보장하며, 플랫폼의 고객 잔액을 보장하는 것은 아닙니다. 애플리케이션은 로그를 통해 활동을 식별할 수 있지만, 로그에 기록된 발행 계약, 파라미터 디코딩, 거래 상태를 모두 함께 검토해야 합니다. "Transfer"라는 이름의 이벤트가 있다고 해서 토큰 계약의 진위 여부 및 실행 결과에 대한 검증을 건너뛸 수 있는 것은 아닙니다.
상태 루트는 특정 블록의 상태를 설명합니다.
상태 루트는 특정 상태의 스냅샷에 해당하며, 계정 잔액, 논스, 코드, 저장소와 관련된 구조를 포함할 수 있습니다. 증명에는 고정된 블록이 필요하며, 어제의 증명을 오늘 적용할 수 없습니다. 특정 저장소 슬롯에 대한 유효한 증명이 토큰 경제, 관리 기관 또는 외부 오라클에 대한 위험이 없음을 보장하는 것은 아닙니다. 기술적 약속의 범위는 마케팅 자료에 나오는 "온체인에서 완전히 검증 가능"이라는 주장보다 더 구체적이어야 합니다.
교차 필드 검증 예시
사용자가 계약 호출을 확인하려는 경우를 가정해 보겠습니다. 먼저 트랜잭션이 입력된 블록을 확인하고, 수신 성공 여부와 이벤트 매개변수를 확인한 다음, 질문에 따라 관련 계정 또는 계약 상태를 조회합니다. 브라우저와 애플리케이션에 다른 정보가 표시되는 경우, 어느 한쪽이 사기라고 단정하기보다는 참조된 블록 높이나 네트워크가 다른지 확인해야 합니다. 이 예시는 증거 수준을 설명하기 위한 것이며, 어떤 계약에 대한 감사 결론을 구성하는 것은 아닙니다.
증명 컨텍스트 보존
체인 식별자, 블록 높이 및 해시, 루트 해시 유형, 쿼리 방법, 증명 데이터 및 도구 버전을 보존합니다. 타사 디코딩 서비스를 사용하는 경우, 해당 서비스의 역할과 잠재적인 캐싱 지연 시간을 명시합니다. 최종성 및 체인 재구성은 여전히 선택된 블록의 상태에 영향을 미칩니다. 데이터 증명을 검증하되, 명시적인 기술적 질문에만 답변하고 서비스 주체, 자산 준비금 또는 향후 상환 가능성을 증명하지 마십시오.