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

Bazı şeyler sınıflandırılması zor, Ethereum protokol tasarımında birçok "detay" Ethereum'un başarısı için kritik öneme sahiptir. İçeriğin yaklaşık yarısı farklı türde EVM iyileştirmelerini kapsar, geri kalan ise çeşitli niş konulardan oluşur, işte bu da "bolluk" anlamına gelir.

Refah: Ana Hedef

• EVM'yi yüksek performanslı ve stabil "nihai durum" haline getirmek
• Hesap soyutlamasını protokole dahil ederek, tüm kullanıcıların daha güvenli ve pratik bir hesap deneyimi yaşamasını sağlamak
• İşlem maliyet ekonomisini 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ğlayın

EVM iyileştirmesi

Hangi sorunu çözdü?

Mevcut EVM, statik analiz yapmayı 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 kriptografik işlemi gerçekleştirmek zor, ancak önceden derlenmiş destek ile mümkün.

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

Mevcut EVM iyileştirme yol haritasının ilk adımı, EVM nesne formatı (EOF), bir sonraki sert çatalla birlikte dahil edilmesi planlanmaktadır. EOF, birçok benzersiz özelliğe sahip yeni EVM kodu sürümünü belirleyen bir dizi EIP'dir, en belirgin olanı:

• Kod ( çalıştırılabilir, ancak EVM'den )'i okuyamaz ve veri ( okunabilir, ancak )'i çalıştıramaz.
• Dinamik yönlendirmeler yasaktır, yalnızca statik yönlendirmelere izin verilir
• EVM kodu artık yakıtla ilgili bilgileri gözlemleyemez.
• Yeni 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 - öncelikle alt alt program özellikleri ile biraz küçülen bayt kodu, ardından ise EOF'a özgü yeni özellikler veya azalan gaz maliyetleri.

EOF'un getirilmesiyle birlikte, daha fazla yükseltme daha kolay hale geldi; şu anda en gelişmiş olanı EVM modülü aritmetik genişlemesi (EVM-MAX). EVM-MAX, modüler işlemler için özel olarak tasarlanmış yeni bir dizi işlem oluşturdu ve bunları diğer işlem kodlarıyla erişilemeyen yeni bir bellek alanına yerleştirdi; bu, Montgomery çarpımı gibi optimizasyonların kullanılmasını mümkün kıldı.

Daha yeni bir fikir, EVM-MAX'ı tek komut çok veri (SIMD) özelliği ile birleştirmektir; SIMD, Ethereum'un bir kavramı olarak uzun zamandır mevcuttur ve ilk olarak Greg Colvin'in EIP-616'sında önerilmiştir. SIMD, birçok kriptografik formu 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 performansa yönelik genişlemenin doğal bir eşleşmesini sağlar.

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

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

python 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üleri ve döngü olmayanları dahil etmek, en azından 2'nin kuvvet modülüsleri için eklenebilir. Ayrıca ISZERO), EVM ana yığın çıkışını( yollamak için eklenmelidir, 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 uygulamak için yeterince güçlü olacaktır. Diğer EVM yükseltmeleri de uygulanabilir, ancak bugüne kadar daha az ilgi görmüştür.

)# Kalan işler ve denge

Şu anda, EOF'un bir sonraki hard fork'ta dahil edilmesi planlanıyor. Her ne kadar son anda kaldırılması her zaman mümkün olsa da - daha önceki hard fork'larda bazı işlevler geçici olarak kaldırılmıştı, bunu yapmak büyük zorluklarla karşılaşacaktır. EOF'un kaldırılması, gelecekte EVM üzerindeki her türlü yükseltmenin EOF olmadan yapılması gerektiği anlamına gelir; bu mümkün olsa da, 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 kodu ifade eder, statik kod incelemesi de nispeten karmaşıktır. Ancak, bunun karşılığında, yüksek düzeydeki dilleri basitleştirebiliriz, EVM uygulamasını basitleştirebiliriz ve diğer faydalar elde edebiliriz. Denilebilir ki, Ethereum L1'in sürekli iyileştirilmesine öncelik veren bir yol haritası EOF üzerine inşa edilmeli ve onu içermelidir.

Yapılması gereken önemli bir iş, EVM-MAX benzeri SIMD işlevlerini uygulamak ve çeşitli şifreleme işlemlerinin gas tüketimini karşılaştırmalı olarak test etmektir.

Yol haritasının diğer kısımlarıyla nasıl etkileşim kurabilirim?

L1, EVM'sini L2'nin de daha kolay bir şekilde uyum sağlaması için ayarlıyor. Eğer ikisi senkronize bir şekilde ayarlanmazsa, uyumsuzluklar ortaya çıkabilir ve olumsuz etkiler yaratabilir. Ayrıca, EVM-MAX ve SIMD, birçok kanıtlama sisteminin gaz maliyetlerini düşürerek L2'nin daha verimli hale gelmesini sağlıyor. Aynı görevleri yerine getirebilen EVM kodları ile daha fazla önceden derlenmiş kodların yerini almak, verimliliği büyük ölçüde etkilemeden daha da kolay hale geliyor.

Hesap Soyutlama

Hangi sorunu çözdü?

Şu anda, işlemler yalnızca bir yöntemle doğrulanabilir: ECDSA imzası. Başlangıçta, hesap soyutlaması bunun ötesine geçmeyi 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 direncin şifrelemeye geçiş
• Eski anahtarların döndürülmesi ###, önerilen güvenlik uygulamaları arasında yaygın 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 başka bir anahtar ) veya bir anahtar grubu ( kullanın.

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

2015 yılından itibaren hesap soyutlaması önerildiğinden beri, hedefi birçok "kolaylık amacı" da dahil olmak üzere genişlemiştir; örneğin, ETH'si olmayan ancak bazı ERC20'lere sahip bir hesap, gaz ödemek için ERC20 kullanabilir.

MPC) çok taraflı hesaplama (, anahtarları birden fazla parçaya ayırmak ve bunları birden fazla cihazda depolamak için kullanılan, 40 yıllık bir geçmişe sahip bir teknolojidir. Kriptografik teknikler kullanarak imzalar oluşturur ve bu anahtar parçalarını doğrudan birleştirmeden işlem yapar.

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

EIP-7702, bir sonraki hard fork'ta tanıtılması planlanan bir öneridir. EIP-7702, tüm kullanıcıları, EOA kullanıcılarını da içerecek şekilde, hesap soyutlama kolaylığı sağlama konusundaki artan farkındalığın bir sonucudur ). Kısa vadede tüm kullanıcıların deneyimini iyileştirmeyi ve iki ekosisteme bölünmeyi önlemeyi amaçlamaktadır.

Bu çalışma EIP-3074 ile başladı ve nihayetinde EIP-7702'yi oluşturdu. EIP-7702, hesapların "kolaylık işlevlerini" tüm kullanıcılara sunmaktadır, bunlar arasında bugünün EOA( dışarıdan sahip olunan hesapları da bulunmaktadır; yani ECDSA imzası ile kontrol edilen hesaplar ).

Bazı zorluklar (, özellikle "kolaylık" zorluğu ), çok taraflı hesaplama veya EIP-7702 gibi ilerleyici teknolojilerle çözülebilir; ancak hesap soyutlama önerisinin ilk güvenlik hedefi, akıllı sözleşme kodunun işlem doğrulamasını kontrol etmesine izin verecek şekilde, orijinal sorunu geriye dönük olarak ele alıp çözmekle gerçekleştirilebilir. Şu ana kadar gerçekleştirmemenin nedeni, güvenli bir şekilde uygulamaktır ve bu da bir zorluktur.

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

Hesap soyutlamasının temeli basittir: 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 gerçekleştirmek ve hizmet reddi saldırılarına karşı koruma sağlamaktan kaynaklanıyor.

Tipik bir anahtar zorluk, çoklu arıza sorunudur:

Eğer 1000 hesabın doğrulama fonksiyonu belirli bir tekil değer S'ye bağlıysa ve mevcut değer S, 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şlemlerin geçersiz hale gelmesine neden olabilir. Bu, saldırganların bellek havuzuna çöp işlemleri göndermesini sağlayarak ağ düğümlerinin kaynaklarını tıkayabilir.

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 elde edildi: "ideal hesap soyutlaması"nı gerçekleştiren 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 önce işlenir, tüm yürütmeler daha sonra işlenir. Bellek havuzunda, yalnızca kullanıcının işleminin doğrulama aşaması 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ımlarına da katı gaz sınırlamaları uygulanmaktadır.

ERC-4337, ek bir protokol standardı olarak tasarlanmıştır (ERC), çünkü o dönemde Ethereum istemci geliştiricileri birleştirmeye (Merge) odaklandıkları için diğer işlevlerle ilgilenmek için ek bir enerjiye sahip değildiler. Bu yüzden ERC-4337, standart işlemler yerine kullanıcı işlemleri olarak adlandırılan nesneleri kullanmıştır. Ancak, son zamanlarda içeriğin en azından bir kısmını protokole yazma ihtiyacını fark ettik.

İki ana neden aşağıdadır:

1. EntryPoint sözleşmenin doğuştan gelen verimsizliği: her paket için yaklaşık 100.000 gas sabit maliyet ve her kullanıcı işlemi için ek binlerce gas.
2. Ethereum özelliklerinin gerekliliğini sağlamak: Listeyi içeren garanti, hesap soyut kullanıcıya aktarılması gerekmektedir.

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

• Ödeme aracısı ( Paymasters ): Bir hesabın başka bir hesabın ücretlerini ödemesine izin veren bir işlev, bu durum doğrulama aşamasının yalnızca gönderici hesabına erişim kuralını ihlal etmektedir, bu nedenle ödeme aracısı mekanizmasının güvenliğini sağlamak için özel işleme yöntemleri getirilmiştir.
• Agregatör(Agregatör): BLS agregasyonu veya SNARK tabanlı agregasyon gibi imza agregasyonunu destekleyen bir işlevdir. Bu, Rollup üzerinde en yüksek veri verimliliğini sağlamak için gereklidir.

(# Kalan işler ve dengeler

Şu anda ana sorun, hesap soyutlamasını protokole tamamen nasıl entegre edeceğimizdir. Son zamanlarda popüler olan yazım protokolü hesap soyutlaması EIP, EIP-7701'dir. Bu öneri, EOF'un üzerinde hesap soyutlaması gerçekleştirmektedir. Bir hesabın doğrulama için ayrı bir kod bölümüne sahip olabilmesi mümkündür. Eğer hesap bu kod bölümünü ayarlarsa, o zaman bu kod, o hesaptan gelen işlemlerin doğrulama adımında yürütülecektir.

Bu yöntemin cazibesi, 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 al
2. Yeni bir EOA türü, burada imza algoritması EVM kodu yürütmedir.

Eğer doğrulama döneminde yürütülebilir kodun karmaşıklığı için katı sınırlar koymaya başlarsak - dış duruma erişime izin verilmez, hatta başlangıçta belirlenen gaz sınırları 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: sadece ECDSA doğrulamasını benzer bir süre gerektiren EVM kodu yürütmesi ile değiştirmek.

Ancak, zamanla bu sınırları gevşetmemiz gerekiyor, çünkü gizlilik 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 sade olmasını talep etmeden, hizmet reddi ) DoS ### riskini daha esnek bir şekilde ele almanın yollarını bulmalıyız.

Ana ticaret, "daha az insanı tatmin eden bir çözüm yazmak için hızlı olmak" ile "daha uzun süre beklemek" gibi görünüyor.