Yazar: shew

Genel Bakış

Pectra yükseltmesinde en karmaşık yönetişim anlaşmazlığı sorunları ortaya çıktı. EIP3074 Pectra yükseltmesine dahil edildikten sonra büyük bir tartışma yarattı, özellikle de ERC4337 ekibinin karşı çıkmasıyla.

EIP3074 bir çıkmaza girdi, yönetim süreci devam edemedi. Vitalik'in EIP7702'yi önermesine kadar ERC4337 ekibinin EIP3074'e yönelik sorgulamaları sona ermedi.

GCC Research, Pectra yükseltmesi sırasında EIP3074 ve ERC7702'nin yönetişim sorunlarının Çin dünyasında pek az tartışıldığını keşfetti. Ancak bu yönetişim sorunu, Ethereum yönetişiminin derin sorunlarını yansıtmaktadır; yani, code is law öncülünde, kodun belirli içeriğini kim kontrol edebilir. EIP3074 ve ERC7702'nin yönetişim sorunları, Ethereum'un iç gerçek yönetişim süreçlerini gözlemlemek için bize iyi bir perspektif sunabilir.

Bu makalenin nihai sonucu, ZeroDev tarafından yayınlanan ve Ethereum yönetişim sisteminin bir VVRC modeli olduğunu ve herhangi bir teklifin dahil edilmesinin önce (Value) Ethereum değerleriyle uyumlu olması gerektiğini ve ardından teklifin Vitalik tarafından tasarlanan vizyonu yansıtması gerektiğini belirten bir görüş yazısından bir alıntıdır (Vision), nihai teklif (Roadmap) yol haritasına yansıtılmalı ve son olarak çekirdek geliştiriciler tarafından tartışılmalı ve müşteriye dahil edilmelidir (Client) Uygulama.

GCC Research, önceki makalede bahsedilen EIP2537'nin yalnızca İstemci katmanında uygulama sorunları nedeniyle nihayetinde sert çatallamaya dahil edilmediğini, EIP3074'ün ise Vizyon ve Yol Haritası sorunları nedeniyle nihayetinde sert çatallamaya dahil edilmediğini belirtmektedir. Ethereum ana geliştiricileri, nihai hesap soyutlama önerisi olarak doğrudan Vitalik'in yazdığı EIP7702'yi seçtiler.

Teklifin İçeriği Özeti

Belirli yönetişim süreçlerini tanıtmadan önce, öncelikle bu makalede bahsedilen EIP3074, EIP7702 ve ERC4337'nin içeriğini kısaca tanıtmamız gerekiyor.

EIP3074, düğüm yazılımı güncellemesi gerektiren bir yürütme katmanı önerisidir. EIP3074'ün temel amacı, gaz sponsorlama ve toplu işlem işlevlerini gerçekleştirmektir. Gaz sponsorlama, kullanıcıların gaz ücretlerini herhangi bir token ile ödeyebilecekleri veya kullanıcıların gaz ücretlerini çevrimdışı olarak ödeyebilecekleri anlamına gelir. Ancak dikkat edilmesi gereken husus, diğer hesap soyutlama önerilerinin imza doğrulama algoritmalarını değiştirmesine izin vermesine rağmen, EIP3074'ün kullanıcıların secp256k1 dışındaki herhangi bir imza algoritmasını kullanmasına izin vermemesidir. Başka bir deyişle, EIP3074, tüm hesap soyutlama işlevlerini karşılayan bir öneri değildir. Bu, EIP3074'ün eleştirilmesinin bir nedenidir.

Beklenen hedefe ulaşmak için, EIP3074 iki opcode tanıtır: AUTH ve AUTHCALL. AUTH opcode'u imzayı doğrulayarak çalışır; imza doğrulaması başarılı olduğunda, bu opcode mevcut EVM bağlamındaki authorized'ı imza sahibinin adresi olarak ayarlar. Bağlamdaki authorized ayarlandıktan sonra, AUTHCALL authorized adresini işlem gönderen msg.sender olarak kullanarak işlem başlatabilir. Bir bakıma, kullanıcı imza ile kendi hesabını bir işlemde bir akıllı sözleşmeye devretmiş olur. Biz genellikle bu kullanıcı tarafından devredilen akıllı sözleşmeye invoker sözleşmesi deriz.

O kullanıcının imza içeriği nedir? Kullanıcının aşağıdaki içeriği imzalaması gerekiyor:

Yukarıdaki içerikteki invoker address, kullanıcının yetkilendirmek istediği invoker sözleşmesi adresini ifade eder. EVM, kullanıcının imza içeriğini ve gerçek imza doğrulama sözleşmesini karşılaştırarak kullanıcının AUTH imza içeriğinin diğer sözleşmeler tarafından kullanılmasını engeller.

Nonce ise işlemlerin tekrar oynatılmasını engelleyen bir tanımlayıcıdır. Bununla birlikte, AUTH işlem kodunun, imzadaki nonce'nin halihazırda imzalanmış olan EOA'nın nonce'u ile tutarlı olup olmadığını doğrulayacağına ve teorik olarak kullanıcı, nonce değerini artırmak için bir işlem başlatmak için EOA hesabını kullanmadığı sürece, kullanıcı tarafından verilen AUTH imzası her zaman çağıran sözleşme tarafından kullanılabilir. Bu çok büyük bir güvenlik açığıdır ve EIP3074 kullanan kullanıcıların, imzayı alan aktarma hizmeti sağlayıcısına güvenmesi gerektiği anlamına gelir. Kullanıcının imzasını alan aktarma hizmeti sağlayıcısı kötü amaçlıysa, hizmet sağlayıcı kullanıcının varlıklarını çalmak için bir noktada kullanıcının AUTH imzasını yeniden oynatabilir.

Bir diğer güvenlik sorunu da commit alanıdır. Commit alanı, belirli işlemleri garanti etmek için kullanılır ve kullanıcılar, imza içeriklerinin ETH transferleri için kullanılmasını önlemek için taahhütte bazı içerikler yazmak gibi, taahhütteki imza izinlerini kontrol etmek için ince ayar yapabilir. EIP3074 belgede, teklif sahibi, taahhüt alanını kullanmanın bir dizi örneğini verir. Ancak sorun şu ki, taahhüdün rolü tamamen akıllı sözleşme tanımına bağlıdır ve esasen isteğe bağlı bir içeriktir. Farklı akıllı sözleşmeler, taahhütteki içeriği tamamen tutarsız bir şekilde ayrıştırabilir ve hatta bazı sözleşmeler taahhüdün içeriğini hiç okumayabilir. EIP3074 güvenli bir şekilde kullanmak istiyorsanız, akıllı sözleşmeyi kendiniz gözden geçirmeniz yeterlidir.

Son olarak, bir EIP3074 mevcut Ethereum işlem mempool'u üzerindeki etkisine bir göz atalım. EIP3074'nin kullanıma sunulmasıyla birlikte, bir bilgisayar korsanı işlemleri başlatmak için çok sayıda hesap kullanabilir ve ardından işlem paketlenmek üzereyken bu hesaplardaki ETH'yi bir kerede boşaltmak için EIP3074 işlemleri kullanabilir ve bu da daha önce başlatılan tüm işlemlerin başarısız olmasına neden olur. Bu tür bir saldırı, yürütme katmanı düğümleri üzerinde önemli bir etkiye sahip olabilir ve esasen bir DoS saldırısıdır. Bununla birlikte, EIP3074 yerini almak için kullanılan EIP7702 da bu soruna sahip olduğuna, ancak EIP7702 daha sonra tartışacağımız bu sorunu önlemek için bazı sınırlamalar getirdiğine dikkat edilmelidir.

Yukarıda bahsedilen EIP3074'ün kendisinde var olan sorunların yanı sıra, ERC4337'nin yazarı Yova, EIP-3074'ün dahil edilmesinin Etkileri başlıklı makalede daha fazla karşıt görüşü tanıttı. Kısacası, bu görüşler esas olarak şunları içermektedir:

1. Merkezileşme riski. AUTH imzasının özel özellikleri nedeniyle, kullanıcılar EIP3074'ün aracılık hizmet sağlayıcılarına ve temel altyapısına tamamen güvenmek zorundadır. Aynı zamanda, şu anda ERC4337 gibi hesap soyutlama protokolleri ile inşa edilen altyapı, EIP3074 ile tamamen uyumsuzdur.
2. Kullanıcı güvenliği. Yukarıda belirtildiği gibi, EIP3074'ün standart bir tasarım yetki kontrol yöntemi yoktur ve imza nonce tasarımında da güvenlik açıkları bulunmaktadır; bu da ciddi güvenlik sorunlarının ortaya çıkma olasılığını artırmaktadır.
3. Tamamlanmamış hesap soyutlama işlevi. Diğer hesap soyutlama önerileri ile kıyaslandığında, EIP3074 tam değildir ve kullanıcı imza algoritmasını değiştirme gibi işlevleri gerçekleştiremez.
4. Kullanıcı deneyiminde sorun var. Kullanıcıların hesaplarını akıllı sözleşmelere devretmeleri gerektiğinde, bir AUTH imzası yapmaları gerekir ve ardından AUTH imzasını içeren çağrıyı zincire yayınlamaları gerekir. Kullanıcıların iki kez imza yapması gerekiyor.

EIP7702, Vitalik tarafından önerilen EIP3074'ü değiştirmek için bir öneridir. Bu öneri yeni bir EVM opcode'u getirmemekte, bunun yerine SET_CODE_TX_TYPE olarak adlandırılan yeni bir işlem türü sunmaktadır. Kullanıcı EIP7702 türünde bir işlem başlattığında, kendi EOA'sını EOA'nın temel işlevselliğini koruyarak akıllı sözleşme işlevselliği ile artırabilir. Kısacası, kullanıcılar hem MetaMask gibi cüzdanlarla işlem başlatmaya devam edebilir hem de diğer kullanıcılar EOA adresini akıllı sözleşme biçiminde çağırabilir.

Basit bir toplu ticaret örneği ile EIP7702 özelliklerine bakalım. Kullanıcılar, EOA adreslerini toplu aramalar gerçekleştirebilen bir akıllı sözleşmeye devretmek için EIP7702 kullanabilir ve ardından kullanıcılar, toplu işlemleri başlatmak için EOA adreslerini akıllı sözleşme biçiminde doğrudan arayabilir.

Teknik gerçekleştirme açısından EIP7702'nin tanıttığı işlem türü, geleneksel işlemlere kıyasla authorization_list listesini eklemektedir. Bu listenin içeriği [[chain_id, address, nonce, y_parity, r, s], ...] şeklindedir. Burada address, kullanıcının yetki vermek istediği akıllı sözleşme adresidir ve nonce, kullanıcının mevcut nonce değeridir. Kalan y_parity, r ve s ise kullanıcının imza sonuçlarıdır. Uygulama sürecinde, öncelikle authorization_list içindeki her bir öğeyi işlemek için döngüye giriyoruz; işlem yöntemi y_parity gibi imza parametrelerini kullanarak EOA adresini geri çıkarmaktır. Ardından EOA adresi, address olan akıllı sözleşmeye yönlendirilir. Sonrasında EOA adresi, sözleşmenin işlevlerini yerine getirmesi için çağrı alabilir.

EIP7702'nin avantajları son derece belirgindir, bunların en temel avantajı EIP7702'nin esasen EOA'nın akıllı sözleşmelere sahip olmasına izin vermesidir. Bu, ERC4337 gibi hesap soyutlamasının temel kurallarıyla tutarlıdır, bu da EIP7702'nin mevcut hesap soyutlama alanında yapılan tüm keşiflerden yararlanabileceği ve mevcut altyapıyı yeniden kullanabileceği anlamına gelir; örneğin, EIP7702 doğrudan ERC4337'nin altyapısını kullanabilir. Şu anda ERC4337, EIP7702 çağrılarını destekleyen EntryPoint v0.8'i piyasaya sürdü. Mevcut altyapıyı yeniden kullanma açısından EIP7702, ERC4337 ile eşit bir merkeziyetsizlik derecesine sahiptir.

Elbette, EIP7702 aslında EIP3074'te ortaya çıkan sorunları tamamen çözmüş değil. EIP3074'teki birçok sorun hâlâ devam ediyor. EIP7702, hesap sözleşmelerinin güvenli bir uygulamaya sahip olmasını talep ederken, protokol kendisi herhangi bir güvenlik garantisi vermemektedir. EIP7702'nin ilk aşamalarında, bazı geliştiriciler olası yeniden oynatma saldırılarını önlemek için imza nonce'unun standartlaştırılmasını önermişti, ancak EIP7702 sonunda bu önerileri kabul etmedi. Bu nedenle, kullanıcılar EIP7702'yi güvenli bir şekilde kullanmak istiyorlarsa, sözleşme güvenliğini kendileri denetlemeleri gerekecek.

Aynı zamanda EIP7702, yürütme katmanına bir dizi sorun getirecektir. Yukarıda EIP3074'ün yürütme katmanı bellek havuzuna yönelik DoS saldırısı için olası bir kullanımını tanıttık. Bu yöntem EIP7702'de de geçerlidir. Bu nedenle EIP7702, EIP7702'yi kullanan tüm EOA adreslerinin bellek havuzunda yalnızca bir bekleyen işlem bulundurmasını önerir, böylece büyük ölçekli DoS saldırılarının ortaya çıkmasını önler.

Sonuç olarak, EIP3074'ün en büyük sorunu, EIP3074'ün tam bir hesap soyutlama işlevini gerçekleştirmemesi, oysa EIP7702 tam bir hesap soyutlama işlevini gerçekleştirmiştir. "Tam hesap soyutlaması"nın neyi içerdiğini tanımlayan ise ERC4337'nin yazarlarıdır. Buraya kadar okuyan okuyucu, EIP3074'ün ERC4337 ekibi tarafından neden karşı çıkıldığını ve nihayetinde EIP7702 ile neden yer değiştirdiğini anlamış olmalıdır. İlerleyen bölümlerde genel yönetim ve tartışma sürecinin tamamını tanıtacağız.

EIP3074 ve EIP7702'nin yönetim süreci

EIP3074, Ethereum çekirdek geliştiricileri toplantısında çok erken bir dönemde bahsedilmiştir. 2 Nisan 2021 tarihinde yapılan Meeting #109'da, Ethereum çekirdek geliştiricileri EIP3074 hakkında basit bir tartışma yapmışlardır. Tartışma sonucu oldukça basitti:

1. Alexey, EIP3074 imza içeriğinin güvenlik riski taşıdığını ve kullanıcılar için ciddi güvenlik kayıplarına neden olabileceğini öne sürdü. EIP3074'ün AUTH imzasının belirli içeriğini daha fazla standartlaştırmasını önerdi. Bu öneri Martin tarafından desteklendi.
2. James, EIP3074'ün potansiyel yürütme katmanı açıkları, örneğin DoS saldırıları gibi, getirebileceğini öne sürdü ve EIP3074'ün yazılı bir tehdit analizi sağlamasını önerdi.
3. Alexey ve Martin, EIP3074 belgesinin kalitesinin ortalama olduğunu, okumak ve anlamak için çok fazla zaman harcadıklarından şikayet ettiler.
4. Martin, EIP3074'ün özünün uygulamalarla, özellikle cüzdan geliştiricileriyle işbirliği ve gerçekleştirme olduğunu düşünüyor. EIP3074'ün yazarları, uygulama geliştiricileriyle bir dizi iletişimde bulunduklarını belirtti.

İlginç olan, Vitalik'in bu toplantıda her halükarda Ethereum'un EOA için tasarlanmış bir işlemle birden fazla çağrı üreten bir teknik çözüme ihtiyaç duyduğunu düşünmesidir. EIP3074'ün potansiyel güvenlik sorunları olsa da, EIP3074 geliştiricilerin ilerlemesi gereken bir olası teknik çözüm sunmaktadır.

Açıkça, EIP3074'ün güvenlik sorunları nedeniyle, bu toplantıda EIP3074 London yükseltmesine dahil edilmedi.

11 Haziran 2021'de Toplantı #115'te EIP3074 geliştiriciler, EIP3074 güvenlik sorunlarına odaklanan güvenlik denetimleri hakkında bir rapor sundu. Basit sonuç, EIP3074 çağıran sözleşmesinin sistemde çok önemli olduğudur, bu nedenle çağıran sözleşmenin yönetilmesi gerekip gerekmediği bir sorudur. EIP3074 geliştiriciler, ek güvenlik için çağıran sözleşmesini resmileştirmek istiyor.

Elbette, bazı tartışmalar msg.sender == tx.origin kullanarak çağrı adresinin EOA olup olmadığını belirlemekle ilgili. EIP3074 getirildiğinde, bu tür belirlemeler geçersiz hale gelecek, ancak bu belirlemelerin geçersiz hale gelmesinin ciddi bir güvenlik sorunu yaratmayacağı sonucuna varıldı. Kısacası, bu toplantının ana amacı, EIP3074'ün önericisinin, 3074'ün güvenlik denetim sonuçlarını ana geliştiricilere tanıtmasıydı. Toplantının nihai sonucu, 3074'ün invoker sözleşmesi sorununu da dikkate alması gerektiği, Londra sert çatala eklenmemesi önerisidir.

2021 yılı 25 Haziran'daki Meeting #116'da, ERC4337'nin ana yazarlarından Yova, EIP 3074 için daha basit bir alternatif önerisi olan A case for a simpler alternative to EIP 3074 adlı materyali sundu. Bu materyal, EIP3074'ün birçok güvenlik sorunu içerdiğini belirtiyor ve bazı içeriklerin değiştirilmesini öneriyor. Örneğin, imza içindeki commit alanının içeriğini kısıtlamayı ve commit alanının {nonce,to,gas,calldata,value,chainid} biçiminde olmasını zorunlu hale getirmeyi öneriyor. Bu imza modeli kullanıldığında, EIP3074 yalnızca belirli belirli işlemleri gerçekleştirmek için kullanılabilir, böylece işlemlerin güvenliği sağlanmış olur.

Bu toplantıda EIP3074'ün yazarı Yova'nın sunduğu materyale yanıt verdi:

1. Invoker sözleşme adresinin EIP standartlarına dahil edilmesini umuyorum, ardından Ethereum ana geliştiricileri tarafından güvenli bir invoker sözleşmesi yazılmasını sağlayarak güvenlik sorunlarını önleyelim.
2. İmza içindeki commit içeriği hakkında, EIP3074 geliştiricileri bunun tamamen kullanıcılar ve cüzdan yazılımı ile ilgili bir sorun olduğunu ve EIP içinde bir standartlaştırmaya ihtiyaç olmadığını düşünüyor.

Vitalik bu toplantıda aşağıdaki üç maddeyi öne sürdü:

1. EIP3074 hâlâ geleneksel secp256k1 imza şemasını kullanıyor ve kuantum direncini gerçekleştiremiyor.
2. EIP3074'ün gelecekte uyumluluğu yoktur, EIP3074 kullanarak bir EOA'nın akıllı sözleşme hesabına evrilmesi mümkün değildir.
3. EIP3074'ün yaşam döngüsü sınırlıdır. 3074, AUTH ve AUTHCALL adlı iki önceden derlenmiş kod tanıttı, ancak hesap soyutlaması yol haritasına göre, gelecekte Ethereum içindeki tüm cüzdanlar akıllı sözleşme cüzdanı olabilir, EIP3074'ün önceden derlenmiş kodu gelecekte iptal edilebilir.

2022 yılının 4 Şubat'ındaki Meeting #131'de, geliştiriciler ShangHai güncellemesinin içinde bulunması gereken EIP türlerini tartıştılar. EIP3074 tartışma kapsamına alındı, ancak geliştiriciler sadece EIP3074'ün geliştirme dinamiklerini basit bir şekilde senkronize ettiler. Dikkate değer bir nokta, toplantıdan önce nethermind'ın Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337 başlıklı bir makale yazmış olmasıdır; bu makalede EIP3074'e karşı herhangi bir itiraz yer almamaktadır.

3 Ağustos 2023 tarihli Toplantı #167'de, çekirdek geliştiriciler başka bir EIP5806'yı tartışırken EIP3074'ten bahsettiler. EIP5806, EOA'nın işlem sırasında deleGate.io çağrısı ile dış sözleşmeleri aramasına izin veren bir yöntemdir. Bu çözüm, bir dereceye kadar EIP7702'ye benzerdir. Ancak çekirdek geliştiriciler bu çözümün güvenliği konusunda da endişelerini dile getirdiler; Ansgar, geçmişte EIP3074'ün muhtemel güvenlik sorunları nedeniyle hiç bir zaman sert bir hard fork'a dahil edilemediğini belirtti ve EIP5806'nın daha radikal bir çözüm olduğunu söyledi.

2024 yılının 29 Şubat tarihinde yapılan Meeting #182'de geliştiriciler EIP3074'ün Pectra yükseltmesine dahil edilip edilmeyeceğini detaylı bir şekilde tartıştılar. Vitalik, herhangi bir hesap soyutlama standardının aşağıdaki üç işlevi içermesi gerektiğini öne sürdü:

1. Anahtar Değişimi
2. Anahtar İhtiyaç Duyulmaması
3. Kuantum karşıtı imzalarla uyumlu olabilir

Vitalik, EIP5806'nın EIP3074'ten daha iyi bir seçenek olabileceğini belirtti. Andrew, EIP3074'ün EIP5806'ya göre daha genel olduğunu düşünüyor ve EIP3074'ün kullanılmasını öneriyor. Vitalik, Andrew'a itiraz etti ve gelecekte tüm cüzdanların akıllı sözleşme cüzdanları olabileceğini, bu durum gerçekleştiğinde EIP3074 tarafından getirilen ön derleme opcode'larının geçersiz olacağını savundu. ERC4337'nin yazarı Yoav, bu toplantıda uzun bir konuşma yaptı ve konuşmasının içeriği şunları içeriyordu:

1. EIP3074, Ethereum bellek havuzuna yönelik DoS saldırılarına yol açabilir ve ERC4337 bu konu üzerine yoğun bir araştırma yaparak saldırıları önlemek için bazı kurallar sunmuştur.
2. EIP3074, kullanıcıların toplu işlem başlatırken iki kez imza atmasını gerektiriyor, bu mantıksız.
3. EIP3074, merkezi bir aracının kullanılmasını gerektirir.

Yova, hesap soyutlama çözümü olarak EIP5806'yı kullanmayı daha çok tercih ediyor.

14 Mart 2024'teki Toplantı #183'te çekirdek geliştiriciler, cüzdanın EIP3074 hakkında ne düşündüğünü tartışmak için MetaMask'tan Dan Finlay'i davet etti. Dan, MetaMask'ın EIP3074'ın testini de destekleyeceğini belirterek EIP3074'den yana. MetaMask, EIP3074 EOA'nın hesap soyutlamanın tüm işlevlerinden yararlanmasını işlevsel olarak sağlayabileceğine inanmaktadır. Güvenlik açısından EIP3074, cüzdan servis sağlayıcıları için yani sıcak ve soğuk anahtar ayrımı için bir çözüm sunar. Cüzdan servis sağlayıcısı, bir işlemi başlatmak için EOA'nın EIP3074 imzasını tutabilir ve kullanıcılar normal işlemlerde sıcak özel anahtarı kullanabilir, ancak soğuk özel anahtar, kullanıcının donanım cüzdanında tutulabilir ve acil bir durum bulunduğunda, kullanıcı, EIP3074 imzasını iptal etmek için bir işlem başlatmak için soğuk cüzdandaki soğuk özel anahtarı kullanabilir. Bu sıcak ve soğuk özel anahtar ayrımı çözümü, cüzdan sağlayıcılarına esneklik sağlar.

Vitalik, EIP3074 içinde cüzdan tasarımcılarının kullanıcıların EIP3074 imzalarının kötüye kullanılmasını önlemek için katı yetkilendirme mantıkları tasarlaması gerektiğini belirtti. İlginç bir şekilde, MetaMask'ın EIP3074 işlevselliği eklenmesi üzerine tartışılırken, Vitalik, L2'nin bir geçiş çözümü olarak kullanılabileceğini belirtti; yani, herhangi bir yeni yürütme katmanı değişikliği öncelikle L2 içinde uygulanmalıdır, çünkü L2'nin fon miktarı sınırlıdır ve ciddi bir sorun meydana gelirse büyük kayıplara yol açabilir.

Dror Tiros, tartışmada EIP3074'ün güvenliğini sağlamanın en iyi yolunun Ethereum'un resmi olarak invoker sözleşmesini vermesi olduğunu belirtti. Ancak Dan Finlay, resmi sözleşme verilmesi fikrine karşı çıkarak, invoker sözleşmesinin tamamen kullanıcılar tarafından belirlenmesi gerektiğini, pazarın en güvenli invoker sözleşmesini sonunda seçeceğini düşündüğünü söyledi.

Ansgar hala EIP3074 bir imzanın yalnızca bir işleme karşılık gelmesi gerektiği ve cüzdan servis sağlayıcılarının işlemleri başlatmak için kullanıcı imzalarını yeniden kullanmaması gerektiği konusunda ısrar ediyor, ancak Dan Finlay da itiraz etti. Dan Finlay, EIP3074 soğuk bir cüzdan tarafından imzalanması gerektiğine inanıyor ve ardından cüzdan servis sağlayıcısı, doğrudan kullanıcı için işlemleri başlatmak için imzayı yeniden kullanabilir ve kullanıcının her seferinde yeniden imzalaması gerekiyorsa, soğuk özel anahtar birden çok kez kullanılabilir. Bu, sıcak ve soğuk özel anahtarları ayırma fikriyle tutarsızdır.

Bu toplantıda, çekirdek geliştiriciler başka bir önemli konuyu tartıştılar: dahil etme listesi. Dahil etme listesi, Ethereum'un sansüre dayanıklılık özelliklerini artırmanın bir yoludur. Kısacası, dahil etme listesi bazı işlemlerin bir sonraki blokta doğrudan dahil edilmesi için taahhüt edilmesine olanak tanır. Ancak çekirdek geliştiriciler EIP3074'ün dahil etme listesiyle çeliştiğini belirttiler.

2024 yılının 11 Nisanındaki Meeting #185 toplantısında, toplantının büyük bir kısmındaki istemci uygulamaları EIP3074'ün Pectra sert çatalına dahil edilmesine onay verdi, ancak Geth karşı çıktı, nedeni EIP3074'ün Verkle ağacında sorunlara yol açabileceği. Danno hala karşı çıkıyor çünkü EIP3074 imza tekrar kullanımına yol açabilir. Yoav da karşı çıktı, Yoav EIP3074 ve Blob işlemleri kullanarak bellek havuzuna saldırı yapma planı sundu. Kısacası, saldırganlar büyük miktarda Blob işlemi başlatabilir, bu Blob işlemleri büyük miktarda veri içerebilir ve ardından EIP3074'ü kullanarak bu Blob işlemlerini geçersiz kılabilir.

Kısacası, bu toplantıda, tüm istemci geliştiricileri, EIP3074 son yükseltmeye dahil edildiği konusunda anlaştılar.

2024 yılı 9 Mayıs'taki Meeting #187'de, çekirdek geliştiriciler EIP7702'nin EIP3074'ü değiştirmesi konusunu ilk kez tartıştı. EIP7702, Vitalik'in çekirdek geliştirici toplantısı başlamadan 90 dakika önce tamamlandı. Toplantıda, çekirdek geliştiriciler EIP7702'nin EIP3074'e göre daha üstün bir standart olduğunu kabul ettiler. Bu toplantıda EIP7702'ye karşı bir muhalefet sesi çıkmadı, yalnızca bazı araştırmacılar EIP7702'nin de EIP3074'e benzer geri alınamaz özellikler taşıdığını, bunun da fon güvenliği sorunlarına yol açabileceğini düşündüler.

2024 yılının 23 Mayıs'ındaki Meeting #188 toplantısında, ana geliştiriciler EIP7702'nin EIP3074'ü değiştirme olasılığını tartıştılar. Bu toplantının nihai sonucu, EIP7702'nin Pectra hard fork'undaki hesap soyutlama standardı olarak EIP3074'ün yerini almasıdır. Vitalik, EIP7702'nin EIP3074 ile tutarlı bazı geri alınamazlık özelliklerine de sahip olduğunu belirtti; bu özellikler EIP3074 tartışılırken yoğun bir şekilde ele alınmıştı. İlginç bir şekilde, toplantıda birçok ERC4337 temsilcisinin de konuşmalara katıldığı gözlemlendi.

Aslında, EIP3074'ün EIP7702 ile değiştirilmesi konusundaki tartışmalar, 188. çekirdek geliştirici toplantısından önce geniş bir şekilde tartışıldı ve o zamanki tartışmalar sonucunda 3074'ün değiştirilmesine karar verildi, bu yüzden çekirdek geliştirici toplantısında büyük bir tartışma yaşanmadı.

Yol Haritası ve Karar

Hesap soyutlamasının temel altyapısı Zerodev, EIP3074'ün değiştirileceğini öğrendikten sonra, "3074 Efsanesi Sonrası Ethereum Yönetimi Üzerine Düşünceler" başlıklı ilginç bir makale yayımladı. Bu makalenin sonucu, EIP7702'nin tüm kullanıcıların yararına olan iyi bir öneri olduğudur. Ancak EIP7702'nin EIP3074'ü değiştirme yönetim süreci en iyi değildir, bunun nedenleri arasında:

1. EIP3074 uzun bir tartışma sürecinden geçti, yukarıda EIP3074'ün çekirdek geliştirici toplantılarındaki birçok tartışmasını tanıttık.
2. EIP3074'ün Pectra yükseltmesine dahil edileceği belirlendikten sonra ERC4337 topluluğundan büyük bir muhalefet aldı. Elbette, yukarıda belirttiğimiz gibi, ERC4337'nin ana geliştiricisi yova, ana geliştirici toplantılarında EIP3074'e karşı olan görüşlerini defalarca ifade etti.

Zerodev, en iyi yönetişim yolunun EIP3074'ün uzun süredir devam eden temel geliştirici tartışmaları sürecinde, ERC4337 topluluğunun geniş bir şekilde katılmasını ve kendi görüşlerini ifade etmesini sağlaması gerektiğini düşünüyor.

EIP3074 geliştiricileri, ERC4337'nin yönetişim başarısızlıklarından sorumlu olması gerektiğini düşünüyor. Çünkü EIP3074 son birkaç yılda yönetişime aktif olarak katıldı ve ERC4337'nin çekirdek geliştiricisi yova ile defalarca iletişim kurdu.

ERC4337 topluluğu, EIP3074'ün yönetişim başarısızlığından ana sorumlu olması gerektiğini düşünüyor. ERC4337 topluluğu üyeleri, Yova'nın ERC4337'nin ana geliştiricisi olarak EIP3074'e karşı birkaç ana geliştirici toplantısında itirazlarını dile getirdiğini, ancak ana geliştiricilerin bu görüşleri dikkate almadığını düşünüyor. ERC4337'deki çoğu topluluk üyesi, EIP3074'ün yönetişim dinamiklerine dikkat etmedi; çoğu üye EIP3074'ün ölmüş bir standart olduğunu düşünüyor. ERC4337 topluluğu ayrıca ana geliştiricilerin ERC4337 topluluğuyla aktif bir şekilde iletişim kurmadığını düşünüyor.

EIP3074 ve ERC4337, kendi doğru yönetişim çalışmalarını yaptıklarını ve diğer tarafın yönetişim başarısızlığından asıl sorumlu olması gerektiğini düşünüyor. Açıkça, bu yönetişim sürecinde daha derin bir nedenin devrede olduğu görülüyor.

Basitçe söylemek gerekirse, bu daha derin neden aslında Ethereum'un yol haritasıdır. Ethereum yol haritası, çekirdek geliştirici toplantısından daha fazla yetkiye sahiptir. Hesap soyutlaması için yol haritası ERC4337 merkezlidir. EIP7702, ERC4337 standardı ile tamamen uyumludur, ancak EIP3074 ERC4337 standardı ile tam olarak uyumlu değildir. Dolayısıyla, Ethereum yol haritası açısından bakıldığında, EIP3074 değişimin gerçekleşmesi kaçınılmazdır.

Elbette, Ethereum yol haritası tamamen Vitalik'in Ethereum'un gelecekteki vizyonuna dair bir sunumudur. Ethereum yönetim sürecinde ciddi bir tartışma olduğunda, yol haritasının tanımlayıcısı olan Vitalik'in nihai karar verme yetkisi vardır. Ve işte bu nedenle Vitalik'in kararı ile EIP3074 değiştirilmiştir.

Ethereum'un yönetim modeli values ⇒ vision ⇒ roadmaps ⇒ clients modeli veya kısaca VVRC modeli olarak adlandırılmaktadır. Yönetim süreci aşağıdaki gibidir:

1. değerler, özellikle topluluğun değerleri, Ethereum topluluğunun değerleri merkeziyetsizlik, sansüre karşı dayanıklılık gibi unsurları içerir.
2. vizyon, aslında Vitalik'in Ethereum'un geleceğine dair kişisel düşüncesidir.
3. yol haritaları, araştırmacılar vizyon temelinde bazı teknik detaylara dair dikkate alınarak daha tam bir uygulama yol haritası sunar.
4. müşteriler Müşteri uygulamasının gerçekleştirilmesi, müşteri uygulamasının ana geliştiricileri, yol haritasını tartışmak için ana geliştirici toplantıları gibi araçları kullanarak yol haritasındaki gereksinimleri yerine getirir.

Yukarıda açıklanan süreç, Ethereum'un gerçek yönetim sürecidir. Vitalik'in kişisel vizyonunun Ethereum yönetim modelinin alt kısmında yer aldığını görebiliyoruz, bu nedenle istemci uygulamasında ciddi bir tartışma ortaya çıktığında, Vitalik'in kişisel görüşü nihai karar olacaktır.

Referanslar

ZeroDev Tanıtımı

null

ZeroDev Tanıtımı

null

Hesap Soyutlama yol haritası hakkında notlar - HackMD

Hesap Soyutlama yol haritası ile ilgili Notlar *Geri bildirimleri için Vitalik ve AA ekibine özel teşekkürler