ACDC #189 · 누가 무슨 말을 했나

ACDC 189 · 누가 무슨 말을 했나 실행을 ZK 증명으로 검증하는 실험은 포크 밖에서 계속된다 빌더 온보딩 예치 경쟁 조건 수정 요청 · 수정 거부 결정 00:37:55 글램스테르담 포크 경계에서 빌더 예치가 검증자 예치금을 가로챌 수 있다는 문제를 리도가 제기했으나 배포 막바지라 수정이 거부됐다. · Dima Gusakov (Lido): 포크 시점 대기 예치 큐에 빌더(0xB0) 예치가 검증자 예치보다 앞서 있으면 검증자 예치가 빌더의 톱업이 되어 검증자가 아예 생기지 않는 제3의 결과가 발생하고 기존 앱 계층 보호 장치가 이를 감당하지 못한다며 간단한 스펙 수정을 요청했다. · Barnabas Busa (EF DevOps): 실제 문제라면 5 6개월 전에 제기했어야 했고 이미 세폴리아에 배포됐으며 후디도 일정이 잡혔다며 반대했다. 메인넷에만 적용될 수정을 라이브 프로덕션에 넣을 수는 없다고 했다. · Pavel (MixBytes): 여러 프로토콜의 우회책을 감사해 봤는데 전부 지나치게 복잡하고 로직이 많아 모니터링과 다중 감사가 필요하다며 보안 관점에서는 베이스 계층 수정이 더 쉽다고 디마를 지지했다. · Matthew Keil (ChainSafe, Lodestar): 결정을 미뤄도 마음이 바뀔 사람은 많지 않고 모든 팀이 이미 후디 릴리스를 잘랐다며 지금 경로를 바꾸기는 어렵다고 반대했다. · Cambridge: 일부 클라이언트만 이 변경을 적용하면 체인이 분기되므로 합의 파괴적 변경이라고 지적했다. (채팅) · Nico Flaig (ChainSafe, Lodestar): EIP-8282가 포크 이후에는 이 문제를 해결한다고 알렸다. (채팅) "당신은 지금 메인넷에만 적용될 수정을 라이브 프로덕션에 넣어 달라고 요구하는 것인데, 그런 일은 일어나지 않을 것이다." (Barnabas Busa, 00:30:20) EIP-8025 선택적 실행 증명의 CFI 여부 · DFI 결정 01:15:42 선택 기능인 실행 증명을 스펙 본류에 올리려면 CFI가 필요한데, 그 자격이 있는지를 두고 EL과 CL 개발자들이 맞섰다. · ignacio: EELS 팀 규칙상 메인 브랜치 업스트림에는 CFI가 필요하고 업스트림하면 1년째 이어 온 리베이스 부담과 PBT 등 다른 기능과의 조율 비용이 사라진다며 CFI를 요청했다. 16K 라인 PR 중 상태 전이 함수를 건드리는 것은 65줄뿐이라고 했다. · lightclient (Matt Garnett) (EF, geth): 브랜치 관리가 어렵다는 것은 코어 EIP를 거버넌스에 통과시킬 이유가 못 된다며 이그나시오에 반박했다. 이더리움의 다른 대형 기능들도 수년간 같은 과정을 견뎠다고 했다. · Iván Litteri (LambdaClass, ethrex 테크 리드): zkEVM 로드맵에 상당한 통합·테스트 작업이 필요해 클라이언트 팀들의 조기 약속이 있어야 한다며 CFI를 지지했다. 기능은 운영자에게 선택이지만 지원은 모든 클라이언트의 기본 기대치가 돼야 한다고 했다. · Manu: CFI 여부가 프리즘의 작업량을 바꾸지는 않지만 몇몇 팀이 이 EIP에 진지하다는 신호가 되므로 CFI에 약하게 찬성한다고 했다. 라이트하우스가 이미 unstable 브랜치에 머지한 것도 암묵적 지지라고 봤다. · Potuz (Offchain Labs, Prysm): 헤제(Heze) 메인 포크 브랜치 머지에 강하게 반대했다. 선택 기능이 더 이상 선택이 아니게 되고 이후 모든 포크의 모든 EIP 작성자가 이 변경과 호환돼야 하기 때문이라고 했다. · Mario Vega (EF, 테스팅, ACDT 진행): EL 스펙에서도 똑같은 문제라며 포투즈에 동의했다. 메인 브랜치에 머지하면 나머지 EIP 전부가 그것에 맞춰야 하므로 개발자들이 찬성하지 않는 한 사실상의 고착을 원치 않는다고 했다. "나는 이것을 메인 포크 브랜치에 머지하는 데 반대한다. 그 순간 선택 기능이 아니게 되고 우리가 하는 모든 포크와 모든 작업에 영향을 주기 때문이다." (Potuz, 01:13:24) EIP-7716 반상관 어테스테이션 페널티 · DFI 결정 01:37:06 다수 검증자가 동시에 다운될수록 페널티를 키워 클라이언트와 인프라 다양성을 유도하자는 제안이 헤고타 포함 여부로 논의됐다. · Oisin Kyne: 지난 5년 중 최악의 클라이언트 중앙화 상태로 3개 클라이언트 각각이 단독 장애만으로 라이브니스 문제를 일으킬 수 있다며 비활성 페널티를 최대 256배까지 가중해 분산을 유도하자고 했다. · Matthew Keil (ChainSafe, Lodestar): 제안 자체는 마음에 들지만 포크에 포함된 EIP 수가 걱정이라며 당장 확정하기보다 남겨 뒀다가 시간이 나면 막판에 넣자고 했다. · Łukasz Rozmej (Nethermind, EIP-8037 공동 저자): 큰 장애가 오기 전까지는 아무도 이 페널티를 체감하지 못해 행동이 바뀌지 않을 수 있다고 우려했다. · Ben Adams (Nethermind): 이미 DFI된 발행량 변경을 만약 하게 된다면 이 페널티와 MEV 번 같은 것들을 함께 묶어 가져와야 한다고 했다. · stokes: CFI의 기준은 강한 지지여야 하며 무관심은 CFI 사유가 아니라고 했다. 강한 지지가 들리지 않아 DFI로 정리했다. "CFI에는 강한 지지가 필요하다고 본다. 사실상의 무관심은 CFI가 되어서는 안 된다." (stokes, 01:36:10) EIP-8205 출금 자격증명 사전 등록 · 다음 콜로 보류 01:57:33 위임 스테이킹 예치를 노드 운영자가 프런트러닝으로 가로채는 오래된 취약점을 프로토콜 차원에서 막을지 논의됐다. · Dima Gusakov (Lido): 이더리움 스테이크의 대다수가 위임 스테이킹이고 비컨체인 출범 때부터 있던 문제라며 공개키와 출금 자격증명을 묶는 약속을 7002류 시스템 컨트랙트로 제출하고 4788로 증명하는 단순한 해법을 헤고타에 넣자고 했다. 스펙과 테스트, 컨트랙트 코드가 준비됐고 감사 비용은 리도가 대겠다고 했다. · meditationduck: ACK3는 위임 스테이킹 예치를 강화하므로 지지한다고 했다. 모든 위임 스테이킹 프로토콜이 이 EIP를 채택해야 한다는 점이 유일한 우려라고 했다. · Tomer Ganor: 0x02 전환은 문제를 풀지 못한다며 디마를 지지했다. 자금이 인출되고 다시 예치되면 결국 새 검증자를 배포해야 하므로 보안 관점에서 이 EIP가 많은 가정과 우회책을 단순화한다고 했다. · Matthew Keil (ChainSafe, Lodestar): 앱 계층 해법이 이미 존재하고 특정 이해관계자 집단을 위해 코어 프로토콜을 바꾸는 선례가 걱정된다며 반대했다. 다음 포크에서 PQ 키를 다루게 되니 PQ 예치 컨트랙트 재설계에서 한 번에 푸는 편이 낫다고 했다. · Greg K (Lido): 7분 발표로는 논의가 부족했고 지금 분위기가 DFI로 들리지도 않는다며 최종 결정을 다음 콜로 미루자고 요청했고 그대로 받아들여졌다. "요점은 합의 계층이 곧 스테이킹이라는 것이고, 이더리움 스테이크의 대다수는 위임 방식으로 스테이킹돼 있다는 것이다." (Dima Gusakov, 01:52:59) 남은 것 · stokes / EF: 클라이언트 릴리스가 정족수에 이르는 대로 후디 안내 EF 블로그 글을 게시한다 · CL 클라이언트 팀: EIP-8365 수정안(가드를 process deposit request로 이동, 포크 전 0x00 예치는 기존 규칙 적용)을 검토하고 1 2회 뒤 콜에서 재논의한다 · EL 스펙 / EELS 팀: CFI 없이도 장기 실험 기능을 지원할 수 있도록 EL 스펙 브랜치 프로세스 개선을 검토한다 콜 페이지에서 전체 보기 → https://ethcollective.xyz/calls/acdc-189