전체 아키텍처
Nigo Protocol은 기업용 분산원장 제품인 BXDL의 코어 프로토콜입니다. 애플리케이션 요청을 원장의 canonical transaction으로 변환하고, 모든 검증 노드가 동일한 상태 전이와 receipt를 계산하며, 합의로 확정된 결과만 외부에 노출하는 역할을 담당합니다.
BXDL은 이 코어 위에 제품 배포, 운영, 보안 정책, 기업 시스템 연계 및 산업별 솔루션을 구성합니다.
설계 원칙
아키텍처는 다음 원칙을 유지합니다.
- 합의 데이터와 실행 구현을 분리합니다. Ledger는 transaction과 block의 canonical bytes를 소유하지만 VM opcode나 업무 규칙을 소유하지 않습니다.
- 상태 전이는 격리된 overlay에서 수행합니다. 실패한 실행은 overlay를 폐기하고, 성공한 결과만 상위 상태에 병합합니다.
- 합의 엔진은 애플리케이션 실행 규칙을 소유하지 않습니다. 합의 노드는 공통 block pipeline을 통해 proposal을 독립적으로 재실행하고 결과를 검증합니다.
- chain-wide 규칙은 합의 상태에 고정합니다. consensus, fee와 execution profile은 노드별 임의 옵션이 아니라 genesis 또는 합의된 activation height에 결속됩니다.
- 최종 확정된 결과만 canonical ledger로 취급합니다. 준비 중인 proposal과 finalized block을 구분합니다.
- 외부 호환 계층은 코어 원장 위의 adapter입니다. Ethereum JSON-RPC와 SDK 호환이 Nigo의 내부 상태 모델을 Ethereum 계정 상태 모델로 바꾸지는 않습니다.
전체 흐름
이 흐름에서 RPC decode와 block commit은 실행 코어의 책임이 아닙니다. 실행 코어는 전달받은 transaction과 상태 view에 대해 결정적인 결과를 만들고, blockchain 계층은 이를 block 단위로 조립하며, consensus 계층은 동일한 결과를 검증하고 확정합니다.
주요 계층
상태와 원장 기반
| 모듈 | 책임 |
|---|---|
nigo-state-cell | StateCell, ID domain, schema/value codec, StateStore와 execution overlay |
nigo-state-commitment | compact Sparse Merkle Tree, canonical state root, proof와 node-store port |
nigo-ledger | block, transaction, receipt, finality value와 canonical codec/hash |
nigo-crypto | secp256k1, BN254, BLS12-381, P-256와 KZG 등 재사용 가능한 암호 primitive |
nigo-state-cell과 nigo-ledger는 VM, Spring, JDBC 또는 RPC를 참조하지 않습니다. 합의에 노출되는 값과
그 값을 처리하는 실행·전송 adapter가 역방향으로 결합되지 않게 하기 위한 경계입니다.
실행과 블록
| 모듈 | 책임 |
|---|---|
nigo-vm | 공용 EVM interpreter, gas schedule과 제한된 Native validator 실행 mode |
nigo-core | signature/admission 재검증, transaction kind별 실행, fee/receipt settlement |
nigo-blockchain | TxPool, block candidate, 순차·병렬 scheduling, block root와 finalized commit 준비 |
Core는 같은 입력 상태와 transaction에서 같은 StateDelta와 receipt가 만들어지도록 합의 실행 규칙을
집행합니다. Core는 block worker 수, RPC DTO, JDBC table 또는 Spring lifecycle을 알지 않습니다.
Blockchain 계층은 transaction마다 child overlay를 만들고 실행 결과를 canonical transaction index 순서로 병합합니다. 병렬 실행을 선택하더라도 최종 ledger bytes와 state root는 순차 실행 결과와 동일해야 합니다.
합의와 네트워크
| 모듈 | 책임 |
|---|---|
nigo-consensus | consensus profile, validator identity/set, 공통 engine/transport/signer/safety-store SPI |
nigo-consensus-qbft | QBFT quorum, proposer, round와 canonical message/certificate 검증 |
nigo-network-p2p | peer identity, handshake, capability, channel/frame과 secure session 경계 |
nigo-transaction-gossip | bounded transaction 전파, ingress/relay/dedup과 peer-fault 정책 |
nigo-block-sync | finalized snapshot, proof, archive, catch-up와 live-follow |
합의 모듈은 Core나 VM을 직접 참조하지 않습니다. Proposal을 실행하고 검증하는 역할은 공통 blockchain pipeline에 있고, QBFT는 어떤 proposal이 quorum finality를 얻었는지를 결정합니다.
현행 허가형 profile은 정적 validator 집합을 중심으로 합니다. Dynamic membership, public validator admission과 퍼블릭 네트워크 경제 보안은 동일한 완료 주장에 포함되지 않습니다.
저장, 조회와 API
| 모듈 | 책임 |
|---|---|
nigo-storage-rdb | State, block, transaction, receipt, finality와 index의 JDBC adapter |
nigo-observability | backend-neutral account, transaction, state와 activity query contract |
nigo-rpc | 공통 JSON-RPC registry, metadata와 공개 정책 |
nigo-native-rpc | Nigo Native JSON-RPC projection |
nigo-eth-compat | Ethereum raw transaction ingress, signature binding, nonce와 hash mapping |
nigo-eth-rpc | Ethereum JSON-RPC projection |
nigo-node | Spring Boot lifecycle, profile, key, transport, storage, RPC와 Monitor 조립 |
저장소 구현은 상태와 원장 port를 구현하지만 canonical transaction 의미를 새로 정의하지 않습니다. Memory와 RDB profile이 동일한 execution contract를 사용하고, Node가 배포 목적에 맞는 adapter를 선택합니다.
Transaction 실행 생명주기
구조, 서명 또는 protocol invariant가 유효하지 않은 transaction은 receipt 없이 거부됩니다. 반면 EVM
REVERT, out-of-gas 또는 허용된 Native validator 실행 실패는 failure receipt와 정의된 fee transition을
남기고 block에 포함될 수 있습니다. 자세한 구분은 트랜잭션 모델을
참고하세요.
상태와 finality
각 transaction 실행은 active StateCell 집합에 대한 spend와 create 결과를 생성합니다. Block pipeline은 이 결과를 순서대로 병합하고 state commitment 계층이 새 state root를 계산합니다.
QBFT validator는 proposal의 transaction, state root, transaction root와 receipt root가 자신의 재실행 결과와 일치하는지 검증합니다. Quorum certificate를 얻기 전 proposal은 canonical block이 아니며, finality 이후에만 block, transaction, receipt, state와 index가 영속 저장됩니다.
아키텍처 경계가 주는 효과
- Memory/RDB adapter를 교체해도 transaction 의미가 바뀌지 않습니다.
- Native RPC와 Ethereum RPC가 같은 finalized ledger를 서로 다른 형태로 투영할 수 있습니다.
- 병렬 실행은 node-local 최적화로 유지되고 block codec에는 worker 설정이 들어가지 않습니다.
- 합의 프로필을 교체하거나 revision을 추가할 때 execution core를 합의 알고리즘에 종속시키지 않습니다.
- 테스트 벡터와 독립 reference를 통해 canonical bytes와 실행 의미론을 별도로 검증할 수 있습니다.
모듈이 존재하거나 integration test가 있다는 사실만으로 전체 BXDL 배포가 production 승인되었다는 의미는 아닙니다. 기능 구현, 통합 검증, 장애 검증과 운영 승인은 검증과 지원 범위에서 분리해 관리합니다.