이더리움 업그레이드 심층 분석: Hegotá

Ethlabs가 Hegotá에서 우선순위를 두는 것과 그 이유.

이더리움의 방향성은 이더리움 위에서 구축하는 사람, 사용하는 사람, ETH를 보유한 사람, 또는 이더리움이 될 수 있는 미래를 믿는 모든 사람에게 중요합니다. 그 미래는 궁극적으로 매일 이더리움 위에서 구축하는 사람들, 애플리케이션, 커뮤니티에 의해 결정되겠지만, 네트워크 업그레이드는 프로토콜이 그들의 요구를 충족시키기 위해 진화하는 주요 방법 중 하나입니다. Hegotá는 Glamsterdam 이후 계획된 다음 이더리움 네트워크 업그레이드이며, 이 문서는 Ethlabs가 Hegotá에서 이더리움이 무엇을 우선순위로 삼아야 한다고 생각하는지와 그 이유에 대한 견해를 공유합니다.

Ethlabs는 설립된 지 8주 된 이더리움 및 ETH를 위한 비영리 R&D 연구소이며, 우리의 사명은 이더리움을 글로벌 경제의 결제 레이어로 만드는 것입니다. 우리는 실제 이더리움 사용과 프로토콜 개발 사이에 위치하며, 사용자, 지갑, 애플리케이션, 롤업, 기관, ETH 보유자, 연구자, 클라이언트 팀의 의견을 듣는 데 시간을 보냅니다. 때로는 온체인에서 구축하기도 합니다. 경기장에 참여하지 않고는 경기장을 만들 수 없기 때문입니다! 우리는 훌륭한 프로토콜 엔지니어링이 훌륭한 제품을 가능하게 하고, 훌륭한 제품이 프로토콜의 다음 방향을 결정하는 데 도움이 되어야 한다고 믿습니다.

Hegotá의 범위는 현재 이더리움의 개방형 기술 프로세스를 통해 초기 단계에서 형성되고 있으며, 아래 제안들은 많은 개인과 연구 및 클라이언트 팀의 작업을 반영합니다. 이 문서는 우리가 우선순위를 두는 것을 권장하는 사항과 아직 의견을 형성 중인 부분에 대한 투명한 기록입니다. 이는 다른 사람들이 평가하고, 도전하고, 개선하는 데 도움을 주길 바라는 입장이며, 앞으로 며칠 및 몇 주 동안 논의하고 더 많이 배움에 따라 이를 반복적으로 업데이트할 것입니다.

Hegotá 업그레이드를 위해, 제안된 모든 EIP를 고려할 때, 우리가 이더리움의 최우선 순위로 보는 영역은 다음과 같습니다:

1. 더 강력한 검열 저항성: 누구든지 자신이 누구인지, 이더리움을 무엇에 사용하는지에 관계없이 트랜잭션을 포함시킬 수 있어야 합니다.
2. 더 빠른 이더리움: 더 빠른 블록은 더 빠른 확인, 더 신선한 온체인 가격, 더 빠른 최종성을 의미합니다.
3. 네이티브 계정 추상화: 계정은 패스키, 후원 트랜잭션, 토큰으로 지불하는 가스, 배치, 더 강력한 프라이버시를 지원해야 하며, 포스트퀀텀 키로의 경로를 제공해야 합니다.
4. 지속적인 L1 확장: 애플리케이션은 수요 급증 시에도 저렴하고 예측 가능한 용량을 유지해야 합니다.

공개적으로 작업하는 것은 Ethlabs의 핵심 목표이며, 그래서 매주 업데이트를 작성하고, 이번과 같은 경우에는 매우 긴 기술 문서를 게시하여 우리의 생각을 공유합니다 😅. 또한 앞으로 몇 주 동안 하이라이트만 원하는 사람들을 위해 더 간결한 콘텐츠도 게시할 예정입니다. 다음 부분은 길고 기술적일 것입니다. 끝까지 읽으시는 분들께 행운을 빕니다!

가장 먼저: EIP 프로세스는 어떻게 작동하나요?

제안 자체를 살펴보기 전에 한 가지 중요한 점이 있습니다: Hegotá의 범위 지정 프로세스 2단계가 막 시작되었습니다. 첫 번째 단계에서는 FOCIL을 Hegotá의 헤드라이너로 선정했습니다. 8월 6일에는 비헤드라이너 EIP를 제안하는 마감일이 있었으며, ACD 프로세스는 이제 Hegotá 업그레이드 전체를 평가하는 단계로 넘어갈 것입니다.

아래 모든 EIP는 현재 PFI (Proposed for Inclusion) 단계에 있으며, 헤드라이너 프로세스를 거친 EIP는 예외입니다. EIP를 포함 제안하는 것은 허가 없이 가능하며, 대부분은 최종 업그레이드에 포함되지 않습니다.

구체적으로, 구현 작업이 진행됨에 따라 제안은 점진적으로 더 강력한 검토 및 최종 출시 가능성에 대한 확신 단계를 거칩니다:

• PFI (Proposed for Inclusion): 업그레이드를 위한 아이디어가 제안되었습니다. 이 단계는 허가가 필요 없으며 클라이언트 지원이나 최종 포함을 의미하지 않습니다.
• CFI (Considered for Inclusion): 클라이언트 팀이 제안을 검토했으며 프로토타입 제작 및 테스트를 진행할 의향이 있습니다.
• SFI (Scheduled for Inclusion): 구현 및 테스트가 계속 잘 진행된다는 가정 하에 포함시키려는 광범위한 의도가 있습니다.

이 프로세스가 어떻게 작동하는지 자세히 알아보려면 Tim Beiko의 간략한 설명 여기를 시청하는 것을 추천합니다.

정리: 이 글을 탐색하는 방법

우리는 Hegotá에 대한 EIP 우선순위에 대한 우리의 견해를 표현하기 위해 Forkcast의 티어 목록을 따릅니다. 결정을 최소화하기 위해 검토된 모든 EIP를 다음 네 가지 티어로 매핑합니다:

• [S-tier] 포함을 강력히 권장합니다.
• [A-tier] 구현 복잡성, 영향 분석 또는 채택과 같은 남아있는 장애물이 해결된다면 포함을 권장합니다.
• [B-tier] 가치가 있지만 이번 업그레이드에는 무리입니다.
• [D-tier] 현재 형태로 Hegotá에 포함하는 것을 권장하지 않습니다.
• [의견 형성 중] 이 EIP에 대한 의견을 아직 형성 중입니다.

이는 Ethlabs의 \권장 사항\임을 유의하시기 바랍니다. 우리는 각 제안을 주로 목적, 사양, 그리고 합리적인 구현 복잡성에 대한 이해 측면에서 평가하며, 더 확실하거나 직접적인 관련이 있는 경우(예: Frames 및 Quick Slots)는 예외입니다. 또한 프로세스가 진행됨에 따라 ethPandaOps, 테스트 팀 및 클라이언트의 평가를 기반으로 우리의 견해를 업데이트할 것입니다.

[CL]은 EIP가 합의 레이어 클라이언트에 영향을 미치고 [EL]은 실행 레이어 클라이언트에 영향을 미친다는 것을 의미합니다.

우리는 여러 EIP( FOCIL, Frame Transactions, Quick Slots 포함)의 공동 저자이며 관련되어 있습니다. 우리는 관련 여부와 관계없이 모든 EIP를 독립적으로 평가하기 위해 노력하지만, 우리의 입장을 평가할 때 이 점을 고려해 주시기 바랍니다.

요약

CL 순위

Forkcaster에서 이 특정 [CL] 순위를 반복해서 확인할 수 있습니다 여기.

EL 순위

Forkcaster에서 이 특정 [EL] 순위를 반복해서 확인할 수 있습니다 여기.

자, 그럼 지체 없이 Hegota 업그레이드에 대한 현재 우리의 견해를 전체적으로 제시합니다:

Hegotá를 위한 테마

0. FOCIL: 검열 저항성 강화

EIP-7805: FOCIL은 이미 SFI 상태이며 Hegotá의 헤드라이너로 확정되었습니다. Ethlabs 팀의 세 명의 멤버(Francesco, Barnabé, Julian)가 공동 저자 중 하나이며, 우리는 그 포함을 강력히 지지합니다. 결정이 이미 확정되었으므로 짧게 설명하겠습니다. 모든 사람에게 중립적인 체인만이 모든 사람을 위한 신뢰의 뿌리가 될 수 있습니다. 이것이 이더리움이 글로벌 경제와 그 안의 모든 개인을 위한 진정한 결제 레이어로 확장될 수 있게 하는 것입니다.

1. Quick Slots: 더 빠른 이더리움

이더리움의 12초 슬롯은 사용자 가치를 떨어뜨리는 지연 비용입니다. 따라서 우리는 Hegotá에 [CL] EIP-8198: Quick Slots [S-tier]를 포함할 것을 강력히 권장하며, 그 이유는 네 가지입니다:

1. 더 빠른 트랜잭션 확인으로 L1의 UX 개선.
2. L1의 온체인 마켓이 더 신선한 가격으로 운영되어 스프레드와 LP 경제성 개선.
3. 최종성과 빠른 확인 규칙이 슬롯 시간을 상속받으므로, 더 빠른 블록으로 둘 다 빨라져 이더리움과의 상호운용성이 개선됩니다.
4. 초당 더 많은 블록 제안자는 검열 저항성(경제적 검열 저항성 포함)을 증가시킵니다. 즉, 일정 기간 동안 블록을 비워두기 위해 지불해야 하는 금액이 늘어납니다.

이더리움의 독특한 탈중앙화를 유지하면서 더 빠르게 가는 것은 이더리움 블록스페이스의 가치를 높이며, 그 가치는 네트워크와 ETH에 귀속됩니다. 모든 감소는 즉시 사용자에게 전달되는 더 많은 가치입니다. 마지막으로, 더 빠른 블록은 애플리케이션 개발자들이 가장 많이 요청한 변경 사항 중 하나입니다.

지금 시작해야 하는 이유는 슬롯 시간 단축이 한 번에 끝나는 변경 사항이 아니기 때문입니다. 확장과 마찬가지로, 제공된 감소는 로드맵 약속보다 애플리케이션에 더 많은 확신을 줍니다. 6초 미만 슬롯으로 가는 길은 슬롯 시간을 변경 가능하게 만든 다음 반복적으로 변경하는 것에서 시작됩니다. EIP-8198은 작업을 두 가지로 나눕니다:

• 사양 및 클라이언트 코드에서 슬롯 시간을 더 쉽게 업데이트할 수 있도록 하는 일회성 리팩터링.
• Hegotá에서의 첫 번째 감소, 이후 로드맵이 진행되고 안전성에 대한 경험적 증거가 확보됨에 따라 후속 포크에서 추가 감소.

Hegotá는 일회성 비용을 지불하기에 적합한 포크입니다. Glamsterdam의 ePBS는 이미 슬롯을 재구성합니다. Hegotá는 합의 레이어에서 상대적으로 가벼운 포크이며, I*에서 분리된 합의로 인해 이 창은 닫힙니다. 따라서 일회성 리팩터링을 위한 CL 대역폭이 지금 사용 가능하며, 앞으로 여러 포크 동안 다시는 이렇게 사용할 수 없을 것입니다.

의미: 우리는 최소 2년 동안 12초를 유지하거나, 약 1년 후 Hegotá에서 10초를 적용하고, 그 다음 해에는 10초 미만을 적용하는 것 중 하나를 선택해야 합니다. 이 두 가지 감소는 이론적인 개선이 아닙니다. 이는 직접적으로 증가된 사용자 가치와 개선된 네트워크 경제성을 얻는 것입니다. 우리는 이제 시작할 때라고 생각합니다.

가장 흔한 반론

클라이언트 개발자 및 EF 프로토콜과의 예비 논의 중에 제기된 4가지 중요한 사항을 여기서 논의합니다:

1. 구현 복잡성: 밀리초 정밀도의 슬롯 타이밍은 ePBS 작업을 통해 이미 합의 사양에 병합되었으며, EIP-8198에 대한 CL 및 EL 사양 초안이 존재하며, 기본 수수료, 가스 한도 및 Blob 일정이 초당 동작을 유지하도록 재조정되었습니다. 남은 비용은 고정된 슬롯 시간을 가정하는 클라이언트 및 도구의 엣지 케이스와 테스트입니다. 일회성 리팩터링은 정확히 이 작업을 선행합니다. 이후 각 감소는 매개변수 변경입니다.

2. zkEVM 증명: 두 가지 주요 문제는 상대적 증명 시간과 일정한 증명 오버헤드입니다.

2.1 상대적 증명 시간은 슬롯 시간 중 증명에 할당된 비율과 슬롯 시간이 변경될 때 이 비율이 어떻게 변하는지를 측정합니다. 다음은 슬롯의 관련 순간에 대한 간략한 설명입니다. 현재 빌더는 이전 페이로드의 릴리스를 관찰하고 즉시 구축을 시작할 수 있습니다. 그런 다음 현재 비콘 블록은 현재 슬롯의 페이로드를 커밋합니다. 이 페이로드는 다음 비콘 제안자의 블록 릴리스 전에 증명되어야 합니다.

증명의 경우, 최소 상대 시간은 전체 슬롯에서 비콘 블록 릴리스의 지연 시간을 뺀 것입니다. 비콘 블록 릴리스의 지연 시간은 압축할 수 없지만 구조상 짧기 때문에 이 단계에서 근본적으로 우리를 제한하지 않습니다. 또한 최적화된 빌더가 페이로드가 구축되는 동안 공동 증명하여 비콘 블록 제안자가 승리 페이로드를 커밋하기 전에 증명을 시작할 수 있는 가능성도 있습니다.

2.2 zkEVM 증명은 일부 고정 오버헤드를 제외하고는 주로 블록 크기에 따라 선형적으로 확장됩니다. 더 빠른 슬롯은 고정 오버헤드가 더 자주 발생하여 동일한 처리량에 대해 더 많은 지연 시간을 추가함을 의미합니다. 주어진 지연 시간 예산 내에서 좋은 처리량을 여전히 얻을 수 있도록 해야 합니다. 여기서 우리는 두 가지 기회를 봅니다: 첫째, 엔지니어링 발전은 이러한 고정 작업의 지연 시간을 계속해서 줄일 것입니다. 둘째, EIP-7862에서 설명된 대로 상태 루트 계산을 지연시키면 증명의 더 많은 부분이 중요 경로 밖으로 이동하여 압축할 수 없는 작업에 대한 지연 시간 예산을 늘릴 수 있습니다. 이 두 기회의 수렴은 더 빠른 슬롯이 미래의 충분한 처리량 증가를 방해하지 않을 것임을 알려줍니다.

3. 포스트퀀텀 전환: 분리된 합의 접근 방식은 미래 합의 아키텍처와 관련하여 안정적인 것으로 간주될 만큼 충분한 지지를 얻었습니다. 분리는 블록 생성의 중요 경로 밖으로 최종성 투표를 이동시키는 것을 의미합니다. 특히, PQ 서명의 대규모 집계 및 관련 재귀적 STARK 메커니즘은 중요 경로 밖에 있게 됩니다. 블록을 생성하고 결과 체인의 헤드를 추적하기 위한 포크 선택 규칙을 얻기 위해 남은 것은 현재 512명의 검증자(아마도 256명)로 구성될 것으로 예상되는 소위원회입니다. 포스트퀀텀 서명 크기는 더 크지만, 제안된 10초 슬롯 시간 내에 전파하는 데 문제가 없으며 미래에는 더 짧은 시간에도 문제가 없을 것입니다.

4. 스마트 계약 및 인프라: 스마트 계약 및 인프라에서 슬롯 시간에 대한 의존도는 현재 조사 중입니다. 스마트 계약의 경우, 우리는 Sourcify와 협력하여 모든 검증된 계약에 대한 분석을 실행하고 있습니다. 우리는 EIP-4788: EVM의 비콘 블록 루트에 따라 저장된 과거 비콘 블록 루트에 대한 슬롯 시간 업데이트의 영향을 연구하고 있습니다. 인프라와 관련하여, 일화적으로 Etherscan은 슬롯 시간 변경이 더 많은 부하로 이어질 가능성이 있지만, 인프라는 작업 증명(Proof-of-Work) 시절의 가변 슬롯 시간에 구축되었기 때문에 많은 변경이 필요하지 않을 것이라고 언급했습니다.

2. 계정 추상화: UX, 보안 및 프라이버시 개선

이더리움과 그 광범위한 생태계는 네이티브 AA가 오랫동안 필요했으며, 이는 패스키 지갑, 후원 트랜잭션, ERC20 가스 결제, 트랜잭션 배치 등과 같은 UX 이점을 가져올 것입니다.

그러나 네이티브 AA로의 길은 특히 험난했습니다. AA는 클라이언트, L2, 지갑, RPC, 개발 도구 등 이더리움 스택의 모든 부분에 영향을 미치기 때문에 매우 다양한 이해 관계자의 동의가 필요하기 때문입니다. 이는 모든 AA EIP가 이더리움의 합의 기반 개발 프로세스를 통과하기 어렵게 만들 뿐만 아니라 EIP가 출시된 후 실질적인 채택을 달성하는 것도 어렵게 만듭니다.

따라서 우리는 Hegotá의 네이티브 AA 제안인 Frame Transactions을 A-tier에 배치합니다. 기술적으로 S-tier에 충분하지 않기 때문이 아니라, 해결하는 데 막대한 양의 조정이 필요한 실질적인 채택 위험을 고려해야 하기 때문입니다. AA 분야에서의 팀 배경을 고려하여, Ethlabs는 L2 및 지갑과 같은 이해 관계자와 협력하여 네이티브 AA의 성공적인 출시를 위해 Frame Transactions을 시장에 출시하는 데 중요한 역할을 할 계획입니다.

이제 Hegotá를 위한 구체적인 AA 제안에 대해 알아보겠습니다.

[EL] EIP-8141: Frame Transactions [A-tier]

우리는 EIP-8141: Frame Transactions이 이더리움의 네이티브 AA 시스템을 위한 최고의 후보라고 믿습니다. 다른 네이티브 AA 제안과 비교하여 Frames는 이더리움의 CROPS 임무와 독특하게 일치시키는 여러 바람직한 속성을 가지고 있습니다:

• 허가 없는 계정 혁신: 검증 로직은 EVM 코드에 의해 처리되므로, 개발자는 검증 로직의 화이트리스트를 요구하는 다른 일부 AA 접근 방식과 달리 원하는 모든 검증 로직을 자유롭게 개발할 수 있습니다.
• 프라이버시 프로토콜에 대한 일류 지원: 첫 번째 요점의 결과로, Railgun과 같은 프라이버시 프로토콜은 프레임 트랜잭션의 검증 로직을 처리하여 사용자가 오늘날처럼 중앙 집중식 릴레이어에 의존하지 않고 비공개 트랜잭션을 보낼 수 있도록 합니다. 이는 프라이버시 프로토콜을 훨씬 더 비공개적이고 검열 불가능하게 만듭니다.
• 포스트퀀텀 안전성: 프레임 트랜잭션은 이더리움의 광범위한 PQ 로드맵을 염두에 두고 개발되었습니다. 예를 들어, 프레임 트랜잭션은 서명을 집계할 수 있도록 명시적으로 설계되어, 개별적으로 각 서명을 검증하는 데 매우 많은 비용이 들 수 있음에도 불구하고 이더리움이 궁극적으로 PQ 서명에 대해 낮은 가스를 청구할 수 있도록 합니다.

Frame Transactions의 주요 약점은 또한 가장 큰 강점에서 비롯됩니다. 검증이 EVM 코드에 의해 처리되기 때문에 검증은 이제 고정 비용 대신 동적 비용을 유발하며, 이는 L2와 같은 높은 TPS 체인에 문제가 될 수 있습니다. 우리는 이 문제가 EIP-7819와 같은 프레임 트랜잭션 위의 추가 EIP 또는 ERC를 통해 해결될 수 있다고 낙관합니다. 여기서 트랜잭션은 검증 로직을 정적으로 표시하여 시퀀서가 필요한 경우 네이티브 코드로 검증을 "단축"할 수 있습니다. 또한 L2 및 EF와 협력하여 프레임 트랜잭션에 대한 벤치마크를 수행하여 성능 병목 현상을 식별하고 해결할 계획입니다.

[CL][EL] Frame Transactions 애드온

Frame txs의 기능을 기반으로 구축하는 확장으로 볼 수 있는 여러 EIP가 있습니다.

[EL] EIP-8250: Frame Transactions을 위한 키 기반 논스 [A-tier]

• 우리는 이 EIP를 개념적으로 EIP-8141: Frame Transactions의 일부로 생각하며, 함께 출시되어야 한다고 믿습니다.
• 이 EIP는 Frame 트랜잭션에 2D 논스를 도입합니다. 2D 논스는 계정이 멤풀에 병렬 트랜잭션을 보낼 수 있게 하고, 프라이버시 프로토콜이 널리파이어를 2D 논스로 저장할 수 있게 합니다. 이는 2D 논스가 읽고 저장하는 데 비용이 매우 적게 드는 특수 저장소이기 때문에 중요합니다. 따라서 프라이버시 트랜잭션은 오늘날처럼 일반 동적 저장소에 널리파이어를 저장하는 것에 비해 가스를 크게 절약할 수 있습니다. 이는 Glamsterdam의 저장소 재가격화(EIP-8037: 상태 생성 가스 비용 증가)의 맥락에서 특히 중요합니다.

[EL] EIP-8272: Frame Transactions을 위한 최근 루트 [B-tier]

• 이는 Frame 트랜잭션과 함께 프라이버시 프로토콜을 사용하는 경험을 향상시키는 또 다른 EIP입니다. 프라이버시 프로토콜은 검증 중에 최근 커밋먼트 루트에 액세스해야 하며, 일반 저장소에 저장하면 비용이 많이 들 뿐만 아니라 Frames의 공개 멤풀 규칙과 충돌할 수 있습니다. EIP-8272는 이러한 루트를 오래된 루트를 자동으로 제거하는 링 버퍼에 저장하는 시스템 계약을 노출하여 이러한 문제를 해결합니다.
• 우리는 이 EIP가 특정 사용 사례에 대해 Frames에 상당한 복잡성을 추가하고, 동일한 목표를 달성하는 더 일반적/우아한 방법이 있을지 확신할 수 없기 때문에 B-tier에 배치했습니다.

[CL] EIP-8369: FOCIL 자격을 위한 VOPS 프로필 [B-tier]

• 이 EIP는 Frames와 VOPS(유효성 전용 부분 무상태성) 간의 상호 작용을 다룹니다. VOPS는 멤풀 노드가 트랜잭션을 검증하기에 충분한 상태만 저장하여, (zkEVM으로 인한) 무상태성 세계에서도 멤풀이 검열 저항성을 유지할 수 있도록 하는 제안입니다.
• 우리는 이 EIP가 커뮤니티가 아직 완전히 합의하지 못한 특정 무상태성 비전에 강하게 연결되어 있기 때문에 B-tier에 배치했습니다.

[EL] EIP-7906: 상태 차이 Opcode를 통한 트랜잭션 어설션 [B-tier]

• 이 EIP는 트랜잭션 결과의 정적 감사 가능성을 향상시킵니다. 사용자는 이미 무엇이 발생해야 하는지 어설션할 수 있지만, 다른 것은 발생하지 않았다는 것을 어설션할 수는 없습니다. 상태 변경의 부재를 증명하려면 새로운 opcode가 필요합니다. 긍정적 어설션(예: WETH 잔액이 최소 1.5 증가)과 부정적 어설션(다른 상태 변경 없음)을 결합하면 사용자는 시뮬레이션 없이도 트랜잭션의 전체 효과를 구조적으로 제한할 수 있으며, 하드웨어 지갑이 명확한 수혜자 중 하나입니다.
• 복잡성을 고려할 때, 하드 포크에 포함시키는 것은 매우 결정적인 선택이 될 것입니다. 우리는 (a) 클라이언트 팀이 이 특정 EIP의 미묘한 차이와 영향을 실제로 이해하고, (b) 테스트 표면과 복잡성을 매우 잘 이해하는 경우에만 이 작업을 수행할 것을 제안합니다.

[EL] EOA 마이그레이션 [B-tier]

[EL] EIP-7851: 코드 제어 EOA 위임 [B-tier] 및 [EL] EIP-8151: 계정 코드 제한 ecRecover [B-tier]는 EOA가 스마트 계정으로 전환할 수 있는 방법을 함께 제시하는 짝을 이루는 표준으로 보는 것이 가장 좋습니다. 이 시나리오에서 EOA는 먼저 EIP-7702를 통해 스마트 계정에 위임합니다. 그런 다음 EIP-7851이 도입하는 opcode는 7702 위임을 영구적으로 만들어 루트 ECDSA 키를 비활성화합니다. 반면 EIP-8151은 ecrecover가 비활성화를 인식하도록 하여 이전 키가 Permit 스타일 흐름을 통해 자금을 빼내지 못하도록 합니다.

우리는 이 쌍을 B-tier에 평가합니다. 이는 EOA를 스마트 계정으로 마이그레이션하는 많은 접근 방식 중 하나일 뿐이며, 이 특정 접근 방식은 광범위한 검토나 지지를 받지 못했기 때문입니다. 특히, 이 접근 방식이 멀티체인 문제에 답하지 못한다는 점이 우려됩니다. 동일한 EOA가 L2에서 어떻게 마이그레이션됩니까? 사용자는 아직 존재하지 않는 체인을 포함하여 모든 체인에서 동일한 작업을 수행해야 하며, 이는 좋지 않은 UX로 이어질 것입니다. L2가 EOA 마이그레이션을 위한 "신뢰의 루트"로 L1을 활용할 수 있는 더 나은 접근 방식이 있을 수 있다고 생각하므로, 사용자가 모든 EVM 체인에 대해 한 번만 마이그레이션할 수 있는 접근 방식을 위해 A/S-tier를 유보합니다.

[EL] PQ 서명 체계 [A-tier]

Hegotá는 포스트퀀텀 서명에 대한 신뢰할 수 있는 경로를 설정해야 하지만, 커밋하기 전에 올바른 메커니즘을 확인해야 합니다.

• EIP-8355: ML-DMA 검증 추가 사전 컴파일을 통해 Frame Transactions과 함께 포스트퀀텀 계정 보안을 구체화합니다.
• 대안: 활성화하지 않고 PQ 지원을 사전 등록하거나, 나중에 PQ 키를 수용할 수 있는 파생 형식을 정의합니다.

[EL] EIP-7819: SETDELEGATE 명령어 [A-tier]

• 네이티브 AA가 Hegota에 도입될 가능성이 높으므로, 새로운 스마트 계정을 배포하는 비용을 낮게 유지하는 것이 중요합니다. 그러나 Glamsterdam에서 EIP-8037로 인해 계정 배포 비용이 실제로 더 비싸질 것입니다. EIP-7819를 사용하면 새 계정이 프록시 계약 대신 간단한 위임 포인터를 사용하여 생성해야 하는 새 상태의 양을 크게 줄여 배포 비용을 낮출 수 있습니다.
• 우리는 더 낮은 계정 배포 비용이 AA 채택의 마찰을 크게 줄일 것이라고 믿기 때문에 이 EIP를 A-tier에 배치했습니다.

3. 성능 엔지니어링: 지속적인 L1 확장

Glamsterdam은 이더리움이 R&D에 접근하는 방식에 전환점을 표시했으며, 프로토콜 설계와 클라이언트 작업 모두에서 성능을 일류 R&D 제약 조건으로 취급했습니다. 지연된 실행, 리소스 재가격화 및 많은 클라이언트 최적화 작업을 통해 지난 2년 동안 30M에서 (최소) 200M으로 확장할 수 있었습니다. 일반적으로 성능 작업은 우리에게 선택권을 제공합니다. 우리가 얻는 여유 공간은 확장, 슬롯 단축, 노드 요구 사항 낮추기 또는 이 모든 것에 사용될 수 있습니다.

오늘날 우리는 여전히 지속적인 확장이 필수적이라고 봅니다. 애플리케이션은 현재 가격뿐만 아니라 이더리움이 시간이 지남에 따라 예측 가능하게 블록스페이스 공급을 확장할 수 있는지 여부에 따라 구축할 위치를 결정합니다. 일관된 증가를 제공하는 것은 로드맵 약속만으로는 제공할 수 없는 확신을 제공합니다. 메인넷 용량은 또한 수요 급증을 처리하기에는 아직 상당히 부족합니다. 이더리움의 11번째 생일에는 일일 중간 기본 수수료가 약 0.1 gwei에 불과했지만, NFT 민트로 인해 한동안 10 gwei 이상으로 치솟았고, 중간 트랜잭션 비용은 약 $1에 도달했으며 90번째 백분위수는 $5를 넘었습니다. 따라서 Glamsterdam의 확장 추진은 Hegotá까지 계속되어야 합니다.

종합하면, 다음 EIP들은 Glamsterdam의 확장 모멘텀을 이어가면서 그 이면의 광범위한 원칙을 강화합니다. 성능은 클라이언트 작업과 프로토콜 설계 모두에서 일류 관심사로 남아 있어야 합니다.

[EL] EIP-8131 및 EIP-8279 [S-tier]: 데이터 재가격화 번들

Glamsterdam 이후, 다음으로 중요한 제약 조건은 페이로드 전파(payload propagation)입니다. 그 이유는 페이로드 바이트의 출처에 따라 가스 계산(gas accounting)에 일관성 없이 반영되거나 전혀 반영되지 않기 때문입니다. EIP-8131: 통합 트랜잭션 콘텐츠 플로어(Unified Transaction Content Floor)는 실행 전에 알려진 콘텐츠에 대해 기존 트랜잭션 플로어를 확장하는 반면, EIP-8279: 블록 접근 목록 바이트 플로어(Block Access List Byte Floor)는 실행 중 동적으로 생성되는 BAL 바이트를 다룹니다.

이러한 동적 계량(dynamic metering) 방식은 EIP-8279를 두 EIP 중 명백히 더 복잡하게 만듭니다. 하지만 우리는 이 둘을 하나의 묶음으로 생각할 것을 제안합니다. 함께 사용하면 트랜잭션과 관련된 바이트에 대한 일관된 회계 처리를 확립하여, 대부분의 일반적이고 데이터가 많지 않은 트랜잭션에는 영향을 주지 않으면서 최악의 경우 페이로드를 제한합니다. 이는 근본적인 리소스 회계 격차를 해결하고 추가 가스 한도 증가를 위한 길을 닦습니다.

[CL][EL] EIP-8146: 블록 접근 목록 사이드카(Block Access List Sidecars) [A-tier]

EIP-8146은 BAL을 페이로드와 별도로 전파하여 중요 경로(critical path) 자체를 개선함으로써 가격 재조정을 보완합니다. 이는 전파를 개선하고 실행 클라이언트(execution clients)가 상태 프리페칭(state prefetching) 및 사후 상태 루트 계산(post-state-root computation)에서 유리한 출발을 할 수 있게 해줍니다. 우리는 이것이 놓쳐서는 안 될, 쉽게 얻을 수 있는 최적화의 일종이라고 봅니다. 구현 작업은 주로 익숙한 CL 가십(gossip) 메커니즘이므로, 이는 특히 EL 중심으로 구성되고 있는 이번 포크에서 노력 대비 가치가 높은 EIP입니다.

기타 관련 EIP

[EL] CPSB 재조정(CPSB Recalibration) [A-tier]

• 매우 간단한 변경 사항이므로, 파이프라인에 유지하고 계획된 가스 한도 증가 및 상태(state) 및 실행 가스(execution gas)의 관찰된 사용량에 따라 필요하다고 판단되면 둘 중 하나를 포함할 것을 권장합니다.
• EIP-8368: 새로운 가스 한도를 위한 CPSB 재조정(CPSB Recalibration for New Gas Limit): EIP-8037에 대한 사전 계획된 후속 조치로, 상태 바이트당 비용(CSPB)이 가스 한도의 함수가 아닌 정적으로 만들어진 점을 보상합니다. 이는 순전히 구현 및 테스트 단순화를 위한 것입니다. 아이디어는 블록별 조정을 포크 시 필요한 경우 일회성 조정으로 대체하여 가스 한도가 증가함에 따라 상태 성장을 목표치로 유지하는 것이었습니다. 현재 CPSB가 150M 가스 한도를 기준으로 보정되었기 때문에, Hegotá에서 조정이 필요할 가능성이 높습니다.
• EIP-8372: 정규화된 상태 가스 한도(Normalized state gas limit): 여전히 EIP-8368의 상당히 최소한의 상위 집합으로, CPSB보다 더 세분화된 조정을 허용하여 상대적 가격 오류로 인해 상태 성장 목표 또는 일반 가스 목표가 미달되는 것을 보상합니다.

[EL] EIP-7862: 지연된 상태 루트(Delayed State Root) [B-tier]

• 명세는 간단하지만, 우리가 아는 한 클라이언트 구현의 복잡성은 잘 이해되지 않고 있습니다. 상태 루트는 코드베이스 전반에 걸쳐 있습니다.
• 경쟁력 있는 블록 생성(빠른 상태 루트 계산)에 대한 접근 장벽을 낮추는 데 어느 정도 이점이 있지만, EIP의 가장 실질적인 장점은 미래에 있다고 생각합니다(상태 루트 계산을 증명할 시간 확보).
• EL은 이미 Hegotá에서 무거운 쪽입니다.

[CL] EIP-8341: 부분 실행 페이로드 커밋(Partial Execution Payload Commitments) [D-tier]

• 거부를 권장합니다: 이점이 적고(상태 루트 계산을 약간 지연), 긴급하지 않으며, EIP-7862: 지연된 상태 루트로 대체됩니다(훨씬 더 많은 시간을 제공).

기타 EIP

이제 주제별로 느슨하게 그룹화된 나머지 EIP를 다룹니다. 일부 EIP에 대해서는 아직 의견을 형성 중입니다. 앞으로 며칠 및 몇 주 동안 클라이언트 팀 및 EIP 작성자로부터 더 많은 정보를 얻는 대로 이 문서를 업데이트할 것입니다.

Hegotá는 EL 중심의 하드 포크가 될 것으로 보이므로, 규율을 유지하고 EL 측 EIP에 대해 높은 기준을 적용할 것을 제안합니다. FOCIL 및 Quick Slots 외에는 Hegotá를 상대적으로 CL 라이트(CL-light)로 유지하는 것이 바람직하다고 생각합니다. 범위를 좁히면 대역폭을 보존하여 클라이언트 팀이 더 큰 아키텍처 전환을 준비할 여유를 가질 수 있습니다.

[CL] 발행(Issuance)

우리는 의도적으로 EIP-8363: 점감형 발행 소각(Tapered Issuance Burn)에 등급을 할당하지 않습니다. 발행은 핵심 개발자(core devs)가 단독으로 결정해야 할 사항이 아니라고 생각하며, 등급 목록은 핵심 개발자에 대한 명시적인 권장 사항입니다. 대부분의 EIP의 경우 ACD 프로세스가 잘 작동하는 이유는 결정이 주로 기술적이며 커뮤니티가 이를 효과적으로 핵심 개발자에게 위임했기 때문입니다. 발행은 커뮤니티 자체가 대략적인 합의에 도달해야 하는 통화 정책 문제라는 점에서 다릅니다. 핵심 개발자의 의견은 중요하지만, 공개 토론에 대한 입력으로서 중요합니다. EIP-8363을 다른 EIP와 함께 순위를 매기는 것은 이를 일반적인 ACD 결정으로 취급하는 것이며, 우리는 그래서는 안 된다고 생각합니다.

기술적으로는 EIP-8363에 따라 발행을 변경하는 데 가치가 있다고 봅니다. 이것이 해결하는 문제는 실제적입니다. 더 많은 ETH가 스테이킹됨에 따라 슬래싱(slashing)의 신뢰성이 약화되고, 높은 스테이킹 비율은 리워드가 대부분 희석을 상쇄함을 의미하며, 규모의 경제는 대규모 운영자와 개인 스테이커 간의 격차를 계속 벌리고 있습니다. 변경에는 효과의 불확실성부터 지분 분배 및 통화 정책 경화 시계 재설정에 이르기까지 위험도 따릅니다. Ansgar의 스레드는 양측을 제시하며 우리의 입장을 반영합니다. 우리 중 일부는 과거에 발행 변경을 주장해 왔으며 그 경로에 대한 확신을 계속 가지고 있습니다.

다른 모든 Hegotá 범위 지정 결정 이후에 발행 결정을 내릴 것을 권장합니다. 이는 커뮤니티 토론에 필요한 시간을 제공하고 범위 지정 프로세스 자체에서 주의를 분산시키는 것을 방지합니다.

[CL] 스테이킹 기능(Staking features)

스테이킹 개선은 가치 있을 수 있지만, 엄격히 필요하지 않은 경우 사용자 혜택이 인프라 전용 변경보다 우선되어야 합니다.

[CL] EIP-8015: 예치금 및 eth1data 필드 제거(Remove deposit and eth1data fields) [A-tier]

• 기술 부채에 대한 매우 간단한 정리입니다. EIP-7688: 순방향 호환 합의 데이터 구조(Forward compatible consensus data structures) 덕분에 관련 없는 필드의 Merkle 증명은 영향을 받지 않으므로 체인 소비자에게 영향이 없습니다.

[EL][CL] EIP-8237: 독립적인 CL/EL 동기화(Independent CL/EL Sync) [B-tier]

• ePBS가 도입한 비콘 블록과 페이로드의 분리를 기반으로 EL과 CL이 독립적으로 동기화할 수 있도록 합니다. 이것은 이더리움 클라이언트의 복잡한 부분을 단순화할 잠재력이 있다고 생각합니다.

[CL] EIP-8205: 출금 자격 사전 등록(Withdrawal credentials preregistration) [D-tier]

• 거부를 권장합니다. EIP가 위임 스테이킹의 실제 문제에 대한 프로토콜 내 솔루션을 제공하지만, 기존 예치 전 솔루션으로 충분하며 추가된 메커니즘의 복잡성은 현재 정당화되지 않는다고 생각합니다.

[CL] EIP-8148: 검증인을 위한 맞춤 스윕 임계값(Custom sweep threshold for validators) [D-tier]

• 거부를 권장합니다. EIP가 그 이점에 비해 너무 복잡하다고 생각합니다(새로운 시스템 계약, 새로운 실행 요청, CL 메커니즘). 이점은 주로 홈 운영자 풀에서 약간의 추가 통합을 장려하는 것이라고 봅니다. 지분이 분배되는 방식을 고려할 때 이것이 전반적인 검증인 통합에 큰 영향을 미치지는 않을 것이라고 생각합니다.

[CL] EIP-8375: ePBS 실행 리워드 의무 소각(ePBS Mandatory Burn of Execution Rewards) [D-tier]

• 거부를 권장합니다. 이것은 아마도 더 많은 사이드 채널링(side-channeling)으로 이어질 것이라고 생각합니다. 게다가 MEV 소각 전략에 대한 수년간의 논의는 광범위한 연구 합의에 도달한 제안으로 이어지지 않았습니다.

[CL] EIP-7716: 역상관 증명 패널티(Anti-correlation attestation penalties) [D-tier]

• 거부를 권장합니다. 스테이킹 인센티브에 대한 이렇게 상당히 큰 변화가 정당화된다는 명확한 증거가 충분하지 않다고 생각합니다. 게다가 스테이킹 인센티브는 분리된 합의(decoupled consensus)의 일부로 재작업될 가능성이 높습니다.

[CL] EIP-8333: 체크포인트를 에포크 경계 블록과 정렬(Align Checkpoint with Epoch Boundary Block) [D-tier]

• 거부를 권장합니다. 좋은 정리 작업이지만, 다가오는 대규모 분리된 합의 전환으로 연기하는 것이 가치 있다고 생각합니다.

[CL] EIP-8359: 비콘 블록 보고 필드(Beacon Block Reporting Field) [의견 형성 중]

[CL] 추가 양자 내성 준비(Further PQ-prep)

이러한 제안은 미래의 양자 이후(post-quantum) 전환에 앞서 남은 BLS 종속성을 줄입니다.

[CL] EIP-8365: BLS 출금 자격 폐기(BLS withdrawal credential retirement) [A-tier]

• 레거시 출금 자격을 폐기하여 프로토콜 단순화를 위한 발판을 마련하고 미래의 PQ 전환을 단순화합니다.
• 매우 간단하다는 점을 고려하여 지금 포함하는 것이 가치 있다고 생각합니다.

[CL] EIP-8367: 폐기된 BLS 검증인에 대한 잔액 종료(Balance sunset for retired BLS validators) [D-tier]

• 거부를 권장합니다. 대부분의 0x0 검증인은 EIP-8365: BLS 출금 자격 폐기가 활성화되기 전이나 후에 자격 증명 변경(BLSToExecutionChange)을 수행하여 자금을 인출하거나 계속 스테이킹할 가능성이 높다고 생각합니다. 남은 0x0 지분을 처리하기 위한 메커니즘을 도입하는 데 큰 긴급성이 있다고 생각하지 않습니다. EIP-8365만 포함하고 다음 단계를 결정하기 전에 그 결과를 지켜볼 것을 권장합니다.

[CL] EIP-8321: 해시 체인 RANDAO(Hash-Chain RANDAO) [D-tier]

• 거부를 권장합니다. RANDAO를 단독으로 양자 내성(post-quantum-safe)으로 만드는 것은 검증인 BLS 키가 취약한 상태에서 프로토콜 수준 보안을 거의 제공하지 못하는 반면, 검증인당 약 32바이트, 새로운 비밀 관리 메커니즘, 그리고 대부분 단일 목적 메커니즘을 추가합니다. 광범위한 PQ 합의 설계는 아직 결정되지 않았습니다. 우리는 점진적인 전환을 지지하지만, 첫 번째 단계는 최종 설계로 대체될 위험을 감수하기보다는 합의된 로드맵을 따라야 합니다.

[EL][CL] zkEVM 준비

대부분의 zkEVM 준비는 좁은 사용자 집합에게 풀 노드 운영을 더 쉽게 만드는 것 이상의 단기적 이점을 거의 제공하지 못하는 반면, 구현 대역폭을 소비하고 잠재적으로 EVM을 더 비싸게 만듭니다. 장기적 가치가 이러한 즉각적인 비용을 명확히 정당화하는 변경 사항만 포함해야 합니다.

[CL] EIP-8025: 선택적 실행 증명(Optional Execution Proofs) [D-tier]

• 이 EIP는 하드 포크를 필요로 하지 않습니다. Hegota와 함께 번들로 제공하자는 제안은 순전히 우선순위의 표현이며, 우리는 그 선택에 동의하지 않습니다. 이에 대한 작업은 계속되어야 하지만, Hegotá가 이로 인해 차단되어서는 안 됩니다.
• 선택적 증명을 출시하기 전에 먼저 최종 상태를 정의하는 방향으로 작업한 다음, 장기적인 검증인/상태 모델에 대한 명확한 비전 없이 선택적 증명을 출시하기보다는 그 방향으로 속도를 높여야 합니다.
• 핵심 미해결 질문은 상태와 관련하여 검증인이 어떤 역할을 해야 하는지입니다. 즉, 완전히 무상태(stateless)가 되기보다는 상태의 일부를 계속 제공하거나 보유해야 하는지 여부입니다. 검증인은 실제 하드웨어와 네트워크 가치를 가진 핵심 노드 코호트이기 때문에, 그 역할을 약화시키는 변경은 더 높은 기준을 충족해야 합니다.

[EL] EIP-7666: ID 사전 컴파일을 EVM화(EVM-ify the identity precompile) [A-tier]

• 유용하고 작은 변경

[EL] EIP-8200: EVM화(EVMification) [B-tier]

• EIP-8200은 세 가지 네이티브 사전 컴파일(precompile)을 동등한 EVM 바이트코드로 대체합니다. 두 가지는 거의 사용되지 않으며 마이그레이션이 간단해 보입니다. 세 번째는 SNARK 검증에 널리 사용되므로, 제거를 지지하기 전에 영향 평가를 원합니다.
• 영향 분석 결과 영향을 받는 사용자에게 마이그레이션 비용이 낮은 것으로 나타나거나 세 번째 사전 컴파일이 범위에서 제거되면 EIP-8200을 [A-tier]로 이동할 것입니다.

[EL] EIP-7709: 스토리지에서 BLOCKHASH 읽기 및 비용 업데이트(Read BLOCKHASH from Storage and Update Cost) [D-tier]

• 가스 비용이 매우 크게 증가하여 상당히 파괴적이며, 긴급하지 않습니다.
• 위험을 줄이기 위해 영향 분석을 수행하거나, 나중에 블록 수준 워밍(block level warming) 또는 이러한 값의 임시 워밍(ad-hoc warming) 형태로 수행하여 영향을 줄일 수 있습니다.

[EL] EIP-8268: 블록 접근 목록의 스토리지 루트(Storage Roots in Block Access Lists) [B-tier]

• BAL 크기에 대한 구체적인 영향 및 관련 트랜잭션 비용에 대한 분석이 필요할 수 있습니다(EIP-8279는 BAL 바이트에 대한 요금을 제안하고 있음). 접촉된 각 계정의 BAL 항목에 추가 스토리지 트라이 루트가 포함되기 때문입니다.

[EL] EVM 기능

Hegotá는 여전히 몇 가지 임시 EVM 결정을 필요로 할 것입니다. 우리는 Hegotá 이후 이더리움은 더 넓은 EVM 생태계에 의해 형성된 장기적인 EVM 로드맵을 위해 노력해야 한다고 믿습니다. Ethlabs는 이에 기여할 것입니다.

[EL] EIP-5920: PAY opcode [A-tier]

• 매우 간단하며, EVM이 갖추기에 좋은 기본 요소라고 생각합니다.
• 구체적인 사용 사례를 더 잘 이해하는 것이 중요할 것입니다.

[EL] EIP-8163: EXTENSION (0xae) opcode 예약(Reserve EXTENSION (0xae) opcode) [A-tier]

• L2에 매우 유용하며, L1에는 실질적인 비용이 없습니다(단순 정보 제공).

[EL] 코드 재사용 / 중복 제거(Code reuse / deduplication) [B-tier]

• EIP-8058: 컨트랙트 바이트코드 중복 제거 할인(Contract Bytecode Deduplication Discount) 및 EIP-8298: SETCODEFROM 코드 재사용 명령어(SETCODEFROM Code Reuse Instruction)는 모두 컨트랙트 코드가 클라이언트의 해당 계정과 별도로 저장되고 코드 해시가 그 사이의 포인터 역할을 한다는 사실을 활용하려고 합니다. 따라서 동일한 공유 코드는 중복 제거되어 저장될 수 있습니다. 두 EIP 모두 다른 곳에 존재하는 코드의 해시로 계정 코드 해시를 저렴하게 설정하는 방법을 허용합니다.
• 우리는 이것을 매력적인 일반적인 아이디어로 간주하지만, 바이너리 트리에 대한 영향과 순방향 호환성을 이해하는 것이 중요할 것입니다. 현재로서는 둘 사이에 선호도가 없습니다.

[EL] 메모리 가격 개혁(Memory pricing reform) [B-tier]

• Hegota에서 메모리 개혁을 전혀 수행할지 여부를 결정해야 합니다. 현재 이 설계 공간에 대한 충분한 이해가 있다고 확신할 수 없습니다.

EIP-7686: 선형 EVM 메모리 한계(Linear EVM memory limits)

• 더 작은 변경으로, 2차 메모리 확장 비용(quadric memory expansion cost)을 없애는 것뿐입니다.

EIP-7923: 선형, 페이지 기반 메모리 비용 산정(Linear, Page-Based Memory Costing)

• 더 깊고 원칙적인 재작업이지만 더 복잡합니다.

[EL] EIP-8219: 검사된 산술 Opcode(Checked Arithmetic Opcodes) [B-tier]

• 전반적으로 EVM에 안전한 수학(safe math)을 추가하는 것이 유용해 보입니다.
• 가격 책정은 벤치마크를 통해 확인되어야 합니다. 얼마나 복잡한가요?
• 벤치마크와 영향 분석(얼마나 많은 트랜잭션이 혜택을 볼 수 있는지, 얼마나, 어떤 컴파일러가 지원을 추가할지?)을 통해 A-tier가 될 수 있습니다.

[EL] EIP-8360: TCREATE Opcode [B-tier]

• 이 EIP는 트랜잭션 범위의 임시 컨트랙트를 생성하는 기능을 도입합니다. 이는 일반적으로 갖추기 좋은 기본 요소입니다.
• EIP는 상당한 복잡성을 추가합니다. 더 철저한 구현 및 테스트 복잡성 평가를 통해 A-tier가 될 수 있습니다.

[EL] EIP-7645: ORIGIN을 SENDER로 별칭 지정(Alias ORIGIN to SENDER) [D-tier]

• 거부를 권장합니다: 변경 사항을 깨뜨리는(breaking change) 것이며, ORIGIN의 부적절한 사용입니다.

[EL] EIP-8182: 비공개 ETH 및 ERC-20 전송(Private ETH and ERC-20 Transfers) [D-tier]

• 거부를 권장합니다: 큰 변경이며, zk 종속성을 추가합니다. 만약 도입된다면, 헤드라이너가 되어야 한다고 생각합니다.

[EL] EIP-2488: CALLCODE opcode 폐기(Deprecate the CALLCODE opcode) [의견 형성 중]

[EL] EIP-4758: SELFDESTRUCT 비활성화(Deactivate SELFDESTRUCT) [의견 형성 중]

[EL] EIP-7979: EVM 호출 및 반환 Opcode(Call and Return Opcodes for the EVM) [의견 형성 중]

[EL] EIP-8173: EVM 제어 흐름의 기초(Foundations of EVM Control Flow) [의견 형성 중]

[EL] EIP-8253: 논스가 0인 스토리지 계정의 논스 증가(Bump nonce of zero-nonce storage accounts) [의견 형성 중]

[EL] EIP-8030: P256 알고리즘 지원(P256 algorithm support) [의견 형성 중]

[EL] EVM 가격 책정

Glamsterdam은 전체 처리량을 제약하는 저평가된 작업의 가격을 인상했습니다. Hegotá의 EVM 가격 책정 제안은 주로 다른 측면, 즉 현재 비용으로 인해 사용이 제한되지만 네트워크 확장성에는 영향을 미치지 않는 개별 작업의 가격을 낮추는 것을 다룹니다. 따라서 이는 EIP당 영향이 낮은 있으면 좋은 기능(nice-to-haves)입니다. 우리는 목표 지향적인 가격 재조정에 열려 있지만, 새로운 계량 메커니즘을 도입하는 제안은 설계가 건전하고 전담 챔피언에 의해 충분히 위험이 제거된 경우에만 포함되어야 합니다.

[EL] EIP-8358: 계정 변경에 대한 순 가스 계량(Net Gas Metering for Account Changes) [B-tier]

• 영향에 대해 확신이 없습니다. 샘플링된 900개의 메인넷 블록, 약 400k 트랜잭션에서: 전체 트랜잭션의 2.07%가 가스를 절약하고 블록 가스의 1.14%가 절약됩니다.

[EL] EIP-7973: 웜 계정 쓰기 계량(Warm Account Write Metering) [의견 형성 중]

[EL] EIP-7609: TLOAD/TSTORE 기본 비용 인하(Decrease base cost of TLOAD/TSTORE) [의견 형성 중]

[EL] EIP-7971: 임시 스토리지에 대한 하드 한계(Hard Limits for Transient Storage) [의견 형성 중]

[EL] EIP-3298: 환불 제거(Removal of refunds) [의견 형성 중]

[EL] EIP-8374: 되돌리기(Revert) 전반에 걸쳐 웜 액세스 세트 유지(Persist Warm Access Sets Across Reverts) [의견 형성 중]

[EL] EIP-8115: 블록 끝의 배치 우선 수수료(Batch priority fees at end of block) [의견 형성 중]

[EL] EIP-8188: 계정 및 슬롯에 대한 마지막 기록 블록(Last-Written Block for Accounts and Slots) [의견 형성 중]

[EL][CL] 실행 데이터 및 인덱싱

[EL][CL] EIP-7668: 블룸 필터 제거(Remove bloom filters) [의견 형성 중]

[EL][CL] EIP-7807: SSZ 실행 블록(SSZ execution blocks) [의견 형성 중]

[EL] EIP-8116: 누적 영수증 필드 교체(Replace cumulative receipt fields) [의견 형성 중]

[EL] EIP-8304: 무신뢰 로그 및 트랜잭션 인덱스(Trustless log and transaction index) [의견 형성 중]

[EL][CL] 네트워킹

이더리움의 P2P 레이어는 특히 트랜잭션, blob 및 증명이 네트워크를 통해 전파되는 방식에 있어 목표 지향적인 개선의 여지가 있습니다.

[CL] EIP-8371: RowDAS - 분산 Blob 재구성(Distributed Blob Reconstruction) [A-tier]

• 일반적으로 blob 수 확장을 위한 병목 현상으로서의 전체 재구성 및 전체 커스터디 노드 성능을 방지합니다.
• 가치 있으며, 결국 어떤 형태의 분산 재구성은 반드시 프로토콜에 포함되어야 합니다. 이를 통해 검증인 커스터디를 제거할 수 있습니다.
• 복잡성을 더 잘 이해해야 합니다.

[CL] EIP-8142: Blob 내 블록(Block-in-Blobs, BiB) [D-tier]

• 시기상조이며, 강한 긴급성이 없고, 매우 늦은 단계이며, 많은 질문이 남아 있습니다(KZG 여부? 새로운 가십 주제 여부?).
• 블록 생성의 중요 경로에 KZG를 도입하고 싶지 않으며, 대안은 불분명하고 추가 복잡성을 더할 것입니다.

[CL] EIP-8243: 소스에서 증명 일괄 처리(Batching Attestations at Source) [D-tier]

• 이것이 최종성 시간(time-to-finality)을 줄이는 데 의존할 수 있는지 불분명하며, 부하에 대한 명확한 제한을 두지 않습니다.
• 메커니즘의 DoS 저항성이 완전히 명확하지 않습니다.

[EL] EIP-8077: eth/XX - 논스로 트랜잭션 알림(announce transactions with nonce) [의견 형성 중]

[EL] EIP-8094: eth/vhash - Blob 인지 멤풀(Blob-Aware Mempool) [의견 형성 중]

[CL] EIP-8334: 번들 증명 전파(Bundled Attestation Propagation) [의견 형성 중]

만약 어떻게든 아직 저희와 함께 하고 계시다면, 끝까지 읽어주셔서 감사합니다. 질문이 있으시면 언제든지 답글을 남겨주시고, 최선을 다해 답변드리겠습니다! 만약 거대한 텍스트 벽을 꿰뚫어 보는 것이 일요일을 보내는 방법이 아니라고 생각하고 건너뛰어 여기까지 스크롤 내려오셨다면, 다음 부분이 간략하다는 사실에 기쁨을 느끼실 것입니다.

몇 마디 (더) ...

이더리움 업그레이드는 그만큼 이해관계가 높기 때문에 복잡합니다. 전 세계의 수천 개 노드가 동시에 새로운 규칙으로 전환되며, 그 과정에서 네트워크는 단 1초도 멈추지 않습니다. 그 엄격함은 이더리움이 출시한 모든 업그레이드를 지탱해 왔으며, 그 결과 11년 동안 100% 가동 시간을 자랑하는 분산 네트워크가 탄생했습니다.

Hegotá에 대한 우리의 입장은 현재로서의 최선의 평가이지만, 논의나 구현 작업에서 나온 새로운 증거가 우리의 견해를 바꿀 때마다 우리의 생각을 업데이트할 것입니다.

이러한 EIP 중 일부는 Ethlabs 구성원이 작성하거나 발전시켰으며, 다른 EIP는 이더리움 전역의 엄청나게 광범위하고 재능 있으며 선의를 가진 연구자, 클라이언트 개발자 및 개인 기여자로부터 나온 것입니다. 그러나 모든 EIP가 성공하려면 클라이언트 팀, 지갑, 애플리케이션, L2, 인프라 제공자, 기관, 노드 운영자, 그리고 궁극적으로 사용자 간의 협력이 필요할 것입니다. 이더리움은 세계의 공동 프로젝트이며, 의미 있는 네트워크 발전은 결코 한 조직의 작업이 아닙니다.

우리는 이 생태계의 작은 일부가 된 것에 감사하며, 이더리움이 잠재력을 실현하도록 돕기를 기대합니다.

– Ethlabs