Blockchain on Jeongseup Blog

EVM은 왜 정수(uint)만 지원하는가?

Wed, 25 Feb 2026 00:00:00 +0000

Solidity에 float이 없는 이유와 블록체인 합의의 관계

핵심 이유: 부동소수점은 합의를 깨뜨린다

블록체인은 수천 개 노드가 동일한 계산을 수행하고 같은 결과에 합의해야 하는 시스템이다.

그런데 IEEE 754 부동소수점(float/double)은 하드웨어마다 미세하게 다른 결과를 낼 수 있다:

1
2
3
4
5
6
7


0.1 + 0.2 =
 Node A (Intel x86): 0.30000000000000004
 Node B (ARM Cortex): 0.30000000000000001
 Node C (AMD Ryzen): 0.30000000000000004

→ A와 C는 같은 상태 해시, B는 다른 상태 해시
→ 합의 실패 → 체인 포크!

반면 정수 연산은 어떤 CPU에서든 동일하다:

1
2


800 * 1e18 / 1000 = 800000000000000000
→ 100% 결정론적(deterministic) → 합의 보장

이유 1: 결정론(Determinism) — 가장 근본적

float이 비결정론적인 구체적 원인들을 살펴보자.

반올림 모드 차이

IEEE 754에는 4가지 반올림 모드가 있다:

Round to nearest (even) — 기본값이지만 바꿀 수 있음
Round toward zero
Round toward +∞
Round toward -∞

CPU나 컴파일러 설정에 따라 모드가 달라질 수 있다.

비결합법칙 (Non-associativity)

1
2


정수: (a + b) + c = a + (b + c) ← 항상 같음
float: (a + b) + c ≠ a + (b + c) ← 다를 수 있음!

예를 들어 a=1e20, b=-1e20, c=1.0일 때:

1
2


(a + b) + c = 0 + 1.0 = 1.0
a + (b + c) = 1e20 + (-1e20) = 0.0

컴파일러 최적화가 연산 순서를 바꾸면 결과가 달라진다.

특수값 처리 차이

NaN, Infinity, -0, denormalized numbers 등 특수값들의 비교·연산 동작이 구현마다 미세하게 다르다.

이유 2: 금융 정밀도 — float은 돈 계산에 위험

은행도 float을 쓰지 않는다:

시스템	방식
COBOL	고정소수점 (packed decimal)
Java	`BigDecimal`
Python	`decimal` 모듈
블록체인	`uint256` + 1e18 스케일링

float의 위험을 구체적으로 보면:

1
2
3
4


잔고 100.10 USDC를 float로 저장하면?
→ 실제 저장값: 100.09999999999999...
→ 100만 번 더하기/빼기 반복하면 오차 누적
→ 잔고 불일치 → 자금 손실 또는 무한 인출 취약점

uint256 + PRECISION 방식:

1
2


100.10 USDC = 100_100_000 (USDC는 6 decimals)
→ 정확히 이 값. 오차 없음. 1000만 번 연산해도 동일.

이유 3: EVM 설계 단순화

EVM은 256비트 워드 기반 스택 머신이다. uint256 하나로 통일하면:

장점
Opcode 수 적음 (`ADD`, `MUL`, `DIV`)
가스 비용 계산 간단 (고정 비용)
구현 버그 감소
상태 저장 단순 (32 bytes 슬롯)

만약 float을 추가한다면:

추가 복잡도
`FADD`, `FMUL`, `FDIV`, `FSQRT` opcode
반올림 모드 명세
`NaN`, `Infinity`, `-0` 처리 규칙
가스 비용 산정 (연산마다 다름)
`int↔float` 변환 opcode
모든 EVM 구현체의 동작 일치 검증

복잡도 대비 이점이 없다. 정수 스케일링으로 충분하기 때문이다.

다른 블록체인도 마찬가지인가?

L2도 float을 명시적으로 제거한다:

Optimism (Bedrock): float 연산 제외 — fraud proof 검증을 위해
Arbitrum Nitro: float 연산 제외 — 동일한 이유

다른 체인들도 마찬가지다:

체인	방식
Solana (BPF)	정수 연산만 지원, float는 프로그램 레벨에서 처리
Cosmos (CosmWasm)	`Decimal256` 타입 제공 (uint 기반 구현)
Move (Sui/Aptos)	`u8`/`u64`/`u128`/`u256`만 지원, float 없음

블록체인 VM에서 float 배제는 업계 표준이다.

DeFi의 우회 방법들

float 없이 소수점을 다루는 방법들:

방식	사용 사례
1e18 (Mantissa)	Compound — 범용 비율 계산
1e27 (Ray)	Aave V3 — 더 높은 정밀도 필요 시
2^96 (Q notation)	Uniswap V3 — 제곱근 가격 계산 최적화
Token decimals	USDC(6), WETH(18) — 토큰 단위 표현
WAD/RAY 라이브러리	ds-math, WadRayMath — 안전한 연산

공통 패턴: “정수로 표현하고, 나눗셈은 최대한 늦추고, 곱셈을 먼저”

결론

EVM이 uint만 지원하는 이유를 우선순위로 정리하면:

합의 안전성 — float은 노드 간 결과 차이를 만들 수 있음
금융 정확성 — 돈 계산에 부동소수점은 위험
설계 단순성 — opcode와 가스 모델 복잡도 최소화

이것은 **“기술적 한계"가 아니라 “의도적 설계 결정”**이다.

분산 합의가 필요 없는 시스템(게임 엔진, 과학 계산)에서는 float이 적합하지만, “수천 대 컴퓨터가 같은 답을 내야 하는” 블록체인에서는 정수가 유일한 선택이다.

Validator Reward Deep Dive Series

Sat, 03 Jan 2026 00:00:00 +0000

Context & Motivation

This series was originally authored during my tenure at Cosmostation, working with the Validator Team. The primary goal of this research was to provide a technical foundation for developing in-house validator monitoring and reward management tools.

To build robust infrastructure, we needed to go beyond the surface and understand the exact mathematical and programmatic flow of rewards across different blockchain architectures. This series documents that journey, covering Cosmos, Sui, Kaia, and Namada.

Series Index

1. Walrus: The Secret of Staking Rewards

Focus: Walrus 프로토콜의 보상 분배 메커니즘, 에포크 변경 및 환율 계산 로직 분석.
Key Insight: initiate_epoch_change와 process_pending_stake를 심층 분석하여 스테이킹 시점과 출금 시점의 환율 차이로 보상이 결정되는 과정을 설명합니다.

2. Sui: How are Epoch Rewards Delivered to Stakers?

Focus: Sui 프로토콜의 네이티브 스테이킹 보상 메커니즘과 sui_system Move 패키지를 통한 에포크 단위 보상 분배.
Key Insight: StakingPool의 환율(Exchange Rate)이 보상을 통해 어떻게 우상향하는지 설명하고, 스테이킹 및 출금 시점의 환율 차이로 보상이 산정되는 원리를 다룹니다.

3. Cosmos: How do Inflation and Fees become Delegator Rewards?

Focus: x/mint, x/auth, FeeCollector, x/distribution, x/staking 모듈 간의 상호작용을 통한 보상 생성 및 분배의 유기적인 과정.
Key Insight: 인플레이션과 수수료가 FeeCollector에 모여 검증인 풀로 이동하고, ‘누적 보상 비율(Cumulative Reward Ratio)‘과 지분(Share)을 기반으로 델리게이터에게 최종 분배되는 F1 모델의 흐름을 설명합니다.

4. Kaia: Staking Rewards in Public Delegation Contract

Focus: PublicDelegation.sol 시스템 컨트랙트와 ERC-20 기반 지분(Share) 토큰을 중심으로 한 스테이킹 보상 메커니즘.
Key Insight: stake() 호출 시 자동 재예치(Auto-compounding)가 발생하여 풀의 총 KAIA가 증가하고, 이로 인해 지분 가치가 상승(Value Accrual)하여 보상이 실현되는 원리를 설명합니다.

5. Namada: PoS Staking and Inflation in Namada

Focus: 나마다(Namada)의 에포크 기반 PoS 인플레이션과 ‘Reward Product’ 방식을 이용한 독창적인 보상 기록 메커니즘.
Key Insight: 매 에포크마다 위임 지분당 보상 비율인 reward_product가 기록되며, 이를 통해 델리게이터의 보상이 위임량 * reward_product의 합으로 산정되는 원리를 설명합니다.

Reflection

Building tools for a top-tier validator team requires a “don’t trust, verify” mindset toward protocol specifications. These articles served as the technical blueprint for our engineering team to ensure reward calculation accuracy and operational excellence.

I hope this archive remains a useful resource for anyone diving deep into the economics of Proof-of-Stake networks.