Lighter의 Vlad 비탈릭, 조셉루빈과 대담

Lighter CEO인 Vlad가 비탈릭 부테린과 Consensys의 CEO인 조셉루빈과 대담을 진행할 예정입니다

원문공지
- 일시 : 5월 19일 12시
- 참여 : Vlad, 비탈릭 부테린, 조셉루빈
- 장소 : Lighter X 스페이스

대담의 주요 논제는 고성능 애플리케이션, 이더리움에서 ZK 롤업, Composability, DeFi의 미래 등으로 구성되어 있네요

이더리움 진영의 전폭적인 지지를 받게된다면 Lighter도 큰 힘을 얻을거 같습니다. 이제 릿쪽이 가격만 올라주면 안되겠니

[EIP-7885, 양자 전환을 위한 한 걸음]

이더리움의 양자 저항 로드맵에 대한 논의가 지속적으로 이뤄지고 있는 가운데, 흥미로운 EIP인 EIP-7885에 대해 소개드립니다.

** EIP-7885의 공동 저자 중 한 분이 한국인 이윤형님이며, 본 글은 이윤형님이 작성해주신 내용을 바탕으로 정리한 것입니다.

[PQC 전환의 비용]

이더리움에 양자내성 서명 전환은 단순히 "어떤 서명을 쓸 것인가"가 아니라 "EVM이 어떤 방식으로 그 비용을 낮출 것인가"의 문제입니다.

이 서명을 온체인에서 검증할 수 있는지, 그리고 그 비용을 감당할 수 있는지가 핵심입니다. 기존 ECDSA 서명의 크기는 65B 수준이지만, Falcon-512는 약 666B, ML-DSA-44는 약 2,420B입니다. 이렇게 큰 서명 크기는 곧 높은 콜데이터 비용으로 이어집니다. 또한, 서명 검증에서의 복잡한 연산 역시 실행 비용을 크게 늘린다는 문제가 있죠.

[비용에 대한 네 가지 접근법과 NTT 프리컴파일]

이더리움에서 PQC 서명의 비용 문제를 다루는 방식은 대략 네 가지로 나눌 수 있습니다.

1. 알고리즘 검증 로직 전체를 프리컴파일으로 넣는 방식
2. 여러 PQC가 공유하는 공통 연산만 프리컴파일으로 넣는 방식
3. 계정 추상화 기반 키 로테이션을 활용하는 방식
4. 공개키를 숨기고 ZK 증명으로 검증하는 방식

EIP-7885은 여기서 2번 접근법입니다. 핵심은 "알고리즘별 검증 로직을 EVM 안에 넣는 것"이 아니라, 여러 격자 기반 PQC 알고리즘이 공유하는 저수준 연산을 EVM 프리컴파일로 노출하는 것입니다.

구체적으로, EIP-7885는 NTT(Number Theoretic Transform)라는 연산을 프리컴파일로 제공합니다. 이는 Falcon, ML-DSA, ML-KEM 등에서 반복적으로 필요한 다항식 곱셈 연산이기에, 어떤 서명 알고리즘을 쓰던 비용을 줄일 수 있고, 어떤 알고리즘이 채택되던 효율을 높일 수 있습니다.

[결과와 의미]

OP Stack 환경에서 이를 구현한 결과는 다음과 같습니다.

• Falcon-512 NTT: 1.8M → 500~790 gas
• Falcon-512 전체 검증 로직: 1.8M → 479k gas (73.4% 절감)
• ML-DSA/Dilithium 계열: 7.9M → 5.7M gas로 절감

EIP-7885의 핵심은 특정 알고리즘 하나를 고정하기보다, 여러 PQC 알고리즘들이 공통으로 쓰는 연산 병목을 낮춰, 이더리움이 특정 서명 방식에 묶이지 않고 양자내성 전환을 준비할 수 있게 하는 것입니다. 쉽게 말하면 단계적이고 범용적인 PQC 전환을 가능하게 한다고 볼 수도 있겠네요.

양자 저항 관련된 가장 많은 연구가 이뤄지고 있는 이더리움에서, 핵심이 될 만한 EIP에 한국인 분이 기여하셨다는 사실도 매우 자랑스럽습니다!

출처

[Zero-Knowledge Proofs, from a Compiler Perspective]

보통 ZK를 설명할 때는 prover, verifier, statement, witness 같은 암호학적 구조에서 시작합니다. 이 설명은 당연히 중요합니다. ZK proof가 왜 설득력 있는지, private witness를 공개하지 않고도 어떤 claim을 믿게 만들 수 있는지 설명해주기 때문입니다.

하지만 개발자의 입장에서 보면 이 설명만으로는 중간이 비어 있습니다.

우리는 프로그램을 작성합니다. verifier는 proof를 검증합니다. 그 사이에서는 무슨 일이 일어날까요?

source code, circuit DSL, guest program, assertion 같은 개발자의 의도는 그대로 proof가 되지 않습니다. 먼저 relation, constraint, circuit, AIR, trace, IR, VM semantics 같은 proof-friendly representation으로 바뀌어야 합니다. 바로 이 변환 과정에서 compiler perspective가 중요해집니다.

[Practical ZK system은 compiler system이기도 하다]

Cryptography는 proof가 왜 설득력 있는지를 설명합니다. Compilation은 그 proof가 무엇에 대한 것인지를 정의합니다.

즉, proof system은 어떤 relation이 만족되었다고 말해줄 수 있습니다. 하지만 그 relation이 정말 개발자가 증명하려던 claim을 표현하는지는 compiler side의 문제입니다.

ZK proof는 source code에서 직접 만들어지는 것이 아닙니다.

proof는 relation과 witness 또는 trace로부터 만들어집니다. source code는 그 relation으로 compile되어야 하고, private input은 그 relation을 만족하는 witness나 execution trace가 되어야 합니다.

그래서 ZK pipeline은 크게 세 부분으로 볼 수 있습니다.

frontend/compiler layer는 “무엇을 증명할 것인가?”를 정의합니다. source program이나 circuit DSL을 constraint, circuit, AIR, trace relation, IR, VM semantics 같은 representation으로 낮춥니다.

witness/execution layer는 “어떤 값들이 이 relation을 만족한다고 주장하는가?”를 만듭니다. circuit system에서는 witness assignment가 되고, zkVM에서는 guest program execution trace가 됩니다.

proving backend는 “그 relation이 만족되었다는 사실을 어떻게 증명할 것인가?”를 담당합니다. 여기서 SNARK, STARK, folding, recursion, lookup, polynomial commitment 같은 proof-system-side 기술이 붙습니다.

[Verifier는 source code를 확인하지 않는다]

예를 들어 source code에 이런 assertion이 있다고 해도,

`assert!(age >= 18);`

verifier가 이 코드를 읽고 “age가 18 이상이구나”라고 판단하는 것은 아닙니다. verifier가 보는 것은 compiled relation, public input, verification key 또는 program identity, 그리고 proof입니다.

이 지점에서 일반적인 프로그램 실행과 ZK의 trust model이 갈라집니다. 일반 software에서는 CPU나 VM이 정해진 semantics에 따라 instruction을 실행했고, 그 결과가 프로그램의 결과라고 받아들이는 구조입니다.

하지만 ZK verifier는 prover의 실행을 직접 신뢰하지 않습니다. prover가 “이 프로그램을 실행했다”고 말하는 것만으로는 충분하지 않습니다. 실행의 의미가 compiled relation이나 trace constraint 같은 obligation으로 바뀌어야 하고, verifier는 그 obligation이 만족되었다는 proof를 확인합니다.

따라서 중요한 질문은 이것입니다.

source-level claim이 lowering 이후에도 같은 의미로 남아 있는가? comparison은 올바르게 range check되었는가? boolean result는 제대로 constrain되었는가? public input은 private witness와 제대로 binding되었는가? zkVM이라면 proof가 올바른 program image와 VM semantics에 묶여 있는가?

이 부분에서 compiler bug는 단순한 compiler bug가 아닐 수 있습니다. ZK에서는 어느 layer에서 생긴 버그든 verifier-trust bug가 될 수 있습니다. 결과는 단순히 실패하는 proof가 아니라, verifier가 잘못된 claim을 믿게 만드는 valid proof일 수 있습니다.

[Cryptography는 보장하고, compilation은 정의한다]

ZK ecosystem은 단순히 “좋은 proof system을 고르는 문제”가 아닙니다. source language, IR, arithmetization, witness generation, proving backend, verifier interface가 모두 연결된 compiler stack에 가깝습니다.

Circom, Noir, Cairo, RISC Zero, SP1, LLZK 같은 도구들도 결국 이 compiler boundary를 어디에 그리는지, 무엇을 frontend가 책임지고 무엇을 backend가 책임지는지를 다르게 선택한 결과로 볼 수 있습니다.

ZK를 암호학으로 이해하는 것은 반드시 필요합니다. 하지만 practical ZK system을 만들고 사용하려면, 암호학만으로는 부족합니다.

개발자가 작성한 프로그램은 그대로 proof가 되지 않습니다. 그 프로그램은 어떤 relation으로 변환되고, 그 relation은 witness나 trace와 만나고, backend는 그 relation이 만족되었다는 사실을 증명합니다.

compiler perspective에서 보면 많은 질문이 더 선명해집니다.

무엇을 증명하는가? 그 claim은 어떤 representation으로 바뀌었는가? 그 변환은 meaning-preserving한가? verifier가 믿는 relation은 개발자가 의도한 relation과 같은가?

이 질문들이 practical ZK system의 핵심이라고 생각합니다.

Full version: [link]

[ZK Summit 14 Review]

ZK Summit 14는 2026년 5월 7일 로마에서 열린 ZK 행사입니다. ZK Summit은 2018년부터 이어져 온 zero-knowledge 생태계의 주요 정기 행사 중 하나이고, academic cryptography와 실제 시스템 적용 사이의 접점에 놓여 있습니다. 그래서 ZK 생태계에서 실제로 무엇이 만들어지고 있고, 어떤 문제가 중요하게 논의되고 있는지 보기 좋은 자리입니다.

이번 ZK14는 Main stage와 side stage를 합쳐 총 24개 발표가 있었고, Ethereum Foundation, Succinct, Zcash/Project Tachyon, Aztec Labs, Nethermind, Miden, Nokia Bell Labs, Powdr Labs 같은 팀과 여러 대학/연구기관 발표가 섞여 있었습니다.

[Overall Take]

ZK14에서 가장 분명했던 흐름은, 논의의 초점이 proof system 자체의 가능성이나 성능에서 실제 시스템 안에서 보장이 어떻게 정의되고 유지되는가로 옮겨가고 있었다는 점이었습니다. Privacy, soundness, verifiability는 더 이상 proof system 레벨에서만 이야기할 수 있는 추상적 속성으로 머물지 않습니다.

실제 사용자, 데이터 흐름, 계정 모델, 운영 환경, 구현 실수 속에서도 그 속성이 유지되는지가 중요해졌습니다. 그중 가장 뚜렷한 변화는 security and correctness의 비중이 크게 올라왔다는 점이고, privacy 역시 단일 application category가 아니라 systems design 문제로 다뤄졌다는 점이었습니다.

[Themes and Talks]

24개 발표를 넓게 나누면 다음과 같습니다.

1. Privacy-preserving systems (7)
Zcash Tachyon · zkID · Merces · client-side validation · eDAS · ZK-AntiCheat · confidential/verifiable telemetry

2. Security / correctness (5)
Poseidon · EF zkEVM Security Sprint · Origin Tags · ZK engineering security · Proof of Seed

3. Proving infrastructure / zkVMs (5)
lambda-vm · Nondeterministic Autoprecompiles · Sumcheck trade-offs · Miden ACE · non-native arithmetic

4. Primitives (5)
ZOOK · VEIL · verifiable FHE · witness encryption · resource-sharing permutations

5. Broader verifiable applications (2)
qedb · Jolt Atlas

[Takeaways]

1. Security and correctness

이번 프로그램에서 가장 뚜렷한 변화는 security/correctness의 비중이었습니다. "Proof가 생성되고 검증된다"는 사실만으로는 충분하지 않습니다. ZK 시스템에서 proof는 실제로 인코딩된 relation에 대해서만 의미가 있고, hash assumption, Fiat-Shamir transcript binding, circuit constraint, VM semantics, witness generation, implementation practice 중 하나라도 어긋나면 시스템이 의도한 statement를 증명하지 않을 수 있습니다.

2. Privacy

Privacy 관련 발표는 많았지만, 단순히 "ZK로 데이터를 숨긴다"는 이야기는 아니었습니다. 반복된 질문은 누가 witness를 보는가, 무엇이 public output이 되는가, 누가 proof 생성에 참여하는가, 검증자는 무엇을 알 권리가 있는가에 가까웠습니다. 실제 시스템 요구가 들어오면 privacy는 암호학적 속성 하나가 아니라 disclosure boundary 설계 문제가 됩니다.

3. Primitives and engineering

Primitive와 engineering 발표도 단순한 속도 경쟁보다는 보장 유지에 가까웠습니다. ZOOK와 VEIL은 효율적인 construction 안에서 zero-knowledge 성질을 유지하는 문제를 다뤘고, Verifiable FHE는 confidentiality와 outsourced computation correctness를 함께 봤습니다. 중요한 지표는 prover time만이 아니라, 최적화와 모듈화 이후에도 어떤 보장이 남는가였습니다.

4. zkVMs and infrastructure

zkVM과 proving infrastructure는 범용성에서 specialization으로 이동하고 있었습니다. 실제 시스템에서는 특정 연산, memory usage, non-native arithmetic, VM instruction, recursion, lookup, precompile 같은 병목이 드러납니다. Application이 어떤 보장을 원하고 어떤 계산을 많이 쓰는지가 infra의 설계 압력으로 돌아오고 있습니다.

5. Verifiability beyond crypto-native systems

qedb와 Jolt Atlas는 각각 verifiable database와 verifiable ML inference 쪽을 보여줬습니다. Telemetry나 validation-oriented talk도 비슷한 방향을 가리켰습니다. 여기서 중요한 보장은 semantic truth가 아니라 computational integrity입니다. 데이터가 현실에서 참인지, 모델 출력이 좋은지까지 증명하지는 않지만, 외부 계산을 operator의 주장만 믿지 않고 검증 가능한 대상으로 바꿉니다.

[Conclusion]

ZK14가 보여준 것은 ZK가 하나의 큰 방향으로 수렴하고 있다는 그림이 아니었습니다. 오히려 ZK가 payment, identity, zkVM, database, ML, telemetry처럼 서로 다른 시스템 안으로 들어가면서, 각 맥락마다 다른 보장을 요구받고 있다는 점이었습니다.

다음 과제는 proof를 더 빠르게 만드는 데서 끝나지 않습니다. 무엇을 숨기고, 무엇을 검증하고, 어떤 실패를 막아야 하는지 먼저 명확히 정해야 합니다. 그리고 그 보장이 circuit, protocol, VM, application, operation을 지나 실제 시스템 안에서도 흐트러지지 않게 유지되어야 합니다.

Full review: [link]

[ETH레터] 이더리움 완결성 100배 단축 제안과 재단 새 핵심 기여자 발표
https://www.digitalasset.works/news/articleView.html?idxno=41126

[AI 시대의 사이버보안, 형식 검증이 답이 될 수 있을까]

지난 몇 달, 이더리움 리서처들 사이에서 새로운 프로그래밍 패러다임이 빠르게 자리잡고 있습니다. 매우 저수준 언어냐 Lean으로 직접 코드를 작성하고, 그 정확성을 기계가 자동 검증 가능한 수학적 증명으로 보장하는 방식이죠. 비탈릭이 오늘 ‘AI와 결합된 형식 검증(formal verification)이 사이버보안의 미래를 어떻게 바꿀 수 있는지’에 대한 글을 통해 이에 대해 알아보겠습니다.

[형식 검증이란 무엇인가]

형식 검증은 수학적 정리를 컴퓨터가 자동 검증할 수 있는 형태로 증명하는 것입니다. 이는 60년 가까이 존재해왔지만, 작성이 까다로워 보안이 매우 중요한 영역에만 적용되어 왔었죠. 그런데 AI의 빠른 발전 덕분에, 그동안 불가능했던 많은 것들이 가능해지고 있습니다.

컴퓨터 프로그램 자체도 수학적 객체이기 때문에, 프로그램이 특정 방식으로 동작한다는 사실 역시 수학 정리로 증명할 수 있습니다. 실제로 Signal, TLS 같은 암호 프로토콜의 실제 구현 보안을 엔드 투 엔드로 증명하려는 프로젝트들이 진행 중이기도 합니다. 이렇게 수학적으로 코드가 형식 검증되면, 사용자나 개발자 입장에서는 코드 전체를 검토할 필요 없이 그 코드에 대해 증명된 명제만 확인하면 되니 신뢰 비용이 크게 줄어들죠.

[AI 시대의 위기와 기회]

최근 다수의 디파이 해킹 사례들이 터지며, 스마트 컨트랙트와 영지식 증명에 AI 기반 버그 탐색까지 더해지면 공격자 우위가 압도적이 될 수 있다는 비관론이 증가하고 있습니다. 일부 사람들은 오픈소스 자체를 포기해야 한다고까지 주장하죠. 그러나 비탈릭은 이를 과도기적 도전이라고 이야기하며, 형식 검증을 사용하면 이를 해결할 수 있다고 주장합니다.

[이더리움 적용 사례]

• STARK: 소프트웨어 자체는 매우 복잡하지만, 보장하려는 보안 속성은 한 문장으로 정리됩니다. "어떤 증명이 프로그램 P, 입력 x, 출력 y에 대한 것이라면, 해시 알고리즘이 깨졌거나 실제로 P(x)=y이거나 둘 중 하나"라는 진술이죠. 목표가 이렇게 단순하기 때문에 형식 검증이 잘 들어맞습니다. 완전히 형식 검증된 STARK 구현을 만드는 Arklib 프로젝트가 진행 중입니다.
• EVM: evm-asm은 EVM 전체를 RISC-V 어셈블리로 직접 작성하고, Lean으로 작성된 구현과의 동치성을 증명합니다.
• 합의: 비잔틴 장애 허용 합의의 속성을 형식적으로 증명하려는 노력이 이어지고 있습니다.

[보안과 효율을 동시에 잡는 것이 가능할까]

형식 검증과 AI의 결합은 "효율 전용 구현"과 "가독성 전용 구현"을 분리한 뒤, 둘의 동치성을 수학적으로 증명하는 길을 엽니다. AI가 어셈블리를 작성하고, 그것이 사람 친화적 고수준 구현과 일치한다는 사실을 증명하면 끝이죠. 이더리움의 전 형식 검증 엔지니어 Yoichi Hirai는 이를 "소프트웨어 개발의 최종 형태"라고 부르기도 합니다.

[한계: 만병통치약은 아니다]

다만 형식 검증은 우리가 일상적으로 이해하는 "정확함"을 증명하지 않습니다. 정확성과 보안은 결국 코드와 인간 의도 사이의 비교인데, 인간의 의도 자체에 오류가 있을 수 있기 때문이죠. 코드의 일부만 검증되어 비검증 영역에서 치명적 버그가 터지거나, 명세 자체가 잘못되거나, 사이드 채널처럼 모델 밖 공격이 들어오는 실제 사례들도 존재합니다.

[시사점]

비탈릭이 그리는 미래는 소프트웨어가 "안전한 핵(secure core)"과 "위험한 가장자리(insecure edge)"로 분화하는 모습입니다. 가장자리는 샌드박스에서 최소 권한으로 운영되고, 핵은 모든 것을 관할하는 형태입니다. 핵에는 AI의 추가 연산력 전부를 보안 강화에 투입하고, 그 크기는 작게 유지합니다. 운영체제 커널, 이더리움, IoT 등이 안전한 핵 후보입니다.

즉 AI와 형식 검증 두 기술은 상보적이며, 적어도 안전한 핵 안에서는 "버그는 불가피하다"는 옛 격언이 거짓이 되는 세계가 가능할 것이라는 게 비탈릭의 결론입니다.

출처

L2BEAT가 라이터의 zk exit hatch에 검증 딱지를 붙여줬다고 하네요.

https://x.com/l2beat/status/2056731750378684898?s=20

[이더리움의 본격적인 ZK화, EIP-8025]

지난 5월 14일, 이더리움 All Core Devs 콜에서 흥미로운 EIP가 제안되었습니다. EF의 zkEVM 팀이 글램스터담 다음 하드포크인 헤고타 포크에 EIP-8025(Optional Execution Proofs)를 포함시키자고 공식 제안한 거죠. 이게 통과되면 이더리움 로드맵에서 가장 중요한 아키텍처 전환 중 하나인, ZK화가 시작됩니다.

[배경 지식: 지금 블록 검증은 어떻게 이루어지나]

현재 이더리움의 모든 풀노드 및 밸리데이터는 블록 안의 모든 트랜잭션을 직접 재실행해서 검증합니다. 이 비용은 블록이 소비한 가스에 정비례하고, 검증하는 노드는 이에 필요한 상태 전체를 들고 있어야 하죠. 이 구조 때문에 가스 한도를 올리려면 노드 운영 비용도 함께 올라가, 탈중앙화 및 보안을 희생하는 딜레마가 생깁니다.

zkEVM 증명은 여기서 완전히 다른 길을 제시합니다. 트랜잭션을 다시 실행하는 대신, 노드는 작은 증명 하나를 받아서 검증만 하면 됩니다. 검증은 stateless하고(상태가 필요 없음), 비용이 블록 크기에 거의 무관합니다. 6,000만 가스 블록이든 6억 가스 블록이든 검증 시간이 비슷하죠. 이 성질 덕분에 가스 한도를 크게 올려도 밸리데이터 노드 운영 기준은 그대로 유지할 수 있습니다.

이러한 방식을 부분적으로 도입하자고 제안하는 EIP가 바로 EIP-8025입니다.

[EIP-8025의 핵심: ‘완전 옵트인’]
EIP-8025의 가장 중요한 특징은 완전 옵트인 방식이라는 점입니다. 참여하지 않는 밸리데이터에겐 아무 변화도 없죠. 옵트인하는 노드는 두 가지 역할을 맡을 수 있습니다.

• Prover (증명 생성 모드): 블록마다 zkEVM 증명을 만들어 gossip 토픽으로 전파
• zkAttester (증명 검증 모드): gossip으로 받은 증명을 검증해서 투표

여기서 핵심은 이 단계에서 ZK 증명이 합의에 영향을 주지 않는다는 것입니다. 밸리데이터가 EIP-8025에 옵트인해 ZK 증명 옵션을 켜더라도, 증명 검증만 해서 블록에 투표하는 것이 아니라, 결국 재실행을 통해 투표에 참여해야 한다는 것이죠.

이러한 선택은 무의미해 보일 수도 있겠지만, 이더리움 L1의 ZK화는 실행, 합의, 암호학, 네트워킹, 경제학까지 프로토콜 전반을 건드리는 거대한 변경입니다. 따라서 이를 한 포크에 바로 수행할 수 없고, 메인넷에서 실제 데이터를 모으면서 개선점들을 찾아나가야 합니다. 옵셔널 단계는 이를 위한 가장 합리적인 방법이며, 일종의 단계적 롤아웃 방식으로도 볼 수 있습니다.

또 하나 중요한 건, EIP를 지금 제안함으로써 이 작업을 프로토콜 업그레이드 프로세스 안에 박아 넣는다는 점입니다. 클라이언트 팀, zkVM 팀, 툴링 메인테이너들이 이제 명확한 타깃을 두고 리소스를 배분할 수 있게 되며, 앞으로의 업그레이드도 이 피처를 고려하여 진행되게 됩니다.

[왜 지금인가]
ZK 기술이 충분히 성숙했기 때문입니다. L2 롤업들은 수년째 프로덕션에서 ZK 증명 스택을 돌리고 있고, 증명 시스템 성능도 크게 개선되어 실시간 증명이 안정적으로 가능한 수준까지 오게 되었습니다. 합의/실행 클라이언트 단 스펙 역시 거의 안정화됐고, 라이트히우스와 프리즘 역시 모두 자체 구현을 갖고 있으며, 이 둘 사이 데브넷도 운영되고 있습니다.

[같이 따라오는 제안들]

EIP-8025와 함께 다음 두 개의 EL 측 EIP가 논의되고 있습니다.

• EIP-7709: BLOCKHASH 명령어를 EIP-2935 히스토리 컨트랙트에서 읽도록 변경. EVM에서 마지막 남은 ‘stateful한’ 옵코드를 정리
• EIP-8200 (EVMification): 사용량 적은 일부 프리컴파일을 EVM 바이트코드로 대체. 평균 증명 시간이 빨라도 공격자가 분 단위 증명이 걸리는 블록을 만들 수 있으면 의미가 없으니, 최악의 경우 증명 시간을 단축하려는 목적

[시사점]
EIP-8025가 헤고타에 들어간다면, 이는 이더리움이 “재실행하는 체인”에서 “증명을 검증하는 체인”으로 넘어가는 첫 공식 단계가 됩니다. 물론 당장은 옵셔널 단계이니 체감되는 변화는 크지 않겠지만, 메인넷에서 실시간 증명 생성과 검증 데이터가 쌓이기 시작하면, 향후 하드포크에서 ZK 증명을 내장할지 결정할 근거가 마련됩니다. 그때가 되면 노드 운영 비용은 극적으로 낮아질 수 있죠.

이는 결국, L1 자체를 롤업으로 만드는 작업입니다. ZK 롤업이 오프체인에서 실행 및 증명 생성을 하고 이더리움 밸리데이터들에게 상태 변경 결과 및 증명과만 제출하듯, 이더리움 L1도 동일한 경로를 통해 롤업과 같은 높은 확장성을 갖추게 되는 것입니다.

이더리움 Kohaku 출시가 다가오는 중

> Ambire 같은 월렛들이 통합 테스트 중

> 추후 더 많은 월렛들이 Kohaku 채택 시 기본 프라이버시 엔진인 레일건 채택 증가

> 레일건은 현재 총 누적 거래량 50억 달러 돌파. 최근 한달 기준 수익은 $359K

> 레일건은 코인을 프라이버시 시스템 상에서 거래하게 해주는 Shield 액션과, 프라이버시 상의 코인을 다시 기존의 노말 코인으로 바꿔주는 unShield 액션에서 0.25%의 수수료가 부과 됨. Kohaku를 통해 월렛들이 레일건 채택 시 Shield/unShield tx 급증이 수익 급증으로 이어질 수 있음

> 레일건은 ZEC, DASH 등에 비해 상당히 저평가되어 있으며 이더리움 상에서 디파이들과 프라이버시하게 상호작용이 가능한 추가적인 특징이 존재

전에 kohaku대해서 분석한 report를 써봤습니다. 혹시나 kohaku대해서 굼굼해하시는 분들에게 추천드립니다~ https://www.wprc.club/papers/kohaku-privacy-framework

OKX, 거래소 OS 발표

OKX가 X Layer 위에 거래소 OS(Exchange OS)를 공개했습니다.

개발자나 기관은 거래소 OS를 통해 X Layer에 현물 거래소, 선물 거래소, 예측시장을 직접 배포할 수 있습니다.

매칭, 마진, 청산, 정산, 리스크 관리 같은 건 프로토콜 레이어로 이전하고, 운영자는 본인의 운영 모델에 따라 설정 및 UX만 올리는 구조입니다.

성능은 OKX와 동일한 밀리초 단위 매칭과 최대 30만 TPS입니다.

거래소 OS는 XIP로 올라올 예정이며, 첫 거래소는 OKX가 직접 예측시장 2026 월드컵 아웃컴(2026 World Cup Outcomes)을 출시할 예정입니다.

발표 파트너로는 xStocks, 센트리퓨지, GSR, 앰버 그룹, 플로우데스크, 메이플 파이낸스, 체인링크, 글래스노드, 난센, 피쓰, 체이널리시스, 알리바바 클라우드, 옵티미즘 등이 참여합니다.

X Layer은 폴리곤 CDK로 만들어졌는데, 폴리곤 CDK가 OP 스택을 쓰다보니 X Layer도 OP 스택 체인입니다. 발표 파트너에 폴리곤이 없고 옵티미즘이 있는 게 신기하네요.

링크

[이더리움의 검열 불가능한 프라이버시를 위한 두 개의 받침대, EIP-8250과 EIP-8272]

지난 4월 16일과 5월 15일, 네이티브 계정 추상화 제안인 EIP-8141의 후속 제안 두 개인, EIP-8250(Keyed Nonces)과 EIP-8272(Recent Roots)가 잇따라 공개됐습니다. 둘 다 이더리움 위의 프라이버시 프로토콜이 EIP-8141 위에서 실제로 굴러가도록 지원하는 EIP입니다.

만약 헤고타에서 위 EIP들이 모두 적용된다면, 이더리움 위 중개자 없는 프라이버시 프로토콜을 구현할 수 있을 것으로 보입니다.

[EIP-8141의 목적 중 하나: 프라이버시]

EIP-8141은 헤고타 포크를 목표로 하는 네이티브 계정 추상화 제안입니다. 한 트랜잭션을 여러 '프레임'으로 쪼개서, 각 프레임이 검증/결제/실행을 따로 맡게 하는 구조죠.

이 제안은 언뜻 보면 프라이버시와 별로 상관이 없지만, 사실은 그렇지 않습니다. 이 표준을 잘 활용하면, 프라이버시 프로토콜이 더 이상 릴레이어(broadcaster)에 의존하지 않아도 되죠. 지금 레일건이나 토네이도 캐시 같은 프로토콜들은, 트랜잭션을 보내기 위해 사용자가 릴레이어에게 요청을 보내야만 합니다. 만약 사용자가 직접 트랜잭션을 보낸다면 사용자의 신원이 발신자 주소에 묶이기 때문에, 제3자 릴레이어가 대신 보내주는 것이죠.

EIP-8141을 활용하면, 이 중개자를 아예 없앨 수 있습니다. 바로 프라이버시 프로토콜 컨트랙트 자체를 유저들의 ‘공용 계정’으로 사용하는 것입니다. EIP-8141이 도입되면, 컨트랙트가 트랜잭션 발신자가 될 수 있기 때문에, 공유 컨트랙트 하나를 발신자로 삼고, 그 안에서 사용자별로 ZK 증명으로 본인이 가진 돈을 인증하고 프라이빗 출금이나 자금 전송을 수행하는 것이죠. 비탈릭이 트위터에서 EIP-8141을 "프라이버시 프로토콜의 1급 시민화"라고 부르던 게 이러한 의미입니다.

근데 이 그림이 실제로 작동하려면, 8141만으론 두 가지 구조적 문제가 남습니다.

[문제 1: 공유 발신자의 직렬화 병목]

"한 컨트랙트가 N명의 사용자를 대표한다"는 모델에는 함정이 있습니다. 발신자에게는 단 하나의 선형 논스만 있어서, 사용자 A의 트랜잭션이 어떤 이유로든 지연되면 B, C, D가 그 뒤에 줄지어 기다려야 한다는 거죠. 서로 완전히 무관한 출금인데도 말입니다.

프라이버시는 본질적으로 사용자들이 서로의 활동에 영향받지 않는다는 전제 위에 서 있는데, 이 전제가 깨지는 것입니다. 서로 동시에 트랜잭션을 보내면, 수수료를 더 많이 낸 사용자의 트랜잭션만 블록에 포함되고, 나머지는 모두 실패하게 됩니다.

[문제 2: 검증 단계에서 외부 상태를 읽지 못함]

EIP-8141의 검증 프레임(VERIFY)은 STATICCALL처럼 동작합니다. 상태 변경이 안 되는 건 당연하고, 공개 멤풀 안전성을 위해 외부 컨트랙트 상태를 자유롭게 읽는 것도 한됩니다. 이 제한이 없으면, 누군가 스토리지 하나를 바꾸는 것만으로 멤풀에 떠 있는 수많은 트랜잭션을 한 번에 무효화시키는 DoS 공격을 수행할 수 있기 때문입니다.

문제는 프라이버시 프로토콜이 ZK 증명을 검증하려면, 해당 프로토콜이 사용하는 머클 트리의 최근 루트가 필요하다는 점입니다. 즉, 현재 EIP-8141 표준만으로는 프라이버시 프로토콜을 구현할 수 없습니다.

[해결: EIP-8250과 EIP-8272]
두 제안은 각각의 문제를 해결합니다.

• EIP-8250 (Keyed Nonces)

기존의 단일한 논스를 (key, seq) 쌍으로 쪼갭니다. 키가 0이면 기존 계정 논스 그대로(하위 호환), 0이 아니면 키마다 독립된 논스를 갖죠. 서로 다른 키의 트랜잭션은 독립적이라, 한 사용자가 다른 사용자를 막지 못합니다. 흔히 '2D 논스'라고 불리며, ERC-4337에서 한 계정이 여러 시퀀스를 병렬로 굴리는 용도로 이미 쓰여 온 개념입니다.

프라이버시 프로토콜에서는 이걸 무효화자(nullifier)에 접목해 사용합니다. 토네이도 캐시 같은 프로토콜에서 출금할 때, 내가 어떤 입금(commitment)을 쓴 것인지 온체인에 그대로 드러내면 입금-출금이 연결돼 프라이버시가 깨집니다. 그래서 프라이버시 프로토콜은 입금마다 고유한 무효화자라는 일회용 라벨을 도입합니다. 온체인에는 무효화자만 공개하고, ZK 증명 안에서 "이 무효화자가 트리 안의 어떤 입금에 대응한다"는 사실만 증명하는 거죠. 한 번 등장한 무효화자는 다시 못 쓰게 막아서 이중지불도 함께 방지합니다.

이 2D 논스가 도입되면, 프라이버시 프로토콜은 논스의 키 자리에 이 무효화자를 그대로 넣게 됩니다. 각 자금의 무효화자가 고유하니 사용자들은 서로 방해받지 않으며, 프로토콜이 시스템 컨트랙트에 그 키를 영구히 마킹해 주니 무효화자 중복 사용 방지까지 EVM 레벨에서 보장됩니다. 앱 컨트랙트가 자기 스토리지에 무효화자 테이블을 관리하던 일을 프로토콜이 대신 해 주는 셈이죠.

• EIP-8272 (Recent Roots)

EIP-8141 트랜잭션에 자기가 검증에 참조할 (source_id, slot, root) 리스트를 선언할 수 있게 합니다. 이게 도입되면, 프라이버시 프로토콜은 새 루트가 생길 때마다 시스템 컨트랙트에 슬롯 단위로 제출하게 됩니다. 해당 프로토콜을 사용하는 사용자는, 본인이 생성한 ZK 증명의 기반이 되는 루트를 트랜잭션에 직접 명시합니다. 그러면 클라이언트가 프레임 실행 전에 이 루트가 진짜 그 프로토콜이 제출한 것인지 미리 검증해 주고, 검증 프레임은 전용 명령어로 트랜잭션 안의 루트를 꺼내 ZK 증명 검증에 사용하죠.

즉, EIP-8272는 EIP-8141의 검증 프레임 제한에 대한 좁고 명시적인 예외를 뚫는 제안입니다. 외부 상태를 자유롭게 읽는 건 여전히 막혀 있지만, "사전에 검증된 최근 루트"라는 좁은 형태로는 검증 단계에 끌어올 수 있게 되는 거죠. 꼭 프라이버시에만 쓸 필요는 없어서 지갑 권한 루트, 과거 상태 루트 등 다양한 응용에도 활용될 수 있을 것으로 보입니다.

[결론]

EIP-8141이 "프라이버시 프로토콜을 멤풀로 직접 보낸다"는 큰 그림을 그렸다면, EIP-8250과 EIP-8272는 그 그림이 현실에서 작동하기 위한 받침대들입니다. 한쪽은 사용자 간 동시성을 풀어주고, 다른 쪽은 검증에 필요한 값을 안전하게 제공합니다. 두 제안이 함께 자리잡아야 비로소 레일건, 프라이버시 풀즈 같은 프로토콜이 릴레이어 없이 L1에서 굴러갈 수 있는 그림이 완성됩니다.

각 제안이 꼭 프라이버시 프로토콜에만 적용 가능한 것은 아니라는 점도 주목할 만한 듯 합니다. EIP-8250은 기존 AA 지갑에서도 자주 사용되었던 2D 논스를 도입하고, EIP-8272를 활용하면 세션 키와 같은 것들을 쉽게 구현할 수 있죠. 즉, 위 제안들은 프라이버시 프로토콜 사용 사례가 가장 큰 목표기는 하나, 다른 사용 사례도 포괄할 수 있는 범용적인 제안이라는 것입니다.

아즈텍, ZK패스포트 개발사 옵시디언 인수

아즈텍이 ZK패스포트(ZKPassport)의 개발사 옵시디언(Obsidian)을 인수했습니다.

ZK패스포트는 영지식 증명을 통해 개인정보를 올리지 않고 KYC를 할 수 있는 프로토콜입니다. 아즈텍 토큰 세일에서도 사용되었었습니다.

옵시디언의 코파운더 마이클 엘리엇(Michael Elliot)과 테어 마주(Theo Madzou)는 아즈텍 랩스에 합류해서 ZK패스포트 개발을 이어가며, 컨슈머 영역으로 제품을 확장할 예정이라고 합니다.

폴리곤처럼 ZK 스톤 모으나요...?

링크

이더리움을 보면 업계에서 되게 조롱 많이 해요. 그런데 펀더멘털 밸류는 엄청나게 달라졌어요 - Hashed 김서준 대표

해시드의 김서준 대표님의 발언 중 이더리움과 관련 된 내용들이 있어서 가져와봤습니다.

"예컨대 이더리움 같은, 그런데 이더리움을 보면 업계에서 되게 조롱 많이 해요. 5년 전이랑 지금이랑 가격이 똑같아요. 그래서 왜 이렇게 그러면 이더리움이 죽었냐 그러니까 이상한 짤들 많아요. 살아 있는지 쿡쿡 찔러보고. 그런데 펀더멘털 밸류는 엄청나게 달라졌어요."

"지금 모든 사람들이 공감하고 있는 IT 영역에서의 투자 기회들 말고 이들에게 결제와 신원을 주게 만들어질 영역이 블록체인이 될 거기 때문에. 퍼블릭 블록체인 중에서 무조건 이더리움을 사라고 말씀드리긴 조심스러운데 스테이블코인이 어떤 블록체인에서 지금 많이 유통되고 있는지는 조사를 하면 나오거든요. 참고로 지금은 이더리움이 한 60% 정도의 스테이블코인을 발행하고 유통하고 있어요."

"에이전트의 세계는 뭐 공감하실 수도 있겠지만 진짜 1%도 안 왔다고 생각해요. 지금 에이전트 잘 쓰고 있는 사람들 우리 주변에 많지 않잖아요. 이게 정말 뭐 커피숍 갔을 때 앉아있는 모든 사람들이 자기 일상을 돌봐주는 새로운 종으로써 우리와 함께 활동하게 됐을 때 어마어마한 트랜잭션과 가치 교환을 하게 될 거고 그것들의 인프라 자체가 퍼블릭 블록체인이 될 거기 때문에."

"스테이블코인을 포함해서 에이전트 트랜잭션이 많이 온보딩되고 있는 에셋을 유심히 관찰해 보시면 재밌는 기회가 있으실 수도 있다. 마치 2017년에 엄청난 버블이 있었잖아요. 그게 실제로 삼성전자, 하이닉스가 최근 들어서 어마어마한 상승을 보였던 것처럼 그런 흐름이 에이전트 파이낸스가 구현되는 시점에 벌어질 수가 있다고 조심스럽게 의견을 드립니다."

"주식회사와 법인이라는 개념의 시초가 네덜란드 동인도 회사에서 시작됐잖아요. 1604년 이 정도였던 것 같아요. 그러니까 400년 정도 된 개념인데 그전까지는 경제 공동체를 만들어서 거기서 투자를 하거나 그거를 배분할 수 있는 글로벌한 프로토콜 같은 게 없었거든요."

"에이전트 자체도 그런 기반이 생겨야 되는데 그럼 이 기반을 어디에 만들 거냐. 에이전트는 디지털 네이티브하게 생겼기 때문에 여기에 대한 신원, 평판, 그런 것들을 쌓기 위한 프로토콜의 표준들이 논의가 되고 있어요. 그중에서 가장 앞서 나가 있는 프로토콜이 이더리움 기반에 만들어지고 있는 ERC-8004라고 하는 건데, NFT 표준에 맞게 에이전트에 대해서 출생 등록을 하고 그다음에 그 에이전트가 해온 일들을 남길 수 있는 디지털 레이어가 필요한데 여기에서 블록체인 이상의 답은 아직까지는 없는 것 같아요."

"그냥 자기 서버에서 그냥 인증했다고 하면 바꿔버릴 수 있는데 그거를 퍼블릭 블록체인과 연결된 구조로 모든 기록을 남겨 놓으면 그거는 신뢰할 수 있는 그래도 지금까지 IT 인프라가 만들어 놓은 것 중에서는 가장 신뢰할 수 있는 증거잖아요."

"그 에이전트의 동작 방식을 스마트 컨트랙트로 만들어서 블록체인이랑 연결시켜 놓으면 투명하게 모든 기록들이 기록으로 남고 보이기 때문에. 그래서 그런 방식으로 지금 구글부터 시작해서 코인베이스, 메타마스크라고 해서 이더리움 쪽에서 제일 큰 지갑, 이런 회사들이 함께 모여가지고 그런 표준을 만들고 있고."

"구글도 지금 자체적으로 하지 않고 ERC-8004나 아니면 x402 같은 거에 다 참여하고 있는 이유 자체가 자기가 혼자서 구글의 서버에 이걸 저장하면 과연 얼마나 많은 파티들이 참여할까? 그래서 자기들이 이니셔티브를 가져가는 초기의 파운딩 파트너 중에 하나지만 거기에 대한 신뢰는 구글 서버보다 사람들은 블록체인을 믿을 거다라는 거죠."

출처: EP 98. AI가 실행하는 시대, 인간에게 남는 건 '의도' (Hashed 김서준 대표)

[EF가 공개한 ePBS 보안 분석 문서]

이더리움 재단 쪽에서 ePBS(EIP-7732)에 대한 보안 분석 문서를 공개했습니다. ePBS를 공부하기에도 매우 좋고, 향후 프로토콜 개발에 있어 EF의 의도를 엿볼 수 있어 소개드립니다.

[EF의 보안 분석 문서: ePBS의 A to Z]

EF에서 공개한 문서는, ePBS가 무엇을 보장하는가에 대한 긴 분석 문서입니다. 해당 문서에서는 ePBS의 보안적인 부분 뿐만 아니라, 전반적인 설명이 굉장히 자세히 적혀있습니다. 슬롯 하나가 굴러가는 과정을 Phase 0~4(입찰 → 블록 발행 → 밸리데이터 투표 → 빌더 공개 → 위원회 투표)로 쪼개 그림과 함께 보여주고, 각 단계마다 실제 스펙을 교육용으로 추상화한 수도코드를 붙입니다.

원래 이더리움 프로토콜을 공부하려면 EIP부터 합의/실행 스펙, ACD 회의록, 각 리서처가 작성한 이더리서치 혹은 HackMD 등을 하나하나 훑어가면서 공부를 했어야 했는데, 이 문서는 이를 하나에 몰아서 자세히 설명해주니, 사전지식 없이도 어느 정도 ePBS에 대해 이해할 수 있게 된다는 장점이 있습니다.

[문서의 목적: 형식적 증명으로 가는 1부]

문서에서 눈여겨볼 점은, 해당 문서가 단순히 설명서는 아니라는 것입니다. 특히, 문서에서는 프로토콜의 약속을 전부 ‘외부에서 관찰 가능한 6개 속성(P1~P6)’으로만 한정해 진술하고 있습니다. 노드 내부 상태가 아니라, 네트워크에 흐르는 메시지와 온체인 데이터만으로 누구나 확인할 수 있는 것들을 기반으로 하는 것이죠. 예를 들면 '정직한 프로포저가 제때 낸 블록은 canonical 체인에 남는다(P1)', '빌더가 페이로드를 숨기면 요금이 청구되지 않는다(P5)' 같은 식입니다. 그리고 각 속성의 논증을 '이 코드 줄 + 이 가정 ⟹ 이 속성'이라는 체인 형태로 만들어 둡니다.

왜 이런 형태로 문서를 작성했을까요? 향후 로드맵을 보면, 후속으로 남겨둔 가정들을 완전한 스펙 의사코드에 대한 줄 단위 증명으로 하나씩 메우는 동반 형식 문서가 작업 중이라고 하죠. 즉 지금 문서는 무엇을 증명해야 하고, 무엇을 가정으로 깔았는지를 빠짐없이 적어둔 '증명 계약'입니다.

이 증명 계약은 향후 형식적 증명, 나아가 형식 검증(formal verification)으로 이어지는 토대가 될 수 있습니다. 속성과 가정이 ‘이 코드 줄 + 이 가정 ⟹ 이 속성’이라는 사슬로 정리돼 있으니, 후속 작업은 이 사슬의 빈칸을 증명으로 채우기만 하면 것이죠.

이게 왜 중요하냐면, ePBS가 머지 이후 가장 큰 합의 레이어 변경 중 하나이기 때문입니다. ePBS가 포함된 글램스터담 업그레이드에서는 빌더라는 새 스테이커, 두 단계로 쪼개진 블록, 무조건 지불, 포크초이스 재설계가 한꺼번에 들어가게 되죠. 이런 규모에서 미묘한 버그 하나가 체인의 라이브니스 자체를 훼손할 수 있습니다. 느낌상 괜찮다 정도가 아니라 ‘이 가정들 아래 이 속성이 반드시 성립한다’가 증명으로 못 박히면, 그만큼 더 안심하고 안전하게 체인을 운영할 수 있게 됩니다.

또한, 이렇게 속성과 가정을 명시적인 계약으로 박아두면 앞으로의 프로토콜 업그레이드에도 기준선이 생깁니다. 새 변경이 기존에 세워둔 가정이나 속성 중 무엇을 건드리는지를 이 계약에 비춰 따져볼 수 있으니까요. 특히 후속 작업이 Lean 등을 활용한 형식 검증까지 이어진다면, 스펙이 바뀔 때마다 어떤 보장이 깨지는지를 다시 돌려 확인하는 일이 훨씬 수월해질 수 있을 것으로 보이네요.

[결론]

해당 문서는 아직 작업 중인 문서이며, 커뮤니티 피드백을 받아 다듬어 나갈 예정이라고 합니다. ePBS는 이더리움의 검열 저항성 및 확장성 개선에도 매우 중요한 업그레이드이니 궁금하신 분들은 한번 읽어보시길 바라며, 보강할 지점이 보이시면 이슈·코멘트로 의견 주셔도 좋을 것 같습니다!

출처

Thanks for sharing this!

One of the main goals of the work was to make ePBS easier to reason about and audit — not just for people already deep in the specs, but also for external reviewers who want to understand the guarantees, assumptions, and tradeoffs without first having to dig through the Python implementation.

We also wanted it to be a fairly self-contained reference, especially given that both the specs and ePBS itself are still evolving.

Some parts are still WIP as we continue interacting with protocol developers and the specs evolve over time, but I think one of the most important sections is the one on properties: we wanted to clearly express what guarantees ePBS provides, to which actors, and under which assumptions and conditions.