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 하나를 넘어 확장되는 답입니다.
동작 방식: ### 트랜잭션을 검증하는 두 방식 | | 8141 (Frame Transactions) | L2 네이티브 검증 | | --- | --- | --- | | 검증자가 실행하는 것 | **EVM 코드**("프레임") | **네이티브 코드** | | 최적화 대상 | 범용성 — PQ 서명, 프라이버시, 어서션 | 처리량 — 매우 높은 TPS | | 비용 | 검증마다 EVM 실행 | 오늘의 k1 서명 검사처럼 거의 공짜 | | 선호 진영 | L1 연구자 / 코어 개발자 | L2 (Base 의 8130 이 이쪽) | 둘은 우열이 아니라 같은 표준에서 다른 것을 원합니다 — 그래서 거의 포크로 갔습니다. ### 화해: 범용 경로를 알아보고, 빠른 경로로 치환 | 제안 | L2 가 알아보는 것 | 치환하는 것 | | --- | --- | --- | | 확장된 7702 위임 | 명명된 코드에 검증을 위임한 계정 | 동등한 네이티브 코드 | | 강제된 프록시 바이트코드 | 고정 바이트코드 → 알려진 검증 로직 | 그 로직의 네이티브 코드 | | 프레임 = 8130 keystore 호출 | 결정론적 keystore 조회 | 그 조회의 네이티브 코드 | 셋 다 EVM 검증을 *미리 읽을 수 있게* 만들어 시퀀서가 지름길로 가게 합니다 — 명세 하나, 실행 모델 둘. ### "Fast Ethereum"의 나머지, 그리고 비대칭 | 워크스트림 | 하는 일 | 비고 | | --- | --- | --- | | FCR (Fast Confirmation Rule) | L1 tx 를 12-24초에 확인 | 파이널리티보다 ~30배 빠름; L1->L2 입금 | | Quick Slots (EIP-8198) | 블록 타임 12초 -> 10초 | Flashbots/BuilderNet 지지; Hegotá 후보 | | Fast Finality | 합의 재설계 | 1-2 슬롯 파이널리티 목표 | | **L2 -> L1 메시징** | **여전히 느림** | **챌린지 기간(낙관적) / 증명 시간(zk)** | 입금은 빨라지고 출금은 아닙니다 — `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).