Nightshade에서 각 shard의 chunk producer는 해당 shard의 transaction과 incoming receipt를 실행할 수 있는 chunk를 만들고, 검증 참여자들이 chunk의 유효성과 가용성을 확인합니다. block producer는 모든 샤드 데이터를 직접 한 덩어리로 실행하는 대신 승인된 chunk header들을 블록에 모읍니다. cross-shard 호출의 결과는 receipt로 목적 shard의 이후 chunk에서 처리되므로 한 transaction처럼 같은 순간에 끝난다고 보면 안 됩니다.
블록 하나가 모든 샤드 bytes를 직접 품는 것은 아니다
Nightshade는 여러 shard가 병렬로 상태를 처리하면서 하나의 체인처럼 block을 만듭니다. shard마다 chunk가 있고 block에는 각 chunk의 header와 commitment가 포함됩니다. chunk header는 이전 상태 root, 새 상태 root, transaction·receipt 결과와 데이터 가용성 정보를 블록 수준에서 연결합니다.
block producer의 역할을 모든 shard transaction을 처음부터 다시 실행하는 중앙 실행자로 이해하면 샤딩 구조를 놓칩니다. shard를 담당하는 chunk producer와 validators가 데이터를 만들고 확인하며, block producer는 합의 가능한 chunk headers를 모아 block proposal을 구성합니다. 누락 chunk가 있을 때도 프로토콜의 이전 chunk 정보와 처리 규칙을 확인해야 합니다.
Nightshade의 블록은 샤드 실행을 대신하는 상자가 아니라, 각 샤드 chunk의 검증 결과를 같은 높이에 연결하는 띠다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 블록 하나가 모든 샤드 bytes를 직접 품는 것은 아니다
Nightshade는 여러 shard가 병렬로 상태를 처리하면서 하나의 체인처럼 block을 만듭니다.
- chunk producer는 입력과 새 상태를 묶는다
chunk producer는 자신이 맡은 shard의 pending transactions와 이전 블록에서 도착한 receipts를 처리해 새 chunk를 만듭니다.
- receipt가 샤드 사이의 비동기 경로다
한 shard의 contract가 다른 shard account를 호출하면 즉시 공유 메모리처럼 상태를 바꾸지 않습니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
chunk producer는 입력과 새 상태를 묶는다
chunk producer는 자신이 맡은 shard의 pending transactions와 이전 블록에서 도착한 receipts를 처리해 새 chunk를 만듭니다. 결과에는 state root 변화와 outgoing receipts가 생깁니다. chunk 데이터는 erasure coding과 분배를 거쳐 참여자가 필요한 조각을 받고 복구·검증할 수 있게 합니다.
서명된 chunk header만 보인다고 모든 참여자가 전체 shard state를 보유한다는 뜻은 아닙니다. 어떤 validator가 어느 shard를 추적하고 어떤 parts를 받아 검증하는지는 epoch assignment와 프로토콜 버전에 좌우됩니다. 문서의 역사적 Nightshade 설계와 현재 구현의 stateless validation 전환을 구분해야 합니다.
| 역할 | 만드는·확인하는 것 | 오해하기 쉬운 경계 |
|---|---|---|
| chunk producer | shard chunk와 state transition | 전체 block 조립자 아님 |
| chunk validator/endorser | chunk 유효성·가용성 신호 | 모든 shard 상태 보유 보장 아님 |
| block producer | chunk headers를 block에 포함 | 모든 cross-shard 결과 즉시 완료 아님 |
| receipt processor | 목적 shard에서 receipt 실행 | 원 transaction과 같은 shard일 필요 없음 |
receipt가 샤드 사이의 비동기 경로다
한 shard의 contract가 다른 shard account를 호출하면 즉시 공유 메모리처럼 상태를 바꾸지 않습니다. 실행은 outgoing receipt를 만들고 routing을 거쳐 목적 shard의 incoming receipt queue에 들어갑니다. 목적 shard의 이후 chunk가 receipt를 실행하고 다시 결과 receipt를 만들 수 있습니다.
따라서 최초 transaction이 block에 포함됐다는 사실과 cross-shard workflow가 최종 성공했다는 사실은 다릅니다. explorer에서는 transaction outcome과 receipt outcome IDs를 따라가며 각 execution status와 block height를 확인해야 합니다. 중간 receipt 실패나 callback 결과도 별도로 처리합니다.
- 원 transaction의 block height와 source shard를 기록한다
- 생성된 receipt IDs와 receiver shard를 순서대로 추적한다
- 각 receipt outcome의 status·logs·gas를 확인한다
- 마지막 callback 또는 앱 상태 변화까지 완료 기준을 정의한다
chunk 누락은 transaction 실패와 같지 않다
특정 block에서 새 chunk가 포함되지 않거나 chunk mask가 비어 보인다면 해당 shard의 모든 transaction이 영구 실패했다고 단정할 수 없습니다. producer 지연, endorsement 부족, data availability 문제 등 원인을 확인하고 다음 block에서 shard 진행이 재개되는지 봅니다. block header의 chunks_included와 개별 chunk header를 대조합니다.
반대로 block height가 계속 증가해도 특정 shard의 chunk가 반복 누락되면 그 shard 사용자에게 지연이 집중될 수 있습니다. 체인 전체 평균 block time만 보면 놓칩니다. shard별 chunk inclusion, gas usage, receipt backlog와 validator assignment를 관측해야 합니다.
현재 구조를 역사 문서와 섞지 않는다
초기 Nightshade 논문은 설계 원리와 data distribution을 상세히 설명하지만 NEAR는 protocol upgrades를 통해 chunk validation과 stateless validation을 발전시켜 왔습니다. 논문 속 역할 이름·메시지 흐름을 현재 mainnet 구현의 불변 사실로 단정하지 않습니다. 현재 공식 문서, protocol version과 release notes를 함께 확인합니다.
그럼에도 핵심 경계는 유지됩니다. shard별 chunk 생성, 검증·가용성 확인, block의 chunk header 결합, receipt 기반 cross-shard 실행입니다. 분석 보고서에는 관측 block의 protocol version을 적어 설계 설명과 운영 사실을 연결해야 합니다.
자주 묻는 질문
block producer가 모든 shard transaction을 직접 실행하나요?
그렇게 단순화할 수 없습니다. shard별 chunk 생산·검증이 있고 block producer는 확인된 chunk headers를 block에 결합합니다.
원 transaction 성공이면 cross-shard 호출도 끝난 건가요?
아닙니다. 생성된 receipts가 목적 shard와 callback에서 순차 처리되는 결과를 끝까지 확인해야 합니다.
chunk가 빠진 block은 잘못된 block인가요?
항상 그렇지 않습니다. 프로토콜의 누락 처리 규칙과 다음 block 진행, endorsement·가용성 상태를 확인해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
