이더리움 백서 요약본

� 이더리움 백서 요약 (원문 충실 정리)

1. 서론 (Introduction)

비트코인 한계 지적: 비트코인은 ‘디지털 화폐’라는 특정 기능에 맞춰 설계됨. 따라서 범용적인 분산 애플리케이션(DApp)을 구현하기에는 한계가 있음.

목표: 이더리움은 "튜링 완전(Turing-complete)한 프로그래밍 언어를 가진 블록체인"을 제공해 모든 분산 애플리케이션을 단일 플랫폼에서 실행 가능하게 만들자는 비전.

2. 배경 (Background)

암호화폐 발전사: 비트코인 → 알트코인(라이트코인, 도지코인) → 카운터파티·메타코인 같은 오버레이 프로토콜.

문제: 각각 기능이 제한적이거나, 비트코인 코드에 맞춰 억지로 기능을 구현해야 해서 비효율적.

3. 비트코인과 합의 (Bitcoin & Consensus)

블록체인은 신뢰할 수 없는 환경에서도 **합의(consensus)**를 이루는 도구.

비트코인의 Proof-of-Work는 이를 성공시켰지만, 확장성과 유연성이 부족.

4. 스마트 계약 (Smart Contracts)

정의: "조건이 충족되면 자동으로 실행되는 코드."

비트코인의 Script 언어는 매우 제한적이라 복잡한 계약 구현 불가.

이더리움은 **범용 프로그래밍 언어(EVM: Ethereum Virtual Machine)**를 통해 누구나 복잡한 계약을 작성할 수 있게 함.

5. 이더리움의 목표 (Ethereum’s Goals)

범용 플랫폼: 특정 애플리케이션에 종속되지 않음.

개발자 친화적: 쉽게 분산 앱을 만들 수 있도록.

튜링 완전성: 임의의 계산을 표현할 수 있음.

6. 이더리움 아키텍처 (Ethereum Architecture)

계정(Account):

외부 소유 계정(EOA, 개인 지갑 주소)

계약 계정(Contract Account, 코드 저장 및 실행 가능)

트랜잭션(Transaction):

계정 간 이더 전송, 또는 계약 호출.

메시지(Message):

계약 간 호출 (재귀적 실행 가능).

가스(Gas):

무한 루프 방지 및 네트워크 자원 비용 책정을 위한 단위.

7. 애플리케이션 사례 (Applications)

백서에서는 대표적인 유즈케이스를 여러 개 제시:

토큰 시스템: 법정화폐, 금, 포인트 등을 토큰화.

금융 파생상품: 옵션, 선물 같은 디파이 초기 형태.

탈중앙화 조직(DAO): 블록체인 상의 투표·의사결정 시스템.

분산 스토리지, 네임 서비스: IPFS, ENS 같은 후대 프로젝트의 아이디어가 이미 등장.

8. 토큰 발행 및 경제 구조

이더(ETH): 네이티브 토큰, 가스 수수료 지불 및 인센티브 제공.

발행 모델: 초기 크라우드세일(ICO), 채굴 보상.

설계 철학: “플랫폼 유지와 보안을 위한 최소한의 인플레이션”

9. 보안 고려

튜링 완전 언어의 위험 → 가스 시스템으로 무한 루프 방지.

계약 코드 자체의 버그 리스크 → 오픈소스 감사 필요.

10. 결론

이더리움은 "세계용 컴퓨터(World Computer)"를 지향.

특정 목적 코인이 아닌, 범용 분산 애플리케이션 플랫폼으로 비트코인 이후 블록체인의 확장 가능성을 열었다.

� 핵심 한 줄 정리

이더리움 백서는 **“비트코인의 화폐 기능을 넘어, 모든 종류의 분산 애플리케이션을 구동할 수 있는 범용 블록체인 플랫폼을 만들자”**는 선언문이다.

쉽게 풀어쓴 버전

� 이더리움 백서 — 쉽게 풀어쓴 정리

1. 왜 이더리움이 나왔을까? (서론)

비트코인은 “디지털 돈”으로는 훌륭했지만, 다른 복잡한 프로그램이나 계약을 실행하기에는 너무 제한적이었어요. 이더리움은 이 한계를 넘어, 누구나 블록체인 위에서 자유롭게 앱을 만들고 실행할 수 있는 범용 플랫폼을 목표로 합니다.

2. 블록체인 진화의 흐름 (배경)

비트코인 이후 수많은 알트코인과 실험들이 나왔지만, 다들 특정한 기능에만 특화되어 있었죠. 그 결과 새로운 기능을 추가할 때마다 ‘새로운 코인’을 만들거나 억지로 기존 시스템을 개조해야 했습니다. 이더리움은 “그냥 한 번에 다 담을 수 있는 플랫폼을 만들자”는 생각에서 출발했습니다.

3. 신뢰 없는 세상에서의 합의 (비트코인과 합의)

블록체인의 핵심은 ‘서로 모르는 사람들끼리도 같은 장부를 신뢰할 수 있게 만든다’는 점입니다. 비트코인은 작업증명(Proof of Work)으로 이 문제를 해결했지만, 기능 확장에는 제약이 컸습니다.

4. 자동으로 실행되는 계약 (스마트 계약)

스마트 계약은 “조건이 맞으면 자동으로 실행되는 코드”입니다. 비트코인에도 제한적으로 비슷한 기능이 있었지만 너무 단순했죠. 이더리움은 **완전한 프로그래밍 언어(EVM)**를 도입해 훨씬 복잡하고 다양한 계약을 만들 수 있게 했습니다.

5. 이더리움의 핵심 목표 (Goals)

이더리움은 특정 목적의 코인이 아니라, 모든 종류의 분산 앱을 위한 범용 플랫폼입니다. 개발자가 직접 블록체인 기반 서비스를 쉽게 만들고 실행할 수 있도록 돕는 것이 가장 큰 목표입니다.

6. 이더리움의 구조 (Architecture)

이더리움은 두 가지 계정이 있어요:

개인이 쓰는 외부 계정(지갑)

코드를 담는 계약 계정(스마트 계약)

이 둘은 트랜잭션으로 연결되고, 계약끼리는 메시지를 주고받습니다. 이 과정에서 자원 낭비를 막기 위해 **가스(Gas)**라는 수수료 시스템을 두어, 무한루프 같은 문제를 차단합니다.

� 이더리움의 구조 (일반인 이해 버전)

1. 이더리움 세계 = 하나의 거대한 장부

이더리움은 ‘하나의 커다란 장부(회계장부 같은 것)’예요.

여기에는 모든 계정과 그 안에 담긴 돈, 규칙, 기록이 적혀 있습니다.

이 장부는 전 세계 수천 대의 컴퓨터가 똑같이 복사해 갖고 있어요.

누가 몰래 지우거나 조작하려고 해도, 다수가 같은 장부를 들고 있으니 들통이 나죠.

2. 두 종류의 계정 (사람 계정 vs. 자동로봇 계정)

이더리움에는 크게 두 가지 계정이 있습니다.

외부 계정(EOA) = “사람이 직접 쓰는 지갑”

우리가 사용하는 은행 계좌와 비슷합니다.

암호(비밀키)로 서명해서 돈을 보내거나 계약을 시작합니다.

스마트 계약 계정(Contract Account) = “로봇 은행원”

여기에는 코드(약속된 규칙)가 들어 있습니다.

스스로 움직이지는 못하고, 누군가가 버튼을 눌러줘야 실행됩니다.

예: “누가 1ETH를 보내면 자동으로 토큰 100개를 준다” 같은 프로그램.

� 쉽게 말해, 사람 계정은 버튼을 누르는 주체, 계약 계정은 버튼이 눌렸을 때 자동으로 일하는 기계예요.

3. 거래(트랜잭션) = 편지

이더리움에서 모든 행동은 “트랜잭션”이라는 편지를 보내는 것에서 시작됩니다.

편지를 보내는 사람: 외부 계정(지갑 주인)

편지 내용: “저 계좌에 돈을 보내줘” 혹은 “저 로봇(계약) 실행시켜”

편지에는 항상 **우표(가스)**가 붙어 있어요.

편지를 받은 네트워크는 편지를 열어보고, 규칙대로 처리합니다.

4. 계약 간 대화(메시지) = 전화

스마트 계약들끼리는 서로 전화를 걸 수 있습니다.

예를 들어:

A라는 계약(자판기)이 “콜라 하나 뽑아주세요”라고 B 계약(창고)에 전화를 겁니다.

B 계약은 창고에서 물건을 빼고 다시 A에게 돌려주죠.

이런 식으로 여러 계약이 한 번의 거래 안에서 연쇄적으로 움직일 수 있습니다.

5. 가스(Gas) = 택시 요금 + 타이머

여기서 중요한 게 바로 **가스(Gas)**입니다.

이더리움의 모든 행동(계산, 저장, 전송)은 택시 요금처럼 가스 요금을 먹습니다.

가스는 실제로는 **이더(ETH)**로 지불합니다.

만약 로봇이 무한히 일하려고 하면? 요금이 부족해져서 자동으로 멈춥니다.

� 그래서 무한루프(끝없는 계산) 같은 사고가 나도, 네트워크 전체가 멈추지 않고 그냥 해당 거래만 실패하는 거예요.

6. 기록 저장(스토리지) = 장부 속 개인 페이지

각 계약 계정은 자기만의 공책을 들고 있다고 생각하면 돼요.

여기에는 숫자, 주소, 데이터 같은 게 줄줄이 적혀 있습니다.

한번 적으면 바꾸는 데 큰 비용(가스)이 들어요.

지우거나 다시 쓰는 것도 에너지(가스)를 써야 하죠.

� 그래서 저장공간은 소중하고, 잘 설계해야 해요.

7. 이벤트(로그) = 영수증

스마트 계약이 어떤 일을 마치면, 그 사실을 “영수증”처럼 찍어서 블록체인에 남깁니다.

예: “사용자 A가 사용자 B에게 토큰 10개를 보냈습니다.”

이건 장부의 밸런스를 바꾸는 건 아니지만, 나중에 검색·조회하기 쉽게 기록으로 남습니다.

8. 한 사이클 예시

예를 들어 내가 이더리움으로 “콜라 자판기”를 만든 상황을 가정해볼게요.

내가 외부 계정(EOA)으로 트랜잭션을 보냄

→ “자판기 계약에게 1ETH를 준다.”

자판기 계약은 규칙을 확인함

→ “1ETH 들어왔으니, 콜라(토큰) 1개를 준다.”

자판기 계약은 창고 계약에 전화 걸음

→ “콜라 하나 꺼내줘.”

창고 계약이 처리 후, 자판기 계약이 나에게 토큰을 돌려줌

모든 과정은 가스를 먹고, 결과는 블록체인 장부에 기록됨

✅ 정리

외부 계정 = 사람의 지갑, 행동의 시작점

스마트 계약 = 버튼 눌리면 일하는 자동 프로그램

트랜잭션 = 편지

메시지 = 계약들 사이의 전화

가스 = 택시 요금 + 타이머 (무한루프 방지 장치)

스토리지 = 각 계약이 가진 개인 공책

로그(이벤트) = 영수증

� 결론: 이더리움은 “사람이 버튼을 누르면, 자동 로봇들이 규칙대로 움직이고, 그 과정은 가스 요금을 내며, 결과는 장부에 기록되는” 시스템이에요.

6. 이더리움의 구조 (완전판)

6.1 월드 스테이트(전체 상태)

네트워크는 매 시점에 “월드 스테이트(world state)”라는 커다란 상태를 갖고 있어.

한 줄 요약: 주소 → 계정 객체의 거대한 맵. 블록이 추가될 때마다 이 상태가 업데이트됨.

world_state = {

0xabc... : Account{ nonce, balance, storage, code },

0xdef... : Account{ ... },

...

}

6.2 두 종류의 계정

A) EOA (Externally Owned Account, 외부 소유 계정)

주체: 사람/지갑. 비밀키로 서명.

필드: nonce(보낸 트랜잭션 수), balance(ETH 잔액).

코드/스토리지: 없음.

역할: 트랜잭션의 유일한 시작점. 서명 없이는 L1에서 아무 일도 안 일어남.

B) 컨트랙트 계정 (Contract Account)

주체: 배포된 스마트 컨트랙트.

필드: nonce(이 계정이 만든 컨트랙트 수), balance, storage(키–값 256비트 슬롯), code(EVM 바이트코드).

특징: 외부에서 트랜잭션을 “보내” 실행시키거나, 다른 컨트랙트의 메시지 호출로 실행됨. 스스로는 서명 못 함.

주소 생성 규칙

CREATE: 주소 = keccak256(rlp(sender_address, sender_nonce))의 하위 20바이트

CREATE2: 주소 = keccak256(0xFF, sender, salt, keccak256(init_code))의 하위 20바이트 (의도적 주소 예측/고정)

6.3 트랜잭션(L1에서 외부 입력이 들어오는 유일한 방법)

트랜잭션은 EOA가 서명해서 네트워크에 던지는 명령서야.

구조(핵심 필드)

nonce: 중복/재생 공격 방지 및 순서 제어

to: 받는 주소(컨트랙트 호출/EOA 송금). 배포 시는 비움

value: 보낼 ETH

data: 함수 호출/파라미터(ABI 인코딩) 또는 배포 시 init code

gasLimit: 이 트랜잭션에 쓸 수 있는 가스 상한

수수료 관련

레거시: gasPrice

EIP-1559: maxFeePerGas, maxPriorityFeePerGas(팁)

v, r, s: 서명

종류

콜 트랜잭션: 기존 주소(to)에 함수 호출(+선택적 ETH 전송)

생성 트랜잭션: to가 없고 data에 init code → 컨트랙트 배포

수명주기(한 방에 이해)

EOA가 서명 → 2) 노드의 mempool 대기 → 3) 검증인이 블록에 포함

실행(EVM) → 5) 성공 시 상태 갱신 & 영수증(receipt) 기록, 실패면 되돌림(revert)

가스는 사용한 만큼 차감(실패해도 대부분 소모)

6.4 메시지 호출 (Contracts ↔ Contracts 내부 상호작용)

트랜잭션이 L1에서 시작되면, 그 안에서 컨트랙트들이 서로 **메시지(message call)**를 주고받아. 이건 블록체인 밖으로는 안 나오는 내부 호출이야(“internal tx”로 표현하기도).

대표적인 EVM 호출 연산

CALL: 다른 컨트랙트의 문맥으로 코드 실행 (가장 일반적)

DELEGATECALL: 호출한 쪽의 저장공간/밸런스를 유지한 채, 다른 컨트랙트의 코드를 빌려 씀(업그레이드/프록시 패턴 핵심)

STATICCALL: 상태 변경 불가(read-only)

CREATE/CREATE2: 컨트랙트 생성

호출 트리와 깊이

하나의 트랜잭션 안에서 **호출 트리(call tree)**가 만들어짐.

최대 깊이 제한(스택/깊이 한도)이 있어 무한 재귀 방지에 도움.

6.5 가스(Gas)와 수수료(왜 무한루프가 안 생기나의 핵심)

가스 = EVM 연산 비용 단위. 각 opcode, 저장공간 접근, 로그, 콜 등에 정해진 가스 비용이 붙음.

실행 절차

트랜잭션 시작 시 가스 탱크(gasLimit)를 들고 들어감.

연산할수록 가스가 줄어듦 → 0이 되면 Out-of-Gas(OOG) 예외 → 해당 호출 범위 내 상태 변경 전부 revert.

남은 가스는 호출자에게 반환(단, 상위 호출 스코프 규칙 따름).

수수료 지불(EIP-1559 이후 기본)

Base Fee: 블록 혼잡도에 따라 자동 조정, **소각(burn)**됨.

Priority Fee(팁): 검증인에게 지급.

실제 지불액 = gasUsed × (baseFee + tip) (상한은 maxFeePerGas)

블록엔 블록 가스 한도가 있어 한 블록에 들어갈 총 연산량이 제한됨.

정리: 무한루프? 가스가 바닥나면 즉시 중단. 그래서 코드를 아무리 실수해도 네트워크 전체가 얼어붙지는 않음(그냥 그 트랜잭션만 돈 날리고 끝).

6.6 저장·코드·이벤트(로그)

저장(Storage)

각 컨트랙트는 256비트 슬롯의 거대한 key–value 맵을 가짐.

SLOAD(읽기)와 SSTORE(쓰기)에 큰 가스 비용.

쓰기(특히 0→비0, 비0→0 전환) 비용/환급 규칙이 있어 최적화 중요.

코드(Code)

배포 시 init code가 실행되고, 반환값이 “런타임 코드”로 영구 기록.

컨트랙트 코드는 원칙적으로 불변(업그레이드는 프록시 패턴으로 해결).

(최근 스펙 변화로) SELFDESTRUCT의 의미가 크게 제한됨—일반적 “코드 삭제로 가스 환급” 같은 트릭은 더 이상 전략이 아님.

이벤트/로그(Receipts)

LOG opcodes로 **토픽(topic)**과 데이터를 내보냄 → 체인에 영수증으로 기록, 인덱싱 쉬움.

상태는 바꾸지 않지만, 클라이언트/인덱서가 훑어보기 좋음(ERC-20 Transfer 이벤트 등).

6.7 콜 플로우 예시 (그림으로 이해)

[EOA] --(Tx: swap(amount=1 ETH))--> [Router Contract]

└─CALL--> [Pair Contract]

└─CALL--> [TokenA Contract] (balance 업데이트)

└─CALL--> [TokenB Contract] (balance 업데이트)

└─EMIT--> SwapExecuted(user, amountIn, amountOut)

중간에 어느 CALL에서 OOG나 revert가 터지면, 그 호출 스코프의 상태변경이 롤백되고 예외가 상위로 전파됨.

6.8 실패/예외/롤백과 가스

revert: 상태 되돌림 + 남은 가스 일부 반환(호출 스코프 기준), 에러 데이터 전파 가능.

assert 실패/invalid/OOG: 더 강한 예외, 남은 가스 거의 소모.

트랜잭션 레벨에서 실패해도 이미 소모한 가스 비용은 돌려받지 못함(네트워크가 연산한 보상).

6.9 보안 포인트(아키텍처와 직결되는 것들)

재진입(Reentrancy): CALL로 외부 컨트랙트에 제어권 넘길 때, 다시 돌아와 상태를 꼬이게 할 수 있음.

대응: Checks-Effects-Interactions 패턴, ReentrancyGuard, pull-payment, 최소 권한 설계.

delegatecall 남용: 호출자 저장공간을 건드리므로 신뢰 못하는 라이브러리에 쓰면 계정 탈탈 털림.

tx.origin 오용: 인증에 쓰지 말 것(피싱 취약).

가스 가정 금지: .transfer 2300 가스 가정에 의존하지 말고 .call{value:..., gas:...} + 보호장치 사용.

6.10 한 번에 훑는 “배포 → 호출” 흐름

배포 트랜잭션(to 없음, data=init code) 전송

EVM이 init code 실행 → 반환된 바이트코드를 해당 주소의 런타임 코드로 저장

사용자(EOA)가 콜 트랜잭션 전송(to=컨트랙트, data=functionSelector+args, value 선택)

가스 한도 안에서 EVM이 실행 → 내부 메시지 호출 발생 → 이벤트 기록

성공 시 상태 업데이트 + 영수증 저장, 실패 시 스코프 롤백(가스는 사용분 소모)

6.11 아주 짧은 메모(실무 팁 느낌)

읽기전용(view/pure) 함수는 온체인 트랜잭션 없이 로컬(EVM 시뮬) 실행 가능 → 가스 0, 상태 변경 없음.

블록 가스 한도가 낮으면 “복잡한 거래”는 여러 번에 나눠야 함(배치/청크 처리).

ABI 인코딩: data의 앞 4바이트는 함수 시그니처 해시(=selector). 나머지는 파라미터.

요약 한 줄(팩폭):

이더리움은 EOA가 트랜잭션으로 불을 지피고, 그 안에서 컨트랙트들이 메시지 호출로 릴레이하며, 모든 단계는 **가스가 일종의 “타이머 겸 토큰”**처럼 연산을 제한한다. 그래서 무한루프·폭주가 구조적으로 불가능하고, 실패해도 네트워크 전체는 안전하게 굴러간다.

7. 무엇을 만들 수 있을까? (애플리케이션 사례)

이더리움으로 가능한 건 엄청 많습니다.

새로운 토큰을 만들어 화폐나 포인트처럼 쓰기

금융 계약(예: 옵션, 선물)

DAO라는 탈중앙화된 조직 운영

분산 저장소, 도메인 네임 서비스 등

오늘날 우리가 보는 디파이(DeFi), NFT, DAO, ENS 같은 서비스들이 사실 이미 백서에서 예견된 셈이죠.

8. 이더리움의 돈, 이더 (토큰 발행 구조)

이더리움 네트워크에서 쓰이는 토큰은 **이더(ETH)**입니다. 이더는 가스 수수료를 내거나, 채굴자·검증인에게 보상으로 주어집니다. 발행 방식은 ICO(초기 크라우드 세일)와 채굴 보상이었고, 설계 철학은 “플랫폼 유지와 보안을 위한 최소한의 인플레이션”이었습니다.

9. 안전장치와 리스크 관리 (보안 고려)

튜링 완전 언어를 쓰면 무한 반복 같은 위험이 생깁니다. 이를 막기 위해 가스 시스템이 들어갔죠. 하지만 여전히 스마트 계약 자체의 버그는 사람 손으로 해결해야 합니다. 그래서 오픈소스 검증과 보안 감사가 중요합니다.

10. 결론 — 세계의 컴퓨터 (Conclusion)

이더리움은 단순한 암호화폐가 아닙니다. 누구나 이 위에 다양한 프로그램을 올리고 실행할 수 있는, 일종의 **“세계용 컴퓨터(World Computer)”**를 지향합니다.

� 한 줄로 정리하면

이더리움 백서는, “비트코인처럼 돈만 쓰는 블록체인이 아니라, 모든 종류의 앱을 구동할 수 있는 범용 블록체인을 만들자”는 선언문입니다.