UTXO Based Model vs Account Based Model

 

비트코인 트랜잭션에서는 자신의 소유한 UTXO(Unspent Transaction Output)의 amount 합으로 잔액을 계산하는 구조였다

이 구조는 ‘내 계좌에 얼마가 있다’가 아니라, ‘아직 사용하지 않은 동전이 몇 개가 있는가’로 잔액을 판단하는 구조이다

2025.10.14 - [블록체인] - 비트코인 트랜잭션부터 채굴까지, 블록이 만들어지는 전 과정 정리

 

하지만 이더리움은 스마트컨트랙트 구현을 위해 Account(계정) 개념이 도입되어 각 주소의 balance 필드로 잔액을 직접 관리한다

 

먼저 UTXO 방식부터 살펴보자

 

UTXO Based Model (Unspent Transaction Output)

• UTXO는 미사용 거래 출력을 의미
• 즉, 비트코인은 “계좌의 잔액”이라는 개념이 없고, 모든 자산은 ‘사용 가능한 동전 조각(UTXO)’으로 존재함
• 트랜잭션이 발생하면 기존 UTXO를 소비하고 그 자리에 새로운 UTXO를 생성하여 저장
• 대표적으로 비트코인, 라이트코인, 비트코인캐시, 도지코인이 이 모델을 사용

 

동작 원리

• 비트코인 네트워크는 트랜잭션의 연결 관계로 잔액을 추적함
• 각 트랜잭션은 Input과 Output으로 구성되며, 새로운 Output은 이전 거래의 Output을 소비(Input) 하여 생성되는 구조

Transaction A (Output 0 → 0.5 BTC)
Transaction B (Input: A.0 → Output: 0.3 to X, 0.2 change to self)

 

예를 들어 Transaction A를 통해 0.5 BTC를 받았다고 가정해보자

 

X에게 0.3 BTC를 송금하는 Transaction B에서는

TransactionA의 0번째 Output(0.5 BTC)을 Input으로 사용하여

0.3 BTC를 X의 주소로 전송하고,

남은 0.2 BTC는 나에게 새로운 UTXO로 반환한다

 

즉,

• 내가 가진 잔액 = 아직 쓰지 않은 UTXO들의 합
• 송금 시 = 필요한 만큼의 UTXO를 골라 소비(Input)하고, 남으면 Change로 새 Output 생성

장점

• 병렬성: 각 트랜잭션이 독립된 UTXO를 참조하기 때문에 여러 트랜잭션을 동시에 검증 가능
• 프라이버시 향상: 매번 새로운 주소와 UTXO 생성 → 사용자가 추적되기 어려움
• 보안성: 이중 지불(Double Spending) 검증이 명확 (UTXO가 이미 사용되었는지만 확인)

단점

• 데이터 비효율: 작은 단위의 잔돈 UTXO가 쌓이면 블록체인 데이터가 커짐 (dust problem)
• 복잡한 트랜잭션 구성: 여러 Input, 여러 Output 구조로 인해 계산이 복잡
• 계정별 상태 조회 어려움(느림): 잔액을 구하려면 “모든 UTXO를 합산”해야 함

 

---

Account Based Model (계정 기반 모델)

• Account 기반 모델은 블록체인 네트워크의 모든 자산 상태를 하나의 전역 상태(State)로 관리하는 구조
• 트랜잭션은 단순히 새로운 상태 전이를 일으키는 명령이며, 이전 상태에 의존하기 때문에 Stateful(상태 기반) 시스템이라고 부름
• Account 모델은 하나의 주소(Account)에 잔액(balance)이 직접 기록되는 구조
• 전역 상태(World State)는 각 계정이 현재 얼마를 보유하는지, 그리고 계정이 스마트 컨트랙트를 포함하는지 등을 관리
• 대표적으로 이더리움, BSC, 폴리곤 등 많은 EVM 계열 체인이 이 모델을 사용

동작 원리

• 트랜잭션에는 결과 상태가 직접 포함되지 않음
• 모든 노드는 동일한 World State(전역 계정 상태)를 유지하며, 트랜잭션 실행 결과를 반영해 이를 업데이트
• 블록 헤더의 stateRoot는 모든 계정의 상태를 요약한 머클 루트로, 네트워크가 동일한 상태에 합의했음을 나타냄
• 트랜잭션이 블록에 포함되면, 모든 노드의 전역 상태가 동일하게 변경됨

 

예를들어

Account[A].balance -= 1 ETH
Account[B].balance += 1 ETH
A.nonce += 1

1. A가 B에게 1 ETH 송금
2. 네트워크는 A의 Balance에서 1 ETH 차감, B의 Balance에서 1 ETH 추가
3. Gas 사용량만큼 A의 Balance에서 추가 차감
4. 트랜잭션은 상태(State) 변경으로 반영됨

 

특징

• 기존 상태(State)에 의존해 결과를 계산하므로 Stateful
• 여러 트랜잭션이 같은 상태를 동시에 수정할 수 없어 병렬 처리 어려움
• 대신, 상태를 직접 수정하는 구조 덕분에 스마트 컨트랙트 실행 가능

장점

• 빠른 조회: 특정 주소의 balance 조회가 즉시 가능 (UTXO 합산 불필요)
• 구조 단순: Input/Output 개념이 없고, 상태 업데이트만 수행
• 컨트랙트 호환성: 계정 단위로 상태(State)를 관리하므로 스마트 컨트랙트 구현 용이

 

단점

• 병렬성 낮음: 모든 계정이 공유된 상태(State)에 의존 → 동시 업데이트 어려움
• 프라이버시 취약: 한 주소에 거래가 누적되므로 추적이 쉬움
• 이중지불 검증 복잡: 전역 상태(State)를 동기화해야 하므로 블록체인 전체 합의에 의존

---

 

UTXO 모델 vs Account 모델 정리

구분	UTXO 모델	Account 모델
대표 체인	Bitcoin, Litecoin	Ethereum, BSC
데이터 구조	트랜잭션의 Input/Output 연결	계정의 상태(balance, nonce 등)
잔액 관리 방식	UTXO 합계	balance 필드 직접 관리
서명 단위	각 Input마다 별도 서명	트랜잭션 전체 1회 서명
병렬 처리	가능 (독립적 트랜잭션)	어렵다 (전역 상태 공유)
프라이버시	높음 (새 주소 생성 가능)	낮음 (주소 고정)
트랜잭션 크기	Input 수에 따라 변동	대부분 일정
컨트랙트 지원	제한적 (Script 수준)	완전한 EVM 실행 가능
이중지불 방지	동일 UTXO의 재사용 불가로 간단히 검증	nonce 기반 검증 필요 (상태 의존적)

 

 

---

Ethereum의 Account 모델 구현

이더리움은 이 Account 모델을 기반으로, 각 계정의 상태를 World State Trie(Modified Merkle Patricia Trie, MPT)에 저장한다

 

💡 World State Trie(MPT 기반)

• World State Trie = 이더리움의 전역 상태(Global State)를 저장하는 자료 구조
• 매 블록마다 stateRoot 라는 루트 노드의 해시 값이 블록 헤더에 기록되고, 이걸 통해 전체 상태가 일관하게 유지됨을 증명
• World State Trie는 이더리움의 상태 저장소(state database) 역할을 하며, 모든 계정의 최신 상태를 요약해서 한 번에 검증할 수 있게 하는 구조

💡 MPT(Modified Merkle Patricia Trie)

• Merkle: 해시 요약을 가능하게 하는 트리 구조
• Patricia: 공간 절약을 위한 압축된 Trie 구조
• Trie (트라이): 키-값(key-value) 매핑을 저장하는 트리 구조

→ 이 세 가지를 결합한 게 MPT

예시)

A 계정에서 B 계정으로 1 ETH를 보내는 트랜잭션이 있다고 해보자

1. 트랜잭션이 실행되면, A의 balance 값을 감소시키고, nonce도 증가시키는 등 상태 변화가 필요함
2. 트리에서 A의 키를 따라 내려가, 기존 노드들 중 일부를 바꾸고, 새로운 잎(leaf) 노드나 branch 노드를 업데이트
3. 이 변경은 루트까지 영향을 미치므로, 최종적으로 새로운 stateRoot 해시가 생김
4. 블록 헤더에 이 새로운 stateRoot를 기록함으로써, 전체 네트워크가 동일한 전역 상태를 갖는 것을 증명

 

각 Account는 다음과 같은 필드를 가진다

 

Account의 일반적 구성 요소

필드	설명
nonce	계정에서 발생한 트랜잭션의 순서를 나타내는 카운터 동일 트랜잭션 재사용(Replay Attack) 방지와 트랜잭션 순서 보장 역할
balance	해당 주소가 보유한 잔액(wei 단위, 1 ETH = 10¹⁸ wei)
storageRoot	(컨트랙트 계정에 해당) 컨트랙트의 내부 저장소를 머클 트리로 요약한 해시 (일반 EOA는 비어있음)
codeHash	(컨트랙트 계정에 해당) 계정이 스마트 컨트랙트를 갖고 있다면, 그 코드의 Keccak-256 해시

 

이 4가지 필드는 World State (전역 상태)에 저장되며 블록체인은 이 전역 상태를 블록 단위로 업데이트함

 

계정의 종류

이더리움에는 두 가지 유형의 계정이 있다

구분	설명	예시
EOA (Externally Owned Account)	사용자가 개인키를 가진 일반 계정	일반 지갑 주소 (0x…)
CA (Contract Account)	스마트 컨트랙트 코드가 배포된 계정	DeFi·NFT 컨트랙트 주소

• EOA → 서명(Signature)으로 트랜잭션 발생 가능
• CA → 외부 트랜잭션을 받아서 코드(EVM)를 실행

이 구조는 UTXO 모델보다 단순하고, 상태 기반 로직을 직접 구현할 수 있어 스마트 컨트랙트 실행에 적합하다