Bu makale, EIP-2537'nin yönetişim tarihini tanıtmakta ve bu önerinin neden 5 yıl sonra yükseltmeye dahil edildiğini araştırmaktadır.
Yazı: shew
Genel Bakış
EIP-2537, Pectra'nın en son fork yükseltmesinde eklenmesi belirlenen EVM ön-derleme talimatıdır. Bu talimat, EVM'ye BLS12-381 eğrisi ile ilgili çeşitli hesaplama yetenekleri 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 güncellemesine dahil edilmesi onaylandı. Bu makale, EIP-2537'nin yönetişim tarihini ana hatlarıyla ele almakta ve bu önerinin neden 5 yıl sonra güncellemeye dahil edildiğini araştırmaktadır.
Teklifin Arka Planı
2017 yılının Ocak ayında, Vitalik Buterin Exploring Elliptic Curve Pairings adlı çalışmasında ilk kez eşleme algoritması ve alt_bn128 eğrisini tanıttı. Ardından, 2017 yılının Şubat ayında, Vitalik Buterin ve Christian Reitwiessner EIP-196 ve EIP-197 önerilerini sundular; bu önerilerin içeriği EVM'ye alt_bn128 eğrisi hesaplama desteği eklemektir.
2017 yılının Ekim ayında yapılan Byzantium yükseltmesinde, alt_bn128 eğrisi resmi olarak dahil edilmiştir. Kısacası, alt_bn128, EVM içinde eğri alan eşleme hesaplamasını ilk kez gerçekleştirmiştir, bu da ZK-Snarks kanıt doğrulamasının EVM içinde tamamlanabileceği anlamına gelmektedir.
Ancak kriptolojinin gelişmesiyle birlikte, 2017 yılının Kasım ayında, zcash geliştirme ekibi BLS12-381: Yeni zk-SNARK Eliptik Eğri Yapımı başlıklı çalışmada BLS12-381 eğrisini ilk kez tanıttı. alt_bn128 ile karşılaştırıldığında, BLS12-381 daha yüksek güvenlik ve daha iyi performans sunmaktadır. Bu tarihten sonra birçok blockchain protokolü BLS12-381 eğrisini kullanmaya başladı ve alt_bn128 eğrisini terk etti.
Mayıs 2018'de, Justin Drake ethresear'da BLS ile Pratik imza birleştirme başlıklı bir makale yayınladı ve Ethereum'un gelecekteki PoS ve parçalama yükseltmelerinin BLS12-381 eğrisi temelinde BLS çoklu imza algoritmasını kullanabileceğini belirtti. O zamanlar, Ethereum araştırmacıları konsensüs katmanı sorununu EIP-1011 ile çözmeyi 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 boyutu belirlenmişti. BLS çoklu imza çözümünün önerilmesiyle, EIP-1011 tarih sahnesinden çekildi. Sonuç olarak, sonraki ETH2 yükseltmelerinin de nihayetinde BLS12-381 eğrisini kullandığı kanıtlandı.
ETH2 geliştirmeleriyle birlikte, ETH2'nin kullandığı BLS12-381'in ETH yürütme katmanına dahil edilmesi çağrısında bulunuldu. Şubat 2020'de bazı araştırmacılar EIP-2537'yi önerdi ve bu önerinin ETH2 test ağında test edilmesini umdular. EIP-2537'nin yazarı Alex Stokes, What eth2 needs from eth1 over the next six months adlı makalede EIP-2537'nin Berlin hard fork'unda dahil edilmesi çağrısında bulundu.
İlginçtir ki, EIP-2537'nin yazarı aynı zamanda Matter Labs'ın kurucu ortağıdır ve Matter Labs'ın en ünlü ürünü ZKSync'tir.
Berlin kargaşası
İlerleyen içeriklere girmeden önce EIP-1962'yi tanıtmalıyız. EIP-1962, Matter Labs'ın 2019'un Nisan ayında önerdiği, eliptik eğri alanı eşleme önceden derleme ile ilgili ilk tekliftir ve bu teklif üç eğriyi desteklemektedir, bunlar şunlardır:
BLS12
BN
MNT4/6 (Ate eşleştirmesi)
Bu EIP, farklı eğrileri işlemek için bir kerede 10 ön derleme talimatı eklemeyi planlıyor. Ancak bu öneri doğduktan sonra, oldukça fazla geliştirici önerinin karmaşık olduğu ve geliştiricilerin bunu gerçekleştirmesinin zor olduğu konusunda şüpheler dile getirdi. Ayrıca, EIP1962'nin son derece genel olması nedeniyle, akıllı sözleşme mühendisleri için çağrı yapmak da oldukça zahmetli. Elbette, EIP-1962'nin önericisi olan Matter Labs, esasen eliptik eğri algoritmasının geliştirme işini tamamladı ve Rust / Go / C++ referans uygulamaları sağladı.
EIP-1962 sorununu çözmek için Matter Labs, 2020 yılı Şubat ayında EIP-1962'yi bölerek birçok EIP önerdi. Bu EIP'ler, EIP-1962'nin arayüzünü kısmen devralmaktadır. Bu EIP'ler şunlardır:
EIP-2537, BLS12-381 için destek sağlar
EIP-2539, BLS12-377 desteği sağlar
PR#2541 BLS12-377 (Zexe eğrisi) desteği sunmaktadır, ancak bu teklifin nihayetinde EIP numarası almadığını ve EIP belgeleri resmi web sitesinde bulunamayacağını unutmayın.
Bu birkaç EIP arasında en önemlisi EIP-2537'dir çünkü konsensüs katmanı 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ğrulaması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 yanlış olduğu tespit edilirse (yeni doğrulayıcılar için), depo başarısız olacak ve kullanıcının yatırdığı ETH kaybolacaktır.
Bu bağlamda, çekirdek geliştiriciler, kullanıcıların ETH2 fonlarını yatırırken olası zararlarını önlemek için mevduat sözleşmesine BLS12-381 ön derlemesini dahil etmeyi umuyorlar. Bu, o dönemde birçok geliştiricinin EIP-1962 ve EIP-2537'ye odaklanmasının da 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, ardından EIP yazarları buna yanıt ve tartışma yaptılar. Ardından, 6 Mart 2020 tarihinde Ethereum Core Devs Meeting #82 toplantısında, Ethereum ana geliştiricileri EIP-2537'yi tartıştılar. Bu toplantıda, Vitalik EIP-2537 gibi EIP'lerin tekrarlayan SNARK kanıtları için son derece etkili olduğunu ve uzun vadede Ethereum'a zarar vermeyeceğini düşündü. Aynı zamanda, toplantıda EIP-2537'nin öncelik durumu 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 hala ilk olarak tartışılan öneri oldu. Bu toplantıda EIP-2537'nin EIP-1962'yi değiştirdiği ve Berlin yükseltmesinin öncelikli EIP listesine dahil edildiği onaylandı ( yani Dahil Olma Uygunluğu (EFI)).
2020 yılının Nisan ayında gerçekleştirilen Ethereum Core Devs Meeting #84 toplantısında, toplantı resmi olarak EIP-2537'yi Berlin sert fork yükseltmesine dahil etti ve Nisan ayında uygulamaya geçilmesi, Mayıs - Haziran aylarında test edilmesi için Berlin yükseltme zaman çizelgesini belirledi. Dikkate değer bir şekilde, bu tartışmada EIP-2537 en yüksek öncelikli konu olarak listelendi.
Daha sonra, EIP-2537 büyük bir geliştirme ve test aşamasına girdi. Sonraki yaklaşık 20 temel geliştirici toplantısında, her toplantıda temel olarak EIP-2537 hakkında tartışmalar yapıldı. Şimdi, her toplantıda EIP-2537 ile ilgili hangi konuların tartışıldığını gözden geçirebiliriz.
Ethereum Core Geliştiricileri Toplantısı #85'te, Danno ve Axic EIP-2537'nin ABI kodlama sorununu tartıştılar. Ardından, ana geliştiriciler mevcut uygulama durumunu senkronize ettiler. EIP-2537'nin önericisi Matter Labs daha önce Rust sürümünün uygulamasını neredeyse tamamladığı için, Besu istemcisi EIP-2537'nin işlevselliğini neredeyse gerçekleştirdiğini açıkladı. Ancak Geth cephesi şu anda EIP-2537'nin uygulanması için kimsenin çalışmadığını belirtti.
Ethereum Core Geliştiricileri Toplantısı #86'da, farklı Ethereum düğüm uygulamaları EIP-2537'nin uygulama durumunu tekrar senkronize etti; Geth, bazı çalışmaların tamamlandığını ancak tamamlanmayı bekleyen büyük bir iş olduğunu belirtti.
Ethereum Core Devs Meeting #87'de, bu geliştirici toplantısının en temel içeriği EIP-2537'nin uygulanmasıydı. Geth geliştiricileri şu anda EIP-2537'yi uygulayan 16000 satırlık bir PR'nın bulunduğunu belirtti, ancak Geth geliştiricileri PR'nın EIP-2537'yi güvenli ve etkili bir şekilde uygulayıp uygulamadığından emin olamıyorlar, bu yüzden geliştiriciler kodun durumunu değerlendirmek için en basit ve kaba yöntem olan bulanık testler ile değerlendirme yapmak zorunda kalıyorlar.
Geth geliştiricisi şunları söyledi: "Yani içgüdüsel olarak, Geth'in Temmuz'daki ana ağ lansmanı için BLS eğrisi işlemleriyle hazır olma şansının olmadığını düşünüyorum." yani Geth'in Berlin'deki belirlenen zamanında EIP-2537 ile ilgili geliştirmeleri tamamlaması büyük ihtimalle mümkün değil.
Hudson Jameson, Geth için PR incelemesine yardımcı olacak bir kriptografi mühendisinin bulunmasını önerdi ve EIP-2537'nin uygulanabilirliğinin güvenliğini test etmek için bir test ağı kullanılmasını önerdi. O sırada ETH2 geliştirme ekibi de BLS imza doğrulamasını uyguluyordu, bu nedenle ETH2 ekibi testlere katılabilir.
Burada, Geth'in EIP-2537 uygulama PR'sının verimliliği sağlamak için büyük ölçüde assembly kodu kullandığına dair bir arka plan bilgisi eklememiz gerekiyor; bu assembly kodunun okunması ve anlaşılması oldukça zor. Bu nedenle, Alex Vlasov, inceleme zorluğunu azaltmak için PR içindeki karmaşık assembly optimizasyonlarının çıkarılmasını önerdi.
Daha önce EIP-2537'nin bir ana hedefinin ETH2 depo sözleşmesine yardımcı olmak olduğunu açıkladık, ancak bu toplantıda depo sözleşmesi geliştiricileri EIP-2537'yi kullanmayan depo sözleşmesinin denetlendiğini belirtti, bu nedenle bazı geliştiriciler, EIP-2537'yi kullanan bir depo sözleşmesi oluşturulmasının en iyisi olmayacağını önerdi.
Sonunda, toplantıda YOLO test ağının eklenmesine karar verildi, bu test ağının temel amacı EIP-2537'yi test etmektir. Aslında, bu toplantıda depo sözleşmesinin tamamlanmasıyla birlikte EIP-2537'nin öneminin önemli ölçüde azaldığını görebiliriz; ayrıca Geth geliştiricileri bu EIP'nin Berlin yükseltmesi öncesinde uygulanamayacağına dair güçlü bir kanaate sahipler. Görünüşe göre EIP-2537'nin Berlin yükseltmesi tarafından kabul edilmemesi artık kesinleşmiş durumda.
Ethereum Core Geliştirici Toplantısı #88'de, Geth geliştiricileri EIP-2537'nin uygulama PR'sında bir dizi sorun buldular ve geliştiriciler daha fazla test ve düzeltme yapılması gerektiğini belirttiler. Bu esnada Geth sisteminde iki EIP-2537 uygulaması mevcut, bunlardan biri montaj 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ılan versiyonun kullanılmasını önerdi.
Ethereum Core Geliştiricileri Toplantısı #89'da, daha ciddi bir sorun ortaya çıktı, YOLO testinde bazı problemler yaşandı, geliştiriciler bunun BLS imzasından kaynaklandığını düşündü, ancak EIP2537 geliştiricileri buna karşı çıktı ve test ağındaki sorunun BLS imzasından kaynaklanmadığını belirtti. EIP-2537 için iyi haber ise, EIP-2537 temelinde yapılan depo sözleşmesinin neredeyse tamamlandığı ve bu sözleşmenin sözleşme denetimini beklediğidir.
Ethereum Core Devs Meeting #90 内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91 toplantısında, bir geliştirici modüler bir çözüm kullanarak geliştirme maliyetlerini azaltmayı ve istemci çeşitliliğini artırmayı önerdi. Eğer okuyucular Ethereum istemci çeşitliliği ile ilgileniyorlarsa, bu iki toplantının kayıtlarını okuyabilirler.
Ethereum Core Geliştiricileri Toplantısı #92'de, 2537 hala Berlin yükseltmesi için gereken EIP olarak doğrulandı.
Ethereum Core Devs Meeting #96'da, Celo tabanlı olarak EIP-2537 ve EIP-2539'un aynı anda ağının sert çatal yükseltmesine dahil edildiği belirtildi, bu nedenle Matter Labs, EIP-2539'un da EIP-2537 ile birlikte YOLO v2 test ağında test edilmesini ve Berlin yükseltmesine dahil edilmesini umuyordu. Ancak Geth geliştiricileri, mevcut EIP-2537'nin Geth içinde tam olarak test edilmediğini savunarak karşı çıktılar. Sonunda toplantıda Berlin yükseltmesine 2696 eklenmemesine ve gelecekte tartışılmasına karar verildi.
Ethereum Core Devs Meeting #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 kaybetmesine neden olması ve Berlin yükseltmesi içindeki diğer EIP geliştirmelerini engellemesidir. İkinci bir faktör ise Ethereum Vakfı'nın EIP-2537'nin yerine 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 getirmiştir.
Yukarıda belirtilen içerik, EIP-2537'nin erken dönemini anlatmaktadır. EIP-2537'nin erken döneminin Berlin yükseltmesindeki en önemli EIP'lerden biri olduğunu görebiliriz; ancak uygulama sorunları nedeniyle nihayetinde iptal edilmiştir. Sonuç olarak, 2021 Nisan ayında Ethereum Berlin yükseltmesini tamamladı; yükseltmenin çekirdeğinde yer alan EIP-2565 gibi gerçek uygulamalar oldukça karmaşık değildir. Berlin yükseltmesi biraz zayıf görünmektedir, çünkü en karmaşık çekirdek EIP-2537 Berlin yükseltmesinden çıkarılmıştır.
Son Gelişmeler
Herkes tarafından bilindiği gibi, Ethereum'un her güncellemesi bir ana öneri ile birlikte gelir; örneğin, Berlin güncellemesinden sonra Londra güncellemesi, Ethereum tarihindeki en önemli işlem ücreti önerisi olan EIP-1559'u getirmiştir. Daha önce bir ana öneri olarak değerlendirilen EIP-2537 için, sonraki tüm güncellemelerin bu öneriyi kapsaması oldukça zordur.
Berlin'den sonraki Londra yükseltmesinde, geliştiriciler issues#369 曾考虑在 London 升级中增加 EIP-2537。在 Ethereum Core Devs Meeting #109'de EIP-2537'nin mevcut gelişimini senkronize ettiler ve şu anda EIP-2537'yi uygulamak için diğer kütüphanelerin kullanılması nedeniyle EIP-2537 için gaz kullanımı hakkında bir tartışma başlattılar. Aynı zamanda, bazı geliştiriciler EIP-2537'yi EVM384 ile değiştirmeyi önerdiler. Ancak, Nisan 2021 Ethereum Core Geliştiriciler Toplantısı #111'de EIP-2537, karmaşıklık nedeniyle Londra yükseltmesinden çıkarıldı. Temel karmaşıklık, EIP-2537 standart uygulamasının bağımlı kitaplıkların yerini almasında yatmaktadır, bu da gaz fiyatlandırmasında olası değişikliklere ve farklı müşteri uygulamalarının gaz tüketimini yeniden değerlendirmesi için önemli miktarda zamana yol açmaktadır.
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 zamanını aldı; yürütme katmanı geliştiricileri PoS yükseltmesini gerçekleştirmek için çok fazla kod yazmak zorunda kaldı. 2022 Eylül'ünde, 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 Devs Meeting #150'de EIP-2537'nin Shanghai yükseltmesine dahil edilip edilmeyeceği kısa bir şekilde tartışıldı, ancak geliştiriciler EIP-2537'nin ertelenmesi gerektiğine karar verdiler. Shanghai yükseltmesinin temel amacı PoS çekimlerini desteklemektir. Sonunda, EIP-2537, çekim işlevselliğini merkezine alan Shanghai yükseltmesine dahil edilmedi.
Daha da acı bir durum, Cancun yükseltmesinin EIP-2537 üzerinde hiç tartışma yapmamış olmasıdır çünkü Cancun yükseltmesinin ana hedefi, yürütme katmanı düğümlerinin EIP-4844'ü desteklemesidir. EIP-4844, Ethereum'un ikinci katmanına, Ethereum'u veri kullanılabilirlik katmanı olarak kullanmayı kolaylaştırmak için Blob sağlamaktadır.
Sonunda, 2024 Şubat ayında gerçekleşen Ethereum Core Devs Meeting #181'de, geliştiriciler Pectra yükseltmesine EIP-2537'nin dahil edilmesini tartıştılar ve o anda geliştiriciler EIP-2537'nin uygulanmasının artık bir sorun olmadığını, yalnızca Gas tüketim fiyatlandırması açısından bazı sorunların bulunduğunu düşündüler.
2024 Aralık 19'daki Ethereum Core Devs Meeting #202 内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的 Ethereum Core Devs Meeting #203'te, geliştiriciler BLS önceden derleme yeniden fiyatlandırmasını tartıştılar. Geth geliştiricisi Jared Wasinger, gaz maliyetinin %20 artırılmasını önerdi ve bu öneri Besu ekibinin referans testleriyle desteklendi.
Özet
Görülüyor ki, EIP'nin Ethereum güncellemesine dahil edilip edilmeyeceği, "elbette kendi çabalarına bağlı, ancak tarihin seyrini de göz önünde bulundurmak gerekir". Her Ethereum güncellemesinin kendi teması vardır; EIP-2537 bir dönem Berlin güncellemesinin en önemli EIP'si haline gelmişti, ancak uygulanabilirlik zorluğu ve karmaşıklığı nedeniyle terk edildi. Ardından Ethereum, PoS tarihine girdi; karmaşık saf yürütme katmanı EIP'leri önemsenmedi, PoS ile ilgili çok sayıda yürütme EIP'si temel güncelleme hedefi olarak değerlendirildi, bu da uzun bir süre boyunca EIP-2537'nin kabul edilmemesine neden oldu.
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Ethereum yönetim gözlemi: EIP-2537 ön derleme süreci｜GCC Araştırma
Yazı: shew
Genel Bakış
EIP-2537, Pectra'nın en son fork yükseltmesinde eklenmesi belirlenen EVM ön-derleme talimatıdır. Bu talimat, EVM'ye BLS12-381 eğrisi ile ilgili çeşitli hesaplama yetenekleri 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 güncellemesine dahil edilmesi onaylandı. Bu makale, EIP-2537'nin yönetişim tarihini ana hatlarıyla ele almakta ve bu önerinin neden 5 yıl sonra güncellemeye dahil edildiğini araştırmaktadır.
Teklifin Arka Planı
2017 yılının Ocak ayında, Vitalik Buterin Exploring Elliptic Curve Pairings adlı çalışmasında ilk kez eşleme algoritması ve alt_bn128 eğrisini tanıttı. Ardından, 2017 yılının Şubat ayında, Vitalik Buterin ve Christian Reitwiessner EIP-196 ve EIP-197 önerilerini sundular; bu önerilerin içeriği EVM'ye alt_bn128 eğrisi hesaplama desteği eklemektir.
2017 yılının Ekim ayında yapılan Byzantium yükseltmesinde, alt_bn128 eğrisi resmi olarak dahil edilmiştir. Kısacası, alt_bn128, EVM içinde eğri alan eşleme hesaplamasını ilk kez gerçekleştirmiştir, bu da ZK-Snarks kanıt doğrulamasının EVM içinde tamamlanabileceği anlamına gelmektedir.
Ancak kriptolojinin gelişmesiyle birlikte, 2017 yılının Kasım ayında, zcash geliştirme ekibi BLS12-381: Yeni zk-SNARK Eliptik Eğri Yapımı başlıklı çalışmada BLS12-381 eğrisini ilk kez tanıttı. alt_bn128 ile karşılaştırıldığında, BLS12-381 daha yüksek güvenlik ve daha iyi performans sunmaktadır. Bu tarihten sonra birçok blockchain protokolü BLS12-381 eğrisini kullanmaya başladı ve alt_bn128 eğrisini terk etti.
Mayıs 2018'de, Justin Drake ethresear'da BLS ile Pratik imza birleştirme başlıklı bir makale yayınladı ve Ethereum'un gelecekteki PoS ve parçalama yükseltmelerinin BLS12-381 eğrisi temelinde BLS çoklu imza algoritmasını kullanabileceğini belirtti. O zamanlar, Ethereum araştırmacıları konsensüs katmanı sorununu EIP-1011 ile çözmeyi 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 boyutu belirlenmişti. BLS çoklu imza çözümünün önerilmesiyle, EIP-1011 tarih sahnesinden çekildi. Sonuç olarak, sonraki ETH2 yükseltmelerinin de nihayetinde BLS12-381 eğrisini kullandığı kanıtlandı.
ETH2 geliştirmeleriyle birlikte, ETH2'nin kullandığı BLS12-381'in ETH yürütme katmanına dahil edilmesi çağrısında bulunuldu. Şubat 2020'de bazı araştırmacılar EIP-2537'yi önerdi ve bu önerinin ETH2 test ağında test edilmesini umdular. EIP-2537'nin yazarı Alex Stokes, What eth2 needs from eth1 over the next six months adlı makalede EIP-2537'nin Berlin hard fork'unda dahil edilmesi çağrısında bulundu.
İlginçtir ki, EIP-2537'nin yazarı aynı zamanda Matter Labs'ın kurucu ortağıdır ve Matter Labs'ın en ünlü ürünü ZKSync'tir.
Berlin kargaşası
İlerleyen içeriklere girmeden önce EIP-1962'yi tanıtmalıyız. EIP-1962, Matter Labs'ın 2019'un Nisan ayında önerdiği, eliptik eğri alanı eşleme önceden derleme ile ilgili ilk tekliftir ve bu teklif üç eğriyi desteklemektedir, bunlar şunlardır:
Bu EIP, farklı eğrileri işlemek için bir kerede 10 ön derleme talimatı eklemeyi planlıyor. Ancak bu öneri doğduktan sonra, oldukça fazla geliştirici önerinin karmaşık olduğu ve geliştiricilerin bunu gerçekleştirmesinin zor olduğu konusunda şüpheler dile getirdi. Ayrıca, EIP1962'nin son derece genel olması nedeniyle, akıllı sözleşme mühendisleri için çağrı yapmak da oldukça zahmetli. Elbette, EIP-1962'nin önericisi olan Matter Labs, esasen eliptik eğri algoritmasının geliştirme işini tamamladı ve Rust / Go / C++ referans uygulamaları sağladı.
EIP-1962 sorununu çözmek için Matter Labs, 2020 yılı Şubat ayında EIP-1962'yi bölerek birçok EIP önerdi. Bu EIP'ler, EIP-1962'nin arayüzünü kısmen devralmaktadır. Bu EIP'ler şunlardır:
Bu birkaç EIP arasında en önemlisi EIP-2537'dir çünkü konsensüs katmanı 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ğrulaması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 yanlış olduğu tespit edilirse (yeni doğrulayıcılar için), depo başarısız olacak ve kullanıcının yatırdığı ETH kaybolacaktır.
Bu bağlamda, çekirdek geliştiriciler, kullanıcıların ETH2 fonlarını yatırırken olası zararlarını önlemek için mevduat sözleşmesine BLS12-381 ön derlemesini dahil etmeyi umuyorlar. Bu, o dönemde birçok geliştiricinin EIP-1962 ve EIP-2537'ye odaklanmasının da 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, ardından EIP yazarları buna yanıt ve tartışma yaptılar. Ardından, 6 Mart 2020 tarihinde Ethereum Core Devs Meeting #82 toplantısında, Ethereum ana geliştiricileri EIP-2537'yi tartıştılar. Bu toplantıda, Vitalik EIP-2537 gibi EIP'lerin tekrarlayan SNARK kanıtları için son derece etkili olduğunu ve uzun vadede Ethereum'a zarar vermeyeceğini düşündü. Aynı zamanda, toplantıda EIP-2537'nin öncelik durumu 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 hala ilk olarak tartışılan öneri oldu. Bu toplantıda EIP-2537'nin EIP-1962'yi değiştirdiği ve Berlin yükseltmesinin öncelikli EIP listesine dahil edildiği onaylandı ( yani Dahil Olma Uygunluğu (EFI)).
2020 yılının Nisan ayında gerçekleştirilen Ethereum Core Devs Meeting #84 toplantısında, toplantı resmi olarak EIP-2537'yi Berlin sert fork yükseltmesine dahil etti ve Nisan ayında uygulamaya geçilmesi, Mayıs - Haziran aylarında test edilmesi için Berlin yükseltme zaman çizelgesini belirledi. Dikkate değer bir şekilde, bu tartışmada EIP-2537 en yüksek öncelikli konu olarak listelendi.
Daha sonra, EIP-2537 büyük bir geliştirme ve test aşamasına girdi. Sonraki yaklaşık 20 temel geliştirici toplantısında, her toplantıda temel olarak EIP-2537 hakkında tartışmalar yapıldı. Şimdi, her toplantıda EIP-2537 ile ilgili hangi konuların tartışıldığını gözden geçirebiliriz.
Ethereum Core Geliştiricileri Toplantısı #85'te, Danno ve Axic EIP-2537'nin ABI kodlama sorununu tartıştılar. Ardından, ana geliştiriciler mevcut uygulama durumunu senkronize ettiler. EIP-2537'nin önericisi Matter Labs daha önce Rust sürümünün uygulamasını neredeyse tamamladığı için, Besu istemcisi EIP-2537'nin işlevselliğini neredeyse gerçekleştirdiğini açıkladı. Ancak Geth cephesi şu anda EIP-2537'nin uygulanması için kimsenin çalışmadığını belirtti.
Ethereum Core Geliştiricileri Toplantısı #86'da, farklı Ethereum düğüm uygulamaları EIP-2537'nin uygulama durumunu tekrar senkronize etti; Geth, bazı çalışmaların tamamlandığını ancak tamamlanmayı bekleyen büyük bir iş olduğunu belirtti.
Ethereum Core Devs Meeting #87'de, bu geliştirici toplantısının en temel içeriği EIP-2537'nin uygulanmasıydı. Geth geliştiricileri şu anda EIP-2537'yi uygulayan 16000 satırlık bir PR'nın bulunduğunu belirtti, ancak Geth geliştiricileri PR'nın EIP-2537'yi güvenli ve etkili bir şekilde uygulayıp uygulamadığından emin olamıyorlar, bu yüzden geliştiriciler kodun durumunu değerlendirmek için en basit ve kaba yöntem olan bulanık testler ile değerlendirme yapmak zorunda kalıyorlar.
Geth geliştiricisi şunları söyledi: "Yani içgüdüsel olarak, Geth'in Temmuz'daki ana ağ lansmanı için BLS eğrisi işlemleriyle hazır olma şansının olmadığını düşünüyorum." yani Geth'in Berlin'deki belirlenen zamanında EIP-2537 ile ilgili geliştirmeleri tamamlaması büyük ihtimalle mümkün değil.
Hudson Jameson, Geth için PR incelemesine yardımcı olacak bir kriptografi mühendisinin bulunmasını önerdi ve EIP-2537'nin uygulanabilirliğinin güvenliğini test etmek için bir test ağı kullanılmasını önerdi. O sırada ETH2 geliştirme ekibi de BLS imza doğrulamasını uyguluyordu, bu nedenle ETH2 ekibi testlere katılabilir.
Burada, Geth'in EIP-2537 uygulama PR'sının verimliliği sağlamak için büyük ölçüde assembly kodu kullandığına dair bir arka plan bilgisi eklememiz gerekiyor; bu assembly kodunun okunması ve anlaşılması oldukça zor. Bu nedenle, Alex Vlasov, inceleme zorluğunu azaltmak için PR içindeki karmaşık assembly optimizasyonlarının çıkarılmasını önerdi.
Daha önce EIP-2537'nin bir ana hedefinin ETH2 depo sözleşmesine yardımcı olmak olduğunu açıkladık, ancak bu toplantıda depo sözleşmesi geliştiricileri EIP-2537'yi kullanmayan depo sözleşmesinin denetlendiğini belirtti, bu nedenle bazı geliştiriciler, EIP-2537'yi kullanan bir depo sözleşmesi oluşturulmasının en iyisi olmayacağını önerdi.
Sonunda, toplantıda YOLO test ağının eklenmesine karar verildi, bu test ağının temel amacı EIP-2537'yi test etmektir. Aslında, bu toplantıda depo sözleşmesinin tamamlanmasıyla birlikte EIP-2537'nin öneminin önemli ölçüde azaldığını görebiliriz; ayrıca Geth geliştiricileri bu EIP'nin Berlin yükseltmesi öncesinde uygulanamayacağına dair güçlü bir kanaate sahipler. Görünüşe göre EIP-2537'nin Berlin yükseltmesi tarafından kabul edilmemesi artık kesinleşmiş durumda.
Ethereum Core Geliştirici Toplantısı #88'de, Geth geliştiricileri EIP-2537'nin uygulama PR'sında bir dizi sorun buldular ve geliştiriciler daha fazla test ve düzeltme yapılması gerektiğini belirttiler. Bu esnada Geth sisteminde iki EIP-2537 uygulaması mevcut, bunlardan biri montaj 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ılan versiyonun kullanılmasını önerdi.
Ethereum Core Geliştiricileri Toplantısı #89'da, daha ciddi bir sorun ortaya çıktı, YOLO testinde bazı problemler yaşandı, geliştiriciler bunun BLS imzasından kaynaklandığını düşündü, ancak EIP2537 geliştiricileri buna karşı çıktı ve test ağındaki sorunun BLS imzasından kaynaklanmadığını belirtti. EIP-2537 için iyi haber ise, EIP-2537 temelinde yapılan depo sözleşmesinin neredeyse tamamlandığı ve bu sözleşmenin sözleşme denetimini beklediğidir.
Ethereum Core Devs Meeting #90 内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91 toplantısında, bir geliştirici modüler bir çözüm kullanarak geliştirme maliyetlerini azaltmayı ve istemci çeşitliliğini artırmayı önerdi. Eğer okuyucular Ethereum istemci çeşitliliği ile ilgileniyorlarsa, bu iki toplantının kayıtlarını okuyabilirler.
Ethereum Core Geliştiricileri Toplantısı #92'de, 2537 hala Berlin yükseltmesi için gereken EIP olarak doğrulandı.
Ethereum Core Devs Meeting #96'da, Celo tabanlı olarak EIP-2537 ve EIP-2539'un aynı anda ağının sert çatal yükseltmesine dahil edildiği belirtildi, bu nedenle Matter Labs, EIP-2539'un da EIP-2537 ile birlikte YOLO v2 test ağında test edilmesini ve Berlin yükseltmesine dahil edilmesini umuyordu. Ancak Geth geliştiricileri, mevcut EIP-2537'nin Geth içinde tam olarak test edilmediğini savunarak karşı çıktılar. Sonunda toplantıda Berlin yükseltmesine 2696 eklenmemesine ve gelecekte tartışılmasına karar verildi.
Ethereum Core Devs Meeting #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 kaybetmesine neden olması ve Berlin yükseltmesi içindeki diğer EIP geliştirmelerini engellemesidir. İkinci bir faktör ise Ethereum Vakfı'nın EIP-2537'nin yerine 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 getirmiştir.
Yukarıda belirtilen içerik, EIP-2537'nin erken dönemini anlatmaktadır. EIP-2537'nin erken döneminin Berlin yükseltmesindeki en önemli EIP'lerden biri olduğunu görebiliriz; ancak uygulama sorunları nedeniyle nihayetinde iptal edilmiştir. Sonuç olarak, 2021 Nisan ayında Ethereum Berlin yükseltmesini tamamladı; yükseltmenin çekirdeğinde yer alan EIP-2565 gibi gerçek uygulamalar oldukça karmaşık değildir. Berlin yükseltmesi biraz zayıf görünmektedir, çünkü en karmaşık çekirdek EIP-2537 Berlin yükseltmesinden çıkarılmıştır.
Son Gelişmeler
Herkes tarafından bilindiği gibi, Ethereum'un her güncellemesi bir ana öneri ile birlikte gelir; örneğin, Berlin güncellemesinden sonra Londra güncellemesi, Ethereum tarihindeki en önemli işlem ücreti önerisi olan EIP-1559'u getirmiştir. Daha önce bir ana öneri olarak değerlendirilen EIP-2537 için, sonraki tüm güncellemelerin bu öneriyi kapsaması oldukça zordur.
Berlin'den sonraki Londra yükseltmesinde, geliştiriciler issues#369 曾考虑在 London 升级中增加 EIP-2537。在 Ethereum Core Devs Meeting #109'de EIP-2537'nin mevcut gelişimini senkronize ettiler ve şu anda EIP-2537'yi uygulamak için diğer kütüphanelerin kullanılması nedeniyle EIP-2537 için gaz kullanımı hakkında bir tartışma başlattılar. Aynı zamanda, bazı geliştiriciler EIP-2537'yi EVM384 ile değiştirmeyi önerdiler. Ancak, Nisan 2021 Ethereum Core Geliştiriciler Toplantısı #111'de EIP-2537, karmaşıklık nedeniyle Londra yükseltmesinden çıkarıldı. Temel karmaşıklık, EIP-2537 standart uygulamasının bağımlı kitaplıkların yerini almasında yatmaktadır, bu da gaz fiyatlandırmasında olası değişikliklere ve farklı müşteri uygulamalarının gaz tüketimini yeniden değerlendirmesi için önemli miktarda zamana yol açmaktadır.
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 zamanını aldı; yürütme katmanı geliştiricileri PoS yükseltmesini gerçekleştirmek için çok fazla kod yazmak zorunda kaldı. 2022 Eylül'ünde, 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 Devs Meeting #150'de EIP-2537'nin Shanghai yükseltmesine dahil edilip edilmeyeceği kısa bir şekilde tartışıldı, ancak geliştiriciler EIP-2537'nin ertelenmesi gerektiğine karar verdiler. Shanghai yükseltmesinin temel amacı PoS çekimlerini desteklemektir. Sonunda, EIP-2537, çekim işlevselliğini merkezine alan Shanghai yükseltmesine dahil edilmedi.
Daha da acı bir durum, Cancun yükseltmesinin EIP-2537 üzerinde hiç tartışma yapmamış olmasıdır çünkü Cancun yükseltmesinin ana hedefi, yürütme katmanı düğümlerinin EIP-4844'ü desteklemesidir. EIP-4844, Ethereum'un ikinci katmanına, Ethereum'u veri kullanılabilirlik katmanı olarak kullanmayı kolaylaştırmak için Blob sağlamaktadır.
Sonunda, 2024 Şubat ayında gerçekleşen Ethereum Core Devs Meeting #181'de, geliştiriciler Pectra yükseltmesine EIP-2537'nin dahil edilmesini tartıştılar ve o anda geliştiriciler EIP-2537'nin uygulanmasının artık bir sorun olmadığını, yalnızca Gas tüketim fiyatlandırması açısından bazı sorunların bulunduğunu düşündüler.
2024 Aralık 19'daki Ethereum Core Devs Meeting #202 内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的 Ethereum Core Devs Meeting #203'te, geliştiriciler BLS önceden derleme yeniden fiyatlandırmasını tartıştılar. Geth geliştiricisi Jared Wasinger, gaz maliyetinin %20 artırılmasını önerdi ve bu öneri Besu ekibinin referans testleriyle desteklendi.
Özet
Görülüyor ki, EIP'nin Ethereum güncellemesine dahil edilip edilmeyeceği, "elbette kendi çabalarına bağlı, ancak tarihin seyrini de göz önünde bulundurmak gerekir". Her Ethereum güncellemesinin kendi teması vardır; EIP-2537 bir dönem Berlin güncellemesinin en önemli EIP'si haline gelmişti, ancak uygulanabilirlik zorluğu ve karmaşıklığı nedeniyle terk edildi. Ardından Ethereum, PoS tarihine girdi; karmaşık saf yürütme katmanı EIP'leri önemsenmedi, PoS ile ilgili çok sayıda yürütme EIP'si temel güncelleme hedefi olarak değerlendirildi, bu da uzun bir süre boyunca EIP-2537'nin kabul edilmemesine neden oldu.