- Topic
104k Popularity
24k Popularity
30k Popularity
6k Popularity
14k Popularity
17k Popularity
139k Popularity
1836k Popularity
60k Popularity
105k Popularity
- Pin
104k Popularity
24k Popularity
30k Popularity
6k Popularity
14k Popularity
17k Popularity
139k Popularity
1836k Popularity
60k Popularity
105k Popularity
Ethereum protokolünün refah yolu: EVM iyileştirmeleri, hesap soyutlaması ve çok boyutlu Gas
Ethereum protokolünün muhtemel geleceği (Altı): Refah Bölümü
Bazı şeyleri tek bir kategoriye koymak zordur, 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ştirmeleriyle ilgilidir, geri kalan kısmı ise çeşitli niş konulardan oluşmaktadır, işte bu "refah"ın anlamıdır.
Refah: Ana Hedef
EVM iyileştirmesi
Hangi problemi çözdü?
Mevcut EVM, statik analiz yapmayı zorlaştırıyor, bu da verimli uygulamalar oluşturmayı, resmi olarak kodu doğrulamayı ve daha fazla genişlemeyi 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, bunun dışında önceden derlenmiş destekle.
O nedir, nasıl çalışır?
Mevcut EVM iyileştirme yol haritasının ilk adımı, bir sonraki sert çatalla birlikte dahil edilmesi planlanan EVM nesne formatı (EOF)dır. EOF, birçok benzersiz özelliğe sahip yeni bir EVM kodu sürümünü tanımlayan bir dizi EIP'dir, en dikkat çekici olanları ise:
Eski sözleşmeler var olmaya ve oluşturulmaya devam edecek, ancak sonunda eski sözleşmelerin kademeli olarak kullanılmaktan kaldırılması (hatta EOF koduna zorla dönüştürülmesi) mümkün olabilir. Yeni sözleşmeler, EOF'un sağladığı verimlilik artışından faydalanacak.
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). EVM-MAX, modüler hesaplamalara ö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 talimat çoklu veri (SIMD) özellikleriyle birleştirmektir. SIMD, Ethereum'un bir kavramı olarak uzun bir süredir mevcuttur ve ilk olarak 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 bulunur. EVM-MAX ve SIMD'nin birleşimi, bu iki performans odaklı genişlemenin doğal bir eşleşmesini sağlar.
Mevcut araştırma bağlantısı
Kalan işler ve dengeler
Şu anda, EOF'un bir sonraki hard fork'ta dahil edilmesi planlanıyor. Her zaman son dakikada kaldırma olasılığı olsa da, bunu yapmak büyük zorluklarla karşılaşacaktır. EOF'u kaldırmak, EVM üzerindeki gelecekteki herhangi bir güncellemenin 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ığı arasındadır, EOF EVM uygulamasına eklenmesi gereken çok sayıda koddur, 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ştirilmesine yönelik yol haritası EOF üzerine inşa edilmelidir.
Yapılması gereken önemli bir iş, EVM-MAX'a benzer SIMD işlevselliğini gerçekleştirmek ve çeşitli kripto işlemlerinin gaz tüketimini karşılaştırmalı testlere tabi tutmaktır.
Harita'nın diğer bölümleriyle nasıl etkileşim kurabilirim?
L1, EVM'sini L2'nin de daha kolay bir şekilde uyum sağlaması için ayarlamaktadır; eğer ikisi senkronize bir şekilde ayarlanmazsa, uyumsuzluklar ortaya çıkabilir ve olumsuz etkiler doğurabilir. Ayrıca, EVM-MAX ve SIMD, birçok kanıtlama sisteminin gas maliyetlerini azaltarak L2'nin daha verimli olmasını sağlar. Aynı görevleri yerine getiren EVM kodları ile daha fazla önceden derlenmiş kodu değiştirmeyi kolaylaştırır; bu durum verimliliği büyük ölçüde etkilemeyecektir.
hesap soyutlama
Hangi problemi çözdü?
Şu anda, işlemler yalnızca bir yöntemle doğrulanabilir: ECDSA imzası. Başlangıçta, hesap soyutlaması bunun ötesine geçmek için tasarlanmıştı 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:
2015 yılından itibaren hesap soyutlaması önerildiğinden bu yana, hedefi birçok "kolaylık hedefi" içerecek şekilde genişlemiştir. Örneğin, ETH'si olmayan ancak bazı ERC20'leri bulunan bir hesap, gas ücretini ERC20 ile ödeyebilir.
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 ve hizmet reddi saldırılarına karşı koruma sağlamak amacıyla gerçekleştirmekten kaynaklanmaktadı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 soyutlama"yı gerçekleştiren çözüm: 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 ardından işlenir. Bellek havuzunda, kullanıcı işleminin doğrulama aşaması yalnızca kendi hesapları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 sıkı gaz sınırlamaları uygulanmaktadır.
Mevcut araştırma bağlantısı
Kalan işler ve denge
Şu anda çözülmesi gereken en önemli konu, hesap soyutlamasını tamamen protokole dahil etmektir. 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 hesap, doğrulama için ayrı bir kod parçasına sahip olabilir; eğer hesap bu kod parçasını ayarlarsa, bu kod, o hesaptan gelen işlemlerin doğrulama adımında yürütülecektir.
Ana denge, "daha az insanı memnun eden bir çözüm yazmak için hızlı bir şekilde ilerlemek" ile "daha uzun süre beklemek, muhtemelen daha ideal bir çözüm elde etmek" arasında gibi görünüyor; ideal yöntem muhtemelen bir tür karışık yöntemdir. Bir karışık 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 yöntem ise önce L2 üzerinde daha iddialı bir hesap soyutlama versiyonunu dağıtmaktır.
Diğer yol haritası bölümleriyle nasıl etkileşime giriyor?
İçerik listesinin hesap soyutlama işlemlerini desteklemesi gerekiyor. Pratikte, içerik listesi ihtiyacı ile merkeziyetsiz bellek havuzu ihtiyacı aslında çok benzer, ancak içerik listesi için esneklik biraz daha fazla. Ayrıca, hesap soyutlama uygulaması mümkün olduğunca L1 ve L2 arasında koordinasyon sağlamalıdır. Gelecekte, çoğu kullanıcının anahtar depolama Rollup'ı kullanmasını bekliyorsak, hesap soyutlama tasarımı buna dayanmalıdır.
EIP-1559 iyileştirmesi
Hangi sorunu çözüyor?
EIP-1559, 2021 yılında Ethereum'da etkinleştirildi ve ortalama blok dahil etme süresini önemli ölçüde iyileştirdi.
Ancak, mevcut EIP-1559'un uygulanması birçok açıdan mükemmel değil:
Blobs için kullanılan formül (EIP-4844), ilk sorunu çözmek için özel olarak tasarlanmıştır ve genel olarak daha basittir. Ancak, EIP-1559'un kendisi ve EIP-4844, ikinci sorunu çözmeyi denememiştir.
Bunun yanı sıra, EIP-1559 ile ilgili olmayan Ethereum kaynak fiyatlandırmasında başka zayıflıklar da bulunmaktadır, ancak bunlar EIP-1559'un ayarlamaları ile çözülebilir. Ana sorunlardan biri, ortalama durum ile en kötü durum arasındaki farklılıktır: Ethereum'daki kaynak fiyatları, en kötü durumu karşılayacak şekilde ayarlanmalıdır; yani bir bloğun tamamının gas tüketimi bir kaynağı kaplamaktadır, ancak gerçek ortalama kullanım bunun çok altındadır ve bu da verimsizliğe yol açmaktadır.
Çok Boyutlu Gas nedir, nasıl çalışır?
Bu düşük verimlilik sorunlarını çözmenin yolu çok boyutlu Gas'tır: farklı kaynaklar için farklı fiyatlar ve kısıtlamalar belirlemek. Bu kavram teknik olarak EIP-1559'dan bağımsızdır, ancak EIP-1559'un varlığı bu çözümü gerçekleştirmeyi daha kolay hale getirir. EIP-1559 olmadan, çeşitli kaynak kısıtlamaları içeren bir bloğu optimal bir şekilde paketlemek karmaşık bir çok boyutlu sırt çantası sorunudur. Ancak EIP-1559 ile, çoğu blok herhangi bir kaynakta tam kapasiteye ulaşmaz, bu nedenle "yeterli ücret ödeyen herhangi bir işlemi kabul etme" gibi basit bir algoritma yeterlidir.
Şu anda yürütme ve veri blokları için çok boyutlu Gas'a sahibiz; prensipte, bunu daha fazla boyuta genişletebiliriz: örneğin calldata (işlem verisi), durum okuma/yazma ve durum boyutu genişlemesi.
EIP-7706, calldata'ya özel yeni bir gaz boyutu tanıtmaktadır. Aynı zamanda, üç tür gazı (EIP-4844 tarzı) tek bir çerçeveye birleştirerek çok boyutlu Gaz mekanizmasını basitleştirmiş ve EIP-1559'un matematiksel eksikliklerini çözmüştür. EIP-7623, ortalama durum ve en kötü durum kaynak sorunlarına daha hassas bir çözüm sunarak, tüm yeni bir boyut getirmeden en fazla calldata'yı daha sıkı bir şekilde sınırlamaktadır.
Mevcut araştırma bağlantısı