TIL - Transaction Validation과 Deterministic State Transition

블록체인에서 Transaction은 단순히 데이터를 전달하는 메시지가 아니라 블록체인 상태(State)를 변경하기 위한 요청이다.

예를 들어 A가 B에게 10개의 토큰을 전송한다고 생각해보자.

현재 상태가 다음과 같다고 가정한다.

A
balance: 100
nonce: 5

B
balance: 20
nonce: 2

A가 다음 Transaction을 생성한다.

from: A
to: B
amount: 10
nonce: 5
signature: ...

하지만 노드는 이 Transaction을 받았다고 바로 상태를 변경하지 않는다.

먼저 이 요청이 유효한 요청인지 검증(Transaction Validation) 해야 한다.

1. Transaction Validation

간단한 송금 Transaction이라면 다음과 같은 검증을 생각할 수 있다.

1. Signature 검증
2. Sender가 존재하는지 확인
3. Nonce가 현재 상태와 일치하는지 확인
4. Balance가 충분한지 확인
5. 모든 검증을 통과하면 State Transition 실행

Signature — 누가 요청했는가?

서명(Signature)은 이 Transaction을 실제 계정 소유자가 요청했다는 것을 증명한다.

공격자가 임의로

from: A
to: Hacker
amount: 100

이라는 Transaction을 만든다고 하더라도 A의 Private Key로 생성한 올바른 서명이 없다면 검증 단계에서 거부된다.

즉,

Signature는 해당 상태 변경을 요청할 권한이 있는지를 증명한다.

Nonce — 몇 번째 요청인가?

Nonce는 계정이 발생시킨 Transaction의 순서를 관리한다.

예를 들어 A의 현재 nonce가 5라면 다음 Transaction 역시 nonce 5를 사용해야 한다고 가정할 수 있다.

Transaction이 정상적으로 처리되면 상태는 다음과 같이 변경된다.

A
balance: 90
nonce: 6

B
balance: 30
nonce: 2

이미 처리된 nonce 5의 Transaction을 누군가 다시 전송하더라도 현재 A의 nonce는 6이므로 검증에 실패한다.

따라서 nonce는 크게 두 가지 역할을 한다.

• Transaction의 실행 순서를 통제한다.
• 이미 실행된 Transaction을 다시 실행하는 Replay Attack을 방지한다.

2. State Transition

Transaction이 모든 검증을 통과했다면 실제 상태를 변경할 수 있다.

이를 **State Transition(상태 전이)**이라고 한다.

현재 상태 S
   ↓
Transaction 실행
   ↓
새로운 상태 S'

이를 함수처럼 표현하면 다음과 같이 생각할 수 있다.

S' = F(S, Tx)

즉,

현재 상태(State)와 Transaction을 입력하면 새로운 상태가 나온다.

송금 Transaction이라면 대략 다음과 같은 변화가 발생한다.

sender.balance -= amount
receiver.balance += amount
sender.nonce += 1

중요한 점은 유효하지 않은 Transaction은 상태를 변경해서는 안 된다는 것이다.

Validation 실패
      ↓
State Transition 실행 X
      ↓
기존 State 유지

3. 왜 Deterministic해야 하는가?

블록체인에는 동일한 상태를 유지하는 여러 노드가 존재한다.

예를 들어 세 노드가 동일한 초기 상태와 동일한 Transaction 목록을 가지고 있다고 하자.

Node A ─┐
Node B ─┼─ 같은 State + 같은 Transactions
Node C ─┘

각 노드는 Transaction을 각자 직접 실행한다.

그런데 실행 결과가 노드마다 다르다면 어떻게 될까?

Node A → State Hash: AAA
Node B → State Hash: BBB
Node C → State Hash: CCC

블록체인이 하나의 상태에 합의할 수 없게 된다.

따라서 상태 전이는 **Deterministic(결정론적)**이어야 한다.

즉,

같은 초기 State
+
같은 Transaction 목록
+
같은 실행 규칙

        ↓

같은 최종 State
+
같은 State Hash

가 보장되어야 한다.

쉽게 말하면 누가 실행하든 입력이 같으면 결과도 반드시 같아야 한다.

이것이 블록체인 실행 환경에서 결정론이 중요한 이유다.

4. Transaction Validation → State Transition → Block Execution

이 세 개념은 범위를 기준으로 구분하면 이해하기 쉽다.

Transaction Validation
        ↓
개별 Transaction이 실행 가능한지 검사

State Transition
        ↓
유효한 Transaction을 실제 State에 적용

Block Execution
        ↓
Block 안의 Transaction들을 순서대로 실행

예를 들어 하나의 블록에 다음 Transaction들이 있다고 해보자.

Block #100

Tx1: A → B 10
Tx2: B → C 5
Tx3: C → D 3

노드는 블록을 실행하면서 각 Transaction을 순서대로 검증하고 상태를 변경한다.

State S0

↓ Tx1 검증 + 실행

State S1

↓ Tx2 검증 + 실행

State S2

↓ Tx3 검증 + 실행

State S3

따라서 블록 실행은 결국 여러 개의 Transaction Validation과 State Transition을 순서대로 수행하는 과정이라고 볼 수 있다.

5. 그럼 Validator와 Finality는 어디에 있는가?

여기서 실행(Execution)과 합의(Consensus)를 구분하는 것이 중요하다.

Transaction Validation과 State Transition은 주로 다음 질문을 다룬다.

"이 Transaction을 실행하면 상태가 어떻게 바뀌는가?"

반면 Validator와 Finality는 다음 문제와 연결된다.

"어떤 블록을 우리가 정식 블록으로 인정할 것인가?"

개념적으로 보면 다음과 같이 나눌 수 있다.

Transaction
     ↓
Validation
     ↓
State Transition
     ↓
Block Execution
     ↓
실행 결과 / 새로운 State

그리고 별도의 합의 메커니즘을 통해 네트워크가 어떤 블록과 상태를 정식 체인의 결과로 받아들일지 결정한다.

따라서 블록체인 코어를 공부할 때는

Execution과 Consensus를 분리해서 생각하는 것이 중요하다.

정리

Transaction은 블록체인 상태를 변경하기 위한 요청이다.

노드는 Transaction을 받으면 먼저 Signature, Nonce, Balance 등의 조건을 검증한다. 검증을 통과한 Transaction만 State Transition을 통해 실제 상태를 변경한다.

그리고 모든 노드는 동일한 초기 상태와 동일한 Transaction 목록을 실행했을 때 반드시 동일한 결과를 만들어야 한다.

그래야 네트워크의 모든 노드가 동일한 State와 State Hash를 유지할 수 있다.

핵심 흐름은 다음과 같다.

Transaction
    ↓
Validation
    ↓
State Transition
    ↓
Block Execution
    ↓
New State

오늘 기억할 문장

서명은 권한을 증명하고, nonce는 순서를 통제하며, deterministic state transition은 모든 노드가 같은 상태에 도달하게 한다.