EVM 호환 계층
Nigo Protocol은 일반 Solidity contract를 실행하는 EVM과 Ethereum JSON-RPC adapter를 제공합니다. 그러나 Nigo 원장을 Ethereum mainnet의 account/state/fee/consensus 모델로 복제하지는 않습니다.
호환성은 다음 네 영역을 구분해서 판단해야 합니다.
- EVM execution: bytecode, opcode, call/create, gas와 precompile
- Transaction ingress: 지원하는 signed Ethereum envelope와 nonce/fee 검증
- JSON-RPC projection: SDK가 호출하는 method와 조회 가능한 state 범위
- Nigo policy: StateCell commitment, ZERO/FIXED fee와 finalized-only 조회
한 영역의 지원을 전체 Ethereum 호환으로 확대해서 해석하면 안 됩니다.
계층 구조
Ethereum raw transaction은 호환 계층에서 검증된 Nigo transaction carrier로 변환됩니다. 실행 결과는 Nigo receipt와 StateCell delta로 확정되고, Ethereum RPC adapter가 이를 transaction, receipt, log와 block 형태로 투영합니다.
실행 revision
| 실행 모드 | Revision | 용도 |
|---|---|---|
| 일반 EVM | Osaka | Solidity contract deployment와 call |
| Native validator | Paris | immutable descriptor에 고정된 제한 실행 |
일반 실행 profile은 Osaka를 대상으로 하고, Shanghai·Cancun·Prague에서 추가된 opcode의 activation boundary를 포함합니다. 그러나 이들 과거 revision을 각각 독립된 완전 실행 profile로 외부에 제공하지는 않습니다.
Native Program은 일반 contract와 다른 정책을 사용합니다. 같은 interpreter를 사용하지만 descriptor가 Paris revision에 고정되고 상태 조회와 외부 호출 같은 opcode를 제한합니다. 자세한 내용은 Native Program을 참고하세요.
Contract 실행
현재 일반 EVM은 다음 실행 경계를 포함합니다.
- contract deployment,
CREATE와CREATE2 CALL,CALLCODE,DELEGATECALL,STATICCALL- child frame별 state, log, return-data와 gas checkpoint
- call/create 실패와 revert rollback
- transaction-scoped transient storage와 context
- EIP-6780 방식의 제한된
SELFDESTRUCT - EVM storage slot, account nonce와 code reference의 StateCell 영속화
- transaction log의 canonical receipt 반영
Built-in bytecode frame은 명시적인 frame scheduler로 실행되며 protocol 최대 depth가 Java 메서드 재귀에 직접 의존하지 않게 설계되어 있습니다. 임의의 custom Java contract/provider 내부 재귀까지 같은 보장을 확장하지는 않습니다.
Precompile
지원 catalog는 revision별 activation과 gas 규칙을 함께 관리합니다.
| 주소 범위 | 기능 |
|---|---|
0x01..0x04 | ECRECOVER, SHA-256, RIPEMD-160, IDENTITY |
0x05 | modular exponentiation |
0x06..0x08 | BN254 add, mul, pairing |
0x09 | BLAKE2F |
0x0a | KZG point evaluation |
0x0b..0x11 | EIP-2537 BLS12-381 family |
0x100 | EIP-7951 P-256 signature verification |
Provider-backed cryptography는 input shape, field/subgroup validation, canonical output과 gas policy를 VM 경계에서 검증합니다. Packaged JAR, 지원 platform, provider fault, license/notice와 SBOM은 별도의 release evidence로 관리해야 합니다.
지원 transaction envelope
| Ethereum 형식 | Nigo kind | 상태 |
|---|---|---|
| Legacy EIP-155 | EVM(2) | 지원 |
| EIP-1559 type-2 | EVM_TYPE2(4) | 지원 |
| EIP-7702 type-4 | EVM_SET_CODE(3) | 지원 |
| pre-EIP-155 legacy | 없음 | 거부 |
| EIP-2930 type-1 | 없음 | 미지원 |
| EIP-4844 type-3 blob transaction | 없음 | 미지원 |
Type-2와 type-4는 signed raw bytes를 authoritative body로 보존합니다. Chain ID, nonce, fee field, value, calldata, access list와 signature를 raw에서 다시 검증하고 Nigo-specific fee funding identity만 별도 carrier에 추가합니다.
지원 envelope와 전체 Ethereum transaction policy는 같은 의미가 아닙니다. 예를 들어 type-2 wire는 지원하지만 Nigo fee settlement가 Ethereum base-fee adjustment, burn, priority auction과 replacement policy를 그대로 구현하지는 않습니다.
Fee policy 차이
현행 chain profile은 ZERO와 FIXED fee를 canonical하게 표현합니다.
| Profile | Type-2 exact fee pair |
|---|---|
ZERO | (maxPriorityFeePerGas, maxFeePerGas) = (0, 0) |
FIXED P | (0, P) |
eth_gasPrice는 활성 Nigo price를 반환하고 eth_maxPriorityFeePerGas는 현행 mapping에서 0을 반환합니다.
이는 Ethereum public fee market quote가 아닙니다. Client는 활성 profile의 exact fee를 사용해야 합니다.
State와 block context 차이
EVM account, code와 storage는 Nigo StateCell과 compact SMT state root에 commit됩니다. 따라서 다음 차이가 있습니다.
- Ethereum account Merkle Patricia Trie root를 생성하지 않습니다.
eth_getProof의 Ethereum MPT account/storage proof를 제공하지 않습니다.- EVM storage slot은
EVMdomain StateCell로 저장됩니다. - canonical account nonce도 StateCell 기반 lifecycle을 따릅니다.
- Nigo consensus가 제공하지 않는
COINBASE,PREVRANDAO,BASEFEE,BLOBBASEFEEcontext는 profile 정책상 zero 값을 사용할 수 있습니다. GASLIMIT은 Nigo block gas limit을 반영합니다.
이 차이는 구현 누락을 숨기는 호환 shim이 아니라 chain policy의 의도적인 차이로 관리합니다.
JSON-RPC 지원 범위
현재 inventory에는 20개의 구현된 Ethereum/Web3 method가 있습니다. 일부는 의미 제약이 있어
CONDITIONAL로 분류합니다.
직접 지원
web3_clientVersion
net_version
eth_chainId
eth_blockNumber
eth_getTransactionByHash
조건부 지원
net_listening
eth_syncing
eth_gasPrice
eth_maxPriorityFeePerGas
eth_getBalance
eth_getTransactionCount
eth_getCode
eth_getStorageAt
eth_call
eth_estimateGas
eth_sendRawTransaction
eth_getTransactionReceipt
eth_getBlockByNumber
eth_getBlockByHash
eth_getLogs
주요 제약은 다음과 같습니다.
- State query와 simulation은 current finalized state를 기준으로 합니다.
latest,safe,finalized는 현행 finalized view로 해석할 수 있지만 historical/pending state는 없습니다.- Pending nonce는 canonical reservation 한 건까지만 투영합니다.
- Receipt, block과 log는 finalized location을 기준으로 노출됩니다.
- 큰 log 범위는 bounded pagination이 필요합니다.
net_listening과eth_syncing은 운영 readiness 또는 sync progress 지표가 아닙니다.
미지원 영역
eth_fillTransaction- server-managed filter lifecycle
- WebSocket
eth_subscribe/eth_unsubscribe eth_getProofadmin_*,debug_*,trace_*
미지원 method가 필요한 애플리케이션은 configuration-only migration 대상으로 분류하면 안 됩니다. Stateless
eth_getLogs polling처럼 대체 가능한 흐름과 pending stream·execution trace처럼 별도 기능 결정이 필요한
흐름을 구분해야 합니다.
SDK 검증 경계
현재 저장소의 고정된 검증 흐름은 다음 SDK를 대상으로 합니다.
- ethers
6.17.0 - viem
2.55.19 - Web3j
4.10.0
검증 범위에는 contract deployment, call, state change, event, receipt, NIGO value와 동일 DB 재시작 후 조회가 포함됩니다. 이 결과는 해당 버전과 테스트된 흐름에 대한 evidence이며 모든 SDK 버전, 모든 API 또는 기존 dApp의 무수정 호환을 의미하지 않습니다.
Web3j 4.10.0의 type-4 작성·서명은 검증 범위에서 지원되지 않습니다. Protocol의 type-4 실행 지원과 특정
SDK의 authoring capability를 별도로 판단해야 합니다.
호환성 평가 체크리스트
애플리케이션을 BXDL/Nigo로 이전하기 전에 다음을 확인합니다.
- Legacy, type-2, type-4 중 어떤 envelope를 작성하는가?
- Ethereum base-fee/tip/replacement 의미에 의존하는가?
- Historical 또는 pending state가 필요한가?
- WebSocket subscription, server filter, trace나 MPT proof가 필요한가?
- 한 account에서 여러 pending nonce를 동시에 queue하는가?
- 사용하는 opcode와 precompile이 active Osaka profile에 포함되는가?
- SDK가 exact Nigo fee pair를 설정할 수 있는가?