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

Ethereum protokol tasarımında başarısı için kritik öneme sahip birçok önemli "detay" bulunmaktadır. Aslında, içeriğin yaklaşık yarısı farklı EVM iyileştirmeleri ile ilgilidir, geri kalan kısım ise çeşitli niş konulardan oluşmaktadır, işte bu "refah"ın anlamı budur.

Refah: Ana Hedef

• EVM'yi yüksek performanslı ve stabil bir "nihai durum" haline getirin
• Hesap soyutlamasını protokole dahil ederek, tüm kullanıcıların daha güvenli ve kullanışlı bir hesap deneyiminden yararlanmalarını sağlar.
• İşlem maliyetlerini optimize etme, ölçeklenebilirliği artırırken riski azaltma
• Gelişmiş kriptografiyi keşfedin, Ethereum'un uzun vadede önemli ölçüde iyileşmesini sağlayın.

EVM iyileştirmeleri

Hangi sorunu çözdü?

Mevcut EVM, statik analiz yapmayı zorlaştırıyor, bu da etkili uygulamalar oluşturmayı, resmi olarak kodu doğrulamayı ve daha fazla genişletmeyi zorlaştırıyor. Ayrıca, EVM'nin verimliliği düşüktür ve birçok yüksek düzeyde kriptografi biçimini gerçekleştirmek zordur, yalnızca önceden derlenmiş desteği sağlamakla 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), bir sonraki sert çatallamada dahil edilmesi planlanmaktadır. EOF, birçok benzersiz özellik taşıyan yeni bir EVM kodu sürümünü tanımlayan bir dizi EIP'dir, en dikkat çekici olanı:

• Kod ( yürütülebilir, ancak EVM'den ) ile veri ( arasında ayrım yapamaz, okunabilir ancak yürütülemez ).
• Dinamik yönlendirme yasaktır, 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 nihayetinde eski sözleşmelerin ( kademeli olarak terk edilmesi ve hatta EOF koduna ) zorunlu olarak dönüştürülmesi mümkün olabilir. Yeni sözleşmeler, EOF'un getirdiği verimlilik artışından faydalanacak - öncelikle alt rutin özellikleri ile biraz küçülmüş byte kodu, ardından da EOF'a özgü yeni işlevler veya azalmış gaz maliyetleri.

EOF'un getirilmesinden sonra, 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 aritmetik işlemlerine özel yeni bir işlem seti 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'ı tek komut çok 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, 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ı alarak başlayacak, ardından:

• (i) herhangi bir tek sayı veya (ii) 2768'e kadar olan 2'nin herhangi bir kuvvetini modül olarak kabul et
• Her EVM-MAX opcode ( toplama, çıkarma, çarpma ) için bir versiyon ekleyin, bu versiyon artık 3 sabit sayı x, y, z kullanmamakta, bunun yerine 7 sabit sayı kullanmaktadır: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. 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 olarak işlenecektir.

• XOR, AND, OR, NOT ve SHIFT( döngü ve döngü olmayan durumları da içerecek şekilde eklenebilir, en azından 2'nin bir kuvveti modül sayısı için. Aynı zamanda ISZERO) EVM ana yelpazesine çıktıyı 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 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.

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

)# Kalan işler ve dengeler

Şu anda, EOF'un bir sonraki hard fork'ta dahil edilmesi planlanıyor. Son anda kaldırılması her zaman mümkün olsa da - önceki hard fork'larda bazı işlevler geçici olarak kaldırılmıştır, 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 gerçekleştirilmesi gerektiği anlamına geliyor; bu yapılabilir, ancak daha zor olabilir.

EVM'nin temel dengesi L1 karmaşıklığı ile altyapı karmaşıklığı arasındadır. EOF, EVM uygulamasına eklenmesi gereken büyük bir kod miktarıdır ve statik kod incelemesi de görece karmaşıktır. Ancak, bunun karşılığında, yüksek düzeyli dilleri basitleştirebilir, EVM uygulamasını basitleştirebilir ve diğer faydaları elde edebiliriz. Denilebilir ki, Ethereum L1'in sürekli iyileştirilmesine öncelik veren yol haritası, EOF üzerine inşa edilmelidir.

Yapılması gereken önemli bir iş, EVM-MAX ile SIMD benzeri bir işlevselliği gerçekleştirmek ve çeşitli kriptografik işlemlerin gas tüketimini benchmark etmektir.

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

L1, EVM'sini L2'nin de uygun ayarlamalar yapabilmesi için daha kolay hale getirecek şekilde ayarlıyor. Eğer ikisi senkronize bir şekilde ayarlanmazsa, uyumsuzluklar oluşabilir ve olumsuz etkiler doğurabilir. Ayrıca, EVM-MAX ve SIMD, birçok kanıt sisteminin gaz maliyetlerini düşürebilir, bu da L2'yi daha verimli hale getirir. Ayrıca, aynı görevleri yerine getirebilen EVM kodları ile daha fazla önceden derlenmiş kodun yerini almayı kolaylaştırır, bu da verimliliği büyük ölçüde etkilemeyebilir.

![Vitalik Ethereum'un olası geleceği (Altı): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(

) 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 direncine sahip kriptografiye geçiş yap
• Eski anahtarları döndürmek ### yaygın olarak ö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 bir anahtar grubu ( kullanın

Gizlilik protokolünün ara ile çalışmasını sağlayarak, karmaşıklığını önemli ölçüde azaltır ve merkezi bir bağımlılık noktasını ortadan kaldırır.

2015'te hesap soyutlaması önerildiğinden beri, hedefi birçok "kolaylık hedefini" de kapsayacak şekilde genişledi; örneğin, ETH'si olmayan ancak bazı ERC20'leri olan bir hesap, gas ödemek için ERC20 kullanabilir.

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

Hesap soyutlamasının özü basit: akıllı sözleşmelerin işlem başlatmasına izin vermek, yalnızca 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 zorluğu çoklu başarısızlık sorunudur: Eğer 1000 hesabın doğrulama fonksiyonu tek bir değer S'ye bağımlı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şlemleri geçersiz kılabilir. Bu, saldırganların bellek havuzuna çöp işlemler göndermesini ve böylece ağ düğümlerinin kaynaklarını tıkamasını çok düşük bir maliyetle mümkün kılar.

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

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

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çerdiğinde ve çevresel değişkenleri okumadığında kabul edilir. Bu, çoklu başarısızlık saldırılarını önleyebilir. Ayrıca, doğrulama adımına da sıkı gaz limitleri uygulanır.

ERC-4337, ek bir protokol standardı olarak tasarlanmıştır )ERC(, çünkü o dönemde Ethereum istemci geliştiricileri )Merge( üzerinde yoğunlaşmışlardı ve diğer işlevlerle ilgilenmek için ek bir enerjiye sahip değildiler. Bu nedenle ERC-4337, geleneksel işlemler yerine kullanıcı işlemleri olarak adlandırılan nesneleri kullanmaktadır. Ancak, son zamanlarda bunun en azından bir bölümünü protokole yazma ihtiyacını fark ettik.

İki ana neden şunlardır:

1. EntryPoint'in sözleşmenin doğasında bulunan düşük verimliliği: her paket için yaklaşık 100.000 gazlık sabit bir maliyet ve her kullanıcı işlemi için ek birkaç bin gaz.
2. Ethereum özelliklerinin gerekliliğini sağlamak: Listeye dahil edilen garantilerin, hesap soyut kullanıcıya aktarılması gerekir.

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

• Ödeme aracısı ) Paymasters (: Bir hesabın başka bir hesabın ücretlerini ödemesine izin veren bir işlevdir, bu da doğrulama aşamasının yalnızca gönderen hesabın kendisine erişim hakkı olduğu kuralını ihlal etmektedir, bu nedenle ödeme aracı mekanizmasının güvenliğini sağlamak için özel bir işlem getirilmektedir.
• Agregatör)Agregatör(: 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.

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

)# Kalan işler ve dengeler

Şu anda ana ihtiyaç, hesap soyutlamasını protokole tamamen entegre etmektir. Son zamanlarda popülerlik kazanan yazılı protokol hesap soyutlaması EIP-7701'dir. Bu öneri EOF'un üzerinde hesap soyutlamasını gerçekleştirir. Bir hesabın doğrulama için ayrı bir kod parçası olabilir; eğer hesap bu kod parçasını ayarladıysa, bu kod, o hesaptan gelen işlemlerin doğrulama aşamasında yürütülecektir.

Bu yönteminin büyüleyici yanı, yerel hesap soyutlamasının iki eşdeğer bakış açısını 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 koymaya başlarsak - dış duruma erişime izin verilmez, hatta başlangıçta belirlenen gaz sınırlamaları kuantum dayanıklılığı veya gizlilik koruma uygulamaları için geçersiz olacak kadar düşükse - o zaman bu yaklaşımın güvenliği oldukça net hale gelir: sadece ECDSA doğrulamasını benzer 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ısız bir şekilde çalışmasına izin vermek ve kuantum direnci sağlamak çok önemlidir. Bunun için, DoS### riskini doğrulama adımlarının son derece sade olmasını talep etmeden daha esnek bir şekilde çözmenin yollarını bulmamız gerekiyor.

Ana denge, "daha az kişinin memnun olduğu bir çözümü hızlı bir şekilde yazmak" ile "daha uzun süre bekleyerek daha ideal bir çözüm elde etmek" arasında gibi görünüyor. İdeal yaklaşım, bir tür karma yaklaşım olabilir. Karma yaklaşım, 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 yöntem, L2 üzerinde önce daha iddialı bir hesap soyutlama versiyonunu dağıtmaktır. Ancak, bununla ilgili 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.

Başka bir uygulama olarak net bir şekilde düşünmemiz gereken bir diğer konu, L1 veya özel L2 üzerinde hesapla ilgili durumu depolayan anahtar depolama hesaplarıdır, ancak L1 ve herhangi bir uyumlu L2 üzerinde kullanılabilirler. Bunu etkili bir şekilde yapmak, L2'nin L1SLOAD veya REMOTESTATI gibi şeyleri desteklemesini gerektirebilir.