트랜잭션 모델
Nigo Protocol은 하나의 범용 transaction에 모든 동작을 넣지 않습니다. 상태 전이 방식과 서명·wire 의미가 다른 transaction을 별도 canonical kind와 hash domain으로 구분합니다.
이 구분을 통해 Native Cell 전이와 Ethereum raw transaction을 같은 block에서 처리하면서도 각 형식의 identity와 검증 규칙을 보존합니다.
공통 envelope
모든 Nigo transaction은 다음 공통 정보를 갖습니다.
| 필드 | 의미 |
|---|---|
txHash | transaction kind별 domain-separated canonical hash |
creator | 정규화된 20-byte creator address |
signature | NIGO 또는 ETH scheme에 맞는 서명 증거 |
timestamp | Nigo transaction timestamp 또는 raw carrier의 canonical 값 |
signatureScheme | NIGO(0) 또는 ETH(1) |
gasLimit | transaction 실행 gas 상한 |
| Ethereum metadata | ETH 서명 흐름에서 signing hash와 fee 관련 원본 정보 보존 |
Kind별 본문과 hash 계산은 공통 필드만으로 환원되지 않습니다. 특히 Ethereum type-2와 type-4 transaction은 서명된 raw bytes를 authoritative body로 보존합니다.
Canonical transaction kind
| Kind | Code | 역할 |
|---|---|---|
DIRECT_CELL | 0 | Core ownership와 보존 규칙으로 검증하는 선언적 Cell 전이 |
PROGRAM_VALIDATED_CELL | 1 | Native Program에 업무 전이 검증을 위임하는 Cell 전이 |
EVM | 2 | Nigo-native EVM call/create 또는 legacy EIP-155 carrier |
EVM_SET_CODE | 3 | signed EIP-7702 type-4 raw transaction carrier |
EVM_TYPE2 | 4 | signed EIP-1559 type-2 raw transaction carrier |
Code와 canonical encoding은 합의 데이터입니다. 새 transaction kind를 추가하거나 기존 encoding을 바꾸는 것은 일반 API 변경이 아니라 protocol revision으로 다뤄야 합니다.
Cell transaction
Cell transaction은 input StateCell ID와 output StateCell을 본문에 선언합니다.
CellTransaction
inputs[] StateCellId
outputs[] StateCell
실행 전 input의 존재, 소유권, domain 접근, output shape와 hash를 검증하고, 성공하면 input을 spend하고 output을 create합니다.
Direct Cell
DIRECT_CELL은 Core가 공통 소유권과 보존 규칙을 직접 검증합니다. Native Asset의 일반 이전이나 protocol-neutral
Direct output처럼 별도 프로그램 실행이 필요하지 않은 명시적 상태 전이에 사용합니다.
Output ID를 최종 transaction hash에서 바로 파생하면 서로가 서로를 요구하는 순환 의존이 생깁니다. Nigo는 이를 intent와 final transaction hash의 두 단계로 분리합니다.
Output semantic descriptor에는 ID를 제외한 owner, schema hash, data type, value와 필요한 asset identity가 포함됩니다. 따라서 producer의 output ID를 서명 전에 계산해 같은 block의 뒤 transaction input으로 연결할 수 있고, output 의미를 서명 후 바꿀 수 없습니다.
Program-validated Cell
PROGRAM_VALIDATED_CELL은 선언한 상태 전이의 업무 규칙 검증을 Native Program에 위임합니다. Transaction은
input/output 외에 다음 invocation을 커밋합니다.
ProgramInvocation V1
programId
expectedRevision
expectedDescriptorHash
methodSelector
assetScopes[]
arguments
Invocation은 stable program identity뿐 아니라 예상 revision과 descriptor hash를 함께 서명합니다. 같은
programId에 새 runtime revision이 존재하더라도 transaction이 의도하지 않은 코드로 조용히 바뀌는 것을
막기 위한 구조입니다.
Core는 공통 protocol invariant를 검증하고, VM은 선택된 Native validator를 제한된 EVM mode에서 실행합니다. 성공 receipt에는 실제 실행한 program ID, revision과 descriptor hash가 포함됩니다.
EVM transaction
EVM
EVM(2)은 contract call과 deployment를 표현합니다.
- target이 없으면 deployment
- target이 있으면 call
value는 unsigned 256-bit NIGO value- calldata와 gas limit을 canonical hash에 결속
- NIGO 서명 또는 검증된 legacy EIP-155 ETH carrier 지원
Legacy ETH 흐름은 Ethereum signing hash, raw transaction hash, nonce, gas price와 서명 field를 복원해 exact 검증합니다. Ethereum transaction에 timestamp가 없기 때문에 carrier timestamp는 authoritative Ethereum hash에서 결정적으로 파생됩니다.
EVM_TYPE2
EVM_TYPE2(4)는 signed raw 0x02 EIP-1559 envelope를 보존합니다.
- chain ID와 nonce
- priority/max fee
- gas limit
- destination와 value
- calldata와 access list
yParity,r,s
Decoder는 raw bytes를 decode한 뒤 같은 bytes로 다시 canonical encode되는지 확인합니다. Ethereum signing hash와 transaction hash는 raw에서 재계산하고, Nigo-specific fee funding identity는 별도 carrier 영역에 결속합니다.
Type-2 envelope를 지원한다는 사실이 Ethereum base-fee market 전체를 지원한다는 의미는 아닙니다. 현재 fee 수용과 정산은 활성 Nigo fee profile 규칙을 따릅니다.
EVM_SET_CODE
EVM_SET_CODE(3)는 signed raw 0x04 EIP-7702 envelope와 authorization list를 보존합니다. Raw Ethereum field와
outer signature가 authoritative하고, Nigo fee funding만 별도 extension으로 결속됩니다.
SDK가 type-4 transaction을 직접 작성하고 서명할 수 있는지는 protocol execution 지원과 별개의 호환성 항목입니다. SDK별 확인된 범위는 향후 개발자 가이드와 compatibility matrix에서 구분합니다.
서명과 identity
Nigo는 NIGO와 ETH signature scheme을 구분합니다.
| Scheme | 검증 기준 |
|---|---|
NIGO | Nigo transaction intent/hash domain에 대한 서명과 creator 복구 |
ETH | Ethereum signing payload/RLP, chain ID, nonce, field와 sender 복구 |
ETH 서명 transaction은 원본 Ethereum identity를 유지하면서 Nigo 원장용 transaction hash와 canonical carrier를 추가로 가질 수 있습니다. 이 두 hash를 같은 값으로 가정하면 안 됩니다. Mapping과 RPC projection은 원본 Ethereum hash와 finalized Nigo transaction identity를 명시적으로 연결합니다.
실행 생명주기
Admission에서 한 번 검증한 transaction도 block 실행 시 합의 상태를 기준으로 다시 검증합니다. Admission과 execution 사이에 nonce, input, program revision 또는 protocol profile이 바뀔 수 있기 때문입니다.
거부와 실행 실패
유효하지 않은 transaction과 유효하게 실행되었지만 실패한 transaction은 다릅니다.
| 결과 | Receipt | Block 포함 |
|---|---|---|
| malformed canonical bytes | 없음 | 아니요 |
| signature 또는 chain ID 불일치 | 없음 | 아니요 |
| input, domain, nonce 또는 protocol invariant 위반 | 없음 | 아니요 |
| Direct Cell 성공 | success | 예 |
| Native validator success | success | 예 |
| Native validator revert 또는 out-of-gas | failure와 정의된 fee transition | 예 |
| EVM success | success | 예 |
EVM REVERT 또는 out-of-gas | failure, VM state rollback 후 fee settlement | 예 |
| validator result/capability protocol 위반 | 없음 | 아니요 |
실행 실패가 block에 포함되는 경우에도 실패한 message의 상태 변경을 commit한다는 의미는 아닙니다. Revertible overlay는 폐기하고 receipt와 fee policy가 허용한 transition만 남깁니다.
Receipt
Canonical receipt는 다음 정보를 보존합니다.
- Nigo transaction hash와 별도 receipt hash
- 실행에서 관찰한 input StateCell
- 생성된 output StateCell
- spent StateCell ID
- contract/native event
- gas limit, gas used와 gas schedule
- fee policy, effective gas price, charged amount와 settlement mode
- success/failure status
- contract deployment address
- 필요한 경우 Native Program identity/revision metadata
Receipt의 input/output/spent ID는 StateCell lineage를 구성합니다. Fee policy revision이나 실제 settlement mode가 다르면 실행 결과가 유사해도 canonical receipt hash가 달라질 수 있습니다.
Block 실행과 병렬성
Block pipeline은 transaction을 canonical index로 고정합니다. 순차 mode는 그 순서대로 실행하고, 병렬 mode는 명시적인 StateCell 접근 관계로 graph와 wave를 구성합니다.
- 같은 frozen state view에서 독립 transaction을 실행
- 실제 접근이 선언된 범위 안인지 검증
- 결과를 canonical transaction index 순서로만 병합
- 접근 범위를 증명할 수 없는 EVM 또는 broad transaction은 barrier로 순차 실행
- 오류나 불확실성이 있으면 순차 경로로 fallback
병렬 실행 전략은 block에 기록되지 않습니다. 서로 다른 worker 설정의 validator도 동일한 transaction, receipt와 state root를 만들어야 합니다.