· Justin Traglia (EF, 보안): 리도 등 분산 밸리데이터 시스템이 지적한 문제를 CL 쪽에서 고치는 게 낫다고 입장을 바꿨다. 메인넷을 늦추지 않고 후디 이후 단기 데브넷에서 테스트하자고 제안했다.
· Dustin Brody (Nimbus): 이런 막판 변경이 바로 과거 사고들의 원인이었다며 반대했다.
· Potuz (Offchain Labs, Prysm): 강하게 반대했다. 단순해 보이는 합의 변경이 번번이 위험한 버그를 낳아왔다며 고치려면 후디와 메인넷을 모두 미루고 충분히 검토해야 하고 일정을 지킬 거라면 고치지 말아야 한다고 했다.
· Dima Gusakov (Lido): 포크 때 딱 한 번 호출되는 함수의 변경이라 데브넷 하나로 2~4일이면 테스트할 수 있다며 Potuz에게 반박했다.
· Matthew Keil (ChainSafe, Lodestar): 기술 검토보다 일정이 문제라고 했다. 데브콘과 연말 휴가 때문에 후디가 며칠만 밀려도 메인넷이 해를 넘긴다며 지연에 반대했다.
· Eitan Seri-Levi (Sigma Prime, Lighthouse): 우회책이 있으니 지연할 가치가 없다며 고치려면 지연이 불가피하다는 점에 동의했다. (채팅)
"무엇도 늦출 가치는 없다고 본다. 이것은 가설적인 공격이다." (Justin Traglia, 00:22:17)

· Toni Wahrstätter (EF, 리서처): 보존 기간을 3,533에서 14,299 에포크로 올리는 PR을 머지하겠다고 했고 14,299 에포크 동안 비최종성(non-finality)이면 네트워크는 이미 죽은 상태라 충분히 보수적인 값이라고 했다.
· Nico Flaig (ChainSafe, Lodestar): 보존을 더 줄이면 비최종성 구간에서 EL이 데이터를 프루닝(pruning)해 CL이 P2P로 페이로드를 제공하지 못할 수 있다고 우려했다. 다만 지금 당장 큰 문제는 아니라고 했다.
· Potuz (Offchain Labs, Prysm): Prysm은 데이터를 받자마자 블라인딩해 최종성까지 기다리는 변경이 쉽지 않다고 했고 비활성 누수로 비최종성 지속 시간의 상한을 계산해 EL 보존이 그 상한보다 길면 된다고 제안했다.
"14K 에포크 동안 비최종성이라면 네트워크는 죽어 있을 것이다. 이미 매우 보수적이고, 14K면 충분히 보수적이라고 생각한다." (Toni Wahrstätter, 00:34:34)

· Potuz (Offchain Labs, Prysm): 무엇을 포크 브랜치에 머지할지는 ACD 콜에서 정해야지 스펙 관리자의 2차 판단에 맡겨서는 안 된다고 했다. CFI는 포크에 싣는다는 뜻이 아니며 SFI 전에는 피처 브랜치에 둬야 한다고 주장했다.
· lightclient (Matt Garnett) (EF, geth): Potuz에 전적으로 동의했다. 포크 브랜치에 올리면 구현이 그에 의존하게 되고 매몰 비용 때문에 암묵적으로 수용된다며 메인 브랜치는 SFI된 것만 담아야 한다고 했다.
· Matthew Keil (ChainSafe, Lodestar): 퀵 슬롯은 특히 광범위한 합의가 없고 향후 슬롯 작업과 양자내성(PQ) 조율에 파급 효과가 있는데 메인 브랜치에 머지하는 것은 골키퍼 몰래 넣는 것 같다고 비판했다.
· Justin Traglia (EF, 보안): 타당한 지적이라며 대체로 동의했다.
· Maria Silva (EIP-8037 제1저자): 퀵 슬롯은 슬롯 시간을 12초로 되돌리기만 하면 되는, 되돌리기 쉬운 변경이라는 점에서 다른 프로토콜 변경과 다르다고 지적했다.
"골키퍼 몰래 공을 넣는 것 같은 느낌이고, 옳다고 느껴지지 않는다." (Matthew Keil, 00:48:37)

· Barnabas Busa (EF DevOps): 지난주 합의한 3개 클라이언트 기준이 충족됐다며 heze-devnet-2를 10초 슬롯으로 하자고 제안했다. 다만 버그 수정 PR 5743이 먼저 머지되고 스펙 릴리스가 나오는 게 낫다고 했다.
· Justin Traglia (EF, 보안): 수정 PR을 이번 주에 머지할 수 있느냐는 질문에, 퀵 슬롯을 이끄는 원 PR 작성자가 리뷰하길 원한다고 답했다.
· felipe: EL이 쓸 블롭 파라미터가 정해지지 않은 상태라며 ethrex만 스펙 PR 3703에 맞춰 구현했으니 모두 같은 값으로 정렬하자고 요청했다. 아니면 테스트를 옮기고 새 릴리스를 내야 한다고 했다.
· Spencer Taylor-Brown (EF, 테스팅): 뭄바이(Mumbai) 전에 hegota-devnet-0을 띄울 계획이 유지되는지 물었고 hegota-devnet-1의 EL 범위는 다음 월요일 콜에서 확정하자고 했다.
"지난주에 짧은 슬롯을 구현한 클라이언트가 3개가 되면 다음 데브넷에서 슬롯 시간을 줄이기로 했고, 3개에 도달한 것으로 보이니 devnet 2는 10초 슬롯을 제안한다." (Barnabas Busa, 00:45:59)

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

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

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

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

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

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

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

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

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

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

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

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

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

· 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)

· 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)

· 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)

· 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)