이더리움 거버넌스 관찰: EIP-2537 사전 조립 프로세스

저자: shew

개요

EIP-2537 은 최신 Pectra 포크 업그레이드에 추가되는 것이 확인된 EVM 사전 어셈블러 명령어입니다. 이 지침은 곡선 영역에서의 페어링 계산 등 BLS12-381 곡선의 다양한 계산 기능을 EVM에 추가합니다.

EIP-2573은 원래 2020년에 제안되었지만 2025년까지 이더리움 업그레이드에 포함될 것이 확정되지 않았습니다. 이 글에서는 주로 EIP-2537의 거버넌스 역사를 소개하고 이 제안을 업그레이드에 포함하는 데 5년이 걸린 이유를 살펴봅니다.

제안 배경

2017년 1월, 비탈릭 부테린은 타원 곡선 페어링 탐구 에서 페어링 알고리즘과 alt_bn128 곡선을 처음 소개했습니다 . 2017년 2월, 비탈릭 부테린과 크리스티안 라이트바이스너가 EVM에 alt_bn128 곡선 계산에 대한 지원을 추가하는 EIP-196 과 EIP-197을 제안했습니다.

2017년 10월 비잔티움 업그레이드에서 alt_bn128 곡선이 공식적으로 통합되었습니다 . 간단히 말해서, alt_bn128 EVM 내에서 곡선 도메인 페어링 계산을 처음으로 구현했으며, 이를 통해 EVM 내에서 ZK-Snarks 증명 검증을 완료할 수 있습니다.

그러나 2017년 11월 암호학이 발전하면서 zcash 개발팀은 BLS12-381: 새로운 zk-SNARK 타원 곡선 구축 에서 BLS12-381 곡선을 처음으로 제시했습니다 . alt_bn128 에 비해 BLS12-381 보안성이 더 높고 성능이 더 좋습니다. 그 이후 많은 블록체인 프로토콜이 BLS12-381 곡선을 사용 하고 alt_bn128 곡선을 포기했습니다 .

2018년 5월, Justin Drake는 ethresear에서 BLS를 사용한 실용적 서명 집계 라는 제목의 기사를 게시하면서, 향후 Ethereum의 PoS 및 샤딩 업그레이드에서 BLS12-381 곡선을 기반으로 하는 BLS 다중 서명 알고리즘을 사용할 수 있다고 지적했습니다 . 당시 이더리움 연구진은 EIP-1011을 사용하여 합의 계층 문제를 해결하고자 했지만, EIP-1011 솔루션은 최대 900명의 검증자를 수용할 수 있었기 때문에 각 검증자에게 1,500 ETH라는 엄청난 스테이킹 규모가 설정되었습니다. BLS 다중서명 솔루션의 도입으로 EIP-1011은 역사의 무대에서 사라졌습니다. 결국, 이후의 ETH2 업그레이드도 BLS12-381 곡선을 사용하게 되었습니다.

ETH2가 개발되면서 ETH2에서 사용하는 BLS12-381 ETH 실행 계층에 도입하자는 요구가 나오기 시작했습니다. 2020년 2월, 일부 연구자들은 EIP-2537을 제안했으며 이 제안이 ETH2 테스트넷에서 함께 테스트될 수 있기를 바랐습니다. EIP-2537 작성자 Alex Stokes는 그의 기사 "다음 6개월 동안 eth2가 eth1에 필요로 하는 것" 에서 베를린 하드 포크에 EIP-2537을 포함시켜야 한다고 주장했습니다 .

흥미롭게도 EIP-2537의 저자는 Matter Labs의 공동 창립자이기도 하며 Matter Labs의 가장 유명한 제품은 ZKSync입니다.

베를린 폭동

다음 내용을 소개하기에 앞서 먼저 EIP-1962에 대해 소개해야 합니다 . EIP-1962는 2019년 4월 Matter Labs에서 제안한 타원 곡선 도메인 페어링 사전 조립에 대한 첫 번째 제안입니다. 이 제안은 다음과 같은 세 가지 곡선을 지원합니다.

• BLS12
• 비엔
• MNT4/6 (Ate 페어링)

이 EIP는 다양한 곡선을 처리하기 위해 한 번에 10개의 사전 조립 지침을 추가하도록 준비되었습니다. 그러나 이 제안이 나온 후 많은 개발자들은 이 제안이 개발자들이 구현하기에는 너무 복잡하고 어렵다는 의문을 제기했습니다. 동시에 EIP1962의 높은 보편성으로 인해 스마트 계약 엔지니어가 이를 호출하는 것도 매우 까다롭습니다. 물론, EIP-1962의 제안자인 Matter Labs는 본질적으로 타원 곡선 알고리즘의 개발을 완료 하고 Rust/Go/C++ 참조 구현을 제공했습니다.

EIP-1962의 문제를 해결하기 위해 Matter Labs는 2020년 2월에 EIP-1962를 분리하기 위한 여러 EIP를 제안했습니다. 이러한 EIP는 부분적으로 EIP-1962의 인터페이스를 상속했습니다. 이러한 EIP에는 다음이 포함됩니다.

• EIP-2537은 BLS12-381에 대한 지원을 제공합니다.
• EIP-2539는 BLS12-377에 대한 지원을 제공합니다.
• PR#2541은 BLS12-377(Zexe 곡선)에 대한 지원을 제공하지만, 이 제안은 EIP 번호를 받지 못했으며 EIP 문서 웹사이트에서 찾을 수 없습니다.

이러한 EIP 중 가장 중요한 것은 EIP-2537인데, 이는 합의 계층에서도 BLS12-381 곡선을 사용하기 때문입니다. EIP-1962와 EIP-2537의 핵심 목적은 모두 메인 네트워크 내에서 합의 계층 BLS 서명의 검증을 구현하는 것입니다. 당시 ETH2는 합의 계층에 대한 입금 계약 설계를 개발하고 있었습니다. 예금 계약이 처음 설계되었을 때 실행 계층에는 BLS 검증 알고리즘이 포함되지 않았으므로 예금 계약은 서명을 검증하지 않았습니다. 특정 BLS 서명은 사용자가 입금한 후 합의 계층에서 검증됩니다. 잘못된 정보가 발견되면(신규 검증자의 경우), 입금은 실패하고 사용자가 입금한 ETH는 손실됩니다.

이러한 맥락에서 핵심 개발자는 사용자의 예치된 ETH2 자금의 손실을 방지하기 위해 예치 계약에서 서명 검증을 구현하기 위해 BLS12-381 사전 조립을 도입하고자 합니다. 이는 당시 많은 개발자들이 EIP-1962와 EIP-2537에 주목한 이유이기도 합니다.

EIP-2537이 처음 제안되었을 때 Vitalik은 EIP에 다음과 같은 일련의 문제가 있다는 것을 즉시 발견했습니다 .

이러한 질문은 주로 EIP 문서의 내용에 초점을 맞추었고, EIP 작성자는 이에 대해 답변하고 논의했습니다. 이후 2020년 3월 6일, Ethereum Core Devs Meeting #82 에서 Ethereum 코어 개발자들은 EIP-2537에 대해 논의했습니다. 회의 중에 Vitalik은 EIP-2537과 같은 EIP가 재귀적 SNARK 증명에 매우 효과적이고 장기적으로 Ethereum에 해를 끼치지 않을 것이라고 믿었습니다. 동시에 회의에서는 EIP-2537의 우선순위도 확인했습니다. 모든 고객은 가능한 한 빨리 EIP-2537을 구현하기로 합의했으며 베를린 업그레이드 전에 모든 개발을 완료할 계획입니다.

이후 EIP-2537이 더 높은 우선순위 작업이 되었습니다. 2020년 3월 20일, 이더리움 코어 개발자 회의 #83 에서 EIP-2537이 여전히 논의된 첫 번째 제안이었습니다. 회의에서는 EIP-2537이 BLS의 핵심 제안인 EIP-1962를 대체하고 베를린 업그레이드를 위한 사전 선택된 EIP 목록(즉, 포함 자격(EFI))의 일부가 될 것이라는 것이 확인되었습니다.

2020년 4월의 이더리움 코어 개발자 회의 #84 에서 회의는 공식적으로 베를린 하드 포크 업그레이드에 EIP-2537을 포함시켰고, 베를린 업그레이드 일정을 4월에 구현하고 5~6월에 테스트하기로 결정했습니다. 이 논의에서 EIP-2537이 최우선 순위로 나열되었다는 점이 주목할 만합니다.

이후 EIP-2537은 대규모 개발 및 테스트 단계에 들어갔습니다. 그 후 약 20차례의 핵심 개발자 회의에서 거의 모든 회의에서 EIP-2537에 대한 논의가 이루어졌습니다. 다음으로, 각 회의에서 EIP-2537과 관련된 어떤 문제가 논의되었는지 살펴보겠습니다.

Ethereum Core Devs Meeting #85 에서 Danno와 Axic은 EIP-2537의 ABI 인코딩 문제에 대해 논의했습니다. 이후 핵심 개발자들은 현재 구현 상태를 동기화했습니다. EIP-2537의 제안자인 Matter Labs가 Rust 버전의 구현을 기본적으로 완료했기 때문에 Besu 클라이언트는 EIP-2537의 기능을 기본적으로 구현했다고 선언했습니다. 하지만 Geth는 현재 EIP-2537 구현을 위해 아무도 노력하고 있지 않다고 밝혔습니다.

Ethereum Core Devs Meeting #86 에서 다양한 Ethereum 노드 구현이 EIP-2537 구현을 다시 한번 동기화했으며 Geth는 일부 작업이 완료되었지만 여전히 해야 할 작업이 많다고 언급했습니다.

Ethereum Core Devs Meeting #87 에서 이 개발자 회의의 핵심 내용은 EIP-2537의 구현이었습니다. Geth 개발자들은 현재 EIP-2537을 구현한 16,000줄의 PR이 있다고 말했지만, Geth 개발자들은 PR이 EIP-2537을 안전하고 효과적으로 구현했는지 확신할 수 없으므로, 개발자는 가장 간단하고 거친 퍼즈 테스트를 통해서만 코드의 상황을 판단할 수 있습니다.

Geth 개발자는 "제 직감으로는 Geth가 7월 메인넷 출시를 위한 BLS 커브 운영을 준비할 가능성은 전혀 없다고 생각합니다."라고 말했습니다. 즉, Geth가 베를린에서 예정된 시간 전에 EIP-2537 개발을 완료할 가능성은 낮다는 뜻입니다.

허드슨 제임슨은 Geth의 PR 검토를 돕기 위해 암호화 엔지니어를 찾을 것을 제안했고, 테스트 네트워크를 사용하여 EIP-2537의 구현 보안을 테스트할 것을 제안했습니다. 현재 ETH2 개발팀도 BLS 서명 검증을 구현하고 있으므로 ETH2팀이 테스트에 참여할 수 있습니다.

여기서 우리는 몇 가지 배경 지식을 추가해야 합니다. 즉, Geth의 EIP-2537 구현 PR은 효율성을 보장하기 위해 많은 어셈블리 코드를 사용합니다. 어셈블리 코드의 이 부분은 읽고 이해하기가 매우 어렵습니다. 그래서 Alex Vlasov는 검토의 어려움을 줄이기 위해 PR 내부의 복잡한 어셈블리 최적화를 제거하는 것을 제안했습니다.

우리는 이미 위에서 EIP-2537의 핵심 목표 중 하나가 ETH2 입금 계약을 지원하는 것이라고 소개했습니다. 하지만 이번 회의에서 입금계약 개발자들은 EIP-2537을 사용하지 않는 입금계약이 감사를 받았다고 언급하였고, 따라서 일부 개발자들은 EIP-2537을 사용하여 다른 입금계약을 출시하지 않는 것이 최선이라고 제안하였습니다.

마지막으로, 회의에서는 EIP-2537을 테스트하는 것을 핵심으로 하는 YOLO 테스트 네트워크를 추가하기로 결정했습니다. 실제로 이번 회의에서 우리는 예치계약 완료로 인해 EIP-2537의 중요성이 상당히 낮아졌다는 것을 볼 수 있습니다. 동시에 Geth 개발자들은 이 EIP가 베를린 업그레이드 전에는 구현되지 않을 가능성이 매우 높다고 이미 믿고 있습니다. EIP-2537이 베를린 업그레이드에서 수용되지 않을 것이라는 것은 이미 정해진 것 같습니다.

Ethereum Core Devs Meeting #88 에서 Geth 개발자들은 EIP-2537 구현 PR과 관련된 일련의 문제를 발견했으며, 개발자들은 추가 테스트와 수정이 필요하다고 말했습니다. 현재 Geth 시스템에는 두 개의 EIP-2537 구현이 있는데, 그 중 하나는 어셈블리 최적화를 포함하고 있고, 다른 하나는 전적으로 Go 언어로 작성되었습니다. 일부 개발자는 코드 검토의 어려움을 줄이기 위해 Go 언어 버전을 직접 사용하는 것을 제안했습니다.

Ethereum Core Devs Meeting #89 에서 더 심각한 문제가 발생했습니다. YOLO 테스트에서는 몇 가지 문제가 발생했습니다. 개발자들은 이 문제가 BLS 서명으로 인해 발생했다고 의심했지만, EIP2537 개발자들은 이를 부인했고 테스트 네트워크 문제는 BLS 서명으로 인해 발생하지 않았다고 믿었습니다. EIP-2537에 대한 좋은 소식은 EIP-2537을 기반으로 한 보증금 계약이 기본적으로 개발되어 계약 감사를 기다리고 있다는 것입니다.

Ethereum Core Devs Meeting #90 에서 이 회의는 7월에 출시될 Berlin 업그레이드에 대한 DDL을 확정했습니다. 물론, 이 회의에서 논의된 또 다른 흥미로운 쟁점은 고객 다양성 문제였습니다. 이 회의에서 개발자들은 주로 Geth의 우세성에 대해 논의했으며, 일부 개발자는 다른 클라이언트의 개발 비용을 줄이기 위해 현재 EIP 구현을 동결할 것을 제안했습니다. 더욱 흥미로운 점은 #91 회의에서 일부 개발자가 개발 비용을 줄이고 고객 다양성을 높이기 위해 모듈형 솔루션을 사용할 것을 제안했다는 것입니다. 독자 중 이더리움 클라이언트 다양성에 관심이 있는 사람은 이 두 회의의 기록을 읽어볼 수 있습니다.

Ethereum Core Devs Meeting #92 에서 2537은 여전히 ​​베를린 업그레이드에 필요한 EIP로 확인되었습니다.

Ethereum Core Devs Meeting #96 에서 Celo가 이미 EIP-2537과 EIP-2539를 네트워크 하드 포크 업그레이드에 포함했기 때문에 Matter Labs는 EIP-2537과 동시에 제안된 EIP-2539를 테스트를 위해 YOLO v2 테스트넷에 올리고 베를린 업그레이드에 진입하기를 바라고 있습니다. 하지만 Geth 개발자들은 현재의 EIP-2537이 아직 Geth에서 완전히 테스트되지 않았다고 주장하며 이의를 제기했습니다. 최종 회의에서는 베를린 업그레이드에 2696을 추가하지 않기로 결정하고, 향후 논의에 맡기기로 했습니다.

Ethereum Core Devs Meeting #99 에서 YOLO v3 테스트넷과 Berlin 업그레이드에서 EIP-2537을 제거하기로 결정했습니다. 핵심적인 이유는 EIP-2537이 핵심 개발자들의 시간을 너무 많이 낭비하여 베를린 업그레이드에서 다른 EIP 개발을 방해했기 때문입니다. 두 번째 요인은 이더리움 재단이 EIP-2537을 대체하기 위해 EVM384를 제안했다는 것입니다. EVM 384는 보다 일반적인 타원 곡선 계산 솔루션을 제공합니다. 그러나 핵심 개발자들은 회의 논의 중에 보안 문제에 대한 우려를 표명했습니다.

위 내용은 EIP-2537의 초기 역사입니다. 우리는 EIP-2537이 초기 베를린 업그레이드에서 가장 중요한 EIP 중 하나였지만, 구현 문제로 인해 결국 중단되었음을 알 수 있습니다. 마침내 2021년 4월에 이더리움은 베를린 업그레이드를 완료했습니다. 업그레이드에 포함된 핵심 EIP-2565의 실제 구현은 복잡하지 않았습니다. 베를린 업그레이드는 약간 빈약해 보였습니다. 이는 가장 핵심적이고 복잡한 EIP-2537이 베를린 업그레이드에서 제외되었기 때문입니다.

이후 개발

우리 모두가 알고 있듯이, 이더리움의 모든 업그레이드에는 핵심 제안이 있습니다. 예를 들어, 베를린 업그레이드에 이은 런던 업그레이드에서는 이더리움 역사상 가장 중요한 거래 수수료 제안인 EIP-1559가 도입되었습니다. 본래 핵심 제안이었던 EIP-2537의 경우, 이 제안을 후속 업그레이드에 통합하는 데 어려움이 있습니다.

베를린 이후 런던 업그레이드에서 개발자들은 issues#369 에서 런던 업그레이드에 EIP-2537을 추가하는 것을 고려했습니다 . Ethereum Core Devs Meeting #109 에서 개발자들은 EIP-2537의 현재 개발 상태를 동기화했습니다. 이때, EIP-2537을 구현하기 위해 다른 라이브러리를 사용했기 때문에 EIP-2537에 의한 가스 사용에 대한 논의가 도입되었습니다. 동시에 일부 개발자는 EIP-2537을 대체하기 위해 EVM384를 사용할 것을 제안했습니다. 하지만 2021년 4월 Ethereum Core Devs Meeting #111 에서 복잡성으로 인해 런던 업그레이드에서 EIP-2537이 제거되었습니다. 핵심적인 복잡성은 EIP-2537 표준 구현이 종속 라이브러리를 대체하여 가스 가격에 변동을 일으킬 수 있다는 사실에 있습니다. 다양한 클라이언트 구현에서는 가스 소비량을 다시 평가하는 데 상당한 시간을 소비해야 합니다.

2021년 6월, issues#343 에서는 상하이 업그레이드에 EIP-2537을 포함할 것을 공식적으로 제안했습니다. 그러나 런던 업그레이드 이후, The Merge라고도 알려진 Pairs 업그레이드는 실제로 많은 개발자의 시간을 소모했으며 실행 계층 개발자는 PoS 업그레이드를 구현하기 위해 많은 코드를 작성해야 했습니다. 2022년 9월에 Pairs 업그레이드가 완료되었고, 임원급 개발자들은 마침내 상하이 업그레이드의 일부 목표에 대해 계속 논의할 기회를 얻었습니다.

2022년 11월, 이더리움 코어 개발자 회의 #150 에서 EIP-2537을 상하이 업그레이드에 포함해야 하는지에 대해 간략히 논의했지만, 개발자들은 EIP-2537을 연기해야 ​​한다고 생각했습니다. 상하이 업그레이드의 핵심은 PoS 인출을 지원하는 것이었습니다. 결국 EIP-2537은 인출 기능 구현을 중심으로 한 상하이 업그레이드에 포함되지 않았습니다.

더욱 비극적인 점은 Cancun 업그레이드에서 EIP-2537에 대해 논의하지 않았다는 것입니다. Cancun 업그레이드의 핵심은 실행 계층 노드가 EIP-4844를 지원한다는 것입니다. EIP-4844는 Ethereum을 Layer 2의 데이터 가용성 계층으로 사용할 수 있도록 Ethereum Layer 2용 Blob을 제공합니다.

마지막으로, 2024년 2월의 Ethereum Core Devs Meeting #181 에서 개발자들은 EIP-2537을 Pectra 업그레이드에 통합하는 것에 대해 논의했으며, 이 시점에서 개발자들은 EIP-2537 구현이 더 이상 문제가 아니며 문제의 일부만이 가스 소비 가격 책정에 있다고 생각했습니다.

2024년 12월 19일 열린 Ethereum Core Devs Meeting #202 에서 Nethermind 개발자들은 EIP-2537의 가격 모델을 최종적으로 확정했습니다. 그렇습니다. EIP-2537의 원래 제안자인 Matter Labs는 이 시점에서 논의에서 거의 물러났습니다. 2025년 1월에 열린 이더리움 코어 개발자 회의 #203 에서 개발자 논의에는 BLS 프리컴파일의 가격을 재조정하는 내용이 포함되었고, Geth 개발자인 Jared Wasinger는 Besu 팀의 벤치마크를 바탕으로 가스 비용을 20% 인상할 것을 제안했습니다.

요약하다

EIP가 이더리움 업그레이드에 포함될지는 "물론 개인의 노력에 달려 있지만, 역사적 흐름도 고려해야 한다"는 점을 알 수 있다. 모든 이더리움 업그레이드에는 고유한 테마가 있습니다. 마치 EIP-2537이 한때 베를린 업그레이드의 가장 중요한 EIP가 되었지만 구현의 어려움과 복잡성으로 인해 중단된 것과 같습니다. 이후 이더리움은 PoS의 역사적인 과정에 접어들었습니다. 복잡한 순수 실행 계층 EIP는 심각하게 받아들여지지 않았고, 많은 수의 PoS 관련 실행 EIP가 핵심 업그레이드 목표로 간주되어 EIP-2537이 오랫동안 수용되지 않는 결과를 낳았습니다.