Layer 1 Solutions: On-Chain Scalability

wine Faster·2026년 9월 10일
Layer 1

블록체인

목록 보기
2/2

1. 강의 주제

Layer 1 Solutions: On-Chain Scalability

핵심 범위:

  • 샤딩(Sharding)
  • 크로스 샤드 트랜잭션(Cross-Shard Transaction)
  • 상태 유효성(State Validity)
  • 블록체인 상호운용성(Blockchain Interoperability)
  • Cosmos / Polkadot
  • Cosmos SDK 기반 체인 구조

Lecture 02의 중심 질문은 다음과 같다.

모든 노드가 모든 트랜잭션(Transaction)을 처리하고 모든 데이터를 저장해야 한다면, 이 작업을 여러 그룹으로 나눠 병렬 처리할 수 없을까?

강의에서는 이를 샤딩(Sharding)의 출발점으로 설명한다. 트랜잭션 처리를 여러 샤드(Shard)로 나누고 병렬 실행하면 수평적 확장(Horizontal Scaling)이 가능하다.

2. 블록체인 확장성의 근본 문제

전통적인 블록체인에서는:

Every Node
   ↓
Process All Transactions
   ↓
Store All Data
   ↓
Maintain Total Ordering

즉, 모든 노드가:

  • 모든 트랜잭션(TX)을 처리하고
  • 모든 데이터를 저장하며
  • 트랜잭션의 전체 순서(Total Ordering)를 유지해야 한다.

이 구조는 노드가 늘어난다고 해서 처리량(Throughput)이 그대로 증가하지 않는 원인이 된다.

3. 샤딩(Sharding)

3.1 기본 개념

샤딩은 하나의 큰 작업 공간을 여러 개의 작은 파티션(Partition)으로 나누는 방식이다.

Without Sharding

TX1
TX2
TX3
TX4
 ↓
One Processing Group
With Sharding

TX1, TX2 → Shard 1
TX3, TX4 → Shard 2

Shard 1 || Shard 2
       Parallel

핵심은:

트랜잭션 처리를 여러 샤드로 분할하고 병렬 실행한다.

3.2 데이터베이스에서의 샤딩

강의에서는 MongoDB를 예로 든다.

샤딩이 필요한 대표적인 상황:

  • 매우 큰 데이터 양(Huge Data Volume)
  • 높은 읽기/쓰기 요청량(High R/W Request Load)

효과:

Better Parallelization
→ Higher Throughput

Smaller Search Space per Shard
→ Faster Response

즉, 여러 샤드가 요청을 병렬로 처리하므로 전체 처리량이 높아지고, 각 샤드가 검색해야 할 데이터 범위는 줄어든다.

3.3 샤드 키(Shard Key)

샤드 키(Shard Key)는 특정 데이터나 요청을 어느 샤드로 보낼지 결정하는 인덱스 필드(Index Field)다.

예:

Address ending 01 → Shard 1
Address ending 02 → Shard 2
...
Address ending 09 → Shard 9

강의에서는 사용자의 주소 마지막 몇 자리를 샤드 키로 사용하는 예를 든다.

4. 전통적 샤딩과 블록체인 샤딩의 차이

Traditional Sharding

전통 시스템은 일반적으로:

  • 신뢰된 인프라(Trusted Infrastructure)
  • 충돌 장애(Crash Failure)
  • 허가된 신원(Permissioned Identity)

을 가정한다.

Blockchain Sharding

블록체인은:

  • 적대적 네트워크(Adversarial Network)
  • 비잔틴 장애(Byzantine Failure)
  • 시빌 신원(Sybil Identity)

을 고려해야 한다.

따라서 데이터베이스 샤딩보다 보안 문제가 훨씬 어렵다.

5. Strawman Sharding

가장 단순한 방식은 각 샤드에 독립적인 검증자(Validator) 그룹을 배치하고 각자 체인을 운영하는 것이다.

문제는 두 가지다.

문제 1. 보안 감소

샤드가 s개라면 검증자가 나뉘므로 각 샤드의 검증자 집합은 작아진다.

강의에서는 s개의 샤드로 분할하면 무작위 검증자 할당이 없을 경우 보안이 약 s배 감소할 수 있다고 설명한다.

문제 2. Cross-Shard Transaction

서로 다른 샤드에 있는 사용자끼리 바로 트랜잭션하기 어렵다.

6. 랜덤 검증자 할당(Random Validator Assignment)

보안 문제를 줄이기 위해 검증자가 원하는 샤드를 선택하게 하지 않고 무작위로 배정한다.

이렇게 하면 공격자가 자신의 악성 노드를 특정 샤드에 집중시키기 어려워진다.

장점:

  • 보안 감소를 크게 완화할 수 있다.

하지만 샤드 자체가 여전히 작은 공격 목표(Smaller Target)이므로 완전한 해결책은 아니다.

따라서 검증자를 주기적으로 무작위 재배치(Random Shuffle / Rotation)해야 한다.

이를 위해 랜덤 비콘 체인(Random Beacon Chain)이 필요하다.

7. 편향되지 않은 랜덤성(Unbiased Randomness)

7.1 RandHound / RandHerd

여러 참가자가 공동으로 랜덤값을 생성한다.

요구되는 특성:

  • 공개 검증 가능(Publicly Verifiable)
  • 예측 불가능(Unpredictable)
  • 편향 불가능(Unbiasable)

7.2 VRF

검증 가능한 랜덤 함수(Verifiable Random Function, VRF)는 공개키 기반 키드 해시(Public-Key Version of a Keyed Cryptographic Hash)로 설명된다.

  • 개인키(Private Key)를 가진 사람만 결과를 계산할 수 있다.
  • 누구나 공개키(Public Key)를 이용해 그 결과가 올바른지 검증할 수 있다.

8. Beacon Chain과 Shard Chain

                Beacon Chain
              /      |      \
             /       |       \
        Shard 1   Shard 2   Shard 3

Beacon Chain의 역할

  • 랜덤성(Randomness) 제공
  • 크로스 샤드 트랜잭션(Cross-Shard Transaction) 지원
  • 크로스 링크(Cross-Link) 집계
  • 최종 블록(Finalized Block) 구성

Shard Chain의 역할

  • 실제 트랜잭션 실행
  • 샤드 내부 블록 검증
  • 효율적인 BFT 합의(BFT Consensus)

간단히 기억:

Shard Chain = Execution
Beacon Chain = Coordination

9. Cross-Link / Chain-Link

Beacon Chain이 각 샤드의 최신 상태를 알아야 하므로 샤드 검증자는 주기적으로 새 블록 정보를 Beacon Chain에 제출한다.

이를 체인 링크(Chain-Link) 또는 크로스 링크(Cross-Link)라고 표현한다.

10. Transaction Sharding vs State Sharding

Case 1. Entire Block 제출

Shard
  ↓
Entire Block
  ↓
Beacon Chain

이 경우:

Transaction Sharding Only

상태(Global State)는 Beacon Chain 수준에 존재한다.

따라서 Cross-Shard Transaction은 Beacon Chain에서 동기적으로(Synchronously) 실행될 수 있다.

Case 2. Block Header만 제출

Shard
  ↓
Block Header
  ↓
Beacon Chain

이 경우:

Transaction & State Sharding

Transaction과 State 모두 샤딩된다. Beacon Chain에 완전한 Global State가 존재하지 않으므로 Cross-Shard Transaction은 Beacon Chain의 중계(Relay)를 받아 각 Shard에서 비동기적으로(Asynchronously) 처리된다.

시험 핵심 비교

Cross-LinkSharding TypeCross-Shard 처리
Entire BlockTransaction Sharding OnlySynchronous
Block HeaderTransaction & State ShardingAsynchronous

11. 비동기 Cross-Shard Transaction과 Atomicity

State Sharding에서는 서로 다른 샤드의 작업이 동시에 끝난다는 보장이 없다.

예:

Shard 1: Train Ticket
Shard 2: Hotel Reservation

원하는 결과:

Train ✓ + Hotel ✓
또는
Train ✗ + Hotel ✗

허용하면 안 되는 결과:

Train ✓
Hotel ✗

여기서 필요한 개념이 원자성(Atomicity)이다.

Atomicity = 전부 성공하거나 전부 실패하는 보장(All-or-Nothing Guarantee)

12. Beacon Chain Validator가 하는 일

강의의 Transaction Sharding 사례에서 Beacon Chain Validator는:

  1. 올바른 Shard Committee가 승인한 Shard Block의 서명(Signature)을 검증
  2. Cross-Shard Transaction 처리
  3. 모든 Shard의 Raw Block을 집계
  4. Merkle 구조로 Global State Tree 생성

을 수행한다.

13. Beacon Validator의 하드웨어 요구사항

Shard가 s개라면 Beacon Validator는 모든 Shard의 Raw Block을 저장한다.

따라서:

  • 통신 대역폭(Communication Bandwidth) 증가
  • 저장공간(Storage) 약 s배 증가

할 수 있다.

하지만 모든 Shard Block을 다시 실행하지는 않는다.

실제 무거운 연산은 Shard Committee가 수행하고, Beacon Validator는 주로 Coordination, Proof Verification, Commitment Verification을 담당한다.

14. Data Availability와 State Validity

Data Availability

강의의 Transaction Sharding 사례에서는 모든 상태가 Beacon Chain 수준에 집계되므로 데이터 가용성(Data Availability) 문제가 비교적 단순하다.

State Validity

각 Shard에서 PBFT가 블록의 정확성을 보장한다.

샤드가 악성으로 변하면 사용자는 Beacon Chain에서 해당 Shard Validator에게 상태 전이 증명(State Transition Proof)을 요구하며 Challenge할 수 있다.

15. Quadratic Sharding

Beacon Chain도 하나의 블록체인이므로 샤드 수를 무한히 늘릴 수 없다.

강의의 예시:

Node Performance ×4
→ Per-Shard Throughput ×4
→ Supported Shards ≈ ×4
→ Total Improvement ≈ 16×

이를 이차 샤딩(Quadratic Sharding)이라고 부른다.

16. State Validity를 보장하는 두 가지 방법

16.1 Fisherman / Fraud Proof

상호작용식 계산 증명(Interactive Proof of Computation)이다.

Result Submitted
      ↓
Challenge Period
      ↓
Someone Challenges
      ↓
Submit Evidence

Challenge Period 안에 누구나 계산 무결성(Computation Integrity)을 의심할 수 있다.

결과 계산자는 정해진 시간 안에 증거(Evidence)를 제출해야 하며, 응답하지 못하면 Fraud의 증거로 사용할 수 있다.

16.2 SNARK

비상호작용식 암호학적 계산 증명(Non-Interactive Cryptographic Proof of Computation)이다.

개념적으로:

f1(f2(f3(...fk(x)))) = y

라는 결과에 대해 공개 검증 가능한 증명(Publicly Verifiable Proof) π를 함께 제시한다.

비교

항목Fraud ProofSNARK
방식InteractiveNon-Interactive
기본 구조Challenge → ResponseResult + Proof
Challenge Period필요핵심 메커니즘 아님
핵심 아이디어잘못됐으면 Challenge처음부터 증명 첨부

17. Elastico / Zilliqa Sharding

대표적인 Transaction Sharding 사례다.

동작 순서:

1. Identity Establishment
   → PoW

2. Assign Shard Committee
   → RANDAO

3. Intra-Committee Consensus
   → PBFT

4. Final Consensus Broadcast
   → Commit Entire Block

5. Generate Next Epoch Randomness

Cross-Link가 Entire Block이므로:

Transaction Sharding Only

이다.

18. NearProtocol Sharding

NearProtocol은:

  • Stake 기반 VRF
  • Threshold PoS
  • TxFlow
  • Cross-Link = Block Header

를 사용한다.

따라서:

Transaction & State Sharding

에 해당한다.

비교

Elastico / ZilliqaNearProtocol
PoWStake 기반
RANDAOVRF
PBFTThreshold PoS + TxFlow
Entire BlockBlock Header
Transaction ShardingTransaction + State Sharding

19. ETH2.0 Sharding

강의에서 설명한 구성:

  • 제한형 PoS(Bounded PoS)
  • Sharding Management Contract에 Security Deposit
  • VRF
  • Cross-Link = Block Header
  • Transaction & State Sharding
  • Casper FFG PoS(Friendly Finality Gadget)

역할:

  • Proposer = Shard Validator
  • Attester = Validity Inspector
  • Attester는 Checkpointed Block에 서명하는 Notary 역할

20. Blockchain Interoperability ≈ State Sharding

강의에서는 블록체인 상호운용성(Blockchain Interoperability)을 상태 샤딩(State Sharding)과 비슷한 구조로 설명한다.

State ShardingCosmosPolkadot
Beacon ChainCosmos HubRelay Chain
Shard ChainCosmos ZonePara Chain
Cross-Shard TXIBCCross-Chain TX

21. Cosmos 구조

             Cosmos Hub
              /      \
             /        \
         Zone 1      Zone 2

각 Zone은 독립적인 블록체인이다.

Zone 간 통신은 블록체인 간 통신(Inter-Blockchain Communication, IBC)을 이용한다.

22. Cosmos와 Polkadot의 차이

Cosmos

각 Zone은 Tendermint Consensus를 사용하거나 다른 Consensus를 사용한 뒤 Tendermint와 연결할 수 있다.

Polkadot

Parachain은 플러거블 합의(Pluggable Consensus) 구조로 설명된다.

23. Cosmos: Deterministic Finality

강의에서는 Cosmos/Tendermint의 최종성을 확률적 체인(Probabilistic Chain)과 비교한다.

Longest-Chain 방식에서는 시간이 지나면서 해당 체인이 Canonical Chain일 확률이 높아진다.

Tendermint에서는 합의가 끝난 블록이 결정적 최종성(Deterministic Finality)을 갖는 방식으로 소개된다.

24. Cosmos Light Client

Light Client는 전체 블록을 저장하지 않고 Block Header 중심으로 검증한다.

주요 정보:

  • 최신 Header
  • Validator Set

이 정보를 이용해 이후 Header를 검증한다.

25. Cosmos Hub and Zones

Hub는 여러 Zone을 연결하고 각 Zone의 Block Header를 추적한다.

Cross-Zone Transfer는 다음과 같은 구조로 이해할 수 있다.

Zone 1
Lock Coins
   ↓
Proof
   ↓
Hub
   ↓
Zone 2

26. Cosmos로 자체 체인 만들기

CometBFT
   ↓
Consensus

Cosmos SDK
   ↓
Framework

Your Module
   ↓
Custom Business Logic

CometBFT

다음 블록에 합의하고 노드를 동기화한다.

Cosmos SDK

다음 기능을 처리하는 블록체인 프레임워크다.

  • Accounts
  • Transactions
  • Fees
  • Reusable Blockchain Features

Custom Module

개발자가 정의하는 사용자 비즈니스 규칙이다.

예:

  • Market
  • Game
  • Identity
  • Payment

27. Cosmos 개발 흐름

1. Start
   ↓
Use a Working Chain Scaffold

2. Add
   ↓
Define Custom Rule

3. Connect
   ↓
Wire Rule into App

4. Run
   ↓
Start Local Node

5. Test
   ↓
Send Transaction
Query Result

28. Custom Module의 세 가지 부분

Message

사용자가 체인에 무엇을 하라고 요청하는가?

State

블록 처리 후 체인이 무엇을 기억하는가?

Query

사용자가 나중에 무엇을 읽을 수 있는가?

Message
   ↓
State Change
   ↓
Query

29. MsgCreateOrder 예시

type MsgCreateOrder struct {
    Creator string
    Symbol  string
    Amount  uint64
}

예시:

Creator = alice
Symbol  = ATOM
Amount  = 10

Keeper에서는:

if msg.Amount == 0 {
    return ErrInvalidAmount
}

으로 입력을 검증한다.

정상이라면 Order를 생성하고 State에 저장한다.

30. Cosmos Module 구현 패턴

Define
  ↓
Write
  ↓
Expose
  ↓
Connect
단계역할구성
Define요청과 데이터 정의Proto
Write비즈니스 규칙을 State에 적용Keeper
ExposeAction/Query 외부 제공MsgServer + Query
Connect실행 중인 App과 연결app.go

31. Module이 Ready가 되는 조건

Register
   ↓
Store
   ↓
Run
   ↓
Reach
단계의미구성
RegisterApp에 Module 등록module manager
StoreState 저장공간 연결keeper + store
RunStartup/Lifecycle에 포함genesis + order
ReachClient가 TX/Query 접근app.go + CLI

32. 시험 전 핵심 비교표

개념반드시 기억할 내용
ShardingTX 처리를 나누고 병렬 실행
Shard KeyTX/Data가 갈 Shard 결정
Blockchain ShardingByzantine + Sybil 고려 필요
Random Assignment악성 Validator 집중 방지
Random Rotation특정 Shard 장기 공격 방지
VRFPrivate Key로 계산, Public Key로 검증
Beacon ChainRandomness + Cross-Shard Coordination
Shard ChainExecution + BFT
Entire Block Cross-LinkTransaction Sharding Only
Block Header Cross-LinkTransaction + State Sharding
Cross-Shard AtomicityAll-or-Nothing
Fraud ProofInteractive Challenge
SNARKNon-Interactive Proof
Elastico/ZilliqaPoW + RANDAO + PBFT
NearStake VRF + Threshold PoS + TxFlow
Cosmos HubBeacon Chain과 유사
Cosmos ZoneShard Chain과 유사
IBCCross-Chain Communication
CometBFTConsensus
Cosmos SDKFramework
Custom ModuleBusiness Logic

33. 전체 흐름 한 장 정리

Blockchain Scalability Problem
        │
        │ Every node processes everything
        ↓
     Sharding
        │
        ├── Partition TX Processing
        ├── Parallel Execution
        └── Shard Key
        │
        ↓
Security Problem
        │
        ├── Byzantine Failure
        ├── Sybil Identity
        └── Smaller Validator Set
        │
        ↓
Random Validator Assignment
        │
        ├── Random Beacon
        ├── VRF
        └── Validator Rotation
        │
        ↓
   Beacon Chain
      /     \
Shard 1   Shard 2
   │         │
  BFT       BFT
      \     /
   Cross-Shard TX
        │
        ├── Entire Block
        │     → Transaction Sharding
        │
        └── Block Header
              → Transaction + State Sharding
                        │
                        ↓
                  Asynchronous TX
                        │
                        ↓
                     Atomicity
                        │
                        ↓
                 State Validity
                  /           \
          Fraud Proof        SNARK

────────────────────────────────

Blockchain Interoperability
        ≈ State Sharding

Beacon Chain → Cosmos Hub → Polkadot Relay Chain
Shard Chain  → Cosmos Zone → Polkadot Para Chain

Cosmos
  │
  ├── CometBFT → Consensus
  ├── Cosmos SDK → Framework
  └── Module → Custom Logic

한 문장으로 강의 정리하기

Lecture 02는 하나의 블록체인이 모든 작업을 처리하는 구조를 여러 샤드(Shard)로 분할해 병렬화하고, 그 과정에서 생기는 샤드 보안, 검증자 배치, Cross-Shard Transaction, Atomicity, State Validity 문제를 해결하는 방법을 다룬다. 후반부에서는 이 구조를 Cosmos와 Polkadot 같은 Blockchain Interoperability와 연결해 설명한다.

profile
wine Faster
이전 포스트

블록체인 기술 아직도 모른다면...이제는 정말 클리어!

0개의 댓글