블록체인과 분산원장 | SW 전공

1. 분산원장과 블록체인

분산원장은 여러 참여자가 거래 기록의 복제본을 보유하고 정해진 합의 규칙에 따라 상태를 갱신하는 시스템이다. 블록체인은 거래를 블록 단위로 묶고 이전 블록과 암호학적으로 연결하는 대표적인 분산원장 구조이다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

Node A: Ledger Copy
Node B: Ledger Copy
Node C: Ledger Copy
      ▲
      │ 합의된 거래·상태 전파
      ▼
   Consensus

모든 분산 DB가 블록체인은 아니고, 모든 블록체인이 완전히 공개된 네트워크인 것도 아니다.

2. 블록 구조

일반적인 개념:

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

Block n
┌──────────────────────────┐
│ Previous Block Hash      │
│ Timestamp·Height         │
│ Transaction Root         │
│ Consensus Metadata       │
├──────────────────────────┤
│ Transaction 1            │
│ Transaction 2            │
│ ...                      │
└──────────────────────────┘

블록 형식은 구현마다 다르지만 이전 블록의 해시를 포함해 연결하는 구조가 핵심이다.

3. 해시 연결과 변조 탐지

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

Block 1
  hash=h1
     ↓ previous=h1
Block 2
  hash=h2
     ↓ previous=h2
Block 3

Block 1의 내용이 바뀌면 h1이 바뀌어 Block 2의 이전 해시와 맞지 않는다. 이후 블록과 합의 상태도 다시 만들어야 하므로 과거 기록 변경이 탐지·억제된다.

“절대 변경 불가능”이라는 표현보다 네트워크의 합의·복제·비용 구조 때문에 임의 변경이 매우 어렵고 탐지 가능하다고 설명하는 것이 정확하다.

4. Merkle Tree

많은 거래의 해시를 트리로 결합해 하나의 루트 해시로 요약한다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

         Merkle Root
         /         \
      H12           H34
     /  \           /  \
   H1   H2        H3   H4
   │    │         │    │
  Tx1  Tx2       Tx3  Tx4

전체 거래를 모두 전달하지 않아도 일부 해시 경로로 특정 거래가 블록에 포함되었는지 검증할 수 있다.

5. 거래와 전자서명

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

거래 내용
   ↓ Hash
거래 요약
   ↓ 개인키 서명
서명된 거래
   ↓ 네트워크 전파
공개키로 서명 검증

전자서명은 거래를 요청한 개인키 보유자와 무결성을 검증한다. 개인키가 탈취되면 공격자가 정상 서명을 만들 수 있으므로 키 관리가 매우 중요하다.

블록체인 주소가 반드시 법적 실명과 연결되는 것은 아니다.

6. 거래 처리 흐름

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

① 사용자가 거래 생성·서명
② 노드가 형식·서명·잔액·규칙 검증
③ 유효 거래를 후보 집합에 보관
④ 합의 참여자가 블록·상태 제안
⑤ 합의 규칙으로 순서·유효 상태 확정
⑥ 블록·원장을 다른 노드가 반영
⑦ 후속 블록·확정성 증가

구체 과정은 플랫폼마다 다르다.

7. 합의의 목적

합의는 중앙 관리자 없이 또는 여러 운영 주체 사이에서 다음을 결정한다.

어떤 거래가 유효한가
거래 순서는 무엇인가
현재 원장 상태는 무엇인가
충돌하는 제안 중 무엇을 채택할 것인가

합의는 “노드 절반이 찬성하면 항상 완료”되는 단일 규칙이 아니다.

8. 대표 합의 개념

방식	핵심	장점·주의
PoW	계산 작업으로 블록 제안 경쟁	공개망 검증, 에너지·처리량 비용
PoS	지분과 프로토콜 규칙으로 검증자 선택	에너지 절감, 지분·거버넌스 설계
BFT 계열	제한된 검증자들이 메시지 교환·투표	빠른 확정 가능, 참여자 수·통신비용
PoA·권한형	승인된 검증자 신원·권한 기반	기업망 효율, 운영 주체 신뢰 필요

합의 알고리즘의 장애허용 조건, 정족수, 확정성은 서로 다르다.

9. Fork와 Finality

Fork는 노드들이 잠시 다른 원장 분기를 따르는 상황이다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

         ┌─ Block 10A ─ Block 11A
Block 9 ─┤
         └─ Block 10B

프로토콜 규칙에 따라 한 분기가 선택되거나 즉시 확정성을 제공할 수 있다.

확률적 Finality: 후속 블록이 쌓일수록 되돌릴 가능성이 감소
결정적 Finality: 정족수 합의 후 되돌리지 않는 구조

“확인 횟수”는 플랫폼과 위험 수준에 따라 다르다.

10. 공개형과 권한형

기준	공개형(Permissionless)	권한형(Permissioned)
참여	누구나 가능할 수 있음	승인된 조직·사용자
검증자	공개 경쟁·지분 등	알려진 검증자
신원	가명 중심 가능	조직 신원 연결
처리·통제	분산성 강조	성능·규제·거버넌스 강조
적용	공개 자산·서비스	기업·기관 간 공유원장

권한형도 여러 주체 간 공동 통제가 필요한 경우에 의미가 있지만, 한 조직만 데이터를 관리한다면 전통 DB가 더 단순할 수 있다.

11. 스마트계약

스마트계약은 원장의 상태와 거래에 따라 결정론적 규칙을 실행하는 프로그램이다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

조건 충족?
   ├─ 예 → 자산 이전·상태 변경
   └─ 아니오 → 거부

장점:

규칙 자동 집행
공동 검증
투명한 상태 변화

위험:

코드 결함이 원장 상태에 직접 영향
배포 후 수정이 어려울 수 있음
외부 세계 정보를 직접 알지 못함
수수료·성능·프라이버시
관리자·업그레이드 권한 집중

12. Oracle

외부 환율·날씨·배송 결과 등을 스마트계약에 제공하는 장치·서비스이다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

외부 데이터
   ↓
Oracle 검증·서명
   ↓
Smart Contract

원장 내부 합의가 외부 데이터의 진실성까지 자동 보장하지는 않는다. Oracle이 잘못되면 계약도 잘못 실행될 수 있다.

13. 장점과 한계

적합 가능성이 높은 상황

여러 독립 조직이 같은 기록을 공유
단일 운영자를 완전히 신뢰하기 어려움
변경 이력과 공동 검증이 중요
자동화된 공동 규칙이 필요

부적합 가능성이 높은 상황

한 조직이 데이터와 권한을 전적으로 통제
초고속·대용량 변경이 필요
민감정보 삭제·수정 요구가 큼
외부 데이터 신뢰가 핵심
단순 중앙 DB가 비용·운영 면에서 충분

블록체인은 모든 데이터 문제의 보편적 해결책이 아니다.

14. 보안 위험

개인키 탈취
스마트계약 취약점
합의 참여자 담합
51% 계열 공격 가능성
Sybil 공격
Oracle 조작
브리지·지갑·거래소 취약점
프라이버시 노출
공급망·노드 소프트웨어 취약점

블록체인 자체의 암호학적 구조가 주변 애플리케이션과 운영의 안전성을 자동 보장하지 않는다.

참고 기준

NIST IR 8202: Blockchain Technology Overview

15. Merkle proof와 거래 모델

Merkle tree에서 8개 leaf 중 한 거래를 검증하려면 균형 이진트리 기준 형제 해시 3개가 필요하다. 전체 거래를 받지 않고도 O(log n)개의 해시로 root 포함 여부를 확인할 수 있지만, root 자체가 신뢰할 블록에 포함되어 있다는 전제가 필요하다.

UTXO 모델에서는 기존 출력 전체를 입력으로 소비하고 남는 금액을 change output으로 돌려준다. Account 모델은 계정 잔액과 nonce를 갱신한다. Nonce는 같은 서명 거래의 재전송·순서 문제를 제어하는 데 사용될 수 있다.

16. 합의와 장애 허용

합의 방식마다 안전 조건이 다르므로 “절반 이상 동의”를 보편 규칙으로 외우면 안 된다.

PoW: 계산 작업과 누적 작업량을 기반으로 경쟁
PoS: stake와 프로토콜 규칙에 따라 제안·검증, 위반 시 slashing 가능
BFT 계열: 전형적 모델에서 n≥3f+1이면 Byzantine 노드 f개를 견디도록 설계 가능

노드 10개라면 이 관계에서 견딜 수 있는 최대 f는 3이다. 실제 프로토콜의 네트워크·동기성·quorum 조건은 별도로 확인한다.

17. Finality·Fork·51% 공격의 범위

확률적 finality는 확인 블록이 쌓일수록 되돌릴 가능성이 낮아지는 방식이고, 결정적 finality는 합의 완료 후 되돌리지 않는 규칙을 지향한다. 51% 수준의 합의 자원 장악은 거래 검열·자기 거래 재조직 등에 영향을 줄 수 있지만, 타인의 개인키 서명을 위조하거나 해시함수의 수학적 보안을 자동으로 깨는 것은 아니다.

18. 스마트계약 보안

재진입 공격은 외부 호출이 상태 갱신 전에 실행될 때 반복 호출로 자금을 빼낼 수 있다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

Checks → Effects → Interactions
조건 확인 → 내부 상태 먼저 변경 → 외부 호출

추가로 권한검사, 입력 범위, 정수 처리, oracle 조작, upgrade 권한, pause·withdraw 한도를 점검한다. 온체인 코드는 외부 현실 데이터를 직접 알 수 없으므로 oracle의 정확성과 탈중앙화가 별도 신뢰 가정이 된다.

19. 적용 적합성 판정

여러 조직이 공동 원장을 운영하고 단일 운영자를 신뢰하기 어렵고, 기록의 순서·감사 가능성이 중요한 경우 후보가 될 수 있다. 반대로 단일 조직이 통제하고 높은 처리량·삭제·정정·개인정보 보호가 핵심이면 일반 DB와 서명 로그가 더 단순할 수 있다.

확인 문제

8개 leaf의 균형 Merkle tree proof 해시 수는?
BFT 관계 n≥3f+1에서 노드 10개의 최대 f는?
51% 공격이 타인 개인키 서명을 자동 위조하는가?
재진입 방어의 대표 상태 변경 순서는?
온체인 계약이 외부 가격을 얻을 때 추가 신뢰점은?