🇰🇷 Cardano의 EUTXO 모델 - 제1부

[CryptoVeri]

Cardano의 EUTXO 모델 Part 1: 스마트 계약을 위한 블록체인 아키텍처의 진화

Ilhun @CryptoVeri
2025년 5월 19일

이 시리즈는 Cardano의 EUTXO 모델이 기존 블록체인 구조와 어떻게 다른지, 왜 중요한지, 그리고 개발자와 사용자가 어떤 이점을 얻을 수 있는지를 다룹니다. Part 1에서는 구조적 기초와 네이티브 자산에 대해 집중적으로 설명합니다.

---

목차

1. 서론: 블록체인 아키텍처 전쟁의 시대
2. 블록체인 회계 모델의 두 축
3. EUTXO: Cardano의 아키텍처적 진화
4. 네이티브 토큰: 스마트 계약 없는 다자산 시스템
5. (예고) Part 2 미리보기

---

1. 서론: 블록체인 아키텍처 전쟁의 시대

블록체인 플랫폼들은 그 핵심인 회계 모델에서 갈라지고 있습니다.

• Ethereum은 스마트 계약 유연성을 위해 계정 기반(Account/Balance) 모델을 채택했습니다.
• 반면 Bitcoin은 트랜잭션 기반의 UTXO(Unspent Transaction Output) 모델을 사용해 보안성과 추적성을 중시합니다.

하지만 이 두 모델은 각각 다음과 같은 문제를 가지고 있습니다:

• Ethereum: 전역 상태(global state) 갱신의 복잡성, 병렬성 부족, 예측 불가능한 수수료
• Bitcoin: 상태를 직접 보존하기 어렵고, 복잡한 스마트 계약 기능 구현에 제약이 있음

Cardano는 Extended UTXO (EUTXO) 모델을 통해 이 두 모델의 장점을 융합했습니다.
즉, Bitcoin의 명확성과 Ethereum의 유연성을 동시에 추구합니다.

---

2. 블록체인 회계 모델의 두 축

계정/잔고(Account/Balance) 모델

• 상태가 ‘계정’에 저장되며, 트랜잭션마다 상태가 갱신됨.
• 글로벌 상태를 참조하므로 병렬 트랜잭션 처리에 한계.
• 일부 계약 실패 시 전체 상태 롤백 → 수수료 손실.
• 예)

블록체인	특징 및 활용
Ethereum	대표적인 계정 기반 플랫폼. 스마트 계약 중심 생태계의 선구자. 모든 상태가 전역으로 유지됨.
BNB Chain	Ethereum과 유사한 구조. 빠른 처리 속도와 낮은 수수료를 추구함.
Avalanche	Ethereum Virtual Machine(EVM) 호환성 제공. 계정 기반 구조.
Solana	Solana는 계정 기반 모델을 사용하지만, Sealevel이라는 병렬 실행 환경을 통해 트랜잭션 간 충돌이 없는 경우 병렬 처리가 가능하도록 설계됨. 고성능을 위해 고유한 계정 관리 방식 도입.
Fantom	EVM 호환 스마트 계약 플랫폼으로, Ethereum과 같은 계정/잔고 모델 사용.
Near Protocol	샤딩(sharding) 기반 확장성과 계정 기반 상태 모델을 조합하여 설계됨.

UTXO 모델

• 트랜잭션은 ‘미사용 출력’을 소비하고 새로운 출력을 생성.
• 트랜잭션 간 상태가 격리되어 병렬 처리에 유리.
• 하지만 상태를 유지하거나 스마트 계약을 구현하기에는 불편함.
• 예)

블록체인	특징 및 활용
Bitcoin	UTXO 모델의 원형. 단순하고 안정적인 송금 시스템을 기반으로 설계됨.
Litecoin	Bitcoin의 파생체. UTXO 모델 기반이며, 송금 목적 중심.
Bitcoin Cash	Bitcoin과 동일한 UTXO 구조. 더 큰 블록 크기를 지원하여 처리량 증가 시도.
Zcash	프라이버시 기능이 추가된 Bitcoin 포크. UTXO 모델 유지.
Dash	마스터노드 기반의 인센티브 시스템을 추가한 UTXO 기반.
Ergo	스마트 계약 확장 가능한 UTXO 모델 사용. Cardano와 유사한 방향성.

EUTXO 모델의 도입

Cardano는 아래 요소를 통해 UTXO에 상태성과 계약성을 부여합니다:

• Datum: 상태 데이터
• Redeemer: 입력 정보
• Context: 트랜잭션 환경 정보
• Validator Script: 실행 조건 스크립트

이를 통해 Ethereum보다 더 정확하고 안전한 상태 기반 트랜잭션 구현이 가능합니다.

---

3. EUTXO: Cardano의 아키텍처적 진화

구성 요소

• Datum: UTXO에 담긴 상태 정보 (예: 토큰 소유자, 점수 등)
• Redeemer: 사용자 요청 정보 (예: 입찰 금액, 명령)
• Context: 현재 트랜잭션 관련 메타데이터
• Validator Script: 모든 조건을 검증하는 Haskell 기반 코드

코드 예시

mkValidator :: Datum -> Redeemer -> ScriptContext -> Bool
mkValidator datum redeemer ctx = (redeemer == expectedKey)

트랜잭션의 성공 여부는 오직 입력, 데이텀, 컨텍스트, 스크립트로 결정됩니다.
이를 통해 Cardano는 다음을 달성합니다:

• 오프체인에서 유효성 시뮬레이션 가능
• 예측 가능한 트랜잭션 결과
• 병렬 처리 구조로 확장성 극대화

---

물론입니다. 아래는 네이티브 토큰과 Forging Policy Script에 대한 부분을 독자들이 더 쉽게 이해할 수 있도록 설명을 보강한 버전입니다. 개념의 맥락, 실제 사용 시나리오, 그리고 구조적인 차별점을 명확히 밝혔습니다.

---

4. 네이티브 토큰: 스마트 계약 없는 다자산 시스템

Ethereum의 ERC 토큰의 문제점

Ethereum에서 새로운 토큰을 만들기 위해서는 보통 ERC-20 또는 ERC-721 표준을 따르는 스마트 계약을 직접 작성해야 합니다. 이 방식은 다음과 같은 문제를 내포하고 있습니다:

• 스마트 계약 작성 필요: 단순한 토큰 발행도 코딩 실력이 요구되며, 복잡한 로직 작성 시 오류 발생 가능성이 높아짐
• 보안 취약점: 잘못 작성된 스마트 계약 하나가 전체 토큰의 자산을 위험에 빠뜨릴 수 있음 (예: The DAO 해킹 사례)
• 비효율적 수수료 체계: Ethereum은 모든 연산에 대해 ‘가스’를 요구하고, 실패하더라도 가스 비용은 사라짐 → 수수료 예측이 어렵고 낭비 발생

결과적으로, 개발자는 높은 진입 장벽에 직면하고, 사용자는 불안정한 자산을 다루게 됩니다.

---

해결책: Cardano의 네이티브 토큰

Cardano는 네이티브(Native) 토큰 시스템을 도입하여 이 문제를 근본적으로 해결했습니다.

• 스마트 계약 없이 토큰을 발행, 전송, 소각 가능
  → ADA와 동일한 방식으로 다뤄지므로 개발자 부담 대폭 감소
• 토큰의 수수료도 ADA로만 지불
  → 일관된 수수료 체계, 수수료 예측 용이
• Ledger 수준에서 다자산(multi-asset) 처리 지원
  → L1(레벨 1) 체계에서 토큰을 ADA와 동일한 방식으로 직접 처리 가능하여, 스마트 계약을 거치지 않기 때문에 토큰 자체의 보안성이 높음
• 토큰 번들(Token Bundle) 구조로 여러 자산을 하나의 트랜잭션으로 처리 가능
  → 하나의 트랜잭션에서 입력과 출력 모두 여러 자산을 동시에 포함할 수 있는 구조

---

트랜잭션 예시 (Token Bundle 형태)

{
  "address": "addr1q9...",
  "amount": {
    "lovelace": 2000000,
    "policy1.mytoken": 10,
    "policy2.nft2025": 1
  }
}

• lovelace: ADA의 최소 단위 (이 예시에서는 2,000,000 러브레이스, 즉 2 ADA)
• policy1.mytoken: 사용자가 정의한 일반 토큰 (예: 포인트, 게임 머니 등)
• policy2.nft2025: 발행이 1회로 제한된 NFT (Non-Fungible Token)

하나의 주소에 ADA와 여러 종류의 토큰이 동시에 포함될 수 있습니다. 마치 디지털 지갑에 여러 종류의 지폐/쿠폰이 들어있는 것과 비슷합니다.

---

Forging Policy Script (토큰 발행 정책 스크립트)

Cardano는 토큰을 아무나, 아무 때나 무분별하게 찍어낼 수 없도록 토큰 생성 및 소각 규칙을 명확히 설정할 수 있도록 합니다. 이를 Forging Policy Script라고 합니다.

이 스크립트는 다음과 같은 조건을 설정할 수 있습니다:

• 지정된 주소만 발행 가능
  → 예: “이 토큰은 특정 회사 지갑 주소만 생성할 수 있다”

• 특정 블록 높이 이후에는 발행 불가
  → 예: “NFT는 2025년 블록 10,000 이후 발행 중지”

• 단 한 번만 발행하고 소각 불가
  → 예: “이 토큰은 유일하게 1개만 존재 (NFT에 이상적)”

간단한 예시 (의사 코드)

policy :: ScriptContext -> Bool
policy ctx =
  txSignedBy ctx issuer &&
  (getSlot ctx < deadline) -- 현재 슬롯을 ctx에서 추출하는 가정

※ 실제 스크립트에서는 ctx에서 슬롯 번호나 서명자를 명시적으로 추출해야 합니다.

→ ‘issuer’가 서명했고, 현재 시간이 마감 이전이면 발행 허용.

이 방식은 스마트 계약 수준의 제어력은 유지하면서도, 불필요한 복잡성과 수수료는 제거한 설계입니다.

---

정리

항목	Ethereum (ERC-20/721)	Cardano (네이티브)
구현 방식	스마트 계약 필요	Ledger 내장
보안성	계약 오류로 전체 위험	ADA와 동일한 수준
수수료	연산량에 따라 가변, 실패 시 소멸	고정적, 실패 시 낭비 없음
확장성	각각의 토큰이 별도 계약	Token Bundle 구조로 단일 트랜잭션 가능

5. (예고) Part 2 미리보기

Part 2에서는 다음을 다룹니다:

• 병렬성과 확장성이 실전에서 어떻게 발휘되는가
• DeFi에서 AMM과 Order Book 구조 비교
• NFT/DAO/접근 제어 설계 사례
• 최신 CIP (Cardano Improvement Proposals) 적용 사례

[Part 2: 실전 활용과 확장성] → 곧 발행 예정

---

* 참고 자료:

• Cardano EUTXO 개요 – IOHK 블로그(영문)
• EUTXO Handbook (PDF)
• 🇰🇷 EUTXO 핸드북 (통합본)