종료된 모든 라운드는 계정이나 특별한 권한 없이, 공개된 온체인 데이터만으로 직접 검증할 수 있습니다. 확인할 사항은 세 가지입니다. 라운드 시작 전에 커밋 해시가 게시되었는지, 공개된 비밀값의 해시가 그 커밋과 일치하는지, 그리고 공개 공식을 다시 계산하면 해당 라운드의 지급 기준이 된 결과가 그대로 재현되는지입니다.
이 가이드에서는 종료된 Crash 라운드 하나를 처음부터 끝까지 검증합니다. 운영자의 비밀값이 라운드 이전에 커밋되었는지, 그리고 크래시 지점이 공개 공식이 산출하는 값과 정확히 같은지를 확인합니다. 특별한 권한은 필요하지 않으며, 모든 데이터는 공개 온체인 데이터에서 가져옵니다. 마지막의 짧은 섹션에서는 각각 한두 건의 트랜잭션만으로 검증할 수 있는 Dice와 Mines를 다룹니다.
증명하려는 내용
- 커밋이 먼저 이루어졌습니다. 비밀값의 해시가 라운드 시작 전에 이미 온체인에 있었으므로, 베팅 이후에 결과를 골라낼 수 없습니다.
- 비밀값이 커밋과 일치합니다.
sha256(secret)이 커밋된 해시와 같습니다.
- 배수가 정직합니다. 비밀값과 블록 해시로 공식을 다시 계산하면, 라운드의 지급 기준이 된 크래시 지점이 정확히 나옵니다.
1단계: 앱에서 라운드의 공정성 데이터 열기
베팅 기록(또는 라운드 기록)을 열고 종료된 라운드를 클릭해 상세 정보를 엽니다. 라운드 결과와 함께 다음 항목이 표시됩니다.
- 크래시 배수: 검증할 최종 배수입니다.
- 게임 비밀값 해시: 공개된 32바이트 비밀값입니다. Solana 익스플로러의 커밋 트랜잭션으로 연결됩니다.
- 블록 해시: 체인 엔트로피로 사용된 Solana 슬롯 해시입니다. 라운드 시작 트랜잭션으로 연결됩니다.
- “이 게임은 공정한가요? 공정성 검증 도구 사용”: 이 라운드 정보가 미리 입력된 공정성 검증 도구를 엽니다. 도구가 라운드의 세 트랜잭션 서명(커밋, 블록 해시, 공개)과 네트워크를 가져와, 아래의 모든 계산을 클릭 한 번으로 다시 수행합니다.
공정성 검증 도구가 가장 편리한 방법입니다. 이 페이지의 나머지 부분은 체인과 본인의 컴퓨터 외에는 아무것도 신뢰하지 않는, 완전히 독립적인 방법을 설명합니다.
2단계: 라운드를 구성하는 세 트랜잭션
3단계: Solana 익스플로러에서 값 읽기
원하는 익스플로러(Solscan, Solana Explorer, SolanaFM 등)에서 앱이 실행되는 네트워크를 선택한 뒤 각 트랜잭션을 엽니다. 트랜잭션 페이지에서 디코딩된 프로그램 이벤트를 찾습니다(“Logs” 또는 “Instruction data” 아래에 있는 경우도 있습니다. 프로그램의 IDL을 인식하는 익스플로러는 이벤트 필드를 이름별로 디코딩해 보여 줍니다).
다음 네 가지 값을 수집합니다.
commit_hash: 커밋 트랜잭션의 32바이트 값.
blockhash: 블록 해시 트랜잭션의 32바이트 값.
local_e: 공개 트랜잭션의 32바이트 비밀값.
crash_point_bps: 공개 트랜잭션에 담긴 최종 크래시 지점(베이시스 포인트 단위, 29948은 2.9948x를 뜻합니다).
인코딩익스플로러는 사이트에 따라 32바이트 값을 hex, base58 또는 바이트 배열로 표시합니다. 아래 스크립트는 hex를 입력으로 받으므로, 익스플로러가 base58로 표시한다면 변환해 주세요(어떤 base58 디코더를 사용해도 됩니다. 중요한 것은 표기 방식이 아니라 바이트 값입니다).
4단계: 순서 확인
익스플로러에서 커밋 트랜잭션과 블록 해시 트랜잭션의 슬롯(또는 블록 시간)을 비교합니다. 커밋이 더 앞서야 합니다. 이것이 이 방식의 핵심입니다. 비밀값은 결합될 엔트로피가 존재하기도 전에 봉인되었습니다.
5단계: 크래시 지점 다시 계산하기
3단계에서 얻은 세 개의 hex 문자열을 채워 넣고 Node.js로 실행합니다(의존성 없음).
두 가지 확인을 모두 통과해야 합니다. commitment ok: true가 출력되고, 출력된 크래시 지점이 라운드의 크래시 배수(그리고 공개 이벤트의 crash_point_bps)와 같아야 합니다. 둘 다 일치한다면, 누구도 신뢰할 필요 없이 이 라운드의 결과가 시작 전에 확정되었고 공개 공식으로 정확히 계산되었음을 증명한 것입니다.
Dice와 Mines
즉석 게임도 같은 방식으로 검증하며, 필요한 트랜잭션 수가 더 적습니다.
- Dice: 베팅마다 트랜잭션 하나.
DiceBetSettled 이벤트에 모든 도출 입력값(slothash, user, nonce)과 roll, 지급액이 담겨 있습니다. Dice 공정성의 공식으로 다시 계산합니다.
- Mines: 게임마다 트랜잭션 두 개. 시작 트랜잭션이 보드 커밋과 슬롯 해시를 게시하고, 정산 트랜잭션이 시드와 전체 보드를 공개합니다. Mines 공정성의 공식으로 다시 계산합니다.
값이 일치하지 않는다면
먼저 흔한 원인부터 배제하세요. hex가 필요한 곳에 base58 값을 붙여 넣었거나, 잘못된 트랜잭션을 사용했거나(라운드마다 세 개가 있습니다), 라운드 당시와 다른 하우스 엣지를 사용했을 수 있습니다(하우스 엣지는 온체인 설정에 저장되며, 변경될 때마다 그 자체가 온체인 트랜잭션으로 남습니다).
그래도 실제로 불일치한다면, 이 시스템은 바로 그런 경우를 드러내기 위해 존재합니다. 데이터는 공개되어 영구적으로 남으므로 누구나 같은 검증을 다시 실행할 수 있습니다. 라운드 번호와 함께 고객 지원팀에 문의해 주세요. 커밋이나 공식이 실제로 불일치하는 경우에 정직한 설명은 존재할 수 없으며, 바로 그렇기 때문에 이 방식에서는 불일치를 숨기는 것이 불가능합니다.