Ethereum yönetim gözlemi: EIP-2537 ön derleme süreci

Yazar: shew

Genel Bakış

EIP-2537, Pectra'nın en son hard fork yükseltmesinde eklenmesi kararlaştırılan EVM ön-derleme talimatıdır. Bu talimat, EVM'ye BLS12-381 eğrisi ile ilgili çeşitli hesaplama işlevleri eklemektedir, örneğin eğri alanındaki eşleme hesaplamaları gibi.

EIP-2573, 2020 yılında önerildi ve 2025 yılına kadar Ethereum yükseltmesine dahil edilmesi onaylandı. Bu makalede, EIP-2537'nin yönetim tarihi ele alınacak ve bu teklifin neden 5 yıl sonra yükseltmeye dahil edildiği araştırılacaktır.

Teklif Arka Planı

2017 yılının Ocak ayında, Vitalik Buterin Exploring Elliptic Curve Pairings'te çiftleme algoritmasını ve alt_bn128 eğrisini ilk kez tanıttı. Ardından, 2017 yılının Şubat ayında, Vitalik Buterin ve Christian Reitwiessner EIP-196 ve EIP-197 önerilerini sundular; önerinin içeriği EVM'ye alt_bn128 eğrisi hesaplama desteği eklemektir.

2017 Ekim ayında yapılan Byzantium yükseltmesinde, alt_bn128 eğrisi resmi olarak dahil edildi. Kısacası, alt_bn128 ilk kez EVM içinde eğri alan eşleme hesaplamalarını gerçekleştirdi, bu da ZK-Snarks kanıtlarının doğrulamasının EVM içinde tamamlanabilmesini sağladı.

Ancak kriptolojinin gelişimiyle birlikte, 2017 Kasım ayında, zcash geliştirme ekibi BLS12-381: New zk-SNARK Elliptic Curve Construction adlı çalışmada BLS12-381 eğrisini ilk kez sundu. alt_bn128 ile karşılaştırıldığında, BLS12-381 daha yüksek bir güvenlik ve daha iyi bir performansa sahiptir. Birçok blok zinciri protokolü daha sonra BLS12-381 eğrisini kullanarak alt_bn128 eğrisini terk etti.

2018 Mayısında, Justin Drake ethresear içinde BLS ile Pragmatik imza toplama başlıklı bir makale yayınladı ve Ethereum'un gelecekteki PoS ve parçalama güncellemelerinin BLS12-381 eğrisi tabanlı BLS çoklu imza algoritmasını kullanabileceğini belirtti. O zamanlar, Ethereum araştırmacıları EIP-1011'i konsensüs katmanı sorununu çözmek için kullanmayı umuyorlardı, ancak EIP-1011 çözümü en fazla 900 doğrulayıcıyı barındırabiliyordu, bu nedenle her bir doğrulayıcı için 1500 ETH'lik devasa bir staking büyüklüğü belirlenmişti. BLS çoklu imza çözümünün ortaya çıkmasıyla, EIP-1011 tarih sahnesinden çekildi. Sonunda, daha sonraki ETH2 güncellemelerinin de BLS12-381 eğrisini kullandığı kanıtlandı.

ETH2 geliştirilmesiyle birlikte, ETH2'nin kullandığı BLS12-381 ile ETH yürütme katmanının entegrasyonu çağrılmaya başlandı. Şubat 2020'de, bazı araştırmacılar EIP-2537'yi önerdi ve bu önerinin ETH2 test ağında test edilmesini umdu. EIP-2537'nin yazarı Alex Stokes, What eth2 needs from eth1 over the next six months makalesinde EIP-2537'nin Berlin hard fork'unda dahil edilmesi çağrısında bulundu.

İlginçtir ki, EIP-2537'nin yazarı da Matter Labs'ın kurucu ortaklarından biridir ve Matter Labs'ın en ünlü ürünü ZKSync'tir.

Berlin kargaşa

İçeriklerin tanıtımına geçmeden önce, EIP-1962'yi tanıtmalıyız. EIP-1962, Matter Labs tarafından 2019'un Nisan ayında önerilen, eliptik eğri alan eşleştirme ön montajı ile ilgili ilk tekliftir ve üç eğriyi destekler:

• BLS12
• BN
• MNT4/6 (Ate eşleştirme)

Bu EIP, farklı eğrileri işlemek için bir kerede 10 adet ön montaj talimatı eklemeyi planlıyor. Ancak bu teklif ortaya çıktığında, oldukça fazla geliştirici teklifin çok karmaşık olduğunu ve geliştiricilerin bunu uygulamada zorlandığını sorguladı. Ayrıca, EIP1962'nin yüksek derecede genelleştirilmesi nedeniyle, akıllı sözleşme mühendisleri için çağırmak da oldukça zahmetli. Elbette, EIP-1962'nin sunucusu olan Matter Labs, esasen eliptik eğri algoritmasının geliştirilme işini tamamladı ve Rust / Go / C++ için referans uygulamalar sağladı.

EIP-1962 sorununu çözmek için Matter Labs, 2020 yılının Şubat ayında EIP-1962'yi parçalayan birden fazla EIP önerdi; bu EIP'ler EIP-1962'nin arayüzünü kısmen miras aldı. Bu EIP'ler şunlardır:

• EIP-2537, BLS12-381 desteği sağlar.
• EIP-2539, BLS12-377 desteği sağlar.
• PR#2541, BLS12-377 (Zexe eğrisi ) desteği sunar, ancak bu teklifin nihayetinde EIP numarasını almadığını ve EIP belge resmi web sitesinde bulunamadığını unutmayın.

Bu birkaç EIP içinde, en önemlisi EIP-2537'dir çünkü konsensüs katmanı da BLS12-381 eğrisini kullanmaktadır. EIP-1962 ve EIP-2537'nin temel amacı, ana ağda konsensüs katmanı BLS imzasının doğrulanmasını gerçekleştirmektir. O dönemde, ETH2 konsensüs katmanının depo sözleşmesi tasarımını geliştiriyordu. Depo sözleşmesi ilk tasarlandığında, yürütme katmanında BLS doğrulama algoritması bulunmadığı için depo sözleşmesi imzayı doğrulamıyordu; belirli BLS imzası, kullanıcı depo yaptıktan sonra konsensüs katmanı tarafından doğrulanacaktır. Eğer hata bulunursa (yeni doğrulayıcılar için), depo başarısız olacak ve kullanıcı tarafından yatırılan ETH kaybolacaktır.

Bu bağlamda, ana geliştiriciler BLS12-381 ön derleme getirmeyi ve depo sözleşmesi içinde imza doğrulaması gerçekleştirmeyi umuyorlar, böylece kullanıcıların ETH2 fonlarını yatırırken olası kayıplarını önleyebiliyorlar. Bu, o dönemde birçok geliştiricinin EIP-1962 ve EIP-2537'ye ilgi göstermesinin de bir nedeniydi.

EIP-2537 ilk ortaya çıktığında, Vitalik hemen EIP'nin var olan bir dizi sorununu fark etti:

Bu sorgular, yalnızca EIP belgelerinin içeriğine odaklandığında, EIP yazarları buna yanıt verip tartışmalar yaptılar. Ardından, 6 Mart 2020'de Ethereum Core Devs Meeting #82 toplantısında, Ethereum çekirdek geliştiricileri EIP-2537'yi tartıştılar. Bu toplantıda Vitalik, EIP-2537 gibi EIP'lerin özyinelemeli SNARK kanıtları için son derece etkili olduğunu ve uzun vadede Ethereum'a zarar vermeyeceğini düşündü. Ayrıca toplantıda EIP-2537'nin önceliği onaylandı, tüm istemciler EIP-2537'yi mümkün olan en kısa sürede uygulamayı kabul etti ve Berlin yükseltmesi öncesinde tüm geliştirmeleri tamamlamayı planladılar.

Sonrasında, EIP-2537 öncelikli bir görev haline geldi. 20 Mart 2020'de, Ethereum Core Devs Meeting #83'te, EIP-2537 hâlâ ilk olarak tartışılan öneri oldu. Bu toplantı, EIP-2537'nin EIP-1962'nin yerini alarak ana BLS önerisi haline geldiğini ve Berlin yükseltmesi için ön seçim EIP listesine girdiğini onayladı ( yani Dahil Olma Uygunluğu (EFI)).

2020 Nisan ayında yapılan Ethereum Core Devs Meeting #84 toplantısında, toplantı resmi olarak EIP-2537'yi Berlin hard fork güncellemesine dahil etti ve Nisan ayında uygulanması, Mayıs - Haziran aylarında test edilmesi için Berlin güncelleme takvimini belirledi. Dikkate değer bir nokta, bu tartışmada EIP-2537'nin en yüksek öncelikli konu olarak listelenmiş olmasıdır.

Sonrasında, EIP-2537 büyük bir geliştirme ve test aşamasına girdi, sonraki yaklaşık 20 ana geliştirici toplantısında, her toplantıda EIP-2537 ile ilgili tartışmalar yer aldı. Şimdi, her toplantıda EIP-2537 ile ilgili hangi konuların tartışıldığını gözden geçirebiliriz.

Ethereum Core Devs Meeting #85'te, Danno ve Axic, EIP-2537'nin ABI kodlama sorununu tartıştılar. Ardından, çekirdek geliştiriciler mevcut uygulama durumunu senkronize ettiler. EIP-2537'nin önericisi Matter Labs, Rust sürümünün uygulamasını temel olarak tamamladığı için Besu istemcisi, EIP-2537'nin işlevselliğini neredeyse tamamladığını belirtti, ancak Geth cephesi şu anda EIP-2537'nin uygulanması için kimsenin çalışmadığını ifade etti.

Ethereum Core Geliştiricileri Toplantısı #86'da, farklı Ethereum düğüm uygulamaları EIP-2537'nin uygulama durumunu yeniden senkronize etti; bu arada Geth, bazı çalışmaları tamamladığını ancak hala tamamlanması gereken çok sayıda iş olduğunu belirtti.

Ethereum Core Geliştiricileri Toplantısı #87'de, bu geliştirici toplantısının en temel içeriği EIP-2537'nin uygulanma sorunudur. Geth geliştiricileri, EIP-2537'yi uygulayan 16000 satırlık bir PR'nın mevcut olduğunu belirtmişlerdir, ancak Geth geliştiricileri PR'nın EIP-2537'yi güvenli ve etkili bir şekilde uygulayıp uygulamadığını belirleyememektedir, bu yüzden geliştiriciler kodun durumunu belirlemek için en basit ve kaba bulanık test yöntemini kullanmak zorunda kalmaktadırlar.

Geth geliştiricisi şöyle diyor: "Yani içgüdüsel tepkim, Geth'in Temmuz'daki ana ağ lansmanı için BLS eğri işlemleriyle hazır olma şansının olmadığıdır." Yani Geth'in Berlin için belirlenen tarihten önce EIP-2537 ile ilgili geliştirmeleri tamamlaması büyük olasılıkla mümkün değil.

Hudson Jameson, Geth için PR incelemesine yardımcı olması için bir kriptografi mühendisi aramayı önerdi ve EIP-2537'nin uygulanabilirliğinin güvenliğini test etmek için test ağı kullanmayı önerdi. Bu noktada ETH2 geliştirme ekibi de BLS imza doğrulamasını uyguladığından, ETH2 ekibi testlere katılabilir.

Burada, Geth'in EIP-2537 uygulama PR'sının verimliliği sağlamak için bol miktarda assembly kodu kullandığını belirtmemiz gerekiyor. Bu assembly kodu oldukça zor okunur ve anlaşılır. Bu nedenle Alex Vlasov, inceleme zorluğunu azaltmak için PR içindeki karmaşık assembly optimizasyonlarının kaldırılmasını önerdi.

Yukarıda EIP-2537'nin temel hedeflerinden birinin ETH2 depo sözleşmesine yardımcı olmak olduğunu zaten belirtmiştik, ancak bu toplantıda depo sözleşmesi geliştiricileri EIP-2537'yi kullanmayan depo sözleşmesinin denetimden geçtiğini belirttiler. Bu nedenle bazı geliştiriciler, EIP-2537'yi kullanan yeni bir depo sözleşmesi çıkarılmaması gerektiğini önerdiler.

Sonunda, toplantı EIP-2537'yi test etmek için bir YOLO test ağı eklemeye karar verdi. Aslında, bu toplantıda, depo sözleşmesinin tamamlanmasıyla birlikte EIP-2537'nin öneminin büyük ölçüde azaldığını görebiliyoruz. Ayrıca, Geth geliştiricileri bu EIP'nin Berlin yükseltmesi öncesinde muhtemelen gerçekleştirilip gerçekleştirilemeyeceğini düşünüyor. Görünüşe göre, EIP-2537'nin Berlin yükseltmesine kabul edilmemesi kesinleşmiş gibi.

Ethereum Core Geliştiricileri Toplantısı #88'de, Geth geliştiricileri EIP-2537'nin uygulanmasıyla ilgili PR'da bir dizi sorun tespit etti ve geliştiriciler daha fazla test ve düzeltme yapılması gerektiğini belirtti. Bu noktada Geth sisteminde iki EIP-2537 uygulaması bulunmaktadır; bunlardan biri assembly optimizasyonu içerirken, diğeri tamamen Go dili ile yazılmıştır. Bir geliştirici, kod inceleme zorluğunu azaltmak için doğrudan Go dili ile yazılmış versiyonun kullanılmasını önerdi.

Ethereum Core Geliştiricileri Toplantısı #89'da daha ciddi bir sorun ortaya çıktı, YOLO testinde bazı sorunlar yaşandı, geliştiriciler bunun BLS imzasından kaynaklandığını düşündü, ancak EIP2537 geliştiricileri buna karşı çıktı ve test ağı sorunlarının BLS imzasından kaynaklanmadığını belirtti. EIP-2537 için iyi haber, EIP-2537'ye dayalı depo sözleşmesinin temelde geliştirilmesinin tamamlanmış olması ve bu sözleşmenin sözleşme denetimini beklemesidir.

Ethereum Core Devs Meeting #90内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91 toplantısında, bir geliştirici, geliştirme maliyetlerini düşürmek ve istemci çeşitliliğini artırmak için modüler bir çözüm önerdi. Eğer okuyucular Ethereum istemci çeşitliliğiyle ilgileniyorlarsa, bu iki toplantının kayıtlarına göz atabilirler.

Ethereum Core Geliştiricileri Toplantısı #92'de, 2537 hala Berlin yükseltmesi için gerekli EIP olarak doğrulandı.

Ethereum Core Devs Meeting #96'da, Celo'nun EIP-2537 ve EIP-2539'u aynı anda ağ hard fork güncellemesine dahil ettiği belirtildi, bu nedenle Matter Labs, EIP-2537 ile birlikte önerilen EIP-2539'un da YOLO v2 test ağında test edilmesini ve Berlin güncellemesine dahil edilmesini umuyor. Ancak Geth geliştiricileri, mevcut EIP-2537'nin Geth içinde tam olarak test edilmediğini savunarak karşı çıktılar. Sonuç olarak, toplantıda Berlin güncellemesine 2696 eklenmemesine ve gelecekte tartışılmasına karar verildi.

Ethereum Core Geliştirici Toplantısı #99'da, bu toplantıda EIP-2537'nin YOLO v3 test ağından ve Berlin yükseltmesinden çıkarılmasına karar verildi. Bunun en temel nedeni EIP-2537'nin ana geliştiricilerin çok fazla zamanını boşa harcaması ve Berlin yükseltmesindeki diğer EIP geliştirmelerini engellemesidir. İkinci bir faktör ise Ethereum Vakfı'nın EIP-2537'nin alternatifi olarak EVM384'ü önermesidir; EVM 384, daha genel bir eliptik eğri hesaplama çözümü sunmaktadır. Ancak ana geliştiriciler toplantı tartışmasında güvenlik sorunları konusunda endişelerini dile getirdiler.

Yukarıdaki içerik, EIP-2537'nin erken dönemine dair bir inceleme sunmaktadır. EIP-2537'nin erken döneminin Berlin yükseltmesindeki en önemli EIP'lerden biri olduğunu görebiliyoruz, ancak uygulanabilirlik sorunları nedeniyle sonunda terk edildi. Son olarak, 2021 yılının Nisan ayında Ethereum, Berlin yükseltmesini tamamladı; yükseltme sırasında yer alan EIP-2565 gibi temel EIP'lerin gerçek uygulamaları karmaşık değil gibi görünüyor. Berlin yükseltmesi biraz zayıf görünüyorsa, bunun nedeni en karmaşık EIP olan EIP-2537'nin Berlin yükseltmesinden çıkarılmış olmasıdır.

sonraki gelişme

Herkesin bildiği gibi, Ethereum'un her bir güncellemesinin bir ana önerisi vardır; örneğin, Berlin güncellemesinden sonra gelen London güncellemesi, Ethereum tarihindeki en önemli işlem ücreti önerisi olan EIP-1559'u getirmiştir. Bir zamanlar ana öneri olarak kabul edilen EIP-2537 için, sonraki tüm güncellemelerin bu öneriyi dahil etmesi oldukça zordur.

Berlin sonrası Londra yükselişinde, geliştiriciler issues#369曾考虑在 London 升级中增加 EIP-2537。在Ethereum Core Devs Meeting #109'da mevcut EIP-2537'nin geliştirme durumunu senkronize ettiler. Bu aşamada EIP-2537'yi uygulamak için diğer kütüphanelerin kullanılması nedeniyle, EIP-2537'nin gas kullanımı ile ilgili bir tartışma ortaya çıktı. Aynı zamanda bir geliştirici EIP-2537'yi EVM384 ile değiştirmeyi önerdi. Ancak, 2021 Nisan'daki Ethereum Core Devs Meeting #111'de, EIP-2537 karmaşıklığı nedeniyle Londra yükselişinden çıkarıldı. Temel karmaşıklık, EIP-2537 standart uygulamasının bağımlı kütüphanelerin değiştirilmesiyle ilgiliydi; bu, gas fiyatlamasında değişikliklere yol açabilir ve farklı istemci uygulamalarının gas tüketimini yeniden değerlendirmesi için önemli bir zaman harcaması gerektirebilir.

2021 yılının Haziran ayında, issues#343 içinde EIP-2537'nin Shanghai yükseltmesine dahil edilmesi resmi olarak önerildi. Ancak, London yükseltmesinden sonra, aslında Pairs yükseltmesi veya The Merge olarak adlandırılan süreç geliştiricilerin büyük bir kısmını meşgul etti; yürütme katmanı geliştiricileri PoS yükseltmesini gerçekleştirmek için çok miktarda kod yazmak zorunda kaldı. 2022 yılının Eylül ayında, Pairs yükseltmesi tamamlandı ve yürütme katmanı geliştiricileri nihayet Shanghai yükseltmesinin bazı hedeflerini tartışma fırsatına sahip oldular.

2022 yılının Kasım ayında, Ethereum Core Geliştirici Toplantısı #150'de EIP-2537'nin Shanghai yükseltmesine dahil edilip edilmeyeceği kısaca tartışıldı, ancak geliştiriciler EIP-2537'nin ertelenmesi gerektiğini düşündüler, Shanghai yükseltmesinin temel amacı PoS çekimlerini desteklemektir. Sonuç olarak, EIP-2537, çekim işlevine odaklanan Shanghai yükseltmesine dahil edilmedi.

Daha trajik olanı, Cancun yükseltmesinin EIP-2537 üzerinde hiçbir tartışma yapmamış olmasıdır, çünkü Cancun yükseltmesinin temel amacı, yürütme katmanı düğümlerinin EIP-4844'ü desteklemesidir. EIP-4844, Ethereum'un ikinci katmanına veri kullanılabilirliği katmanı olarak Ethereum'u kullanması için Blob sağlamaktadır.

Sonunda, 2024 Şubat ayında düzenlenen Ethereum Core Devs Meeting #181'de, geliştiriciler Pectra yükseltmesine EIP-2537'nin dahil edilmesini tartıştılar ve bu noktada geliştiriciler EIP-2537'nin uygulanmasının artık bir sorun olmadığını, sadece Gas tüketim fiyatlandırmasıyla ilgili bazı sorunların bulunduğunu düşündüler.

2024'te 12 Aralık 19'unda gerçekleşen Ethereum Core Devs Meeting #202内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的Ethereum Core Devs Meeting #203'te, geliştiriciler BLS önceden derlenmiş kodunun yeniden fiyatlandırılması dahil konuları tartıştılar. Geth geliştiricisi Jared Wasinger, gaz maliyetinin %20 artırılmasını önerdi ve bu öneri Besu ekibinin benchmark testiyle desteklendi.

özet

| Tarih | Olay | | --- | --- | | 2020 Şubat | EIP-1962 Resmi Olarak Önerildi EIP-2537 | | Nisan 2020 - Ekim 2020 | Geliştirici toplantılarında EIP-2537 uygulama sorunları defalarca tartışıldı ve nihayetinde uygulanamaz olduğu için Berlin yükseltmesi ile vazgeçildi | | 2021 Mart - 2021 Nisan | Geliştirici toplantısında EIP-2537 gaz maliyeti konusu tartışıldı, sonunda karmaşıklığı nedeniyle Londra güncellemesi ile terk edildi | | Kasım 2022 | Geliştirici toplantısında Shanghai güncellemesinin dahil edilip edilmeyeceği tartışıldı, sonuçsuz | | Şubat 2024 | Geliştiriciler EIP-2537'nin herhangi bir uygulama sorunu olmadığını düşünüyor, ancak hala bazı gaz maliyeti sorunları olduğunu düşünüyorlar, Pectra yükseltmesine dahil edilebileceğini belirtiyorlar | | 2024 Aralık - 2025 Ocak | Geliştirici toplantısında belirli maliyet hesaplama modelleri tartışılacak, EIP-2537 maliyet sorunu resmi olarak çözülecek |

EIP'nin Ethereum yükseltmesine dahil edilip edilmediğinin "elbette kendi kendine mücadeleye bağlı olduğu, ancak aynı zamanda tarihsel güzergahı da hesaba kattığı" görülebilir. Her Ethereum yükseltmesinin kendi teması vardır, tıpkı EIP-2537'nin bir zamanlar Berlin yükseltmesi için en önemli EIP olması, ancak uygulamanın zorluğu ve karmaşıklığı nedeniyle hurdaya çıkarılması gibi. Daha sonra, Ethereum, PoS'un tarihsel sürecine girdi ve yalnızca karmaşık yürütme EIP'leri ciddiye alınmazken, çok sayıda PoS ile ilgili yürütme EIP'si temel yükseltme hedefleri olarak kabul edildi ve bu da EIP-2537'nin uzun süre kabul edilmemesine yol açtı.