블록체인 코어 공부 - Transaction Validation부터 Execution, Consensus, PulseVM까지
오늘은 블록체인에서 트랜잭션이 들어온 뒤 검증되고, 실행되고, 블록이 합의되고, 최종 상태가 저장되는 과정을 공부했다.
처음에는 Validation, Execution, Consensus가 비슷한 과정처럼 느껴졌는데, 각각의 역할을 분리해서 생각하니 구조가 명확해졌다.
1. Transaction은 State를 변경해달라는 요청이다
블록체인의 핵심을 아주 단순하게 보면 결국 State를 관리하는 상태 머신(State Machine)이라고 볼 수 있다.
예를 들어 현재 State가 다음과 같다고 하자.
State S0
Alice
balance = 100
nonce = 7
Bob
balance = 20
Alice가 Bob에게 10을 보내는 Transaction을 만든다.
Tx
from = Alice
to = Bob
amount = 10
nonce = 7
signature = ...
이 Transaction의 의미는 결국 다음과 같다.
"현재 State를 이 규칙에 따라 변경해 주세요."
즉 Transaction 자체가 State를 변경하는 것이 아니라, State 변경을 요청하는 입력값이다.
2. Transaction Validation
Transaction을 받았다고 바로 State를 변경하면 안 된다.
먼저 이 Transaction이 프로토콜의 규칙을 만족하는지 검증해야 한다.
예를 들어 다음과 같은 것들을 확인할 수 있다.
1. Signature가 올바른가?
2. Sender가 존재하는가?
3. Nonce가 올바른가?
4. 필요한 balance가 존재하는가?
5. Transaction 형식이 올바른가?
6. 필요한 비용이나 resource를 감당할 수 있는가?
이를 간단하게 표현하면:
Transaction
↓
Validation
↓
PASS / FAIL
Validation의 핵심 질문은 다음과 같다.
"이 요청을 프로토콜 규칙상 처리해도 되는가?"
3. Signature와 Nonce는 왜 필요한가?
Signature
Signature는 쉽게 말하면:
"이 Transaction을 정말 Alice가 요청한 것이 맞는가?"
를 확인하기 위한 것이다.
Private Key를 가진 사용자가 Transaction에 서명하고, 노드는 Public Key 등을 이용해 서명을 검증한다.
따라서 Signature는 주로 인증과 권한(Authorization) 문제를 해결한다.
Nonce
Nonce는 Transaction의 순서와 Replay 문제를 해결한다.
예를 들어 Alice의 현재 nonce가 7이라면:
현재 Alice nonce = 7
Tx1 nonce = 7
Tx2 nonce = 8
Tx3 nonce = 9
처럼 Transaction의 순서를 관리할 수 있다.
이미 처리된 nonce의 Transaction을 다시 보내더라도 현재 State의 nonce와 맞지 않기 때문에 거부할 수 있다.
즉 Nonce는 대표적으로 다음 문제를 해결한다.
Transaction ordering
Replay protection
4. Validation과 Execution은 다르다
오늘 가장 중요하게 구분한 개념 중 하나다.
Validation
"이걸 처리해도 되는가?"
Execution
"실제로 처리하면 State가 어떻게 바뀌는가?"
예를 들어:
현재 State
Alice = 100
Bob = 20
Transaction:
Alice → Bob 10
Validation에서는:
Signature OK?
Nonce OK?
Balance 충분?
형식 OK?
→ PASS
를 확인한다.
Execution에서는 실제로:
Alice.balance -= 10
Bob.balance += 10
Alice.nonce += 1
을 수행하여 새로운 State를 계산한다.
S0
Alice = 100
Bob = 20
↓ Execution
S1
Alice = 90
Bob = 30
즉,
Validation = 실행 가능한 입력인지 판단
Execution = 그 입력을 State Machine에 적용하여 결과 State를 계산
이라고 볼 수 있다.
5. Validation할 때 State가 어떻게 바뀔지 알 수 있지 않나?
단순한 Transaction이라면 어느 정도 예상할 수 있다.
예를 들어:
Alice = 100
Bob = 20
Alice → Bob 10
이라면 검증하면서도 사람이 보기에는:
Alice = 90
Bob = 30
이 될 것이라고 쉽게 예상할 수 있다.
하지만 스마트 컨트랙트는 이야기가 달라진다.
예를 들어:
DEX.swap(10 ETH)
라는 Transaction이 있다고 하자.
정확한 결과를 알려면:
swap() 실행
↓
현재 Pool State 읽기
↓
가격 계산
↓
다른 Contract 호출
↓
Storage Read
↓
Storage Write
↓
Slippage 검사
↓
SUCCESS / REVERT
등 실제 Contract 코드를 실행해야 한다.
그리고 여기까지 했다면 사실상 Execution을 한 것이다.
따라서 중요한 경계는 다음과 같다.
최종 State를 정확하게 계산하기 위해 State Machine을 실제로 돌리기 시작하면 그것은 Execution이다.
6. Validation을 통과해도 Execution이 성공한다는 뜻은 아니다
이것도 중요한 부분이다.
Validation PASS
↓
Execution
↙ ↘
SUCCESS REVERT
Transaction이 기본적인 실행 조건을 만족했더라도 실제 Smart Contract를 실행하면서 조건에 걸릴 수 있다.
예를 들어 DEX Swap이라면:
Transaction 생성 시점
ETH 가격 = 3,000
slippage 조건 만족
이었지만 실제 블록에서 실행될 때:
다른 Transaction들이 먼저 실행됨
↓
Pool State 변경
↓
ETH 가격 변화
↓
내 Transaction 실행
↓
slippage 조건 실패
↓
REVERT
가 가능하다.
즉 Transaction을 생성하거나 검증하던 시점의 State와 실제 실행 시점의 State가 다를 수 있다.
7. State Transition
Execution의 핵심은 결국 State Transition이다.
S1 = Transition(S0, Tx1)
예를 들어:
S0
↓ Tx1
S1
↓ Tx2
S2
↓ Tx3
S3
각 Transaction이 이전 State를 입력으로 받아 새로운 State를 만든다.
따라서 Transaction 순서가 매우 중요하다.
Tx1 → Tx2 → Tx3
과
Tx3 → Tx1 → Tx2
는 동일한 Transaction 집합이어도 서로 다른 결과를 만들 수 있다.
8. Block Execution
Block에는 여러 Transaction이 들어간다.
Block #100
Tx1
Tx2
Tx3
Tx4
Block Execution은 이 Transaction들을 정해진 순서대로 실행하는 것이다.
State S0
↓ Tx1
State S1
↓ Tx2
State S2
↓ Tx3
State S3
↓ Tx4
State S4
따라서 Block Execution의 결과는:
Previous State
+
Ordered Transactions
+
Execution Rules
=
New State
라고 생각할 수 있다.
9. Deterministic Execution
블록체인에서 매우 중요한 성질이다.
모든 노드가 다음 세 가지를 동일하게 가지고 있다면:
같은 Initial State
같은 Transaction 순서
같은 Execution Rule
결과 역시 같아야 한다.
Node A
S0 + [Tx1, Tx2, Tx3]
↓
S3
Node B
S0 + [Tx1, Tx2, Tx3]
↓
S3
즉:
Same State
+ Same Ordered Input
+ Same Rules
--------------------
= Same Result
이것이 deterministic state transition이다.
블록체인의 모든 노드가 동일한 State를 유지할 수 있는 핵심 조건 중 하나다.
10. Execution과 Consensus는 다른 문제다
처음에는 Execution을 "블록을 만드는 과정"이라고 생각하기 쉬운데 다르다.
Execution
"이 Transaction/Block을 실행하면
State가 어떻게 바뀌는가?"
Consensus
"여러 후보 중 어떤 Block/History를
우리 체인이 인정할 것인가?"
즉:
Blockchain
│
┌─────────┴─────────┐
│ │
Consensus Execution
│ │
어떤 Block을 Block을 실행하면
인정할 것인가? State가 어떻게 변하는가?
Execution 결과가 올바른 Block이 있다고 해서 그 Block이 반드시 canonical history가 되는 것은 아니다.
여러 개의 유효한 후보 Block이 존재할 수 있고, 어떤 History를 선택할지는 Consensus의 역할이다.
11. Block Producer는 Transaction 순서를 결정한다
Block Producer / Proposer는 일반적으로 프로토콜의 제약 안에서:
Mempool
├ TxA
├ TxB
├ TxC
└ TxD
중 어떤 Transaction을 포함할지, 어떤 순서로 넣을지를 결정한다.
예를 들어:
Block
TxC
TxA
TxD
처럼 구성될 수 있다.
그리고 Execution은 이미 결정된 그 순서대로 State Transition을 수행한다.
따라서:
Block Producer
↓
Tx Selection / Ordering
↓
Block
↓
Execution
↓
State Transition
의 관계를 가진다.
이 때문에 Transaction Ordering은 MEV 같은 문제와도 연결된다.
12. Finality는 또 다른 개념이다
Execution을 통해 State가 계산됐다고 끝이 아니다.
Consensus를 통해 해당 Block이 체인의 History로 인정되고, 프로토콜에 따라 더 이상 뒤집히지 않는 것으로 간주되는 단계가 필요하다.
큰 흐름은 다음과 같다.
Transaction
↓
Validation
↓
Execution
↓
Block Validation / Consensus
↓
Accepted History
↓
Finality
즉 각각의 질문이 다르다.
Validation
"이 요청 괜찮아?"
Execution
"실행하면 State가 어떻게 돼?"
Consensus
"어떤 Block을 인정할까?"
Finality
"이 History를 이제 최종 확정된 것으로 볼 수 있는가?"
13. Avalanche Continuous Execution
Avalanche의 Continuous Execution을 공부하면서 Validation과 Execution의 차이가 더 명확해졌다.
전통적인 동기식 방식에서는 개념적으로 Block의 실제 Execution이 Consensus 진행을 막을 수 있다.
Block
↓
Full Execution
↓
State Result 확인
↓
Consensus 진행
Execution이 무거우면 Consensus가 기다려야 한다.
Continuous Execution의 아이디어는 Consensus와 Full Execution의 진행을 분리하여 Pipeline처럼 처리하는 것이다.
개념적으로:
Block
↓
사전 Validation
↓
Consensus / Accepted
↓
Execution Queue
↓
Full Execution
↓
State / Receipt 계산
Consensus가 Block을 ordering/accept하는 동안 Executor는 이전에 Accepted된 Block들을 계속 실행할 수 있다.
예를 들면:
Consensus
B100 → B101 → B102 → B103
↓
Accepted
Execution
B100 → B101 → B102 ...
Consensus가 Execution보다 앞서갈 수 있다.
이것이 Pipeline 구조와 비슷하다.
14. 그렇다면 검증하고 넘기는 거면 기존과 같은 것 아닌가?
처음에는 그렇게 느껴졌다.
Continuous Execution도 아무 Block이나 Accepted하는 것이 아니라 사전 Validation을 수행하기 때문이다.
차이는 검증의 깊이와 비용이다.
기존 방식에서는 Full Execution을 통해 실제 결과까지 계산해야 다음 단계로 갈 수 있다면, Continuous Execution에서는 먼저:
"최악의 경우를 고려하더라도 이 Block을 나중에 처리할 수 있는가?"
와 같은 필요한 조건을 확인하고 무거운 Full Execution을 뒤로 미룰 수 있다.
즉:
기존
Full Execution
↓
정확한 결과 계산
↓
Consensus
에 비해:
Continuous Execution
Pre-Validation
↓
Consensus / Accepted
↓
Full Execution
이라는 분리가 가능해진다.
핵심은 Validation을 제거한 것이 아니다.
Consensus가 무거운 Full Execution을 기다리지 않아도 되도록 Execution을 분리한 것이 핵심이다.
15. Accepted됐는데 나중에 Transaction이 REVERT하면?
가능하다.
중요한 것은:
Block Accepted
와
Transaction SUCCESS
가 같은 의미가 아니라는 것이다.
이미 Consensus에서 Block의 위치와 순서가 Accepted되었다면, 그 Block 안의 Transaction을 Full Execution했을 때 REVERT가 발생할 수도 있다.
Block Accepted
↓
Full Execution
↓
Tx1 SUCCESS
Tx2 REVERT
Tx3 SUCCESS
REVERT 역시 VM이 정의한 정상적인 deterministic execution result일 수 있다.
따라서 REVERT가 발생했다고 이미 Accepted된 Block을 제거하는 것이 아니다.
다만 Full Execution 자체가 불가능한 수준의 문제가 Accepted 이후 발견된다면 이는 단순한 REVERT와 다른 심각한 문제다.
그래서 Accepted 전에 필요한 사전 조건과 resource bound 등을 검증하여 Accepted된 Block이 나중에 실행 자체를 할 수 없는 상황을 방지하는 설계가 필요하다.
16. VM은 무엇인가?
오늘 가장 크게 정리된 개념 중 하나다.
VM을 단순히 "바이트코드를 실행하는 프로그램" 정도로 생각했는데, 블록체인 아키텍처에서는 더 넓게 볼 수 있다.
VM은 대략:
State가 무엇이고, Transaction/Operation을 어떻게 검증하며, 그것을 실행했을 때 State가 어떻게 바뀌는지를 정의하고 구현하는 실행 계층
이라고 생각할 수 있다.
예를 들어 VM 코드에는 다음과 같은 것들이 존재할 수 있다.
Account의 구조
Balance 저장 방식
Nonce 규칙
Transaction Validation
transfer 실행 규칙
Smart Contract 실행
State Read / Write
Block Validation
State Transition
즉:
State S1 = VM(State S0, Input)
와 같은 State Machine을 구현하는 것이 VM의 중요한 역할이다.
17. 그렇다면 State는 VM 안에 있는가, DB 안에 있는가?
둘을 구분해야 한다.
예를 들어 실제 현재 State가:
Alice.balance = 100
Alice.nonce = 7
Bob.balance = 20
이라면 이 실제 데이터는 DB 등에 영속적으로 저장된다.
반면 VM 코드에는:
Account란 무엇인가?
Balance는 어떻게 저장하는가?
Nonce는 어떻게 증가하는가?
transfer가 실행되면
sender.balance -= amount
receiver.balance += amount
어떤 Transaction을 invalid 처리하는가?
같은 State의 구조와 변경 규칙이 존재한다.
따라서:
VM
┌───────────────┐
│ State 정의 │
│ Validation │
│ Execution │
│ Transition │
└───────┬───────┘
│
Read / Write
│
▼
DB
┌───────────────┐
│ Alice = 100 │
│ Bob = 20 │
│ nonce = 7 │
│ contract data │
│ ... │
└───────────────┘
즉 한 문장으로:
VM은 State가 무엇이고 어떻게 바뀌는지를 정의하고 관리하며, DB는 그 규칙에 따라 만들어진 실제 State 데이터를 저장한다.
18. State Sync는 왜 Execution과 연결되는가?
현재 State는 지금까지의 모든 State Transition이 누적된 결과다.
원칙적으로 Genesis부터 모든 Block을 실행하면 현재 State를 만들 수 있다.
Genesis S0
↓ B1
S1
↓ B2
S2
↓ B3
...
↓ B1,000,000
Current State
하지만 새로운 Node가 이 모든 Block을 처음부터 Replay하면 오래 걸린다.
그래서 State Sync를 통해 검증 가능한 최근 State를 받아 저장하고 그 이후 Block부터 실행할 수 있다.
Genesis부터 Replay
X
최근 State 확보
↓
DB에 저장
↓
그 이후 Block부터 Execution
↓
최신 State 유지
따라서 State Sync는 단순한 네트워크 다운로드 문제가 아니라 Execution의 결과물인 State와 State Storage를 어떻게 복구할 것인가라는 문제와 연결된다.
19. Avalanche는 원하는 VM을 사용할 수 있는 구조다
Avalanche를 공부하면서 중요한 구조를 알게 됐다.
Avalanche에서는 Consensus와 VM/Application Logic이 분리되어 있다.
개념적으로:
AvalancheGo
│
Snowman Consensus
│
VM Interface
│
┌───────┼────────┐
▼ ▼ ▼
EVM PulseVM Custom VM
즉 Avalanche Consensus가 특정 Execution Model 하나에 강하게 묶여 있는 구조가 아니다.
정해진 VM Interface를 구현한다면 서로 다른 State Machine을 연결할 수 있다.
예를 들어 Avalanche 내부에서도:
C-Chain
↓
Coreth / EVM 계열
P-Chain
↓
PlatformVM
X-Chain
↓
AVM
처럼 서로 다른 VM을 사용한다.
20. AvalancheGo와 VM은 Interface로 연결된다
Consensus Engine이 VM 내부 구현을 모두 알 필요는 없다.
VM이 정해진 Interface를 구현하면 된다.
개념적으로:
AvalancheGo
"Block 만들어줘"
↓
VM.BuildBlock()
"이 Block 확인해줘"
↓
Block.Verify()
"Consensus 결과 이 Block Accepted야"
↓
Block.Accept()
이런 식으로 Consensus와 Execution 계층이 Interface를 통해 통신한다.
따라서 AvalancheGo 입장에서는 VM 내부가 EVM인지, Antelope 계열인지 등의 세부 실행 규칙을 모두 직접 알아야 할 필요가 없다.
21. Antelope Execution Model
Antelope에서 Execution은 단순히 WASM 명령어 몇 개를 실행하는 것보다 넓은 개념으로 보는 것이 좋다.
Antelope에는 다음과 같은 실행 모델이 있다.
Account
↓
Permission / Authority
↓
Transaction
↓
Action
↓
WASM Contract
↓
Inline Action
↓
Table / State Read & Write
↓
Resource 처리
↓
State Transition
예를 들어:
Transaction
alice@active
├─ token::transfer
└─ dex::swap
이 Transaction을 실행할 때 Antelope 계열 실행 환경은:
Signature 확인
Permission 확인
Action Dispatch
WASM Contract 실행
Inline Action 처리
DB Read / Write
Resource 처리
Atomicity 처리
등의 규칙을 적용한다.
따라서 Antelope Execution Model이라고 하면 단순히 WASM Runtime 하나만 의미하기보다 Account, Permission, Action, WASM, State Transition 등을 포함한 전체적인 실행 환경으로 이해하는 것이 좋다.
22. PulseVM은 왜 존재하는가?
여기서 PulseVM이 연결된다.
처음에는:
"Metal/Avalanche 계열인데 왜 Antelope VM을 사용하지?"
라는 의문이 들었다.
하지만 Consensus와 Execution을 분리해서 생각하면 자연스럽다.
Blockchain
│
┌─────────┴─────────┐
│ │
Consensus Execution
│ │
Avalanche / PulseVM
Snowman Antelope 계열
즉 PulseVM은 Antelope 전체 블록체인을 Avalanche 안에 넣는다는 의미가 아니다.
Antelope 계열의 Execution Model을 Avalanche의 VM 구조에 맞게 연결하는 것에 가깝다.
23. EVM과 PulseVM의 차이를 개념적으로 보면
EVM을 사용하면 Ethereum 계열의 Execution Environment를 사용하게 된다.
Transaction
↓
Ethereum Account Model
↓
EVM
↓
Smart Contract
↓
EVM Storage / Gas Rules
↓
State Transition
PulseVM을 사용하면 Antelope 계열의 Execution Model을 사용할 수 있다.
Transaction
↓
Antelope 계열 Account
↓
Permission / Authority
↓
Action
↓
WASM Contract
↓
Antelope 계열 State / Resource Rules
↓
State Transition
즉 어떤 VM을 선택하느냐는 결국 어떤 State Machine과 Execution Rule을 사용할 것인가를 선택하는 것이라고 볼 수 있다.
24. 왜 PulseVM을 사용할까?
PulseVM을 사용하는 이유는 Avalanche의 Consensus를 사용하면서도 Antelope 계열의 Execution Model이 가진 특징을 활용하고 싶기 때문이다.
예를 들어 Antelope 계열에는:
Account
Permission / Authority
Action
WASM Contract
Resource Model
State Model
등의 실행 구조가 있다.
특히 Permission 구조를 이용하면 단순한:
Private Key → Address
보다 애플리케이션 수준에서 세밀한 권한 모델을 구성할 수 있다.
PulseVM은 이런 Antelope 계열 실행 환경을 Avalanche의 VM Interface와 연결한다.
개념적으로:
Avalanche / Snowman
Consensus
│
│
VM Interface
│
▼
PulseVM
│
Antelope 계열 Execution
│
┌─────────┼─────────┐
│ │ │
Account Permission Action
│
WASM
│
State Transition
│
▼
DB
따라서:
Avalanche의 Consensus + Antelope 계열의 Execution
이라는 조합이 가능해진다.
25. 오늘 공부한 전체 흐름
오늘 배운 내용을 하나의 그림으로 연결하면 다음과 같다.
User
│
│ Transaction 생성
▼
Transaction
│
│
▼
Validation
│
│ "이 요청을 처리해도 되는가?"
▼
Block Candidate
│
│
▼
Consensus
│
│ "어떤 Block / Ordering을 인정할 것인가?"
▼
Accepted Block
│
│
▼
Execution
│
│ VM의 실행 규칙 적용
▼
State Transition
│
│
▼
New State
│
│
▼
DB에 저장
│
│
▼
Finality / Settlement
Continuous Execution에서는 이 과정 중 Consensus와 Full Execution이 Pipeline처럼 겹쳐 진행될 수 있다.
Consensus
B100 ─ B101 ─ B102 ─ B103 ──→
Execution
B100 ─ B101 ─ B102 ──→
따라서 Consensus가 반드시 모든 Full Execution을 하나씩 기다렸다가 다음 Block으로 넘어가야 하는 것은 아니다.
26. 오늘의 핵심 정리
오늘 공부하면서 가장 중요했던 것은 Blockchain Core를 하나의 덩어리로 생각하지 않고 역할별로 분리해서 보는 것이었다.
Transaction
= State 변경 요청
Validation
= 이 요청을 처리해도 되는가?
Execution
= 실제 실행했을 때 State가 어떻게 바뀌는가?
State Transition
= S0 → S1
Block Execution
= Block의 Transaction을 순서대로 State에 적용
Deterministic Execution
= 같은 State + 같은 입력 순서 + 같은 규칙 → 같은 결과
Consensus
= 어떤 Block / History를 인정할 것인가?
Finality
= 인정된 History를 언제 최종 확정된 것으로 볼 것인가?
VM
= State의 구조와 Validation / Execution / Transition 규칙을 구현
DB
= 실제 현재 State 데이터를 영속적으로 저장
State Sync
= 과거 전체를 Replay하지 않고 검증 가능한 State를 확보하여 동기화
PulseVM
= Antelope 계열 Execution Model을 Avalanche VM 구조에 연결
결국 가장 큰 그림은 다음과 같다.
Blockchain Node
│
┌──────────┴──────────┐
│ │
Consensus Execution
│ │
어떤 History를 State를 어떻게
인정할 것인가? 변경할 것인가?
│ │
│ VM
│ │
└─────────┬───────────┘
│
State
│
▼
DB
그리고 Avalanche + PulseVM을 이 그림에 대입하면:
Metal / Avalanche 계열
│
Snowman Consensus
│
VM Interface
│
▼
PulseVM
│
Antelope 계열
Execution Model
│
State Transition
│
▼
DB
오늘 공부한 내용을 한 문장으로 정리하면:
Consensus는 "무엇을 실행할지"를 합의하고, VM은 "그것을 실행하면 State가 어떻게 변하는지"를 결정하며, DB는 그 결과 State를 저장한다.
그리고 PulseVM은 이 구조에서 Avalanche의 Consensus와 Antelope 계열의 Execution Model을 연결하는 VM이라고 이해할 수 있다.
'Study' 카테고리의 다른 글
| TIL - Transaction Validation과 Deterministic State Transition (0) | 2026.09.15 |
|---|---|
| TIL - DB 커넥션 점유시간과 Redis 혼재로 인한 동시성 병목 (0) | 2026.08.15 |
| TIL - 로또 게임 쇼츠 자동화 파이프라인 구축기 (0) | 2026.08.13 |
| TIL - JVM Cold Start: 왜 첫 요청은 항상 느린가 (0) | 2026.08.07 |
| TIL - ExecutorService와 CountDownLatch로 동시성 테스트하기 (0) | 2026.07.29 |