마지막 실행 ACD에서 blob 대상 증가와 일부 다른 보조 제안자들이 CFI 상태로 이동되었습니다.
해당 제안들은 다음과 같습니다:
- EIP 7623 (호출 데이터 비용 증가)
- 이 EIP는 호출 데이터의 가스 비용을 높여 블록에 가능한 최대 호출 데이터 양을 낮추어 블록의 최대 크기를 줄입니다. 4844 이전에는 롤업이 데이터를 블록체인에 게시하는 방식이었기 때문에 호출 데이터 가격을 올리는 것이 실현 가능하지 않았지만, 이제 롤업이 blob을 게시하므로 호출 데이터 가격을 올려 최대 블록 크기를 제어할 수 있습니다.
- EIP 7762 (min_base_fee_per_blob_gas 증가)
- 이 EIP는 blob에 대한 작은 예약 가격(약 1센트)을 설정하여 가격 발견 속도를 높이도록 설계되었습니다. 컨트롤러 구현으로 인해 blob 가격이 2배씩 증가하는 데 거의 6개의 전체 블록이 걸리므로, 1 wei 대신 2^25 wei로 이 매개변수를 설정하면 컨트롤러가 빠르게 증가할 수 있습니다.
- EIP 7742 (CL과 EL 간 blob 개수 분리)
- 이는 주로 EL과 CL 간 적절한 관심사 분리를 유지하기 위해 blob 개수 변수를 적절한 위치에 배치하는 정리 작업입니다.
- EIP 7691 (blob 대상을 3에서 4로 증가, blob 제한은 6으로 유지)
- EIP 4844 수수료 컨트롤러는 3 대상, 6 제한과 마찬가지로 4 대상, 6 제한에도 잘 작동합니다.
반대 의견
통화 중과 솔로 스테이커들 사이에서 이러한 제안들에 대한 반대 의견이 있었습니다. 특히 솔로 스테이커들은 블록을 단독으로 제안하는 데 필요한 추가 대역폭에 대해 걱정했습니다. 그러나 위의 제안들을 살펴보면 이러한 우려가 근거 없어 보입니다. 사실 모든 제안이 함께 포함되면 블록의 최대 크기가 줄어들 것입니다. blob 대상을 늘리는 것이 blob 제한을 늘리는 것을 의미하지 않으며, 7623의 추가로 인해 블록 페이로드의 non-blob 부분의 최대 크기가 줄어들 것입니다.
또한 일부 솔로 스테이커들은 자신의 낮은 업로드 대역폭 속도에 대해 게시하면서 솔로 스테이킹을 위한 최소 검증기 요구 사항에 대한 논의가 있었습니다. 블록을 단독으로 제안하는 노드는 극소수이며, 이는 높은 기회 비용이 있습니다. 그럼에도 불구하고 이러한 우려를 진지하게 받아들여야 합니다.
반대 의견에 대한 대응
먼저, 크기가 x인 블록을 안정적으로 제안하는 데 필요한 대역폭은 얼마나 될까요? 제안자는 자신의 블록이 슬롯 시작 4초 내에 네트워크의 최소 40%에 도달하도록 해야 합니다. 블록은 P2P 네트워크를 통해 전파되지만, 이 전에 제안자가 이를 시드해야 합니다. 제안자는 N개의 피어에게 전체 블록을 보냅니다. 더 많은 수의 고품질 피어에게 보내면 블록이 타임아웃 전에 네트워크의 충분한 부분에 도달할 확률이 높아집니다.
그러나 기본 클라이언트 구현에는 지연 시간과 신뢰성 최적화가 매우 단순하다고 이해하고 있습니다. 다시 말해, 추가 대역폭을 사용하지 않고도 노드가 블록 전파 속도를 최적화할 수 있는 방법이 있을 수 있습니다.
그럼에도 불구하고 농촌 스테이커의 극히 열악한 연결은 미래에 병목 현상을 일으킬 가능성이 있으므로, 하드웨어 요구 사항과 마찬가지로 인터넷 연결 요구 사항을 설정하는 것이 중요합니다. 이 논의의 시작점으로 50MB/s 업로드 속도를 제안합니다. 오늘날 우리에게 그렇게 많은 대역폭이 필요하지 않지만, 롤업 로드맵의 목표는 블록당 64개의 blob까지 확장하는 것이므로, PeerDAS와 함께 오는 최적화에도 불구하고 향후 상당한 확장 여력이 있습니다. 또한 북미, 남미, 아시아, 유럽에서 소비자 인터넷 50MB 업로드 속도가 널리 사용되고 있으며, 아프리카에서도 상당한(훨씬 덜 포괄적이지만) 이 속도 범위의 액세스가 있습니다. 따라서 이 속도 범위는 지리적 분권화 수준을 유지하면서도 네트워크가 크게 성장할 수 있는 여유를 제공할 것입니다.
최소 예치(stake) 감소 제안
트위터에서 비탈릭은 노드를 실행하는 데 필요한 예치(stake) 금액을 낮추는 것을 제안했습니다. 이는 좋지 않은 아이디어라고 생각합니다. 예치(stake)에는 두 가지 이유가 있는데, 하나는 책임성(잘못된 행동에 대한 슬래싱)이고 다른 하나는 사이빌 방지(참여하려면 예치(stake)가 필요)입니다. 최소 예치(stake) 요구 사항을 낮추면 최종 확정을 위해 집계해야 할 서명이 이미 너무 많기 때문에 한계적으로 좋지 않습니다. 각 추가 서명은 매 epoch마다 집계해야 하는 또 다른 서명을 도입함으로써 네트워크에 비용을 부과합니다. 현재의 최소 예치(stake)가 적절해 보이며, 다음 하드포크에서 MAXEB 이후 노드 수가 크게 감소하기를 희망합니다. 또한 프로토콜 외부 솔루션을 통해 이미 솔로 스테이커가 훨씬 낮은 담보로 예치(stake)할 수 있습니다.
