나이트셰이드(Nightshade)에서는 샤드마다 청크 생산자(chunk producer)가 그 샤드의 거래와 들어온 영수증(receipt)을 실행할 청크를 만들고, 검증 참여자들이 청크의 유효성과 가용성을 확인합니다. 블록 생산자는 모든 샤드 데이터를 한 덩어리로 직접 실행하지 않고, 승인된 청크 헤더들을 블록에 모읍니다. 샤드를 넘나드는 호출의 결과는 영수증 형태로 목적 샤드의 이후 청크에서 처리되므로, 거래 하나처럼 같은 순간에 끝난다고 보면 안 됩니다.
블록 하나가 모든 샤드 데이터를 직접 품는 것은 아니다
나이트셰이드는 여러 샤드가 나란히 상태를 처리하면서도 하나의 체인처럼 블록을 만듭니다. 샤드마다 청크가 있고, 블록에는 각 청크의 헤더와 약정(commitment)이 들어갑니다. 청크 헤더는 이전 상태 루트, 새 상태 루트, 거래·영수증 결과와 데이터 가용성 정보를 블록 단위에서 이어 줍니다.
블록 생산자를 모든 샤드 거래를 처음부터 다시 실행하는 중앙 실행자로 이해하면 샤딩 구조를 놓칩니다. 샤드를 맡은 청크 생산자와 검증자들이 데이터를 만들고 확인하며, 블록 생산자는 합의할 수 있는 청크 헤더를 모아 블록 제안을 꾸립니다. 빠진 청크가 있을 때도 프로토콜의 이전 청크 정보와 처리 규칙을 확인해야 합니다.
나이트셰이드의 블록은 샤드 실행을 대신하는 상자가 아니라, 각 샤드 청크의 검증 결과를 같은 높이에 묶어 주는 띠입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 블록 하나가 모든 샤드 데이터를 직접 품는 것은 아니다
나이트셰이드는 여러 샤드가 나란히 상태를 처리하면서도 하나의 체인처럼 블록을 만듭니다.
- 청크 생산자는 입력과 새 상태를 묶는다
청크 생산자는 자기가 맡은 샤드의 대기 거래와 이전 블록에서 도착한 영수증을 처리해 새 청크를 만듭니다.
- 영수증이 샤드 사이의 비동기 경로다
한 샤드의 계약이 다른 샤드 계정을 호출해도, 공유 메모리처럼 곧바로 상태가 바뀌지는 않습니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
청크 생산자는 입력과 새 상태를 묶는다
청크 생산자는 자기가 맡은 샤드의 대기 거래와 이전 블록에서 도착한 영수증을 처리해 새 청크를 만듭니다. 그 결과 상태 루트가 바뀌고 내보낼 영수증이 생깁니다. 청크 데이터는 삭제 부호화(erasure coding)와 분배를 거쳐, 참여자가 필요한 조각을 받아 복구하고 검증할 수 있게 됩니다.
서명된 청크 헤더가 보인다고 모든 참여자가 샤드 상태 전체를 갖고 있다는 뜻은 아닙니다. 어느 검증자가 어떤 샤드를 추적하고 어떤 조각을 받아 검증하는지는 에포크 배정과 프로토콜 버전에 달려 있습니다. 문서에 남은 초기 나이트셰이드 설계와, 현재 구현이 옮겨 가고 있는 무상태 검증(stateless validation)을 구분해야 합니다.
| 역할 | 만드는·확인하는 것 | 오해하기 쉬운 경계 |
|---|---|---|
| 청크 생산자 | 샤드 청크와 상태 전이 | 블록 전체를 조립하지 않음 |
| 청크 검증자·보증자 | 청크 유효성·가용성 신호 | 모든 샤드 상태 보유를 보장하지 않음 |
| 블록 생산자 | 청크 헤더를 블록에 포함 | 샤드 간 결과가 모두 즉시 끝나지 않음 |
| 영수증 처리 샤드 | 목적 샤드에서 영수증 실행 | 원래 거래와 같은 샤드일 필요 없음 |
영수증이 샤드 사이의 비동기 경로다
한 샤드의 계약이 다른 샤드 계정을 호출해도, 공유 메모리처럼 곧바로 상태가 바뀌지는 않습니다. 실행은 내보낼 영수증을 만들고, 이 영수증은 경로를 거쳐 목적 샤드의 수신 영수증 대기열에 들어갑니다. 목적 샤드의 이후 청크가 영수증을 실행하고, 다시 결과 영수증을 만들 수도 있습니다.
따라서 처음 거래가 블록에 포함됐다는 사실과 샤드 간 작업 흐름이 최종 성공했다는 사실은 다릅니다. 탐색기에서는 거래 결과와 영수증 결과 ID를 따라가며 각 실행 상태와 블록 높이를 확인해야 합니다. 중간 영수증 실패나 콜백 결과도 따로 처리합니다.
- 원래 거래의 블록 높이와 출발 샤드를 기록합니다
- 생성된 영수증 ID와 받는 샤드를 순서대로 추적합니다
- 영수증 결과마다 상태·로그·가스를 확인합니다
- 마지막 콜백이나 앱 상태 변화까지 완료 기준을 정합니다
청크 누락은 거래 실패와 같지 않다
어떤 블록에 새 청크가 들어가지 않았거나 청크 마스크가 비어 보여도, 그 샤드의 거래가 모두 영구 실패했다고 단정할 수는 없습니다. 생산자 지연, 보증 부족, 데이터 가용성 문제 같은 원인을 확인하고, 다음 블록에서 샤드 진행이 이어지는지 봅니다. 블록 헤더의 chunks_included와 개별 청크 헤더를 맞춰 봅니다.
반대로 블록 높이가 계속 올라가도 특정 샤드의 청크가 거듭 빠지면 그 샤드 사용자에게 지연이 몰릴 수 있습니다. 체인 전체의 평균 블록 시간만 보면 놓칩니다. 샤드별 청크 포함 여부, 가스 사용량, 영수증 적체, 검증자 배정을 지켜봐야 합니다.
현재 구조를 역사 문서와 섞지 않는다
초기 나이트셰이드 논문은 설계 원리와 데이터 분배를 자세히 설명합니다. 하지만 니어(NEAR)는 프로토콜 업그레이드를 거치며 청크 검증과 무상태 검증을 발전시켜 왔습니다. 논문 속 역할 이름과 메시지 흐름을 현재 메인넷 구현의 변하지 않는 사실로 단정하지 않습니다. 현재 공식 문서, 프로토콜 버전, 릴리스 노트를 함께 확인합니다.
그래도 핵심 경계는 그대로입니다. 샤드별 청크 생성, 검증과 가용성 확인, 블록의 청크 헤더 결합, 영수증 기반 샤드 간 실행입니다. 분석 보고서에는 관측한 블록의 프로토콜 버전을 적어 설계 설명과 운영 사실을 이어 줘야 합니다.
자주 묻는 질문
블록 생산자가 모든 샤드 거래를 직접 실행하나요?
그렇게 단순화할 수는 없습니다. 샤드별 청크 생산과 검증이 따로 있고, 블록 생산자는 확인된 청크 헤더를 블록에 묶습니다.
원래 거래가 성공하면 샤드 간 호출도 끝난 건가요?
아닙니다. 생성된 영수증이 목적 샤드와 콜백에서 차례로 처리된 결과를 끝까지 확인해야 합니다.
청크가 빠진 블록은 잘못된 블록인가요?
항상 그렇지는 않습니다. 프로토콜의 누락 처리 규칙, 다음 블록 진행, 보증·가용성 상태를 확인해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
