The ticker is ETH
1.51K subscribers
1.24K photos
15 videos
3 files
1.22K links
이더리움 탐험대 채팅방 https://t.me/thetickerisethchat
Download Telegram
Forwarded from 마인부우의 크립토볼 (minebuu)
11월 3일 이더리움 데브콘에서 비탈릭과 Nico가 Kokahu 라이브 데모 예정

https://cfp.devcon.org/devcon8/talk/C39QAG/

Ambire wallet이 Kohaku sdk를 빠르게 통합했기 때문에 해당 월렛으로 데모를 진행할 예정인 것 같네요. 토네이도, 레일건, 프라이버시 풀 등 주요 기능들을 전부 보여줄 것으로 예상된다고 나와있습니다.

해당 뉴스 때문에 오늘 Ambire wallet의 WALLET 토큰 (+64%)과 Railgun의 $Rail (+8%)이 크게 상승 중

데브콘까지 2주 정도 남았는데 레일건쪽 트레킹하면 좋을것 같네요.

레일건은 이전에도 설명했지만 단순 전송뿐만 아니라 defi 활동들 스왑, 예치 등도 프라이버시하게 할 수 있는 프로젝트이고, 프라이버시를 지키면서도 범죄 주소나 트랜잭션에 연관되어 있지 않다는 것을 증명가능한 (PPOI) 프로젝트입니다.

Kohaku는 이런 프라이버시 기능들을 이더리움 지갑에 쉽게 탑재할 수 있도록 만든 SDK이고 코하쿠가 정식 출시하면 많은 지갑들이 탑재하면서 자연스럽게 코어 프라이버시 엔진인 레일건, 토네이도캐시 등의 사용이 증가하지 않을까 싶네요
❤6
연기된 글램스테르담을 두고 상태 가스 설계 철학과 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
👍2
Forwarded from 도리의 코인메모
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 모두에 파급이 큰 사안이다.
The ticker is ETH
ACDT #102 · 10월 26일 메인넷 포크를 앞두고 데브넷과 테스트 진행을 점검하기 위해 코어 개발자들이 모이는 테스팅 콜(ACDT)이다. 한 줄 요약 가스 리프라이싱 EIP인 8037과 8038이 배포된 컨트랙트와 예상 못 한 방식으로 상호작용한다는 보안 보고 때문에 후디(Hoodi) 테스트넷 포크가 최소 2주 연기됐다. 외부 감사 결과를 본 뒤 일정을 다시 잡고 스펙 변경은 최후 수단으로만 남겨 둔다. 결정된 것 · 후디 포크 일정을 최소 2주…
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
가스 리프라이싱 수습 경로가 정해지는 사이 코어 개발 자금 조달 논쟁이 전면화됐다

이번 호 인사이트
· 가스 리프라이싱 수습의 기본 경로가 영향받는 컨트랙트의 자체 수정으로 잡혔다
· 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배 빨리 퍼지는 효과가 시뮬레이션에서 확인됐다.
❤1
The ticker is ETH
ACDC #190 · 10월 29일 합의 계층(CL) 클라이언트 개발자들이 격주로 모이는 콜이다. 한 줄 요약 헤고타 포크의 범위 확정 작업이 이 콜로 마무리됐다. EIP-8015가 포함 확정(SFI)됐고 묶음 증명 전파 등 4건이 포함 검토(CFI)로 올라갔으며 예치 프런트러닝(front-running) 수정안 EIP-8205는 후보에서 제외(DFI)됐다. 결정된 것 · EIP-8015(비컨 상태 정리)가 헤고타 포함 확정(SFI)됐다. 비컨 체인…
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
👍4❤2👎2
역대 최대 바이낸스 해킹이 이더리움에 동결 권한과 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