"Güvensizlik", "geçiş testini geçme" ve "öz egemenlik" gibi önemli ve sürekli az değer verilen yönlerden biri protokol basitliğidir. Bir protokol yüzbinlerce düğümle aşırı merkeziyetsiz ve %49 Bizans hata toleransına sahip olsa bile, düğümler kuantum güvenli peerda'lar ve starklarla her şeyi tamamen doğrulasa bile, protokol yüzbinlerce satır kod ve beş doktora düzeyinde kriptografi türüyle karmaşık bir karmaşa ise, sonuçta o protokol üç testi de geçer: * Güvensizlik değil çünkü protokolün hangi özellikleri olduğunu söyleyen küçük bir yüksek rahip sınıfına güvenmek zorundasınız * Mevcut müşteri ekipleri giderse, yeni ekiplerin aynı kalite seviyesine ulaşması son derece zor olduğu için bu test testini geçmiyor * Kendi kendine egemen değil çünkü en teknik insanlar bile onu inceleyemez ve anlayamazsa, tamamen sizin değildir Ayrıca daha az güvenlidir, çünkü protokolün her bölümü, özellikle diğer parçalarla karmaşık yollarla etkileşime girebiliyorsa, protokolün bozulma riski taşır. Ethereum protokol geliştirme konusunda endişelerimden biri, protokolü şişirse veya kritik bağımlılıklar olarak tamamen yeni etkileşimli bileşenler veya karmaşık kriptografi eklese bile, çok spesifik ihtiyaçları karşılamak için yeni özellikler eklemeye çok hevesli olmamızdır. Bu, kısa vadeli işlevsellik kazanımları için iyi olabilir, ancak uzun vadeli öz egemenliği korumak ve imparatorlukların ve ideolojilerin yükseliş ve çöküşünü aşan yüz yıllık merkeziyetsiz bir hiperyapı yaratmak için oldukça yıkıcıdır. Temel sorun, protokol değişiklikleri "mevcut protokoldeki değişiklikler olarak ne kadar büyükler" perspektifinden değerlendirilirse, geriye dönük uyumluluğu koruma arzusu, eklemelerin çıkarmalardan çok daha sık gerçekleşmesine yol açar ve protokol zamanla kaçınılmaz olarak şişirir. Buna karşı koymak için, Ethereum geliştirme sürecinin açıkça bir "basitleştirme" / "çöp toplama" fonksiyonuna ihtiyacı var. "Basitleştirme"nin üç ölçütü vardır: * Protokoldeki toplam kod satırlarının en aza indirilmesi. İdeal bir protokol tek bir sayfaya - ya da en azından birkaç sayfaya - sığdırır * Temelde karmaşık teknik bileşenlere gereksiz bağımlılıklardan kaçınmak. Örneğin, güvenliği yalnızca hash'lara bağlı olan bir protokol (daha iyisi: tam olarak bir hash fonksiyonuna), hash ve kafeslere bağlı olan protokolden iyidir. İzogenileri eklemek en kötüsü, çünkü (bu şeyleri çözen gerçekten zeki, çalışkan nerdlere özür dilerim) kimse izogenileri anlamıyor. * Daha fazla _invarians_ eklenmesi: protokolün dayanabileceği temel özellikler, örneğin EIP-6780 (kendini imha çıkarma), en fazla N depolama yuvasının slota değiştirilebileceği özelliğini ekledi, bu da istemci geliştirmeyi önemli ölçüde basitleştirdi ve EIP-7825 (TX başına gaz sınırı) bir işlem işleme maliyetine maksimum bir madde ekledi; bu da ZK-EVM'lere ve paralel yürütmeye büyük katkı sağladı. Çöp toplama parça parça olabilir ya da büyük ölçekli olabilir. Parça parça yaklaşım, mevcut özellikleri alıp sadeleştirmeye ve daha anlamlı hale getirmeye çalışıyor. Bir örnek, Glamsterdam'daki gaz maliyeti reformları; bu reformlar, daha önce keyfi olan birçok gaz maliyetini, kaynak tüketimine açıkça bağlı olan az sayıda parametreye bağlı hale getiriyor. Büyük ölçekli çöp toplama işlemlerinden biri, PoW'un yerine PoS ile geçiyordu. Bir başka sorunun da Lean uzlaşması kapsamında gerçekleşmesi muhtemeldir; bu da aynı anda çok sayıda hatayı düzeltmek için alan açar ( ). Bir diğer yaklaşım ise "Rosetta tarzı geriye doğru uyumluluk"tur; karmaşık ama az kullanılan özellikler kullanılabilir kalır, ancak zorunlu protokolün bir parçası olmaktan "düşürülür" ve bunun yerine akıllı sözleşme koduna dönüşür, böylece yeni istemci geliştiriciler onlarla uğraşmak zorunda kalmaz. Örnekler: * Tam yerel hesap soyutlamasına geçtikten sonra, tüm eski tx türleri emekliye ayrılabilir ve EOA'lar, tüm bu işlem türlerini işleyebilen kodları akıllı sözleşme cüzdanlarına dönüştürülebilir * Mevcut ön derlemeleri (gerçekten gerekenler hariç) EVM veya daha sonraki RISC-V koduyla değiştirebiliriz * Sonunda VM'yi EVM'den RISC-V'ye (veya daha basit bir VM'ye) değiştirebiliriz; EVM yeni VM'de akıllı bir sözleşmeye dönüştürülebilir. Son olarak, Ethereum protokolünün tüm eski sürümlerini yönetme ihtiyacı hisseden müşteri geliştiricilerinden uzaklaşmak istiyoruz. Bu, docker konteynerlerinde çalışan eski istemci sürümlerine bırakılabilir. Uzun vadede, Ethereum'a geçiş hızının daha yavaş olmasını umuyorum. Bence çeşitli nedenlerle bu _mutlaka_ olmalı. Bu ilk on beş yıl, kısmen ergenlik dönemi olarak görülmeli; burada birçok fikri keşfettik ve neyin işe yaradığını, neyin faydalı, neyin olmadığını gördük. Faydalı olmayan kısımların Ethereum protokolünde kalıcı bir yük olmasını engellemeye çalışmalıyız. Temelde, Ethereum'u şu şekilde geliştirmek istiyoruz: