지난 편에서 한 가지 질문을 남겼다

1편에서는 이더리움이 지금의 구조까지 어떻게 발전했는지 살펴봤습니다.

처음에는 대부분의 일을 Ethereum L1이 직접 처리했습니다.

그러다 PoW에서 PoS로 전환했고, Rollup을 중심으로 Layer 2가 확장됐습니다. Rollup에 필요한 데이터를 효율적으로 제공하기 위해 Blob이 등장했고, 이후 PeerDAS까지 도입됐습니다.

흐름만 놓고 보면 Ethereum L1 → PoW → PoS → Rollup / Layer 2 → Blob → PeerDAS → 더 많은 확장 필요로 이어집니다.
그리고 마지막에 이런 질문이 남았습니다.

이더리움이 지금보다 훨씬 커진 뒤에도 현재와 같은 보안과 탈중앙화를 유지할 수 있을까?

Lean Ethereum은 바로 이 질문을 더 먼 미래까지 가져간 구상입니다.

2025년 7월 Justin Drake가 공개한 Lean Ethereum 비전에서는 Ethereum L1을 이루는 세 핵심 영역을 다시 바라봅니다.

Consensus Layer
Data Layer
Execution Layer

그리고 각각을 다음과 같이 표현했습니다.

Justin Drake의 원문에서는 이를 각각 Beacon Chain 2.0, Blobs 2.0, EVM 2.0이라는 이미지로 설명합니다. 하지만 이것은 실제 제품명이나 확정된 업그레이드 이름이라기보다 각 영역을 얼마나 크게 다시 바라보는지를 표현한 것입니다.

하나씩 살펴보겠습니다.

1. Lean Consensus — 블록을 더 빨리 확정하려면

먼저 Consensus입니다. Consensus는 어렵게 들리지만 하는 일은 비교적 단순합니다. Ethereum에는 수많은 Validator가 있고, 이들은 네트워크에 올라온 블록을 확인해

“이 블록을 Ethereum의 올바른 기록으로 인정하자.”

라는 합의에 참여합니다.

현재 구조를 단순화하면 Transaction → Block 생성 → Validator 검증 → Consensus → Finality로 이어집니다.
여기에서 중요한 단어가 Finality입니다.

Finality는 쉽게 말하면

“이 블록은 이제 확정됐다고 볼 수 있다.”

는 단계입니다.

블록체인에서는 단순히 블록이 만들어지는 것과 그 블록이 되돌리기 어려운 상태로 확정되는 것이 같은 의미가 아닙니다.

2. 왜 Finality를 더 빠르게 만들려고 할까?

일반적인 ETH 전송만 생각하면 몇 초 차이가 별것 아닌 것처럼 보일 수 있습니다.

하지만 Ethereum 위에 더 많은 금융 시스템과 Layer 2가 올라간다고 생각하면 이야기가 달라집니다.

예를 들어 Layer 2가 Ethereum의 상태를 기준으로 다른 작업을 진행해야 한다면 Ethereum L1 → 확정 → L2 Settlement → 다음 금융 활동으로 이어지기 때문에 L1의 확정 속도는 그 위 시스템의 속도에도 영향을 줄 수 있습니다.
L1에서 확신할 수 있는 시점이 빨라질수록 그 위에 연결된 시스템도 더 빠르게 다음 단계로 이동할 여지가 생깁니다.

Ethereum Foundation의 2026년 프로토콜 우선순위에서도 더 빠른 L1 confirmation과 더 짧은 L2 settlement time이 Layer 2 간 사용 경험 개선과 연결된다고 설명합니다.

Lean Consensus는 이 문제를 훨씬 더 장기적인 관점에서 봅니다.

Justin Drake가 처음 제시한 Lean Consensus의 방향에는 초 단위 Finality가 포함돼 있습니다. 그는 이를 기존 Beacon Chain을 한 단계 더 발전시키는 개념으로 소개했고, 이전에 Beam Chain으로 불리던 연구 방향과 연결했습니다.

즉 현재는 Block → Validator → Consensus → Finality의 흐름이라면, Lean Consensus가 지향하는 방향은 Block → Validator → 더 빠른 Consensus → Seconds-level Finality입니다.
하지만 여기서 중요합니다.

Ethereum Mainnet이 이미 수초 Finality를 제공하고 있다는 뜻은 아닙니다.

Lean Consensus가 지향하는 장기 목표입니다.

3. 그런데 빠르게 만드는 것만으로는 부족하다

Ethereum이 중앙 서버라면 방법은 훨씬 단순할 수 있습니다. 성능 좋은 서버를 몇 대 두고 빠르게 결정하면 됩니다. 하지만 Ethereum은 그렇게 작동해서는 안 됩니다. 네트워크가 빨라졌는데 소수의 고성능 서버만 Validator가 될 수 있다면 Ethereum이 중요하게 생각하는 탈중앙화에 영향을 줄 수 있기 때문입니다.

따라서 Lean Consensus가 해결하려는 문제는 단순히 빠른 Consensus가 아닙니다. 빠른 Finality + 강한 Security + Decentralization + 낮은 Validator 부담을 함께 만족해야 합니다.

Justin Drake가 Lean Consensus를 설명하면서 성능뿐 아니라 ultimate security and decentralization을 함께 강조한 이유도 여기에 있습니다.

그리고 여기에서 전혀 다른 문제가 하나 더 등장합니다.

암호기술입니다.

4. Validator의 서명도 언젠가는 바뀌어야 한다

현재 Ethereum Validator는 합의를 위해 BLS Signature를 사용합니다. 이 기술은 여러 Validator의 서명을 효율적으로 집계하는 데 매우 유용합니다. 하지만 Ethereum이 앞으로 수십 년간 존재한다고 가정하면 현재 사용하는 암호기술을 영원히 그대로 사용할 수 있다는 보장은 없습니다. 가장 대표적인 장기 위험이 양자컴퓨터입니다.

Ethereum 공식 문서는 현재 Ethereum이 사용하는 BLS뿐 아니라 계정의 ECDSA, Blob에 사용되는 KZG 등 여러 암호체계를 향후 포스트퀀텀 방식으로 전환해야 할 영역으로 분류하고 있습니다.

여기서 오해하면 안 되는 것이 있습니다.

현재 양자컴퓨터가 Ethereum을 공격할 수 있다는 의미는 아닙니다.

Ethereum.org 역시 현재의 양자컴퓨터는 Ethereum 암호체계를 깨뜨릴 수준과 거리가 있으며, 지금 진행하는 연구는 미래를 준비하기 위한 것이라고 명시합니다. 그래도 암호체계를 하루아침에 바꿀 수는 없기 때문에 지금부터 준비하는 것입니다.

Lean Consensus의 장기 그림에는 현재의 Validator → BLS Signature → Consensus에서 장기적으로 Validator → Post-Quantum Signature → Lean Consensus로 이어지는 변화까지 포함됩니다.

Ethereum Foundation의 Post-Quantum 팀은 실제로 leanXMSS, leanVM, leanSig 등 관련 오픈소스 구현을 개발하고 있으며 여러 클라이언트 팀이 참여하는 포스트퀀텀 interoperability devnet도 운영하고 있습니다.

즉 Post-Quantum은 단순한 아이디어만 존재하는 단계는 아니며 연구와 구현이 실제 진행되고 있습니다. 다만 Mainnet 전환이 완료됐다는 뜻도 아닙니다.

5. Lean Data — L2가 많아지면 데이터는 누가 처리할까?

두 번째는 Lean Data입니다.

1편에서 Blob과 PeerDAS를 설명한 이유가 여기 있습니다.

Ethereum의 현재 확장 전략에서는 많은 거래 실행을 Layer 2가 담당합니다. 흐름은 사용자 → Layer 2 → 수많은 Transaction 처리 → 필요한 Data → Ethereum으로 볼 수 있습니다.
그러면 L2가 성장할수록 Ethereum에 필요한 것은 무엇일까요?

더 많은 Data Availability 용량입니다.

그래서 Dencun에서 Blob이 등장했고, Fusaka에서는 PeerDAS가 도입됐습니다.

PeerDAS가 적용되면서 모든 노드가 모든 Blob 데이터를 다운로드해야 하는 방식에서 벗어나, 데이터 조각을 여러 노드가 나누어 보관하고 샘플링하는 구조로 발전했습니다. Ethereum.org는 이를 통해 개별 노드의 부담을 제한하면서 L2가 사용할 수 있는 데이터 용량을 크게 확장할 수 있다고 설명합니다.

현재 흐름은 Rollup 증가 → Blob 증가 → Node 부담 증가 → PeerDAS → Blob을 나누어 처리 → 더 많은 Data Availability로 이어집니다.
그런데 Lean Ethereum은 여기서 한 단계 더 나아갑니다.

6. Lean Data는 ‘Blob을 더 많이’만 의미하지 않는다

Lean Data를 단순히

Blob 용량을 계속 크게 만든다.

라고 이해하면 핵심을 놓칩니다.

Justin Drake가 제시한 Lean Data의 표현은 “Blobs 2.0”이었습니다.

여기에는 크게 두 가지 방향이 들어갑니다.

첫 번째는 Post-Quantum Blob입니다.

두 번째는 더 세분화된 Blob 크기입니다.

현재 Ethereum Blob의 무결성을 검증하는 데 사용되는 핵심 기술 중 하나가 KZG Commitment입니다.

PeerDAS에서도 노드는 자신이 받은 데이터 조각이 실제 Blob 데이터와 일치하는지 확인하기 위해 KZG Commitment를 활용합니다.

문제는 KZG 역시 장기적인 포스트퀀텀 전환 대상이라는 점입니다.

따라서 현재는 Rollup → Blob → KZG → Data Availability의 구조라면, Lean Data가 바라보는 장기 방향은 Rollup → Lean Data → Post-Quantum Commitment → 더 큰 Data Availability에 가깝습니다.
Lean Ethereum 원안에서는 이를 hash-based DAS commitments 방향으로 표현했습니다.

여기서 중요한 변화가 하나 보입니다.

Consensus와 Data는 서로 전혀 다른 이야기가 아닙니다. 둘 다 결국 Post-Quantum 암호기술이라는 지점에서 연결되기 시작합니다.

7. 세 번째는 가장 익숙한 EVM이다

마지막은 Lean Execution입니다.

Ethereum에서 스마트컨트랙트를 실행하는 핵심 환경이 EVM입니다.

예를 들어 사용자가 DeFi에서 토큰을 교환하면 사용자 → Swap Transaction → Smart Contract → EVM → 계산 실행 → Ethereum State 변경의 흐름으로 처리됩니다.
Ethereum 생태계의 스마트컨트랙트는 이 EVM이라는 실행 환경을 중심으로 발전했습니다.

따라서 Execution Layer를 바꾼다는 것은 간단한 일이 아닙니다.

현재 Ethereum 위에는 수많은 스마트컨트랙트와 개발도구가 존재합니다.

그래서 Lean Execution의 핵심에는 중요한 조건이 붙습니다.

성능은 높이되 기존 EVM 생태계의 호환성과 네트워크 효과는 유지한다.

Justin Drake가 Lean Execution을 소개하면서 EVM compatibility를 명시한 이유입니다.

8. 그런데 현재 EVM은 ZK를 위해 만들어진 것이 아니다

여기서 ZK가 등장합니다.

ZK는 Zero-Knowledge Proof, 즉 영지식 증명입니다. 이 글에서 수학적인 원리까지 알 필요는 없습니다. 핵심만 보면 됩니다.

기존 블록체인에서는 다른 사람이 수행한 계산이 맞는지 확인하기 위해 같은 계산을 다시 실행하는 방식이 일반적입니다.

실행
10 + 20 = 30 → 다른 Node도 다시 실행

10 + 20 = 30 → 맞다

ZK Proof를 활용하면 복잡한 계산 실행 → Proof 생성 → 다른 Node → 전체 계산을 다시 하지 않고 Proof를 검증하는 다른 접근이 가능합니다.

Ethereum Foundation의 zkEVM 팀은 실제로 zkVM을 이용해 Ethereum Mainnet의 확장성을 높이는 작업을 진행하고 있습니다. 현재는 Ethereum 블록에 선택적으로 실행 증명을 붙이는 단계에서 출발해 장기적으로는 필수 증명을 통한 L1 ZK 확장을 목표로 하고 있습니다.

Ethereum Foundation의 2026년 프로토콜 우선순위에도 zkEVM attester client를 prototype 단계에서 production readiness로 발전시키는 작업이 포함돼 있습니다.

9. Lean Execution이 원하는 것은 ‘증명하기 쉬운 실행 구조’

여기서 현재 EVM의 오래된 특성이 문제가 됩니다.

EVM은 처음부터

“나중에 모든 Ethereum 계산을 ZK Proof로 증명하자.”

라는 목표를 가지고 설계된 시스템이 아닙니다.

따라서 기존 EVM의 계산을 ZK 증명으로 만들려면 복잡성과 비용이 생길 수 있습니다.

Lean Execution은 이 지점을 보다 근본적으로 바라봅니다.

Justin Drake는 이를

minimal, SNARK-friendly instruction set

방향으로 설명합니다.

쉽게 표현하면,

계산하기만 쉬운 컴퓨터가 아니라 계산했다는 사실을 증명하기도 쉬운 컴퓨터를 만들자.

에 가깝습니다.

현재는 EVM → Transaction 실행 → 여러 Node가 실행 / 검증하는 구조라면, Lean Execution은 더 단순한 실행 구조 → Transaction 실행 → Proof 생성 → Proof 검증으로 발전시키는 방향입니다.

이 구조가 충분히 발전한다면 블록을 직접 다시 계산하는 비용과 블록이 올바르다는 것을 검증하는 비용을 분리할 수 있는 가능성이 커집니다.

이것이 Ethereum의 L1 확장성과도 연결됩니다.

10. 그러면 Ethereum이 RISC-V로 바뀌는 것인가?

Lean Ethereum을 검색하다 보면 RISC-V라는 이름을 자주 만나게 됩니다.

그래서

Ethereum이 EVM을 버리고 RISC-V로 바꾼다.

라고 이해하기 쉽습니다.

하지만 현재 그렇게 확정된 것은 아닙니다.

Lean Ethereum 최초 제안에서도 RISC-V는 Lean Execution의 최소화된 SNARK-friendly instruction set을 구현할 수 있는 가능한 선택지(possibly RISC-V)로 표현됐습니다.

현재 Ethereum Foundation의 zkVM 표준화 작업에서는 RV64IM을 포함한 RISC-V 기반 아키텍처가 실제 연구되고 있지만 이것과

“Ethereum Mainnet EVM이 RISC-V로 교체된다.”

는 주장은 같은 의미가 아닙니다. Ethereum Foundation의 L1 zkEVM 작업 역시 현재 EVM 호환성과 Ethereum의 기존 환경을 기반으로 진행되고 있습니다.

따라서 지금 단계에서는 현재의 EVM → Ethereum 생태계를 유지하면서, EVM 호환성 유지 + ZK 친화적인 실행 + 더 단순한 구조 → Lean Execution → RISC-V도 가능한 기술 후보로 연구가 이어지고 있다고 이해하는 것이 가장 정확합니다.

RISC-V는 중요한 연구 대상이지만 결정된 최종 목적지는 아닙니다.

11. 세 가지를 다시 연결하면 하나의 그림이 된다

지금까지 설명한 것을 한꺼번에 놓아보겠습니다.

Lean Consensus

Validator → Consensus → 더 빠른 Finality → Post-Quantum Signature

Lean Data

Rollup → Blob → 더 큰 Data Availability → Post-Quantum Commitment

Lean Execution

Transaction → Execution → ZK Proof → 효율적인 Verification
처음에는 서로 다른 기술처럼 보였습니다.

하지만 세 개를 합치면 Lean Ethereum이 원하는 전체 그림이 보입니다.

즉 Lean Ethereum은 TPS 하나를 높이는 프로젝트가 아닙니다.

합의하는 방법, 데이터를 제공하는 방법, 계산을 검증하는 방법을 함께 바꾸려는 장기적인 프로토콜 방향입니다.

12. 그런데 왜 세 영역 모두에서 Hash가 등장할까?

Lean Ethereum에서 흥미로운 부분이 하나 있습니다.

Consensus, Data, Execution은 서로 하는 일이 다릅니다.

그런데 Justin Drake의 Lean Ethereum 비전에서는 세 영역 모두에서 Hash-based cryptography가 중요한 기반으로 등장합니다.

원안의 방향을 단순화하면 Consensus: BLS → Hash-based Signature, Data: KZG → Hash-based Commitment, Execution: EVM 재실행 → Hash-based zkVM으로 정리할 수 있습니다.
왜 Hash일까요?

가장 중요한 이유 중 하나는 Post-Quantum입니다.

현재 Ethereum이 사용하는 ECDSA, BLS, KZG 등은 장기적으로 양자컴퓨터에 대비한 전환이 필요한 암호체계입니다. Ethereum Foundation은 2026년 별도의 Post-Quantum Security 팀을 구성하고 관련 프로토콜·서명·실행환경 연구를 진행하고 있습니다.

그러면서 Lean Ethereum의 세 구조가 다시 하나로 모입니다.

        Lean Consensus
               │
               │
Lean Data ── Hash ── Lean Execution
               │
               │
        Post-Quantum

이 부분이 Lean Ethereum을 이해하는 데 상당히 중요합니다.

성능 개선과 양자내성 전환을 서로 별개의 작업으로 보지 않고, 프로토콜을 다시 단순화할 기회로 함께 바라보고 있기 때문입니다.

13. 그렇다면 Lean Ethereum은 지금 만들어지고 있는가?

여기에서는 선을 명확하게 그을 필요가 있습니다.

그렇기도 하고, 아니기도 합니다.

Lean Ethereum을 구성하는 모든 것이 하나의 완성된 사양으로 정해져 개발되고 있는 것은 아닙니다.

반면 관련 기술 상당수는 실제 연구와 개발이 진행되고 있습니다.

예를 들어 2026년 현재 Ethereum Foundation은 zkEVM을 통한 L1 검증, Post-Quantum Signature, leanVM, leanXMSS, statelessness 등 여러 작업을 실제로 진행하고 있습니다. 포스트퀀텀 interoperability devnet에는 10개가 넘는 클라이언트 팀도 참여하고 있습니다.

따라서 현재 상태를 다음처럼 구분해서 보는 것이 좋습니다.

현재 Ethereum Mainnet
        ├─ 이미 적용된 기술
        ├─ 다음 Fork 후보
        ├─ Prototype / Devnet
        ├─ Research
        └─ Long-term Vision
                    ↓
              Lean Ethereum

Lean Ethereum이라는 이름 아래 언급됐다고 해서 모든 기술이 Ethereum Mainnet에 적용될 것이 확정된 것은 아닙니다.

Ethereum의 로드맵은 연구 결과와 EIP, 개발자 논의, 테스트를 거치면서 계속 바뀝니다.

14. Lean Ethereum을 ‘더 빠른 이더리움’이라고만 보면 안 되는 이유

여기까지 보면 Lean Ethereum의 방향을 조금 다르게 볼 수 있습니다.

보통 블록체인의 성능 경쟁은 TPS ↑ · Block Time ↓ · Fee ↓ 같은 숫자로 표현됩니다.

물론 Lean Ethereum도 높은 성능을 지향합니다.

하지만 목표는 그보다 복잡합니다.

                  Performance
                       ↑
                       │
Security  ←── Lean Ethereum ──→ Simplicity
                       │
                       ↓
                Decentralization
                       +
                 Post-Quantum

성능을 높였는데 일반 사용자가 Node를 운영하기 어려워진다면 문제가 됩니다.

Finality를 빠르게 만들었는데 Validator 구조가 중앙화된다면 그것도 문제가 됩니다.

ZK Proof를 사용했는데 프로토콜이 지나치게 복잡해진다면 또 다른 위험이 생깁니다.

그래서 Lean Ethereum 원안에서는 성능과 함께 continuity, hardness, simplicity를 중요한 조건으로 제시합니다.

Lean Ethereum의 진짜 질문은

“Ethereum을 얼마나 빠르게 만들 수 있는가?”

가 아니라,

“Ethereum의 기본적인 성격을 유지하면서 어디까지 확장할 수 있는가?”

에 더 가깝습니다.

지금까지의 변화를 한 번에 정리해보자

1편과 2편을 연결하면 Ethereum이 가려는 방향이 조금씩 보이기 시작합니다.

이제 Lean Ethereum이 무엇을 하려는지는 어느 정도 보입니다.

하지만 아직 중요한 질문 하나가 남았습니다.

이런 기술들이 실제로 적용되면 우리가 사용하는 Ethereum은 무엇이 달라질까?

그리고 더 현실적인 질문도 있습니다.

Lean Ethereum은 지금 어디까지 진행됐고, 언제 무엇을 확인해야 할까?

이것이 마지막 3편의 주제입니다.

1편이 “왜 Lean Ethereum인가”였다면,
2편은 “무엇을 바꾸려 하는가”,
3편은 “그래서 언제, 무엇이 달라지는가”입니다.