Ethereum protokolünün olası geleceği(alt):The Splurge

Ethereum protokol tasarımında birçok "detay" başarısı için kritik öneme sahiptir. Aslında, içeriğin yaklaşık yarısı farklı türde EVM iyileştirmelerini kapsarken, geri kalan kısmı ise çeşitli niş konulardan oluşmaktadır, işte bu "refah"ın anlamıdır.

Refah: Ana Hedef

• EVM'yi yüksek performanslı ve stabil bir "son durum" haline getirmek
• Hesap soyutlamasını protokole dahil et, tüm kullanıcıların daha güvenli ve pratik bir hesap deneyimi yaşamasını sağlar.
• İşlem ücretleri ekonomisini optimize etme, ölçeklenebilirliği artırma ve aynı zamanda riski azaltma
• Gelişmiş kriptografi keşfedin, Ethereum'un uzun vadede önemli ölçüde iyileşmesini sağlayın

EVM iyileştirmesi

Hangi sorunu çözdü?

Mevcut EVM, statik analiz yapmayı zorlaştırıyor, bu da verimli uygulamalar oluşturmayı, resmi olarak kod doğrulamayı ve daha fazla genişleme yapmayı zorlaştırıyor. Ayrıca, EVM'nin verimliliği düşüktür, birçok yüksek seviyeli kriptografi biçiminin gerçekleştirilmesi zordur, ancak önceden derlenmiş destek ile mümkündür.

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

Mevcut EVM iyileştirme yol haritasının ilk adımı EVM nesne formatı (EOF) olup, bir sonraki hard fork'ta dahil edilmesi planlanmaktadır. EOF, birçok benzersiz özelliğe sahip yeni bir EVM kod versiyonunu belirten bir dizi EIP'dir, en dikkat çekici olanı:

• kod ( yürütülebilir, ancak EVM'den ) ile veri ( arasında okuma yapılamaz, ancak ) yürütülemez.
• Dinamik yönlendirmelere izin verilmez, yalnızca statik yönlendirmelere izin verilir
• EVM kodu artık yakıtla ilgili bilgileri gözlemleyemiyor.
• Yeni bir açık alt rutin mekanizması eklendi

Eski sözleşmeler var olmaya ve oluşturulmaya devam edecek, ancak nihayetinde eski sözleşmelerin ( kademeli olarak terk edilmesi ve hatta EOF koduna ) zorunlu dönüşüm yapılması muhtemeldir. Yeni sözleşmeler, EOF'un getirdiği verimlilik artışından faydalanacaktır - ilk olarak, alt rutin özellikleriyle biraz küçültülmüş bytecode ile, ardından EOF'a özgü yeni özellikler veya azalan gaz maliyetleri ile.

EOF'un tanıtılmasından sonra, daha fazla yükseltme yapmak daha kolay hale geldi, şu anda en gelişmiş olanı EVM modülü aritmetik genişletmesi ( EVM-MAX ). EVM-MAX, modüler aritmetik için özel olarak tasarlanmış yeni bir dizi işlem oluşturdu ve bunları diğer işlem kodları ile 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'ı tek komut çoklu veri (SIMD) özelliği ile birleştirmektir. SIMD, Ethereum'un bir konsepti olarak uzun süredir mevcuttur ve ilk olarak Greg Colvin'in EIP-616'sında önerilmiştir. SIMD, hash fonksiyonları, 32 bit STARK'lar ve ızgara tabanlı şifreleme dahil olmak üzere birçok kriptografi biçimini hızlandırmak için kullanılabilir. EVM-MAX ve SIMD'nin birleşimi, bu iki performans odaklı genişlemenin doğal bir eşleşme olmasını sağlar.

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

• EOF:
• EVM-MAX:
• SIMD:

Kalan işler ve dengeler

Şu anda, EOF'un bir sonraki sert çatalla dahil edilmesi planlanıyor. Her zaman son dakikada bunu kaldırmak mümkün olsa da - önceki sert çatallarda bazı işlevler geçici olarak kaldırılmıştır - bunu yapmak büyük zorluklarla karşılaşacaktır. EOF'un kaldırılması, EVM üzerinde gelecekteki herhangi bir yükseltmenin EOF olmadan gerçekleştirilmesi gerektiği anlamına gelir; bu yapılabilir, ancak daha zor olabilir.

EVM'nin ana dengesi, L1 karmaşıklığı ile altyapı karmaşıklığıdır. EOF, EVM uygulamasına eklenmesi gereken çok sayıda koddur ve statik kod incelemesi de oldukça karmaşıktır. Ancak, bunun karşılığında, yüksek seviyeli dilleri basitleştirebilir, EVM uygulamasını basitleştirebilir ve diğer faydaları elde edebiliriz. Denilebilir ki, Ethereum L1'in sürekli iyileştirilmesi için öncelik verilen yol haritası EOF üzerine inşa edilmelidir.

Yapılması gereken önemli bir iş, EVM-MAX ile SIMD benzeri işlevlerin gerçekleştirilmesi ve çeşitli şifreleme işlemlerinin gaz tüketiminin karşılaştırmalı testlerinin yapılmasıdır.

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

L1, EVM'sini L2'nin de daha kolay uyum sağlaması için ayarlamaktadır. Eğer her iki taraf senkronize bir şekilde ayarlama yapmazsa, uyumsuzluk ortaya çıkabilir ve olumsuz etkiler yaratabilir. Ayrıca, EVM-MAX ve SIMD birçok kanıt sistemi için gas maliyetlerini düşürebilir, bu da L2'yi daha verimli hale getirir. Aynı görevleri yerine getirebilen EVM koduyla daha fazla önceden derlenmiş kodun yerini almanın daha kolay hale gelmesini sağlar, bu da verimliliği büyük ölçüde etkilemeyebilir.

Hesap Soyutu

Hangi sorunu çözdü?

Şu anda, işlemler yalnızca bir yöntemle doğrulanabilir: ECDSA imzası. Başlangıçta, hesap soyutlaması bunun ötesine geçmek ve hesabın doğrulama mantığının herhangi bir EVM kodu olmasına izin vermek üzere tasarlanmıştır. Bu, bir dizi uygulamayı etkinleştirebilir:

• Kuantum direnci şifrelemeye geç
• Eski anahtarların döndürülmesi ( yaygın olarak önerilen bir güvenlik uygulaması olarak kabul edilmektedir )
• Çoklu imza cüzdanı ve sosyal geri yükleme cüzdanı
• Düşük değerli işlemler için bir anahtar kullanın, yüksek değerli işlemler için diğer bir anahtar ( veya bir anahtar grubu ) kullanın.

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

2015'te hesap soyutlaması önerildiğinden beri, hedefi çok sayıda "kolaylık hedefini" de kapsamaktadır. Örneğin, ETH'si olmayan ancak bazı ERC20'leri olan bir hesap, gas ödemesi için ERC20 kullanabilmektedir.

MPC( çok taraflı hesaplama ), anahtarları birden fazla parçaya ayırmak ve bunları birden fazla cihazda saklamak için kullanılan, 40 yıllık bir geçmişe sahip bir tekniktir. Kriptografi teknolojisini kullanarak imzalar oluşturur, bu anahtar parçalarını doğrudan bir araya getirmeden.

EIP-7702, bir sonraki sert çatalla birlikte tanıtılması planlanan bir öneridir. EIP-7702, hesap soyutlama kolaylığı sağlama konusundaki artan farkındalığın bir sonucudur; bu, ( dahil olmak üzere tüm kullanıcılar ve ) EOA kullanıcıları için geçerlidir. Kısa vadede tüm kullanıcıların deneyimini geliştirmeyi ve iki ekosisteme bölünmeyi önlemeyi amaçlamaktadır.

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, bugünkü EOA( dışarıdan sahip olunan hesaplar da dahil olmak üzere, yani ECDSA imzası ile kontrol edilen hesaplara) sunmaktadır.

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

Hesap soyutlamasının temeli basittir: akıllı sözleşmelerin işlem başlatmasına izin vermek ve yalnızca EOA değil. Tüm karmaşıklık, bunu merkeziyetsiz bir ağı koruyucu bir şekilde gerçekleştirirken ve hizmet reddi saldırılarına karşı koruma sağlarken gelmektedir.

Tipik bir anahtar zorluk çoklu arıza sorunudur:

Eğer 1000 hesabın doğrulama fonksiyonu tek bir değer S'ye bağlıysa ve mevcut S değeri, bellek havuzundaki işlemlerin hepsinin geçerli olmasını sağlıyorsa, o zaman S'nin değerini tersine çeviren tek bir işlem, bellek havuzundaki diğer tüm işlemleri geçersiz kılabilir. Bu, saldırganların bellek havuzuna çöp işlemleri göndermesini sağlayarak ağ düğümlerinin kaynaklarını tıkayabilmesine 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 bir çözüm olarak "ideal hesap soyutlaması"nı gerçekleştiren ERC-4337 sonuca varıldı.

ERC-4337'nin çalışma prensibi, kullanıcı işlemlerinin işlenmesini iki aşamaya ayırmaktır: doğrulama ve yürütme. Tüm doğrulamalar önce işlenir, tüm yürütmeler ise daha sonra işlenir. Bellek havuzunda, kullanıcı işleminin doğrulama aşaması yalnızca kendi hesabını içeriyorsa ve çevresel değişkenleri okumuyorsa, kabul edilir. Bu, çoklu başarısızlık saldırılarını önlemeye yardımcı olur. Ayrıca, doğrulama adımına da katı bir gaz limiti uygulanmaktadır.

ERC-4337, ek bir protokol standardı olarak tasarlandı (ERC), çünkü o dönemde Ethereum istemci geliştiricileri birleştirmeye (Merge) odaklandılar ve diğer işlevleri ele almak için ek bir enerji yoktu. Bu yüzden ERC-4337, geleneksel işlemler yerine kullanıcı işlemleri olarak adlandırılan nesneleri kullandı. Ancak, son zamanlarda bunların en azından bir kısmını protokole yazma ihtiyacını fark ettik.

İki ana sebep şunlardır:

1. EntryPoint'in sözleşmenin doğuştan verimsizliği: Her bir paket için yaklaşık 100,000 gaz sabit masraf ve her kullanıcı işlemi için ek binlerce gaz.
2. Ethereum özelliklerinin gerekliliğini sağlamak: İçerdiği liste ile oluşturulan garantilerin, hesap soyut kullanıcıya aktarılması gerektiği.

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

• Ödeme Aracısı (Paymasters): Bir hesabın başka bir hesabın masraflarını ödemesine izin veren bir işlevdir, bu da doğrulama aşamasının yalnızca gönderici hesabına erişim sağlaması kuralını ihlal eder, bu nedenle ödeme aracısı mekanizmasının güvenliğini sağlamak için özel bir işlem getirilmiştir.
• Agregatörler (Aggregators): BLS agregasyonu veya SNARK tabanlı agregasyon gibi imza agregasyonu işlevlerini destekler. 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 (, toplama işlevini ) kullanıyor:
• EIP-7562( yazılım protokolü için hesap soyutlama ):
• EIP-7701( EOF tabanlı yazım protokolü hesap soyutlama ):

Kalan işler ve denge

Şu anda çözülmesi gereken en önemli konu, hesap soyutlamasını tamamen protokole nasıl entegre edeceğimizdir. Son zamanlarda popüler olan yazım protokolü hesap soyutlama EIP'si EIP-7701'dir, bu öneri EOF'un üzerinde hesap soyutlamayı gerçekleştirir. Bir hesap, doğrulama için ayrı bir kod bölümüne sahip olabilir; eğer hesap bu kod bölümünü ayarlarsa, o kod, o hesaptan gelen işlemlerin doğrulama adımında yürütülecektir.

Bu yöntemin büyüleyici yanı, yerel hesap soyutlamasının iki eşdeğer perspektifini açıkça göstermesidir:

1. EIP-4337'yi protokolün bir parçası olarak kullan
2. Yeni bir EOA türü, burada imza algoritması EVM kodu yürütmedir.

Eğer doğrulama süresince yürütülebilir kod karmaşıklığına katı sınırlar koymaya başlarsak - dış duruma erişimine izin verilmez, hatta başlangıçta belirlenen gas limiti, kuantum direnci veya gizlilik koruma uygulamaları için etkisiz olacak kadar düşükse - bu yaklaşımın güvenliği oldukça açıktır: ECDSA doğrulamasını benzer süreye ihtiyaç duyan EVM kodu yürütmesi ile değiştirmekten ibarettir.

Ancak, zamanla bu sınırları gevşetmemiz gerekiyor çünkü aracı olmadan gizliliği koruyan uygulamaların çalışmasına izin vermek ve kuantum dayanıklılığı çok önemlidir. Bunun için, doğrulama adımlarının son derece basit olmasını gerektirmeden, hizmet reddi (DoS) riskini daha esnek bir şekilde çözmenin yollarını bulmalıyız.

Ana trade-off, "daha az insanı memnun eden bir çözümü hızlıca yazmak" ile "daha uzun süre beklemek, muhtemelen daha ideal bir çözüm elde etmek" arasında gibi görünüyor. İdeal yaklaşım, bir tür karma yöntemi olabilir. Bir karma yöntem, bazı kullanım durumlarını daha hızlı yazmak ve diğer kullanım durumlarını keşfetmek için daha fazla zaman ayırmaktır. Diğer bir yaklaşım, L2 üzerinde daha iddialı bir hesap soyutlama versiyonunu önce dağıtmaktır. Ancak, bununla karşılaşılan zorluk, L2 ekibinin benimsenen önerinin uygulanabilirliğine güven duyması gerektiğidir; özellikle de L1 ve/veya diğer L2'lerin gelecekte uyumlu çözümleri benimsemesini sağlamak için.

Açıkça dikkate almamız gereken bir diğer uygulama anahtar depolama hesabıdır, bu