비컨 상태를 정리하는 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