Ethereum protokolünün olası geleceği (Altı): Refah

Yazı: Vitalik Buterin

Bazı şeyler tek bir kategoriye sokulması zor; Ethereum protokol tasarımında, birçok "detay" Ethereum'un başarısı için son derece önemlidir. Aslında, içeriğin yaklaşık yarısı farklı türde EVM iyileştirmeleri ile ilgilidir, geri kalan kısmı ise çeşitli niş konulardan oluşmaktadır, işte bu "refah" anlamına gelir.

Refah: Ana Hedef

• EVM'yi yüksek performanslı ve stabil "nihai durum" haline getirmek
• Hesap soyutlamasını protokole dahil etmek, tüm kullanıcıların daha güvenli ve pratik bir hesap deneyimi yaşamasını sağlar.
• İşlem maliyet ekonomisini optimize et, ölçeklenebilirliği artırırken riski azalt.
• Gelişmiş kriptografi keşfederek Ethereum'un uzun vadede önemli ölçüde iyileşmesini sağlamak

EVM geliştirmeleri

Hangi sorunu çözdü?

Mevcut EVM'nin statik analiz yapılması zordur, bu da verimli uygulamalar oluşturmayı, resmi doğrulama kodu yazmayı ve daha fazla genişletmeyi zorlaştırır. Ayrıca, EVM'nin verimliliği düşüktür ve birçok ileri düzey kriptografi biçimini yalnızca önceden derlenmiş destek ile gerçekleştirmek zordur.

O nedir, nasıl çalışır?

Mevcut EVM geliştirme yol haritasının ilk adımı, bir sonraki sert çatallamada dahil edilmesi planlanan EVM nesne formatıdır (EOF). EOF, birçok benzersiz özelliğe sahip yeni bir EVM kodu sürümünü belirten bir dizi EIP'dir, en dikkat çekeni şudur:

• Kod (çalıştırılabilir, ancak EVM'den okunamaz) ile veri (okunabilir, ancak çalıştırılamaz) arasındaki ayrım
• Dinamik yönlendirmeye izin verilmez, yalnızca statik yönlendirmeye izin verilir.
• EVM kodu artık yakıtla ilgili bilgileri gözlemleyemez
• Yeni bir açık alt rutin mekanizması eklendi

Eski sözleşmeler var olmaya ve oluşturulmaya devam edecek, ancak sonunda eski sözleşmelerin kademeli olarak terk edilmesi (hatta EOF koduna zorunlu dönüşüm) muhtemeldir. Yeni sözleşmeler, EOF'un getirdiği verimlilik artışından faydalanacak - öncelikle alt program özellikleri ile biraz küçülen byte kodu, ardından EOF'ya özgü yeni özellikler veya azalan gaz maliyetleri ile.

EOF'un tanıtılmasından sonra, ilerideki yükseltmeler daha kolay hale geldi, şu anda en gelişmiş olanı EVM modül aritmetik genişletmesi (EVM-MAX). EVM-MAX, modüler hesaplamalara yönelik yeni bir dizi özel işlem oluşturdu ve bunları diğer işlem kodlarıyla erişilemeyen yeni bir bellek alanına yerleştirdi, bu da Montgomery çarpımı gibi optimizasyonların kullanılmasını mümkün kıldı.

Daha yeni bir fikir, EVM-MAX'i tek komut çoklu veri (SIMD) özellikleriyle birleştirmektir. SIMD, Ethereum'un bir konsepti olarak uzun süre boyunca var olmuştur ve ilk kez Greg Colvin'in EIP-616'sında önerilmiştir. SIMD, birçok kriptografi biçimini hızlandırmak için kullanılabilir; bunlar arasında hash fonksiyonları, 32 bit STARK'lar ve ızgara tabanlı kriptografi bulunmaktadır. EVM-MAX ve SIMD'nin birleşimi, bu iki performans odaklı genişlemenin doğal bir eşleşmesini sağlar.

Bir EIP kombinasyonunun genel tasarımı EIP-6690'ı başlangıç noktası alacak ve ardından:

• (i) herhangi bir tek sayı veya (ii) 2'nin 2768'e kadar olan herhangi bir kuvvetini modül olarak kabul eder.
• Her EVM-MAX opcode'u (toplama, çıkarma, çarpma) için, artık 3 tane sabit x, y, z kullanmak yerine 7 tane sabit: x_start, x_skip, y_start, y_skip, z_start, z_skip, count kullanan bir versiyon ekleyin. Python kodunda, bu opcode'ların işlevi şuna benzer:

for i in range(count): mem[z_start + z_skip * count] = op( mem[x_start + x_skip * count], mem[y_start + y_skip * count] )

Gerçek uygulamada, bu paralel bir şekilde işlenecektir.

• XOR, AND, OR, NOT ve SHIFT (döngüsel ve döngüsel olmayan dahil) eklenebilir, en azından 2'nin kuvvet modülü için. Aynı zamanda ISZERO (çıktıyı EVM ana yığınına iten) eklenecek, bu da eliptik eğri kriptografisi, küçük alan kriptografisi (örneğin Poseidon, Circle STARKs), geleneksel hash fonksiyonları (örneğin SHA256, KECCAK, BLAKE) ve ızgara tabanlı kriptografi için yeterince güçlü olacaktır. Diğer EVM yükseltmeleri de gerçekleştirilebilir, ancak şimdiye kadar dikkat düşük olmuştur.

Mevcut araştırma bağlantısı

• EOF:
• EVM-MAX:
• SIMD:

Kalan iş ve denge

Şu anda, EOF'un bir sonraki hard fork'ta dahil edilmesi planlanıyor. Son dakika da kaldırılması her zaman mümkün olsa da - önceki hard fork'larda bazı işlevlerin geçici olarak kaldırıldığı durumlar oldu - bunu yapmak büyük zorluklarla karşılaşacaktır. EOF'un kaldırılması, gelecekte EVM için yapılacak herhangi bir yükseltmenin EOF olmadan gerçekleştirilmesi gerektiği anlamına geliyor; bu mümkün olsa da, muhtemelen daha zor olacaktır.

EVM'nin ana dengesi, L1 karmaşıklığı ile altyapı karmaşıklığı arasındadır; EOF, EVM uygulamasına eklenmesi gereken çok sayıda koddur ve statik kod incelemesi de görece karmaşıktır. Ancak, bunun karşılığında, yüksek düzeydeki dilleri basitleştirebilir, EVM uygulamasını basitleştirebilir ve diğer faydalar elde edebiliriz. Ethereum L1'in sürekli iyileştirilmesine yönelik yol haritasının EOF üzerine inşa edilmesi ve dahil edilmesi gerektiği söylenebilir.

Yapılması gereken önemli bir iş, EVM-MAX'a benzer SIMD işlevselliğinin gerçekleştirilmesi ve çeşitli şifreleme işlemlerinin gas tüketiminin performans testinin yapılmasıdır.

Yol haritasının diğer bölümleriyle nasıl etkileşim kurabilirim?

L1, EVM'sini L2'nin de daha kolay bir şekilde uygun ayarlamalar yapabilmesi için ayarlamaktadır. Eğer her iki taraf senkronize bir şekilde ayarlama yapmazsa, uyumsuzluk oluşabilir ve olumsuz etkiler yaratabilir. Ayrıca, EVM-MAX ve SIMD, birçok kanıt sisteminin gas maliyetlerini düşürebilir, böylece L2'yi daha verimli hale getirir. Ayrıca, aynı görevleri yerine getirebilen EVM kodları ile daha fazla önceden derlenmiş kodun değiştirilmesini kolaylaştırır, bu da verimliliği büyük ölçüde etkilemeyebilir.

hesap soyutlama

Hangi sorunu çözdü?

Şu anda, işlemler yalnızca bir şekilde doğrulanabilir: ECDSA imzası. Başlangıçta, hesap soyutlaması bunu aşmayı ve hesabın doğrulama mantığının herhangi bir EVM kodu olmasına izin vermeyi amaçlıyordu. Bu, bir dizi uygulamayı etkinleştirebilir:

• Kuantum direnci şifrelemeye geçiş
• Eski anahtarları döndürmek (genellikle önerilen bir güvenlik uygulaması olarak kabul edilir)
• Çoklu imza cüzdanı ve sosyal kurtarma cüzdanı
• Düşük değerli işlemler için bir anahtar kullanın, yüksek değerli işlemler için başka bir anahtar (veya anahtar grubu) kullanın.

Gizlilik protokolünün aracı olmadan çalışmasına izin vermek, karmaşıklığını önemli ölçüde azaltır ve merkezi bir bağımlılık noktasını ortadan kaldırır.

2015 yılından itibaren hesap soyutlama önerildiğinden beri, hedefi "kolaylık hedefleri" de dahil olmak üzere genişletilmiştir; örneğin, ETH'si olmayan ancak bazı ERC20'leri olan bir hesap, gas ödemek için ERC20 kullanabilir. Aşağıda bu hedeflerin derleme tablosu bulunmaktadır:

MPC (Çok Taraflı Hesaplama), anahtarları birden fazla parçaya bölmek ve bunları birden fazla cihazda depolamak için kriptografik teknikler kullanarak imzalar oluşturmak üzere doğrudan bu anahtar parçalarını birleştirmeden kullanılabilen 40 yıllık bir teknolojidir.

EIP-7702, tüm kullanıcıların (EOA kullanıcıları da dahil) yararına hesap soyutlama kolaylığı sağlamayı amaçlayan bir öneridir ve bu öneri, bir sonraki sert çatala dahil edilmesi planlanmaktadır. EIP-7702, tüm kullanıcıların deneyimlerini kısa vadede iyileştirmek ve iki ekosisteme bölünmeyi önlemek için artan bir farkındalığın sonucudur.

Bu çalışma EIP-3074 ile başladı ve sonunda EIP-7702'ye dönüştü. EIP-7702, hesap soyutlamasının "kolaylık işlevlerini" tüm kullanıcılara sunar, bu da günümüzdeki EOA'ları (Dışa Sahip Hesaplar, yani ECDSA imzasıyla kontrol edilen hesaplar) içerir.

Grafikten görülebilir ki, bazı zorluklar (özellikle "kolaylık" zorluğu) çok taraflı hesaplama veya EIP-7702 gibi ilerici teknolojilerle çözülebilir, ancak başlangıçta hesap soyutlama önerisinin ana güvenlik hedefi yalnızca geriye dönüp orijinal sorunu çözerek gerçekleştirilebilir: akıllı sözleşme kodunun işlem doğrulamasını kontrol etmesine izin vermek. Şimdiye kadar başarısız olmasının nedeni, güvenli bir şekilde uygulamakta olan bu zorluğudur.

Bu nedir, nasıl çalışır?

Hesap soyutlamasının temelinde basit bir fikir yatıyor: akıllı sözleşmelerin işlem başlatmasına izin vermek, sadece EOA değil. Tüm karmaşıklık, bunu merkeziyetsiz bir ağı korumaya dost bir şekilde uygulamak ve hizmet reddi saldırılarına karşı korunmaktır.

Tipik bir anahtar zorluk, çoklu başarısızlık sorunudur:

Eğer 1000 hesabın doğrulama fonksiyonu tek bir S değerine bağımlıysa ve mevcut S değeri, bellek havuzundaki tüm işlemleri geçerli kılıyorsa, o zaman S değerini tersine çeviren tek bir işlem, bellek havuzundaki diğer tüm işlemlerin geçersiz olmasına neden olabilir. Bu, saldırganların bellek havuzuna çöp işlemler göndererek ağ düğümlerinin kaynaklarını tıkamasına olanak tanır.

Yıllarca süren çabaların ardından, işlevselliği genişletirken hizmet reddi (DoS) riskini sınırlamayı amaçlayan, nihayetinde "ideal hesap soyutlaması"nı gerçekleştiren bir çözüm elde edildi: ERC-4337.

ERC-4337'nin çalışma prensibi, kullanıcı işlemlerinin işlenmesini iki aşamaya ayırmaktır: doğrulama ve icra. Tüm doğrulama işlemleri önce işlenir, tüm icra işlemleri ise daha sonra işlenir. Bellek havuzunda, kullanıcı işleminin doğrulama aşaması yalnızca kendi hesabını içerdiğinde ve çevresel değişkenleri okumadığında kabul edilir. Bu, çoklu başarısızlık saldırılarını önlemeye yardımcı olur. Ayrıca, doğrulama adımlarına da sıkı gaz sınırlamaları uygulanır.

ERC-4337, Ethereum istemci geliştiricilerinin o sırada birleştirme (Merge) üzerinde yoğunlaşmasından dolayı ek bir protokol standardı (ERC) olarak tasarlandı, bu nedenle diğer işlevleri ele almak için fazladan bir enerji yoktu. Bu yüzden ERC-4337, normal işlemler yerine kullanıcı işlemleri olarak adlandırılan bir nesne kullandı. Ancak, son zamanlarda protokolün en azından bir kısmının yazılması gerektiğini fark ettik.

İki ana neden aşağıdaki gibidir:

1. EntryPoint olarak sözleşmenin doğasında var olan düşük verimlilik: Her bir paket için yaklaşık 100,000 gazlık sabit bir maliyet ve her kullanıcı işlemi için ek binlerce gaz.
2. Ethereum özelliklerinin gerekliliğini sağlamak: Listeyi içeren garanti, hesap soyut kullanıcıya aktarılması gereken bir içeriği oluşturur.

Ayrıca, ERC-4337 iki işlevi daha genişletmiştir:

• Ödeme Temsilcileri (Paymasters): Bir hesabın başka bir hesabın ücretlerini ödemesine izin veren bir işlevdir, bu da doğrulama aşamasında yalnızca gönderen hesabın kendisine erişim kurallarıyla çelişir, bu nedenle ödeme temsilci mekanizmasının güvenliğini sağlamak için özel işlemler getirilmiştir.
• Agregatörler (Aggregators): BLS agregasyonu veya SNARK tabanlı agregasyon gibi imza agregasyonunu destekleyen işlevler. Bu, Rollup üzerinde en yüksek veri verimliliğini sağlamak için gereklidir.

Mevcut araştırma bağlantısı

• Hesap soyutlama tarihi hakkında konuşma:
• ERC-4337：
• EIP-7702：
• BLSWallet kodu (birleştirme işlevini kullanarak):
• EIP-7562 (protokol yazma için hesap soyutlama):
• EIP-7701 (EOF tabanlı yazma protokolü hesap soyutlaması):