EIP-8288의 시각화

이더리움 메인 체인에 암호 기능을 어떻게 넣을지를 두고, 최근 비탈릭이 꽤 분명한 방향을 내놨습니다. 여기에 Ethlabs의 Derek Chiang이 시각화를 붙여 해설하면서 관심이 더 커졌는데요, 두 글을 묶어서 정리해봤습니다.

프리컴파일 말고, EIP-8288로 가자

앞으로 이더리움에 필요한 기능 중 상당수는 무거운 암호 연산을 요구합니다. 양자내성(PQ) 서명은 기존 서명보다 훨씬 크고, 프라이버시 트랜잭션에는 STARK 같은 ZK 증명이 붙죠.

지금까지는 새 암호 기능이 필요할 때마다 프리컴파일을 추가하는 방식이 익숙했습니다.
비탈릭은 이 방식이 맞지 않다고 봅니다.

프리컴파일이든 EVM이든 결국 데이터를 블록에 calldata로 올려야 처리할 수 있는데, 블록 공간은 한정돼 있다는 거죠. PeerDAS나 blocks-in-blobs를 쓰더라도 약 8MB/s 정도가 현실적인 상한이라고 합니다.

비탈릭은 이더리움은 "블록체인"이 아니라 "암호학적 세계 컴퓨터"이고, 메인 스레드에 꼭 있을 필요가 없는 데이터와 연산은 메인 스레드에 넣지 말아야 한다는 겁니다. 대신 무거운 연산은 사용자 기기에서 직접 계산하고 STARK로 증명한 뒤, 이를 EIP-8288의 재귀 집계 구조에 태우자고 제안합니다.

체인은 "연산이 수행됐고 결과는 이것"이라는 사실만 확인하면 되고, 원본 데이터나 연산 과정은 볼 필요가 없습니다. 이렇게 하면 누구나 원하는 암호 방식을 쓸 수 있고, 체인은 가볍게 유지되며, 프리컴파일을 더 추가할 일도 없어진다는 게 비탈릭의 주장입니다.

EIP-8288은 어떻게 작동하나

EIP-8288은 비탈릭과 Thomas Coratger가 제안한 EIP로, 핵심은 멤풀을 분산 증명 공장처럼 쓰는 것입니다.

트랜잭션은 무거운 서명이나 STARK를 본체에 넣지 않고 “dependency”로 따로 선언합니다. 이 구조는 EIP-8141(frame 트랜잭션) 위에 새로운 frame 모드를 추가하는 방식이죠. 멤풀 노드들은 일정 시간마다 받은 증명들을 모아서 합친 뒤 다시 전파하고, 이 과정이 여러 라운드 반복되면서 증명 개수가 점점 줄어듭니다. 마지막에는 블록 빌더가 남은 것들을 블록당 증명 하나로 합칩니다.

알려진 수치로는 블록마다 100~300KB 크기의 STARK 하나와 statement당 96바이트 정도가 추가되고, 프라이버시 트랜잭션의 가스 사용량은 수천만 단위에서 수만 단위로 줄어들 것으로 예상됩니다. Falcon이나 ML-DSA 같은 새 서명 방식도 EVM을 수정하지 않고 지원할 수 있고요.

Derek이 주목한 부분: 탈중앙화될수록 확장성이 커진다

Ethlabs의 Derek은 비탈릭의 글을 인용하면서 EIP-8288의 집계 과정을 GIF로 시각화했습니다. "지금까지 가장 좋아하는 EIP"라고 할 만큼 높게 평가합니다. 이 구조가 탈중앙화 수준이 높아질수록 확장성이 오히려 커진다는 점을 강조합니다.

보통은 처리량을 늘리려면 노드 사양을 올려야 하고, 그만큼 중앙화 압력이 생기죠.

Derek의 설명에 따르면 EIP-8288은 이 관계를 뒤집습니다. 멤풀 노드 하나하나가 증명을 합치는 작업자이기 때문에, 노드가 늘어날수록 처리할 수 있는 서명과 증명도 늘어납니다. 여러 라운드에 걸쳐 합치므로 각 노드가 쓰는 대역폭은 일정하게 유지되고요. 빌더는 멤풀이 미리 집계해둔 것을 마무리만 하면 되니 하드웨어 요구 사항이 올라가지 않고, 검증자는 수천 개 서명 대신 증명 하나만 확인하면 됩니다.

여기에 STARK까지 집계 대상이니 어떤 서명 방식이든 STARK로 감싸서 넣을 수 있죠.

Derek은 이를 바탕으로, 이더리움이 초당 수만 건의 PQ·프라이버시 트랜잭션을 처리하면서 트랜잭션당 가스는 아주 적게 쓰고, 동시에 지금보다 더 탈중앙화될 수 있다고 주장합니다.

현재 상태
EIP-8288은 9월 9일 EIP 저장소에 병합됐고, 아직 Draft 단계로 적용 일정은 정해지지 않았습니다. 비탈릭은 Hegota 다음 포크인 I-star에서 검토되기를 바란다고 밝힌 상태입니다.

비탈릭: https://x.com/VitalikButerin/status/2112032009413439704?s=20

Derek: https://x.com/decentrek/status/2112535053188145367?s=20

[글램스터담 업그레이드, 보안 이슈로 연기]

어제 ACD 회의에서, 주요한 보안 이슈로 글램스터담 업그레이드가 연기되었습니다. 다음주 월요일에 진행될 예정이었던 후디 네트워크 업그레이드는 관련 이슈에 대한 해결책이 확정될 때까지 무기한 연기되었습니다.

취약점은 이더리움의 가스 동작을 바꾸는 EIP-8037과 EIP-8038애 있었습니다. 며칠 전 발간된 ChainSecurity의 글에 따르면, 해당 EIP들은 솔리디티 내 gasleft() 함수가 반환하는 가스 잔량과 가스 부족 시의 동작을 바꿀 수 있습니다. 이로 인해 외부 호출이 가스 부족으로 실패했음에도, 기존에는 함께 롤백되던 상위 컨트랙트가 실패를 기록하고 트랜잭션을 정상적으로 완료하는 등 예상치 못한 동작이 가능해집니다. 예를 들어, 어떤 디파이 프로토콜에서 유저가 ETH 출금을 수행할 때, 실제 출금이 수행되진 않았지만, 컨트랙트 내에서는 출금이 성공적으로 수행된 것처럼 여겨져 출금 권리가 소멸될 수 있죠. ChainSecurity에 따르면, 전수 조사를 하지 않아도 벌써 이 변경에 영향받는 13개의 프로토콜을 발견했으며, 그 중에는 사람들이 많이 사용하는 메이저 프로토콜도 있다고 합니다.

이더리움 재단은 지난 8월 경 글램스터담 가스 변경에 대한 영향 파악을 위해 이더리움 내 트랜잭션을 전수조사하여 관련 프로젝트들에게 연락을 취한 바 있지만, 이는 “성공하던 트랜잭션이 실패하는 사례”에 국한되어 있으며, 위와 같이 트랜잭션이 성공하더라도 내부 로직에 문제가 생기는 경우까지 조사를 하지는 못한 것으로 보입니다.

기존에도 이더리움은 하드포크 간 항상 하위 호환성을 지키지는 않았습니다. SELFDESTRUCT의 동작을 바꾼 것을 대표적인 예시로 들어 왔죠. 다만, 이 같은 변경은 SELFDESTRUCT를 일반적인 컨트랙트에서 거의 사용하지 않기 때문이었고, 이더리움은 일반적으로 사용자에 대한 영향을 최소화하는 방향의 하드포크만 수행해 왔습니다. 따라서 이번처럼 메이저 프로토콜이 영향받을 수 있는 사항에 대해서는, 보수적으로 하드포크 일정을 연기하게 된 것 같네요.

물론 일정이 어떻게 될지는 지켜봐야겠지만, 휴가가 많은 연말/연초 특성 상, 원래 12월 초로 예상되었던 글램스터담 메인넷 업그레이드는 내년 초로 미뤄질 것으로 보입니다. 또한, 기존 컨트랙트들의 영향이 커 EIP-8037이나 EIP-8038을 포크에서 제외하게 될 경우, 기존 글램스터담에서 예상되었던 블록 가스 리밋 증가 계획이 재검토되어, 200M 까지의 확장성 증가가 이뤄지지 못할 가능성도 존재할 수 있을 것으로 생각되네요.

물론 일정이 미뤄진 건 아쉽지만, 하드포크 이후에 문제를 발견하는 것보다는 낫다고 생각됩니다. 혹시 이더리움 메인넷 위에서 업그레이드 불가능한 컨트랙트를 운영하고 계시다면, 위 글을 통해 영향받는 지점이 있는지 확인해보시기 바랍니다!

출처

글램스테르담 포크가 가스 리프라이싱 보안 이슈로 무기한 연기됐다

이번 호 인사이트
· 가스 리프라이싱의 하위호환 리스크가 경고 단계를 지나 실제 포크 연기 사유가 됐다
· 포크 파이프라인 병렬화가 글램스테르담 연기의 로드맵 충격을 줄이고 있다
· 중앙화 인프라의 연쇄 사고로 탈중앙화가 다시 보안 논거로 쓰이고 있다

프로토콜 업데이트
· EF의 Hoodi 연기 공지와 노드 운영자 롤백 안내
· geth, MPT에서 Partitioned Binary Tree로 첫 자가 마이그레이션 성공

포럼 제안
· EIP-8453 드래프트, 헤드 투표와 파이널리티 증명을 분리하는 디커플드 합의
· EIP-8450 드래프트, 비컨 스테이트에 양자내성 밸리데이터 키 레지스트리
· SEACAST, 실행 가능한 스펙과 형식 모델을 갖춘 브로드캐스트 프로토콜 제안
· 암호화 멤풀에서 송신자의 공개 선택권 가치를 정량화한 연구
· EIP-8288 집계에 복수 증명 크기를 허용하는 이기종 재귀 제안
· EVM 점프·콜 테이블 제안과 신규 드래프트 단신

트위터 논쟁
· 글램스테르담 비판의 시점을 둘러싼 pcaversaccio와 EF 리서처들의 설전
· Gloas 빌더 입찰을 최고가로 고르는 클라이언트 옵션을 둘러싼 논쟁

주요 발언
· Barnabé Monnot, '이보다 강한 멀티포크 계획과 파이프라이닝은 본 적 없다'
· potuz, '지금의 이더리움 ACD는 MicahZoltu의 내가 말했잖아 순간이다'
· EthCoordinate, '테스트넷은 바로 이럴 때를 위해 존재한다'

전체 요약 보기 → https://ethcollective.xyz/news

EIP-8453 — Decoupled Consensus
-> 블록 합의와 최종성(Finality) 투표를 분리해 Gasper의 구조적 한계를 해결하자

현재 하나의 Attestation이 담당하는 두 가지 기능을 독립적인 투표 과정으로 분리하는 것이 핵심.

- Available Chain: 슬롯마다 약 512명의 검증자 위원회가 블록 헤드에 투표하여 체인을 계속 진행시킴

- Finality Gadget: 전체 검증자 집합이 별도의 투표 라운드에 참여하여 블록을 최종 확정.

- 기대 효과: 최초 목표는 최종성 시간 4배 이상 단축이며, 장기적으로 수십 초 또는 그 이하의 최종성을 추구합.

- 추가 목표: 리오그 공격 방어 강화, 슬롯 시간 단축의 기반 마련, 양자내성 암호로의 전환 용이성 확보.

- 타겟: 스트로맵 기준 I* 포크(2028년 초)

ACDE #248 · 10월 22일
실행 계층(EL) 클라이언트 개발자들이 격주로 모이는 올코어데브 실행 계층(ACDE) 콜이다.

한 줄 요약
체인시큐리티가 글램스테르담(Glamsterdam) 가스 재가격(repricing) EIP로 기존에 실패하던 악성 트랜잭션이 성공하게 된다는 취약점을 공개하자, 10월 26일 예정이던 후디(Hoodi) 테스트넷 포크가 무기한 취소되고 메인넷 날짜 결정도 영향 분석이 끝날 때까지 미뤄졌다.

결정된 것
· 10월 26일 예정이던 후디 글램스테르담 하드포크가 무기한 취소됐고 새 날짜는 정하지 않았다. 스펙이 바뀔 경우에 대비해 포크 이전 스펙의 테스트넷을 하나 남겨두는 결정이다.
· 메인넷 글램스테르담 포크 날짜 결정은 전체 영향 분석이 끝날 때까지 미뤄졌다. 2026년 12월 포크는 매우 어려워졌고 2027년이 유력하다.
· ACDT 콜이 60분에서 90분으로 늘어난다. 매번 시간이 모자라던 테스트 콜에 여유를 주는 변경이다.
· bogota-devnet-2 범위를 EIP-8253, EIP-4758, EIP-8298, EIP-8151 네 개로 확정하고 다음 주 Nethermind, Geth, ethrex 세 클라이언트로 출시한다. 헤고타(Hegota) 후보 EIP를 실제 네트워크에서 돌려보는 실험망이다.
· 첫 EL+CL 통합 데브넷(hegota-devnet-0)은 데브콘 이후로 잡고 FOCIL과 프레임(Frames)의 상호작용 논의는 데브콘 현장에서 시작한다. 두 기능이 서로 영향을 주기 때문에 설계를 먼저 맞추려는 것이다.

일정
· 2026년 10월 26일 주에 bogota-devnet-2 출시, 확정
· 다음 ACDE는 4주 뒤인 2026년 11월 19일경, 확정

왜 중요한가
가스비 구조를 바꿔 확장을 노린 글램스테르담이 이미 배포된 디파이 컨트랙트를 공격 가능하게 만들 수 있고 13개 프로젝트가 영향권으로 확인됐다. 12월로 보던 메인넷 업그레이드는 2027년으로 밀릴 가능성이 커졌고 보안 분석 결과에 따라 스펙 자체가 바뀔 수도 있다.

ACDE #248 · 누가 무슨 말을 했나
가스 재가격이 기존 컨트랙트를 깨뜨릴 수 있다는 경고에 포크를 멈췄다

글램스테르담이 배포된 컨트랙트를 깨도 되는가 · 연기 결정 00:47:12
체인시큐리티가 가스 재가격 EIP-8037/8038 아래에서 기존에 실패하던 악성 트랜잭션이 성공하게 되는 취약점을 공개하면서 프로토콜 변경이 사용자 컨트랙트를 깨도 되는지가 쟁점이 됐다.

· Hubert: 셀프디스트럭트 강제 전송과 상태 가스 환급이 결합하면 ETH를 보내지 않고도 잔액이 갱신되는 예시를 제시했다. 13개 디파이 프로젝트에 책임 공개(responsible disclosure)를 진행 중이며 조사는 전수 조사가 아니라고 밝혔다.
· Maria Silva (EIP-8037 제1저자): 충분히 큰 업그레이드 불가 컨트랙트가 영향을 받는지가 스펙 변경 여부를 가르는 질문이라고 짚었고 Hubert의 답을 듣고 그런 컨트랙트의 존재가 아직 불확실하니 스펙 변경 가능성이 남아 있다고 결론냈다.
· Potuz (Offchain Labs, Prysm): 보안이 포크의 시의성보다 100% 우선한다고 썼다. (채팅)
· lightclient (Matt Garnett) (EF, geth): 개발자 과실로 책임을 돌리는 접근은 잘못됐고 충분한 자금과 사용자가 기대는 기능이라면 프로토콜이 사용자 공간을 깨서는 안 된다고 주장했다. 앱 개발자에게 업그레이드를 강제하는 일은 극도로 지저분해진다고 덧붙였다.
· Toni Wahrstätter (EF, 리서처): 큰 컨트랙트가 깨진다면 당연히 스펙을 바꾸고 포크를 미루겠지만 지금은 실제 영향을 몰라 추측이 이르다고 했다. 깨진 불변식을 복원하려 들면 EIP가 주는 이득 자체가 사라질 수 있다고도 경고했다.
"내가 말하려는 것은 글램스테르담 전에는 통하지 않았지만 글램스테르담 후에는 통하게 된 악성 트랜잭션이다." (Hubert, 00:13:56)

후디 포크를 멈출 것인가 · 취소 결정 00:49:52
10월 26일로 나흘 앞까지 다가온 후디 테스트넷 포크를 강행할지, 보안 분석이 끝날 때까지 취소할지를 콜 안에서 결정해야 했다.

· Justin Florentine (Besu): 이미 포크한 세폴리아(Sepolia)와 비교할 대조군이 필요하다며 후디를 포크 이전 스펙에 남겨두자고 했다.
· Daniel Lehrner: 스펙을 바꿔야 하면 세폴리아는 버려야 하고 후디까지 포크하면 바뀐 스펙을 테스트할 곳이 아예 없어진다고 지적했다.
· Potuz (Offchain Labs, Prysm): Daniel의 말에 동의하며 분산된 검증자가 많은 후디를 다시 배포하는 것은 큰 고통이므로 후디 연기로 기울었다.
· Parithosh Jayanthi (EF DevOps): 릴리스가 이미 나가 커뮤니티 전체가 새 버전으로 갈아타야 하므로 포크 실패 위험이 있다고 반론했으나, 이전 버전으로 롤백하면 된다는 Potuz의 지적을 수긍했다.
· Dima Gusakov (Lido): 리도는 어제 이미 업그레이드를 마쳤지만 온체인 롤백은 가능하다며, 후디에 230만 스테이크를 가진 30여 운영자에게 롤백을 요청하겠으나 100% 이행은 보장 못 한다고 했다.
"후디는 미뤄야 할 것 같다. 답해야 할 질문이 남아 있는데 포크를 강행할 좋은 이유를 못 들었고, 후디를 잃는 것은 좋지 않다." (lightclient (Matt Garnett), 00:35:13)

CFI는 기본 포함인가
헤고타에 CFI 상태 EIP가 19개 가까이 쌓인 가운데, CFI를 사실상 포함 확정처럼 취급하는 관행을 바로잡자는 문제 제기가 나왔다.

· lightclient (Matt Garnett) (EF, geth): CFI를 기본 포함으로 보는 사람과 기본 제외로 보는 사람이 섞여 있어 '이더리움이 이걸 해야 하나'라는 논의 없이 EIP가 미끄러져 들어간다고 지적했다. 모든 프로토콜 변경은 리스크이므로 필요 최소한만 바꿔야 하고 CFI가 기본 포함이라면 PFI에서 CFI로 가는 문턱을 훨씬 높여야 한다고 했다.
· Justin Florentine (Besu): lightclient에 격하게 동의하면서도 CFI에서 SFI로 가는 단계가 작업량을 평가하는 자리이므로 CFI를 기본 포함으로 만들어 그 단계를 잃어서는 안 된다고 했다.
· Łukasz Rozmej (Nethermind, EIP-8037 공동 저자): 이번 스코핑에서도 조건이 붙은 CFI가 많았고 조건이 충족되지 않으면 DFI가 기본이라며, CFI를 기본 포함으로 봐서는 안 된다고 했다.
· Mario Vega (EF, 테스팅, ACDT 진행): CFI에 시간을 쏟는 순간 매몰 비용 오류가 생겨 거절이 정치적으로 어려워진다며, CFI 자체가 큰 결정임을 인지하고 앞으로 더 신중해야 한다고 했다.
· Potuz (Offchain Labs, Prysm): CFI는 애초에 모든 클라이언트가 구현을 강제받지 않은 채 테스트하려고 만든 것이라며 기본 포함 해석에 강하게 반대했다.
"이더리움에 가하는 모든 변경은 리스크다. 8037과 8038에서 지금 보고 있는 그대로다. 그래서 우리는 절대적으로 최소한의 변경만 해야 한다." (lightclient (Matt Garnett), 01:25:40)

다음 데브넷, EL 단독인가 통합인가 · 스코프 확정 01:36:58
데브콘 전에 EL 단독 데브넷(bogota-devnet-2)을 하나 더 띄울지, 바로 EL+CL 통합 데브넷(hegota-devnet-0)으로 갈지와 그 범위를 정해야 했다.

· Mario Vega (EF, 테스팅, ACDT 진행): FOCIL과 프레임은 실제 상호작용이 있어 합치는 가치가 있지만 보고타가 준비됐다면 그것만으로도 테스트 가치가 있으니 먼저 내보내자고 했다.
· Jihoon: FOCIL과 프레임의 상호작용 설계가 아직 준비되지 않아 다음 주 통합 데브넷은 이르고 FOCIL 단독이라면 가능하다고 했다.
· lightclient (Matt Garnett) (EF, geth): EL 단독이면 다음 주 출시에 자신이 있다고 했고 이번 주에 아무것도 못 띄우면 데브콘 이동 때문에 몇 주 밀릴 것을 걱정했다.
· Justin Florentine (Besu): FOCIL과 프레임 상호작용을 보려는 것이라면 EIP를 세 개나 더 얹지 말자고 했고 다만 SETCODEFROM은 넣겠다고 했다. 자기 팀은 네 개 시한을 못 맞추지만 3개 클라이언트로 출시하는 것에 반대하지 않았다.
· Łukasz Rozmej (Nethermind, EIP-8037 공동 저자): 네더마인드는 모든 EIP에서 앞서 있다며 네 개 전부 포함하길 원한다고 했다.
· Barnabas Busa (EF DevOps): 출시에는 클라이언트 3개면 충분하므로 준비된 팀만으로 네트워크를 띄우면 된다고 했다.
"출시에는 클라이언트만 있으면 된다. 3개 클라이언트를 모을 수 있으면 네트워크를 띄울 수 있을 것이다." (Barnabas Busa, 01:43:33)

남은 것
· EF와 클라이언트 팀: 후디 포크 취소를 알리는 블로그 글을 즉시 발행하고, 롤백할 클라이언트 버전 목록을 싣고 새 릴리스가 나올 때마다 갱신한다
· 모든 EL·CL 클라이언트 팀: 후디 포크 일정을 제거한 새 릴리스를 낸다
· Fredrik, Francesco, Toni와 보안 연구자들: 다음 주 ACDT에서 영향 분석 결과와 분석 일정표를 발표한다

콜 페이지에서 전체 보기 → https://ethcollective.xyz/calls/acde-248

연기된 글램스테르담을 두고 상태 가스 설계 철학과 ACD 프로세스 논쟁이 벌어졌다

이번 호 인사이트
· 가스 리프라이싱 논쟁은 일정 문제를 지나 배포된 컨트랙트에 대한 약속 문제가 됐다
· Hoodi 연기가 ACD 의사결정 구조에 대한 공개 비판과 개편 제안을 불러왔다
· AI 에이전트가 포크 블로커의 영향 분석에 실전 투입되기 시작했다

프로토콜 업데이트
· EF 리서치, 에이전트 스웜으로 8037·8038 앱 레이어 영향 분석 착수
· Nethermind, 글램스테르담 블로커의 최종 수정을 Hegotá로 예고
· Besu, 상태 트리 마이그레이션 데브넷에서 Partitioned Binary Tree 루트 동기화 성공
· 형식검증된 이더리움 속성을 모으는 레지스트리 라이브러리 공개
· ACDE #249 아젠다 공지, 11월 5일 개최

포럼 제안
· EIP-8037 리저버 잔량을 읽는 RESERVOIR 옵코드 제안
· 직전 콜의 실패 원인을 구분하는 CALLSTATUS 옵코드 제안
· L2 내부에서 ECDSA를 제거한 해시 전용 롤업 공개
· 에이전트 안전 사양의 채택을 귀속 가능하게 만드는 ASF ERC 초안
· 제3자가 에이전트 신용 디폴트를 흡수하는 Agent Credit Backers ERC 초안
· ethresear.ch 주간 라운드업

트위터 논쟁
· 상태 가스 리프라이싱이 상태 성장을 해결하는지를 두고 lightclients와 EF 리서처들이 갈렸다
· 설계자들이 이더리움을 쓰지 않는다는 비판에서 ACD 프로세스 개편론까지 이어졌다
· Unchained의 ETH 수급 기사를 두고 Laura Shin과 lex_node가 갈렸다
· 커뮤니티 활동을 공개적으로 추진하는 방식을 두고 binji_x와 비판자가 갈렸다

주요 발언
· shemnon, '클라이언트 팀이 후원하지 않는 EIP는 진전시키지 말아야 한다'
· dankrad, '완전한 상태 만료의 UX 비용보다 상태가 10배 커지는 쪽을 감수하는 편이 낫다'

전체 요약 보기 → https://ethcollective.xyz/news

L2는 여전히 이더리움을 확장하고 있는가. 스타크웨어, 아비트럼, 옵티미즘 패널 정리

- L2를 이더리움의 "브랜드 샤드"로 보던 그림이 현실에선 안 통했고, L1은 예상보다 빨리 확장된 반면 L2 탈중앙화와 상호운용성은 더딤.

- 세 팀 모두 앞으로도 L2가 L1보다 훨씬 큰 확장을 제공할거라 생각. gas, tx만 봐도 L2 전체가 이더리움보다 훨씬 많이 처리 중.

- Stage 2는 더 이상 절대 목표가 아님. L2BEAT보다 검열 저항성 같은 실질 속성을 원한다는 입장. 오프체인은 엄밀히 따지면 이더리움 자체도 L1 기준을 못 맞춘다고 지적...;

- 옵티미즘은 일부 파트너가 Stage 2를 추진하는 건 탈중앙화 자체보다 정부가 체인 업그레이드 같은 걸 요구할 때 "우리는 아예 못 한다"는 방어 논리가 필요해서임.

- 오프체인은 L2의 진짜 장점을 거버넌스 주권으로 봄. 각 체인 커뮤니티가 원하는 걸 스스로 정하는건 모놀리식 설계로는 불가능. 스타크웨어는 집단의 거버넌스를 코드로 압축하겠다는 건 환상이라고...

- L2가 가치만 빼먹고 blob 수수료는 쥐꼬리만 낸다는 비판에 대해서... 스타크웨어는 이게 의도된 설계라고 강조. blob 자체가 L2 비용을 낮추려고 만든 건데 가치 환원까지 바라는 건 말이안된다는 의미임... 대안으로 바이백, L2 스테이킹 연결을 제시함.

- 아비트럼 스택 체인들이 에스크로에 ETH 공급량의 1% 가까이, 100만 ETH 넘게 묶어두고 있음. L2가 20배 크면 ETH의 20%가 묶이는 구조. ETH를 네이티브 가스 토큰으로 쓰는 게 가장 큰 기여.

- 옵티미즘은 유통망을 강조함. L2 위에 짓는 기업들의 고객 확보 능력이 결국 ETH 보유자와 사용자 수로 돌아옴.

- 초기 업계는 보안과 사이퍼펑크 이념 중심이었는데, 사용자는 체인이 아니라 제품을 봄... 사실 시퀀서가 어디 있는지 아는 사람도 거의 없음.

- L1 합의는 엄청 비쌈, L2로 짓는 게 경제적. 자체 L1은 통제권을 더 원해서지만 장기적으론 개방형 표준이 이긴다고 봄.

출처

ACDT #102 · 10월 26일
메인넷 포크를 앞두고 데브넷과 테스트 진행을 점검하기 위해 코어 개발자들이 모이는 테스팅 콜(ACDT)이다.

한 줄 요약
가스 리프라이싱 EIP인 8037과 8038이 배포된 컨트랙트와 예상 못 한 방식으로 상호작용한다는 보안 보고 때문에 후디(Hoodi) 테스트넷 포크가 최소 2주 연기됐다. 외부 감사 결과를 본 뒤 일정을 다시 잡고 스펙 변경은 최후 수단으로만 남겨 둔다.

결정된 것
· 후디 포크 일정을 최소 2주 미루고 감사 완료 후 재논의하기로 했다. EIP-8037/8038의 피해 범위 분석이 끝날 때까지 테스트넷 업그레이드는 멈춘다.
· 빌더 온보딩 수정안(consensus-specs PR #5736)이 승인돼 이번 주에 병합된다. 포크 시점에 0x0B 접두사가 명시된 예치만 빌더로 처리한다. 예치하면 반드시 검증자가 생긴다는 스테이킹 프로토콜의 불변식을 지킨다는 뜻이다.
· GetPayload 타임아웃 정의가 제거됐다(execution-apis PR #958 병합 완료). 실행 계층(EL)은 더 좋은 블록을 기다리지 말고 요청이 오면 즉시 응답해야 한다는 뜻이다.
· 쇼터 슬롯(shorter slots)은 피처 브랜치로 남기고 과반 클라이언트가 동의하기 전에는 헤제(Heze) 본 스펙에 병합하지 않기로 했다. 슬롯 단축 제안은 아직 정식 스펙에 들어가지 않는다.

일정
· ACDT #103은 11월 9일에 열린다. 데브콘(Devcon) 때문에 11월 2일 콜은 건너뛴다. 확정.
· EIP-8037/8038 피해 범위 감사 보고서는 10월 26일부터 약 2주 뒤 나올 예정이다. 확정 일정이 아닌 예상치(ETA)다.

왜 중요한가
이미 배포된 컨트랙트가 깨질 수 있다는 보고가 나오면서 글램스테르담(Glamsterdam) 테스트넷 일정 전체가 감사 결과에 묶였다. 8037을 포크에서 빼면 가스 한도를 안전하게 올릴 수 없어 BAL 같은 최적화가 무의미해진다는 지적이 나올 만큼 사용자와 L2 모두에 파급이 큰 사안이다.

ACDT #102 · 누가 무슨 말을 했나
보안 감사가 끝날 때까지 테스트넷 포크를 최소 2주 미룬다

EIP-8037/8038 보안 이슈와 후디 연기 · 일정 결정 00:24:42
가스 리프라이싱 EIP 두 개가 배포된 컨트랙트와 예상 못 한 방식으로 상호작용한다는 보안사 보고가 나와 후디 포크를 미룰지와 스펙을 고칠지가 논의됐다.

· Toni Wahrstätter (EF, 리서처): 하드코딩된 가스, 갑자기 늘어나는 gasLeft, 리펀드가 막혀 있던 실행 경로를 여는 문제 등 네 가지 이슈를 정리했다. 피해 범위는 꽤 파악됐지만 후디 일정은 최소 1주 미루고 논의를 이어가자고 했다.
· Fredrik: ChainSecurity와 Dedaub에 종합 감사를 의뢰했고 보고서까지 약 2주가 걸린다며 확신이 설 때까지 기다리자고 권고했다.
· Maria Silva (EIP-8037 제1저자): 영향받는 컨트랙트를 찾아 팀에 연락해 자체 수정을 기본 경로로 삼되, 고칠 수 없고 피해 범위가 클 때만 최소한의 표적화된 스펙 변경을 고려하자고 했다. 스펙 변경은 비용이 크고 다른 컨트랙트를 또 깨뜨릴 수 있다는 이유다.
· Łukasz Rozmej (Nethermind, EIP-8037 공동 저자): 어느 길이 맞을지 모르니 스펙 변경과 비변경 두 경로를 병행 탐색해 두자고 했다. 자신의 스펙 변경 PR은 여러 AI 모델이 서로의 허점을 찾게 하며 12시간 이상 다듬은 결과라고 설명했고 Maria Silva가 이를 불변식별 표적 수정으로 쪼개는 데 동의했다.
· Francesco D'Amato (EF, 리서처): Sourcify에 검증된 모든 컨트랙트를 스캔하는 등 종합 분석을 했는데 알려진 이슈를 빠르게 찾은 뒤 이틀간 의미 있는 발견이 없었다며 스펙 변경 가능성은 매우 낮다고 봤다. (채팅)
"다시 강조하면, 지금으로서는 스펙 변경이 필요해 보이지 않는다." (Toni Wahrstätter, 00:23:49)

getPayload 타임아웃 제거 · 확정 00:36:39
데브넷에서 일부 EL 클라이언트가 더 비싼 블록을 만들려고 getPayload 응답을 미루다 타임아웃이 반복되자, 타임아웃 정의 자체를 없애고 즉시 응답을 요구하는 변경을 두고 논의했다.

· Daniel Lehrner: 더 가치 있는 블록을 만들려고 일부러 기다린 것은 맞지만 이번 논의로 그게 의도된 동작이 아님이 분명해졌다며 이제 스펙이 명확해졌다고 했다.
· Fabio: FOCIL이 들어오면 빈 블록은 인클루전 리스트를 만족하지 못해 무가치하므로, 첫 응답에 최소한 인클루전 리스트 트랜잭션은 담아야 해 약간의 지연이 생길 수 있다고 지적했다.
· Nico Flaig (ChainSafe, Lodestar): 빌더가 설정돼 있으면 CL이 getHeader 응답 이후에 getPayload를 불러 EL에 최대한의 빌드 시간을 줄 수도 있다며 EL의 기대 동작이 스펙에서 충분히 명확한지 물었다.
· Dustin Brody (Nimbus): 데브넷에서 Reth의 일관된 getPayload 타임아웃을 봤는데 버그인지 스펙이 허용하는 동작인지 구분할 수 없었다며 어느 쪽이든 의도를 명확히 하는 이 변경이 유용하다고 했다.
· Potuz (Offchain Labs, Prysm): 이 변경이 Prysm의 FCU 타이밍을 깨뜨릴 수 있다고 우려했고 FOCIL과 쇼터 슬롯이 이 상호작용과 함께 더 깊이 검토되길 바란다고 했다. (채팅)
"우리는 더 가치 있는 블록을 만들려고 일부러 기다렸지만, 논의를 거치고 보니 그게 우리가 해야 할 일이 아니었던 것 같다." (Daniel Lehrner, 00:33:15)

페이로드 가스 한도 고시프 체크
ePBS에서는 무효 페이로드를 퍼뜨리기 쉬워지기 때문에, 합의 계층(CL)이 고시프 단계에서 트랜잭션 수를 가스 한도 기준으로 미리 걸러내자는 제안이 나왔다.

· Nico Flaig (ChainSafe, Lodestar): 비드의 가스 한도를 최소 트랜잭션 가스로 나눠 페이로드의 최대 트랜잭션 수를 제한하고 고시프와 역직렬화 단계에서 일찍 거부하자고 제안했다. P2P 계층을 단단하게 만드는 방법이라고 했다.
· Justin Traglia (EF, 보안): 체크 자체는 아주 기본적인 것이라 지지하지만 CL에 최소 트랜잭션 가스를 정의해야 하는 점이 유일한 불만이라고 했다. 스펙에 넣어야 거부(reject)와 피어 다운스코어링이 가능하다고도 덧붙였다.
· Toni Wahrstätter (EF, 리서처): 최소 트랜잭션 가스는 포크마다 바뀌고(글램스테르담 이전 21,000, 이후 12,000) 프레임 트랜잭션으로 또 바뀔 텐데, CL이 EL 상수를 알아야 하는 결합은 근본적으로 잘못됐다며 반대했다.
· Potuz (Offchain Labs, Prysm): Toni의 우려에 대한 절충으로, EL과 일치할 필요 없는 아주 낮은 보수적 하한(예: 1,000 미만)을 쓰면 자주 고칠 필요 없이 최악의 DoS는 막을 수 있다고 제안했다.
"CL이 갑자기 최소 트랜잭션 가스 값을 알아야 하는 식으로 EL과 CL을 결합하는 것은 내게는 근본적으로 잘못됐다고 느껴진다." (Toni Wahrstätter, 00:52:12)

쇼터 슬롯 스펙 병합 전략 · 확정 01:04:15
쇼터 슬롯 구현이 PR 3개에 흩어져 어떤 커밋을 테스트 타깃으로 삼을지 혼란스러워지자, 헤제 본 스펙에 병합할지를 두고 공방이 벌어졌다.

· Barnabas Busa (EF DevOps): 퀵 슬롯 구현 PR이 3개나 열려 있어 테스트 타깃이 혼란스럽다며 다음 데브넷이 겨냥할 스펙을 병합해 두는 쪽을 선호했다. 안정된 스펙 버전 없이 SFI가 먼저 나오는 것은 비현실적이라고 봤고 나중에는 슬롯 시간을 6/12초 그대로 두고 병합하면 아무것도 깨지지 않는다고 제안했다.
· Potuz (Offchain Labs, Prysm): 포함이 확정되지 않은 피처는 메인 스펙 밖에 둬야 하고 테스트에 병합이 필요한 것도 아니라며 Barnabas에 반대했다. 피처 작성자가 데브넷용 태그를 제공하면 되고 그 태그가 메인 브랜치에서 나올 필요는 없다고 했다. 미니멀 스펙 시간을 바꾸면 Prysm 테스트가 깨진다고도 지적했다.
· Matthew Keil (ChainSafe, Lodestar): 쟁점은 기계장치 자체가 아니라 슬롯 시간을 바꾼 채 병합하는 것이라며 메인넷 12초와 미니멀 6초를 그대로 두면 반대가 크게 줄어든다고 했다. 미니멀 시간 변경이 테스트를 깨뜨린다는 Potuz의 지적에는 동의했다.
· Justin Traglia (EF, 보안): 과반 클라이언트가 헤제 스펙 병합에 동의할 때까지 피처로 남겨야 하며 SFI가 병합의 전제는 아니지만 폭넓은 클라이언트 지지가 필요하다고 정리했다. 결정은 디스코드와 ACDC로 넘겼다.
"포함이 예정되지 않은 것들은 메인 스펙 밖에 두고 싶고, 테스트하기 위해 병합이 필요하다고 생각하지 않는다." (Potuz, 00:59:04)

남은 것
· Sam: 백필 중에는 엔벌로프 서명을 검증할 수 없다는 점을 명시하는 consensus-specs PR을 연다.
· Nico Flaig: MIN_TRANSACTION_GAS 상수를 사용한 GetPayload 트랜잭션 수 고시프 체크 consensus-specs PR을 연다.
· 전체 팀: 향후 비슷한 보안 돌발을 줄이기 위한 프로세스 개선안인 PM PR #2284를 검토한다.

콜 페이지에서 전체 보기 → https://ethcollective.xyz/calls/acdt-102

ZK 2026

https://www.succinct.xyz/2026-zk-industry-report

가스 리프라이싱 수습 경로가 정해지는 사이 코어 개발 자금 조달 논쟁이 전면화됐다

이번 호 인사이트
· 가스 리프라이싱 수습의 기본 경로가 영향받는 컨트랙트의 자체 수정으로 잡혔다
· EF 자금 축소를 배경으로 프로토콜 내장 개발자 펀딩 논쟁이 전면화됐다
· 토큰화 주식이 발행 단계를 지나 담보와 유동성의 금융 구조로 들어갔다

프로토콜 업데이트
· Sepolia에서 EIP-8025 실행 증명 프루버 가동, 블록당 6~7초 증명
· EIP-7002 인출 요청 컨트랙트의 핵심 속성 Lean 4 기계 증명
· nero_eth의 EIP-8037 점검 요청, 가스가 트랜잭션 중간에 되돌아오는 세 가지 문제
· EF App Enablement, 앱 레이어 팀의 로드맵 의견 수렴과 CROPS 설계 연구

포럼 제안
· 합의 레이어 P2P의 양자내성 마이그레이션 인벤토리
· 블라인드 서명 공격을 막는 트랜잭션 검증 표준 STVA 드래프트
· EIP-4844 포인트 평가를 묶어 검증하는 배치 KZG 기법 제안
· EIP-8297 바이너리 트리 상태의 물리 스토리지 설계 비교
· 전자여권 기반 1인 1표 암호화 투표 설계 Proof of One
· CALLSTATUS 옵코드 번호 이동
· 이번 주 ERC 드래프트 5건

트위터 논쟁
· 프로토콜 내장 개발자 펀딩을 두고 lightclients와 lex_node가 갈렸다
· 코어 개발 추가 자금의 긴급성을 두고 lightclients와 trent_vanepps가 갈렸다
· ETH가 가치저장 자산이어야 하는지를 두고 lex_node와 Tim Beiko가 갈렸다
· 리프라이싱이 OP 스택을 다시 깨뜨린 책임을 두고 donnoh_eth와 nero_eth가 갈렸다
· 탈중앙화가 비즈니스 모델이 될 수 있는지를 두고 binji_x와 lex_node가 갈렸다

주요 발언
· Barnabé Monnot, '예산 제약을 풀어주는 것은 어려운 선택을 돕지 않는다'

전체 요약 보기 → https://ethcollective.xyz/news

ACDC #190 · 10월 29일
합의 계층(CL) 클라이언트 개발자들이 격주로 모이는 콜이다.

한 줄 요약
헤고타 포크의 범위 확정 작업이 이 콜로 마무리됐다. EIP-8015가 포함 확정(SFI)됐고 묶음 증명 전파 등 4건이 포함 검토(CFI)로 올라갔으며 예치 프런트러닝(front-running) 수정안 EIP-8205는 후보에서 제외(DFI)됐다.

결정된 것
· EIP-8015(비컨 상태 정리)가 헤고타 포함 확정(SFI)됐다. 비컨 체인 상태에서 쓰지 않는 데이터를 정리하는 작은 변경이다.
· 포크 이후 0x00 예치의 ETH를 소각할지, 잔액을 0x01 예치로 큐에 다시 넣을지(바르나바스 제안) 결정이 2주 미뤄졌다. 데브콘에서 논의해 다음 콜에서 확정한다.
· EIP-8334(묶음 증명 전파)가 헤고타 포함 검토(CFI)로 올라갔다. 증명 데이터를 묶어 보내 네트워크 대역폭을 줄이는 변경이다.
· EIP-8383(CL 블록 보관 기간 축소)이 헤고타 CFI됐다. 설정값 하나를 바꿔 노드가 옛 블록을 보관하는 기간을 줄인다.
· EIP-8148(검증자 맞춤 스위프 임계값)이 헤고타 CFI됐다. 검증자가 32에서 2048 ETH 사이에서 자동 출금 기준을 직접 정할 수 있게 한다.

일정
· 2026년 10월 30일 컨센서스 스펙(consensus-specs) 릴리스. 확정이 아닌 계획이다.
· 글램스테르담(Glamsterdam) 데브넷 출범을 2026년 11월 16일에서 20일 사이로 추정. 제안 단계다.

왜 중요한가
헤고타에 들어갈 후보 목록이 사실상 정해져 클라이언트 팀들이 구현과 데브넷 테스트에 착수할 수 있게 됐다. 묶음 증명 전파와 고속 페이로드 전파가 포함되면 가정용 노드의 대역폭 부담이 절반으로 줄고 큰 블록이 3배 빨리 퍼지는 효과가 시뮬레이션에서 확인됐다.

ACDC #190 · 누가 무슨 말을 했나
비컨 상태를 정리하는 EIP가 헤고타(Hegota) 포크에 확정 포함됐다

입찰 가십 명세를 어디까지 정할 것인가
빌더가 네트워크에는 높은 입찰을, 제안자에게는 낮은 입찰을 직접 보내는 버그를 고치는 두 PR이 경쟁해 어느 쪽을 명세에 넣을지 논의됐다.

· Justin Traglia (EF, 보안): 자신이 올린 PR5774는 제안자가 같은 빌더의 중복 입찰을 값과 무관하게 받도록 하는 것이라고 설명하면서 자신의 것보다 니코의 PR을 선호한다고 밝혔다.
· Nico Flaig (ChainSafe, Lodestar): PR5776은 최소 3% 증가와 0.001 ETH 하한으로 DOS를 막으면서 빌더가 인덱스 하나로 단계적 입찰을 할 수 있게 해 정직한 입찰도 좋아진다고 설명했다.
· Barnabas Busa (EF DevOps): 3% 같은 수치를 명세에 못 박지 말고 클라이언트 구현 세부사항으로 둘 수 없느냐고 물었다.
· Justin Traglia (EF, 보안): 클라이언트마다 기준이 다르면 빌더가 최저 기준에 맞춰 움직여야 하므로 일관된 명세가 필요하다고 바르나바스에게 답했다.
· Potuz (Offchain Labs, Prysm): 전역 가십 토픽을 과잉 명세하고 있다며 반대했다. 제안자는 어떤 입찰이든 받으면 되므로 제안자 쪽에서 해결되는 문제고 Prysm은 복잡한 버전을 구현하지 않을 가능성이 크다고 했다.
· Enrico Del Fante (Consensys, Teku): 클라이언트가 자체 필터링을 구현하면 가십 검증 레퍼런스 테스트와 실제 동작이 충돌할 수 있다는 부작용을 지적했다.
"우리는 이미 이 주제를 지나치게 복잡하게 만들고 지나치게 명세화하고 있다." (Potuz, 00:11:07)

포크 이후 0x00 예치, 소각이냐 재큐잉이냐 · 결정 2주 연기 00:34:21
EIP-8365로 0x00 검증자 생성을 막은 뒤 들어오는 예치금을 소각할지, 재활성화 경로를 남길지를 놓고 단순성과 자금 보호가 맞섰다.

· Barnabas Busa (EF DevOps): ETH를 소각하는 대신 잔액을 0으로 만들어 예치 큐에 다시 넣고 BLS-to-execution 변경으로 0x01 검증자로 재활성화하게 하자고 제안했다. 휴면 상태의 대량 스테이크가 한 에폭에 활성화되는 공격을 막기 위한 설계라고 했다.
· Potuz (Offchain Labs, Prysm): 제안에 완전히 반대하지는 않지만 예치를 그냥 버리고 소각하는 쪽이 확실히 더 단순하다고 했다.
· NC: 0x00 예치가 워낙 드물기 때문에 오히려 프로토콜을 단순하게 유지하자는 반대 논리도 성립한다고 했다.
· Kevaundray Wedderburn (EF, 응용 리서치): 포크 이후 예치자만 보호하는 셈인데 0x00 사용자가 적다는 것을 아는 만큼 지금 공지를 내면 되지 않느냐며 이 접근이 최선인지 의문을 표했다.
· Barnabas Busa (EF DevOps): 모든 검증자가 이더리움 블로그 공지를 읽는 것은 아니며 이미 기능을 폐기한 도구가 있어도 메인넷에서 0x00 예치가 계속 나온다고 케브에게 반박했다.
· NC: 지난 ACDC와 ACDT에서도 나온 주제라며 다음 논의에서는 반드시 확정되길 바란다고 했다. (채팅)
"피할 수 있다면 ETH를 소각하는 것은 정말 내키지 않는다." (Barnabas Busa, 00:28:35)

예치 프런트러닝, 지금 고치나 PQ에서 고치나 · DFI 결정 01:15:09
예치 프런트러닝 취약점을 EIP-8205로 지금 대비할지, 어차피 바뀔 PQ 예치 컨트랙트 재설계에 맡길지를 놓고 리도 측과 클라이언트 팀들이 맞섰다.

· Dima Gusakov (Lido): 프런트러닝은 실재하는 취약점이므로 CFI로 유지하고 PQ 예치 컨트랙트가 이 문제를 해결한다고 확인되는 시점에 떨어뜨리자고 제안했다. 지금 DFI하면 해결 약속 자체가 사라진다고 봤다.
· Kevaundray Wedderburn (EF, 응용 리서치): 현재 PQ 예치 컨트랙트 제안 두 가지, 즉 스테이커와 오퍼레이터를 분리하는 EIP-8413과 현행 유지안 모두 프런트러닝을 해결하지 못하고 하나는 유인만 줄인다고 지적했다.
· Barnabas Busa (EF DevOps): 이 문제를 프로토콜 차원에서 풀어야 하는지 모르겠다고 했다.
· Potuz (Offchain Labs, Prysm): 문제의 실재와 해법의 안전성에는 동의하지만 어차피 예치 흐름을 바꿀 PQ에서 해결하면 되는데 왜 지금 복잡도를 더해야 하는지 이해하지 못하겠다고 했다.
· Greg K (Lido): 포투즈에 동의하면서도 DFI되면 영영 해결되지 않을 위험이 있다며 최소한 PQ 예치 컨트랙트에서 반드시 해결한다는 코어 개발자들의 합의를 요구했다.
"이 문제를 해결해야 한다는 데 동의하고 어차피 예치 흐름을 바꿔야 한다면, PQ가 이것을 해결할 최적의 자리다." (Potuz, 01:11:01)

묶음 증명 전파와 포크 전환기 처리 · CFI 결정 00:55:19
디커플드 합의를 대비해 증명을 묶어 보내는 EIP-8334의 대역폭 효과와, 지금 증명 구조를 건드릴 가치가 있는지가 논의됐다.

· Sukun Tarachandani: 클라우드 데브넷에서 디커플드 합의 부하를 시뮬레이션한 결과, EIP-8334 없이는 가정용 노드의 송신 대역폭이 25Mbps 선을 넘어 약 40Mbps까지 치솟았고 4개 단위 묶음만으로도 대역폭이 절반으로 줄었다고 발표했다.
· Saulius Grigaitis (Grandine): 지금 단계에서 그렇게 중요해 보이지 않는다며 나중에 시간이 나면 다시 검토하자고 했다.
· Nico Flaig (ChainSafe, Lodestar): 일렉트라 때 증명 데이터를 바꾸지 않으려고 일부러 피해 갔다며 디커플드 합의 전에 증명 구조를 건드릴 가치가 있는지 의문을 제기했다.
· Sukun Tarachandani: 증명 데이터 자체는 바뀌지 않고 네트워크 계층의 바깥 객체만 바뀌는 순수 네트워킹 변경이라고 니코에게 답했다.
· Potuz (Offchain Labs, Prysm): 포크 전환 직후 몇 슬롯 동안은 옛 포맷과 새 포맷의 증명을 모두 가십해야 하므로 전환기 처리가 미묘할 것이라고 우려했다.
· Barnabas Busa (EF DevOps): 전환 2에폭 전부터 전환 후 1에폭까지 두 토픽을 모두 구독해 모두가 이전하도록 돕는 방식을 제안했다.
"모든 증명 데이터를 따로따로 반복해 보내는 대신 하나로 묶어 증명 데이터와 서명만 보내는 아주 단순한 아이디어다." (Sukun Tarachandani, 00:42:04)

남은 것
· CL 클라이언트 팀: 입찰 가십 PR5774와 PR5776을 검토하고 며칠 안에 어느 접근을 택할지 의견을 낸다.
· 바르나바스와 CL 팀: FOCIL 페이로드 재구축 모호성을 다음 ACDE 콜에 올려 EL 팀 의견을 받는다.
· PQ 리서치와 EF: PQ 예치 컨트랙트 설계자가 예치 프런트러닝 문제를 명시적으로 다뤄야 하며, 코어 개발자들이 이를 요구사항으로 확인했다.

콜 페이지에서 전체 보기 → https://ethcollective.xyz/calls/acdc-190

크립토 역사상 최악의 해킹 사건이 될 이번 바이낸스 해킹에 대해, 두 가지 이야기들이 X에서 존재하는 것 같아 정리해보았습니다.

1. EIP-7702는 해킹에서 어떠한 역할을 하는가

해커는 이더리움의 펙트라 업그레이드에서 도입한 EIP-7702를 활용해 바이낸스 핫 월렛에 악의적인 코드를 설치했고, 단일 트랜잭션을 통해 핫 월렛에 있는 대부분의 자금을 인출하였습니다.

이번 바이낸스 핫 월렛 뿐만 아니라 EOA에 대한 해킹 사건에는 항상 EIP-7702가 애용되는데, 이는 EIP-7702가 편하기 때문이지, EIP-7702 자체가 취약하기 때문이 아닙니다.

EIP-7702는 EOA에 코드를 설치하여, EOA를 스마트 계정처럼 사용할 수 있도록 만들어줍니다. 가장 대표적인 사용처는 배치 트랜잭션(batch transaction)으로, 한 번에 여러 개의 트랜잭션을 보낼 수 있도록 하는 기능이죠. 예를 들어 스왑을 하려고 할때 EVM에서는 스왑 전 토큰 사용을 승인하는 스텝이 존재하는데, 이 기능을 활용하면 승인과 스왑을 한 트랜잭션 안에 수행할 수 있습니다. 메타마스크, OKX, Ambire 등 EIP-7702을 지원하는 지갑을 쓰시는 분들 중에는 이 기능의 혜택을 받은 분들도 계시리라 생각됩니다.

다만 이 기능은, 지갑 키를 탈취한 해커한테도 유용하게 사용될 수 있습니다. 이번 바이낸스 해킹에서도 EIP-7702가 없었다면 해커는 모든 자산마다 최소 한 개의 트랜잭션을 날렸어야 했겠지만, 7702를 활용해 모든 자산을 한 트랜잭션으로 옮길 수 있었죠.

일반적으로 지갑에는 임의의 코드를 EIP-7702로 설치할 수 있는 기능이 존재하지 않으며, 바이낸스도 마찬가지였을 것이기 때문에, 이런 해킹은 지갑 키를 탈취한 케이스에만 유효합니다.

EIP-7702 도입 당시 ‘해커도 이 기능을 유용하게 쓸 수 있지 않냐’며 도입을 반대했던 여론도 있지만, 큰 관점으로 봤을때 전반적인 계정 추상화 과정에서 이런 부작용은 피할 수 없었던 걸로 생각됩니다. 지갑 입장에서 키를 탈취한 공격자와 실제 주인을 구분할 방법은 없으니까요.

이더리움의 다다음 업그레이드에서 EIP-8141이 도입되면, 이러한 상황이 더 나아질 수도 있지 않을까 싶습니다. 예를 들어, EIP-8141에서 파생된 EIP-7906은 트랜잭션의 실행 결과가 특정 조건을 만족시키지 않는다면 전체를 되돌리는 기능을 제공합니다. 만약 거래소 핫 월렛이 이를 활용하여 ‘특정 금액 이상인 이상 출금을 판단하는’ 기능을 갖춘 스마트 어카운트 기반으로 운용된다면, 만약 키가 해킹되더라도 그 영향을 제한할 수 있지 않을까 싶네요.

2. 아베에는 bad debt가 쌓였는가

해커는 탈취한 자금의 일부를 아베에 USDT 형태로 예치하고 검열 불가능한 자산인 ETH를 빌려갔습니다. 이를 두고 ‘아베에 bad debt가 쌓인 것 아니냐’해는 말들이 많은데, 이번 사건은 아베에 큰 영향이 있지 않은 것으로 보입니다.

대출 프로토콜에 Bad debt가 쌓인다는 것은, 프로토콜이 상환 가능한 것보다 많은 돈을 빌려줬을때 성립하는 이야기입니다. 그런데 이번 사례에서 해커가 아베에 맡긴 돈은 전부 정상이었죠. 해커가 돈을 값지 않더라도, 해커의 포지션은 ETH 가격 상승 시 청산을 통해 정상적으로 프로토콜에 흡수될 수 있습니다. 즉 이번 사건에서 대출자가 정상적으로 본인의 돈을 인출하지 못하게 되는 상황이 일어날 것으로 보이진 않습니다.

이는 이전 KelpDAO 해킹과는 사뭇 다른 모습입니다. 해당 사건에서는 무한 민팅된 자산을 담보로 잡고 돈을 빌렸기 때문에, 해당 자금을 청산하더라도 빌려준 돈만큼의 자금을 회수하지 못하는 bad debt가 발생할 수 있었죠. 결국 디파이 프로젝트들이 돈을 모으고 해커의 포지션을 강제청산하는 Defi United 프로그램을 진행한 것이었구요.

바이낸스의 말에 따르면 해킹 자금의 절반 이상이 동결되었으며, 사용자 자금은 자체 자금과 비상 기금 등으로 복구가 가능하다고 합니다.

근래 웹2와 웹3를 가리지 않고 수많은 소프트웨어 취약점들과 해킹 사건들이 터져나오고 있습니다. 각자 개인 지갑 및 기기들의 보안을 다시 한번 점검해보시기를 바랍니다. Stay safe

역대 최대 바이낸스 해킹이 이더리움에 동결 권한과 EIP-7702 보완이라는 숙제를 남겼다

이번 호 인사이트
· 역대 최대 해킹의 수습은 프로토콜 밖의 동결 권한과 L2 보안 카운슬이 맡았다
· EIP-7702 악용이 확인되자 하루 만에 프로토콜 차원의 보완 제안이 나왔다
· 양자내성이 연구 단계를 지나 클라이언트와 지갑의 제품 사양이 되고 있다

프로토콜 업데이트
· Gattaca의 신규 합의 레이어 클라이언트 Silver 발표
· 액티브 밸리데이터 81만 5천으로 2023년 9월 이후 최저

포럼 제안
· EIP-8476, EOA의 7702 위임을 영구 차단하는 옵트아웃
· 7702 위임 서명에 256블록 신선도 제한을 거는 초안
· 서명 없이 ZK 증명으로 인가하는 양자내성 설계
· STVA 연작, 범위 제한 권한 토큰과 재현 가능한 시뮬레이션 결과
· ERC-8478, x402 에이전트 결제의 수취인 검증
· ERC-8472 Stock Locates, 토큰화 주식 대차 조회 인터페이스

트위터 논쟁
· 미국의 북한 역해킹 주장을 두고 발언자와 보안 연구자들이 갈렸다
· 바이낸스 해킹에서 EIP-7702의 책임을 두고 decentrek과 binji_x가 갈렸다
· 이더리움 위 중앙화의 가치를 두고 ryanberckmans와 lex_node가 갈렸다

주요 발언
· dankrad, '완벽해 보이던 타원곡선에 작은 금이 갔다'
· Tim Beiko, '이더리움의 affordance는 에이전트에게 유별나게 강력하다'
· gluk64, '에이전트 시대의 금융 인프라는 서버 보안 가정에 기댈 수 없다'
· ercwl, '지난주 취약점은 다 들었는데 익스플로잇은 어디 있나'

전체 요약 보기 → https://ethcollective.xyz/news