Ethereum protokolünün gelecekteki olası gelişim yönleri: Refah Bölümü
Ethereum protokol tasarımında başarısı için kritik öneme sahip birçok önemli "detay" bulunmaktadır. İçeriğin yaklaşık yarısı farklı türde EVM iyileştirmeleri ile ilgilidir, geri kalan kısmı ise çeşitli niş konulardan oluşmaktadır, işte bu da "bolluk" anlamına gelir.
Refah: Ana Hedefler
EVM'nin yüksek performanslı ve stabil "son durum" haline getirilmesi
Hesap soyutlamasını protokole entegre edin, böylece tüm kullanıcılar daha güvenli ve kullanışlı bir hesap deneyimi yaşayabilir.
Ticaret maliyetlerini optimize et, ölçeklenebilirliği artırırken riski azalt
Gelişmiş kriptografi keşfi, Ethereum'un uzun vadede önemli ölçüde iyileşmesini sağlıyor.
EVM iyileştirmesi
Hangi sorunu çözdü?
Mevcut EVM, statik analiz yapmayı zorlaştırıyor, bu da etkili uygulamalar oluşturmayı, kodu resmi olarak doğrulamayı ve daha fazla genişletmeyi zorlaştırıyor. Ayrıca, EVM'nin verimliliği düşüktür, birçok yüksek düzeyde kriptografi biçimini gerçekleştirmek zordur, ancak önceden derlenmiş destek ile mümkündür.
Bu nedir, nasıl çalışır?
Mevcut EVM iyileştirme yol haritasının ilk adımı EVM nesne formatı (EOF), bir sonraki sert hard fork'ta dahil edilmesi planlanıyor. EOF, birçok benzersiz özelliğe sahip yeni bir EVM kodu sürümünü belirten bir dizi EIP'den oluşmaktadır, en dikkat çekici olanı:
Kod ( çalıştırılabilir, ancak EVM'den ) ile veri ( arasında ayrımı okuyamaz, 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özlemleyemiyor.
Yeni bir açık alt rutin mekanizması eklendi
EOF kod yapısı, kod bölümü, veri bölümü ve tür bilgisi bölümünü içerir.
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şletmesi ( EVM-MAX ). EVM-MAX, modüler aritmetik için özel olarak tasarlanmış 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'i tek komut çoklu veri (SIMD) özelliği ile birleştirmektir. SIMD, hash fonksiyonları, 32 bit STARK'lar ve ızgara tabanlı kriptografi dahil olmak üzere birçok kriptografi biçimini hızlandırmak için kullanılabilir. EVM-MAX ve SIMD'nin birleşimi, bu iki performansa dayalı genişlemenin doğal bir eşleşmesini sağlar.
Mevcut araştırma bağlantısı
EOF:
EVM-MAX:
SIMD:
Kalan işler ve değerlendirmeler
Şu anda, EOF'un bir sonraki sert çatalla birlikte dahil edilmesi planlanıyor. Her ne kadar son dakikada kaldırılması mümkün olsa da, bu büyük zorluklarla karşılaşacaktır. EOF'un kaldırılması, EVM üzerindeki gelecekteki herhangi bir güncellemenin EOF olmadan gerçekleştirilmesi 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'un EVM uygulamasına eklenmesi gereken çok sayıda kod vardır, statik kod incelemesi de görece karmaşıktır. Ancak, karşılığında, yüksek seviyeli dilleri basitleştirebilir, EVM uygulamasını sadeleştirebilir ve diğer faydalar elde edebiliriz. Denilebilir ki, Ethereum L1 sürekli iyileştirme yol haritasının öncelikle EOF üzerine inşa edilmesi ve dahil edilmesi gerekir.
Gerçekleştirilmesi gereken önemli bir iş, EVM-MAX ile SIMD benzeri işlevleri uygulamak ve çeşitli kripto işlemlerinin gas tüketimini referans testine tabi tutmaktır.
Harita planının diğer bölümleriyle nasıl etkileşim kurulur?
L1, EVM'sini ayarlayarak L2'nin de gerekli ayarlamaları daha kolay yapabilmesini sağlıyor. Eğer her iki taraf senkronize bir şekilde ayarlama yapmazsa, uyumsuzluklar oluşabilir ve olumsuz etkiler ortaya çıkabilir. Ayrıca, EVM-MAX ve SIMD, birçok kanıt sisteminin gas maliyetlerini düşürebilir, böylece L2'yi daha verimli hale getirir. Aynı görevleri yerine getirebilen EVM kodları ile daha fazla önceden derlenmiş kodu değiştirmek de daha kolay hale geliyor ve bu, verimliliği önemli ölçüde etkilemeyebilir.
Hesap Soyutlama
neyi çö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 için geçerli olmasına izin veriyordu. Bu, bir dizi uygulamanın etkinleştirilmesini sağlayabilir:
Kuantum-anti şifrelemeye geçiş yap
Eski anahtar ( değiştirmek 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 başka bir anahtar ( veya bir anahtar grubu ) kullanın.
Özelliklerin, merkezi bir bağımlılığı ortadan kaldırarak ve karmaşıklıklarını önemli ölçüde azaltarak, ortağsız bir şekilde çalışmasına izin vermek.
2015 yılından beri hesap soyutlaması önerildiğinden beri, hedefi birçok "kolaylık hedefi" de dahil olmak üzere genişletilmiştir; örneğin, ETH'si olmayan ancak bazı ERC20'leri olan bir hesabın ERC20 kullanarak gaz ücreti ödeyebilmesidir.
Bu nedir ve nasıl çalışır?
Hesap soyutlamasının özü basittir: akıllı sözleşmelerin yalnızca EOA değil, işlem başlatmasına izin vermektir. Tüm karmaşıklık, bunu merkeziyetsiz ağı korumaya dost bir şekilde gerçekleştirmek ve hizmet reddi saldırılarına karşı önlem almakla ilgilidir.
Tipik bir anahtar zorluk, çoklu başarısızlık sorunudur: Eğer 1000 hesabın doğrulama fonksiyonları tek bir S değerine bağımlıysa ve mevcut S değeri bellek havuzundaki işlemlerin hepsinin geçerli olmasını sağ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 çöp işlemler göndermesi için çok düşük bir maliyetle ağ düğümlerinin kaynaklarını tıkanmasına yol açar.
Yıllarca süren çabaların ardından, işlevselliği genişletirken hizmet reddi ( DoS ) riskini sınırlamayı amaçlayan, "ideal hesap soyutlaması"nı gerçekleştirmenin çö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 ise daha sonra işlenir. Bellek havuzunda, yalnızca kullanıcı işleminin doğrulama aşaması kendi hesabıyla ilgili olduğunda 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ında katı gaz sınırlamalarının uygulanması zorunludur.
Şu anda ana ihtiyaç, hesap soyutlamayı protokole tamamen entegre etmenin yollarını bulmaktır. Son zamanlarda popüler olan yazma 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ı ayarladıysa, bu kod, o hesaptan gelen işlemlerin doğrulama aşamasında yürütülecektir.
Bu yöntemin büyüleyici yanı, yerel hesap soyutlamasının iki eşdeğer bakış açısını açıkça göstermesidir:
EIP-4337'yi protokolün bir parçası olarak al
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ığına sıkı sınırlar koymaya başlarsak, bu yaklaşımın güvenliği oldukça nettir: ECDSA doğrulamasını, benzer süre gerektiren EVM kodu yürütmesiyle değiştirmekten ibarettir.
Ancak zamanla, bu sınırları gevşetmemiz gerekiyor, çünkü aracısız çalışan gizlilik koruma uygulamalarına izin vermek ve kuantum direnci sağlamak son derece önemlidir. Bu nedenle, doğrulama adımlarının son derece basit olması gerektiği şartını aramadan, hizmet reddi (DoS) riskini daha esnek bir şekilde çözmenin yollarını bulmamız gerekiyor.
Ana denge "daha az insanı memnun edecek bir çözümü hızlıca yazmak" ile "daha uzun süre beklemek ve muhtemelen daha ideal bir çözüm elde etmek" arasında gibi görünüyor; ideal yaklaşım muhtemelen bir tür karma yöntem olacaktır. 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 ise L2 üzerinde daha iddialı bir hesap soyutlama versiyonunu önceki olarak dağıtmaktır. Ancak, bununla ilgili zorluk, L2 ekibinin benimsenen önerinin uygulanabilir olduğuna güven duyması gerektiği, özellikle L1 ve/veya diğer L2'lerin gelecekte uyumlu çözümleri benimseyebilmesini sağlamak için.
Bir diğer önemli uygulama, anahtar depolama hesaplarıdır. Bu hesaplar, L1 veya özel L2 üzerinde hesapla ilgili durumları depolar, ancak L1 ve herhangi bir uyumlu L2 üzerinde kullanılabilir. Bunu etkin bir şekilde yapmak, L2'nin L1SLOAD veya REMOTESTATICCALL gibi opcode'ları desteklemesini gerektirebilir, ancak bu aynı zamanda L2 üzerindeki hesap soyutlama uygulamalarının bu opcode'ları desteklemesini de gerektirir.
Diğer yol haritası bölümleriyle nasıl etkileşiyor?
Liste dahil etme, hesap soyutlama işlemlerini desteklemelidir. Pratikte, liste dahil etme gereksinimi ve merkeziyetsiz bellek havuzu gereksinimi aslında oldukça benzer olup, liste dahil etme için esneklik biraz daha fazladır. 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 geliştirmesi
Bu neyi çözüyor?
EIP-1559, 2021'de Ethereum'da etkinleştirildi ve ortalama blok dahil etme süresini önemli ölçüde iyileştirdi. Ancak, mevcut EIP-1559 uygulaması birçok açıdan mükemmel değil:
Formül hafif bir eksikliğe sahip: bu %50 blok hedefi değildir, bunun yerine yaklaşık %50-53 dolu blok hedeflenmektedir, bu varyansa bağlıdır ( bu, matematikçilerin "aritmetik-geometrik ortalama eşitsizliği" olarak adlandırdığı ile ilgilidir ).
Aşırı durumlarda ayarlamalar yeterince hızlı değil.
Arkadaki blobs için formül ( EIP-4844, ilk problemi çözmek için özel olarak tasarlanmıştır ve genel olarak daha basittir. Ancak, EIP-1559'un kendisi ve EIP-4844, ikinci problemi çözmeyi denememiştir. Bu nedenle, mevcut durum, iki farklı mekanizmayı içeren karmaşık bir ara durumdur ve zamanla her ikisinin de iyileştirilmesi gerektiğine dair bir görüş vardır.
Ayrıca, EIP-1559 ile ilgisi olmayan Ethereum kaynak fiyatlandırma zayıflıkları vardır, ancak bunlar EIP-1559'un ayarlamaları ile çözülebilir. Ana sorunlardan biri, ortalama durum ile en kötü durum arasındaki farktır: Ethereum'daki kaynak fiyatları, bir bloğun tamamının gaz tüketiminin bir kaynağı kapladığı en kötü durumu ele alacak şekilde ayarlanmalıdır, ancak gerçek ortalama kullanım bunun çok altındadır, bu da verimsizliğe yol açar.
![Vitalik'in Ethereum'un Olası Geleceği Hakkında (Altı): The Splurge])https://img-cdn.gateio.im/webp-social/moments-fe95dd28b911aea1a22365468b7c42cd.webp(
) Çok Boyutlu Gas nedir, nasıl çalışır?
Bu düşük verimlilik sorunlarını çözmenin yolu çok boyutlu Gas: Farklı kaynaklar için farklı fiyatlar ve kısıtlamalar belirlemektir. Bu kavram teknik olarak EIP-1559'dan bağımsızdır, ancak EIP-1
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
14 Likes
Reward
14
7
Share
Comment
0/400
MissedAirdropBro
· 07-26 03:16
Neden yine hesap soyutlama!
View OriginalReply0
BrokenDAO
· 07-25 06:25
Yine hırslı bir yol haritası, sonuç büyük ihtimalle Casper'ın kaderini tekrar edecek.
View OriginalReply0
GasGuru
· 07-24 20:52
Güvenilir görünüyor, değil mi?
View OriginalReply0
SigmaBrain
· 07-24 20:51
Bu versiyonun hala değiştirilmesi mi gerekiyor?
View OriginalReply0
OPsychology
· 07-24 20:45
Bu güncelleme ne zaman yayınlanacak?
View OriginalReply0
WalletWhisperer
· 07-24 20:31
davranışsal kalıplar, evm2.0'ın kitlesel cüzdan göçlerini tetikleyeceğini... istatistiksel olarak kaçınılmaz olduğunu öne sürüyor
View OriginalReply0
Whale_Whisperer
· 07-24 20:29
EVM yükseltmesi çoktan gündeme gelmeliydi. Bu gas ücreti gerçekten dayanılmaz.
Ethereum protokolünün gelecekteki planı: EVM yükseltmeleri, hesap soyutlaması ve ücret optimizasyonu
Ethereum protokolünün gelecekteki olası gelişim yönleri: Refah Bölümü
Ethereum protokol tasarımında başarısı için kritik öneme sahip birçok önemli "detay" bulunmaktadır. İçeriğin yaklaşık yarısı farklı türde EVM iyileştirmeleri ile ilgilidir, geri kalan kısmı ise çeşitli niş konulardan oluşmaktadır, işte bu da "bolluk" anlamına gelir.
Refah: Ana Hedefler
EVM iyileştirmesi
Hangi sorunu çözdü?
Mevcut EVM, statik analiz yapmayı zorlaştırıyor, bu da etkili uygulamalar oluşturmayı, kodu resmi olarak doğrulamayı ve daha fazla genişletmeyi zorlaştırıyor. Ayrıca, EVM'nin verimliliği düşüktür, birçok yüksek düzeyde kriptografi biçimini gerçekleştirmek zordur, ancak önceden derlenmiş destek ile mümkündür.
Bu nedir, nasıl çalışır?
Mevcut EVM iyileştirme yol haritasının ilk adımı EVM nesne formatı (EOF), bir sonraki sert hard fork'ta dahil edilmesi planlanıyor. EOF, birçok benzersiz özelliğe sahip yeni bir EVM kodu sürümünü belirten bir dizi EIP'den oluşmaktadır, en dikkat çekici olanı:
EOF kod yapısı, kod bölümü, veri bölümü ve tür bilgisi bölümünü içerir.
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şletmesi ( EVM-MAX ). EVM-MAX, modüler aritmetik için özel olarak tasarlanmış 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'i tek komut çoklu veri (SIMD) özelliği ile birleştirmektir. SIMD, hash fonksiyonları, 32 bit STARK'lar ve ızgara tabanlı kriptografi dahil olmak üzere birçok kriptografi biçimini hızlandırmak için kullanılabilir. EVM-MAX ve SIMD'nin birleşimi, bu iki performansa dayalı genişlemenin doğal bir eşleşmesini sağlar.
Mevcut araştırma bağlantısı
Kalan işler ve değerlendirmeler
Şu anda, EOF'un bir sonraki sert çatalla birlikte dahil edilmesi planlanıyor. Her ne kadar son dakikada kaldırılması mümkün olsa da, bu büyük zorluklarla karşılaşacaktır. EOF'un kaldırılması, EVM üzerindeki gelecekteki herhangi bir güncellemenin EOF olmadan gerçekleştirilmesi 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'un EVM uygulamasına eklenmesi gereken çok sayıda kod vardır, statik kod incelemesi de görece karmaşıktır. Ancak, karşılığında, yüksek seviyeli dilleri basitleştirebilir, EVM uygulamasını sadeleştirebilir ve diğer faydalar elde edebiliriz. Denilebilir ki, Ethereum L1 sürekli iyileştirme yol haritasının öncelikle EOF üzerine inşa edilmesi ve dahil edilmesi gerekir.
Gerçekleştirilmesi gereken önemli bir iş, EVM-MAX ile SIMD benzeri işlevleri uygulamak ve çeşitli kripto işlemlerinin gas tüketimini referans testine tabi tutmaktır.
Harita planının diğer bölümleriyle nasıl etkileşim kurulur?
L1, EVM'sini ayarlayarak L2'nin de gerekli ayarlamaları daha kolay yapabilmesini sağlıyor. Eğer her iki taraf senkronize bir şekilde ayarlama yapmazsa, uyumsuzluklar oluşabilir ve olumsuz etkiler ortaya çıkabilir. Ayrıca, EVM-MAX ve SIMD, birçok kanıt sisteminin gas maliyetlerini düşürebilir, böylece L2'yi daha verimli hale getirir. Aynı görevleri yerine getirebilen EVM kodları ile daha fazla önceden derlenmiş kodu değiştirmek de daha kolay hale geliyor ve bu, verimliliği önemli ölçüde etkilemeyebilir.
Hesap Soyutlama
neyi çö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 için geçerli olmasına izin veriyordu. Bu, bir dizi uygulamanın etkinleştirilmesini sağlayabilir:
Özelliklerin, merkezi bir bağımlılığı ortadan kaldırarak ve karmaşıklıklarını önemli ölçüde azaltarak, ortağsız bir şekilde çalışmasına izin vermek.
2015 yılından beri hesap soyutlaması önerildiğinden beri, hedefi birçok "kolaylık hedefi" de dahil olmak üzere genişletilmiştir; örneğin, ETH'si olmayan ancak bazı ERC20'leri olan bir hesabın ERC20 kullanarak gaz ücreti ödeyebilmesidir.
Bu nedir ve nasıl çalışır?
Hesap soyutlamasının özü basittir: akıllı sözleşmelerin yalnızca EOA değil, işlem başlatmasına izin vermektir. Tüm karmaşıklık, bunu merkeziyetsiz ağı korumaya dost bir şekilde gerçekleştirmek ve hizmet reddi saldırılarına karşı önlem almakla ilgilidir.
Tipik bir anahtar zorluk, çoklu başarısızlık sorunudur: Eğer 1000 hesabın doğrulama fonksiyonları tek bir S değerine bağımlıysa ve mevcut S değeri bellek havuzundaki işlemlerin hepsinin geçerli olmasını sağ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 çöp işlemler göndermesi için çok düşük bir maliyetle ağ düğümlerinin kaynaklarını tıkanmasına yol açar.
Yıllarca süren çabaların ardından, işlevselliği genişletirken hizmet reddi ( DoS ) riskini sınırlamayı amaçlayan, "ideal hesap soyutlaması"nı gerçekleştirmenin çö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 ise daha sonra işlenir. Bellek havuzunda, yalnızca kullanıcı işleminin doğrulama aşaması kendi hesabıyla ilgili olduğunda 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ında katı gaz sınırlamalarının uygulanması zorunludur.
Mevcut araştırma bağlantısı
Kalan işler ve dengeler
Şu anda ana ihtiyaç, hesap soyutlamayı protokole tamamen entegre etmenin yollarını bulmaktır. Son zamanlarda popüler olan yazma 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ı ayarladıysa, bu kod, o hesaptan gelen işlemlerin doğrulama aşamasında yürütülecektir.
Bu yöntemin büyüleyici yanı, yerel hesap soyutlamasının iki eşdeğer bakış açısını açıkça göstermesidir:
Eğer doğrulama süresince yürütülebilir kod karmaşıklığına sıkı sınırlar koymaya başlarsak, bu yaklaşımın güvenliği oldukça nettir: ECDSA doğrulamasını, benzer süre gerektiren EVM kodu yürütmesiyle değiştirmekten ibarettir.
Ancak zamanla, bu sınırları gevşetmemiz gerekiyor, çünkü aracısız çalışan gizlilik koruma uygulamalarına izin vermek ve kuantum direnci sağlamak son derece önemlidir. Bu nedenle, doğrulama adımlarının son derece basit olması gerektiği şartını aramadan, hizmet reddi (DoS) riskini daha esnek bir şekilde çözmenin yollarını bulmamız gerekiyor.
Ana denge "daha az insanı memnun edecek bir çözümü hızlıca yazmak" ile "daha uzun süre beklemek ve muhtemelen daha ideal bir çözüm elde etmek" arasında gibi görünüyor; ideal yaklaşım muhtemelen bir tür karma yöntem olacaktır. 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 ise L2 üzerinde daha iddialı bir hesap soyutlama versiyonunu önceki olarak dağıtmaktır. Ancak, bununla ilgili zorluk, L2 ekibinin benimsenen önerinin uygulanabilir olduğuna güven duyması gerektiği, özellikle L1 ve/veya diğer L2'lerin gelecekte uyumlu çözümleri benimseyebilmesini sağlamak için.
Bir diğer önemli uygulama, anahtar depolama hesaplarıdır. Bu hesaplar, L1 veya özel L2 üzerinde hesapla ilgili durumları depolar, ancak L1 ve herhangi bir uyumlu L2 üzerinde kullanılabilir. Bunu etkin bir şekilde yapmak, L2'nin L1SLOAD veya REMOTESTATICCALL gibi opcode'ları desteklemesini gerektirebilir, ancak bu aynı zamanda L2 üzerindeki hesap soyutlama uygulamalarının bu opcode'ları desteklemesini de gerektirir.
Diğer yol haritası bölümleriyle nasıl etkileşiyor?
Liste dahil etme, hesap soyutlama işlemlerini desteklemelidir. Pratikte, liste dahil etme gereksinimi ve merkeziyetsiz bellek havuzu gereksinimi aslında oldukça benzer olup, liste dahil etme için esneklik biraz daha fazladır. 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 geliştirmesi
Bu neyi çözüyor?
EIP-1559, 2021'de Ethereum'da etkinleştirildi ve ortalama blok dahil etme süresini önemli ölçüde iyileştirdi. Ancak, mevcut EIP-1559 uygulaması birçok açıdan mükemmel değil:
Arkadaki blobs için formül ( EIP-4844, ilk problemi çözmek için özel olarak tasarlanmıştır ve genel olarak daha basittir. Ancak, EIP-1559'un kendisi ve EIP-4844, ikinci problemi çözmeyi denememiştir. Bu nedenle, mevcut durum, iki farklı mekanizmayı içeren karmaşık bir ara durumdur ve zamanla her ikisinin de iyileştirilmesi gerektiğine dair bir görüş vardır.
Ayrıca, EIP-1559 ile ilgisi olmayan Ethereum kaynak fiyatlandırma zayıflıkları vardır, ancak bunlar EIP-1559'un ayarlamaları ile çözülebilir. Ana sorunlardan biri, ortalama durum ile en kötü durum arasındaki farktır: Ethereum'daki kaynak fiyatları, bir bloğun tamamının gaz tüketiminin bir kaynağı kapladığı en kötü durumu ele alacak şekilde ayarlanmalıdır, ancak gerçek ortalama kullanım bunun çok altındadır, bu da verimsizliğe yol açar.
![Vitalik'in Ethereum'un Olası Geleceği Hakkında (Altı): The Splurge])https://img-cdn.gateio.im/webp-social/moments-fe95dd28b911aea1a22365468b7c42cd.webp(
) Çok Boyutlu Gas nedir, nasıl çalışır?
Bu düşük verimlilik sorunlarını çözmenin yolu çok boyutlu Gas: Farklı kaynaklar için farklı fiyatlar ve kısıtlamalar belirlemektir. Bu kavram teknik olarak EIP-1559'dan bağımsızdır, ancak EIP-1