8.4 · 검증과정
발생했습니다 ≠ 확인되었습니다. 검증 체인을 완료한 후에만 결과가 PoB 원장에 입력되고 장기적인 가치 입력이 됩니다.
온체인 합의가 확인하는 것은 거래 순서와 상태 전환입니다. PoB가 확인하는 것은 “이런 일이 업계에서 주장하는 대로 일어났는가”이다. 검증 프로세스는 자료의 완전성, 시간 일관성, 속성의 자체 일관성 및 제외 규칙과의 비교(8.3)와 같은 주관적인 설명을 감사 가능한 워크플로로 압축합니다.
확인을 위한 5단계(워크플로 보기)
① 이벤트 응모
최종 상태에 대한 고유 이벤트 번호를 생성하고 거래, 작업, 관련 노드 및 명세서 유형(금융/서비스/성장 등)을 바인딩합니다. 제출에는 증명 책임이 있습니다. 자료에 공백이 있을 경우 제출자는 제한 시간 내에 이를 채워야 합니다.
② 증거패키지 업로드
템플릿에 따라 계약서, 온체인 참조, 은행/에스크로 경로(규정 준수 완화), 이메일/회의록, 수락 양식 등을 제출하세요. GIPS와 유사: 데이터는 단순히 "신청자를 신뢰"하는 것이 아니라 독립적인 당사자가 결론을 검토하기 위해 합리적인 노력을 기울일 수 있을 만큼 충분해야 합니다.
③ 검토 대기열
감사자는 진위성(제3자와 일치하는지 또는 체인에 있는지 여부), 무결성(최종 상태가 닫혀 있는지 여부), 시간 순서(날짜가 소급되었는지 여부), 귀속 경계(8.5와 충돌하는지 여부), 제외 규칙(8.3에 속하는지 여부)을 확인합니다. 다중 서명, 순환 또는 샘플링 감사와 결합할 수 있습니다.
④ 결론 생성
통과 / 보충 / 거부됨 / 분쟁 에스컬레이션. 끝없는 지연을 방지하기 위해 보충 문서의 빈도와 시간 제한이 있어야 합니다. 분쟁에 대한 이의제기 기록은 "침묵 통과"를 방지하기 위해 보관되어야 합니다.
⑤ 고려사항 제출
통과 후 PoB 이벤트 원장(결론 해시, 키 메타데이터 및 버전 포함)이 기록됩니다. 이 기록은 감사된 성과 항목과 유사합니다. 이는 후속 정산, 평판 및 재검증을 위한 기준점 역할을 할 수 있습니다.
PoW와 비교: 채굴자가 증명하는 것은 컴퓨팅 파워입니다. PoB 감사가 증명하는 것은 자료와 사실의 일관성입니다. PoA와의 비교: PoA는 인증자의 신원을 신뢰합니다. PoB에는 여전히 증거 패키지가 필요하며 검토자의 신원이 자료를 대체하지 않습니다.
증명데스크 : 네트워크 디스크가 아닌 검증센터
증거 수집구조화된 필드 + 첨부 파일 버전; 채팅 창에서 파일이 손실되어 감사할 수 없도록 만드는 것을 방지하세요.
경영 검토대기열 우선순위, SLA, 이중 검토 또는 무작위 검사 규칙을 관리할 수 있습니다.
논쟁의 여지를 남겨두세요후속 검토 및 규칙 반복을 용이하게 하기 위해 이의제기 및 판결에 대한 이유는 뒤에 남겨집니다.
출력 결론최종 상태를 명확히 합니다. PoB 진입 여부; 실패하면 장기적인 가치 분배 의미론에 들어가지 않습니다.
부정행위 방지는 프로세스 수준에서 이루어집니다.
- 교차 확인: 온체인 시간, 제3자 이메일 도메인 이름, 계약 번호가 공개된 내용과 일치합니까?
- 상호 배타적 이벤트: 판결에 의해 분할되지 않는 한 동일한 자금 조달 라운드 및 동일한 승인 대상에 대해 하나의 보관된 지배 체인만 허용됩니다.
- 냉각 및 빈도: 비정상적으로 높은 빈도의 템플릿 소재는 수동 또는 알고리즘 지원 검토를 유발합니다.
검증 과정을 통해 WCN은 "가장 목소리가 큰 사람"에서 "가장 견고한 재료를 가진 사람"으로 바뀌었습니다. 이 단계가 없으면 PoB는 오프체인 Excel 기록 크레딧과 다르지 않으며 변조에 더 취약합니다.