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

Bazı şeyler tek bir kategoriye yerleştirilmesi zor, Ethereum protokol tasarımında, Ethereum'un başarısı için birçok "detay" 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şur, işte "refah"ın anlamı budur.

Refah: Ana Hedef

• EVM'yi yüksek performanslı ve stabil "son durum" haline getirmek
• Hesap soyutlamasını protokole dahil ederek, tüm kullanıcıların daha güvenli ve kullanışlı hesapların tadını çıkarmasını sağlar.
• İşlem ücretlerini optimize et, ölçeklenebilirliği artırırken riski azalt.
• Gelişmiş kriptografi keşfedin, Ethereum'un uzun vadede önemli ölçüde iyileşmesini sağlamak.

EVM iyileştirmesi

Hangi sorunu çözdü?

Mevcut EVM, statik analizi zorlaştırıyor, bu da verimli uygulamalar oluşturmayı, resmi kod doğrulamasını ve daha fazla genişlemeyi zorlaştırıyor. Ayrıca, EVM'nin verimliliği düşük, birçok ileri düzey kriptografi biçimini gerçekleştirmek zor, ancak yalnızca önceden derlenmiş açık destekle mümkün.

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

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

• Kod ( yürütülebilir, ancak EVM'den ) ile veri ( arasında ayrım yapılamaz, ancak okunabilir, fakat ) yürütülemez.
• Dinamik yönlendirmeler yasaktır, 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 ) zorla dönüştürülmesi mümkün olabilir. Yeni sözleşmeler, EOF'un getirdiği verimlilik artışından yararlanacak - öncelikle alt rutin özellikleri sayesinde biraz küçülen byte kodu, ardından EOF'a özel yeni işlevler veya azalan gaz maliyetleri.

EOF'un tanıtılmasından sonra, daha fazla yükseltme daha kolay hale geldi, şu anda en gelişmiş olanı EVM modül aritmetik genişlemesi ( EVM-MAX )'dir. EVM-MAX, modül işlemlerine özel yeni bir dizi işlem oluşturur ve bunları diğer işlem kodlarıyla erişilemeyen yeni bir bellek alanına yerleştirir, bu da Montgomery çarpımı gibi optimizasyonların kullanılmasını mümkün kılar.

Daha yeni bir fikir, EVM-MAX'i tek talimat çoklu veri ( SIMD ) özelliği ile birleştirmektir. SIMD, Ethereum'un bir fikri olarak uzun süredir vardır ve ilk olarak Greg Colvin'in EIP-616'sında önerilmiştir. SIMD, birçok şifreleme biçimini hızlandırmak için kullanılabilir, bunlar arasında hash fonksiyonları, 32 bit STARK'lar ve ızgara tabanlı şifreleme yer alır. EVM-MAX ve SIMD'nin birleşimi, bu iki performansa yönelik genişlemenin doğal bir eşleşmesini sağlar.

Bir EIP kombinasyonunun genel tasarımı EIP-6690 ile başlayacak ve ardından:

• (i) herhangi bir tek sayı veya (ii) 2768'e kadar olan 2'nin kuvveti modül olarak izin verilir.
• Her EVM-MAX opcode ( toplama, çıkarma, çarpma ) için, artık 3 adet anlık sayı x, y, z yerine 7 adet anlık sayı kullanarak bir versiyon ekleyin: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Python kodunda, bu opcode'ların işlevi benzer şekilde:

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( dahil etmek mümkün döngüsel ve döngüsel olmayan ), en azından 2'nin kuvvet modülü için. Aynı zamanda ISZERO( eklemek, çıktıyı EVM ana yığınına ) itecektir, bu da eliptik eğri kriptografisi, küçük alan kriptografisi ( gibi Poseidon, Circle STARKs), geleneksel hash fonksiyonları ( gibi SHA256, KECCAK, BLAKE) ve ızgara tabanlı kriptografi gerçekleştirmek için yeterince güçlü olacaktır. Diğer EVM yükseltmeleri de gerçekleştirilebilir, ancak bugüne kadar daha az ilgi görmüştür.

Kalan işler ve dengeler

Şu anda, EOF'un bir sonraki sert çatalda dahil edilmesi planlanıyor. Son anda kaldırılması her zaman mümkün olsa da - önceki sert çatallarda işlevlerin geçici olarak kaldırıldığı durumlar oldu, ancak bunu yapmak büyük zorluklarla karşılaşacaktır. EOF'un kaldırılması, EVM'nin gelecekteki herhangi bir yükseltmesinin EOF olmadan yapılması gerektiği anlamına geliyor; bu yapılabilir, ancak daha zor olabilir.

EVM'nin ana dengesi, L1 karmaşıklığı ile altyapı karmaşıklığı arasındadır; EOF, EVM uygulamasına eklenmesi gereken büyük miktarda koddur ve statik kod denetimi de nispeten karmaşıktır. Ancak, bunun karşılığında yüksek seviye dilleri basitleştirebilir, EVM uygulamasını basitleştirebilir ve diğer faydalar elde edebiliriz. Ethereum L1'in sürekli iyileştirilmesine öncelik veren bir yol haritasının EOF'un üzerine inşa edilmesi gerektiği söylenebilir.

Gerçekleştirilmesi gereken önemli bir iş, EVM-MAX'a benzer SIMD fonksiyonlarının uygulanması ve çeşitli kripto işlemlerinin gaz tüketiminin referans testlerinin yapılmasıdır.

Harita üzerindeki diğer bölümlerle nasıl etkileşimde bulunabilirim?

L1, EVM'sini L2'nin de daha kolay bir şekilde ilgili ayarlamalar yapabilmesi için ayarlıyor; eğer ikisi senkronize bir şekilde ayarlama yapmazsa, uyumsuzluk oluşabilir ve olumsuz etkiler doğurabilir. Ayrıca, EVM-MAX ve SIMD, birçok kanıtlama sisteminin gaz maliyetlerini düşürebilir, böylece L2'yi daha verimli hale getirir. Aynı görevleri yerine getirebilen EVM kodunu daha fazla önceden derlenmiş kodun yerine kullanmak da daha kolay hale gelir, 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ı amaçlıyordu ve hesapların doğrulama mantığının herhangi bir EVM kodu olmasına izin veriyordu. Bu, bir dizi uygulamanın önünü açabilir:

• Kuantum direnci kriptografiye geçiş yap
• Eski anahtarları döndürmek ( yaygın olarak önerilen bir güvenlik uygulaması olarak kabul edilmektedir )
• Ç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 bir anahtar grubu ) kullanın.

Gizlilik protokollerinin, aracısız çalışmasına izin vererek karmaşıklığını önemli ölçüde azaltmak ve kritik bir merkezi bağımlılık noktasını ortadan kaldırmak.

2015 yılından itibaren hesap soyutlama önerildiğinden bu yana, hedefi birçok "kolaylık hedefini" de kapsamaktadır, örneğin, ETH'si olmayan ancak bazı ERC20'leri olan bir hesabın ERC20 ile gaz ödeyebilmesidir.

MPC( çoklu taraflı hesaplama), anahtarları birden fazla parçaya bölüp bu parçaları birden fazla cihazda saklamak için kullanılan, 40 yıllık bir geçmişe sahip bir tekniktir. Şifreleme tekniklerini kullanarak imzalar oluşturur, bu anahtar parçalarını doğrudan birleştirmeden.

EIP-7702, bir sonraki sert fork'ta tanıtılması planlanan bir tekliftir. EIP-7702, EOA kullanıcıları da dahil olmak üzere tüm kullanıcıların yararına hesap soyutlama kolaylığı sağlama konusundaki artan farkındalığın bir sonucudur (. Kısa vadede tüm kullanıcıların deneyimini geliştirmeyi ve iki ekosisteme bölünmeyi önlemeyi hedeflemektedir.

Bu çalışma EIP-3074 ile başladı ve nihayetinde EIP-7702'yi oluşturdu. EIP-7702, hesap soyutlamasının "kolaylık işlevlerini" tüm kullanıcılara sunar, bugün EOA) dışarıdan sahip olunan hesaplar da dahil olmak üzere, yani ECDSA imzasıyla kontrol edilen hesaplar(.

![Vitalik'in Ethereum'un Olası Geleceği Hakkında (Altı): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(

Grafikten görülebilir ki, bazı zorluklar ) özellikle "kolaylık" zorluğu ( çoklu taraflı hesaplama veya EIP-7702 gibi ilerici teknolojilerle çözülebilir, ancak hesap soyutlama önerisinin ilk güvenlik hedefi yalnızca geri dönülerek ve orijinal sorunun çözülmesiyle gerçekleştirilebilir: akıllı sözleşme kodunun işlem doğrulamasını kontrol etmesine izin vermek. Şimdiye kadar gerçekleştirilememesinin nedeni, bunu güvenli bir şekilde uygulamaktır ve bu bir zorluktur.

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

Hesap soyutlamasının temeli basittir: akıllı sözleşmelerin yalnızca EOA değil, aynı zamanda işlem başlatmasına izin vermek. Tüm karmaşıklık, bunun merkeziyetsiz bir ağı korumaya dost bir şekilde uygulanması ve hizmet reddi saldırılarına karşı korunmasından kaynaklanı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şlemleri geçersiz kılabilir. Bu, saldırganların bellek havuzuna çok düşük bir maliyetle gereksiz işlemler göndererek ağ düğümlerinin kaynaklarını tıkayabilmesine olanak tanır.

Yıllarca süren çalışmalar sonucunda, işlevselliği genişletirken hizmet reddi ### DoS ( riskini sınırlamayı amaçlayan bir çözüm geliştirildi: ERC-4337.

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 öncelikle işlenir, tüm yürütmeler ise daha sonra işlenir. Bellek havuzunda, yalnızca kullanıcı işleminin doğrulama aşaması 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ımı için de katı gaz sınırlamaları uygulanmaktadır.

ERC-4337, Ethereum istemci geliştiricilerinin o sırada Merge)'e odaklanmasından dolayı, ek işlevlerle ilgilenmek için ek bir enerjiye sahip olmadıkları için, ek bir protokol standardı olarak tasarlandı (ERC). Bu nedenle ERC-4337, geleneksel işlemler yerine kullanıcı işlemleri adı verilen nesneleri kullanmaktadır. Ancak, son zamanlarda, bunun en azından bir kısmını protokole yazma ihtiyacını fark ettik.

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

1. EntryPoint'in sözleşmenin doğuştan verimsizliği: Her bir paket için yaklaşık 100.000 gazlık sabit bir maliyet ve her bir kullanıcı işlemi için ek olarak binlerce gaz.
2. Ethereum özelliklerinin gerekli olduğundan emin olun: Hesap soyut kullanıcılarına aktarılması gereken garantileri içeren listeyle oluşturulan içerikleri içermelidir.

Ayrıca, ERC-4337 iki işlevselliği 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 durum doğrulama aşamasında yalnızca gönderici hesabının kendisine erişim kurallarıyla çelişmektedir, bu nedenle ödeme aracısı mekanizmasının güvenliğini sağlamak için özel işlemler getirilmiştir.
• Agregatör(Agregatörler): BLS agregasyonu veya SNARK tabanlı agregasyon gibi imza agregasyonu işlevlerini destekler. Bu, Rollup üzerinde en yüksek veri verimliliği sağlamak için gereklidir.

(# Kalan işler ve değerlendirmeler

Şu anda ana ihtiyaç, hesap soyutlamasını tamamen protokole dahil etmenin yollarını bulmaktır. Son zamanlarda popüler olan yazım protokolü hesap soyutlaması EIP, EIP-7701'dir. Bu öneri, EOF'un üzerinde hesap soyutlamasını 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ü ayarlamışsa, bu kod, o hesaptan gelen işlemlerin doğrulama adımında çalıştırılacaktır.

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

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

Eğer doğrulama süresince yürütülebilir kod karmaşıklığı için katı sınırlar belirlemeye başlarsak - dış duruma erişime izin verilmez, hatta başlangıçta belirlenen gaz sınırı, kuantum direncine veya gizlilik koruma uygulamalarına bile yetersiz olacak kadar düşükse - bu yaklaşımın güvenliği oldukça net olur: ECDSA doğrulamasını, benzer süre gerektiren EVM kodu yürütmesi ile değiştirmekten ibarettir.

Ancak, zamanla bu sınırları gevşetmemiz gerekiyor, çünkü özel koruma uygulamalarının aracı olmadan çalışmasına izin vermek ve kuantum direnci sağlamak son derece önemlidir. Bunun için, doğrulama adımlarının son derece basit olmasını talep etmeden, hizmet reddi )DoS### riskini daha esnek bir şekilde çözmenin yollarını bulmamız gerekiyor.

ana