Copy English

Why

The acrimony is real but downstream — this is an execution-model fight wearing a governance costume. The accusations ("Base is hijacking L1 governance," "L1 is unresponsive to L2s") are what a genuine technical incompatibility looks like when it reaches a mailing list. 8141 makes validation maximally general by running EVM code: post-quantum signature aggregation, privacy protocols, transaction assertions are all just code you can express. L2s validate secp256k1 signatures with native code today precisely because EVM execution is too slow at their TPS, and they want AA validation on the same fast path. Generality and performance are asking for two different representations of the same standard, and that — not personalities — is why it nearly forked.

The reconciliation is a single idea worth extracting: make the general path recognizable so the fast path can shortcut it. All three working-group proposals do the same thing — a 7702-style delegation that names the validator, a mandated proxy bytecode, or re-interpreting a frame as a deterministic 8130 keystore call — so that an L2 sequencer can look at the account, know exactly what the EVM validation would do, and run equivalent native code instead. That is the same shape as l1-zkevm-optional-proofs (an optional fast/cheap path layered over a general one) and the core claim of the-boundary-is-the-unit: a standard survives divergence only if the shared interface holds while implementations differ underneath. A spec fragments when generality and speed cannot share one representation; it survives when the fast path can recognize and shortcut the general one.

Why it matters past AA: this is the template for L1-vs-L2 governance, now Ethereum's central axis. Ethlabs frames the rest of its work the same way — "Fast Ethereum" is the L1 bending toward L2 needs: FCR (Fast Confirmation Rule) letting bridges confirm L1 transactions in 12-24s, ~30x faster than finality; Quick Slots (EIP-8198) cutting block time 12s->10s; a consensus rework targeting 1-2 slot finality. And the honest asymmetry the L2 interviews surfaced belongs in the model: FCR makes L1->L2 deposits fast, but L2->L1 withdrawals stay slow because optimistic rollups are bound by the challenge window and zk rollups by proving time — exactly the l2-finality-three-clocks and erc-7683-settlement-security boundary. The AA fight is the first real test of whether L1 can serve L2 performance without fragmenting the EVM, and the recognize-and-substitute pattern is the answer that scales past this one EIP.

How it works

Two ways to validate a transaction

The two are not ranked — they want different things from the same standard, which is why it nearly forked.

The reconciliation: recognize the general path, substitute the fast one

All three make the EVM validation legible in advance so the sequencer can shortcut it — one spec, two execution models.

The rest of "Fast Ethereum," and the asymmetry

Deposits get fast; withdrawals do not — the same boundary as l2-finality-three-clocks.

Related cards

erc-8141 (the proposal itself, and the 8141/8130/Tempo field), l1-zkevm-optional-proofs (optional fast path over a general one), the-boundary-is-the-unit (a standard survives when the shared interface holds), l2-finality-three-clocks and erc-7683-settlement-security (the L2->L1 asymmetry), choosing-a-chain-is-a-lease (L1-vs-L2 as a governance axis).

← All Dev Notes · Workspace Index · Top ↑

Copy 한국어

AA 명세 하나, 실행 모델 둘 — 아니면 EVM 이 쪼개진다

Base 가 미는 EIP-8130 과 L1 이 선호하는 Frame Transactions(EIP-8141)가 이더리움 네이티브 계정 추상화 설계를 놓고 충돌했고, 감정이 상할 만큼 격해져 둘을 통합할 워킹그룹이 꾸려졌습니다(Ethlabs, Week 11, 2026-09). 거버넌스 드라마는 기술적 사실 하나의 하류입니다 — 8141 은 트랜잭션을 EVM 코드를 실행해 검증하고(최대한 범용), L2 는 속도를 위해 네이티브 코드로 검증하며 높은 TPS 에서 EVM 검증을 감당할 수 없습니다. 제안된 모든 해법은 한 동작을 공유합니다 — L2 가 그 검증을 알아보고 동등한 네이티브 코드로 치환하게 해, 명세 하나가 두 방식으로 돌게 하는 것.

아직 범위 미정 — 빌드가 아니라 이해·비교 연습입니다. 두 제안을 읽고 각각이 무엇을 재고 트랜잭션을 어떻게 검증하는지 씁니다. 핵심 문장은 검증자가 무엇을 실행하나 입니다 — 8141 은 EVM 바이트코드("프레임")를 실행하고, L2 는 네이티브 코드를 실행하고 싶어 하며, 그게 긴장의 전부입니다. 그다음 워킹그룹의 세 화해안을 모델링하고 각각에 대해 한 질문에 답합니다 — L2 시퀀서가 미리 무엇을 읽어야 어떤 네이티브 코드로 치환할지 아는가? (1) 7702 식 위임을 확장해, 계정이 시퀀서가 네이티브 등가물로 바꿀 수 있는 명명된 코드에 검증을 위임. (2) 특정 account-proxy 바이트코드를 강제해, 시퀀서가 프레임만 보고 무슨 로직이 돌지 확신. (3) 검증 프레임을 결정론적인 8130 keystore 컨트랙트 호출로 재해석 — 네이티브 코드로 치환 가능. 산출물은 표입니다: 제안 -> L2 가 알아보는 것 -> 치환하는 것 -> 잃는 범용성. 사실: Ethlabs(Derek Chiang) Week 11 업데이트, 2026-09 — 프로젝트 자신의 프레이밍("AA 공식 해결. 사실은 아님")에 Base 업데이트 예고; 8130/8141 메커니즘은 EIP 원문으로 확인할 것.

왜

감정 다툼은 실재하지만 하류입니다 — 이것은 거버넌스 옷을 입은 실행 모델 다툼입니다. 비난들("Base 가 L1 거버넌스를 납치한다", "L1 이 L2 요구에 무반응이다")은 진짜 기술적 비호환이 메일링 리스트에 도달했을 때의 모습입니다. 8141 은 EVM 코드를 실행해 검증을 최대한 범용으로 만듭니다 — 양자내성 서명 집계, 프라이버시 프로토콜, 트랜잭션 어서션이 전부 표현 가능한 코드일 뿐. L2 는 오늘 secp256k1 서명을 네이티브 코드로 검증하는데, 바로 EVM 실행이 자기 TPS 에서 너무 느려서이고, AA 검증도 같은 빠른 경로에 두고 싶어 합니다. 범용성과 성능이 같은 표준의 서로 다른 표현을 요구하는 것 — 인물이 아니라 그것이 — 거의 포크로 간 이유입니다.

화해는 뽑아 둘 만한 한 아이디어입니다 — 범용 경로를 알아볼 수 있게 만들어 빠른 경로가 지름길로 가게 하라. 워킹그룹의 세 제안은 같은 일을 합니다 — 검증자를 명명하는 7702 식 위임, 강제된 프록시 바이트코드, 또는 프레임을 결정론적 8130 keystore 호출로 재해석 — 그래서 L2 시퀀서가 계정을 보고 EVM 검증이 무엇을 할지 정확히 알아 동등한 네이티브 코드를 대신 돌립니다. l1-zkevm-optional-proofs(범용 위에 얹은 선택적 빠른·저렴 경로)와 같은 모양이고, the-boundary-is-the-unit 의 핵심 주장입니다 — 표준은 구현이 아래에서 갈려도 공유 인터페이스가 버틸 때만 분기를 견딥니다. 명세는 범용성과 속도가 한 표현을 공유 못 할 때 쪼개지고, 빠른 경로가 범용 경로를 알아보고 지름길로 갈 수 있을 때 살아남습니다.

AA 너머로 왜 중요한가: 이것은 이제 이더리움의 중심 축이 된 L1 대 L2 거버넌스의 템플릿입니다. Ethlabs 는 나머지 작업도 같은 틀로 봅니다 — "Fast Ethereum"은 L1 이 L2 요구 쪽으로 굽는 것입니다: FCR(Fast Confirmation Rule)로 브리지가 L1 트랜잭션을 12-24초, 파이널리티보다 약 30배 빠르게 확인; Quick Slots(EIP-8198)로 블록 타임 12초->10초; 1-2 슬롯 파이널리티를 노리는 합의 재설계. 그리고 L2 인터뷰가 드러낸 정직한 비대칭은 모델에 들어가야 합니다 — FCR 은 L1->L2 입금을 빠르게 하지만, L2->L1 출금은 낙관적 롤업이 챌린지 기간에, zk 롤업이 증명 시간에 묶여 여전히 느립니다 — 정확히 l2-finality-three-clocks·erc-7683-settlement-security 의 경계입니다. AA 다툼은 L1 이 EVM 을 쪼개지 않고 L2 성능을 섬길 수 있는지의 첫 진짜 시험이고, 알아보고-치환하는 패턴이 이 EIP 하나를 넘어 확장되는 답입니다.

동작 방식

트랜잭션을 검증하는 두 방식

둘은 우열이 아니라 같은 표준에서 다른 것을 원합니다 — 그래서 거의 포크로 갔습니다.

화해: 범용 경로를 알아보고, 빠른 경로로 치환

셋 다 EVM 검증을 미리 읽을 수 있게 만들어 시퀀서가 지름길로 가게 합니다 — 명세 하나, 실행 모델 둘.

"Fast Ethereum"의 나머지, 그리고 비대칭

입금은 빨라지고 출금은 아닙니다 — l2-finality-three-clocks 와 같은 경계.

관련 카드

erc-8141(제안 자체, 그리고 8141/8130/Tempo 판), l1-zkevm-optional-proofs(범용 위 선택적 빠른 경로), the-boundary-is-the-unit(공유 인터페이스가 버틸 때 표준이 산다), l2-finality-three-clocks·erc-7683-settlement-security(L2->L1 비대칭), choosing-a-chain-is-a-lease(거버넌스 축으로서의 L1 대 L2).

← 전체 개발 노트 · 워크스페이스 인덱스 · 맨 위 ↑