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

Yazan: Vitalik Buterin

Bazı şeyleri tek bir kategoriye koymak zordur, Ethereum protokol tasarımında, birçok "detay" Ethereum'un başarısı için 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şmaktadır, 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 et, tüm kullanıcıların daha güvenli ve pratik bir hesap deneyimi yaşamasını sağlar.
• İşlem ücretleri ekonomisini optimize et, ölçeklenebilirliği artırırken riski azalt.
• Gelişmiş kriptografiyi keşfetmek, Ethereum'un uzun vadede önemli ölçüde iyileşmesini sağlamak

EVM iyileştirmesi

Hangi sorunu çö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, ancak özel destek ile önceden derlenmiş kod ile mümkündür.

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

Mevcut EVM geliştirme yol haritasının ilk adımı, bir sonraki sert çatala dahil edilmesi planlanan EVM nesne formatıdır (EOF). EOF, birçok benzersiz özelliğe sahip yeni bir EVM kodu versiyonunu belirten bir dizi EIP'den oluşmaktadır, en dikkat çekici olanları şunlardır:

• Kod (çalıştırılabilir, ancak EVM'den okunamaz) ile veri (okunabilir, ancak çalıştırılamaz) arasındaki ayrım
• Dinamik yönlendirmeler yasaktır, yalnızca statik yönlendirmelere izin verilir
• EVM kodu, yakıtla ilgili bilgileri artık gözlemleyemez.
• Yeni bir açık alt rutin mekanizması eklendi

Eski sözleşmeler var olmaya devam edecek ve oluşturulabilecek, ancak sonunda eski sözleşmelerin kademeli olarak terk edilmesi (hatta EOF koduna zorunlu dönüşüm) mümkün olabilir. Yeni sözleşmeler, EOF'un getirdiği verimlilik artışından faydalanacak------ilk olarak alt rutin özellikleriyle biraz küçülen byte kodu, ardından ise EOF'a özgü yeni işlevler veya azalan gaz maliyetleri ile.

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 hesaplamalar 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 çarpması gibi optimizasyonların kullanılmasını mümkün kıldı.

Daha yeni bir fikir, EVM-MAX'ı tek komut çoklu veri (SIMD) özellikleri ile birleştirmektir. SIMD, Ethereum'un bir konsepti olarak uzun zamandır mevcuttur ve ilk olarak Greg Colvin'in EIP-616'sında ortaya konmuştur. SIMD, birçok kriptografi biçimini hızlandırmak için kullanılabilir, bunlar arasında hash fonksiyonları, 32 bit STARKs ve ızgara tabanlı kriptografi bulunmaktadır. EVM-MAX ve SIMD'nin birleşimi, bu iki performansa yönelik ölçeklenmenin doğal bir eşleşmesini sağlar.

Bir EIP kombinasyonunun genel tasarımı EIP-6690 ile başlayacaktır, 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'u (toplama, çıkarma, çarpma) için, 3 tane anlık sayı x, y, z yerine 7 tane anlık sayı: x_start, x_skip, y_start, y_skip, z_start, z_skip, count kullanan bir versiyon ekleyin. 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 bir şekilde işlenecektir.

• XOR, AND, OR, NOT ve SHIFT (döngüsel ve döngüsel olmayan dahil) eklenebilir, en azından 2'nin kuvveti modülünde. Aynı zamanda ISZERO (çıktıyı EVM ana yığınına iten) eklenmesi, eliptik eğri kriptografisi, küçük alan kriptografisi (örn. Poseidon, Circle STARKs), geleneksel hash fonksiyonları (örn. SHA256, KECCAK, BLAKE) ve ızgara tabanlı kriptografi gerçekleştirmek için yeterince güçlü olacaktır. Diğer EVM yükseltmeleri de uygulanabilir, ancak şimdiye kadar dikkate alınma oranı daha düşüktür.

Mevcut araştırma bağlantısı

• EOF:
• EVM-MAX:
• SIMD:

Kalan işler ve dengeleme

Şu anda, EOF'un bir sonraki sert çatalla dahil edilmesi planlanıyor. Ancak, her zaman son dakikada bunu kaldırma olasılığı vardır------önceki sert çatallarda bazı işlevler geçici olarak kaldırılmıştır, ancak bunu yapmak büyük zorluklarla karşılaşacaktır. EOF'u kaldırmak, gelecekte EVM'ye yapılacak her türlü güncellemenin EOF olmadan yapılması gerektiği anlamına gelir, bu mümkün olsa da, 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 miktarda koddur ve statik kod kontrolü de nispeten karmaşıktır. Ancak, bunun karşılığında yüksek düzeydeki 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 üzerine inşa edilmesi gerektiği söylenebilir.

Yapılması gereken önemli bir iş, EVM-MAX benzeri SIMD işlevselliğini uygulamak ve çeşitli kripto işlemlerinin gaz tüketimini standart hale getirmektir.

Harita ile diğer bölümlerle nasıl etkileşim kurabilirim?

L1, EVM'sini L2'nin de daha kolay bir şekilde uyum sağlayabilmesi için ayarlamaktadır; eğer her iki taraf da senkronize bir şekilde ayarlama yapmazsa, uyumsuzluklar meydana gelebilir ve olumsuz etkiler yaratabilir. Ayrıca, EVM-MAX ve SIMD, birçok kanıt sisteminin gaz maliyetlerini düşürebilir, böylece L2'nin daha verimli olmasını sağlar. Aynı görevleri yerine getirebilen EVM kodları ile daha fazla önceden derlenmiş kodun değiştirilmesi de daha kolay hale gelir ve bu, verimliliği büyük ölçüde etkilemeyebilir.

hesap soyutlama

Hangi sorunu çözdü?

Şu anda, işlemler yalnızca bir yöntemle doğrulanabilir: ECDSA imzası. Başlangıçta, hesap soyutlaması bunu aşmayı amaçlıyordu ve hesap doğrulama mantığı için herhangi bir EVM koduna izin veriyordu. Bu, bir dizi uygulamayı etkinleştirebilir:

• Kuantum Dirençli Kriptografi'ye Geçiş
• Eski anahtarları döndürmek (genellikle ö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 anahtar grubu) kullanın

Gizlilik protokolünün ara birim olmadan çalışmasına izin vermek, karmaşıklığını önemli ölçüde azaltır ve kritik bir merkezi bağımlılık noktasını ortadan kaldırır.

2015 yılından bu yana hesap soyutlaması önerildiğinden beri, hedefleri birçok "kolaylık hedefi" içerecek şekilde genişlemiştir; örneğin, ETH'si olmayan ancak bazı ERC20'leri olan bir hesabın ERC20 ile gaz ödeyebilmesidir. Aşağıda bu hedeflerin özet grafiği bulunmaktadır:

MPC (Çok Taraflı Hesaplama), anahtarları birden fazla parçaya ayırmak ve bunları birden fazla cihazda saklamak için kullanılan, 40 yıllık bir geçmişe sahip bir teknolojidir. Bu teknoloji, bu anahtar parçalarını doğrudan birleştirmeden imza oluşturmak için kriptografik teknikler kullanır.

EIP-7702, tüm kullanıcıları (EOA kullanıcıları dahil) faydalandırmak amacıyla hesap soyutlama kolaylığı sağlamak için artan bir farkındalığın sonucu olarak, bir sonraki sert çatalla birlikte tanıtılması planlanan bir öneridir. 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'ye dönüştü. EIP-7702, hesap soyutlamasının "kolaylık işlevlerini" tüm kullanıcılara sunmaktadır, bu da bugünün EOA'larını (ECDSA imzasıyla kontrol edilen dış sahipli hesaplar) kapsamaktadır.

Grafikten görülebilir ki, bazı zorluklar (özellikle "kolaylık" zorluğu) çok taraflı hesaplama veya EIP-7702 gibi ilerici teknolojilerle çözülebilir, ancak hesap soyutlama önerisinin başlangıçta ortaya konan ana güvenlik hedefi yalnızca geri dönerek ve temel sorunu çözerek gerçekleştirilebilir: akıllı sözleşme kodunun işlem doğrulamasını kontrol etmesine izin vermek. Şu ana kadar başarılmamış olmasının sebebi güvenli bir şekilde uygulanması gereken bir zorluk olmasıdır.

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

Hesap soyutlamasının temeli basittir: 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şı önlem almakla ilgilidir.

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

Eğer 1000 hesabın doğrulama fonksiyonu belirli bir tekil değer S'ye bağımlıysa ve mevcut değer S, hafıza havuzundaki işlemlerin hepsinin geçerli olmasını sağlıyorsa, S değerini değiştiren tekil bir işlem hafıza havuzundaki diğer tüm işlemleri geçersiz kılabilir. Bu, saldırganların hafıza havuzuna çöp işlemleri 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.

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ğrulama işlemleri önce işlenir, tüm yürütme işlemleri ise ardından işlenir. Bellek havuzunda, kullanıcı işleminin doğrulama aşaması yalnızca kendi hesabını içeriyor ve çevresel değişkenleri okumuyorsa kabul edilecektir. 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ı bir gaz sınırlaması uygulanır.

ERC-4337, Ethereum istemcileri geliştiricileri birleştirmeye (Merge) odaklandıkları için, ek bir protokol standardı (ERC) olarak tasarlanmıştır ve diğer işlevleri ele almak için ek bir enerji harcamamışlardır. Bu nedenle ERC-4337, normal işlemler yerine kullanıcı işlemleri olarak adlandırılan nesneleri kullanmaktadır. Ancak, son zamanlarda, içeriğin en azından bir kısmının protokole yazılması gerektiğini fark ettik.

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

1. EntryPoint'in sözleşmenin doğal verimsizliği: Her paket yaklaşık 100,000 gazlık sabit bir maliyete sahiptir ve her kullanıcı işlemi için ek binlerce gaz gerekir.
2. Ethereum özelliklerinin gerekliliğini sağlamak: Listeyi içeren garantilerin, hesap soyut kullanıcılarına aktarılması gerektiği gibi oluşturulması.

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

• Ödeme Temsilcileri (Paymasters): Bir hesabın başka bir hesabın ücretlerini ödemesine izin veren bir işlevdir, bu da doğrulama aşamasında yalnızca gönderici hesabına erişim kurallarıyla çelişmektedir, bu nedenle ödeme temsilci mekanizmasının güvenliğini sağlamak için özel işlemler getirilmiştir.
• Agregatörler (Aggregators): BLS agregasyonu veya SNARK tabanlı agregasyon gibi imza agregasyonunu destekleyen bir işlev. Bu, Rollup üzerinde en yüksek veri verimliliğini sağlamak için gereklidir.

Mevcut araştırma bağlantısı

• Hesap soyutlaması tarihi hakkında bir konuşma:
• ERC-4337:
• EIP-7702：
• BLSWallet kodu (birleştirme işlevini kullanarak):
• EIP-7562 (protokole yazma hesap soyutlama):
• EIP-7701 (EOF tabanlı yazım protokolü hesap soyutlama):

Kalan